@
fkdtz 有一种比较恶心的场景就是,业务的单据模型是有主单和明细维度,作业数据的上报时机是主单状态为已完成(即所有的明细都为已完成时,当然,每个明细可能有各自的操作人和完成时间),所以要等到最后再一起上报。
业务方由于某些实现原因,无法一次请求批量上报,而是拆成每个明细进行上报。所以对本系统的消费者来说,有高并发更新的场景(一个主单可能有几百个明细)。
我也想到了 Batch Consume 攒一批消息批量消费,确实一定程度上解决了这种情况下的并发问题。
不过我在想有没有多种方式配合起来实现会更加完善。例如直接分布式锁/消息队列串行化。
您说的串行,在 RocketMQ 里的实现,可以使用有序消息实现。
对于 Producer 来说,自定义负载均衡策略,根据操作人 operator 字段做 partition key ,路由到固定的一个 Message Queue ;
对于 Consumer 实例来说,通过 MessageListenerOrderly 顺序消费的实现(包括:拉取消息时消费实例对 MessageQueue 加锁、消费消息时线程池中的线程对 MessageQueue 也加锁、对 ProccessQueue 也加锁保证 rebalance 了也要等到提交 offset 才能让新的消费者消费)。
但是有序消费消费失败会原地重试阻塞其他消息消费的特性,和我们的场景是有冲突了。
我们的目标只是为了尽量避免并发冲突,而不需要如此严格的有序性。串行化消费有更好的办法吗?