● RocketMQ体系结构。
● 常见的部署拓扑关系。
● 生产环境Namesrv、Broker、Console部署及验证部署结果。
下面介绍一些RoketMQ的关键词：
使用者 ：一般是指生产、消费程序的直接研发人员、RocketMQ中间件的维护人员等。
Console管理平台 ：管理RocketMQ生产者组、Topic、消费者组和 RocketMQ元数据的平台。管理平台可以自研，也可以基于社区提供的
RocketMQ Console二次开发而来，或者直接使用社区提供的RocketMQ Console。
Namesrv集群 ：一个无状态的元数据管理，Namesrv之于RocketMQ 等价于Zookeeper之Kafka。
Broker 集群 ：消息中间商或消息代理。主要用于保存消息，处理生产者、消费者的各种请求的代理。包含Master和Slave两种角色，与 MySQL中的主从角色类似。
生产者集群 ：消息发送方，通常由一个或多个生产者实例组成。
消费者集群 ：消息接收方，通常由一个或多个消费者实例组成。
4.2 常用的部署拓扑和部署实践
4.2.1 常用的拓扑图
常用的RocketMQ的部署拓扑方式有5种，不同的部署方式可靠性不同，大家在公司落地部署时，可以根据企业业务的需求进行选择，或者有新的部署方式也可以分享给笔者和RocketMQ社区。
一个基本部署拓扑中至少包含Console管理平台、Namesrv和 Broker，下面将逐一介绍。
Namesrv部署： 推荐一个集群并部署2～3个Namesrv节点。
Broker部署： 目前笔者已知的Broker有5种部署方式，下面会详细讲解。
第一种：单 Master。“集群”中只有一个节点，宕机后不可用。
通常用于个人入门学习，比如测试发送消息代码、测试消费消息代码等，建议在生产环境中不要使用这种部署方式。
第二种：单 Master，单 Salve。单主从模式，Master 宕机后集群不可写入消息，但可以读取息。通常用于个人深入学习，比如研究源码、设计原理等，建议在生产环境中不要使用这种部署方式。
第三种：多 Master，无 Salve。该种部署方式性能最好，并且当单个 Master 节点宕机时，不影响正常使用。
第四种：多Master、多Slave，异步复制。在第三种方式上增加了Slave，当一个Master节点宕机时，该Master不能写入消息，消费可以在其对应的Slave上进行。新消息的生产、消费不受影响。添加Salve后，消费者可以从对应的Slave中读取已发送到宕机Master中的消息。 生产环境中可以使用这种部署方式。
第五种：多 Master、多 Slave，同步复制。这种部署方式完全解决了第四种部署方式的弊端，虽然由于Master-Salve同步复制导致发送消息耗时增加，集群性能大大下降，但是这仍然是最可靠的部署方式。生产环境中可以使用这种部署方式。
4.2.2 同步复制、异步复制和同步刷盘、异步刷盘在实际部署集群时，RocketMQ 中有两组概念需要搞清楚：同步复制、异步复制和同步刷盘、异步刷盘。图4-2展示了两组概念的基本含义。
复制是指Broker与Broker之间的数据同步方式。分为同步和异步两种，同步复制时，生产者会等待同步复制成功后，才返回生产者消息发送成功；异步复制时，消息写入Master Broker后即为写入成功，此时系统有较低的写入延迟和较大的系统吞吐量。
刷盘是指数据发送到Broker的内存（通常指PageCache）后,以何种方式持久化到磁盘。同步刷盘时，生产者会等待数据持久化到磁盘后，才返回生产者消息发送成功，可靠性极强；异步刷盘时，消息写入PageCache即为写入成功，到达一定量时自动触发刷盘。此时系统有非常低的写入延迟和非常大的系统吞吐量。
在企业中实际使用时，要结合业务自身的属性合理配置主从同步方式和刷盘方式。大部分场景下使用异步复制、异步刷盘即可满足。
4.2.3 部署实践
这里主要介绍部署2Namesrv+2Master+2Slave+1Console的过程
1.Namesrv部署
Namesrv部署可以按以下几个步骤进行。 第一步：修改Namesrv日志目录和Namesrv启动配置文件。
日志配置文件目录：./conf/logback_namesrv.xml。Namesrv启动配置文件目录：./conf/namesrv.conf。
第二步：启动Namesrv，启动命令如下。
第三步：验证启动结果。
查看 Namesrv的日志文件 namesrv.log的内容，如果内容包含The Name Server boot success.serializeType=XXX，则说明启动成功。
2.Master Broker部署
第一步：修改日志配置文件，保存目录和启动配置文件。
日志配置文件路径：./conf/logback_broker.xml。
启动配置文件路径：./conf/broker.conf。启动配置项很多，这里我们只挑选几个常用的配置项进行讲解。
brokerName=broker-1-master： Broker名字，主从Broker名字须一致。
brokerId=0 ：0代表master，1代表slave。
brokerRole=ASYNC_MASTER： 表示主从Broker异步复制。 namesrvAddr=127.0.0.1：9876：
Namesrv地址，如果是多个地址，则用分号隔开。
flushDiskType=ASYNC_FLUSH： 保存消息刷盘策略（同步或异步）。
fileReservedTime=72： 保存多少小时。
deleteWhen=01： 过期数据每天凌晨一点删除。
autoCreateTopicEnable=false： 是否可以自动创建Topic，生产环境不要打开。
storePathCommitLog=/data/RocketMQ/commitlog: commitlog 数据保存路径,目前只能设置一个。
storePathRootDir=/data/RocketMQ： 全部数据保存路径。
autoCreateSubscriptionGroup=false ： 是 否 自 动 创 建 消 费 者组。建议生产环境不要设置为False。
brokerClusterName=RocketMQ-cluster-1： 集群名字。
JVM参数配置如下：
./bin/runbroker.sh： 建议将-Xms和-Xmx配置为物理内存的1/3。 其他JVM参数建议保持不变。
os.sh： 这里面保存了RocketMQ认为最适合RocketMQ运行的一些系统参数。将su-admin-c′ulimit-n′中的admin修改为启动RocketMQ的用户后，执行os.sh脚本即可。
第二步：启动master，命令如下。
第三步：验证master启动结果。在Broker日志目录下会生成12个日志文件：
broker_default.log 、 broker.log 、 commercial.log 、 filter.log 、 lock.log 、 protection.log 、 remoting.log 、 stats.log 、 storeerror.log 、 store.log 、 transaction.log 、
watermark.log。
我们查看其中的broker.log文件，如果生成如下所示的内容，则说明启动成功。
3.Slave Broker部署
第一步：修改日志配置文件，保存目录和启动配置文件，修改启动配置文件中的两个配置项为：brokerId=1，brokerRole=SLAVE，其他配置项建议和Master Broker保持一致。
第二步、第三步：与Master Broker完全一致。
4.部署社区版RocketMQ Console管理平台
第一步：启动配置文件修改。RocketMQ Console是一个Springboot 项目，其配置文件是application.properties，具体修改配置项如下：
