随着互联网的不断发展，企业积累的数据越来越多。

当单台数据库难以存储海量数据时，人们便开始探索如何将这些数据分散地存储到多台服务器的多台数据库中，逐渐形成了分布式数据库。

如果将数据分散存储，对于数据的增删改查操作就会变得更加复杂，尤其是难以保证数据的一致性问题，这就涉及了常说的分布式事务。

OSCHINA特邀《深入理解分布式事务：原理与实战》作者 @ 冰河 和大家一起聊聊分布式事务相关的问题。在此，我们整理了活动中的十个问题，与大家分享。

嘉宾简介

冰河，互联网高级技术专家、MySQL技术专家、分布式事务架构专家。

多年来，一直致力于分布式系统架构、微服务、分布式数据库、分布式事务与大数据技术的研究，在高并发、高可用、高可扩展性、高可维护性和大数据等领域拥有丰富的架构经验。

可视化多数据源数据异构中间件mykit-data作者；《深入理解分布式事务：原理与实战》、《海量数据处理与大数据技术实战》和《MySQL技术大全：开发、优化与运维实战》作者；“冰河技术”微信公众号维护者。

2021年新作《深入理解分布式事务：原理与实战》从 基础知识、解决方案、原理分析、源码实现和工程实践 等5个维度全面、系统、深入的介绍了分布式事务。

更有来自京东、阿里、腾讯、蚂蚁金服、滴滴、饿了么、58集团、IBM等互联网大厂及Apache软件基金会的近20位专家高口碑力荐。

在当当预售第一天便开始持续霸榜当当新书榜 第1位 。

问题1：大佬，请教一下，分布式和Paxos之类容错是绑定的吗？如何解决容错的问题？

答： 这里是两个问题，首先来回答下第一个问题：分布式和Paxos之类容错是绑定的吗？ 我个人认为应该不算是绑定的吧，但是二者也是有联系的。分布式系统在架构设计时，要在数据一致性和系统可用性之间取得平衡。在分布式领域中，除了Paxos算法外，比较著名的算法还有Raft算法，Gossip算法，Zab算法等。分布式系统在不同的场景下，权衡数据一致性和系统可用性，可根据不同的算法实现系统的容错。

接下来，我们聊聊第二个问题：如何解决容错的问题？ 我个人认为数据容错可以分为数据的容错和分布式系统的容错。 Paxos在某种程度上可以分为：Basic Paxos 和 Multi Paxos，paxos将采用客户端自己保存票ticket，服务器只是保存已经发布的票。Paxos一致性算法存在如下一些条件：

1.一个Acceptor必须批准它收到的第一个提案（[编号，Value]）。

2.如果编号为M0、Value值为V0的提案被选定了，那么所有比编号M0更高的，且被选中的提案，其Value值必须也是V0.（简单来说：就是如果提案被选中，编号M必须最大。）

（1）如果编号为M0，Value值为V0的提案被选定了，那么所有比编号M0更高的，且被Acceptor批准的提案，其Value值必须也是V0。

（2）如果一个提案[M0，V0]被选定后，那么之后任何Proposer产生的编号更高的提案，其Value值都为V0。

由于Paxos算法的实现过于复杂，行业很少直接采用Paxos算法。使用的比较多的是Raft算法。Raft 是 Multi Paxos 的一种实现，是通过一切以领导者为准的方式，实现一系列值的共识，然而不是所有节点都能当选 Leader 领导者，Raft 算法对于 Leader 领导者的选举是有限制的，只有最全的日志节点才可以当选。

所以，在分布式系统中，我们可以通过Raft算法实现数据的一致性，达到系统容错的目的。 当然，Paxos算法和Raft算法都是强一致性算法，在强一致性下就需要牺牲系统的可用性了，如果需要在一定程度上保证系统的可用性，就需要采用Base理论作为支撑。此时可以采用Gossip协议实现。

Gossip 的协议原理有一种传播机制叫谣言传播，它是指一个节点有了新数据后，这个节点就变得活跃起来，并通过一定的周期向其他节点发送新数据，直到所有的节点都存储了这条新数据。这种方式达成的数据一致性是 “最终一致性”。

也就是说当数据被更新后，经过一定的时间，集群内各个节点所存储的数据最终会达成一致。 我们在分布式系统的建设过程中，是一个不断在数据一致性和系统可靠性之前取得平衡的一个过程。

其实所谓的谣言在实际的实现中，是我们自己封装的消息，对于同一条消息来说，往往在生产消息的地方就需要为每一条消息生成一个全局唯一的id，其他节点在处理消息时会同时将消息放到消息记录中。

问题2：在什么条件下适用于分布式部署？

答： 分布式部署的条件不是唯一的，有时是根据业务的需要决定的。例如：单机部署已无法满足业务的发展时，需要将业务进行拆分进行分布式部署。单机数据库无法满足数据的读写性能时，需要考虑将数据拆分后存储到部署在多台服务器上的数据库中。还有一种情况就是：系统明确要求必须具备高可用和良好的可靠性，此时，尽管系统在单机环境下未达到瓶颈，也是需要进行分布式部署来满足需求的。

问题3：在选择一些分布式数据库时，有哪些评价标准可以分享一下嘛？

答： 这些应该没有统一的标准，更多的是根据自己的业务场景，权衡数据一致性和系统的可用性，同时需要考虑可靠性和容错性，在分布式数据库中做权衡对比，最终选择一款最适合自己业务场景的数据库。总体来说，没有最好的分布式数据库，只有最适合自己业务场景的分布式数据库。

问题4：您好，请教一个问题，如果在代码中一系列操作，涉及到Java代码、mysql和redis等多个环节，是否有适合的分布式事务方案呢？还是说遇到类似情况，只能采用一些“补偿”的方法来处理。

答： 分布式事务的解决方案总体上可以分为强一致性方案和弱一致性方案，而弱一致性方案我们也可以称它为柔性事务。在互联网高并发大流量的业务场景下，我们很少直接采用强一致性方案，因为这种方案会极大的降低系统的性能。因此，更多的采用了柔性事务，在柔性事务中，只要经过一小段时间后，数据达到一致的状态即可。使用柔性事务时，不可避免的会由于各种因素导致数据状态的不一致，此时，就需要通过一定的方式对事务进行补偿。

如果事务涉及到Java代码、mysql和redis等多个环节，则不宜采用强一致性解决方案，更好的方案是采用柔性事务，而柔性事务需要我们采用一定的方式对事务进行补偿。

问题5：有没有什么技术方案是现阶段比较通用的解决办法呢？

答： 其实严格意义来说，没有任何一种方案是通用的，每种分布式事务的解决方案都有其适用的业务场景，正所谓没有最好的方案，只有最适合的方案。

问题6：大佬 如果项目中使用了比如RocketMQ的事务 如何监控事务性能呢 或者如果项目详情缓慢 如何定位问题？

答： 这些可以使用APM（应用性能管理）工具来排查和定位，比如，Zipkin，hydra、cat、open-falcon等，你可以了解下每个的使用，这些都是开源的。不过我们公司是根据具体场景自研的APM，后面我会分享一些这方面的文章。

问题7：分布式事务是只能管理数据库事务吗？ TCC 这种方式管理事务是不是比较复杂？

答： 其实在广义上讲，分布式事务不仅仅只能管理数据库事务，它可以涵盖各数据源之间的数据一致性，例如关系型数据库，分布式数据库，NoSQL数据库、Redis等。TCC这种方式管理事务对业务的侵入性比较大，需要将原本的业务逻辑拆分为Try-Cancel-Confirm三个部分，需要对原有业务代码进行改造。

问题8：您好，请问哪些场景下会产生分布式事务问题？ 另想咨询您RPC分布式补偿如何解决？

答： 总体来说会有三种场景：单应用多数据源、多应用单数据源、多应用多数据源。对于RPC分布式补偿的解决方案可以参考下Hmily，都是不错的实现方式，在高并发和大流量场景下得到了验证。《深入理解分布式事务：原理与实战》一书中对于具体的实现方式进行了详细的讲解。

问题9：你好，现在有什么开箱即用的解决方案么？我就知道一个阿里的Seata ，老师推荐Seata 么？

答： Seata是众多分布式事务解决方案中的一种，当然可以使用Seata，也可以使用Dromara社区的Hmily，Raincat和Myth，也可以使用基于RocketMQ的事务消息实现。

问题10：哪些场景下会产生分布式事务问题？分布式事务有哪些解决方案？现在知道好像只有 Seata， atomikos 它们有什么优缺点? 分别适用什么场景? 还有其它常用的分布式解决方案吗？

答： 有些框架不只是实现了一种分布式事务的解决方案，比如Seata就支持2pc，tcc, at等模式，每一种模式最佳的适用场景都不同。另外，实现2pc的还有Raincat，实现tcc的还有hmily，当然，hmily也支持tac模式，实现可靠消息方案可以基于rocketmq实现，也可以利用myth框架实现。大部分问题都可以在《深入理解分布式事务：原理与实战》一书中找到详细的答案。

购买链接：https://item.jd.com/12972343.html