铜川做网站,网站动态效果用什么软件做的,0元试用网站开发,网站建设需要会什么文章目录 1. 三座大山 NPC 的概念2. NPC 细分理解2.1. Network Delay 网络延迟2.2. Process Pause 进程暂停2.3. Clock Drift 时钟漂移Is the Algorithm Asynchronous? 本文参考#xff1a; RedLock红锁安全性争论#xff08;上#xff09; https://martin.kleppmann.com/… 文章目录 1. 三座大山 NPC 的概念2. NPC 细分理解2.1. Network Delay 网络延迟2.2. Process Pause 进程暂停2.3. Clock Drift 时钟漂移Is the Algorithm Asynchronous? 本文参考 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暂停甚至可能合谋组合它们的延迟。如果磁盘实际上是一个网络文件系统或网络块设备如亚马逊的EBSI/O延迟进一步受到网络延迟变化的影响。如果操作系统配置为允许交换到磁盘分页则简单的内存访问可能导致页面错误page fault要求将磁盘中的页面装入内存。当这个缓慢的I/O操作发生时线程暂停。如果内存压力很高则可能需要将不同的页面换出到磁盘。在极端情况下操作系统可能花费大部分时间将页面交换到内存中而实际上完成的工作很少这被称为抖动thrashing。为了避免这个问题通常在服务器机器上禁用页面调度如果你宁愿干掉一个进程来释放内存也不愿意冒抖动风险。可以通过发送SIGSTOP信号来暂停Unix进程例如通过在shell中按下Ctrl-Z。
简单总结来看操作系统层面的网络IO、磁盘IO、CPU 切换编程语言层面的垃圾回收器 STW都是有可能让当前进程或者线程暂停的。甚至严格意义上来说客户端或者服务端任意一方宕机也属于进程暂停因为这就相当于程序没法继续运行下去。
考虑最坏的情况这种暂停就是有可能导致分布式锁自动超时释放从而产生并发问题或者是 RPC 调用的超时问题。
2.3. Clock Drift 时钟漂移
指两台电脑或者进程在时间流速基本相同的情况下它们之间出现的时间差值。Martin 指出时钟漂移出现的场景有 1. 运维人员手动调整系统时间 2. 同步 NTPNetwork 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》。
