FJJJJJ

注册中心namesrv 概述 在一个分布式服务系统里面注册中心是不可或缺的，因为它维护这服务的状态，防止分布式系统出现单点故障，提供高可用。 假使不使用注册中心，服务发现，那么就需要在客户端配置每个服务端的信息，那么在服务端横向扩容的时候就显得很生硬，服务发现功能主要是为了让服务自动注册，让客户端能够自动感知到服务端的状态信息，从而使用一定的策略权衡调用服务。 rocketmq注册中心 网上普遍存在如下两个架构图： 不同于其他的注册中心： rocketmq的namesrv之间是互不通信的，并且是不分M-S的

Rocketmq 刷盘机制 三个文件 在rocketmq里面存在这样三个文件 indexfile consumequeue commitlog 其中indexfile和consumequeue可以理解为索引文件， indexFile consumeQueue commitlog 刷盘

由于HA机制需要两台机器运行，我笔者只有一台电脑，不然就需要修改很多端口文件配置来进行启动，难度较大，所以这节就直接分析代码，就不debug进入到程序了。 rocketmq HA rocketmq添加slave有如下好处： 数据备份：保证多台broker数据的冗余，特别是主从同步复制的情况下，master出现不可恢复的故障之后，保证数据不丢失 高可用性：即使master掉线，consumer会自动从连到对应的slave机器，不会出现消费停滞的情况 提高性能：分担master的压力，主要表现在，拉取消息的最大

继前文顺藤摸瓜RocketMQ之消息发送debug解析分析完消息发送的流程之后，我们接着分析rocketmq的消息消费流程，环境搭建见前面的文章消息发送。 消息发送流程分析 consumer启动以及拉取消息 来到我们的代码org.apache.rocketmq.example.quickstart.Consumer： new了一个consumer的默认实现，然后设置了一些必要信息之后，就执行start方法，我们跟进： public class Consumer { public static .

启动rocketmq

代码结构 映入眼帘，还是可以很清晰的分辨出各个模块都是负责哪块的 acl 访问控制列表（Access Control Lists，ACL），RocketMQ权限管理模块 broker 接收客户端请求，处理消息分发，存储消息数据等 client MQ客户端，包括Producer和Consumer common 用于存储RocketMQ项目的通用代码和Model等 dev merge_rocketmq_pr.py脚本，用于处理RP distribution Client、Namesrv、Broker等启动脚本