您的位置: 首页  >  文章  >  RocketMQ部署及刷盘机制

RocketMQ部署及刷盘机制

分类: 文章 • 2025-04-05 18:53:52

RocketMQ部署结构

RocketMQ部署及刷盘机制

RocketMQ关键特性

RocketMQ部署及刷盘机制

(1). 所有数据单独存储到一个 Commit Log，完全顺序写，随机读。

(2). 对最终用户展现的队列实际只存储消息在CommitLog的位置信息，并且串行方式刷盘。

这样做的好处如下:
(1). 队列轻量化，单个队列数据量非常少。
(2). 对磁盘的访问串行化，避免磁盘竟争，不会因为队列增加导致IOWAIT增高。

每个方案都有缺点，它的缺点如下:
(1). 写虽然完全是顺序写，但是读却变成了完全的随机读。
(2). 读一条消息，会先读ConsumeQueue，再读CommitLog，增加了开销。 (3). 要保证CommitLog与ConsumeQueue完全的一致，增加了编程的复杂度。

以上缺点如何克服:

  1. (1).  随机读，尽可能让读命中 PAGECACHE，减少 IO 读操作，所以内存越大越好。如果系统中堆积的消息过多，

    读数据要访问磁盘会不会由于随机读导致系统性能急剧下降，答案是否定的。

    另外 4k 的消息在完全随机访问情况下，仍然可以达到 8K 次每秒以上的读性能。

    1. a)  访问 PAGECACHE 时，即使只访问 1k 的消息，系统也会提前预读出更多数据，在下次读时，就可能命

      中内存。

    2. b)  随机访问 Commit Log 磁盘数据，系统 IO 调度算法设置为 NOOP 方式，会在一定程度上将完全的随机

      读变成顺序跳跃方式，而顺序跳跃方式读较完全的随机读性能会高 5 倍以上，可参见以下针对各种 IO

      方式的性能数据。

      http://stblog.baidu-tech.com/?p=851

  2. (2).  由于ConsumeQueue存储数据量极少，而且是顺序读，在PAGECACHE预读作用下，ConsumeQueue的读

    性能几乎与内存一致，即使堆积情况下。所以可认为 Consume Queue 完全不会阻碍读性能。

  3. (3).  Commit Log 中存储了所有的元信息，包含消息体，类似于 Mysql、Oracle 的 redolog，所以只要有 Commit

    Log 在，Consume Queue 即使数据丢失，仍然可以恢复出来。

刷盘策略

RocketMQ 的所有消息都是持久化的，先写入系统 PAGECACHE，然后刷盘，可以保证内存与磁盘都有一份数据， 访问时，直接从内存读取。

异步刷盘

在有 RAID 卡，SAS 15000 转磁盘测试顺序写文件，速度可以达到 300M 每秒左右，而线上的网卡一般都为千兆 网卡，写磁盘速度明显快于数据网络入口速度，那么是否可以做到写完内存就向用户返回，由后台线程刷盘呢?

  1. (1).  由于磁盘速度大于网卡速度，那么刷盘的进度肯定可以跟上消息的写入速度。

  2. (2).  万一由于此时系统压力过大，可能堆积消息，除了写入 IO，还有读取 IO，万一出现磁盘读取落后情况，

        会不会导致系统内存溢出，答案是否定的，原因如下:

        综上，内存溢出的情况不会出现。

    1. a)  写入消息到 PAGECACHE 时，如果内存不足，则尝试丢弃干净的 PAGE，腾出内存供新消息使用，策略

      是 LRU 方式。

    2. b)  如果干净页不足，此时写入 PAGECACHE 会被阻塞，系统尝试刷盘部分数据，大约每次尝试 32 个 PAGE，

      来找出更多干净 PAGE。

同步刷盘

同步刷盘与异步刷盘的唯一区别是异步刷盘写完 PAGECACHE 直接返回，而同步刷盘需要等待刷盘完成才返回， 同步刷盘流程如下:

(1). 写入 PAGECACHE 后，线程等待，通知刷盘线程刷盘。 (2). 刷盘线程刷盘后，唤醒前端等待线程，可能是一批线程。 (3). 前端等待线程向用户返回成功。

 

RocketMQ 在单点故障情况下，通过异步复制，可保证99%的消息不丢，但是仍然会有极少量的消息可能丢失。通过同步双写技术可以完全避免单点，同步双写势必会影响性能，适合对消息可靠性要求极高的场合，例如与 Money 相关的应用。

高可用性机制

如何达到发送端的高可用性呢?在创建 Topic 的时候，把 Topic 的多个 Message Queue创建在多个 Broker组上(相同 Broker名称，不同 brokerId 的 机器组成 一 个 Broker 组)，这样当 一 个 Broker 组的 Master 不可用后，其他组 的 Master 仍然可用， Producer 仍然可以发送消息 。 RocketMQ 目前还不支持把 Slave 自动转成 Master，如果机器资源不足，需要把 Slave 转成 Master，则要手 动停止 Slave角色的 Broker，更改配置文件，用新的配置文件启动 Broker。

同步刷盘和异步刷盘、同步复制和异步复制

实际应用中要结合业务场景，合理设置刷盘方式和主从复制方式，尤其是 SYNC FLUSH 方式，由于频 繁 地触发磁盘 写动 作， 会明显 降低性能 。 通常情 况下，应该把 Master和 Save配置成 ASYNC FLUSH 的刷盘方式，主从之间配 置成 SYNC MASTER 的 复制方式，这 样即使有 一台机器出故障， 仍然能保证 数据不丢，是个不错的选择 。

 

消息过滤

RocketMQ还可以通过 Tag 进行过滤、用 SQL 表达式的方式进行过滤、Filter Server方式过滤三种过滤方式从Broker端对数据进行过滤后达到消费的目的。

 

Topic下默认是4个队列

/**
 * Number of queues to create per default topic.
 */
private volatile int defaultTopicQueueNums = 4;

 

相关推荐