科技乱炖 - 这个618貌似有点冷
618有点冷吗?
先回想一下,今年618我买什么东西了吗?好像有,又好像没有。
如果仅看618的话,我在PDD上买了一堆生活用品,但他们貌似并没有在618更便宜多少。
但如果把618拉长到601来看的话,我买了Apple Watch,然后再618前夕使用保价政策优惠了300块。
今年618动静大吗?我想,除了在朋友圈京东的同学发出来一些备战的状态,其它时候并没有收到太多的宣传。相反,它将整个周期拉长了,从五月下旬就开始预热,部分商品已经便宜了。
Hello Jellyyyyyyyyyyyyyy !!
我们在前面的文章分析了Vertx核心单机部分的源码。今天轮到Vert.x-Web,由于Web的内容比较多,因此分为上下两部分。
希望通过本文的解析,让读者了解Vertx的关键部分的实现原理。对诸如如下问题有一个具象的认识。
- Vertx实例的作用?一个应用是否只对应一个Vertx实例?
- Verticle是一个怎样的存在?
- 本地模式下消息是如何在EventBus上传输和响应的?
- EventBus和EventLoop是如何关联起来的?
目前我们开发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看似危险的控制结构,而查看手册这也是官方推荐的使用方式。于是想找找其它消息队列拉取消息的原理。
explain是SQL优化的前提。但explain的结果,无论是官方手册,还是别人写的博客,看完后点头如捣蒜,但往往看到自己SQL的执行计划时,并不很确定要优化的点在哪里。很大一部分原因是不知道各计划节点的具体含义,更确切地说,是不明白SQL执行的原理。比如,我们并不能很好地回答以下问题
- index scan、index only scan、bitmap index scan 有啥区别?
- 为什么明明有建立索引,但PG就是不用呢?
- 执行计划中有子查询就一定不好吗?
- hash join、merge join、nestloop join有啥区别?
- 。。。。。。
本文的目的,是让大家看懂SQL执行计划。毕竟,看懂了,才谈得上优化。
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文档进行记录和总结。