从分布式系统的设计理念说起

分布式系统的首要目标是提升系统的整体性能和吞吐量。如果最终设计出来的分布式系统占用了 10 台机器才勉强达到单机系统的两倍性能，那么这个分布式系统还有存在的价值吗？另外，即使采用了分布式架构，也仍然需要尽力提升单机上的程序性能，使得整体性能达到最高。所以，我们仍然需要掌握高性能单机程序的设计和编程技巧，例如多线程并发编程、多进程高性能 IPC 通信、高性能的网络框架等。

另外，任何分布式系统都存在让人无法回避的风险和严重问题，即系统发生故障的概率大大增加：小到一台服务器的硬盘发生故障或宕机、一根网线坏掉，大到一台交换机甚至几十台服务器一起停机。分布式系统下故障概率的增加，除了受到网络通信天生的不可靠性及物理上分布部署的影响，还受到 X86 服务器品质等的影响。

所以，分布式系统设计的两大关键目标是性能与容错性，而这两个目标的实现恰恰是很棘手的，而且相互羁绊！举个例子，我们要设计一个分布式存储系统，出于对性能的考虑，在写文件时要先写一个副本到某台机器上并立即返回，然后异步发起多副本的复制过程，这种设计的性能最好，但存在「容错性」的风险，即在文件写完后，目标机器立即发生故障，导致文件丢失！如果同时写多个副本，在每个副本都成功以后再返回，则又导致「性能」下降，因为该过程取决于最慢的那台机器的性能。

由于性能指标是绝对的，而容错性指标是相对的，而且实际上对于不同的数据与业务，我们要求的容错性可以存在很大的差异，比如允许意外丢失一些日志类的数据；允许一些信息类的数据暂时不一致但最终达到一致；对交易类的数据要求有很高的可靠性。所以我们会发现，很多分布式系统的设计都提供了多种容错性策略，以适应不同的业务场景，我们在学习和设计分布式系统的过程中也需要注意这一特性。

下面继续谈谈分布式系统设计中的两大思路：中心化和去中心化。

在分布式架构设计里，中心化始终是一个主流设计。中心化的设计思想很简单，分布式集群中的节点器按照角色分工，大体上分为两种角色：Leader 和 Worker。Leader 通常负责分发任务并监督 Worker，让 Worker 一直在执行任务；如果 Leader 发现某个 Worker 因意外状况不能正常执行任务，则将该 Worker 从 Worker 队列去除，并将其任务分给其他 Worker。基于容器技术的微服务架构 Kubernetes 就恰好采用了这一设计思路。在分布式中心化的设计思路中，还有一种设计思路与编程中敏捷开发的思路类似，即充分相信每个 Worker，Leader 只负责任务的生成而不再指派任务，由每个 Worker 自发领任务，从而避免让个别 Worker 执行的任务过多，并鼓励能者多劳。

中心化设计存在的最大问题是 Leader 的安全问题，如果 Leader 出了问题，则整个集群崩溃。但我们难以同时安排两个 Leader 以避免单点问题。为了解决这个问题，大多数中心化系统都采用了主备两个 Leader 的设计方案，可以是热备或者冷备，也可以是自动切换或者手动切换，而且越来越多的新系统都具备了自动选举切换 Leader 的能力，以提升系统的可用性。中心化设计还存在另外一个潜在的问题，即 Leader 的能力问题，如果系统设计和实现得不好，问题就会卡在 Leader 身上。

下面一起探讨去中心化设计。

在去中心化设计里通常不区分 Leader 和 Worker 这两种角色。全球互联网就是一个典型的去中心化的分布式系统，联网的任意节点设备宕机，都只会影响很小范围的功能。去中心化设计的核心是在整个分布式系统中不存在一个区别于其他节点的 Leader，因此不存在单点故障问题，但由于不存在 Leader，所以每个节点都需要与其他（所有）节点对话才能获取必要的集群信息，而分布式系统通信的不可靠性大大增加了上述功能的实现难度。

去中心化设计中最难解决的一个问题是「脑裂」问题，这种情况的发生概率很低，但影响很大。脑裂指一个集群由于网络的故障，被分为至少两个彼此无法通信的单独集群，此时如果两个集群各自工作，则可能会产生严重的数据冲突和错误。一般的设计思路是，当集群判断发生了脑裂问题时，规模较小的集群就「自杀」或者拒绝服务。

实际上，完全意义的真正去中心化的分布式系统并不多见。相反，在外部看来去中心化但工作机制采用了中心化设计思想的分布式系统不断出现。在这种架构下，集群中的 Leader 是被动态选择出来的，而不是人为预先指定的，而且在集群发生故障的情况下，集群的成员会自发地举行「会议」选举新的 Leader 主持工作。最典型的案例就是 ZooKeeper 及用 Go 实现的 Etcd。

参考：从分布式到微服务

从分布式系统的设计理念说起相关推荐

QCon演讲速递：异步处理在分布式系统中的优化作用
本文根据阿里巴巴技术保障研究员赵海平在2015年QCon全球软件开发大会(北京站)主题演讲整理而成. \\ 赵海平在Facebook工作8年期间,主要针对后端进行性能优化的工作,包括PHP的优化,me ...
异步处理在分布式系统中的优化作用
本文根据阿里巴巴技术保障研究员赵海平在2015年QCon全球软件开发大会(北京站)主题演讲整理而成. 赵海平在Facebook工作8年期间,主要针对后端进行性能优化的工作,包括PHP的优化,memca ...
骂战之后，天才王垠或将加入华为，赵海平怒离职，加入字节跳动！
作者| Mr.K 来源| 技术领导力(ID:jishulingdaoli) 还记得去年那场著名的骂战吗?网红王垠受邀面试阿里P9岗位,被p10赵海平面试,王垠面挂后网上发文吐槽自己遭遇了不公面试, ...
创建可扩展性系统-4
高可扩展性系统的一些理论基础在2000年ACM的PODC座谈会上加州大学伯克利教授 Eric Brewer在主题"建立可靠的分布式系统"的演讲中提出了所谓的CAP定律,至今被大型 ...
大厂十年：我的三段职业经历和八条建议！
我(作者大飞哥)2009年本科毕业,毕业第一年进入QQ后台,从事分布式系统的开发. 那年,我完成了一个学生到职业人士的蜕变,也完成了学生式技术思维到职业式技术思维的转变. 毕业入职后,参与的第一个项目 ...
rabbitmq实战指南_太香了这份架构解密：从分布式到微服务（第二版），神仙进阶指南...
有这样一本神奇的架构书读者可以在字里行间见证微服务的发展脉络大到分布式.微服务.云原生.K8s.Service Mesh小到网络.分布式系统.RPC.分布式存储.分布式计算.全文检索与消息队列中间件等 ...
jdbc取款怎样限制条件_京东张亮：我们是怎样打造一款分布式数据库的
我们是怎样打造一款分布式数据库的作者 | 张亮关系型数据库在过去数十年的数据库领域一直占据着绝对主导的地位,它所带来的稳定性.安全性和易用性,成为了构建现代化系统的基石.随着的互联网高速发展,构架 ...
绝世巨作，阿里架构师著作的《架构解密：从分布式到微服务》来了
前言一.什么是架构把一个整体(完成人类生存的所有工作)切分成不同的部分(分工),由不同角色来完成这些分工,并通过建立不同部分相互沟通的机制,使得这些部分能够有机的结合为一个整体,并完成这个整体所需 ...
Redis（四）集群-AKF、CAP
AKF原理 AKF(X-Y-Z) 1.X轴:主从复制的全量同步解决了单点故障问题,也就是AKF理论中的X轴. 2.Y轴:按照不同的业务使用不同的redis服务.订单.用户.支付等都使用不同的服务.也就 ...

从分布式系统的设计理念说起

从分布式系统的设计理念说起相关推荐

最新文章

热门文章