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

[zhengchengdong]

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

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

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

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

[AItsuki]

你是对的

[sunwei0325]

复杂业务还是需要 MQ 保证顺序的, 不然 aws 的 SQS 也不会设计一个 FIFO 队列了

[Plutooo]

MQ MQ ，Message Queue ，我觉得需要 Queue 有顺序没有什么问题

[54qyc]

OP 也魔怔了，看见别人用顺序消息就开始脑补开始喷了？别人思路必须跟你一样？你要是不接受有序消息，你不能反问别人还有没有其他的解决方案？上来就是恶意假设？不过这里顺序消息也根本处理不了秒登秒登出场景。生产的时候并不能保证先生产登录 后生产登出，如果是有多个应用服务器的话。

[coderzhangsan]

看问题的角度不一样，程序员从技术角度要保证业务的可靠性和严谨性，没什么问题，需求交互场景细节这个可以沟通，按照需求调整，没必要鸡蛋里挑骨头。

[B1acKy1in]

个人理解是简单的业务，消费者那里缓存下，然后验证下时间戳就够了；复杂系统还是搞点组件（甚至搞个服务）来处理下吧，毕竟复杂业务的架构跨度太大了，很难说哪里有啥问题。

[zihuyishi]

这个计算在线时长的逻辑不太合适吧，如果我今天不登出意思就完成不了这个任务了？
如果以后要做防沉迷是不是我只要一直在线也可以一直玩下去了

[k9982874]

取出最后登录时间，登出时间一减就成，确实不需要 mq 。
但是 op 的态度是真的让人讨厌。

[opentrade]

程序闪退了，就不计算我的在线时长？

[shalk]

如果登入消息丢了呢，这个时长就不记录了么

[yibinhp]

@sunwei0325 请教一下，多消费者的情况下怎么保证 mq 有序消费啊

[Jooeeee]

如果登录登出是同一个 mq ，且 mq 有这个能力，为什么不用呢。
另外，这个需求看着不需要很精确，没有登录消息，就当是 5 分钟好了

[lsk569937453]

我是看了标题进来的，只能说你的应用场景可以不用 MQ 。

但是针对你的标题，我想说 MQ 确实需要一个保证顺序的功能。

比如现在主流的分布式事务的解决方案就是分布式消息，而分布式消息里面很重要的一点就是 MQ 的消息必须是顺序的。

[Goooooos]

@yibinhp

不同 MQ 有不同的实现。kafka 可以通过指定 key 让同一个 key 的消息落到同一个 partition

[sunwei0325]

MQ 保证顺序, 主要是因为分布式服务以及服务器网络通信等因素, 造成的 AB 消息入队, 结果是 BA 消息出队这种情况.

但是如果像闪退闪登这种, 2 个事件一起发, 很可能由于网络, 客户端先发的登出消息, 后于登录消息到达 MQ, 这种情况下, 即使 MQ 保证顺序, 消费者看到的依然是乱序.

上面说的这种情况可以借鉴 Flink 的 watermark+window, 由业务进行补偿处理, 虽然 IngestionTime 是乱序的, 但是 EventTime 是有序的.

[wolfie]

mq 消息存储没有时间戳吗。

多实例多线程 消费一个队列 如何应对。

[Pantheoon]

队列的本质就是先进先出

[kingfalse]

功能实现了吗？实现了就没毛病！毕竟每个人都有自己的骚操作。

[GopherDaily]

你菜

[makersy]

这标题就有问题。MQ 也是 queue ，保证顺序为什么不是 queue 该做的事情？