前言
在一年前我曾经有做过一些Zkeeper的相关总结，现在我们再把它捡回来，重新的把一些前因后果都扯得更加明白。
一、分布式系统与Zkeeper的关系
1.1集中式服务
我们先从服务部署架构的发展历程说起，其实无非就是集中式和分布式，集中式就是说，什么我都是由一台机器搞定的。分布式就是多台服务器联合完成。所以在一开始的时候一般都是从一台服务器开始，将我们的服务部署上去，然后就是一些老套路，Web应用就部署在Tt上开放8080端口提供服务，然后它需要的一个数据库服务就开放3306端口提供。它的优点就在于结构，部署，项目架构都比较简单。
然后再根据业务的发展去扩展，那扩展同样也可以分为两种方式，一种是横向扩展，一种为纵向扩展。既然一台搞不定，那就要不提升这个服务器的性能，要不就整多几台一起上。但是我们想想，也不是个人就会把服务器安排的服服帖帖的呀，这台机子一挂，那就全挂了。而且大型主机的购买，还有研发，维护人才，那都是得花大价钱的。这里给大家扩展一个“摩尔定律”
反正简单点来说，就是我花两倍的钱，根本买不到两倍的性能。但是横向扩展就不一样了，一个人打不过，叫多几个人一起打不就行了?
1.2去IOE运动
阿里巴巴搞出来的一个口号，具体点就是IBM小型机，Ole数据库，EMC的高端存储，有兴趣的也可以了解一下。因为当时面临的问题是，企业如果需要提升单机处理能力，成本会很高且性价比极低。还整天怕这怕那的，一宕机就整个服务停掉。慢慢的国内很多公司跟着一起响应，分布式就起来了。
1.3分布式服务
分布式系统有着它具体的定义：分布式系统是一个硬件或者软件组件分布在不同的网络计算机上，彼此之间仅通过消息传递进行通信和协调的系统。所以就是一堆计算机联合起来对外提供服务，但是对于用户来说，像是一台机子在完成这事。
特点很多，大致就是下面5个：分布：这个就是多台计算机都被放置在了不同的位置对等：集群中的多个工作节点都是一个货色，干的都一样的活儿。而且存在副本概念并发：多个机器同时操作一份数据可能会引发的数据不一致问题全局时钟：多个主机上的事件先后顺序会对结果产生影响，这也是分布式场景中非常复杂的一个问题各种故障：某节点宕机，网络不好···突发情况
1.4分布式场景中经常遇到的几个问题通信异常：其实就是网络问题，导致多节点状态下数据不一致网络孤立：这个其实就是各个子网络内部正常，但是整个系统的网络是不正常的。导致局部数据不一致的问题
节点宕机问题分布式三态：成功，失败，超时这3种状态引出的各个问题。请求发送和结果响应都有可能丢失，无法确定消息是否发送/处理成功数据丢失：这个一般通过副本机制，从其它节点读取解决，或者对于有状态的节点来说丢失数据就可以通过恢复状态来解决。异常处理原则：任何在设计阶段考虑到的异常情况都必须假设一定会在实际运行中发生
1.5衡量分布式系统的性能标准性能：主要就是吞吐能力，响应延迟，并发能力。系统某一时间可以处理的数据总量，通常是用系统每秒处理的总数据量衡量，而响应延迟指的是完成某一功能所需要的的时间。并发能力就是同时完成某一功能的能力，通常就是用QPS衡量可用性：在面对各种异常时可以正确提供服务的能力。比如我们常说的5个9就是指一年内只有5分钟的宕机时间。6个9就是31秒可扩展性：指可以通过扩大机器规模达到提高系统性能的效果
一致性：副本管理
但是这些标准都是一个方面要求太高之后会带动另外一方面变差，比如说我们需要做到高可用，可能需要多个副本，但是多个副本的状态下，对于数据的一致性又很难去做到了。然后高吞吐下又很难做到低延迟，所以我们需要针对自己的业务场景去进行考量。
1.6对于一致性的扩展强一致性：写操作完成之后，读操作一定能读到最新数据，在分布式场景中这样是非常难实现的，比如Pxs算法，Qr机制，ZAB协议都是干这个事的。弱一致性：不承诺可以立即读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能的保证到某个时间级别(比如XX时，XX分，XX秒后)，数据可达到一致性状态。
它还有一个特例叫做最终一致性，就是尽可能快的保证数据的一致。但是这个快到底是多快，就没有准确定义了。好比女票想要吃到炸鸡，你给点了份外卖，可是美团骑手，饿了吗骑手也说不准什么时候送到，他只能说保证尽快送到。就这么个意思。
因为最终一致性实在是太弱了所以我们还有一些特例情况会出现读写一致性，它是指用户读取自己写入的结果永远可以第一时间看到自己更新的内容，这个就像微信朋友圈一样的，我们发出来的东西，微信是一定会让我们看到的，可是朋友们是不是你发了立刻就能看到，那可就说不准了。
还有一些单调读一致性，因果一致性就不展开说明了，有兴趣的小伙伴可以自行搜索。
总而言之，为了保证系统的高可用，防止单点故障引发的问题，并能够让分布在不同节点上的副本都能正常为用户提供服务，这时，我们的Zkeeper就应运而生了。它就能帮助我们解决这个分布式系统中数据一致性的问题
需要解决这个问题我们需要了解分布式事务，分布式一致性算法，Qr机制，CAP和BASE理论，接下来我们慢慢去展开
二、分布式事务
事务：单机存储系统中用来保证存储系统的数据状态一致性，这是不是读起来有点拗口，没事，我们换个说法，广义上的事务，就是指一个事情的所有操作，要不全部成功，要不全部失败，没有中间状态。狭义一点，那就是数据库做的那些操作。特征也很简单，就是耳熟能详的ACID。
分布式系统中每个节点都仅仅知道自己的操作是否成功，但是不知道其它节点是个啥情况，这就有可能导致各节点的状态可能是不一致的，所以为了实现跨越多节点且保证事务的ACID时，需要引入一个协调者，然后参与事务的各个节点都叫做参与者
典型的套路就是2PC和3PC，接下来我们慢慢展开
2.12PC是个什么东西
在事务的参与过程中会产生多个角色，暂时我们先这么理解，协调者负责事务的发起，而参与者负责执行事务。
假定存在上面的3个角色，分别是一个协调和两个参与，此时我们需要A，B执行一个事务，并且要求这个事务，要么同时成功，要么同时失败。
2PC阶段一：执行事务
此时协调者会先发出一个命令，要求参与者A，参与者B都都去执行这个事务，但是不提交
说的再详细一点，就会产生写red，nd的日志，锁定资源，执行事务。但是执行完了之后，直接向协调者打报告，询问一下，大哥我能提交吗?
这个在日常写Jv的过程中应该经常遇到，就是前面写了一大堆操作，但是等到最后一定会写一个()这样的东西，这就是所谓的执行但不提交
2PC阶段二：提交事务
当协调者收到第一阶段中的所有事务参与者(图中的A，B)的反馈(这个反馈简单理解为，告诉协调者前面的第一阶段执行成功了)时，就发送命令让所有参与者提交事务。
如果要说的再细一点，那就是协调者收到反馈，且所有参与者均响应可以提交，则通知参与者进行it，否则rllk
所以2PC也叫做二阶段提交，其实就是这么简单分成了两步，一步执行，一步提交。
2PC的4个缺点：性能
整个流程看下来就知道这明显产生了同步阻塞，各个需要操作数据库的节点都占用了数据库的资源。只有当协调者收到所有节点都准备完毕的反馈，事务协调者才会通知itrrllk，而参与者执行完这个itrrllk的操作后，才会去释放资源。
2PC的4个缺点：单点故障
那我们刚刚也知道了，协调者才是这个事务的核心。假如此时协调者故障宕机，会导致通知无法传达到参与者的问题，比如收不到那个itrrllk，整一个事务便会停滞。
2PC的4个缺点：数据不一致
协调者在第二阶段会发送itrrllk。可是这并不能保证每一个节点都正常收到这个命令，所以会可能窜在，参与者A收到了命令，提交了事务，但是参与者B没有。所以网络波动是永恒的病因，你永远无法躲开这个因素。
2PC的4个缺点：不存在容错机制
这个协调者需要收到所有的节点反馈准备完成才会下达it的指示，任意一个参与者的响应没有收到，协调者就会进行等待，而且只要存在一个宕机的节点，都会使得整个事务失败回滚。
2.23PC是个啥东西
在2PC的前提下进行了一个改良，将2PC中的准备阶段进行拆分，形成，，三个阶段。
并且引入超时机制，一旦事务参与者在指定时间内没有收到协调者的itrrllk指令，就会自动进行本地it，解决协调者的单点故障问题
3PC第一阶段
协调者先询问：哎你们这帮人到底能不能行?参与者就根据自身的实际情况回答yesrn。
3PC第二阶段
如果参与者都是返回同意，协调者则向所有参与者发送预提交请求，并进入准备阶段，这里的准备阶段其实就是让参与者锁定资源，等待指令的意思，然后就是事务的执行，此时也像2PC一样，执行但不提交。然后等待协调者的指令，此时如果迟迟等不到指令，一段时间后就会自行本地提交
但是这样也会存在弊端，比如协调者成功给1，2参与者都发送回滚，然后3刚好就没收到，那么3就自动提交了，所以超时机制其实并不能完全保证数据的一致性
三、分布式一致性算法
3.1Pxs算法
不知道大家有没有看到我上一年的那篇从零开始的高并发(三)---Zkeeper集群的搭建和leder选举如果需要详细了解，推荐跳转到那篇哦。
↑返回顶部↑