一年时间，减肥成功，撒花，感谢妹子去年送我学游泳！

最近学习 Netty 时，看到 Netty 宣称解决了很多 Java 原生 NIO 的很多 bug，其中之一是 epoll 空轮询导致 CPU 利用率 100%。

在阅读 JDK 或框架源码的时候，常常发现部分方法是以 0 结尾的，凭直觉这并非良好的命名方式，但的确广泛存在，这是为什么呢？

MongoDB 有很多超时配置，虽然它们都有各自的默认值，但为了提升应用的及时响应性、性能等，有时需根据实际情况进行修改。

不同语言、同一语言不同版本的驱动，对同一配置可能采用不同的默认值，细节需要查阅文档。

以下是比较常用的 3 个：

1. 服务器选择超时；
2. 连接超时；
3. Socket 超时；

在分布式系统中，复制是指在多个节点上保存同一数据的副本，节点之间通过网络进行通信，复制带来的好处有：

• 容错
• 水平扩展（吞吐量）
• 降时延

分布式系统容器化为多个容器容易理解，但为什么单机应用有时也需要拆分为多个容器呢，直接放到一个容器中不行吗？

首先，明确下应用容器化目的：

1. 资源隔离（CPU & 内存）
2. 管理隔离（不同镜像由不同团队负责）
3. 关注点分离（每个容器仅做一件事，并将其做好）

因此，如果单机应用有以上需求，就需要考虑将其拆分为多个容器。

当然，单机应用拆分为多个容器后，并非就变成分布式系统了，因为拆分后的容器通常借助 Kubernetes 的 Pod 运行在 同一物理节点 上，因此依然可视之为单机应用，只不过该应用现在由多个进程（容器）组成。

在 Scala 中，函数（function）和方法（method）是两个非常接近的概念，大多数场景中，可以不区分两者，如果非要区分，可查阅文末的参考文档。

根据 官方教程：

• 函数分两类：
  • 实现 FunctionN 的对象
  • 匿名函数
• 方法：在类、对象内部用 def 声明

很多框架要求应用（正常 or 异常）退出时，显式进行“善后”处理，如释放资源、防止数据不一致、主动告知自己死亡，避免被动检测带来的时间浪费等等。

下面以 Kafka Streams 为例介绍如何实现优雅停机。

应用关闭后，应显式关闭 Kafka Streams 线程，以防止数据不一致、进行 task 迁移等：

1
2

// KafkaStreams#close()
streams.close();

为实现优雅停机，以上代码应该放到 shutdown 钩子中：

1

Runtime.getRuntime().addShutdownHook(new Thread(archiveStreams::close));

时至今日（2019 年），微服务已经飞入寻常百姓家，但关于微服务的争论却还没有停止（事实上早就该停止了），我在公司 espace 群里经常听到两种截然不同的观点：

1. 微服务解决了很多问题，不上微服务就是不先进，就是技术落后；
2. 微服务没有解决问题，反而引入了很多复杂性；

这两种说法各自阐述了微服务的一面，合起来才是对它的完整描述：

以增加复杂度为代价，微服务解决了很多问题。

至于该不该使用微服务，则需要先了解微服务解决了什么问题，又引入了什么问题，只有明确了它的优点和缺点，才能根据实际业务需求做出理智的权衡。

quorum [ˈkwɔ:rəm]，法定人数

Quorum 机制是一种投票算法，核心思想是：

执行某操作之前，必须先获取足够的票数。

在分布式系统中，Quorum 投票有两种常见用法：

• 副本读写控制：保证同一数据的多个副本在每一时刻，只能用于读 or 写；
• 事务提交协议：存在网络分区时，保证分布式事务的原子性；