顺序消费时，消费端如何做主备模式？

Question

啊神老师好：顺序消费的时候，消费端如何高可用？，比如顺序消息全在 Topic-Order, 消费端 ConsumeA 接受消息驱动子业务进行，这个消息比较重要不能停止，假如此时ConsumeA意外故障业务将收影响，有没有什么机制做一个高可用？补充一个ConsumeB,ConsumeA故障后可以切换到ConsumeB？相当于消费端的主备模式？

当时想ConsumeA，ConsumeB 同时启动，但是涉及到业务去重？处理起来感觉比较麻烦，还是请教下阿神老师在实际场景中如何做才最好？

Answer 1

WittChen 3小时前

举个例子重新开一个回答，不然传不了图，面对顺序消费，在设计之初就要避免多Provider端向同主题Broker投递消息

Answer 2

WittChen 3小时前

其实真正难的是怎么保证provider端的有序投递，这也是我来回顾课程的主要原因之一，很遗憾老师并没有设计出这样复杂的业务场景，比如A ->B -> C 三个业务节点，我们要按上述顺序投递，但ABC在三台机器上，乎在毫秒级的时间内处理完业务并生成消息投递到队列中，这样就极有可能造成投递时的无序，如果不做任何处理，将会造成消费时的无序

• WittChen #1

  当然，我觉的之所以难以举例的原因是，像这种严格保证顺序操作的行为不应该出现在消息中间件中，消息中间件是为了让系统解耦，重要的是提升系统的吞吐量，而显然这种严格按照循序消费的模式不适合消息中间件，在程序设计之出就应该避免这样的问题，对我说的是“问题”，就比如老师举例的订单，发货，确认签收，这需要消息中间件掌控吗顺序，这不是很自然的顺序的嘛，只有创建了订单付了前，才会生成发货单提醒商家，这时系统流程控制，不应该是消息中间来控制顺序

Answer 3

WittChen 4小时前

课程买了很久，我是几年后才来回顾的，现在rocketmq发展到了5.x版本，出现了proxy，无论是producer还是consumer都不需要直连broker，新的版本删除了人工操作队列这种复杂业务场景的api，这些交给proxy优化，完全解决了你说的问题主备，你可以起很多个consumer监听主题下的topic，只要保证消费端用的PushConsumer这个类型，对垒只会在上一个消息消费成功后吐出下一条消息，保证了消息的顺序性，前提是你得保证发送的顺序，至于主备，A机器挂了，proxy还连着B机器，一样工作

Answer 4

阿神 2019-03-08 11:41:31

实际看业务需求，如果是关键性业务就需要考虑保证不阻断业务，如果非关键业务就保证消息不丢失即可