ShawyerPeng

c2hhd3llcnBlbmdAZ21haWwuY29t 已注册，感谢

@leosj 大佬能不能分享一下你的提示词呀？我用 Antigravity 生成的代码竟然跑步起来，让他排查 bug 验证花了 15 分钟也没解决。我用 Codex 也不能很完美地复刻。

你们这种抢注域名的 s 骗子 kling3.live 什么野鸡

已支持

@z1829909 有道理，不过消息队列 by partition 串行化，可以不用这么重的有序消费功能实现吗？

@zdking08135 问题 1 ，我在楼上回复了~是业务方因为某些原因，举个例子把 1 点到 2 点之间的所有操作攒到一起最后都为完成状态时，才一起上报过来（还不是批量上报，而是拆分成明细行进行上报，消费方无法在一个请求中在内存中处理 N 个时间窗口的更新逻辑，当然了，MQ 可以攒一批消息进行批量消费）
问题 2：业务的异常 case ，代码逻辑会做异常处理，本问题可以忽略不考虑
问题 3 ，不同的作业类型不一样，可能 1 秒一个，也可能十几分钟才做完一个任务。

@fkdtz 有一种比较恶心的场景就是，业务的单据模型是有主单和明细维度，作业数据的上报时机是主单状态为已完成（即所有的明细都为已完成时，当然，每个明细可能有各自的操作人和完成时间），所以要等到最后再一起上报。
业务方由于某些实现原因，无法一次请求批量上报，而是拆成每个明细进行上报。所以对本系统的消费者来说，有高并发更新的场景（一个主单可能有几百个明细）。
我也想到了 Batch Consume 攒一批消息批量消费，确实一定程度上解决了这种情况下的并发问题。

不过我在想有没有多种方式配合起来实现会更加完善。例如直接分布式锁/消息队列串行化。
您说的串行，在 RocketMQ 里的实现，可以使用有序消息实现。
对于 Producer 来说，自定义负载均衡策略，根据操作人 operator 字段做 partition key ，路由到固定的一个 Message Queue ；
对于 Consumer 实例来说，通过 MessageListenerOrderly 顺序消费的实现（包括：拉取消息时消费实例对 MessageQueue 加锁、消费消息时线程池中的线程对 MessageQueue 也加锁、对 ProccessQueue 也加锁保证 rebalance 了也要等到提交 offset 才能让新的消费者消费）。
但是有序消费消费失败会原地重试阻塞其他消息消费的特性，和我们的场景是有冲突了。
我们的目标只是为了尽量避免并发冲突，而不需要如此严格的有序性。串行化消费有更好的办法吗？