Hi~各位读者朋友们，感谢您阅读本文，我是笠泱，本期分享下我对分布式系统的一些认知和理解。
本期导语
我们先来思考一个问题：什么是分布式系统，为什么会有分布式系统？
分布式的对立面是单体，单体是指将某个应用系统仅部署在一台服务器节点上。而分布式是指多台服务器节点协同作业实现应用系统完整功能，节点间协同必然会经由网络通信。
要回答为什么会有分布式系统我们先看看传统的单体架构面临什么问题？随着业务的发展，一个应用系统必然会演化出多功能模块，功能模块间也必然会有业务上的逻辑依赖和调用关系，如果全部署在单台服务器上，当其中一个功能模块资源占用过高或崩溃可能会引起整台服务器宕机进而影响其他功能，这就好比“鸡蛋不要放一个篮子里”，所以我们需要对多功能模块的应用系统进行拆分解耦部署在不同服务器上，各服务器节点通过网络通信协作实现应用系统的完整能力。
因为分布式系统是基于网络通信的，以下八点内容对网络运算的认识是错误的：
1、The network is reliable -- 网络是可靠的。
2、Latency is zero -- 延迟是不存在的。
3、Bandwidth is infinite -- 带宽是无限的。
4、The network is secure -- 网络是安全的。
5、Topology doesn't change -- 拓扑结构是一成不变的。
6、There is one administrator -- 总会有一个管理员去兜底。
7、Transport cost is zero -- 不必考虑传输成本。
8、The network is homogeneous -- 网络是同质化的。
CAP定理
2000年7月，加州大学伯克利分校的 Eric Brewer 教授在ACM PODC 会议上提出CAP 猜想。两年后，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP。之后，CAP 论正式成为分布式计算领域的公认定理。
CAP定理是指一个分布式系统最多只能同时满足一致性(Consistency) 、可用性(Avallability) 和分区容错性(Partition tolerance) 这三项中的两项
- 一致性(Consistency): 一致性指 all nodes see the same data at the same time，即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致
- 可用性(Availability): 可用性指Reads and writes always succeed，即服务一直可用，而且是正常响应时间
- 分区容错性(Partition tolerance): 分区容错性指the system continues to operate despite arbitrary message loss or failure of part of the system，即分布式系统在遇到某节点或网络分区故障的时候，仍然能够继续运行
简单理解如下：
C：一致性 -->强一致性，原子性 CAP的C是强一致性
A：可用性 --> 高可用 + 高性能，即服务一直可以用，而且是正常的响应时间
P：分区容错性 -->网络分区 数据需要通过网络进行同步 当一个分区（节点）发生故障时能转到其他分区处理
CAP权衡
通过 CAP 理论，我们知道无法同时满足一致性、可用性和分区容错性这三个特性，那要舍弃哪个呢?
按CAP定理理论上有CA、CP和AP三类组合，但实际情况却是因物理世界的网络不可能100%可靠，一定会发生分区，对分布式系统而言分区容错性是系统设计时必须要考虑的，换句话讲CA系统在物理世界下一定不可能以分布式形式存在，所以分布式系统只能是CP系统或者AP系统中的一个。
对于多数大型互联网应用的场景，服务器节点众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9，即保证AP，舍弃C(退而求其次保证最终一致性)。虽然某些地方会影响客户体验，但没达到造成用户流程的严重程度。
对于涉及到金融类这样不能有一丝让步的场景，一致性是必须保证。网络发生故障分区时宁可停止服务，这时需要保证CP舍弃 A，例如网络故障时只读不写。
BASE理论
eBay 的架构师 Dan Pritchett 源于对大规模分布式系统的实践总结，在 ACM 上发表文章提出 BASE 理论，BASE理论是对 CAP 理论的延伸，核心思想是即使无法做到强一致性(Strong Consistency，CAP 的一致性就是强一致性)，但应用可以采用适合的方式达到最终一致性 (Eventual Consitency)
- 基本可用(Basicallv Available): 基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现
- 软状态(Soft State): 软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。MySQLReplication 的异步复制也是一种体现
- 最终一致性(Eventual Consistency): 最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况
如何判定一个分布式系统是CP还是AP系统？
判定方法：假设将分布式系统的服务器节点同时破坏仅保留一个，如果连上该节点还可用就是AP，如果不可用就是CP
另一个简单判断方法：存数据的中间件都应该优先CP系统，例如分布式数据库、ES、zookeeper
1、Nacos：Nacos有两个功能即注册中心和配置中心，Nacos可以通配置实现选择部署成什么系统，注册中心时优先保可用，可配置成AP系统 ，配置中心时优先保一致，可配置成CP系统。
2、Mysql：严格来讲原生的mysql在设计之初并未考虑分布式使用场景，原生的mysql其实是个单体CA系统，而通常采用binlog主从同步的mysql集群方案其实是AP系统，那针对原生支持分布式集群部署的数据库则是CP系统，例如Percona、TiDB、OceanBase，只是为了保证一定程度的A，引入了多数派原则。
3、Redis：也要分情况看，因为Redis的集群化和持久化方案有多种，但一般而言缓存都具有临时性，一般视为AP系统
4、分布式一致性协议：gossip协议就是典型的 AP代表，ZAB、Raft、Paxos协议是典型的CP代表
本期总结
本期内容分享了对分布式系统和CAP定理的一些理解，最后作者想谈下架构设计通式，所以系统的架构设计都可以围绕高可用、高性能、高并发、高安全、高扩展、可观测这6个指标，想要很好的满足这6大指标，通常需要引入微服务，而微服务的实现途径就是通过分布式解决方案。
最后，感谢您的阅读！系列文章会同步更新在微信公众号@云上的喵酱、阿里云开发者社区@云上的喵酱、CSDN@笠泱，您的点赞+关注+转发是我后续更新的动力！
