MQ 就 MQ 好了，保证顺序那什么的是你该干的事儿吗？啊？

[zhengchengdong]

MQ 用来解耦挺好的。我们有个业务，计算用户在线时长，然后触发完成 “每日在线 15 分钟” 的每日任务。登录，登出都发消息，接到消息的程序减一下时间得到在线时间触发任务完成。

我们的系统有个毛病，可能出现闪登闪退，也就是同一个毫秒登录马上登出，这就尴尬了，消费者可能先收到登出再收到登录。这个时候程序员小伙子们可来劲了：“我知道我知道，可以用 MQ 的保证消息顺序能力”，然而被我制止了。我已经受的够够的了，一有什么达不到，立马诉诸各类技术框架的功能。

不急，先想想，登录的业务本质是什么？就是验证身份，成功之后开启一段会话，登出自然就是终结这段会话咯，在线时长就是这段会话的时长。好，那么当先收到登出消息时，无非就是发现这个会话没有开始时间么，但是他确实是一个存在的会话啊，没有开始时间就没有好了，先放着，一会儿登录消息来了那么会话开始时间也就补齐了，可以调用会话的 “计算会话时长” 方法计算在线时间了。

所以这关 MQ 的保证消息顺序什么事？我们是不是做技术做魔怔了？把太多的业务解决方案诉诸技术，系统越来越复杂，在错误的道路上越走越远。。。

[FrankAdler]

水平不高的人有话语权是这样的
block 了

[Habyss]

可是 mq 单队列单消费者, 本身不就是有序的吗.

[Habyss]

@Habyss #42 无序的话,
1. 生产者入队就无序
2. 消费者做了特殊处理,无序
3. 多消费者同时处理,无序
跟 mq 本身没什么关系吧

[Masoud2023]

你们不应该先解决一下闪灯闪退的问题吗

[GeruzoniAnsasu]

> 登录的业务本质是什么？就是验证身份，成功之后开启一段会话

明明你「理解」了本质，怎么还能想出这种结论。


假设你们的系统真的能先收到登出再收到登录，登出的时候，会话在哪？





> 么当先收到登出消息时，无非就是发现这个会话没有开始时间么，但是他确实是一个存在的会话啊，没有开始时间就没有好了

哈？ REALLY? 你是凭什么认为这个登出消息能是一个合法消息的？

[qiyilai]

为什么非要登出才能统计在线时长？好奇怪

[wOuv7i4e7XxsSOR1]

不能保证顺序的 mq 还能叫 mq 吗？

[venglide]

典型的流处理问题，文不对题。

[StyleTnT]

@zihuyishi 想到了梦幻，不退出登录就不用充点卡。

[kelvin_fly]

我理解是两个事情。一是发送到 MQ 的 message 本身就顺序有问题，由于网络波动或者其他啥原因。 另一个是 MQ 保证顺序。 最好在 message 中携带业务的时间戳。
这个计算时长应该业务方自己解决先手顺序，因为只靠 MQ 的顺序也解决不了

[Aresxue]

无非就是顺序消息存在的必要性，答案是有必要。只是说不能一股脑地把问题都丢给中间件以为就万事大吉了，10TPS 有 10TPS 的处理方式，1kTPS 有 1kTPS 的，10wTPS 也有 10wTPS 的，就事论事选择最适合业务的。

[totoro52]

你们的业务好奇怪啊， 计算在线时长，而且是每日任务， 那取当日首次登陆时间，和当前存在时间计算一下不就知不知道满足 15 分钟了吗，
为什么还要去登出登入什么奇奇怪怪的逻辑，登出才出发任务？ 那我一直登着不退出不就不触发这个任务了，难不成你们业务是必须实实在在的计算某一次在线时长满足 15 分钟的？

[nbndco]

@totoro52 我也想说，在线时间计算还能靠登出这个信号么？我都不记得我上次登出任何东西是什么时候了。

[Mikawa]

要不先修一下闪登的问题，然后在线的时候能不能发个心跳包
来自某个必须要登出才能统计在线的游戏的玩家

[totoro52]

@nbndco 游戏可能就会频繁涉及登出登入，但以登出作为计算任务的触发点， 我是没想到，这要是发个在线时长奖励活动， 我岂不是还要把游戏重开一下才能领。。

[nuII]

笑死，主要问题来源不是因为闪登闪退吗？这问题不修，搞其他的有用？

[WashFreshFresh]

怎么先放着，服务维护重启怎么办，存 redis 还是存库？存的话什么时候取出来，登出的时候取出来？
业务就是这样一步步搞复杂的。

[Akiya]

同一个 partition 本来就是保证顺序的。但是 MQ 有序并不能解决你这里秒登秒退的问题。总之 OP 确实有点魔怔

[imokkkk]

我理解 如果项目已经引入了 MQ ，用到这里来解决问题也不是不行，如果单纯为了解决这个问题引入 MQ ，那确实没必要额外在运维一个组件。

[herofire]

你是对的！我必需为此点个赞