RocketMQ的一些特性 - 樵夫后院 - ITeye技术网站
博客分类：
原创文章，转载请注明出处：/blog/2091966
我想说，真tm蛋疼，2.0和3.0架构变化挺大的，nameserver有必要吗？zookeeper不是挺好的吗？
一 nameserver
相对来说，nameserver的稳定性非常高。原因有二：
1 nameserver互相独立，彼此没有通信关系，单台nameserver挂掉，不影响其他nameserver，即使全部挂掉，也不影响业务系统使用，这点类似于dubbo的zookeeper。
2 nameserver不会有频繁的读写，所以性能开销非常小，稳定性很高。
1 与nameserver关系
单个broker和所有nameserver保持长连接
心跳间隔：每隔30秒（此时间无法更改）向所有nameserver发送心跳，心跳包含了自身的topic配置信息。
心跳超时：nameserver每隔10秒钟（此时间无法更改），扫描所有还存活的broker连接，若某个连接2分钟内（当前时间与最后更新时间差值超过2分钟，此时间无法更改）没有发送心跳数据，则断开连接。
时机：broker挂掉；心跳超时导致nameserver主动关闭连接
动作：一旦连接断开，nameserver会立即感知，更新topc与队列的对应关系，但不会通知生产者和消费者
2 负载均衡
一个topic分布在多个broker上，一个broker可以配置多个topic，它们是多对多的关系。
如果某个topic消息量很大，应该给它多配置几个队列，并且尽量多分布在不同broker上，减轻某个broker的压力。
topic消息量都比较均匀的情况下，如果某个broker上的队列越多，则该broker压力越大。
由于消息分布在各个broker上，一旦某个broker宕机，则该broker上的消息读写都会受到影响。所以rocketmq提供了master/slave的结构，salve定时从master同步数据，如果master宕机，则slave提供消费服务，但是不能写入消息，此过程对应用透明，由rocketmq内部解决。
这里有两个关键点：
一旦某个broker master宕机，生产者和消费者多久才能发现？受限于rocketmq的网络连接机制，默认情况下，最多需要30秒，但这个时间可由应用设定参数来缩短时间。这个时间段内，发往该broker的消息都是失败的，而且该broker的消息无法消费，因为此时消费者不知道该broker已经挂掉。
消费者得到master宕机通知后，转向slave消费，但是slave不能保证master的消息100%都同步过来了，因此会有少量的消息丢失。但是消息最终不会丢的，一旦master恢复，未同步过去的消息会被消费掉。
所有发往broker的消息，有同步刷盘和异步刷盘机制，总的来说，可靠性非常高
同步刷盘时，消息写入物理文件才会返回成功，因此非常可靠
异步刷盘时，只有机器宕机，才会产生消息丢失，broker挂掉可能会发生，但是机器宕机崩溃是很少发生的，除非突然断电
5 消息清理
默认10秒，由broker配置参数cleanResourceInterval决定
物理文件不能无限制的一直存储在磁盘，当磁盘空间达到阈值时，不再接受消息，broker打印出日志，消息发送失败，阈值为固定值85%
默认每天凌晨4点，由broker配置参数deleteWhen决定；或者磁盘空间达到阈值
文件保留时长
默认72小时，由broker配置参数fileReservedTime决定
6 读写性能
文件内存映射方式操作文件，避免read/write系统调用和实时文件读写，性能非常高
永远一个文件在写，其他文件在读
顺序写，随机读
利用linux的sendfile机制，将消息内容直接输出到sokect管道，避免系统调用
7 系统特性
大内存，内存越大性能越高，否则系统swap会成为性能瓶颈
cpu load高，使用率低，因为cpu占用后，大部分时间在IO WAIT
磁盘可靠性要求高，为了兼顾安全和性能，采用RAID10阵列
磁盘读取速度要求快，要求高转速大容量磁盘
1 与nameserver关系
单个消费者和一台nameserver保持长连接，定时查询topic配置信息，如果该nameserver挂掉，消费者会自动连接下一个nameserver，直到有可用连接为止，并能自动重连。
与nameserver没有心跳
默认情况下，消费者每隔30秒从nameserver获取所有topic的最新队列情况，这意味着某个broker如果宕机，客户端最多要30秒才能感知。该时间由DefaultMQPushConsumer的pollNameServerInteval参数决定，可手动配置。
2 与broker关系
单个消费者和该消费者关联的所有broker保持长连接。
默认情况下，消费者每隔30秒向所有broker发送心跳，该时间由DefaultMQPushConsumer的heartbeatBrokerInterval参数决定，可手动配置。broker每隔10秒钟（此时间无法更改），扫描所有还存活的连接，若某个连接2分钟内（当前时间与最后更新时间差值超过2分钟，此时间无法更改）没有发送心跳数据，则关闭连接，并向该消费者分组的所有消费者发出通知，分组内消费者重新分配队列继续消费
时机：消费者挂掉；心跳超时导致broker主动关闭连接
动作：一旦连接断开，broker会立即感知到，并向该消费者分组的所有消费者发出通知，分组内消费者重新分配队列继续消费
3 负载均衡
集群消费模式下，一个消费者集群多台机器共同消费一个topic的多个队列，一个队列只会被一个消费者消费。如果某个消费者挂掉，分组内其它消费者会接替挂掉的消费者继续消费。
4 消费机制
消费者不间断的从broker拉取消息，消息拉取到本地队列，然后本地消费线程消费本地消息队列，只是一个异步过程，拉取线程不会等待本地消费线程，这种模式实时性非常高。对消费者对本地队列有一个保护，因此本地消息队列不能无限大，否则可能会占用大量内存，本地队列大小由DefaultMQPushConsumer的pullThresholdForQueue属性控制，默认1000，可手动设置。
消息拉取线程每隔多久拉取一次？间隔时间由DefaultMQPushConsumer的pullInterval属性控制，默认为0，可手动设置。
消息消费数量
监听器每次接受本地队列的消息是多少条？这个参数由DefaultMQPushConsumer的consumeMessageBatchMaxSize属性控制，默认为1，可手动设置。
5 消费进度存储
每隔一段时间将各个队列的消费进度存储到对应的broker上，该时间由DefaultMQPushConsumer的persistConsumerOffsetInterval属性控制，默认为5秒，可手动设置。
6 如果一个topic在某broker上有3个队列，一个消费者消费这3个队列，那么该消费者和这个broker有几个连接？
一个连接，消费单位与队列相关，消费连接只跟broker相关，事实上，消费者将所有队列的消息拉取任务放到本地的队列，挨个拉取，拉取完毕后，又将拉取任务放到队尾，然后执行下一个拉取任务
1 与nameserver关系
单个生产者者和一台nameserver保持长连接，定时查询topic配置信息，如果该nameserver挂掉，生产者会自动连接下一个nameserver，直到有可用连接为止，并能自动重连。
默认情况下，生产者每隔30秒从nameserver获取所有topic的最新队列情况，这意味着某个broker如果宕机，生产者最多要30秒才能感知，在此期间，发往该broker的消息发送失败。该时间由DefaultMQProducer的pollNameServerInteval参数决定，可手动配置。
与nameserver没有心跳
2 与broker关系
单个生产者和该生产者关联的所有broker保持长连接。
默认情况下，生产者每隔30秒向所有broker发送心跳，该时间由DefaultMQProducer的heartbeatBrokerInterval参数决定，可手动配置。broker每隔10秒钟（此时间无法更改），扫描所有还存活的连接，若某个连接2分钟内（当前时间与最后更新时间差值超过2分钟，此时间无法更改）没有发送心跳数据，则关闭连接。
移除broker上的生产者信息
3 负载均衡
生产者时间没有关系，每个生产者向队列轮流发送消息
浏览 19383
浏览: 423490 次
来自: 杭州
请问楼主，新增一个broker的话应该怎么做？给新的broke ...
此文：有意义！
另外咨询两个个问题当前shell命令开启的所有进程数的计算方式 ...workming 的BLOG
用户名：workming
文章数：126
评论数：235
访问量：1100387
注册日期：
阅读量：5863
阅读量：12276
阅读量：393337
阅读量：1084446
51CTO推荐博文
一、简介是一款分布式、队列模型的消息中间件，具有以下特点：、支持严格的消息顺序；、支持与两种模式；、亿级消息堆积能力；、比较友好的分布式特性；、同时支持与方式消费消息；更多介绍可以参考以下链接：本文采用双的架构模式。二、服务器分布、相关说明地址主机名机型角色架构模式内存、（双模式）内存、（双模式）、信息添加、系统环境、总体架构三、安装与配置、安装、安装、环境变量设置、主机名设置、服务器' &&& /etc/sysconfig/network、服务器' &&& /etc/sysconfig/network、配置、服务器、服务器、参数调整需要根据内存大小进行适当地调整、服务启动、启动【、】、启动【】、启动【】四、服务健康监控、依赖组件安装、监控#!/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
SRV_PORT="9876"&&&&&&&&&&&&&&&&&&&&##&端口号
SRV_PROT="tcp"&&&&&&&&&&&&&&&&&&&&&##&协议类型
SRV_NAME="rocketmq_nameserver"&&&&&##&服务名
##&是否已正确扫描
SCAN_FLAG=0
for&ETH_NAME&in&`/sbin/ifconfig&|&grep&eth1&|&awk&'{print&$1}'`
&&&&&&&ETH1_ADDR=`/sbin/ifconfig&${ETH_NAME}&|&awk&-F&':'&'/inet&addr/{print&$2}'&|&sed&'s/[a-zA-Z&]//g'`
&&&&&&&[[&-z&"${ETH1_ADDR}"&]]&&&&continue&||&break
TMP_SRV_PROT=`echo&${SRV_PROT}&|&tr&'[A-Z]'&'[a-z]'`
if&[[&"${TMP_SRV_PROT}"&==&"tcp"&]];&then
&&&&&&&PROT_OPT="S"
elif&[[&"${TMP_SRV_PROT}"&==&"udp"&]];&then
&&&&&&&PROT_OPT="U"
&&&&&&&echo&"未知的协议类型！"&&&&exit1
##&最多扫描3次，成功一次即可，以避免网络抖动而导致误判
for&((i=0;&i&3;&i++));&do
&&&&&&&RETVAL=`/usr/bin/nmap&-n&-s${PROT_OPT}&-p&${SRV_PORT}&${ETH1_ADDR}&|&grep&open`
&&&&&&&[[&-n&"${RETVAL}"&]]&&&&SCAN_FLAG=1;break&||&sleep&10
if&[[&${SCAN_FLAG}&-ne&1&]];&then
&&&&&&&[[&-n&`ps&aux&|&grep&java&|&grep&namesrv`&]]&&&&kill&-9&`ps&aux&|&grep&java&|&awk&'/namesrv/{print&$2}'`
&&&&&&&cd&/usr/local/rocketmq/bin&&&&nohup&sh&mqnamesrv&&
fi、监控#!/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
SRV_PORT="10911"&&&&&&&&&&&&&&&&&&&&&&##&端口号
SRV_PROT="tcp"&&&&&&&&&&&&&&&&&&&&&&&&##&协议类型
SRV_NAME="rocketmq_brokerserver"&&&&&&##&服务名
##&是否已正确扫描
SCAN_FLAG=0
for&ETH_NAME&in&`/sbin/ifconfig&|&grep&eth1&|&awk&'{print&$1}'`
&&&&&&&ETH1_ADDR=`/sbin/ifconfig&${ETH_NAME}&|&awk&-F&':'&'/inet&addr/{print&$2}'&|&sed&'s/[a-zA-Z&]//g'`
&&&&&&&[[&-z&"${ETH1_ADDR}"&]]&&&&continue&||&break
TMP_SRV_PROT=`echo&${SRV_PROT}&|&tr&'[A-Z]'&'[a-z]'`
if&[[&"${TMP_SRV_PROT}"&==&"tcp"&]];&then
&&&&&&&PROT_OPT="S"
elif&[[&"${TMP_SRV_PROT}"&==&"udp"&]];&then
&&&&&&&PROT_OPT="U"
&&&&&&&echo&"未知的协议类型！"&&&&exit1
##&最多扫描3次，成功一次即可，以避免网络抖动而导致误判
for&((i=0;&i&3;&i++));&do
&&&&&&&RETVAL=`/usr/bin/nmap&-n&-s${PROT_OPT}&-p&${SRV_PORT}&${ETH1_ADDR}&|&grep&open`
&&&&&&&[[&-n&"${RETVAL}"&]]&&&&SCAN_FLAG=1;break&||&sleep&10
if&[[&${SCAN_FLAG}&-ne&1&]];&then
&&&&&&&[[&-n&`ps&aux&|&grep&java&|&grep&broker`&]]&&&&kill&-9&`ps&aux&|&grep&java&|&awk&'/broker/{print&$2}'`
&&&&&&&cd&/usr/local/rocketmq/bin&&&&nohup&sh&mqbroker&-c&../conf/2m-noslave/broker-a.properties&&
fi【注意】以上红色标注部分，在上的名称为“”、信息添加本文出自 “” 博客，请务必保留此出处
了这篇文章
类别：┆阅读(0)┆评论(0)
17:25:30 19:15:48 10:46:21 15:12:12 15:54:45 16:09:32 17:16:58 09:14:00 09:24:43 13:38:13 16:37:09 17:53:13 17:40:37 17:35:14分布式消息队列RocketMQ深度解析（11）
我们知道，在早期的RocketMQ版本中，是有依赖ZK的。而现在的版本中，是去掉了对ZK的依赖，转而使用自己开发的NameSrv。
并且这个NameSrv是无状态的，你可以随意的部署多台，其代码也非常简单，非常轻量。
那不禁要问了：ZooKeeper是业界用来管理集群的一个非常常用的中间件，比如Kafka就是依赖的ZK。那为什么RocketMQ要自己造轮子，自己做集群的管理呢？纯粹就是再做一个Zookeeper吗？
本篇试图通过一个架构上的巨大差异，来阐述为什么RocketMQ可以去掉ZK。
Kafka的架构拓扑图
我们知道，在Kafka中，是1个topic有多个partition，每个partition有1个master + 多个slave。对应如下图所示：
注意：这里只有3台机器(b0,b1,b2)，每台机器既是Master，也是Slave。具体来说，比如机器b0，对于partition0来说，它可能是Master；对应partition1来说，它可能又是Slave。
RocketMQ的架构拓扑图
不同于Kafka里面，一台机器同时是Master和Slave。在RocketMQ里面，1台机器只能要么是Master，要么是Slave。这个在初始的机器配置里面，就定死了。其架构拓扑图如下：
在这里，RocketMQ里面queue这个概念，就对应Kafka里面partition。
有3个Master, 6个Slave，那对应到物理上面，就是3+6，得9台机器！！！而不是上面像Kafka一样，3台机器。
Master/Slave/Broker概念上的差异
通过上面2张图，我们已经可以直观看出2者的巨大差异。反映到概念上，虽然2者都有Master/Slave/Broker这3个概念，但其含义是不一样的。
Master/Slave概念差异
Master/Slave是个逻辑概念，1台机器，同时具有Master角色和Slave角色。
Master/Slave是个物理概念，1台机器，只能是Master或者Slave。在集群初始配置的时候，指定死的。其中Master的broker id = 0，Slave的broker id & 0。
Broker概念差异
Broker是个物理概念，1个broker就对应1台机器。
RocketMQ：Broker是个逻辑概念，1个broker =
1个master + 多个slave。所以才有master broker,
slave broker这样的概念。
那这里，master和slave是如何配对的呢？ 答案是通过broker name。具有同1个broker name的master和slave进行配对。
具体到配置里面，如下：
//机器1的配置
brokerClusterName=DefaultCluster
brokerName=broker-a
brokerId=0
deleteWhen=04
fileReservedTime=48
brokerRole=ASYNC_MASTER
flushDiskType=ASYNC_FLUSH
//机器2的配置
brokerClusterName=DefaultCluster
brokerName=broker-a
brokerId=1
deleteWhen=04
fileReservedTime=48
brokerRole=SLAVE
flushDiskType=ASYNC_FLUSH
//机器3的配置
brokerClusterName=DefaultCluster
brokerName=broker-a
brokerId=2
deleteWhen=04
fileReservedTime=48
brokerRole=SLAVE
flushDiskType=ASYNC_FLUSH
这里机器1和机器2，机器3具有相同的brokerName（broker-a)，一个brokerId = 0，另2个brokerId & 0。所以机器1是Master，机器2, 3是Slave。
所以这里可以看出：RokcetMQ和Kafka关于这2对概念的定义，刚好是反过来的！Kafka是先有Broker，然后产生出Master/Slave；RokcetMQ是先定义Master/Slave，然后组合出Broker。
答案：为什么可以去ZK?
从上面对比可以看出，Kafka和RocketMQ在Master/Slave/Broker这个3个概念上的差异。
这个差异，也就影响到topic, partition这种逻辑概念和Master/Slave/Broker这些物理概念上的映射关系。具体来讲就是：
在Kafka里面，Maser/Slave是选举出来的！！！RocketMQ不需要选举！！！
在Kafka里面，Maser/Slave是选举出来的！！！RocketMQ不需要选举！！！
在Kafka里面，Maser/Slave是选举出来的！！！RocketMQ不需要选举！！！
重要的话说三篇。具体来说，在Kafka里面，Master/Slave的选举，有2步：第1步，先通过ZK在所有机器中，选举出一个KafkaController；第2步，再由这个Controller，决定每个partition的Master是谁，Slave是谁。
这里的Master/Slave是动态的，也就是说：当Master挂了之后，会有1个Slave切换成Master。
而在RocketMQ中，不需要选举，Master/Slave的角色也是固定的。当一个Master挂了之后，你可以写到其他Master上，但不会说一个Slave切换成Master。
这种简化，使得RocketMQ可以不依赖ZK就很好的管理Topic/queue和物理机器的映射关系了，也实现了高可用。
这里，也涉及到了我在上1篇里，所说的“消息顺序”的问题：在Kafka里面，一个partition必须与1个Master有严格映射关系，这个Master挂了，就要从其他Slave里面选举出一个Master；而在RocketMQ里面，这个限制放开了，一个queue对应的Master挂了，它会切到其他Master，而不是非要选举出来一个。
说到这，答案基本就知道了：RocketMQ不需要像Kafka那样有很重的选举逻辑，它把这个问题简化了。剩下的就是topic/queue的路由信息，那用个简单的NameServer就搞定了，很轻量，还无状态，可靠性也能得到很好保证。
Topic的创建过程
下面从使用的角度，看看Kafka和RocketMQ在创建topic的时候，分别都需要指定什么参数？
从这些参数也可以看出，2者的topic, partition这种逻辑概念和物理机器之间的映射关系，有很大不同。
RocketMQ 创建topic的命令
下面代码来自UpdateTopicSubCommand这个类，也就是RocketMq创建topic时，调用的类。这里有几个关键参数，其他参数我省略了：
//b和c2选1，b是指定topic所在的机器，c是指定topic所在的cluster
//这个是基本参数，没什么好讲的
readQueueNums/writeQueueNums: //队列个数。缺省2者相等，是8。关于这个readQueueNums/writeQueueNums，是RocketMQ特有的概念，后面再来详细分析。此处就认为他们2者相等，是同1个。
Option opt = new Option("b", "brokerAddr", true, "create topic to which broker");
opt.setRequired(false);
options.addOption(opt);
opt = new Option("c", "clusterName", true, "create topic to which cluster");
opt.setRequired(false);
options.addOption(opt);
opt = new Option("t", "topic", true, "topic name");
opt.setRequired(true);
options.addOption(opt);
opt = new Option("r", "readQueueNums", true, "set read queue nums");
opt.setRequired(false);
options.addOption(opt);
opt = new Option("w", "writeQueueNums", true, "set write queue nums");
opt.setRequired(false);
options.addOption(opt);
Kafka创建topic的命令
跟RocketMQ相比，有2个同样的参数：1个是topic，一个是队列数目，也就是这里的–partitions。
2者在创建topic时一个显著的不同
Kafka有一个参数replication-factor，也就是指定给1个Master配几个Slave?
RocketMQ有一个参数c，也就是clusterName，来指定这个cluster里面，所有的Master和Slave的配对（多个master, 多个slave) 对应同1个topic!!!
缺省情况下，所有的Master和Slave属于同1个集群，也就是上面的3台机器配置中的第1个参数：brokerClusterName=DefaultCluster。
结合上面的架构拓扑图，我们就可以看出：
对于kafka来说，你指定topic，它的partition个数，它的master/slave配比，然后系统自动从所有机器中，为每个topic_partition分配1个master + 多个slave；
对于RokcetMQ来说，你指定topic，它的queue个数，它对应的cluster。然后系统自动建立这个cluster(多个master + 多个slave) 和你的topic之间的映射关系。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：26215次
排名：千里之外
原创：61篇
评论：27条
(9)(7)(18)(7)(27)}