最近mq越来越火，很多公司在用，很多人在用，其重要性不言而喻。但是如果我让你回答下面的这些问题：
1.保证消息传递与一致性 1.1生产者确保消息自主性 当生产者发送一条消息时，它必须完成他的所有业务操作。 如下图： 这保证消费者接受到消息时，生产者已处理完毕相关业务，也就是1PC的基础。 1.2
在分布式系统中，随着系统架构演进，原来的原子性操作会随着系统拆分而无法保障原子性从而产生一致性问题，但业务实际又需要保障一致性，下面我从学习和实战运用总结一下分布式一致性解决方案。
RocketMQ（以下简称MQ）作为消息中间件在事务管理，异步解耦，削峰填谷，数据同步等应用场景中有着广泛使用。当业务系统进行灰度发布时，Dubbo与HTTP的调用可以基于业界通用的灰度方式在我们的微服务治理与网关平台来实现，但MQ已有的灰度方案都不能完全解决消息的隔离与切换衔接问题，为此，我们在鲁班MQ平台（包含根因分析、资源管理、订阅关系校验、延时优化等等的扩展）增加了MQ灰度功能的扩展实现。
相信很多小伙伴都了解过分布式事务或者在项目中也接触到了分布式事务问题，但是基本对分布式事务的认识都是片面的，今天借此给小伙伴们分享我整理的工作中比较常见的分布式解决方案，相信同学们耐心看完后一定会对分布式事务问题有个深刻的认识。
现在的架构师总喜欢把最终一致挂在嘴上，好像最终一致是解决分布式场景下数据一致问题的金科玉律。事实上又怎么样呢？
Kafka 消息框架，大家一定不陌生，很多人工作中都有接触。它的核心思路，通过一个高性能的MQ服务来连接生产和消费两个系统，达到系统间的解耦，有很强的扩展性。
为了便于大家查找问题，了解全貌，整理个目录，我们可以快速全局了解关于消息队列，面试官一般会问哪些问题。
MQ全称为Message Queue-消息队列，是一种应用程序对应用程序的消息通信，一端只管往队列不断发布信息，另一端只管往队列中读取消息，发布者不需要关心读取消息的谁，读取消息者不需要关心发布消息的是谁，各干各的互不干扰。
“发消息”过程，往往是为通知另外一个系统更新数据，MQ的“事务”，主要解决消息生产者和消息消费者的数据一致性问题。
（1）解耦：可以在多个系统之间进行解耦，将原本通过网络之间的调用的方式改为使用MQ进行消息的异步通讯，只要该操作不是需要同步的，就可以改为使用MQ进行不同系统之间的联系，这样项目之间不会存在耦合，系统之间不会产生太大的影响，就算一个系统挂了，也只是消息挤压在MQ里面没人进行消费而已，不会对其他的系统产生影响。
在使用微服务时，存在跨多个服务更新数据库数据的情况。那么这就会出现一个问题，比如我们有三个服务（如下图），正常情况下，当一个请求进来时，服务1到服务3会分别改变其数据库中存储的数据，但是如果出现部分服务网络不通或者部分服务失效的情况，那么整个服务调用链就会失效，进而出现部分服务更新数据库成功，而剩余服务更新数据库失败的情况，这就出现了所谓了数据不一致。
在分布式系统中，为了保证数据一致性是必须使用分布式事务。分布式事务实现方式就很多种，今天主要介绍一下使用 RocketMQ 事务消息，实现分布事务。
小码收到猎头小姐姐的面试邀约后，认真进行了准备，并在约定时间到达了面试公司....
综上所述，根据不同的业务需求和技术实力，选择适合的消息队列是非常重要的。常见的消息队列包括 ActiveMQ、RabbitMQ、RocketMQ和Kafka。每种消息队列都有其优缺点，如单机吞吐量、时效性、可用性、消息可靠性和功能支持等方面有所差异。因此，在选择消息队列时，需要根据实际情况综合考虑这些因素。
随着微服务架构的推广，越来越多的公司采用微服务架构来构建自己的业务平台。就像前边的文章说的，微服务架构为业务开发带来了诸多好处的同时，例如单一职责、独立开发部署、功能复用和系统容错等等，也带来一些问题。
先说下这个词的概念，维基百科给的解释：年轻人出于对国内压抑的工作文化的失望，与其跟随社会期望坚持奋斗，不如选择“躺平”的处事态度。
MQ组件是系统架构里必不可少的一门利器，设计层面可以降低系统耦合度，高并发场景又可以起到削峰填谷的作用，从单体应用到集群部署方案，再到现在的微服务架构，MQ凭借其优秀的性能和高可靠性，得到了广泛的认可。 随着数据量增多，系统压力变大，开始出现这种现象：数据库已经更新了，但消息没发出来，或者消息先发了，但后来数据库更新失败了，结果研发童鞋各种数据修复，这种生产问题出现的概率不大，但让人很郁闷。这个其实就是数据库事务与MQ消息的一致性问题，简单来讲，数据库的事务跟普通MQ消息发送无法直接绑定与数据库事务绑定在一起，例如上面提及的两种问题场景：
一款分布式消息中间件，基于erlang开发， 具备语言级别的高并发处理能力。和Spring框架是同一家公司。支持持久化、高可用。
前面我们讲了分布式事务的2PC、3PC , TCC 的原理。这些事务其实都在尽力的模拟数据库的事务，我们可以简单的认为他们是一个同步行的事务。特别是 2PC,3PC 他们完全利用数据库的事务能力，在一阶段开始事务后不进提交会严重影响应用程序的并发性能。TCC 一阶段虽然不会阻塞数据库，但是它同样是在尽力追求同时成功同时失败的一致性要求。但是在很多时候，我们的应用程序的核心业务为了追求更高的性能、更高的可用性，可以允许在一段时间内的数据不一致性，只需要在最终时刻数据是一致就可以了。基于以上场景我们可以采用基于可靠消息服务的最终一致性分布式事务处理方案。
消息最多传递一次，如果当时客户端不可用，则会丢失该消息。即消息在传递时，最多被送达一次。无消息可靠性保证，允许丢消息。
一款分布式消息中间件，基于erlang语言开发， 具备语言级别的高并发处理能力。和Spring框架是同一家公司。 支持持久化、高可用
分布式事务是企业集成中的一个技术难点，也是每一个分布式系统架构中都会涉及到的一个东西，特别是在微服务架构中，几乎可以说是无法避免。
随着计算能力的提升、互联网的兴起、数据的分布和存储需求、容错性和可用性的要求、业务的分布和协同需求以及云计算和大数据技术的发展，分布式系统变得越来越重要，并在各个领域得到广泛应用。分布式系统由于机器宕机、网络异常、消息丢失、消息乱序、数据错误、不可靠的 TCP、存储数据丢失等原因面临一系列挑战，本文重点讲述分布式系统面临的挑战之一数据一致性问题。
现今互联网界，分布式系统和微服务架构盛行。业界著名的CAP理论也告诉我们，在设计和实现一个分布式系统时，需要将数据一致性、系统可用性和分区容忍性放在一起考虑。
关于CAP,BASE理论，以及TCC，seata解决方案，可以参考我上一篇博客.《Java分布式事务-seata,tcc解决方案总结》 本文是接着一篇继续的。
基于水平扩容能力和成本考虑，传统的强一致的解决方案（e.g.单机事务）纷纷被抛弃。其理论依据就是响当当的CAP原理。
继之前的mysql夺命连环之后，我发现我这个标题被好多套用的，什么夺命zookeeper，夺命多线程一大堆，这一次，开始面试题系列MQ专题，消息队列作为日常常见的使用中间件，面试也是必问的点之一，一起来看看MQ的面试题。
分布式事务这个话题，开发者们一定都不陌生。电商系统最容易出现分布式事务的处理，比如用户在电商平台购买一个商品，用户首先下单，然后平台要扣减库存。创建订单和库存的扣减一般都在不同的服务器上(微服务架构)。而用户购买到商品的行为，必须要下单和扣减库存都成功，才算这次的交易成功，反之则失败。
之前已经出过MQ系列相关的对线面试官，为方便小伙伴们能够通篇阅读更加方便，此篇文章均出自对线面试官系列。往期文章参考：
对于分布式事务，相信所有人都应该很了解，为什么会有分布式事务？无论是数据量导致的分库，还是现在微服务盛行的场景都是他出现的原因。
我们都知道在大多数情况下，通过浏览器查询到的数据都是缓存数据，如果缓存数据与数据库的数据存在较大差异的话，可能会产生比较严重的后果的。对此，我们应该也必须保证数据库数据、缓存数据的一致性，也就是就是缓存与数据库的同步。
数据库和缓存（比如：redis）双写数据一致性问题，是一个跟开发语言无关的公共问题。尤其在高并发的场景下，这个问题变得更加严重。
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
这里的并发不是高并发，只是将正式环境的一小段流量同时打到我的自测环境。一个请求同时多次发送，真正意义上并发处理同一个数据，主要需求是保证数据幂等性和正确性。
最近看到了我在Github上写的rabbitmq-examples陆续被人star了，就想着写个rocketmq-examples。对rabbitmq感兴趣的小伙伴可以看我之前的文章。下面把RocketMQ的各个特性简单介绍一下，这样在用的时候心里也更有把握
有赞是提供商家 SAAS 服务，随着越来越多的商家使用有赞，搜索或详情的需求也日益增长，针对需求及场景，之前提到过的订单管理架构演变及 AKF 架构等在这两篇文章里已经有所体现，而这些数据的查询来自于不同的 NoSQL，怎么同步这些非实时存储系统将是一个很有趣的事情。
在 《柔性事务之TCC详解》 和《柔性事务之Saga详解》两文中我们详细剖析了柔性事务的第一个分支补偿型事务。在《刚性事务总结和柔性事务概述》中我们介绍过的柔性事务包含补偿型事务和通知型事务。
我们以一个转帐的场景为例来说明这个问题，Bob向Smith转账100块。这个列子在瓜子也有很多实际场景映射，如：车源状态变化，订单状态变化，金融放款，物流运输……
单体数据库不涉及网络交互，所以在多表之间实现事务是比较简单的，这种事务称之为本地事务。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
