前面几篇文章分享了kafka 相关的实现逻辑，kafka在大吞吐量方面有较好的表现，但是有时候我们需要实现比较复杂的业务逻辑从而对于吞吐量方面要求不是太高，这个时候我们就可以选择RocketMQ.
有了Kafka 为什么还要RocketMQ?
我们知道kafka 的性能非常好，吞吐量也非常大。Kafka单机写入 TPS 号称在百万条/秒;追求性能的话，Kafka单机性能更高。这也依靠基于他的顺序写入，Memory Mapped Files 技术 和消费者端的zero copy。(kafka基于sendfile实现Zero Copy，直接从内核空间(DMA的)到内核空间(Socket的)，然后发送网卡。)但是对平常工作中各种复杂的应用场景及对数据可靠性要求严格的业务就有点力不从心了。我们从以下几个方面分析：
【数据可靠性方面】
RocketMQ所支持的同步方式提升了数据的可靠性，RocketMQ支持异步/同步刷盘;异步/同步Replication;Kafka使用异步刷盘方式，异步Replication。
【消息顺序性】
Kafka 某些配置下，支持消息顺序，但是一台Broker宕机后，就会产生消息乱序;
RocketMQ支持严格的消息顺序，在顺序消息场景下，一台Broker宕机后，
发送消息会失败，但是不会乱序;
【关于定时/延时消息】
Kafka不支持定时消息;
RocketMQ支持定时消息;
【关于分布式事务消息】
Kafka不支持分布式事务消息;RocketMQ支持分布式事务消息
【关于消息查询机制】
Kafka不支持消息查询。
RocketMQ支持根据Message Id查询消息，也支持根据消息内容查询消息
【关于Broker 的设计上】
当broker里面的topic的partition数量过多时，kafka的性能却不如rocketMQ。
kafka和rocketMq都使用文件存储，但是kafka是一个分区一个文件，当topic过多，分区的总量也会增加，kafka中存在过多的文件，当对消息刷盘时，就会出现文件竞争磁盘，出现性能的下降。一个partition(分区)一个文件，顺序读写。一个分区只能被一个消费组中的一个 消费线程进行消费，因此可以同时消费的消费端也比较少。
rocketMq所有的队列都存储在一个文件中，每个队列的存储的消息量也比较小，因此topic的增加对rocketMq的性能的影响较小。rocketMq可以存在的topic比较多，可以适应比较复杂的业务。
RocketMQ架构设计
RocketMq技术架构
RocketMQ架构上主要分为四部分，如上图所示:
- Producer：消息发布的角色，支持分布式集群方式部署。Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递，投递的过程支持快速失败并且低延迟。
- Consumer：消息消费的角色，支持分布式集群方式部署。支持以push推，pull拉两种模式对消息进行消费。同时也支持集群方式和广播方式的消费，它提供实时消息订阅机制，可以满足大多数用户的需求。
- NameServer：NameServer是一个非常简单的Topic路由注册中心，其角色类似Dubbo中的zookeeper，支持Broker的动态注册与发现。主要包括两个功能：Broker管理，NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查Broker是否还存活;路由信息管理，每个NameServer将保存关于Broker集群的整个路由信息和用于客户端查询的队列信息。然后Producer和Conumser通过NameServer就可以知道整个Broker集群的路由信息，从而进行消息的投递和消费。NameServer通常也是集群的方式部署，各实例间相互不进行信息通讯。Broker是向每一台NameServer注册自己的路由信息，所以每一个NameServer实例上面都保存一份完整的路由信息。当某个NameServer因某种原因下线了，Broker仍然可以向其它NameServer同步其路由信息，Producer,Consumer仍然可以动态感知Broker的路由的信息。但是NameServer 并不会像ZK 一样提供选举功能
- BrokerServer：Broker主要负责消息的存储、投递和查询以及服务高可用保证，为了实现这些功能，Broker包含了以下几个重要子模块。
- Remoting Module：整个Broker的实体，负责处理来自clients端的请求。
- Client Manager：负责管理客户端(Producer/Consumer)和维护Consumer的Topic订阅信息
- Store Service：提供方便简单的API接口处理消息存储到物理硬盘和查询功能。
- HA Service：高可用服务，提供Master Broker 和 Slave Broker之间的数据同步功能。
- Index Service：根据特定的Message key对投递到Broker的消息进行索引服务，以提供消息的快速查询。
RocketMq架构部署
RocketMQ 网络部署特点
NameServer是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。
- Broker部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave 的对应关系通过指定相同的BrokerName，不同的BrokerId 来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信息到所有NameServer。注意：当前RocketMQ版本在部署架构上支持一Master多Slave，但只有BrokerId=1的从服务器才会参与消息的读负载。
- Producer与NameServer集群中的其中一个节点(随机选择)建立长连接，定期从NameServer获取Topic路由信息，并向提供Topic 服务的Master建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署。
- Consumer与NameServer集群中的其中一个节点(随机选择)建立长连接，定期从NameServer获取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息，消费者在向Master拉取消息时，Master服务器会根据拉取偏移量与最大偏移量的距离(判断是否读老消息，产生读I/O)，以及从服务器是否可读等因素建议下一次是从Master还是Slave拉取。
结合部署架构图，描述集群工作流程：
- 启动NameServer，NameServer起来后监听端口，等待Broker、Producer、Consumer连上来，相当于一个路由控制中心。
- Broker启动，跟所有的NameServer保持长连接，定时发送心跳包。心跳包中包含当前Broker信息(IP+端口等)以及存储所有Topic信息。注册成功后，NameServer集群中就有Topic跟Broker的映射关系。
- 收发消息前，先创建Topic，创建Topic时需要指定该Topic要存储在哪些Broker上，也可以在发送消息时自动创建Topic。
- Producer发送消息，启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取当前发送的Topic存在哪些Broker上，轮询从队列列表中选择一个队列，然后与队列所在的Broker建立长连接从而向Broker发消息。
- Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，开始消费消息。
模块间数据流转
生产-消费模型
生产消费流程
