分布式难题-三座大山NPC

本文参考：

• RedLock红锁安全性争论（上）

• https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html

• https://redis.io/docs/latest/develop/use/patterns/distributed-locks/#analysis-of-redlock

在复习梳理 Redis 分布式锁的过程中，拜读了 Martin 大佬关于如何设计 Redis 分布式锁的文章，其中针对红锁 RedLock 安全性的问题，Martin 大佬也在文章中提出了很多见解。红锁的不可靠问题，其实很大部分也是来源于“分布式环境的不可靠”，RedLock红锁安全性争论（上） 文章中提出的“分布式三座大山 NPC” 我感觉总结得很好，所以想在文章中整理一下自己对于这个概念的理解。

1. 三座大山 NPC 的概念

分布式的三座大山 NPC:

• N: Network Delay 网络延迟
• P: Process Pause 进程暂停
• C: Clock Drift 时钟漂移

Redis 分布式锁会碰到上述问题，那由小及大，Redis 分布式锁只是整个分布式环境的一个组件，其实在整个分布式软件架构中，NPC 也是经常会出现的问题，甚至大部分软件服务的不可靠问题，都可以归因于 NPC 这三座大山。

2. NPC 细分理解

2.1. Network Delay 网络延迟

首先思考下分布式环境下不同组件通信的方式，无非就是 Http 网络通信、RPC 远程调用。不止是上面的 Redis，像其他的中间件比如 MQ、ES, 都会涉及到服务器与这些中间件的 Http 连接通信。那通信的过程中，就难以避免网络丢包、延迟的问题，这就是不可靠问题的来源。平常项目报警群中会时不时出现下游 RPC timeout 超时，客户端 web 接口超时，给用户展现的就是接口无数据返回，网页展示不出来，这种问题基本都是靠重试，最终一致性解决了。

2.2. Process Pause 进程暂停

DDIA 中列出了很多进程暂停的情况：

• 许多编程语言运行时（如Java虚拟机）都有一个垃圾收集器（GC），偶尔需要停止所有正在运行的线程。这些“停止世界（stop-the-world）”GC暂停有时会持续几分钟！甚至像HotSpot JVM的CMS这样的所谓的“并行”垃圾收集器也不能完全与应用程序代码并行运行，它需要不时地停止世界。尽管通常可以通过改变分配模式或调整GC设置来减少暂停，但是如果我们想要提供健壮的保证，就必须假设最坏的情况发生。
• 在虚拟化环境中，可以**挂起（suspend）**虚拟机（暂停执行所有进程并将内存内容保存到磁盘）并恢复（恢复内存内容并继续执行）。这个暂停可以在进程执行的任何时候发生，并且可以持续任意长的时间。这个功能有时用于虚拟机从一个主机到另一个主机的实时迁移，而不需要重新启动，在这种情况下，暂停的长度取决于进程写入内存的速率。
• 在最终用户的设备（如笔记本电脑）上，执行也可能被暂停并随意恢复，例如当用户关闭笔记本电脑的盖子时。
• 当操作系统上下文切换到另一个线程时，或者当管理程序切换到另一个虚拟机时（在虚拟机中运行时），当前正在运行的线程可以在代码中的任意点处暂停。在虚拟机的情况下，在其他虚拟机中花费的CPU时间被称为窃取时间（steal time）。如果机器处于沉重的负载下（即，如果等待运行的线程很长），暂停的线程再次运行可能需要一些时间。
• 如果应用程序执行同步磁盘访问，则线程可能暂停，等待缓慢的磁盘I/O操作完成。在许多语言中，即使代码没有包含文件访问，磁盘访问也可能出乎意料地发生——例如，Java类加载器在第一次使用时惰性加载类文件，这可能在程序执行过程中随时发生。 I/O暂停和GC暂停甚至可能合谋组合它们的延迟。如果磁盘实际上是一个网络文件系统或网络块设备（如亚马逊的EBS），I/O延迟进一步受到网络延迟变化的影响。
• 如果操作系统配置为允许交换到磁盘（分页），则简单的内存访问可能导致页面错误（page fault），要求将磁盘中的页面装入内存。当这个缓慢的I/O操作发生时，线程暂停。如果内存压力很高，则可能需要将不同的页面换出到磁盘。在极端情况下，操作系统可能花费大部分时间将页面交换到内存中，而实际上完成的工作很少（这被称为抖动（thrashing））。为了避免这个问题，通常在服务器机器上禁用页面调度（如果你宁愿干掉一个进程来释放内存，也不愿意冒抖动风险）。
• 可以通过发送SIGSTOP信号来暂停Unix进程，例如通过在shell中按下Ctrl-Z。

简单总结来看，操作系统层面的网络IO、磁盘IO、CPU 切换，编程语言层面的垃圾回收器 STW，都是有可能让当前进程或者线程暂停的。考虑最坏的情况，这种暂停就是有可能导致分布式锁自动超时释放从而产生并发问题，或者是 RPC 调用的超时问题。

2.3. Clock Drift 时钟漂移

指两台电脑（或者进程）在时间流速基本相同的情况下，它们之间出现的时间差值。Martin 指出时钟漂移出现的场景有 1. 运维人员手动调整系统时间 2. 同步 NTP（Network Time Protocol 网络时间协议）时间出现跳跃。

Redis 的官方文档中有写到：

Is the Algorithm Asynchronous?

The algorithm relies on the assumption that while there is no synchronized clock across the processes, the local time in every process updates at approximately at the same rate, with a small margin of error compared to the auto-release time of the lock. This assumption closely resembles a real-world computer: every computer has a local clock and we can usually rely on different computers to have a clock drift which is small.

At this point we need to better specify our mutual exclusion rule: it is guaranteed only as long as the client holding the lock terminates its work within the lock validity time (as obtained in step 3), minus some time (just a few milliseconds in order to compensate for clock drift between processes).

This paper contains more information about similar systems requiring a bound clock drift: Leases: an efficient fault-tolerant mechanism for distributed file cache consistency.

简单来说就是，RedLock 红锁算法依赖于一种假设：尽管跨进程间没有一个同步的全局时钟，但是每个进程本地的时间都是以相同的流速更新的，相对于分布式锁自动释放的时间，不同进程之间的 clock drift 是非常小的，这个道理也是适用于当前现实生活中的计算机上的。

由此可见，分布式环境本身就是不可靠的！我们平时的项目编程甚至可以说是面向不可靠性的编程，了解这些道理是不是可以让自己对于分布式的理解更上一层楼了呢。有机会一定拜读一下 Martin 大佬的《 Designing Data-Intensive Applications》。