rocketmq

目录 前言 正文 消息队列概述 消息队列的特点 2.1. 采用异步处理模式 2.2. 应用系统之间解耦合 消息队列的传递服务模型 消息队列的的传输模式 4.1. 点对点模型 4.2. 发布/订阅模型（Pub/Sub） 消息队列应用场景 5.1. 异步处理 5.2. 系统解耦 5.3. 最终一致性 5.4. 广播 5.5. 流量削峰和流控 5.6. 日志处理 5.7. 消息通讯 消息队列的推拉模型 6.1. Push推消息模型 6.2. Pull拉消息模型 6.3. 两种类型的区别 消息队列技术对比 7.1. ActiveMQ 7.2. RabbitMQ 7.3. RocketMQ 7.4. Kafka 7.5. 几种消息队列对比 小结 前言 消息队列 已经逐渐成为企业应用系统 内部通信 的核心手段。它具有 低耦合 、 可靠投递 、 广播 、 流量控制 、 最终一致性 等一系列功能。 当前使用较多的 消息队列 有 RabbitMQ 、 RocketMQ 、 ActiveMQ 、 Kafka 、 ZeroMQ 、 MetaMQ 等，而部分 数据库 如 Redis 、 MySQL 以及 phxsql 也可实现消息队列的功能。 正文 1. 消息队列概述 消息队列 是指利用 高效可靠 的 消息传递机制 进行与平台无关的 数据交流 ，并基于 数据通信 来进行分布式系统的集成。 通过提供

开发单体应用时，相信大家都有使用过数据库的 本地事务 ，也就是在同一个数据库中，可以允许一组操作要么全都正确执行，要么全都不执行。这里特别指出了本地事务，也就是说明数据库事务只支持同一个数据库的操作。可随着技术和业务发展，一方面随着系统业务量增大，数据库存储东西越来越多。当达到一定数据量时，为了应对高并发，就会出现分库分表需求。另一方面，随着服务化方案的推广，越来越多的公司团队将原有的大项目拆分成一个个小应用，这也使得跨应用（JVM）数据库场景出现。可是目前数据库不支持跨库事务，我们应该如何实现分布式事务呢？本文首先会为大家梳理分布式事务的基本概念和理论基础，然后介绍几种目前常用的分布式事务解决方案。 一、定义 百度百科给出的定义：“分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。”简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 二、事务的四大特性 ACID 1.原子性 原子性要求，事务是一个不可分割的执行单元，事务中的所有操作要么全都执行，要么全都不执行。 2.一致性 一致性要求，事务在开始前和结束后，数据库的完整性约束没有被破坏。 3.隔离性

Java Web系列文章汇总贴: Java Web知识总结汇总 分布式事务基本理论 基本概念 通常把一个数据库内部的事务处理，如对多个表的操作，作为本地事务看待。数据库的事务处理对象是本地事务，而分布式事务处理的对象是全局事务。 所谓全局事务，是指分布式事务处理环境中，多个数据库可能需要共同完成一个工作，这个工作即是一个全局事务，例如，一个事务中可能更新几个不同的数据库（可以是不同的应用对应的数据库）。对数据库的操作发生在系统的各处但必须全部被提交或回滚 。此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功，还要依赖与全局事务相关的其它数据库的操作是否成功，如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。 一般情况下，某一数据库无法知道其它数据库在做什么。因此，在一个 DTP 环境中，交易中间件是必需的，由它通知和协调相关数据库的提交或回滚。而一个数据库只将其自己所做的操作（可恢复）映射到全局事务中。 2PC、3PC基本概念 2PC,3PC主要是基于分布式事务的分布式一致性算法（因为分布式事务也可能会导致数据的不一致问题，这跟副本的不一致性从大类上看是都归于数据的不一致）。 在分布式系统中，各个节点之间在物理上相互独立，通过网络进行沟通和协调。由于存在事务机制，可以保证每个独立节点上的数据操作可以满足ACID。但是

分布式事务 分布式理论 单个数据库的性能产生瓶颈的时候，我们可能对数据库进行分区，这里所说的分区是指物理分区，分区之后可能不同的库就处于不同的服务器上了，这个时候单个数据库的ACID已经不能适应这种情况了，而在这种ACID的集群环境下，再想保证集群的ACID会导致我们的系统变得很差，这个时候我们需要引入CAP原则。 一致性(Consistency) ： 客户端知道一系列的操作都会同时发生(生效) 可用性(Availability) ： 每个操作都必须以可预期的响应结束 分区容错性(Partition tolerance) ： 即使出现单个组件无法可用,操作依然可以完成 具体地讲在分布式系统中，在任何数据库设计中，一个Web应用至多只能同时支持上面的两个属性。显然，任何横向扩展策略都要依赖于数据分区。因此，设计人员必须在一致性与可用性之间做出选择。 [了解] 数据库支持2PC，又叫XA Transactions,MySQL5.5、SQL Server2005、Oracle7开始支持。 其中，XA是一个两阶段提交协议，该协议分为以下两个阶段： ·第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交。 ·第二阶段：事务协调器要求每个数据库提交数据。 如果任何一个数据库否决此次提交，那么所有数据库都会被要求回滚它们在次数据库中的那部分信息

获取最早的消息存储时间AdminBrokerProcessor#getEarliestMsgStoretime AdminBrokerProcessor#processRequest#this.getEarliestMsgStoretime(ctx, request) private RemotingCommand getEarliestMsgStoretime(ChannelHandlerContext ctx, RemotingCommand request) throws RemotingCommandException { final RemotingCommand response = RemotingCommand.createResponseCommand(GetEarliestMsgStoretimeResponseHeader.class); final GetEarliestMsgStoretimeResponseHeader responseHeader = (GetEarliestMsgStoretimeResponseHeader) response.readCustomHeader(); final GetEarliestMsgStoretimeRequestHeader requestHeader =

虚拟机使用RocketMQ报错 sendDefaultImpl call timeout RocketMQ发生下面错误 原因 解决方法 RocketMQ发生下面错误 在虚拟机下安装RocketMQ，并且在客户端的 Producer 发送消息对的时候发生如下异常错误信息： Exception in thread "main" org . apache . rocketmq . remoting . exception . RemotingTooMuchRequestException : sendDefaultImpl call timeout at org . apache . rocketmq . client . impl . producer . DefaultMQProducerImpl . sendDefaultImpl ( DefaultMQProducerImpl . java : 640 ) at org . apache . rocketmq . client . impl . producer . DefaultMQProducerImpl . send ( DefaultMQProducerImpl . java : 1310 ) at org . apache . rocketmq . client . impl . producer .

一、为什么使用消息队列？ 大多数情况下，使用消息队列目的是：： 解耦、异步、削峰 。 通过一个 MQ，Pub/Sub 发布订阅消息这么一个模型，彻底解耦了 通过MQ，使得同步的操作变为异步操作，提高效率。 通过MQ，控制服务可以接收到的请求数量 二、消息队列有什么优缺点 优点就是在特殊场景下有其对应的好处， 解耦、异步、削峰 缺点有以下几个： 系统可用性降低 系统引入的外部依赖越多，越容易挂掉。需要保证消息队列的高可用 系统复杂度提高，保证消息没有重复消费，怎么处理消息丢失的情况，怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已。 一致性问题 A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了。 三、如何解决消息丢失？ ack（消费者确认）（ 消费者手动ack ） 持久化 （交换机、队列、消息） 不推荐使用消息事务，会验证降低性能 生产者确认（publisher confirm）：生产者发送消息后，等待mq的ACK，如果没有收到或者收到失败信息，则重试。如果收到成功消息则业务结束。 channel.waitForConfirmsOrDie(10000); 可靠消息服务（可选，自己编写逻辑）：对于部分不支持生产者确认的消息队列，可以发送消息前

面试题 为什么使用消息队列？ 消息队列有什么优点和缺点？ Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别，以及适合哪些场景？ 面试官心理分析 其实面试官主要是想看看： 第一 ，你知不知道你们系统里为什么要用消息队列这个东西？ 不少候选人，说自己项目里用了 Redis、MQ，但是其实他并不知道自己为什么要用这个东西。其实说白了，就是为了用而用，或者是别人设计的架构，他从头到尾都没思考过。 没有对自己的架构问过为什么的人，一定是平时没有思考的人，面试官对这类候选人印象通常很不好。因为面试官担心你进了团队之后只会木头木脑的干呆活儿，不会自己思考。 第二 ，你既然用了消息队列这个东西，你知不知道用了有什么好处&坏处？ 你要是没考虑过这个，那你盲目弄个 MQ 进系统里，后面出了问题你是不是就自己溜了给公司留坑？你要是没考虑过引入一个技术可能存在的弊端和风险，面试官把这类候选人招进来了，基本可能就是挖坑型选手。就怕你干 1 年挖一堆坑，自己跳槽了，给公司留下无穷后患。 第三 ，既然你用了 MQ，可能是某一种 MQ，那么你当时做没做过调研？ 你别傻乎乎的自己拍脑袋看个人喜好就瞎用了一个 MQ，比如 Kafka，甚至都从没调研过业界流行的 MQ 到底有哪几种。每一个 MQ 的优点和缺点是什么。每一个 MQ 没有绝对的好坏 ，但是就是看用在哪个场景可以 扬长避短

面试题 为什么使用消息队列？ 消息队列有什么优点和缺点？ Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别，以及适合哪些场景？ 面试官心理分析 其实面试官主要是想看看： 第一 ，你知不知道你们系统里为什么要用消息队列这个东西？ 不少候选人，说自己项目里用了 Redis、MQ，但是其实他并不知道自己为什么要用这个东西。其实说白了，就是为了用而用，或者是别人设计的架构，他从头到尾都没思考过。 没有对自己的架构问过为什么的人，一定是平时没有思考的人，面试官对这类候选人印象通常很不好。因为面试官担心你进了团队之后只会木头木脑的干呆活儿，不会自己思考。 第二 ，你既然用了消息队列这个东西，你知不知道用了有什么好处&坏处？ 你要是没考虑过这个，那你盲目弄个 MQ 进系统里，后面出了问题你是不是就自己溜了给公司留坑？你要是没考虑过引入一个技术可能存在的弊端和风险，面试官把这类候选人招进来了，基本可能就是挖坑型选手。就怕你干 1 年挖一堆坑，自己跳槽了，给公司留下无穷后患。 第三 ，既然你用了 MQ，可能是某一种 MQ，那么你当时做没做过调研？ 你别傻乎乎的自己拍脑袋看个人喜好就瞎用了一个 MQ，比如 Kafka，甚至都从没调研过业界流行的 MQ 到底有哪几种。每一个 MQ 的优点和缺点是什么。每一个 MQ 没有绝对的好坏 ，但是就是看用在哪个场景可以 扬长避短

博客名称：唯有坚持不懈 博客作者：丁威 作者简介：中通科技技术平台部架构师，《RocketMQ技术内幕》作者、中间件兴趣圈微信公众号维护者。 博客简介： 主要关注Java主流开源中间件，博客从JAVA高端基础入手，从源码的角度分析了Java集合框架、Java并发包(多线程、并发锁)，紧接着进入到网络编程专题，开通了源码分析Netty5系列专栏，随后依次开通了源码分析Mycat系列专栏、源码分析RocketMQ专栏、源码分析ElasticJob专栏、源码分析Dubbo专栏、Elasticsearch使用指南等。后续会持续关注Java端主流框架，诸如Haddoop、Hbase、Sentinel、Fascar、Spring Clould等。 目前主要专栏如下： 作者维护的的微信公众号：中间件兴趣圈，二维码如下： 作者新手《RocketMQ技术内幕》已成功上市： 《RocketMQ技术内幕》已出版上市，目前可在主流购物平台（京东、天猫等）购买，本书从源码角度深度分析了RocketMQ NameServer、消息发送、消息存储、消息消费、消息过滤、主从同步HA、事务消息；在实战篇重点介绍了RocketMQ运维管理界面与当前支持的39个运维命令；并在附录部分罗列了RocketMQ几乎所有的配置参数。本书得到了RocketMQ创始人、阿里巴巴Messaging开源技术负责人、Linux