分布式开放消息系统(RocketMQ)的原理与实践.docxVIP

分布式开放消息系统(RocketMQ)的原理与实践 2021-04-03 分布式消息系统作为实现分布式系统可扩展、可伸缩性的关键组件，需要具有高吞吐量、高可用等特点。而谈到消息系统的设计，就回避不了两个问题： 消息的挨次问题 消息的反复问题 RocketMQ作为阿里开源的一款高功能、高吞吐量的消息两头件，它是怎样来处理这两个问题的？RocketMQ 有哪些关键特性？其实现原理是怎样的？ 关键特性以及其实现原理 一、挨次消息 消息有序指的是可以依据消息的发送挨次来消费。例如：一笔订单产生了 3 条消息，分别是订单创建、订单付款、订单完成。消费时，要依据挨次依次消费才有意义。与此同时多笔订单之间又是可以并行消费的。首先来看如下示例： 假如生产者产生了2条消息：M1、M2，要保证这两条消息的挨次，应当怎样做？你脑中想到的可能是这样： 你可能会接受这种方式保证消息挨次 假定M1发送到S1，M2发送到S2，假如要保证M1先于M2被消费，那么需要M1到达消费端被消费后，通知S2，然后S2再将M2发送到消费端。 这个模型存在的问题是，假如M1和M2分别发送到两台Server上，就不能保证M1先达到MQ集群，也不能保证M1被先消费。换个角度看，假如M2先于M1达到MQ集群，甚至M2被消费后，M1才达到消费端，这时消息也就乱序了，说明以上模型是不能保证消息的挨次的。如何才能在MQ集群保证消息的挨次？一种简约的方式就是将M1、M2发送到同一个Server上： 保证消息挨次，你改进后的方法 这样可以保证M1先于M2到达MQServer（生产者等待M1发送成功后再发送M2），依据先达到先被消费的准绳，M1会先于M2被消费，这样就保证了消息的挨次。 这个模型也仅仅是理论上可以保证消息的挨次，在实际场景中可能会遇到下面的问题： 网络延迟问题 只需将消息从一台服务器发往另一台服务器，就会存在网络延迟问题。如上图所示，假如发送M1耗时大于发送M2的耗时，那么M2就仍将被先消费，仍旧不能保证消息的挨次。即便M1和M2同时到达消费端，由于不清楚消费端1和消费端2的负载情况，仍旧有可能消灭M2先于M1被消费的情况。 那如何处理这个问题？将M1和M2发往同一个消费者，且发送M1后，需要消费端响应成功后才能发送M2。 聪慧的你可能已经想到另外的问题：假如M1被发送到消费端后，消费端1没有响应，那是连续发送M2呢，还是重新发送M1？一般为了保证消息肯定被消费，确定会选择重发M1到另外一个消费端2，就如下图所示。 保证消息挨次的正确姿态 这样的模型就严格保证消息的挨次，细心的你仍旧会发觉问题，消费端1没有响应Server时有两种情况，一种是M1的确没有到达(数据在网络传送中丢失)，另外一种消费端已经消费M1且已经发送响应消息，只是MQ Server端没有收到。假如是其次种情况，重发M1，就会形成M1被反复消费。也就引入了我们要说的其次个问题，消息反复问题，这个后文会具体讲解。 回过头来看消息挨次问题，严格的挨次消息格外简约理解，也可以通过文中所描述的方式来简约处理。总结起来，要实现严格的挨次消息，简约且可行的方法就是： 保证生产者 - MQServer - 消费者是一对一对一的关系 这样的设计虽然简约易行，但也会存在一些很严峻的问题，比如： 并行度就会成为消息系统的瓶颈（吞吐量不够） 更多的特别处理，比如：只需消费端消灭问题，就会导致整个处理流程堵塞，我们不得不花费更多的精力来处理堵塞的问题。 但我们的最终目标是要集群的高容错性和高吞吐量。这好像是一对不行调和的冲突，那么阿里是如何处理的？ 世界上处理一个计算机问题最简约的方法：“恰好”不需要处理它！—— 沈询 有些问题，看起来很重要，但实际上我们可以通过合理的设计或者将问题分解来规避。假如硬要把时间花在处理问题本身，实际上不只效率低下，而且也是一种铺张。从这个角度来看消息的挨次问题，我们可以得出两个结论： 不关注乱序的应用实际大量存在 队列无序并不意味着消息无序 所以从业务层面来保证消息的挨次而不只仅是依靠于消息系统，是不是我们应当寻求的一种更合理的方式？ 最终我们从源码角度分析RocketMQ怎样实现发送挨次消息。 RocketMQ通过轮询全部队列的方式来确定消息被发送到哪一个队列（负载均衡策略）。比如下面的示例中，订单号相同的消息会被先后发送到同一个队列中： // RocketMQ通过MessageQueueSelector中实现的算法来确定消息发送到哪一个队列上// RocketMQ默认供应了两种MessageQueueSelector实现：随机/Hash// 当然你可以依据业务实现本人的MessageQueueSelector来打算消息依据何种策略发送到消息队列中SendResult send