两阶段提交就是使用XA协议的原理，我们可以从下面这个图的流程来很容易的看出中间的一些比如commit和abort的细节。
错误信息关键点：MQBrokerException：CODE:2 DESC:[TIMEOUT_CLEAN_QUEUE]broker busy,start flow control for a while,period in queue：205ms，size of queue:880。
那么，RocketMQ-client怎么知道这条消息要发送到RocketMQ集群中的哪一个broker上呢？
在异步消息传输系统中，消息乱序是一个常见的挑战。当消息在发送过程中发生重试时，很可能会导致消息的乱序，这可能对系统的一致性和可靠性产生负面影响。本文将探讨异步消息发送中可能出现的消息乱序问题，以及解决这些问题的方法。
Pulsar中消息的顺序性和几个因素有关：用户自己的业务线程数、Producer 的路由模式(SinglePartition、RoundRobinPariion等、Topie是否分区、发送方式（同步、异步），是否开启批量发送、消息是否有Key。 每个Producer实例都有一个属于自已的发送队列，不管是同步发送还是异步发送，所有的消息都会先进入这个队列。同步发送是基于异步发送实现的----异步发送会返回一个CompletablePuture对象，同步发送只是在此基础上同步等特而已（通过CompletableFuture,get（）实现)。因此，同步发送的消息也会先进入发送队列，不过每次入队后都会触发发送操作。
备注：比如生产端消息没有完全投递成功，或者消费端落库异常导致消费端落库缺少消息条目的情况
从rocketmq topic的创建机制可知，一个topic对应有多个消息队列，那么我们在发送消息时，是如何选择消息队列进行发送的？假如这时有broker宕机了，rocketmq是如何规避故障broker的？看完这篇文章，相信你会从文中找到答案。
分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。例如在大型电商系统中，下单接口通常会扣减库存、减去优惠、生成订单 id, 而订单服务与库存、优惠、订单 id 都是不同的服务，下单接口的成功与否，不仅取决于本地的 db 操作，而且依赖第三方系统的结果，这时候分布式事务就保证这些操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
在大型互联网中，主要采用消息中间件来进行业务的解耦和操作的异步化，这也是消息中间件最基础的特点，也是业务系统对消息中间件的最基本需求。
RocketMQ分布式集群是通过Master和Slave的配合达到高可用性的；Master 角色的Broker支持读和写，Slave角色的 Broker仅支持读，也就是Producer只能和Master角色的Broker 连接写入消息;Consumer可以连接Master角色的Broker，也可以连接Slave角色的Broker来读取消息；
只有发送消息设置了tags,消费方在订阅消息时，才可以利用tags在broker做消息过滤
上篇文章，王子通过一个小案例和小伙伴们一起分析了一下消息是如何丢失的，但没有提出具体的解决方案。
本文将结合自己使用RocketMQ的经验，对消息发送常见的问题进行分享，基本会遵循出现问题，分析问题、解决问题。
在分布式系统中，为了保证数据一致性是必须使用分布式事务。分布式事务实现方式就很多种，今天主要介绍一下使用 RocketMQ 事务消息，实现分布事务。
本文不讲什么是 RocketMQ ，不讲它的实现原理，只想和大家探讨下它的事务消息的正确使用方式
消息发送成功返回确认消息，那就能确保消息不丢失。如果发送失败了，mq-client就尝试自动重试，避免网络抖动导致发送丢失。
在微服务架构中，我们常常使用异步化的手段来提升系统的 吞吐量 和 解耦 上下游，而构建异步架构最常用的手段就是使用 消息队列(MQ)，那异步架构怎样才能实现数据一致性呢？本文主要介绍如何使用RocketMQ的事务消息来解决一致性问题。
producerGroup: 组名 createTopicKey：创建topic，实际生产实践不允许生产者创建top。 defaultTopicQueueNums(默认为4)：默认的topic关联的队列数量 sendMsgTimeout(单位:ms)：发送消息连接broker超时时间。 compressMsgBodyOverHowmuch(默认压缩字节4096)：消息体达到多少压缩。 retryTimesWhenSendFailed (可配置)：发送失败重试次数 retryAnotherBrokerWhenNotStoreOK(默认false)：发送broker存储失败换个broker发送。 maxMessageSize(默认128K)：消息最大可以设置多大。 heartbeatBrokerInterval：与broker的心跳间隔(以微秒为单位，默认为30毫秒)
Kafka作为一种分布式消息队列系统，在大数据领域和实时数据处理中扮演着重要的角色。随着Kafka的广泛应用，用户对其功能的需求也在不断增加。延时操作作为其中之一，为用户提供了更多的灵活性和实用性。本文将介绍Kafka中延时操作的相关内容，包括其背后的原理、实现方式以及应用场景。
如果要想保证Kafka数据不丢， 要从Kafka的三个地方入手：生产者、服务端和消费者。
https://www.open-open.com/lib/view/open1421150566328.html
这是笔者最近处理一个叫异步大点击的业务问题所思考出来的方案。由于mq使用的是亚马逊的sqs服务，而sqs是按请求数消费的原因，所以才有的将多消息合并为一条消息发送的想法。
之前安装好了RocketMQ,这一篇就简单记录一下Spring boot是怎么集成RocketMQ的，如果有需要安装RocketMQ的同学看这一篇,Linux在线安装RocketMQ，如果没有linux环境的同学也可以本地启动，只需要有java环境即可。
客服IM的核心业务就是在线沟通，客服与用户通过实时沟通的方式可以在最短的时间内帮助用户解决问题。初期为了快速支撑业务需求，便基于第三方SDK进行了二次开发，同时也埋下了问题定位困难，特殊功能实现成本高等隐患。随着公司业务的快速发展，客服对IM聊天的性能和体验都有了更高的要求，第三方SDK消息通信逐渐遇到了瓶颈，为解决第三方SDK接入带来的潜在隐患、提升IM的稳定性和高扩展性，自研一套可控、稳定、灵活的IM系统已是无法避开的一条道路了。以下主要是以客服端(web)为主。
以电商交易场景为例，用户支付订单这一核心操作的同时会涉及到下游物流发货、积分变更、购物车状态清空等多个子系统的变更。在微服务架构场景下，这些子系统之间要么是通过RPC通信，要么通过MQ消息组件通信。
消息有序指的是按照消息的发送顺序来消费(FIFO)。RocketMQ可以保证消息有序，消息有序分为部分有序和全局有序。全局有序是指某个Topic下的所有消息都要保证顺序；部分顺序消息只要保证每一组消息被顺序消费即可。
在使用RabbitMQ消息中间件时，因为消息的投递是异步的，默认情况下，RabbitMQ会删除那些无法路由的消息。为了能够检出消息是否顺利投递到队列，我们需要相应的处理机制。今天就来验证一下相关的验证机制。
每天定时抓取web端个小程序端数据，退送wx指定人/群或者邮件。本次通过邮件和wx，推送数据到邮箱或wx指定人
在使用消息队列时，有两个经常让我们烦恼的问题，消息丢失和消息重复。那我们在做技术选型时，有没有一个消息队列能解决消息丢失和消息重复这两个问题呢？
MQ 事务消息 有一些第三方的MQ是支持事务消息的，比如RocketMQ，他们支持事务消息的方式也是类似于采用的二阶段提交，但是市面上一些主流的MQ都是不支持事务消息的，比如 RabbitMQ 和 Kafka 都不支持。 第一阶段Prepared消息，会拿到消息的地址。第二阶段执行本地事务，第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。也就是说在业务方法内要想消息队列提交两次请求，一次发送消息和一次确认消息。如果确认消息发送失败了RocketMQ会定期扫描消息集群中的事务消息，这时候发现了Prepared消息，它会向消息发送者确认，所以生产方需要实现一个check接口，RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。
At least Once：指每个消息必须投递一次。Consumer先Pull消息到本地，消费完成后，才向服务器返回ack，如果没有消费一定不会ack消息。
大概的意思就是： A 系统先发送一个 prepared 消息到 mq，如果这个 prepared 消息发送失败那么就直接取消操作别执行了； 如果这个消息发送成功过了，那么接着执行本地事务，如果成功就告诉 mq 发送确认消息，如果失败就告诉 mq 回滚消息； 如果发送了确认消息，那么此时 B 系统会接收到确认消息，然后执行本地的事务； mq 会自动定时轮询所有 prepared 消息回调你的接口，问你，这个消息是不是本地事务处理失败了，所有没发送确认的消息，是继续重试还是回滚？一般来说这里你就可以查下数据库看之前本地事务是否执行，如果回滚了，那么这里也回滚吧。这个就是避免可能本地事务执行成功了，而确认消息却发送失败了。 这个方案里，要是系统 B 的事务失败了咋办？重试咯，自动不断重试直到成功，如果实在是不行，要么就是针对重要的资金类业务进行回滚，比如 B 系统本地回滚后，想办法通知系统 A 也回滚；或者是发送报警由人工来手工回滚和补偿。 这个还是比较合适的，目前国内互联网公司大都是这么玩儿的，要不你就用 RocketMQ 支持的，要不你就自己基于类似 ActiveMQ？RabbitMQ？自己封装一套类似的逻辑出来，总之思路就是这样子的。
同步消息（Sync Message）：生产者向broker发送消息，执行相关的代码同时等待，直到broker服务器返回发送结果，在后续执行。
一次大的操作由不同的小操作组成的，这些小的操作分布在不同的服务器上，分布式事务需要保证这些小操作要么全部成功，要么全部失败。从本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
最近的工作我在做一个有关于消息发送和接受封装工作。大概流程是这样的，消息中间件是采用rabbitmq，为了保证消息的绝对无丢失，我们需要在发送和接受前对消息进行DB落地。在发送前我会先进行DB的插入，
一条消费成功被消费经历了生产者->MQ->消费者，因此在这三个步骤中都有可能造成消息丢失。
发送顺序消息无法利用集群Fail Over特性消费，顺序消息的并行度依赖于队列数量，存在队列热点问题，个别队列由于哈希不均导致消息过多，消费速度跟不上，产生消息堆积问题遇到消息失败的消息，无法跳过，当前队列消费暂停。
在之前的文章中，我们详细介绍了 SpringBoot 整合 mail 实现各类邮件的自动推送服务。
RabbitMQ相信大家都非常熟悉了，今天咱们来聊聊怎么保证RabbitMQ的可靠性。
https://gitee.com/boring-yingjie/rabbit-mq-message-confirmation.git
即时通讯网整理的大量IM技术文章中（见本文末“参考资料”一节），有关消息可靠性和一致性问题的文章占了很大比重，原因是IM这类系统抛开各种眼花缭乱的产品功能和技术特性，保证消息的可靠性和一致性几乎是IM产品必需的素质。
分布式事务解决方案有很多种，最要包括基于XA协议的两阶段提交方案、本地消息表方案、TCC事务补偿型方案、可靠消息最终一致性方案、尽最大努力通知型方案等。面试的时候不可能长篇大论，所以能答上下面这三种方案就七八不离十。
客服IM的核心业务其实就是在线沟通，客服IM的好处是使得客服与用户通过实时沟通的方式可以在最短的时间内帮助用户解决问题。
最近了解并简单实用了下Rabbitmq，整个使用也大致了解了，但是要作做到真正的可靠，仅仅依赖于应用提供的方式是否在业务环境中真的能够达到可靠的目的。当然我们所谓的可靠性主要指的以下几方面（个人认为）：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
