分布式系统架构理论与组件

1.分布式系统的发展

在计算机发展的早期，一直都是集中式计算，计算能力依赖大型计算机。随着互联网的发展，繁重的业务需要巨大的计算能力才能完成，而集中式计算无法满足要求，大型计算机的价格也非常昂贵。分布式计算将任务分解成更小的部分，分配给多台计算机处理，这样可以节约整体计算时间，大大提高计算效率。

互联网大型网站往往面临高并发访问、海量数据处理等问题，必须保证系统高可用、易伸缩等等。分布式架构采用多台机器协同工作，动态伸缩容量，使用冗余节点来消除单点故障，提高系统可用性。

2.分布式系统的挑战

软件开发没有银弹，任何系统结构都有利有弊，分布式系统的挑战有三点：

• 1）网络资源受限：节点间采用网络通信，而网络存在带宽限制和延时，任何一个节点都无法做到瞬间响应和高吞吐量。
• 2）节点管理成本：分布式系统节点可能膨胀到成千上万个，运维节点的成本非常高。
• 3）缺乏全局时钟：网络上计算机时钟同步的准确性受到极大的限制，没有一致的全局时间。计算机在空间随意分布，很难定义不同机器上事件先后发生顺序。

3.分布式系统基本理论

3.1 CAP定理

分布式系统的三个特性Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），最多只能同时满足其中两个，三者不可兼得。

• Consistency (一致性)：数据更新后，所有节点在同一时间的数据完全一致。客户端并发访问时，返回的数据是一致的。服务端尽快将数据复制到整个系统，以保证数据最终一致。
• Availability (可用性)：系统能够一直为用户服务，不出现操作失败或者超时等情况。在单位时间内的可用性常用N个9来衡量，比如99.999%的可用性。
• Partition Tolerance (分区容错性)：分布式系统内部由许多节点构成，外界看上去是一个整体。节点或网络分区遇到故障的时候，仍然能够对外提供满足一致性或可用性的服务。系统中少量机器宕掉，剩下的机器还能够正常运转，用户没有任何感知。

大型互联网应用的集群节点非常多，发生节点或者网络故障是常态。系统必须要满足分区容错性，最终只能在C和A之间取舍。

传统行业项目有所不同，以金融系统为例，涉及到金钱的操作，必须要满足数据一致性。出现网络故障宁可停止服务，也要保证C，最终只能在A和P之间取舍。

3.2 PACELC理论

CAP理论并不能很好的指导现实的系统架构。比如Availability (可用性)，如果接口长时间才返回结果，固然可用，但是业务上不能接受。大部分情况下，系统分区都是平稳运行的，系统设计要权衡延迟与数据一致性的问题。为了保证数据一致性，读写的延迟必然升高。

在分区错误的情况下，在C和A中取舍，缩写为 PAC。分区正确的情况下，取 Latency（延迟）与 Consistency（一致性），缩写为LC。PACELC 中的 E 代表 Else，连起来就是PACELC。

很多存储软件实现了 PACELC 的策略，用户根据不同业务场景使用不同的配置。以MySQL主从复制为例，提供了三种模式：

• 异步模式：主库执行完客户端提交的事务，立即将结果返给客户端，不关心从库是否已经接收并处理。由于数据同步的延时，客户端在从库上可能读不到最新数据。这种模式对MySQL是性能最佳的，但是用户需要权衡，业务能否忍受这种延时。
• 全同步复制：主库执行完客户端提交的事务，所有的从库都执行了该事务才返回结果。这样保证强一致性，但是响应时间变长了。
• 半同步