ShawyerPeng

已支持

@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 才能让新的消费者消费）。
但是有序消费消费失败会原地重试阻塞其他消息消费的特性，和我们的场景是有冲突了。
我们的目标只是为了尽量避免并发冲突，而不需要如此严格的有序性。串行化消费有更好的办法吗？

@emmmbu select for update 在高并发场景下性能很差吧

@crysislinux 感觉好像要解决的问题不太一样？我是想在高并发场景解决：来了一个值 c ，如果它在[a, b]窗口范围内，没拿到锁，则不允许更新滑动窗口的左区间或者右区间（如果 c < a 则更新为[c, b]，如果 c > b 则更新为[a, c]）。
因为我要防止并发更新，所以要锁住这个窗口范围。

@zpfhbyx 我们需要保证是近实时的分析，由于逻辑复杂（比如需要实现超时机制，一个人中间一直没有作业的休息间隔超过 20 分钟则需要终止这段作业时长统计；还需要有不同作业类型切换的顶替机制；还有时长跨天拆分机制，把原来的一条数据库记录一拆为二，保证单据绑定正确日期的工时）很难放到离线 HSQL 中实现正确的统计逻辑。

@MidGap 两个线程同时读到当前数据库的那一行 startTime = 100, end_time = 200
线程 A 上报的作业时间为 201 ，这时候想更新右区间（在线程 B 更新后才更新）：update end_time = 201
此时线程 B 上报的作业时间为 202 ，B 先成功更新数据库右区间：update end_time = 202 。
线程 A 此时才去更新数据库 update end_time = 201 ，这时候把值 202 覆盖了，出现问题。

@namenone 感谢思路，想问下这种分布式锁间隙锁的场景 有成熟的方案吗？
考虑到管理 key range 范围的秒级分片粒度锁的原子性获取和释放，感觉实现的复杂度还是挺大的。
另外，用布隆过滤器优化，感觉这几个地方还需要考虑：
1. 布隆过滤器的判断和加锁也是非原子性的
2. 布隆过滤器误判的场景：返回存在，但实际不存在锁。会导致误以为该间隙被锁。如果再去查 Redis ，这个操作在高并发场景也不能保证原子性吧？