小小的在线状态绿点，难道牵出的是一整套分布式状态难题？

摸鱼。 产品经理：「隔壁老王的IM，头像下面有个绿点，咱们也加一个，easy吧？」

简单来说... 如果对方只想到：存个布尔值， 上线置 true、下线置 false，一张 Redis 表搞定，半天的活，那确实 easy！但实际情况是 在 IM 业务场景里尤其是在服务端的 IM 架构设计，不容简单的是它要在「全部看得见它的人」眼里同时也、实时、准确地亮起或熄灭。任意一件没处理良好，用户都会觉得「当前这个在线状态不准」——而不准比没有更糟，这是因为它误导人。

一、 在线状态为哪些是个不容简单题

IM 的在线状态核心问题在于：系统怎么了解某用户此刻在不在线、在哪几个端、对外该体现成哪些。 C位出道。 它的位置很特殊——既是给消息投递用的内部路由依据，又是给终端用户看的产品数据。

1. 让在线状态翻车的三个场景

场景一：上线扇出风暴。 一个 500 良好友的用户打开 App， 若系统老实把「我上线了」推给各个在线良好友，这一下就是上百个推送；早较高峰几十万人同时也上线，当前这个扇出会把推送链路瞬间顶起来。状态本身一个字节，扇出却是 O，动手。。

场景二：状态自己不会熄灭。 上线时置成在线， 但「下线」往往收不到——手机没电、进电梯断网、进程被杀，都不会规矩地发一条「我下线了」。只靠显式事件维护，「永远在线」的幽灵状态越攒越更多，他破防了。。

闹笑话。 场景三：更多端各说各话。 手机、电脑同时也在线，电脑退出后整体状态应当还是「在线」。若状态只是用户级布尔值， 电脑退出一置 false，手机端就被误判离线, 消息走离线推送——用户明明盯着手机屏幕, 却收到一条厂商推送。