本文已参与「新人创作礼」活动，一起开启掘金创作之路。
前言
RocketMQ对于JAVA程序员来说应该都不陌生，RocketMQ是一款由阿里巴巴开源出来的一款消息中间件，各个大厂基本上都在用的这么一个中间件，其优点自不必言说，所以今天就不给大家来剖析RocketMQ了。
我们来分享点不一样的，相信大家在用RocketMQ时或多或少都会遇到一些问题，而比较常见的就是当其报错或配置一个参数时，往往一些新手就会懵逼这是啥意思呀，不知道如何处理。所以小编在这里整理了一份《RocketMQ全部参数配置表》，帮助大家来更好的使用RocketMQ。
废话不多说直接上干货。
1 、 Broker 配置 ![]()
| 参数名 | 默认值 | 说明 |
|---|---|---|
| listenPort | 10911 | 接受客户端连接的监听端口 |
| namesrvAddr | null | nameServer 地址 |
| brokerIP1 | 网卡的 InetAddress | 当前 broker 监听的 IP |
| brokerIP2 | 跟 brokerIP1 一样 | 存在主从 broker 时， 如果在 broker 主节点上配置了 brokerIP2 属性， broker 从 节点会连接主节点配置的 brokerIP2 进行同步 |
| brokerName | null | broker 的名称 |
| brokerClusterName | DefaultCluster | 本 broker 所属的 Cluser 名称 |
| brokerId | 0 | broker id, 0 表示 master, 其他的正整数表示 slave |
| storePathCommitLog | $HOME/store/commitlog/ | 存储 commit log 的路径 |
| storePathConsumerQueue | $HOME/store/consumequeue/ | 存储 consume queue 的路径 |
| mappedFileSizeCommitLog | 1024 ***** 1024 ***** 1024(1G) | commit log 的映射文件大小 |
| deleteWhen | 04 | 在每天的什么时间删除已经超过文件保留时间的 commit log |
| fileReservedTime | 72 | 以小时计算的文件保留时间 |
| brokerRole | ASYNC_MASTER | SYNC_MASTER/ASYNC_MASTER/SLAVE |
| flushDiskType | ASYNC_FLUSH | SYNC_FLUSH/ASYNC_FLUSH SYNC_FLUSH 模式下的 broker 保证在收到确认生产 者之前将消息刷盘。 ASYNC_FLUSH 模式下的 broker 则利用刷盘一组消息的模 式， 可以取得更好的性能。 |
2 、客户端的公共配置
| 参数名 | 默认值 | 说明 |
|---|---|---|
| namesrvAddr | Name Server地址列表，多个NameServer地 址用分号隔开 | |
| clientIP | 本机IP | 客户端本机IP地址，某些机器会发生无法识别 客户端IP地址情况，需要应用在代码中强制指 定 |
| instanceName | DEFAULT | 客户端实例名称，客户端创建的多个 Producer、 Consumer实际是共用一个内部实 例（这个实例包含网络连接、线程资源等） |
| clientCallbackExecutorThreads | 4 | 通信层异步回调线程数 |
| pollNameServerInteval | 30000 | 轮询Name Server间隔时间，单位毫秒 |
| heartbeatBrokerInterval | 30000 | 向Broker发送心跳间隔时间，单位毫秒 |
| persistConsumerOffsetInterval | 5000 | 持久化Consumer消费进度间隔时间，单位毫 秒 |
3 、 Producer 配置 ![]()
| 参数名 | 默认值 | 说明 |
|---|---|---|
| producerGroup | DEFAULT_PRODUCER | Producer组名， 多个Producer如果属于一个应用， 发送同样 的消息， 则应该将它们归为同一组 |
| createTopicKey | TBW102 | 在发送消息时， 自动创建服务器不存在的topic， 需要指定 Key， 该Key可用于配置发送消息所在topic的默认路由。 |
| defaultTopicQueueNums | 4 | 在发送消息， 自动创建服务器不存在的topic时， 默认创建的队 列数 |
| sendMsgTimeout | 10000 | 发送消息超时时间， 单位毫秒 |
| compressMsgBodyOverHowmuch | 4096 | 消息Body超过多大开始压缩 （Consumer收到消息会自动解压 缩） ， 单位字节 |
| retryAnotherBrokerWhenNotStoreOK | FALSE | 如果发送消息返回sendResult， 但是sendStatus!=SEND_OK， 是否重试发送 |
| retryTimesWhenSendFailed | 2 | 如果消息发送失败， 最大重试次数， 该参数只对同步发送模式 起作用 |
| maxMessageSize | 4MB | 客户端限制的消息大小， 超过报错， 同时服务端也会限制， 所 以需要跟服务端配合使用。 |
| transactionCheckListener | 事务消息回查监听器， 如果发送事务消息， 必须设置 | |
| checkThreadPoolMinSize | 1 | Broker回查Producer事务状态时， 线程池最小线程数 |
| checkThreadPoolMaxSize | 1 | Broker回查Producer事务状态时， 线程池最大线程数 |
| checkRequestHoldMax | 2000 | Broker回查Producer事务状态时， Producer本地缓冲请求队 列大小 |
| RPCHook | null | 该参数是在Producer创建时传入的， 包含消息发送前的预处理 和消息响应后的处理两个接口， 用户可以在第一个接口中做一 些安全控制或者其他操作。 |
4 、 PushConsumer 配置 ![]()
| 参数名 | 默认值 | 说明 |
|---|---|---|
| consumerGroup | DEFAULT_CONSUMER | Consumer组名， 多个Consumer如果属于一个应用， 订阅同样的消息， 且消 费逻辑一致， 则应该将它们归为同一组 |
| messageModel | CLUSTERING | 消费模型支持集群消费和广播消费两种 |
| consumeFromWhere | CONSUME_FROM_LAST_OFFSET | Consumer启动后， 默认从上次消费的位置开始消费， 这包含两种情况： 一 种是上次消费的位置未过期， 则消费从上次中止的位置进行； 一种是上次消 费位置已经过期， 则从当前队列第一条消息开始消费 |
| consumeTimestamp | 半个小时前 | 只有当consumeFromWhere值为CONSUME_FROM_TIMESTAMP时才起作 用。 |
| allocateMessageQueueStrategy | AllocateMessageQueueAveragely | Rebalance算法实现策略 |
| subscription | 订阅关系 | |
| messageListener | 消息监听器 | |
| offsetStore | 消费进度存储 | |
| consumeThreadMin | 10 | 消费线程池最小线程数 |
| consumeThreadMax | 20 | 消费线程池最大线程数 |
| consumeConcurrentlyMaxSpan | 2000 | 单队列并行消费允许的最大跨度 |
| pullThresholdForQueue | 1000 | 拉消息本地队列缓存消息最大数 |
| pullInterval | 0 | 拉消息间隔， 由于是长轮询， 所以为0， 但是如果应用为了流控， 也可以设置 大于0的值， 单位毫秒 |
| consumeMessageBatchMaxSize | 1 | 批量消费， 一次消费多少条消息 |
| pullBatchSize | 32 | 批量拉消息， 一次最多拉多少条 |
5 、 PullConsumer 配置 ![]()
| 参数名 | 默认值 | 说明 |
|---|---|---|
| consumerGroup | DEFAULT_CONSUMER | Consumer组名， 多个Consumer如果属 于一个应用， 订阅同样的消息， 且消费逻 辑一致， 则应该将它们归为同一组 |
| brokerSuspendMaxTimeMillis | 20000 | 长轮询， Consumer拉消息请求在Broker 挂起最长时间， 单位毫秒 |
| consumerTimeoutMillisWhenSuspend | 30000 | 长轮询， Consumer拉消息请求在Broker 挂起超过指定时间， 客户端认为超时， 单 位毫秒 |
| consumerPullTimeoutMillis | 10000 | 非长轮询， 拉消息超时时间， 单位毫秒 |
| messageModel | BROADCASTING | 消息支持两种模式： 集群消费和广播消费 |
| messageQueueListener | 监听队列变化 | |
| offsetStore | 消费进度存储 | |
| registerTopics | 注册的topic集合 | |
| allocateMessageQueueStrategy | AllocateMessageQueueAveragely | Rebalance算法实现策略 |
6 Message 数据结构
| 字段名 | 默认****值 | 说明 |
|---|---|---|
| Topic | null | 必填，消息所属topic的名称 |
| Body | null | 必填，消息体 |
| Tags | null | 选填，消息标签，方便服务器过滤使用。目前只支持每个消息设 置一个tag |
| Keys | null | 选填，代表这条消息的业务关键词，服务器会根据keys创建哈希 索引，设置后，可以在Console系统根据Topic、 Keys来查询消 息，由于是哈希索引，请尽可能保证key唯一，例如订单号，商品 Id等。 |
| Flag | 0 | 选填，完全由应用来设置， RocketMQ不做干预 |
| DelayTimeLevel | 0 | 选填，消息延时级别， 0表示不延时，大于0会延时特定的时间才 会被消费 |
| WaitStoreMsgOK | TRUE | 选填，表示消息是否在服务器落盘后才返回应答。 |
结语
当然想要完全掌握RocketMQ记住这些肯定远远不够，在这小编为了帮助大家更好的学习也整理了一部分资料来帮助大家更快的上手《 RocketMQ集群搭建》《RocketMQ入门笔记》《RocketMQ安装》《MQ技术脑图》
喜欢的同学可以记得“点赞收藏关注” 最后祝大家早日升职加薪！！！
