本文已参与「新人创作礼」活动，一起开启掘金创作之路。
蓝本
1. 为什么要使用MQ
(1) 解耦 ：传统单一大服务架构拆分成网络体系架构，降低各部分系统之间的耦合****
(2) 异步：各个服务之间有异步通信需求，需要消息中间键进行消息传递****
(3) 削峰 ：请求达到峰值后，后端service还可以保持固定消费速率消费，不会被压垮****
(1) 分布式：复杂业务的执行拆分到各个子业务系统执行****
2. RocketMQ优点
RocketMQ是一款java语言开发的分布式的消息中间件
(1) 灵活可扩展性
RocketMQ天然支持集群，其核心四组件（Name Server、Broker、Producer、Consumer）每一个都可以在没有单点故障的情况下进行水平扩展
(2) 海量消息堆积能力
单一队列百万消息的堆积能力，RocketMQ提供亿级消息的堆积能力，堆积了亿级的消息后，依然保持写入低延迟
(3) 支持顺序消息****
可以保证消息消费者按照消息发送的顺序对消息进行消费。
顺序消息分为全局有序和局部有序，一般推荐使用局部有序，即生产者通过将某一类消息按顺序发送至同一个队列来实现
(4) 支持多种消息过滤方式
消息过滤分为在服务器端过滤和在消费端过滤。服务器端过滤时可以按照消息消费者的要求做过滤
(5) 支持事务消息
RocketMQ 除了支持普通消息，顺序消息之外还支持事务消息，这个特性对于分布式事务来说提供了又一种解决思路
(6) 回溯消费
回溯消费是指消费者已经消费成功的消息，由于业务上需求需要重新消费。
RocketMQ 支持按照时间回溯消费，时间维度精确到毫秒，可以向前回溯，也可以向后回溯。
3. RocketMQ 架构
核心概念
(1) Broker
broker是RocketMQ服务节点
broker主要用于producer和consumer接收和发送消息
每个broker启动时，都会遍历NameServer列表，与每个NameServer建立长连接，注册自己的信息，之后定时上报
(1) Nameserver
类似zookeeper，底层由netty实现，提供了路由管理、服务注册、服务发现的功能，是一个无状态节点
nameserver是服务发现者，集群中各个角色（producer、broker、consumer等）都需要定时向nameserver上报自己的状态，以便互相发现彼此，超时不上报的话，nameserver会把它从列表中剔除
nameserver可以部署多个，当多个nameserver存在的时候，其他角色同时向他们上报信息，以保证高可用，集群间互不通信，没有主备的概念
(2) Producer
消息的生产者，随机选择其中一个NameServer节点建立长连接，获得Topic路由信息
(3) Consumer
消息的消费者，通过NameServer集群获得Topic的路由信息，连接到对应的Broker上消费消息
4. RocketMQ的负载均衡
负载均衡（Load Balance），意思是将负载（工作任务，访问请求）进行平衡、分摊到多个操作单元（服务器，组件）上进行执行。是解决高性能，单点故障（高可用），扩展性（水平伸缩）的终极解决方案。www.cnblogs.com/fanBlog/p/1…
RocketMQ中的负载均衡都在Client端完成，具体来说的话，主要可以分为Producer端发送消息时候的负载均衡和Consumer端订阅消息的负载均衡
(1) producer端
发送端随机递增取模的方式选择一个队列来发送消息到相应的broker，来达到写入时的负载均衡
如果发送失败，再按一定的时间做退避策略去改变发送队列
(4) consumer端
在RocketMQ中，Consumer端的两种消费模式（Push/Pull）都是基于拉模式来获取消息的。而在Push模式只是对pull模式的一种封装。
pull消息时采用的是消息队列分配策略算法来进行负载均衡。如
①消息队列的平均分配算法(默认)
②环形分配策略
③手动配置分配策略
5. RocketMQ可靠性
解决方式
(1) 同步发送
同步发送是指发送端在发送消息时，阻塞线程进行等待，直到服务器返回发送的结果。
有可能发生重复投递
(2) 异步发送
发送后需要根据发送的结果信息来判断是否需要重试来保证消息的可靠性
(3) 单点故障
主从模式，可以采用增加Slave节点，主从异步复制仍然可能有极少量数据丢失，同步复制可以完全避免单点问题。(解决机器无法开机；磁盘损坏）
(4) 单机的刷盘机制
同步刷盘可以保证数据不丢失，异步刷盘可能导致少量数据丢失 （解决Broker异常Crash；OS Crash；机器掉电，但是能立即恢复供电情况）
(5) 消费重试
消费者从RocketMQ拉取到消息之后，需要返回消费成功来表示业务方正常消费完成。返回CONSUME_LATER表示过段时间再次消费。
多次CONSUME_LATER进入死信队列
(6) 死信队列
未能成功消费的消息，消息队列并不会立刻将消息丢弃，而是将消息发送到死信队列
可以通过RocketMQ提供的相关接口从死信队列获取到相应的消息，保证了消息消费的可靠性。
(7) 消息回溯
回溯消费是指Consumer已经消费成功的消息，或者之前消费业务逻辑有问题，现在需要重新消费。
RocketMQ Broker提供了一种机制，可以按照时间维度来回退消费进度，这样就可以保证只要发送成功的消息，只要消息没有过期，消息始终是可以消费到的。
baijiahao.baidu.com/s?id=169055…
5. RocketMQ 幂等性
幂等性，用在编程领域，则意为对同一个系统，使用同样的条件，一次请求和重复的多次请求对系统资源的影响是一致的。在这里，探索重复消费问题。
引起重复消费的原因
通常消费消息的确认机制一般分为两种思路：
先提交后消费先消费 ，可以解决重复消费的问题但是会丢失消息
消费成功后再提交 RocketMQ默认实现这种，然后由各自consumer业务方保证幂等来解决重复消费问题
解决方式
①发送时避免重复投递
②业务id识别本地缓存判断消息唯一
③consumer业务保证事务的一致性
7. RocketMQ事务
RocketMQ是一种最终一致性的分布式事务，就是说它保证的是消息最终一致性
只能保证消息发送方本地事务加上+发送事务正常，无法保证消息订阅方的事务。
也就是说，如果消息发送失败，可以取消本地事务；发送方本地事务异常，也可以取消消息的到达订阅方
但是一旦发送方整个事务正常，消息可被订阅，即使订阅方出现异常，发送方已经执行的操作就不再回滚。
如果订阅方最终执行失败，几乎可以断定就是代码有问题所以才引起的异常，因为消费端RocketMQ有重试机制，如果不是代码问题一般重试几次就能成功。如果是代码的原因引起多次重试失败后，也没有关系，将该异常记录下来，由人工处理，人工兜底处理后，就可以让事务达到最终的一致性
