分布式事务一致性解决方案 如何使用消息队列解决分布式事务？
如何使用消息队列解决分布式事务？
有两种选择。
Scheme 1 Local message transaction table
生产者需要添加一个事务消息表。具体步骤如下：[1。生产者执行业务逻辑并将事务记录插入到消息表中。这两个操作在一个本地事务中
2。启动后台线程定期轮询消息表并将消息发送到消息队列
3。删除消息表中的消息，直到发送成功。
方案2需要消息队列支持，业务端提供回溯接口
1。生产端将准备好的消息发送到消息队列
2。在本地事务中，业务逻辑
3。根据执行结果确认或取消准备好的消息
4。消息队列将确保准备好的消息被确认或取消，并且消息队列将不断地向生产端请求执行结果，这要求生产端提供类似的回调函数。
在方案2中，消息队列取代了方案1中的消息表和后台线程轮询功能，但并非所有消息队列都支持此功能。支持Rocketmq。
方案1的开发工作量大，外部依赖性小
方案2的开发工作量小，但依赖于特定的消息队列。
微服务调用为啥用RPC框架，http不更简单吗？
简单一点，HTTP是协议，RPC是概念！RPC可以基于HTTP协议（feign）、TCP协议（netty）、RMI协议（soap）和web服务（XML-RPC）框架实现。在传输过程中，由于序列化方法的不同，也出现了一些框架和协议，如Dubbo中的Dubbo协议、grpc protobuf序列化协议等。实际上，它们都是基于远程调用的概念。什么是远程呼叫？
关键是RPC是远程调用。远程调用是客户端通过上述协议向服务器发送接口、参数、参数类型、方法、返回值、返回值类型等（称为方法签名），通知服务器要调用的接口方法。这个过程就是RPC的实现过程！HTTP和RPC是两码事
！在性能方面，HTTP本身是基于TCP协议的，属于应用层协议，所以HTTP协议本身在实现过程中会占用大量的资源（内存、带宽等）。在性能方面，它肯定不如直接通过TCP实现的RPC协议快。不管HTTP有多优化，它绝对没有TCP那么快！另一方面，TCP依赖于字节码。目前常用的是将客户端调用的接口信息以序列化的方式发送到服务器端。序列化框架包括许多内容（Hession、protobuf、kryo等）。Kryo具有最高的序列化性能，protobuf具有序列化后最小的字节码）。序列化后的字节码越小，占用的带宽越小，序列化时间越长，线程IO延迟越短，线程IO延迟越小。因此，在具体的应用层，有很多技术可以讨论。您可以根据自己的硬件能力选择相应的技术
！欢迎热爱科技的人们来探索
面一个5年java，不知数据结构，却大谈分布式，这样的能要吗？
我猜您向人们询问了各种JDK数据结构的基本实现原则。事实上，我一直在想。知道基本的实现原则是可以的，也是值得的，但是如果你不知道呢？人们知道哪些数据结构适用于哪些场景，并且能够熟练地使用它们。那不是。。。够了吗？对贵公司的需求不足吗？你希望他为你的公司创建一个新的数据结构吗？就像two peas或JDK一样，JDK的数据结构性能遇到了瓶颈，求职者会给你提供比工作提供的数据结构更好的数据结构。
传统事务为什么解决不了分布式事务？
其根本原因是传统事务只能解决单个事务资源的问题，而分布式事务则考虑了多个事务资源的问题。这两种场景是不同的，传统的事务无法解决分布式事务的问题。
1. 传统的事务通常指数据库事务，事务资源的强一致性保证了事务的一致性。在传统的单一应用中，由于事务资源在同一个应用中，无法跨多个事务资源调用，因此可以高效工作；
，只需要保证数据的“最终一致性”，但最终时间需要在用户可接受的范围内；但在金融关联交易领域，仍然需要采用强一致性的方法来保证交易的准确性和可靠性。
3. 目前，分布式事务常用的解决方案有：两阶段提交、三阶段提交、sagas长事务、补偿模式、可靠事件模式（本地事件表、外部事件表）、可靠事件模式（非事务消息、事务消息），TCC等
不同实现的优缺点如下图所示：
科普知识@大象聊天技术
分布式事务一致性解决方案 spring分布式事务解决方案 springcloud分布式事务
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
