RocketMQ

一、服务发现 RocketMQ有下面几个角色 NameSrv: 注册中心 Broker: 消息服务器 Producer: 消息生产者 Consumer: 消息消费者 RocketMQ没有使用Zooke

简介 RocketMQ整体架构设计 Producer：消息生产者 Consumer：消息消费者 NameServer：查询各个Topic对应的Broker IP列表 BrokerServer：存储消息

一、概要 RocketMQ采用了2PC的思想来实现了提交事务消息，同时增加一个补偿逻辑来处理二阶段超时或者失败的消息 所以，事务消息大致分两个流程：正常事务消息的发送及提交、事务消息的补偿流程 1.1

概要 消息有序指的是可以按照消息的发送顺序来消费(FIFO)。RocketMQ可以严格的保证消息有序，可以分为分区有序或者全局有序。 顺序消费的原理解析，在默认的情况下消息发送会采取Round Rob

1. 为什么要使用MQ 1.1 流量削峰 使用消息队列做缓冲。假设一个订单系统最多能处理一万个订单，当订单数量超过一万个后，只能限制超过一万后不允许用户下单。这时可以用MQ做缓冲，把一秒内下的订单分散

1. 使用场景 在淘宝购物车下单时，涉及到购物车系统和交易系统，这两个系统之间的数据最终一致性可以通过分布式事务消息的异步处理实现。在这种场景下，交易系统是最为核心的系统，需要最大限度地保证下单成功。

1. 消息发送方式 1.1 同步消息 消息发送进入同步等待状态，保证消息一定到达 1.2 异步消息 1.3 单向消息 只发消息，不等待服务器响应。 通常消息的发送是这样一个过程： 客户端发送请求到服务

RocketMQ如何保证消费幂等？ 消息幂等 当出现消费者对某条消息重复消费的情况时，重复消费的结果与消费一次的结果是相同，并且多次消费并未对业务系统产生任何负面影响，那么这个消费者的处理过程就是幂等

RocketMQ服务发现源码。RocketMQ没有使用Zookeeper作为服务的注册中心，而是自研的NameSrv，每个NameSrv都是无关联的节点。