查看原文

Presence 系统说白了就是那套标记在线隐身正在忙这些状态的系统，LinkedIn 使用的技术栈是 Play Framework & Akka Actor Model，处理的流量量级为 1.8K QPS。

从业务上来说，要存储的数据自然是 online status + timestamp，挑战倒不在数据存储，而是怎么把这样的数据变更推到 C 端该用户的关注者，特别是那些正停留在该用户页面上浏览的那些用户。关于推送这个流程，Linkedin 的做法是浏览器保持实时连接，然后引入 Pub/Sub 系统，让这个实时连接去 Sub 另外一个用户的 user presence topic。当某个用户上线了，Presence Platform 就 Pub 消息到频道，这样另外一边的用户就收到推送了。

这个系统要解决的另外一个大问题是用户反复上线下线给系统造成不必要的压力，这可能会是用户网络情况不给力等原因。LinkedIn 的做法倒也简单，实时连接加上一个心跳，一轮心跳 N 秒钟，在这段期间内用户就算一直登录。后端用一个分布式的 K/V 数据库刷新用户的 online status 和时间戳，数据库会在心跳过期一段时间后清掉状态，完成下线的更新。另外他们引入了 D2 负载均衡，让用户 ID 尽量哈希到同一台机器。毕竟这种场景，Sticky 的处理性能比较高。

后端将心跳和状态更新的数据推到 Akka 系统处理消息。Akka Actors 封装了如何处理消息的状态和行为，然后将消息通过轻量线程被递送到其它 Actors 那里。整个系统可以处理上百万的 Actors。