17. 典型地,在底层硬件上,当单个 CPU 制程到 10ns 以内级别的级别,由于量子效应的影响
会逐渐更大,导致制程到头了。这样单个 CPU 无法改进,我们就看到了各种各样的多核技
术,把多个 CPU 做到一起,让它们协同工作。同时为了更好的利用内存,我们可以给不同
的 CPU 以不同的内存(包括缓存)。这就是所谓的 NUMA 架构。我们可以把它看做是一
个分布式技术在硬件的应用。
同样地,在软件的层面,我们把一个系统的各个部分也拆解成不同的单元,独立运行,也
就形成了分布式系统,进而发展出来了分布式服务,分布式文件系统,分布式消息队列,
分布式事务,分布式数据库等等。
当原先的一个单机系统,变成了由很多个不同机器节点组成的复杂分布式系统以后,整个
系统的环境就会变得复杂。整体间的协调,管理,就成为了一个比较大的挑战。
这方面,google 在分布式领域的三篇经典论文(DFS/MapReduce/Bigtable),某种程度
上解决了分布式文件系统、分布式计算和数据存储的一些常见问题。
谈谈 CAP 不可能三角形
(/)
18. 分布式环境
分布式环境与单机环境最大的区别在于:单机是一个由 底层系统(操作系统,HAL,BIOS
以及固件) 层层包裹的整体。从应用角度看,组成这台机器的硬件要么(看上去)都在正
常状态,要么都不在状态,不需要过分关注。
在单机环境,操作系统及 BIOS 既不会向软件报告有一个 CPU 或内存被拔出插槽,也不会
报告某条系统总线发生超时 —— 应用也不需要设计成在这种情况下还要继续工作。
而 分布式环境 天生就需要处理部分失效。原因很简单:分布式 = 多个节点。概率论告诉我
们:节点数越多,单个节点发生意外故障的概率就越大。而且,这里并没有 分布式操作系
统 帮助我们处理这种意外。
因此,在分布式环境,应用要负责处理节点故障带来的部分失效。早在 2000 年,Eric
Brewer 教授就提出,分布式系统的部分失效遵循一个定理:
CAP 定理
缩写 CAP 代表 Consistency(一致性), Availability(可用性)和 Partition tolerance(分区
容忍性)。注意:这里的 Consistency 与 ACID 里的数据一致性(C)概念不一样。这里指
分布式节点拥有相同的数据副本。
CAP 定理断言,任何一个分布式系统都不可能同时满足 C-A-P 三个特性:
C -- 从每个节点读到相同的数据。 A -- 从任何位置发起的读写请求都能够成功返回。 P --
即使出现分区(部分隔离),也能响应请求。
这是可以证明的。设想一下,当一个分布式系统发生了部分失效:
系统被故障分隔成了两个区域:写入区域(1)的数据无法传播到区域(2),而产生在区
域(2)的读请求也不能转发到区域(1)。
(/)