RocketMQ的动态缩扩容和消息实时投递

RocketMQ的动态缩扩容和消息实时投递

动态伸缩

随着业务增长，显示流量会出现快速增长，这时候需要增加服务器，也就是扩容。当流量持续一段时间后又回归到正常情况，为了避免浪费服务器资源，需要减少服务器，这就是缩容。RocketMQ正是有动态伸缩的能力。

消息队列扩容

一个Consumer实例可以同时消费多个消息队列中的消息。如果一个Topic的消息量特别大，但Broker集群水位压力很低，可以对Topic的消息队列扩容，Topic消息队列跟消费速度成正比。**消息队列数在创建Topic时可以指定，也可以在运行中进行修改。**相反，如果一个Topic的消息特别小，但队列数很多，可以对Topic消息队列缩容。

Broker集群扩容

如果一个Topic的消息量特别大，但Broker集群水位很高，此时需要对Broker机器扩容。**扩容方式很简单，直接机器部署Broker。**新的Broker启动后会向NameServer注册，Producer和COnsumer通过NameServer发送新Broker并更新路由信息。相反，如果Broker集群水位很低，我们可以适当减少Broker服务器来节约成本，进行缩小容量。

消息实时投递

获取消息的两种模式：

• Push推模式：当消息发送给服务端时，由服务端主动推送给客户端Consumer。

  优点：是客户端Consumer能实时地接收到新的消息数据。

  缺点：

  1. 如果Consumer消费一条消息耗时很长，消费推送速度大于消费速度，Consumer消费不过来会出现缓冲区溢出；

  2. 一个Topic可能对应多个ConsumerGroup，服务端一条消息会产生多次推送，对服务端造成压力

• Pull拉模式：客户端Consumer主动发送请求，每间隔一段时间轮询去服务端拉取消息。

  优点：Consumer根据当前消费速度选择合适的时机触发拉取

  缺点：拉取的时间间隔不好控制。间隔太长可能导致消息消费不及时，服务端积压消息。间隔太短，服务端收到的消息少，导致Consumer拉取请求无效，浪费网络资源和服务资源

RocketMQ采用长轮询，以客户端Consumer轮询的方式主动发送拉取请求到服务端Broker，Broker检测到有新的消息立即返回Consumer，但如果没有新的消息暂时不返回任何信息，挂起当前请求缓存到本地，Broker后台有个线程检查挂起请求，等新消息产生时返回Consumer。DefaultMQPushConsumer就是推拉结合

总结

好了 这就是RocketMQ高性能设计的动态缩扩容和消息实时投递的内容了，如果你感觉还不错的话就给我点赞评论留言吧，您的赞和评论是对我最大的鼓励，继续加油。

参考文献

RocketMQ文档：

https://github.com/apache/rocketmq/blob/master/docs/cn/design.md