Twitter 工程经理 Sarrabh Pathak 在伦敦 QCon 2017 大会上介绍了Twitter 网站的通知系统架构。他主要介绍了Twitter 所面临的独特挑战，比如社交网络的双峰（bimodal）性、如何应付尖刺流量以及如何实现实时的通知机制。
Pathak 解释说，与一般的社交网络不同，Twitter 的用户数据具有不对称性。有些用户有数百万关注者，而有些则只有不到百人。这导致了通知具有双峰性，也给实现实时通知带来了挑战。例如，名人的推文比普通人的推文产生更大的通知负载。
Pathak 说，不同类型的用户以及严格的性能需求给架构带来了如下挑战：
- 延迟：人们要尽可能快地收到通知，毕竟 Twitter 需要实时地通知用户当下正在发生的事情。
- 展开（fanout）：一个拥有数百万关注者的用户，他的一个推文会触发数百万个通知，系统必须能够处理这种大型的尖刺流量。
- 不均衡的调用：有些内部调用，比如访问缓存，只需要几毫秒。而有些外部调用，比如访问 Google，可能需要半秒多钟。在进行伸缩时必须考虑到这些情况。
- 多数据中心：Twitter 必须尽可能地具备弹性，即使发生了故障，也要保证用户仍然能够收到通知。
首先，通知分为推送和拉取两种模式。人们在访问 Twitter 时看到的通知信息流使用的是拉取模式，而短信和邮件则使用推送模式。
Pathak 说，对于拉取模式，通知一般是从缓存里获取的，因为信息流的生成是很耗费资源的。Twitter 使用了 Manhatten ，Twitter 的实时分布式后端存储，也是 Redis 的一个分支。通过使用缓存，最小化了延迟，提升了用户体验。与此同时，通知信息流通过异步的方式被复制到多个数据中心，目的是在发生故障时，用户仍然能够看到相同的信息流。
为了应对延迟和尖刺流量问题，Twitter 使用了推送通知模式，不仅进行横向伸缩，同时还使用了临时缓存。这解决了同一个用户有数百万个通知事件的问题。
为了解决不均衡调用问题，Twitter 使用了优先级队列来防止调用阻塞；名人的推文不会对其他用户的登录造成阻塞。另外，不同类型的调用被分成组，这意味着因外部依赖发生宕机造成的影响是相互隔离的。
最后，Pathak 对该架构进行了总结：
- 尽可能专注在异步操作上，因为它比同步操作更容易伸缩。
- 在权衡读取时间和写入时间时，考虑只写入不太可能发生过期的数据，比如 ID。
- 确保应用能够支持多数据中心部署。
整个访谈可以在线观看，里面还有一个来自Twitter 工程师Gary Lam 关于个人定制化通知的访谈。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论