科技乱炖 - 这个618貌似有点冷

618有点冷吗？

先回想一下，今年618我买什么东西了吗？好像有，又好像没有。

如果仅看618的话，我在PDD上买了一堆生活用品，但他们貌似并没有在618更便宜多少。

但如果把618拉长到601来看的话，我买了Apple Watch，然后再618前夕使用保价政策优惠了300块。

今年618动静大吗？我想，除了在朋友圈京东的同学发出来一些备战的状态，其它时候并没有收到太多的宣传。相反，它将整个周期拉长了，从五月下旬就开始预热，部分商品已经便宜了。

读《西西弗神话》有感

思考人生意义的必要性

意义，亦可作价值、作用。是我们一直在找寻的东西。

上学的意义，读书的意义，工作的意义，以及终极问题——活着的意义、人生的意义。

人是需要驱动力的，而驱动力的很大一部分，来自于对自身当前境况及前途的希望和预期。当不停地对自己进行灵魂拷问，往往会发现你的生活，你的存在并无多大意义，又或者是生活的意义太过遥远，遥远导致短期的心灵空虚。希望变得若隐若现，驱动力时有时无。轻则彷徨度日，重则丧失生活的信心，走向极端。

因此，学习如何和无意义感相处，是一项重要的课题。是每个人总会遇到的问题，迟早而已。

说明：文章中代码参考使用方式即可，请忽略其代表的逻辑部分

为何想要用Spring Webflux?

《每记》是一款新产品。一开始想用webflux，为什么呢？这里给出自己的几点理由

• Spring生态加持，想必会很好用
• 一直只闻其声不见其人，很想用用
• 原计划中的vertx-spring项目，想要做成的结果，和webflux很像；因此希望从webflux中找到一些发现

馒

写在前面

在遥远而古老的二十世纪末、二十一世纪初，的四川东北部乡村，家里的面食几乎只有一种——挂面。自家种的小麦，大夏天吭哧吭哧背到大队加工厂，制面机震耳欲聋，眼看着小麦变成面粉，再变成面条，上杆、晾晒，从早上等到下午，中午吃自带的干粮。晾干、切断，用精心裁剪的报纸包装成束，装袋，再吭哧吭哧背回家。半年的面食就算完成了。这几乎是人生前十来年每年必做的工作，就像死亡和税收——无法逃脱。

我们在前面的文章分析了Vertx核心单机部分的源码。今天轮到Vert.x-Web，由于Web的内容比较多，因此分为上下两部分。

• 上：分析Vert.x-Web核心类及其主要能力。
• 下：分析HttpServer的线程调度以及Web OpenAPI的工作原理

希望通过本文的解析，让读者了解Vertx的关键部分的实现原理。对诸如如下问题有一个具象的认识。

• Vertx实例的作用？一个应用是否只对应一个Vertx实例？
• Verticle是一个怎样的存在？
• 本地模式下消息是如何在EventBus上传输和响应的？
• EventBus和EventLoop是如何关联起来的？

API的响应需要约束

目前我们开发Web API的方式是通过定义Open API描述文件来定义请求约束。约束能够保证所有请求参数按照正确的格式和必要性传输，从而规范化输入。这保护了服务端内部的安全——输入约束不变的情况下，输入的值总是合法可期的。

尽管Open API也提供了对Response Body的定义，允许用户描述响应的消息格式，但由于其不具有强制性——语法上可以不写，写了也不与实际返回内容有深入结合，因此无法验证真实API的响应是否符合预期，这也是从一开始不愿写响应体的原因。

而关于验证API响应的重要性，是不言而喻的，截止目前，至少有两个时刻让我有了“如果能够在单元测试就验证响应体格式就好了”的想法。

其一：今年上半年的一次down time，彼时是上线真米视频，其video id要做到可控（手动编写，数位字符串），而原逻辑使用了阿里云生成的video id——32位字符串。使用的方案是将手动生成的video id替换了阿里云video id，结果由于测试上的不周全导致所有视频的video id都被替换，对于那些没有分配手动id的音视频，其video id自然变成了null。而该问题因为机缘巧合对视频无影响，仅对音频产生影响。导致较长时间才发现。回首该问题，出在video id字段的格式上，如果有对响应体做约束——要求video id必须有值，且长度为32位，则该问题能够在单元测试就发现。

同事：阿里云MNS获取消息的API使用起来不够方便，需要不断手动长轮询，看起来有点原始。
我：em。。。那其它消息队列使用什么方式？难道不是长轮询？

在使用阿里云MNS（Message Notification Service）服务时，意识到其从服务端获取消息的方式是手动长轮询。写代码时可能会用到while-true看似危险的控制结构，而查看手册这也是官方推荐的使用方式。于是想找找其它消息队列拉取消息的原理。

破掉的FLAG

2019年8月11日，发布博文《我有点想要写博客了》，总结了之前一段时间的个人状态，并立下从那以后每月至少两篇博文的FLAG。如今一年过去了，不出所料，FLAG倒了。这一年间按计划应该又至少24篇新发布的文章，实际数量——20篇。且其中质量较好的不到10篇。考虑到立FLAG只有几个月里写的挺积极，则近几个月如果不是公司的一月一篇的硬性博客任务，恐怕会是触目惊心的0篇文章。

explain是SQL优化的前提。但explain的结果，无论是官方手册，还是别人写的博客，看完后点头如捣蒜，但往往看到自己SQL的执行计划时，并不很确定要优化的点在哪里。很大一部分原因是不知道各计划节点的具体含义，更确切地说，是不明白SQL执行的原理。比如，我们并不能很好地回答以下问题

• index scan、index only scan、bitmap index scan 有啥区别？
• 为什么明明有建立索引，但PG就是不用呢？
• 执行计划中有子查询就一定不好吗？
• hash join、merge join、nestloop join有啥区别？
• 。。。。。。

本文的目的，是让大家看懂SQL执行计划。毕竟，看懂了，才谈得上优化。

与MySQL相比，有何优势

1. SQL标准的null判断用is null，而不是=null。PG可以设置transform_null_equals把=null翻译成is null

Postgresql提供 监听 - 通知 的订阅服务，使得数据库客户端向服务端的指定通道注册为监听客户端，服务端在发出Notify通知时，所有已注册的监听客户端将能够收到该通知。

使用协程已经有较长的时间了，但一直停留在launch、async启动协程，suspend方法挂起的阶段。这段时间系统梳理Kotlin知识时才发现，对协程（仅对Kotlin）还有很多概念不甚了解。例如CoroutineScope对协程生命周期的重要性、协程父子结构的作用、结构化并发、一些Kotlin协程中约定俗称的规定等。

BIO、NIO、NIO2、AIO、Reactor、Proactor、EventLoop、Linux五种IO模型

上述术语和概念，相信大多数人都知道或部分知道，但都无法完整表达他们之间的意思，处于模棱两可的状态。我也不例外，而触发写这篇文章的契机，是有人问起我Vertx高性能的原因是什么时？我不假思索地回答NIO，因为在我的印象中，Vertx基于Netty实现，Netty又是对NIO的包装。但仔细想想，用NIO就能高性能吗？NIO和Vertx的EventLoop有什么关系呢？和Reactor又是什么关系呢？——我不禁开始思考人生。

下面就开始探索吧

Java8中引入了新的库java.time，提供更为好用的日志API，从此不再在Date、Calendar这些类中纠结。本文基于java.time API文档进行记录和总结。