关于分布式系统的一些理解及思考 I

前言

我是 Porterxie，一个爱问为什么的程序员。

最近在理解某些分布式系统产品时，发现之前从网上学习到的一些零散碎片化的分布式理论、人类正常思考逻辑与产品本身设计思想这三者之间产生了矛盾，确实让我产生了一些困惑。因此打算做一个《关于分布式系统一些理解及思考》的合集，记录下自身的困惑以及个人主观的理解，而非聊一些结论性的东西，因此文章主要是自身的理解和认识，必然会存在理解错误的地方，忘见谅。

对于个人而言，我认为计算机技术是一种很连贯的东西，每一项技术的产生都是针对现实的问题，而不是凭空产生，因此了解技术前世今生，连贯性、系统性的去学习很有必要的。有时候我们在学习技术的时候往往都是以点入面，当你要深入去学习一门技术时，我建议阅读完整的书籍或者一些技术大佬的文章（虽然有时候并不连贯，但是会给你启发，把你引入正确的道路），而非仅有概念描述或常人无法理解文章（也可能是我 IQ 不够），我曾也读到过一些完全抄袭某些书本内容但又不完整的文章（让人有点哭笑不得）。

什么是分布式系统

相对单机系统（通常为单进程）部署在单个节点上而言，分布式系统通常由多个进程模块组成（可能分布在不同节点上）并且之间通过网络通信发生信息或数据的交换。

分布式与集群有一定的相似点（都是由多个进程模块组成，且都可能分布在不同节点上），会产生一些混淆。

集群系统主要是为了提高系统整体的负载能力而在物理部署结构上进行调整，通常是增加相同模块数量以及通过负载均衡模块根据某种规则将请求路由到这些模块上，以此分担系统负载，并且模块不存在信息交换或仅通过共享存储交换（通常在设计之初就并未考虑过相同模块之间通过网络通信进行信息与数据交换）。

分布式系统通常为解决某些实际问题，而在系统设计之初就进行考量，进程模块之间通过网络通信完成信息与数据的交换。从广义角度看，模块（可以是任何实体）之间存在通信（可以是任意方式的通信），我们就可以称之为分布式。例如：快递将包裹从发件人送到你的手上，交互模块是人，之间的通信方式是快递运输，又例如：当我们手机通过网络将数据传输到服务器上的整个过程，其实也可称之为分布式系统。

当然，此处我们所聊仅限于计算机体系下的分布式系统，该体系下的分布式系统从不同的角度看，可以分为多种类别，此处我姑且将其划分为：分布式计算、分布式数据两类。

对于不同类别的分布式系统，所面临的挑战及解决方案是不一样的，例如分布式计算系统在遇到网络或者节点问题时，可以对失败任务或整个任务进行重算，而分布式数据系统，在遇到类似问题时，所要面临的是可用性、数据的不一致或数据丢失问题。

为什么要聊分布式系统

对于目前多数的应用系统而言，是由应用系统将一系列的标准模块联系在一起组成，诸如：数据库、缓存、消息队列、数据存储等，其中对于数据保存占据了应用系统中的重要位置（换句话说：只要数据正确且不丢失，其他运行状态都可恢复），因此在本文中我们所要聊的也是分布式数据系统（后文中如提到分布式系统未加说明也指分布式数据系统）。

通常在做系统设计时，我们会做两方面的思考：一方面是功能性的思考（产品需求），另一方面是非功能性的思考（可靠性、扩展性、维护性、安全性、兼容性、合规性等）。而在非功能性中，我们通常会将可靠性放在重要位置去考量，特别是在产品是面对客户的情况下，系统是否可靠是能够直接影响用户体验及好感度。试想这样一种场景：用户将它们的重要文件存放在服务器上，因为服务器磁盘损坏，导致数据丢失时，那么该如何去跟客户解释（让我想起一句话：程序和程序员有一个能跑就行）。面对上述场景时，通常会将数据文件采用多副本（分布式），存放在不同机器甚至不同地区的方式，来保证在单台节点磁盘损毁时，不会造成数据永久丢失（容错是一定范围内的，假设银河系不在了，此种程度容错成本是非常高的）。当然分布式系统不仅仅是用来解决数据丢失的容错，例如我们会将数据分散在不同节点上来提高系统负载能力，又或是将数据放在更靠近用户的数据中心，降低用户访问的延迟（例如 DNS）。

标准模块屏蔽了诸多分布式系统问题的细节，以 API 或 SQL 等方式，为我们应用系统提供服务。标准模块不同功能分类下，有多种功能类似的产品出现，它们由不同公司或者机构去运营，在面对这样一个 “百家争鸣” 的现实，我们该如何去看待、理解及选择合适产品组件，通常是比较麻烦和费事的。

我的建议是：

• 明确系统设计中的难点，这些产品是否能够支持；
• 应该清楚系统中的难点本身所面临的挑战，这样才能更加清晰的去知道这些产品组件是否真的能够为你提供支持，而非它们宣传的那样。

这也是我想聊分布式系统的原因。

分布式系统面临的挑战

• 网络通信存在延迟及不可靠，可能发生网络中断
• 节点本身的不可靠性，例如程序或系统 BUG、断电、硬件故障及其他人为破坏等

分布式系统通过网络通信进行信息及数据的交换，但因为网络通信延迟及不可靠或节点本身的不稳定性，引发更多让我们考虑的问题。

例如在数据库主从复制中（通常是一主多从，提高读性能），复制过程在某个时刻，所有节点的数据可能是不一致的，在用户读取数据时存在不能读到最新数据或某次读取到比之前更早的数据的问题，这样的问题会对用户造成一定的困扰。针对第一个问题，通常可以采用回主读的方式，对于第二个问题，可采用单调读的方式（通过某项规则，让每次请求都落在同一台机器上）。但是所有请求采用回主读时，就不能提高读性能，一般会采用一种折中的方案，例如读自己写的方式（对于用户自身信息查询回主读，读取其他用户信息使用副本读）。

上述例子仅仅是分布式系统在某种特定场景下的所要考虑的问题之一，也仅是为了表达“在分布式系统中有诸多需要考虑的问题，且并没有特别完美的方案，通常会根据实际业务需求做出取舍”这样一个观点。

关于 CAP 理论

关于 CAP 理论，我的观点是：可以作为理解分布式系统的考虑面，但切忌生搬硬套，其次更推荐大家去学习 BASE 理论。

CAP 理论本身所描述的是：在分布式系统中，因为网络分区是无法避免的，因此只能在 CP 及 AP 之间做抉择。

最简单的理解方式： 假设两个节点 A 和 B , A 负责写入数据，B 负责同步数据，此时 A 和 B 之间的网络无法通信，如果 A 继续写入，那么必然会导致 A 和 B 之间的数据是不一致的，如果要保持 A 和 B 数据的一致，那么则要让 A 无法写入。

对于 CAP 理论而言，忽略了 A 和 B 之间通信延迟，认为在网络通信正常的情况下，A 和 B 一定是一致的，其次 CAP 理论仅考虑了网络分区的故障。

相信很多人在学习分布式理论的时候都接触到 CAP 以及网上搜过大量关于 CAP 的资料，对于 CAP 理论的介绍，很多都是基于概念上的，就给众多人造成一种错觉：一个分布式系统要么是 CP、要么是 AP，因此很多人对 Zookeeper 打上一个 CP 模型系统的标签。如果生搬硬套 CAP 理论，在深入理解一个分布式系统的时候会给你造成很多困惑，这种困惑的存在，个人觉得根源还是在一致性理解。