习惯用 GitKraken ，感觉最好用

推荐公益站 ai.dooo.ng ，Codex 4.5 随便蹬，每半天刷新 200$

ios 谢谢～ c2hhd3llcnBlbmdAZ21haWwuY29t

哈哈哈哈哈够味儿

我怎么感觉没有恶意标记文件呢？为什么会扫出来 pifox LevelDB: MALICIOUS MARKERS FOUND 呢？跑命令还有自己去目录下('~/Library/Application Support/apifox/Local Storage/leveldb')找了都没有_rl_headers 、_rl_mc 、af_uuid 类似文件

MALICIOUS MARKERS FOUND 这就是中招了？

c2hhd3llcnBlbmdAZ21haWwuY29t 感谢~

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

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

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

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