189 8069 5689

RocketMQ基本概念及原理是什么

这篇文章将为大家详细讲解有关RocketMQ基本概念及原理是什么,文章内容质量较高,因此小编分享给大家做个参考,希望大家阅读完这篇文章后对相关知识有一定的了解。

为无极等地区用户提供了全套网页设计制作服务,及无极网站建设行业解决方案。主营业务为成都网站设计、网站制作、无极网站设计,以传统方式定制建设网站,并提供域名空间备案等一条龙服务,秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求,就会得到认可,从而选择与我们长期合作。这样,我们也可以走得更远!

RocketMQ使用
基本概念
ProducerGroup
    通常具有同样属性(处理的消息种类-topic、以及消息处理逻辑流程—分布式多个客户端)的一些producer可以归为同一个group。在事务消息机制中,如果某条发送某条消息的producer-A宕机,使得事务消息一直处于PREPARED状态并超时,则broker会回查 同一个group的其他producer,确认这条消息应该commit还是rollback。
ConsumerGroup
    具有同样逻辑消费同样消息的consumer,可以归并为一个group。同一个group内的消费者,可以共同消费(CLUSTERING)对应topic的消息,达到分布式并行处理的功能。
Topoic
    消息的逻辑管理单位。
Queue
    消息的物理管理单位。一个Topic下可以有多个Queue,Queue的引入使得消息存储可以分布式集群化,具有了水平扩展的能力。
消费进度管理
    RocketMQ的broker端,不负责推送消息,无论消费者是否消费消息,都将消息存储起来。谁要消费消息,就向broker发请求获取消息,消费记录由consumer来维护。RocketMQ提供了两种存储方式来保留消费记录:一种是保留在consumer所在的服务器上;另一种是保存在broker服务器上。用户还可以自己实现相应的消费进度存储接口。
    默认情况下,采用集群消费(CLUSTERING),会将记录保存在broker端;而采用广播消费(BROADCASTING)则会将消费记录保存在本地。
顺序消息
    用户实现MessageQueueSelector为某一批消息(通常是有同样的唯一的标示ID),选择同一个Queue,则这一批消息的消费将是顺序消费(并由同一个consumer完成消费)。
事务消息
    这样的消息有多个状态,并且其发送是两阶段的。第一个阶段发送PREPARED状态的消息,此时consumer是看不见这种状态的消息的,发送完毕后回调用户的TransactionExecutor接口,执行相应的事务操作(如数据库),当事务操作成功时,则对此条消息返回commit,让broker对该消息执行commit操作,成为commit状态的消息对consumer是可见的。

基本原理
    总览
RocketMQ以Topic来管理不同应用的消息。对于生产者而言,发送消息是,需要指定消息的Topic,对于消费者而言,在启动后,需要订阅相应的Topic,然后可以消费相应的消息。Topic是逻辑上的概念,在物理实现上,一个Topic由多个Queue组成,采用多个Queue的好处是可以将Broker存储分布式化,提高系统性能。
    RocketMQ中,producer将消息发送给Broker时,需要制定发送到哪一个队列中,默认情况下,producer会轮询的将消息发送到每个队列中(所有broker下的Queue合并成一个List去轮询)。
    对于consumer而言,会为每个consumer分配固定的队列(如果队列总数没有发生变化),consumer从固定的队列中去拉取没有消费的消息进行处理。
 
Producer
Producer端(属于client)的逻辑概述:
 
producer端的逻辑都比较简单,将消息发送到某个Queue中即可,具体发送到那个Queue可以由用户控制(MessageQueueSelector接口),默认情况下,将轮询方式选择Queue。在producer端,会从NameServer将所有Broker的Topic及对应的Queue信息(即:TopicRoute信息)拉取到本地,然后根据组建成一个List。因此在MessageQueueSelector,可以看到所有的Queue信息。
    RocketMQ将topic的消息以多个Queue来管理,使得其较为容易的就可以进行水平扩展,提供系统吞吐力。这样分布带来的问题,就是从全局上不能做到顺序性(很多时候也并不需要全局上的顺序性)。
RocketMQ提到支持顺序消息,实际上是指基于Queue级别的顺序。用户将某些需要满足顺序的一批消息(比如电商某个订单号的一系列后续操作、比如数据库的某个主键的insert、delete、update等操作)发送到固定的某个Queue中,则从这个Queue消费消息的consumer,针对这一批消息是顺序消费。
问题1:针对顺序消息的队列,是否可以做到不停服务下的集群动态扩展?
Consumer
    consumer逻辑稍微复杂一点。初步思考,consumer端至少需要处理:
1、    消息的获取
2、    offset(消费进度)的管理与存储
3、    集群消费模式下,Queue的分配问题(rebalance)
RocketMQ对外提供了两种不同形式的Consumer:PushConsumer和PullConsumer。顾名思义,对于PullConsumer而言,用户需要主动调用相应的接口去拉取未消费的消息。对于PushConsumer而言,用户提供消息处理的CallBack,有未曾消费的消息时,会主动回调这个CallBack来处理消息。虽从用户角度而言,Consumer存在主动(pull)和被动(push),但RocketMQ本身的broker端仅仅保存所有的消息,并不负责push消息,因此PushConsumer的底层实现也是有一个长连接主动去broker上拉取未消费的消息,然后回调用户的callback逻辑。

    PushConsumer端逻辑概述:
        自己使用PushConsumer的代码非常简单:
        
1
2
3
4
5
6
7
8
9
10
11    DefaultMQPushConsumer consumer = new DefaultMQPushConsumer(“groupName”);
consumer.subscribe(“TopicName”, “*”); // a | b | c
consumer.registerMessaeListener( new MessageListenerConcurrently() {
public ConsumeConcurrentlyStatus consumeMessage(List msgs, 
                                  ConsumeConcurrentlyContext context) {
  System.out.println(“Consume Message Num: ” + msgs.size());
   return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
}
});
consumer.start();
// add shutdown hook to execute consumer.shutdown();
第2行的subscribe即定于某个topic下,符合某些标签(tag)的消息。这个过滤会在服务端过滤(其实在consumer端也有过滤逻辑)。tag之间用”|”分割开。这些tag会被解析成SubscriptionData来保存信息,主要存储tag的字符串集合,以及这些tag对应的hashcode集合(在broker端的存储和过滤其实都是tag值对应的hashcode,可能是为了加速过滤以及节约存储空间)。
    主要的逻辑在第10行调用start函数之后开始。Consumer的主要实现是DefaultMQPushConsumerImpl,其包含的对象关系简单如下图:
 
DefaultMQPushConsumerImpl中各个对象的主要功能如下:
RebalancePushImpl:    主要负责决定,当前的consumer应该从哪些Queue中消费消息;
PullAPIWrapper:        长连接,负责从broker处拉取消息,然后利用ConsumeMessageService回调用户的Listener执行消息消费逻辑;
ConsumeMessageService:    实现所谓的“Push-被动”消费机制;从Broker拉取的消息后,封装成ConsumeRequest提交给ConsumeMessageSerivce,此service负责回调用户的Listener消费消息;
OffsetStore:            维护当前consumer的消费记录(offset);有两种实现,Local和Rmote,Local存储在本地磁盘上,适用于BROADCASTING广播消费模式;而Remote则将消费进度存储在Broker上,适用于CLUSTERING集群消费模式;
MQClientFactory:    大杂烩,负责管理client(consumer、producer),并提供多中功能接口供各个Service(Rebalance、PullMessage等)调用;大部分逻辑均在这个类中完成;


使用
Producer返回值
发送消息时,只有抛出异常,才是发送失败,其他情况下,根据如下返回值,应用层做相应取舍处理逻辑:
SendStatus
返回值    解释
SEND_OK    发送成功
FLUSH_DISK_TIMEOUT    发送成功,但broker刷盘失败,此时如若服务器宕机,消息会丢失;
FLUSH_SLAVE_TIMEOUT    写从失败;如果主宕机,消息丢失;
SLAVE_NOT_AVAILABLE    从不可用;
注意:当配置多master无slave的集群时,若master的brokerRole为SYNC_MASTER,则发送消息会一直返回这个值;最新版本(3.1.14以上)事务消息将一直发送失败(事务消息中处理了返回值不为SEND_OK,则直接进行ROLL_BACK);
当应用方明确指出,producer发送成功为SEND_OK状态的消息对consumer才是可见的。可以采用事务消息来完成这个功能,RocketMQ 从3.0.14版本开始,对于事务消息,开始检查SendStatus,如果不为SEND_OK,则直接执行事务消息的回滚。
Consumer返回值
当使用PushConsumer(使用callBack回调执行应用消费逻辑)
非顺序消息(ConsumeConcurrentlyStatus)
返回值    解释
CONSUME_SUCCESS    消费成功
RECONSUME_LATER    消费失败,稍后重新消费这一批消息
RECONSUMER_LATER的解释:
    这一批消息均会sendBack到broker上,稍后会重新消费这一批消息。可以通过设置参数,使得批量消费的“批量”为一条,这样可以一定程度避免重复消费。但这样设置后,可能效率较低。另外一种方法是在用户指定的CallBack(MessageListenerConcurrently)中,通过对应的ConsumeConcurrentlyContext参数来控制本批消息从哪一条之后重复消费。
具体方法是控制context的ackIndex变量。这个变量的意思是对于这一批消息(List),[0, ackIndex]内的消息是成功消费的,而(ackIndex, Lst.size)内的消息是消费失败的,如果返回值为RECONSUME_LATER,则对于失败范围的消息将调用sendBack回发到broker上(从代码看来,这个功能只对CLUSTERING消费模型的consumer生效,BROADCASTING的直接丢弃)。这里还有个小的tips,在调用SendBack失败后,会在consumer本地去尝试重复消费这些回发失败的消息(构造相应的ConsumeRequest)。这个处理模式(先消费,消费失败的消息尝试回发给broker,回发给broker失败的消息尝试在consumer端重新消费)一直尝试,直到消费成功或者回发到broker成功。
顺序消息(ConsumerOrderlyStatus)
返回值    解释
SUCCESS    消息处理成功
ROLLBACK    回滚消息—似乎用在了事务消息中
COMMIT    提交消息—似乎用在了事务消息中
SUSPEND_CURRENT_QUEUE_A_MOMENT    当前队列挂起一段时间
问题:消费端的ROLLBACK、COMMIT如何理解???
普通消息
    
使用TIPS
集群搭建
1.    基本配置
使用./bin/mqbroker –p >conf/broker.conf,查看所有参数的默认取值;根据自己集群的需要修改对应的配置;
2.    集群选择
RocketMQ集群支持如下一些模式的配置:
集群模式    特点    适用场景
单Master    一个Broker实例;
或者多个Broker实例,但Topic只在某一个Broker上配置了;    测试
多Master 无Slave    多个Broker实例构成集群,且brokerID均为0(即角色都为Master)    
master挂掉后,这个master上未被消费的消息,暂时不能被消费;
可以容忍消息丢失(未被consumer消费)的应用场景;如日志收集

多Master多Slave    每个master有一个backup的slave    HA高可用;当master-slave采用同步双写时(采用异步时,任可能存在部分未写入slave的消息丢失),master挂掉,也可以从slave处消费消息;但当master挂掉后,目前不支持自动的Failover(因此不支持producer的写);

疑问: 手动如何切换?是否需要修改Slave的配置为Master,然后重启broker实例?代价有点高,支持发送命令切换否?

当使用多master无slave的集群搭建方式时,master的brokerRole配置必须为ASYNC_MASTER。如果配置为SYNC_MASTER,则producer发送消息时,返回值的SendStatus会一直是SLAVE_NOT_AVAILABLE。
3.    系统参数优化
参考bin/os.sh中的参数,重点注意物理内存预留参数(vm.min_free_kbytes)。
4.    broker的启动
采用集群模式时,启动broker时,需要制定nameserver 地址的list,这里一定要注意,要将所有的nameserver 地址都包含进去;因为rocketmq的nameserver之间并不会同步,均需要broker主动汇报;如果有3个nameserver: A B C,启动时只制定了A,忘记制定了B C,那么客户端如果刚好链接了B或C去获取broker的信息,则会获取失败。
消息使用
    
问题整理
问题:
1、服务器磁盘配置大概是怎样(重点想了解磁盘配置、磁盘总容量,例如: N * 4T SATA 7200 )?
2、服务器的磁盘做raid了吗?做的哪一种raid?刷磁盘模式是SYNC还是ASYNC?
3、rocketmq采用的哪种方式搭建(多master无slave、多master多slave)?如果是master-slave方式,主从同步是SYNC还是ASYNC方式?

解答:
1、一般是3T磁盘,实际是12个600,12* 600G的sas 15000转的磁盘做了raid10
2、刷盘模式通常是异步方式
3、大部分集群是不开启slave的, 有少部分集群会开启 sync方式的slave 

关于RocketMQ基本概念及原理是什么就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。


新闻标题:RocketMQ基本概念及原理是什么
网站路径:http://cdxtjz.com/article/pojese.html

其他资讯