冗余双写方案下数据一致性问题解决及延申问题处理方案，小白以及计算机类学生的福音

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新大数据全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注大数据）

正文

缺点：采用事务一致性后，高并发场景下性能下降严重，且本身Seata自身也存在一定的性能损耗。Seata更适用于后台管理系统等并发量不高的应用，并不适用C端应用。

方案二：

使用消息队列（MQ）作为通信中介是一种高效的方式，其中生产者仅需确认消息发送成功即可，而订阅的消费者（B端/C端）则负责消费消息。对于商户（生产者）而言，一旦消息成功发送，便可立即返回成功标识，使得响应效率最大化。具体的业务逻辑，如创建短链码等任务，则由相应的消费者负责处理。这种方式不再依赖于强一致性（全局锁），从而提升了系统的请求并发量。然而，为确保最终一致性，必须加强消息处理的幂等性和异常处理能力。

缺点：弱一致性，不适用于需要强一致的场景，当消费者消费失败时，需要额外写接口回滚生产者业务逻辑。

2、问题：市面上有很多MQ产品，例如Kafka或RabbitMq，两者各有千秋，Mq产品如何选择？

方案一：

Kafka采用发布/订阅模式，消息被分区并分发给订阅者，每个消费者可以独立地消费特