RocketMQ 的下载及安装
便于个人学习,做个人记录使用
原文 移步 RocketMQ 的下载及安装 - 风止雨歇 - 博客园
一、MQ的比较
Kafka | RocketMQ | RabbitMQ | |
设计定位 | 系统间的数据管道,实时数据处理; 例如:收集日志、监控数据、网站活跃性跟踪、常规消息系统 | 非日志的可靠性消息传递; 例如:电商系统、订单、交易、消息推送、bin-log分发等 | 可靠消息传递;和 RocketMQ类似 |
成熟度 | 日志领域成熟 | 成熟 | 成熟 |
开发语言 | Scala | Java | Erlang |
支持协议 | 一套 自行设计的基于TCP的二进制协议 | 自定义的一套 | AMQP |
客户端语言 | C/C++、Python、Go、Erlang、Ruby等 | Java | Java、C++、Python、PHP等 |
持久化方式 | 磁盘 | 磁盘 | 内存、文件 |
集群管理 | Zookeeper | Name server | ------ |
选主方式 | 从 ISR 中选举一个 leader | 不支持自动选主; 通过设定 broker name、broker Id 实现;borker name 相同,borker id=0 时为 master,其他为 slave | 最早加入 集群的 Broker |
可用性 | 非常高 分布式、主从 | 非常高 分布式、主从 | 高 主从,采用镜像模式实现,数据量大时可能产生性能瓶颈 |
主从切换 | 自动切换 N个副本,允许N-1个时效,master时效后自动从 ISR 中选择一个主 | 不支持自动切换 master 时效后不能向 master 发消息,消费者大概 30s 感知到此事件,此后从 slave 消费;如果 master 无法恢复,异步复制时可能出现部分信息丢失 | 自动切换 最早加入的集群的节点为master;因为新加入的 slave 不会同步 master 之前的数据,所以可能出现部分数据丢失 |
数据可靠性 | 很好 支持生成者单条发送、同步刷盘、同步复制,但是这种场景下性能明显下降 | 很好 生成者单条发送,broker同步刷盘、异步刷盘、 同步双写,异步复制 | 好 生产者支持同步 / 异步ACK;支持队列数据持久化,镜像模式中支持主从同步 |
消息写入性能 | 非常好 每条10个字节测试:百万条/s; | 很好 每条10个字节测试:单机单borker约7w/s,单机3borker约12w/s | RAM 约为 RocketMQ的 1/2; Disk性能约为RokcetMQ的 1/3; |
性能稳定性 | 队列/分区 多时性能不稳定,明显下降; 消息堆积时性能稳定; 当单机的 topic 的数量超过 64 个,则性能下降特别厉害; | 队列较多、消息堆积时性能稳定; 单机的 队列数量支持 5w,topic 的增加不影响性能; | 消息堆积时性能不稳定,明显下降 |
复制备份 | 消息先写入 leader 的 log,follwers 从 leader 中 pull 到数据以后先 ACK leader,再写入 log; ISR 维护与 leader 同步的列表,落后太多的 follwer 被删除掉 | 同步双写 异步复制:slave 启动线程从 master 中拉数据 | 普通模式下不复制 镜像模式下:消息先到master,然后写入到 slave 上;入集群之前的消息不会被复制到新的 slave 上 |
消息投递实时性 | 毫秒级 具体由消费者轮询间隔时间决定 | 毫秒级 支持pull、push两种模式、延时通常在毫秒级 | 毫秒级 |
顺序消费 | 支持顺序消费 但是一台broker宕机后,就会产生消息乱序 | 支持顺序消费 在顺序消费场景下,消费失败时消费队列将会暂停 | 支持顺序消费 但是如果一个消息消费失败哦,此消息的顺序将会被打乱 |
定时消息 | 不支持 | 开源版本仅支持定时 Level | 不支持 |
事务消息 | 不支持 | 支持 | 不支持 |
Broker端消息过滤 | 不支持 | 支持 通过 tag 过滤,类似于 topic | 不支持 |
消息查询 | 不支持 | 支持 根据 messageId 查询 支持根据 mesageKey 查询消息 | 不支持 |
消息失败重试 | 不支持失败重试 offset存储在consumer中,无法保证 | 支持失败重试 offset 存储在 broker 中 | 支持失败重试 |
消息重新消费 | 支持通过修改 offset 来重新消费 | 支持按照时间来重新消费 | |
发送端负载均衡 | 可自由指定 | 可自由指定 | 需要单独 LoadBanlance |
消费方式 | consumer pull | consumer pull / broker push | broker push |
批量发送 | 支持 默认 producer 缓存、压缩,然后批量发送 | 不支持 | 不支持 |
消息清理 | 指定文件保存时间,过期删除 | 指定文件保存时间,过期删除 | 默认可用内存少于40%,触发GC,GC时找到两个相同的文件,合并right到left |
访问权限控制 | 无 | 无 | 类似于数据库,需要配置用户名和密码 |
管理后台 | 官网不提供;第三方开源管理工具可供使用 | 官网提供;rocketmq-dashboard | 官网提供;rabbitmq-admin |
管理后台的功能 | Kafka Web Conslole Broker列表;Kafka集群中 Topic列表; | Cluster、Topic、Connection、NameServer、MessageBroker、Offset、Consumer | OverView、Conections、channels、exchanges、queues、admin |
优点 | 1、高吞吐、低延迟、高可用、集群热扩展、集群容错上由很好的表现; 2、producer 端提供缓存、压缩功能,可节省性能,提高效率; 3、提供顺序消费能力; 4、提供多种客户端语言; 5、生态完善,在大数据处理方面有大量配套的设施; | 1、在高吞吐、低延迟、高可用上有非常好的表现;消息堆积时,性能也好; 2、api、系统设计都更加适合在业务处理场景; 3、支持多种消费方式; 4、支持 Broker 消息过滤; 5、支持事务; 6、提供消息顺序消费能力;Consumer 可以水平扩展,消费能力很强; 7、集群规模在 50 台左右,单日处理消息上百亿;经历过大数据量的考验,比较稳定可靠; | 1、在高吞吐量、高可用较前俩者有所不如; 2、支持多种客户端语言;支持AMQP协议; 3、由于 Erlang 语言的特性,性能也比较好;使用 RAM 模式时,性能很好; 4、管理界面较丰富,在互联网公司也有较大规模的应用; |
缺点 | 1、消费集群数目受到分区数目的限制; 2、单机topic多时,性能会明显降低; 3、不支持事务; | 1、相比于 Kafka,使用者较少,生态不够完善;消费堆积、吞吐率上也有所不如; 2、不支持主从自动切换,master 时效后,消费者要一定时间才能感知; 3、客户端只支持Java; | 1、Erlang 语言难度较大;集群不支持动态扩展; 2、不支持事务、消息吞吐能力有限; 3、消息堆积时,性能明显下降; |
二、RocketMQ 的安装
1、 下载 RocketMQ 的包;
1 |
|
2、 解压缩
1 |
|
3、配置环境变量
1 2 3 4 5 |
|
4、修改完后,让环境变量立即生效
1 |
|
5、修改 RocketMQ 使用的内存
rocketmq需要启动两个服务:
- name server:默认配置JVM使用的内存是4G;
- broker:默认配置JVM使用的内存是8G, 内存设置的过大,可能导致开发环境中内存不足,服务无法启动,可以通过适当降低两个服务的内存解决.
早期rocketmq使用的注册中心是zookeeper, 但由于它包含的功能过于强大, 而rocketmq使用zookeeper包含的内容过于丰富,导致我们在使用时往往需要搭建zookeeper的服务,以致后来rocketmq自己开发了符合自己应用场景的注册服务,name server和broker;
(1)修改name server内存256m;
1 2 3 4 5 6 7 8 9 10 |
|
(2)修改broker内存256m;
1 2 3 4 5 6 7 8 |
|
6、启动RocketMQ
(1)先启动name server;
1 2 3 4 5 6 7 8 |
|
(2)再启动broker;
1 2 3 4 5 6 7 8 9 10 11 |
|
Broker的配置说明:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
|
7、命令行快速验证
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
|
8、关闭RocketMQ服务
1 2 3 4 5 6 |
|
三、安装 RocketMQ-Dashboard
1、将代码下载下来,下载地址
1 |
|
2、解压之后,执行 mvn 进行打包;
1 |
|
3、运行 jar 包
1 |
|
4、访问管理界面
http://192.168.172.20:8080
四、集群搭建
Broker 的配置说明:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
准备2个虚拟机分别是虚拟机centos-node-01与centos-node-02,分别部署2个NameServer,并在每台机器上分别启动一个Master和一个Slave,互为主备,在主目录下的conf文件夹下提供了多种broker配置模式,分别有:2m-2s-async,2m-2s-sync,2m-noslave,可以以此为模版做如下配置:
1 2 3 |
|
1、配置192.168.241.198 Master和Slave
Master broker-m.conf配置如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
Slave broker-s.conf配置
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
启动mqnamesrv
1 |
|
启动broker Master
1 2 |
|
启动broker Slave
1 2 |
|
2、配置192.168.241.199 Master和Slave
Master broker-m.conf配置如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
slave broker-s.conf配置如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
启动mqnamesrv 与 mqbroker 启动流程同上。
集群启动后
1 2 |
|
测试
1 2 3 4 5 |
|
配置说明
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|