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 能实时地接收到新的消息数据。

• 缺点：

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

• 一个 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