RabbitMQ高可用
RabbitMQ高可用
- 各种消息队列对比
- 使用推荐
- RabbitMQ 高可用
- 普通集群模式
- 镜像集群模式
- 保证消息队列的幂等性(消息不被重复消费)
- 消息队列的可靠性传输
- 生产者丢失数据
- RabbitMQ丢失数据
- 消费者丢失数据
- 保证消息的顺序性
- 消息积压问题
各种消息队列对比
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 单机吞吐量 | 万级, 吞吐量比RocketMQ和Kafka要低一个数量级 | 万级, 吞吐量比RocketMQ和Kafka要第一个数量级 | 10万级, RocketMQ也是可以支撑高吞吐的一种MQ | 10万级别, 这是Kafka最大的优点, 就是吞吐量搞, 一般配合大数据类的系统来进行实时数据计算, 日志采集等场景 |
| 可用性 | 高, 基于主从架构实现高可用性 | 高, 基于主从架构实现高可用性 | 非常高, 分布式架构 | 非常高, Kafka是分布式的, 一个数据多个副本, 少数机器宕机, 不会丢失数据, 不会导致不可用 |
| 消息可靠性 | 有较低的概率丢失数据 | 经过参数优化配置, 可以做到 0 丢失 | 经过参数优化配置, 消息可以做到 0 丢失 | |
| 时效性 | ms 级 | 微秒级, 这是RabbitMQ的一大特点, 延迟是最低的 | ms 级 | 延迟在 ms 级以内 |
| 功能支持 | MQ 领域的功能及其完备 | 基于 erlang 语言开发, 所有并发能力强, 性能极其好, 延迟很低 | MQ 功能较为完善, 还是分布式的, 扩展性好 | 功能较为简单, 主要支持简单的MQ 功能, 在大数据领域的实时计算以及日志采集被大规模使用, 是事实上的标准 |
| 优劣势总结 | 非常成熟, 功能强大, 在业内大量的公司以及项目中都有应用. 偶尔会出现较低概率丢失消息, 而现在社区以及国内应用都越来越少, 官方社区现在对ActiveMQ5.x 维护越来越少, 几个月才发布一个版本而且缺少主要是基于解耦和异步来用的, 较少在大规模吞吐的场景中使用 | erlang 语言开发, 性能极其好, 延迟很低, 吞吐量到万级, MQ功能比较完备而且开源提供的管理界面非常棒, 用起了很好用, 社区相对比较活跃, 几乎每个月都会发布几个版本, 在国内一些互联网公司近几年用RabbitMQ也比较多, 但问题也显而易见, RabbitMQ确实吞吐量会低一些, 这是因为事先机制比较中, 而且 erlang 开发, 国内有实例做 erlang 源码基本的研究和定制不多, 基本只能依赖于开源社区的快速维护和修复bug, 而且 RabbitMQ集群动态扩展会比较麻烦. | 接口简单易用, 而且在阿里大规模应用过, 日处理消息上百亿, 可以做到大规模吞吐, 性能也非常好, 分布式扩展也很方便, 社区维护还可以, 可靠性和可用性都是OK的, 还可以支撑大规模的topic数量, 支撑复杂MQ业务场景, java语音开发, 可以自己阅读源码,进行定制化开发,社区活跃度相对较为一般, 文档简单, 接口不是按照标准 JMS 官方走的, 有些系统要迁移需要修改大量代码. | Kafka 的特点很明显, 就是仅仅提供较少的核心功能, 但是提供超高的吞吐量, ms 级的延迟, 极高的可用性以及可靠性, 而且分布式可以任意扩展, 同事Kafka最好是支撑较少的 topic 数量即可. 保证超高吞吐量, 唯一劣势是有可能消息重复消费, 对数据准确性会造成极其轻微的影响. 在大数据领域中以及日志采集中, 这点轻微影响可以忽略这个特性, 天然适合大数据实时计算以及日志收集 |
使用推荐
- ActiveMQ 没有经历过大规模吞吐量场景验证, 社区也不是很活跃, 不推荐
- RabbitMQ 有比较稳定的支持, 社区活跃度搞, 中小型公司推荐
- RocketMQ 阿里出品,社区活跃度没有 RabbitMQ 搞, 需要二次开发, 推荐大型公司使用
- Kafka 大数据领域的业内标准, 实时计算, 日志采集等
RabbitMQ 高可用
- 单机模式
- 普通集群模式
- 镜像集群模式(高可用)
普通集群模式
在多台机器上启动多个RabbitMQ实例,每个机器启动一个创建queue只会放在一个RabbitMQ实例上, 但是每个实例都会同步queue的元数据, 消费的时候, 实际上如果连接通道另一个实例, 呢么就会从queue所在的实例上去拉取数据, 如果那个放queue的实例宕机了, 就会导致其他实例无法从这个实例上拉取实际, 这个方案主要是提高吞吐量, 就是让集群中多节点来服务耨个queue的读写操作
镜像集群模式
该模式才是高可用模式, 在镜像集群模式下, 创建的queue会存在多个实例, 每个节点都会有一份万总的queue镜像, 每次写消息到queue时, 会自动把消息同步到多个实例的queue上.开启该模式就是新增一个镜像集群模式策略
好处: 任何一个机器宕机, 可以到其他节点去消费数据
坏处: 性能开销太大, 需要同步到所有集群, 不是分布式的
保证消息队列的幂等性(消息不被重复消费)
结合业务分析
- 比如拿个数据要写库, 先根据主键查询, 如果该数据已存在, 就不插入, 而是进行修改
- 如果是写入Redis, 那就没问题, 因为每次set天然幂等性
- 如果需要让生产者发送每天数据的时候, 里面加一个全局唯一 ID, 到消费这里, 先根据这个id去查询判断之前是否有过消费, 如果没有消费那就进行处理, 如果消费过就不进行处理
- 基于数据的唯一键来保证重复数据不会重复插入多条, 有了唯一键约束, 重复数据插入会报错, 不会导致脏数据出现
消息队列的可靠性传输
生产者丢失数据
事务机制
使用RabbitMQ的事务功能, 在生产者发送数据之前开启RabbitMQ事务,然后发送消息, 如果消息没有发送成功被RabbitMQ接收到, 那么生产者会收到异常报错, 此时就可以回滚事务, 然后重试发送. 如果收到可以提交事务就可以提交事务. 缺点是吞吐量会下来, 太耗性能
confirm 机制
还可以开启 confirm 模式, 每次写的消息都会被分配一个唯一id, 然后写入 RabbitMQ 中, RabbitMQ 会回传一个 ack 消息, 告诉你消息OK了, 如果 RabbitMQ 没有处理这个消息, 会回调 nack 接口, 告诉你消息接收失败, 可以重试
事务机制和 confirm 机制区别
- 事务是同步的, 提交一个事务后会阻塞在那
- confirm 机制是异步的, 发送这个消息后就可以发送下一个消息, 然后 RabbitMQ接收后会异步回调接口通知消息已接收
一般推荐使用 confirm 机制
RabbitMQ丢失数据
开启RabbitMQ的持久化, 恢复之后会自动读取之前存储的数据, 一般不会丢失数据, 除非RabbitMQ还没完成持久化就挂了, 可能会丢失少量数据, 概率太小
设置持久化步骤
- 创建queue时将其设置为持久化, 保证 queue的元数据, 但是不会持久化queue里的数据
- 发送消息的时候将消息的 deliverMode 设置为 2 . 就是持久化消息
必须同时设置上面两个才能持久化, 还可以跟生产者那边的 confirm 机制配合, 只有消息被持久化到磁盘后才通知生产者 ack
消费者丢失数据
消费者刚拿到数据, 还没开始处理系统就挂了
可以使用 RabbitMQ 提供的 ack机制, 关闭RabbitMQ的自动ack, 在处理完后手动ack, 没手动确认ack的话, RabbitMQ会认为还没处理完, 消息是不会丢失的
保证消息的顺序性
才分多个queue, 每个queue对应一个消费者, 然后在这个消费者内用内存队列排队, 然后分给不同的worker来处理
消息积压问题
- 仅仅是消费者消费速度落后于生产速度, 可以扩容消费者群组
- 积压严重
- 修复现有消费者问题,然后停掉
- 重新创建一个容量更大topic, 比如分区是原来的10倍
- 编写一个临时消费者程序, 消费来源积压的队列, 不做任何耗时处理, 将消息均写入新创建的队列中
- 将修复好的消费者部署到原来10倍的机器上消费新队列
- 解决后恢复原有架构
- 消息有过期失效机制, 已经丢失大量数据, 只能将丢失的数据写入程序查询出来后重新写入MQ中
RabbitMQ高可用相关推荐
- RabbitMQ学习系列（六）: RabbitMQ 高可用集群
前面讲过一些RabbitMQ的安装和用法,也说了说RabbitMQ在一般的业务场景下如何使用.不知道的可以看我前面的博客,http://www.cnblogs.com/zhangweizhong/ca ...
- RabbitMQ高可用集群搭建
RabbitMQ高可用集群搭建 摘要:实际生产应用中都会采用消息队列的集群方案,如果选择RabbitMQ那么有必要了解下它的集群方案原理一般来说,如果只是为了学习RabbitMQ或者验证业务工程的正确 ...
- RabbitMQ:使用Docker构建RabbitMQ高可用负载均衡集群
目录 一.构建RabbitMQ集群 1. 启动多个RabbitMQ节点 2. 加入集群 3. 配置镜像队列 二.HAProxy负载均衡 1. 安装HAProxy 2. 配置HAProxy 3. 启动 ...
- RabbitMQ高可用--Quorum Queue(仲裁队列)的用法
原文网址:RabbitMQ高可用--Quorum Queue(仲裁队列)的用法_IT利刃出鞘的博客-CSDN博客 简介 说明 本文介绍RabbitMQ的Quorum Queue(仲裁队列)的用法. 官 ...
- RabbitMQ 高可用集群搭建
RabbitMQ 高可用集群搭建 1 集群简介 1.1 集群架构 当单台 RabbitMQ 服务器的处理消息的能力达到瓶颈时,此时可以通过 RabbitMQ 集群来进行扩展,从而达到提升吞吐量的目 ...
- RabbitMQ高可用方案总结
RabbitMQ的集群方案有以下几种: 1.普通的集群 exchange,buindling再所有的节点上都会保存一份,但是queue只会存储在其中的一个节点上,但是所有的节点都会存储一份queu ...
- RabbitMQ 高可用集群搭建及电商平台使用经验总结
面向EDA(事件驱动架构)的方式来设计你的消息 AMQP routing key的设计 RabbitMQ cluster搭建 Mirror queue policy设置 两个不错的RabbitMQ p ...
- RabbitMQ 高可用之镜像队列
如果RabbitMQ集群只有一个broker节点,那么该节点的失效将导致整个服务临时性的不可用,并且可能会导致message的丢失(尤其是在非持久化message存储于非持久化queue中的时候).可 ...
- 企业私有云之rabbitmq高可用
默认openstack使用rabbitmq做信息队列,如果想是云高可用,那么需要对每个涉及的组件都进行高可用配置,本文主要介绍如何使用rabbitmq做高可用. 高可用的方法为: 1 2 通过 Erl ...
最新文章
- Linux常用20条命令
- python selenium 点击开始按钮_使用Selenium和Python单击一个按钮
- 爱立信与中国联通成功完成国内首个LTE三载波聚合大规模部署测试
- 用jar 命令打包war包
- php session 全局,PHP超级全局变量——Session 变量
- bzoj1180: [CROATIAN2009]OTOCI
- 又双叒叕是一个动态简历
- 带你换个角度理解图卷积网络
- 关于C++的建议，仅仅为了规范代码(一)
- Linux安装weblogic报错“u01/app/oraInventory/“ cannot read/execute
- 【操作系统】时间片轮转调度法
- iOS软键盘弹出后视图向上移动
- 纹波(ripple）--学习笔记
- idea弹窗 Placing the unmodified important.txt in the zip file with the agent jar in the same directo
- 【Linux】进程通信
- [JSOI2009]有趣的游戏
- word2016论文不同章节设置页眉页码方法
- Twitter的网页代码
- 使用Eric构建使用Caffe应用程序
- python生成迁移文件