RocketMQ 高可用设计之主从复制和读写分离
RocketMQ 高可用设计之主从复制和读写分离
主从复制
RocketMQ 为了提高消费的高可用性,避免 Broker 发生单点故障引起 Broker 上的消息无法及时消费,同时避免单个机器上硬盘坏损出现消费数据丢失。
RocketMQ 采用 Broker 数据主从复制机制,当消息发送到 Master 服务器后会将消息同步到 Slave 服务器,如果 Master 服务器宕机,消息消费者还可以继续从 Slave 拉取消息。
消息从 Master 服务器复制到 Slave 服务器上,有两种复制方式:同步复制 SYNC_MASTER 和异步复制 ASYNC_MASTER。
通过配置文件 conf/broker.conf 文件配置:
对 brokerRole 参数进行设置。
同步复制:Master 和 Slave 都写成功后才返回客户端写成功的状态。
优点:Master 服务器出现故障,Slave 服务器上有全部数据的备份,很容易恢复到 Master 服务器。
缺点:由于多了一个同步等待的步骤,增加数据写入延迟,降低系统吞吐量。
异步复制:仅 Master 服务器写成功即可返回给客户端写成功的状态。
优点:没有同步等待的步骤,低延迟,高吞吐。
缺点:如果 Master 服务器出现故障,有些数据可能未写入 Slave 服务器,未同步的数据可能丢失
实际应用中,需要结合业务场景,合理设置刷盘方式和主从复制方式。不建议使用同步刷盘方式,因为它频繁触发写磁盘操作,性能下降很明显。**通常把 Master 和 Slave 设置为异步刷盘,同步复制,保证数据不丢失。**这样即使一台服务器出故障,仍然可以保证数据不丢失。
读写分离
读写分离机制是高性能、高可用架构中常见的设计,例如 Mysql 实现读写分离机制,Client 只能从 Master 服务器写数据,可以从 Master 服务器和 Slave 服务器都读数据。
RocketMQ 的 Consumer 在拉取消息时,Broker 会判断 Master 服务器的消息堆积量来决定 Consumer 是否从 Slave 服务器拉取消息消费。默认一开始从 Master 服务器拉群消息,如果 Master 服务器的消息堆积超过物理内存 40%,则会返回给 Consumer 的消息结果并告知 Consumer,下次从其他 Slave 服务器上拉取消息。
这就是 RocketMQ 高可用设计之主从复制和读写分离,希望对你有帮助。如果你觉得这篇文章还不错的话,欢迎给我留言点赞,奥利给。
版权声明: 本文为 InfoQ 作者【周杰伦本人】的原创文章。
原文链接:【http://xie.infoq.cn/article/5c2910d52540a8fb7c76a6a80】。文章转载请联系作者。
评论