Apache RocketMQ：有关如何确保稳定容量的经验教训

了解如何使用RocketMQ确保容量稳定。本文来自国内专业IT教育学院【优锐课】。Java学习资料交流qq群：907135806，在接下来的学习如果过程中有任何疑问，欢迎进群探讨。

毫不奇怪，当性能波动时会有例外。在那种情况下，我们如何保持容量的稳定性？在谈论解决方案时，我们必须了解紧迫性。如果不立即处理，这些紧急情况可能会导致整个群集的级联故障。该解决方案采用三种众所周知的方法：降级，流量整形和断路器。

降级

降级意味着系统将确认存在问题并做出相应调整。这确实是这三个中的懒惰解决方案。它所做的只是删除某些消息。至于谁决定删除哪一个，则取决于Qos配置和用户数据分析。结果，那些被认为“不太重要”的主题将被关闭。

流量整形

有关如何调整流量的主要理论有两种：泄漏桶和令牌桶。漏水的桶假设泄漏以稳定的速度发生，这表明桶会接受更多的水。如果接收速率超过泄漏速率，则存储桶将溢出。

令牌桶要求每个请求都必须先获取令牌，然后才能进入令牌桶。当然，令牌以恒定的速度更新。如果请求没有令牌到达，这就是切断流量的信号。

两种理论都在软件实践中使用。例如，番石榴具有RateLimiter模块，Netty具有TrafficShaping模块。

RocketMQ通过对流量进行分类来解决此问题。对于那些被确定为频繁重复请求的请求，它们将被置于故障快速通道中。这意味着如果延迟超过阈值，它们将被终止。对于不频繁或较大的请求，将使用诸如滑动窗口之类的机制来调整频率并控制影响。

断路器

许多Java开发人员都熟悉Netflix Hystrix。但是对于那些不是的人，断路是拒绝或超时保护群集的请求的机制。让我们看一下以下示例：

“Dependency I” 正在成为瓶颈。如果无人看管，越来越多的请求将挂在那里，并最终导致整个系统瘫痪。引入了断路器来拒绝这些请求。
但是，许多产品（例如Hystrix）需要30秒钟左右的时间来确定瓶颈，尤其是那些与系统资源有关的瓶颈。这对于消息队列来说太长了。 RocketMQ通过快速识别硬件级别瓶颈来做到这一点，并将在几毫秒内做出响应。

总结

消息队列的稳定容量是一项关键功能。RocketMQ确保该方面运行良好。现在我们许多人可能会想，这三种机制将如何协同工作？嗯，像任何设计一样，有针对性的使用情况和那些被遗漏的用途。我们使用其中的三个来确保没有遗忘用例。

Java学习资料交流qq群：907135806，在接下来的学习如果过程中有任何疑问，欢迎进群探讨。

也可以添加vx：ddmsiqi，有更多JVM、Mysql、Tomcat、Spring Boot、Spring Cloud、Zookeeper、Kafka、RabbitMQ、RockerMQ、Redis、ELK、Git等Java学习资料和视频课程！抽丝剥茧 细说架构那些事——【优锐课】