zookeeper到底是什么？
zookeeper实际上是yahoo开发的，用于分布式中一致性处理的框架。最初其作为研发hadoop时的副产品。由于分布式系统中一致性处理较为困难，其他的分布式系统没有必要 费劲重复造轮子，故随后的分布式系统中大量应用了zookeeper，以至于zookeeper成为了各种分布式系统的基础组件，其地位之重要，可想而知。著名的hadoop，kafka，dubbo 都是基于zookeeper而构建。
要想理解zookeeper到底是做啥的，那首先得理解清楚，什么是一致性。
所谓的一致性，实际上就是围绕着“看见”来的。谁能看见？能否看见？什么时候看见？举个例子：淘宝后台卖家，在后台上架一件大促的商品，通过服务器A提交到主数据库，假设刚提交后立马就有用户去通过应用服务器B去从数据库查询该商品，就会出现一个现象，卖家已经更新成功了，然而买家却看不到；而经过一段时间后，主数据库的数据同步到了从数据库，买家就能查到了。
假设卖家更新成功之后买家立马就能看到卖家的更新，则称为强一致性；
如果卖家更新成功后买家不能看到卖家更新的内容，则称为弱一致性；
而卖家更新成功后，买家经过一段时间最终能看到卖家的更新，则称为最终一致性。
分布式事务处理模式
一般分布式事务处理模式包括：2阶段提交、3阶段提交、TCC（Try-Confirm-Cancel）、可靠消息（消息队列、数据库表）、SAGAS长事务、补偿性事务。具体采用哪一种分布式事务处理模式，需要根据自己业务场景来选择合适的机制。
duboo、spring cloud都可以算作是SOA框架，分布式事务控制支持依赖其他组件，例如通过JTA（2阶段、3阶段）、ActiveMQ消息中间件、ByteTCC（TCC）等。
zookeeper、redis可以支持分布式锁，分布式锁是分布式事务的核心，但分布式锁不等同于分布式事务。
redis对分布式锁的支持主要通过setnx，在使用redis分布式锁时候，一定要注意处理加锁客户端异常导致锁资源没有正常释放的情况（例如调用端down掉），在调用setnx时候需要加上对锁超时时间的判断。
zookeeper对分布式锁的支持可以直接使用zookeeper curator-recipes客户端。
具体的分布式事务处理
目前解决的办法有基于XA的2pc两阶段提交，实际上就是整个事务过程由事务管理器和资源管理器来共同参与。这么一说可能题主就明白了这是位于资源层面的解决方案，说白了就是你的数据库或者MQ要支持两阶段提交协议，由于在整个事务过程中会一直锁定资源，而且涉及到网络操作，那这个东西就不太可靠，而且会影响性能，扩展性和可用性都不友好，同时对于服务层面的分布式它是搞定不定的。所以后面又搞出来个tcc，这个类似2pc，只是它是位于业务层面，基本的思路是把比较长的分布式事务拆分成本地的短事务。这需要结合业务的特点去设计，比如买10块钱的东西，针对支付这个服务，在进行扣费的时候先有个冻结用户10块钱的动作，这个就是try。等到后面tcc框架发起confirm操作时才真正把10块钱扣掉，如果tcc框架发起cancel操作则把10块钱解冻。需要注意的是由于confirm和cancel可能失败，因此可以结合全局事务ID设计成幂等性的接口。
上面两种从某种程度上来讲都能提供比较强的一致性，但是有很多场景是不需要这种强一致性的。根据CAP（一致性、可用性、可靠性）的理论，鱼和熊掌不可兼得，可靠性是必须要的，所以需要在C和A之间做平衡，实际上在互联网领域Ａ也是必须的，因此就不得不在Ｃ上做文章。于是有了弱一致或者最终一致，它不要求你在做完一个操作后能立马看到效果，只要在可接受的时间内看到正确的结果即可。这方面的内容epay的架构师有过介绍，目前业界用这种的比较多，Sina Visitor System 这篇文章讲解的比较详细。其解决分布式事务的思路就是避免分布式事务，具体来说就是利用本地事务+异步消息+重试+幂等去保证整个系统数据的最终一致性。