关于rocketmq消息顺序消费的几点疑惑？
了解rocketmq的同学都知道 broker 和queue ，消息其实是存在queue中的。一个broker其实类似于一个rocketMq服务。
我们在rocketmq可视化控制台创建topic的时候，是可以选择，你这个topic要创建多少个queue的。
queue的大小也直接影响到消费者的消费能力。
比如你topic 有4个queue 那么就可以支持4个消费者来消费。一对一
如果你有两个消费者，那么就 一个消费者分配2个queue。
如果你有5个消费者，那就闲置一个queue。
比如这样的业务场景，一个订单有 下单->支付->确收 这三个流转状态。消费端肯定要按照 下单->支付->确收 这样的流程走。那就要保证
消息的顺序性，要不然，消费端先获取到了确收的消息，但是一查数据还没这个订单岂不是乱套了。（注意：这个仅仅是打个比方，意思到了就行）
环境：topic 2个broker 8个queue （重点是我创建的这个topic有8个queue，每台broker里面有4个queue）
如果我们想让消息顺序消费，其实只需要保证消息都跑到一个queue中就行了。（注意：这里不考虑单broke，单queue的情况。就是多broker，多queue）
那么我们怎么保证这个消息跑到一个queue呢？
在java的api中，我们是可以指定发送queue的策略的，比如发送消息的时候可以根据订单ID % 8 = queue的索引。
这样是可以保证相同的订单一定会跑到同一个queue。
到这，铺垫结束，我的疑惑来了。
1、如果我想扩大或者减少这个topic的queue，有对应的api么？
2、如果我这时候又添加了一个broker，变成了三台，那么会影响老的topic？因为我当时创建的时候这个topic是8，（我感觉是不会变的）
3、现在是三个broker，我又创建了一个topic，还是8个queue，那么queue的分布 是不是就变成了 3 3 2 这样了？
我觉得加broker是不会改变原来的topic的queue个数的，因为创建的时候已经指定了，应该也没有可以修改topic的queue的api。盲猜如果是想改变的话，那么重新建一个topic拉倒了。（只是猜测）
如果我上面的猜测 是正确的话，那么这个queue的个数是不变的，那么根据策略指定落在那个queue，这个方法也可行。如果这个topic的queue的个数可以修改的话，那么根据策略指定queue就走不通了。
4、还有个问题是，比如遇到洪峰情况，因为queue就8个，导致消费端的消费能力不够，想扩大下queue的数量提高消费能力，这时候应该怎么办？
难道是 洪峰来之前，加机器，然后重建topic的时候增加queue的数量，洪峰走之后再重建topic，减少queue？ （感觉不会这么做吧，忒麻烦了么吧）
除了4的问题外，搭建个集群环境动手试一下其实就能得到答案，但是在试验之前还是想发帖讨论下，因为我觉得技术问题这东西，大家一起讨论讨论，可能会有意想不到新的收获。
以上是 关于rocketmq消息顺序消费的几点疑惑？ 的全部内容， 来源链接： utcz.com/p/944791.html
