一、RocketMQ 存储机制详解
1.1 存储文件结构
RocketMQ 的存储文件主要分布在store目录下，该目录是在broker.conf配置文件中通过storePathRootDir参数指定的，默认路径为${user.home}/store 。主要包含以下几种关键文件类型：
1.1.1 CommitLog 文件：所有主题的消息都顺序存储在 CommitLog 文件中，它是 RocketMQ 消息存储的核心。每个 CommitLog 文件默认大小为 1G，文件名以该文件创建时第一条消息的偏移量命名，如00000000000000000000。消息在 CommitLog 中以固定格式存储，包含消息长度、CRC 校验码、消息体等信息。这种顺序存储方式极大地提高了磁盘的写入性能。
1.1.2 ConsumeQueue 文件：ConsumeQueue 是消息消费队列的存储文件，每个 Topic 的每个 Queue 都对应一个 ConsumeQueue 文件。它起到索引的作用，存储了消息在 CommitLog 中的物理偏移量、消息大小、Tag 的哈希值等信息。通过 ConsumeQueue，Consumer 可以快速定位到消息在 CommitLog 中的位置，从而实现高效的消息拉取。ConsumeQueue 文件默认大小约为 600W 条消息，文件名同样以偏移量命名。
1.1.3 IndexFile 文件：IndexFile 用于实现消息的快速检索，主要为了满足根据消息 Key 或时间范围查询消息的需求。它存储了消息的 Key、CommitLog 偏移量、时间戳等信息，并构建了 Hash 索引。每个 IndexFile 文件固定大小为 400M，文件名以创建时的时间戳命名。
1.1.4 Checkpoint 文件：Checkpoint 文件记录了 CommitLog、ConsumeQueue 和 IndexFile 的最后更新时间戳，用于 Broker 重启时进行数据恢复，确保数据的一致性和完整性。
1.1.5 Abort 文件：Abort 文件是一个标识文件，当 Broker 正常关闭时，该文件会被删除；如果 Broker 异常退出，Abort 文件会保留，用于指示 Broker 下次启动时需要进行数据恢复操作。
1.2 消息写入原理
1.2.1 Producer 发送消息：Producer 将消息发送到 Broker，Broker 接收到消息后，首先会对消息进行校验，如检查消息大小、Topic 是否存在等。
1.2.2 写入 CommitLog：校验通过后，消息会被顺序写入 CommitLog 文件。在写入过程中，会为消息分配唯一的偏移量，同时计算 CRC 校验码，确保消息的完整性。由于 CommitLog 采用顺序写入，充分利用了磁盘的顺序读写特性，大大提高了写入效率。
1.2.3 更新 ConsumeQueue：消息写入 CommitLog 成功后，Broker 会根据消息所属的 Topic 和 Queue，更新对应的 ConsumeQueue 文件。在 ConsumeQueue 中，记录该消息在 CommitLog 中的偏移量等信息，为 Consumer 拉取消息提供索引。
1.2.4 更新 IndexFile（可选）：如果消息设置了 Key，Broker 会将消息的 Key、CommitLog 偏移量等信息写入 IndexFile，构建 Hash 索引，以便后续根据 Key 进行快速查询。
1.3 消息读取原理
1.3.1 Consumer 请求消息：Consumer 向 Broker 发送拉取消息的请求，请求中包含 Topic、Queue 等信息。
1.3.2 查询 ConsumeQueue：Broker 接收到请求后，根据 Topic 和 Queue 找到对应的 ConsumeQueue 文件，从 ConsumeQueue 中读取消息在 CommitLog 中的偏移量和消息大小等信息。
1.3.3 读取 CommitLog：根据 ConsumeQueue 中获取的偏移量，从 CommitLog 文件中读取完整的消息数据。在读取过程中，会验证 CRC 校验码，确保消息的正确性。
1.3.4 返回消息给 Consumer：Broker 将读取到的消息返回给 Consumer，Consumer 接收到消息后进行业务处理。
二、CentOS 7 下 RocketMQ 存储相关配置
2.1 配置文件修改
在 CentOS 7 上，RocketMQ 的主要配置文件为broker.conf，位于 RocketMQ 安装目录的conf文件夹下。以下是一些与存储相关的重要配置参数及其修改说明：
1、存储路径配置：
storePathRootDir=/home/rocketmq/store
storePathCommitLog=/home/rocketmq/store/commitlog
storePathConsumeQueue=/home/rocketmq/store/consumequeue
storePathIndex=/home/rocketmq/store/index
storeCheckpoint=/home/rocketmq/store/checkpoint
abortFile=/home/rocketmq/store/abort上述配置分别指定了 RocketMQ 各类存储文件的根目录、CommitLog 文件目录、ConsumeQueue 文件目录、IndexFile 文件目录、Checkpoint 文件路径以及 Abort 文件路径。可根据实际磁盘空间和业务需求调整这些路径，例如将存储文件分散到不同的磁盘分区，以提高 I/O 性能。
2、刷盘机制配置：
flushDiskType=ASYNC_FLUSH
# 或
# flushDiskType=SYNC_FLUSHflushDiskType参数用于设置刷盘方式，有ASYNC_FLUSH（异步刷盘）和SYNC_FLUSH（同步刷盘）两种模式。异步刷盘时，消息写入内存后立即返回成功响应，由后台线程定期将内存中的数据刷入磁盘，这种方式写入性能高，但存在数据丢失风险；同步刷盘则是在消息写入磁盘后才返回成功响应，保证了数据的可靠性，但会降低写入性能。
3、文件大小配置：
mapedFileSizeCommitLog=1073741824
mapedFileSizeConsumeQueue=30000000mapedFileSizeCommitLog用于设置 CommitLog 文件的大小，默认值为 1G（1073741824 字节）；mapedFileSizeConsumeQueue用于设置 ConsumeQueue 文件的大小，默认约为 30M（30000000 字节）。可根据实际业务量和磁盘空间调整这些参数，例如业务消息量较大时，适当增大 CommitLog 文件大小，减少文件切换频率。
2.2 命令操作
1、查看存储文件状态：可通过查看store目录下的文件及相关日志，了解存储文件的状态。例如，查看 CommitLog 文件的内容（不建议直接查看二进制文件，可通过日志辅助分析）：
ls -l /home/rocketmq/store/commitlog2、重启 Broker 使配置生效：修改broker.conf配置文件后，需要重启 Broker 才能使配置生效。先停止 Broker：
sh mqshutdown broker再重新启动 Broker：
nohup sh mqbroker -c conf/broker.conf &三、RocketMQ 性能优化策略
3.1 刷盘机制优化
1、根据业务场景选择刷盘方式：对于可靠性要求极高的业务，如金融交易，应选择SYNC_FLUSH同步刷盘方式，确保消息不丢失；对于对性能要求较高，可容忍一定数据丢失风险的业务，如日志记录，可采用ASYNC_FLUSH异步刷盘方式，提升写入性能。
2、调整异步刷盘参数：如果采用异步刷盘，可通过调整flushCommitLogLeastPages和flushCommitLogThoroughInterval参数优化刷盘性能。flushCommitLogLeastPages表示每次异步刷盘时，内存中至少积累的页数（默认为 4 页）；flushCommitLogThoroughInterval表示强制刷盘的时间间隔（单位为毫秒，默认值为 1000 * 60 * 5，即 5 分钟）。可根据实际业务量，适当减小flushCommitLogLeastPages，缩短flushCommitLogThoroughInterval，以提高数据刷盘的及时性。
3.2 文件存储优化
1、合理设置文件大小：根据业务消息量和磁盘空间，合理调整 CommitLog 和 ConsumeQueue 文件的大小。避免文件过大导致查询效率降低，或文件过小频繁切换文件带来的性能开销。例如，对于消息量较小且消息生命周期较短的业务，可适当减小 ConsumeQueue 文件大小。
2、分散存储路径：将 CommitLog、ConsumeQueue、IndexFile 等存储文件分散到不同的磁盘分区或物理磁盘上，减少 I/O 竞争，提高读写性能。在broker.conf中修改存储路径配置实现。
3.3 内存映射优化
RocketMQ 采用内存映射（mmap）技术，将文件映射到内存中，减少数据在用户态和内核态之间的拷贝，提高读写效率。可通过调整系统参数vm.max_map_count来优化内存映射性能。在 CentOS 7 上，使用以下命令临时调整该参数：
sysctl -w vm.max_map_count=655300如需永久生效，可修改/etc/sysctl.conf文件，添加或修改：
vm.max_map_count=655300然后执行sysctl -p使配置生效。
3.4 其他优化措施
1、负载均衡：合理配置 Producer 和 Consumer 的负载均衡策略，避免单个 Broker 负载过高。例如，Producer 可采用轮询等方式将消息发送到不同的 Broker，Consumer 可根据消费能力动态分配消息队列。
2、定期清理过期数据：对于不再需要的消息，可通过设置消息的过期时间（在发送消息时设置maxTimeToLive参数），让 Broker 自动清理过期数据，减少存储压力。