分布式系统的一些基础理论

前言

在一年前我曾经有做过一些 Zookeeper 的相关总结，现在我们再把它捡回来，重新的把一些前因后果都扯得更加明白。

一、分布式系统与 Zookeeper 的关系

1.1 集中式服务

我们先从服务部署架构的发展历程说起，其实无非就是 集中式 和 分布式 ，集中式就是说，什么我都是由一台机器搞定的。分布式就是多台服务器联合完成。所以在一开始的时候一般都是从一台服务器开始，将我们的服务部署上去，然后就是一些老套路，Web 应用就部署在 Tomcat 上开放 8080 端口提供服务，然后它需要的一个数据库服务就开放 3306 端口提供。它的优点就在于结构，部署，项目架构都比较简单。

然后再根据业务的发展去扩展，那扩展同样也可以分为两种方式，一种是横向扩展，一种为纵向扩展。既然一台搞不定，那就要不提升这个服务器的性能，要不就整多几台一起上。但是我们想想，也不是个人就会把服务器安排的服服帖帖的呀，这台机子一挂，那就全挂了。而且大型主机的购买，还有研发，维护人才，那都是得花大价钱的。这里给大家扩展一个 “摩尔定律”

反正简单点来说，就是我花两倍的钱，根本买不到两倍的性能。但是横向扩展就不一样了，一个人打不过，叫多几个人一起打不就行了？

1.2 去 IOE 运动

阿里巴巴搞出来的一个口号，具体点就是 IBM小型机，Oracle数据库，EMC的高端存储，有兴趣的也可以了解一下。因为当时面临的问题是，企业如果需要提升单机处理能力，成本会很高且性价比极低。还整天怕这怕那的，一宕机就整个服务停掉。慢慢的国内很多公司跟着一起响应，分布式就起来了。

1.3 分布式服务

分布式系统有着它具体的定义：分布式系统是一个硬件或者软件组件分布在不同的网络计算机上，彼此之间仅通过消息传递进行通信和协调的系统。所以就是一堆计算机联合起来对外提供服务，但是对于用户来说，像是一台机子在完成这事。

特点很多，大致就是下面5个：

1. 分布：这个就是多台计算机都被放置在了不同的位置
2. 对等：集群中的多个工作节点都是一个货色，干的都一样的活儿。而且存在副本概念
3. 并发：多个机器同时操作一份数据可能会引发的数据不一致问题
4. 全局时钟：多个主机上的事件先后顺序会对结果产生影响，这也是分布式场景中非常复杂的一个问题
5. 各种故障：某节点宕机，网络不好···突发情况

1.4 分布式场景中经常遇到的几个问题

1. 通信异常：其实就是网络问题，导致多节点状态下数据不一致
2. 网络孤立：这个其实就是各个子网络内部正常，但是整个系统的网络是不正常的。导致局部数据不一致的问题
3. 节点宕机问题
4. 分布式三态：成功，失败，超时这3种状态引出的各个问题。请求发送和结果响应都有可能丢失，无法确定消息是否发送/处理成功
5. 数据丢失：这个一般通过副本机制，从其它节点读取解决，或者对于有状态的节点来说丢失数据就可以通过恢复状态来解决。

异常处理原则：任何在设计阶段考虑到的异常情况都必须假设一定会在实际运行中发生

1.5 衡量分布式系统的性能标准

1. 性能：主要就是吞吐能力，响应延迟，并发能力。系统某一时间可以处理的数据总量，通常是用系统每秒处理的总数据量衡量，而响应延迟指的是完成某一功能所需要的的时间。并发能力就是同时完成某一功能的能力，通常就是用 QPS 衡量
2. 可用性：在面对各种异常时可以正确提供服务的能力。比如我们常说的 5个9 就是指一年内只有5分钟的宕机时间。6个9 就是 31 秒
3. 可扩展性：指可以通过扩大机器规模达到提高系统性能的效果
4. 一致性：副本管理

但是这些标准都是一个方面要求太高之后会带动另外一方面变差，比如说我们需要做到高可用，可能需要多个副本，但是多个副本的状态下，对于数据的一致性又很难去做到了。然后高吞吐下又很难做到低延迟，所以我们需要针对自己的业务场景去进行考量。

1.6 对于一致性的扩展

1. 强一致性：写操作完成之后，读操作一定能读到最新数据，在分布式场景中这样是非常难实现的，比如 Paxos算法，Quorum机制，ZAB协议都是干这个事的。
2. 弱一致性：不承诺可以立即读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能的保证到某个时间级别（比如XX时，XX分，XX秒后），数据可达到一致性状态。

它还有一个特例叫做最终一致性，就是尽可能快的保证数据的一致。但是这个快到底是多快，就没有准确定义了。好比女票想要吃到炸鸡，你给点了份外卖，可是美团骑手，饿了吗骑手也说不准什么时候送到，他只能说保证尽快送到。就这么个意思。

因为最终一致性实在是太弱了所以我们还有一些特例情况会出现读写一致性，它是指用户读取自己写入的结果永远可以第一时间看到自己更新的内容，这个就像微信朋友圈一样的，我们发出来的东西，微信是一定会让我们看到的，可是朋友们是不是你发了