大型分布式服务器那些复杂原理和设计思路大概说说

说到大型分布式服务器,你可以把它想象成不是一台超级电脑在干活，而是成千上万台普通的电脑（我们叫它们服务器节点）手拉手连在一起，共同完成一个巨大的任务，比如淘宝双十一的抢购、微信上亿人同时发消息、或者百度一下搜出结果，背后都是这套东西在支撑，它的核心设计思路，其实就是解决“人多力量大”时带来的各种麻烦事。

第一，为啥要分布式？因为一台机器根本扛不住。 （来源：基于可扩展性需求的基本共识） 想象一下，如果全中国只有一家银行的一个柜台办理业务，那队伍得排到哪儿去？系统非得崩溃不可，分布式就是开无数家分行和无数个柜台，把客户分流，在服务器世界里，这就是“负载均衡”，会有专门的调度员（负载均衡器），像银行大堂经理一样，把来的请求（比如你的搜索指令）智能地分给后面闲着的那台服务器去处理，这样，没有单台服务器的压力会太大，整个系统就能承受海量的用户访问。

第二，数据存哪里？不能把所有鸡蛋放一个篮子里。 （来源：基于数据持久性与可靠性的设计原则） 数据是最宝贵的，如果所有用户的数据只存在一台机器的硬盘上，那这台机器一旦硬盘坏了，或者着火了，数据就全丢了，分布式系统会把一份数据，复制成好几个副本，然后分散存到不同的机器上，甚至不同的城市的数据中心里，这叫“数据冗余”或“副本机制”，比如你的微信聊天记录，其实在公司后台可能同时存了三份，这样哪怕坏了一两台机器，你的记录也还在，但这就带来了新问题：如何保证这三份数据是一模一样的？如果同时有两个人修改同一份数据，听谁的？这就要用到“一致性协议”，比如Paxos或Raft，你可以理解为这几台存数据的机器之间有个投票机制，任何修改必须得到大多数机器的同意才能生效，确保大家步调一致。

第三，怎么保证挂了也不影响服务？得有个备胎计划。 （来源：基于高可用性与容错性的核心目标） 机器是会出故障的，这是必然的，分布式系统的设计思路是，假定任何部件随时都可能坏掉，所以系统要有“容错”能力，关键服务不能只部署在一台机器上，而是要有“主备”模式或多活模式，一台主服务器在干活，另外一台或多台备用服务器时刻同步着主服务器的数据，一旦检测到主服务器宕机了，备用服务器能在几十毫秒内自动顶上去，用户几乎感觉不到中断，这就叫“高可用”，为了实现这个，系统中需要有“心跳检测”机制，就像伙伴之间不停地互相喊“我还活着”，一旦听不到回应，就知道对方可能出事了，要启动应急预案。

第四，服务器之间怎么通信？不能说方言，得说普通话。 （来源：基于服务间通信的通用实践） 这么多台机器要协同工作，它们之间必须频繁地通信，处理你下单请求的服务器，需要调用用户信息服务器来验证你的身份，调用库存服务器检查有没有货，调用支付服务器完成扣款，它们之间通过网络传递消息，这里的设计关键是通信协议要高效、可靠，常用的方式有RPC（远程过程调用），你可以理解为一种标准化的“工作联络单”，让一台服务器能像调用自己内部函数一样，轻松调用另一台遥远服务器上的功能，而不用关心网络传输的复杂细节。

第五，当业务增长时，如何平滑地加机器？ （来源：基于弹性伸缩的系统架构思想） 公司业务在发展，用户量在暴增，原来的服务器不够用了怎么办？分布式系统要支持“可扩展”，理想情况是，能够像搭积木一样，简单地增加服务器就能提升整体处理能力，但这里有个难题：新加的机器怎么融入集体？数据如何重新分布？这就涉及到“分片”技术，可以把全国用户按地区“分片”，北方用户的数据存在北京的机器集群，南方用户的数据存在深圳的机器集群，当用户增多时，可以给每个片区单独增加机器，或者把大的片区分割成更小的片区，一个好的分片策略要尽量让数据和请求均匀分布，避免出现某些机器累死、某些机器闲死的情况。

大型分布式服务器的设计思路，核心就是：

• 拆解： 把大应用拆成小服务，把大数据拆成小片段。
• 冗余： 关键部件和服务都有备份，消除单点故障。
• 调度： 智能地分配任务和流量，让系统负载均衡。
• 协同： 通过可靠的通信和一致性协议，让所有节点步调一致。
• 容错： 假定故障会发生，并设计系统能自动应对和恢复。

所有这些复杂的设计,最终目标就是为了让你在使用淘宝、微信、百度时，感觉像是在用一台无比强大、永远在线的超级电脑，而完全感知不到背后是无数台普通机器在协同作战的复杂与艰辛。