分布式系统架构以及 CAP 原理
点击蓝色“大数据每日哔哔”关注我
加个“星标”，第一时间获取大数据架构，实战经验
● 本文主要分为以下几个部分：
什么是分布式系统
对 CAP 的一点理解
一点总结
参考文献
扩展阅读
一、什么是分布式系统？
关于分布式系统的定义，《分布式系统原理和范型》一书中是这样定义分布式系统的：“分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像是单个系统”。
(图片选自《分布式系统常用技术及案例分析》)
设计一个分布式系统，需要考虑很多方面。比如系统如何拆分子系统？如何规划子系统中的通信？通信是否安全？系统是否具有扩展性？子系统如何让实现可靠性？数据的一致性如何保证？等等，都不是很好解决。
但是对于我们一般的用户来说，开源世界已经有完善的解决方案和工具了，比如，我们在设计通信时，我们可以采用面向消息的中间件，比如Apache ActiveMQ、RabbitMQ、Apache RocketMQ、Apache Kafka等，也有类似与 Google Protocol Buffer、Thrift等 RPC框架。在设计分布式计算时，我们分布式计算可以采用 MapReduce、Apache Hadoop、Apache Spark 、Apache Flink 等。在大数据分布式存储方面，我们可以选择 HDFS、Apache HBase、Apache Cassandra、Memcached、Redis、MongoDB等。在分布式监控方面，常用的技术包括Nagios、Zabbix、Consul、ZooKeeper等。
二、对 CAP 的一点理解
2000 年 7 月，加州大学伯克利分校的 Eric Brewer 教授在 ACM PODC 会议上提出 CAP 猜想。2 年后，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP。之后，CAP理论正式成为分布式计算领域的公认定理。
首先我们先来看看 CAP 分别代表什么？
一致性：更新操作成功并返回客户端完成后,分布式的所有节点在同一时间的数据完全一致。（注意：这里说的是强一致性。）
可用性: 读和写操作都能成功。无论何时，都可以在有效时间内返回用户的请求。
分区容错性：再出现网络故障导致分布式节点间不能通信时，系统能否继续服务
需要注意的是：在分布式系统中，没有一种设计可以同时满足一致性、可用性、分区容错性 3 个特性。CAP 三者不是对等的，其中 P 是基础，CA 之前需要权衡。
如果说Spanner真有什么特别之处，那就是谷歌的广域网。Google通过建立私有网络以及强大的网络工程能力来保证P，在多年运营改进的基础上，在生产环境中可以最大程度的减少分区发生，从而实现高可用性。
CAP之父在《Spanner，真时，CAP理论》一文中写到
在全球广域地理分布环境下（全球规模的分布式系统），网络分区是一个自然的事实，甚至有人认为是必然的。（用来解释为什么 P 是基础。）
上面提到的一致性可以分为几类：强一致性、单调一致性、弱一致性、会话一致性、最终一致性。
| 强一致性 |
任何时刻，任何用户都能读取到最近一次成功更新的数据。 |
单调一致性 |
任何时刻，任何用户一旦读到某个数据在某次更新后的值，那么就不会再读到比这个值更旧的值。也就是说，可获取的数据顺序必是单调递增的。 |
| 弱一致性 |
用户无法在确定时间内读到最新更新的值。 |
| 会话一致性 |
任何用户在某次会话中，一旦读到某个数据在某次更新后的值，那么在本次会话中就不会再读到比这值更旧的值，会话一致性是在单调一致性的基础上进一步放松约束，只保证单个用户单个会话内的单调性，在不同用户或同一用户不同会话间则没有保障。 |
| 最终一致性 |
用户只能读到某次更新后的值，但系统保证数据将最终达到完全一致的状态，只是所需时间不能保障。 |
三、总结
文章开头部分也提到了，现在的开源世界已有完善的分布式系统解决方案了，我们没有必要重复造*，难度也可想而知。我们可以在使用的过程中倒推这个系统满足了 CAP 的哪两个特性。比如：Zookpper 是 CP，P 是基础的，所有分布系统需要优先考虑这个，Zookeeper 从顺序一致性、原子性、单一镜像、持久性、实时性保证了数据的一致性。但是它在某些情况（重启或网络节点故障）下会重新选举 Leader，此时整个集群是不可用的。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。所以说，ZooKeeper不能保证服务可用性。所以 Zookepper 保证了 CP，而不是 AP。
本文只是简单的介绍了一下分布式系统概念以及CAP理论的初探，可以帮助我们更好的理解分布式框架在实际中的应用场景。更深层次的内容可以参考文末的参考以及扩展链接。欢迎一起交流~
四、参考
1.https://waylau.com/talk-about-distributed-system/
2.https://github.com/waylau/distributed-systems-technologies-and-cases-analysis
3.https://blog.****.net/qq_26222859/article/details/53079655
4.https://blog.****.net/yanpenglei/article/details/80362561
五、扩展阅读
1.https://dbaplus.cn/news-159-1917-1.html
2.《How to beat the CAPtheorem》
（完）
本文分享自微信公众号 - 大数据每日哔哔（bb-bigdata）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。