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

[zhengchengdong]

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

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

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

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

[milkpuff]

楼主说的对。我赞同。
我觉得楼主的重点在于”把太多的业务解决方案诉诸技术“，这一点指出得准确

[leonshaw]

这是重排，不是保序

[GuangXiN]

MQ 不是 Message Queue 的缩写么？ Queue 不保证 FIFO 还叫 Queue 么？

[cp19890714]

挖掘业务本质, 是个很难但是非常重要的能力. 这个能力难以通过固有的教程去训练.
对于人来说, 技术能力可以通过已有的教程文档快速掌握, 自然就会依赖技术.

[PVXLL]

都是菜鸡

[ShuWei]

通过两条消息的时间差去计算在线时长，这真的是个好的方案么？会不会，这个方案从一开始就是有问题的

[adoal]

“我们的系统有个毛病”……你看，你自己都知道是业务系统的毛病，不去解决毛病也就罢了，毕竟屎山不能乱动，以防溅一脸屎汤。人家要在外围用技术手段来把你这业务系统这端的毛病给人家外围附加功能带来的困扰 workaround 掉，你还怪人家做技术做魔怔了。“系统越来越复杂，在错误的道路上越走越远”是“把太多的业务解决方案诉诸技术”导致的吗？你们这群技术不重要业务该被舔的嘤嘤怪，心里真的没有点碧树吗？

[IvanLi127]

MQ 有复杂的也有简单的，你知道人家说的是什么 MQ 吗？

[neoblackcap]

就这样的统计功能都要放在业务系统里面做，那什么系统跑不死啊。登录，登出的事件写日志（进 MQ 再落地也一个道理），直接通过回放日志，简单统计一下当天是否有超过 15 分钟的在线就得了。而且还不会对业务系统产生影响，因为这需求可以做成实时的，也可以做成离线。
OLAP 的活就不要压业务系统了。

[SeaTac]

> 我们的系统有个毛病，可能出现闪登闪退
不先把系统的问题修一修么

[xuanbg]

1 、我不懂闪退为啥还能有登出动作？
2 、计算在线时长不是应该用 redis 吗？用 MQ 做啥？

[haochih]

你是对的

[jguo]

“我喜欢和聪明人交往，因为不用考虑他们的尊严”。讨论技术问题别上来就开启防御姿态。

[dongdong12345]

第一反应是修复这个登入登出的毛病

[me1onsoda]

@yibinhp 一个消费者对应一个 broker

[zsdroid]

系统有毛病不管，先来发帖喷一喷别人。op 牛逼。

[msaionyc]

“先放着”是什么意思，这条消息怎么处理？
如果这个消息处理的地方为这个行为做个补丁，其实也等于提高了系统复杂度，后人接手时也会摸不着头脑，为什么这么做

[ecareyu]

其实 up 主，你说的压根就是两件事，但也可以说是一件事，就是，产品思维和技术思维，技术一般很难跳出技术思维这个圈，但是很多以产品思维来想，有些事，确实没必要完全通过复杂的技术实现，因为用户根本不会 care 。你要没必要喷那个小伙，毕竟，他只是个技术，你让他往产品想，那属实有点隔行如隔山了。

[zhazi]

笑死，op 来找认同，结果被按着头喷。
水平不高的人当 ld 是这样的

[Leviathann]

mq 保证的不是入队的顺序吗，入队就是乱的保证什么？