开发者学堂课程【消息队列 RocketMQ 5.0 云原生架构升级课程：RocketMQ 消息收发弹性--生产集群如何解决大促场景消息收发的弹性&降本诉求】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1234/detail/18400
Rocket MQ消息收发弹性--生产集群如何解决大促场景消息收发
主要内容：
一、产品介绍：什么是消息收发弹性
二、产品使用及限制：消息收发弹性的使用及限制
三、使用方式及演示：结合业务场景的最佳使用方式
今天分享阿里云Rocket MQ5.0场景消息收发功能，并且通过该功能生产集群是如何解决大促场景消息收发的弹性以及降本诉求。本次介绍将从产品介绍、产品使用及限制、使用方式及演示等三个方面进行介绍。在介绍Rocket MQ5.0的实例的消息收发弹性之前，先从整体上介绍一下阿里的策略。
一、产品介绍：什么是消息收发弹性
通常认为业务方往往存在预期外的突发业务热点和毛刺流量，为了应对这些突发热点常规扩容的是无法及时应对的，服务存在不确定性的风险。因此为了应对突发流量，设计了一套处理机制，首先是黄色部分，这部分相当于需要满足规格内的预期流量，这是毋庸置疑的，因为每个规格是对应的一个预期内的GPS上限。然后还要应对弹性区间内的突发流量，为了应对这个突发流量，需要做到可以随时开启的弹性能力。最后就是要对完全超过弹性上限的流量进行限流，来保证服务的稳定可靠。针对弹性区间的突发流量的集群，如果是通过常规扩容的方式，则需要更多的时间，在这段时间之内业务会受损，若仅仅是为了这部分突发流量，就把资源控容到一个比较大的规格，并不划算。若使用5.0实例的消息收发弹性能力，可以将弹性区的突发流量收到秒级响应的，并且针对大数据的预期内的短期的突发流量可以是做到按量收费，也更加实惠。因为仅仅用户真正使用到了弹性区间内的一部分流量才会进行收费。
接下来具体介绍5.0消息收发弹性能力的实例，这个能力最直观的感受其实就是在5.0实例行业有一个自适应弹性的TPS这一部分，可以看到在收发TPS弹性的旁边有额外自适应的弹性TPS，则用户可以通过对部分进行设置，就可以快速低成本的应对大促短时间内的突发流量。不直接升级规则、提高标准而使用弹性TPS来满足突发流量的场景的原因是，此处假设一个大促场景，比如说在今晚的0点有大促活动，如果使用社区收发彩信功能，那这些用户完全可以提前几天就把弹性功能打开，等到大促结束流量恢复之后再把这个功能关闭，实际上不关闭也不会有什么问题，因为如果没有使用的话就不进行收费，使用之后才会收费。
但是如果通过升级规格提升标准TPS来处理突发流量，同样是提前几天就把规则给升高，那么在大促前这几天实际上是按照高规格进行收费的，但是又无法使用高规格的TPS，故此用户实际上是花了更多的钱，并且造成了资源的浪费。即使是用户为了避免自己过度浪费，在大促当天0点之前升级规则，这也会出现问题，一个是用户需要付出的额外的精力来关注Rocket MQ进行按时分配，实例的分配是一个非常消耗资源的操作，并且耗时时间会很长，没有办法做到开箱即用秒级生效。这样的话可能会对用户的业务造成一些有损的影响，使用消息弹性功能的话，可以秒级成效，开箱即用的，而且是弹性的，也是弹性收费的。但是弹性的TPS也不是一个解决问题万能的，它也是有上限的。可以看到在上图所示，它的上限其实基本上是在标准TPS的基础上有一半的弹性TPS。也就是说如果用户预估自己的业务流量，即使是标准TPS加上弹性TPS仍然无法满足的话，此时只能通过升级规则进行扩容处理，这种情况下使用消息收发弹性功能是满足不了的。消息收发发弹性还是会进行扩容弹性，仅仅因为弹性的计算节点已经没有办法满足这个需求，需要扩容存储来满足这种需求，所以需要升配规则，这部分的原理后面会有详细介绍。还有用户可能会问，日常TPS在2500左右，可不可以购买图里的实例，还是购买一个2000标准TPS的实例，但是若把弹性功能打开，弹性有1000，实际上是可以满足消息发送至3000 TPS的。在这样的场景下，其实建议直接使用标准发送消息TPS大于2500的实例，因为弹性TPS这部分的使用会有额外收费。如果一天24个小时都在大量的使用弹性TPS，基本上不能直接使用更高规格的实例，这样才会更加实惠。
接下来介绍5.0实例是如何具体实现消息收发弹性能力的，并且在扩容的场景下对比传统自建的基础上具有的优势。
若左图所示，传统自建集群它是一个存储机资源部分的架构，在这种架构下捕捉是一个很重的数据，可以看到同时需要处理客户端的请求，需要负责消息的读取和写入，即需要同时负责计算和存储两方面的功能。那这样的话，就是作为的一个状态结构，那如果想要扩容的话，就需要很重的操作，时间也会比较慢，而且在很多时候，并不需要真的把握存储能力的扩容，仅仅是为了应对短时间的高TPS的请求计算能力的。
那此时为了满足这种短时间的高速TPS请求，将其中一个辅助扩容，但实际上随着扩容出来的存储能力是被浪费掉的。再来看一下右图的5.0实例的结构，首先可以看到5.0实例的架构是一个存储计算分离的模式，用户的客户端仅仅计算节点，计算节点才会创作节点之间的消息的读取、写入或者存储的部分。
客户端并不会直接访问存储节点，消息收发弹性功能实际上就是意味着client的弹性得益于存储计算分离的架构，可以快速低成本的扩容计算层的节点。计算层的节点作为工作的应用扩容的过程十分便捷，并且依赖于阿里云云厂商拥有大量资源池的前提下，配送到资源的材质扩容。
Rocket MQ 5.0消息收发弹性能力，一方面依赖于阿里云作为云厂商的弹性能力和自身的存储分离的方案才得以实现的。也就是说在大促这种短时间大量突发流量的场景下，实际上大部分是不需要扩容存储节点，此时就可以通过开通消息收发弹性功能的能力来满足需求。
二、产品使用及限制：消息收发弹性的使用及限制
接下来讲解产品的使用及限制，消息收发弹性功能仅仅是支持专业版和铂金版，标准版实例是不支持，并且可以看到，如上图所示，专业版的单机规格也是不支持消息收发弹性功能，因为这个单机版实际上是给用户作为一个测试验证的测试实例，并不建议用户在上面生产业务，因为它是单机版的，没有办法生产业务。而且可以看到不同规格的实例的弹性TPS上限也是不同的，基本上是在标准TPS的基础上额外会有一半的弹性TPS。上面这张图展示的是标准版的弹性TPS上限，如图所示，其他规格的弹性上限小伙伴们可以自行参照官网文档，在这里面就不具体列出。收费的标准之前也介绍过，是额外计费的，而且计费是按照小时进行收费的，计费的具体方式是超过标准TPS的部分流量乘以使用时长再乘以弹性规格的使用单价计算得出。而且可以看到针对不同版本的实例，在不同地域，它的单价实际上会有一些略微的差别。
用户可能担心使用此部分弹性TPS会不会有一些稳定性的风险，因为毕竟是在基础标准的TPS之外额外提供的能力，这样给人一种感觉，就是对于实例，如果使用了消息收发弹性的功能，是不是因为这个实例已经是处在一种超出额外预算的状态，关于这个问题，实际上是不需要担心的，因为对于不同的规格都已经经过了线上的压缩验证，实际上超出了标准TPS的这个弹性TPS是享受一样的稳定性，为期三个月的保障。同时可以看到5.0实例的三个版本，标准版，专业版，铂金版，它的稳定性SIV是啊逐渐升高的，即弹性TPS的这部分是与实例整体稳定性IOS是满足实例整体性SIV的。不会因为使用了弹性GPS它的稳定性就会下降，是不会这样的。
三、使用方式及演示：结合业务场景的最佳使用方式
最后进行操作消息收发弹性能力，进而验证这个功能。因为Rocket MQ 5.0的实例依然支持使用Rocket MQ 4.0实例的交叉访问，所以在这里分别提供了一个一点叉客户端和五点叉客户端的测试代码的实例。可以看到这个程序才写了两千个线程的线程池，并且通过rob limit 的根据输入参数设置了每秒最大的发送设备条数。在程序中会打印发送失败的原因，并且每秒会统计一下总共发送的消息量，根据这个功能，可以验证是不是能达到预期想要的一秒中发送的消息TPS。
此处已经购买好了一个专业版的实例，而且此实例默认是不会开启消息收发弹性能力的。如果要开启的话，需要在实例消息的页面点击开启弹性，进入到实例修改页面，再点开消息弹性的按钮。具体要注意的是在这里可以调整收发信息请求的占比，因为一条消息可能会被多个股东订阅，那这样的话发送一条消息被三个股东订阅，那它的发送消费比例就是1:3，就意味着如果有一条消息的写入会有三个消息的消费，就有三次消费，那整体的TPS就是4，也就是一条消息对应4个TPS。用户可以根据自己的业务场景以及是如何使用这个消息的，自定义设置消息收发的占比。现在先不开启弹性能力，可以看到发送TPS上限是2000，此时先尝试发送2300 GPS时会出现的问题。
可以看到现在基本上每秒成功发送在2200左右，然后其实很多消费都是公司发至线路上去，可以看到报错信息里面会打印出限流阈值。示的是标准TPS标准发送TPS是2000，但是能够跑到差不多2200左右，因为不会限制的很严格，会预留一定的空间，避免边界情况，例如一个用户就偶尔超了一点点的这种情况是不希望对用户造成业务影响的，所以会预留一定的空间。
接下来设置好弹性实例，并且设计触发比改成4:5比，即发送占比改成40%。
现在可以看到已经成功修改了。
那现在再尝试发送2300的TPS，因为这个时候实例实际上应该是可以发送到2400的，还有1600的标准TPS发送和800信息TPS发送。现在已经成功发送300左右个TPS了，并且没有触发任何的限流场景，这已经意味着已经满足了之前的预期情况。以上是本节课的全部内容，如果小伙伴们感兴趣的话，也可以自己根据弹性实例来进行验证。
