zookeeper 入门系列 : 分布式事务
zookeeper实际上是yahoo开发的，用于分布式中一致性处理的框架。最初其作为研发Hadoop时的副产品。由于分布式系统中一致性处理较为困难，其他的分布式系统没有必要 费劲重复造轮子，故随后的分布式系统中大量应用了zookeeper，以至于zookeeper成为了各种分布式系统的基础组件，其地位之重要，可想而知。著名的hadoop、kafka、dubbo 都是基于zookeeper而构建。
如何保证在分布式环境下数据的最终一致，这个就是zookeeper需要解决的问题。对于这些问题，有哪些挑战，zookeeper又是如何解决这些挑战的，下一篇文章将会主要涉及这个主题。
一些常见的解决一致性问题的方式：
查询重试补偿。对于分布式应用中不确定的情况，先使用查询接口查询到当前状态，如果当前状态不一致则采用补偿接口对状态进行重试推进，或者回滚接口对业务做回滚。典型的场景如银行跟支付宝之间的交互。支付宝发送一个转账请求到银行，如一直未收到响应，则可以通过银行的查询接口查询该笔交易的状态，如该笔交易对方未收到，则采取补偿的模式进行推送。
定时任务推送。对于上面的情况，有可能一次推送搞不定，于是需要2次，3次推送。不要怀疑，支付宝内最初掉单率很高，全靠后续不断的定时任务推送增加成功率。
TCC。try-confirm-cancel。实际上是两阶段协议，第二阶段的可以实现提交操作或是逆操作。
zookeeper到底能做什么？
在业界的实际应用是什么？了解这些应用，会对zookeeper能够做的事有更直观的认识。
在业界的实际应用是什么？了解这些应用，会对zookeeper能够做的事有更直观的认识。
hadoop
鼻祖级应用，ResourceManager在整个hadoop中算是单点，为了实现其高可用，分为主备ResourceManager，zookeeper在其中管理整个ResourceManager。
可以想象，主备ResourceManager最初是主RM提供服务，如果一切安好，则zookeeper无用武之地。然而，总归会出现主RM提供不了服务的情况。于是会出现主备切换的情况，而zookeeper正是为主备切换保驾护航。
先来推理一下，主备切换会出现什么问题。传统的主备切换，可以让主备之间维持心跳连接，一旦备机发现主机心跳检测不到了，则自己切换为主机，原来的主机等待救援。这种方式有两个问题，一是由于网络抖动，负载过大等问题，备机检测不到心跳并不能说明主机一定挂了，有可能一定时间后主机或网络恢复，这时候主机并不知道备机已经切换为主机，2台主机互相争用，可能造成脑裂；二是如果一些数据集中在主机上面，则备机切换时由于同步延时势必会损失掉一部分的数据。
如何解决这些问题？早期的方式提供了不少解决方案，比如备机一旦切换为主机，则通过电源控制直接切断主机电源，简单粗暴，但是此刻备机已经是单点，如果主机是因为量撑不住而挂，那备机有可能会重蹈覆辙，最终导致整个服务不可用。
