一、为什么需要集群
马果果病了
马果果毕竟年纪大了，这办事处的事情越来越多，终于有一天扛不住，生病了，住院了，听医生说要休息好几天。办事处负责人不在的话就不能给村民们提供服务了。大家平时也要注意身体啊～
一连好几天都没收到通知的坤坤急死了，还有其他非常依赖办事处的村民们都一起跑去村委会投诉了，村委会也很无奈啊，最终商量了下，决定请村里威望同样很高的著名企业家，太极爱好者并且还是村里首富的马小云成立第二办事处，地点离原来的办事处也很近，同样负责处理之前马果果办事处的事务。马小云之前也是办事处的常客，对其中的流程已经是非常清楚了，一直想为人民做实事的他，欣然答应了下来。
而且已经有了之前的成功经验，所以直接照搬之前的处理流程就行了。但是细心的村民很快就发现了问题，之前在马果果的办事处很多已经记录过的事务，现在都消失了，在新的办事处这里需要重新登记，非常不方便，但是马小云表示也没办法，马果果病得太突然了，还没交接过，只能表示让大家忍忍。
就这样，过了两周，马果果痊愈出院了，在住院期间他也已经得知了马小云这两周代他帮助村民解决大小事务，他内心非常感激马小云所做的一切，热爱工作的他，第一时间就回到了工作岗位，把办事处的大门重新打开，也广播告诉了村民，自己这里又能办理事务了，希望大家可以继续过来。由于马小云毕竟业务能力稍差点，处理速度没那么快，导致第二办事处排队更严重了。
听到第一办事处又开张的村民们非常高兴，毕竟谁也不希望排长队浪费时间，于是都来到了第一办事处
但是呢，马果果休息了两周，这两周期间村民的登记的事务，他全部都没有，村民们纷纷表示这不行啊：我们不管你们有几个办事处，你们得保证数据都是一致的啊!。村委会也同意村民的诉求，勒令两个办事处整改，需要解决这个问题!而且因为马果果资历更老，更有经验，所以让马小云一切听马果果的指挥，方案也由马果果去想办法出台。
1.2 马果果的新规定
马果果不愧姜还是老的辣，很快就想出了一个好办法，出台了一系列的规则：
数据必须以马果果为主 两个办事处间需要打通联系，随时保持沟通 之前把村民前来登记的事务区分成读和写，是非常正确的决定。之后写操作必须通过马果果，读操作马小云可以自行解决
马果果把自己办公室的布置重新调整了下变成了这样：
简单介绍下新来的同事们：
小PS负责区分村民的请求是否需要发起提案，并把请求再次转发给小C以及小S 小C负责管理小PS提案的提交工作，这个职位非常重要，所以马果果很有私心的请了一个妹子来承担这个职位 现在的小S不再和小F打交道了而是和小A打交道，等他归档完后就会通知小A 因为现在有两个办事处了，所以需要聘请一个话务员，专门负责和隔壁的马小云办事处进行沟通
和马果果不太一样，这里也简单介绍下：
使用小FR替换了原来的小P作为办事处第一接待人 小S也不和小F打交道了，直接和小SA打交道，等他归档完就会通知小SA 和马果果一样也聘请了一个话务员负责和马果果进行联系
原来只有马果果负责的一个办事处，随着马果果的病倒，村民的业务就无法继续展开了，这就是单点故障，所以在原来的基础上增加一个办事处，可以增加整个办事处的吞吐量的同时也可以在一个办事处无法提供服务时，不至于导致村民们无法使用，这就是高可用。这也是为什么需要集群部署的最重要原因!
二、第一办事处
引入了集群前，原本一个节点数据自己内部运作管理就行，非常方便，但是引入集群后，集群间的节点如何沟通成了问题，让我们一起来看看马果果的新员工们是怎么做的吧?
不同于之前的单机流程，现在流程复杂了很多，增加了很多出场的人物，为了让大家能快速记忆，我这里提前把名字的由来剧透给大家：
小P对应代码中的 PReprequestProceSSoR 负责预处理 小PS对应代码中的 ProposalrequestProceSSoR 负责写事务的提案 小C对应代码中的 CoMMITProceSSoR 负责对事务请求提交 小S对应代码中的 SyncrequestProceSSoR 负责数据的归档 小A对应代码中的 AckrequestProceSSoR 负责告诉马果果当前事务的 ACK 信息 小F对应代码中的 FinalrequestProceSSoR 负责对内存模型的操作
2.1 负责的小PS
原先小P在第一时间询问村民后，并对当次请求进行标记后，就会把该请求转发给小PS，小PS做的事情也很简单：
主要就是看是不是写请求，如果是的话就要发起提案并且本地要通知小S归档。
2.2 忙碌的小C
小C是除了小F最忙碌的人了，她在接受到上一个同事传递过来的请求后会：
不是说小C是最忙的吗?就这?
别急，小C的处理过程的确是比较繁琐，但是我这里先给出简单的流程，最重要的提交操作，我暂时不展开，之后会讲～
2.3 小S和小A
小S处理的流程发生了改变，他前面的同事不再是小P，而他处理完归档后也不再把请求交给小F而是交给小A，而小A做的事情更简单，仅仅只是告诉马果果办事处此次事务请求归档成功，其实就是 ACK。
2.4 话务员
为了更顺畅的和隔壁的马小云办事处相互沟通，马果果定下了几个暗号，而话务员则负责用暗号去通知马小云
request ProPOSAL ACK COMMIT
当然暗号不止这些，之后有遇到再说。
在具体展开流程细节前，我觉得还是要把马小云的流程简单介绍下，等两边都介绍完后，再合并在一起讲解～
三、第二办事处
同样因为现在有两个办事处的关系，马小云也无法单纯使用之前的流程，并且新员工中有明显区别于马果果的小FR和小SA，这里也介绍下：
小FR对应代码中的 FolloweRrequestProceSSoR 负责马小云这边的预处理 小SA对应代码中的 SendAckrequestProceSSoR 和马果果的小A类似，通过话务员通知马果果当前事务的 ACK
3.1 同样细心的小FR和小SA
和小PS有点类似，也是需要区分读写，但区别是写请求需要通知马果果。
小SA的逻辑是接受到小S的归档信息后，把 ACK 通知给马果果，太简单了就不画图了。
四、实战
刚刚我们把两个办事处逻辑都大致介绍了下，但是太过于碎片化了和简单，所以下面开始进入实战环节，会分别假定不同的业务场景和复杂程度，从简单到复杂，把从村民来办事处登记事务到办事处处理完成之间的逻辑按照时间顺序进行整理。
前排提醒，多图预警
4.1 一个读请求(马果果)
假设我们的坤坤来到马果果的办事处，想要查询鸡太美最新的跳舞视频
小P首先知道坤坤是合法的村民，然后询问得知，此次来办事处的目的是为了查询，就会把此次登记标记为读请求，就把坤坤的请求交给下一个柜台的小PS。
小PS拿到请求后，先把请求原封不动的给到了小C，之后通过小P的标记知道了这是一个读请求，便不做其他处理。
小C取到这个请求后也发现这是一个读请求，所以也直接交给了小F，自己不需要其他处理。
小F拿出了小红本查看，假设存在，把对应的数据就返回给了坤坤。
坤坤拿到了结果心满意足的回去了并且定好了 17 点的闹钟守在电脑前等着鸡太美的开播了
