今年花了一些笔墨写推拉系统架构:
- 系统通知,推送还是拉取?
- 状态同步,推送还是拉取?
- 网页消息,推送还是拉取?
- 群已读回执,推送还是拉取?(这个diao)
- 群消息,存一份还是多份?(这个meng)
- feed流,到底什么是读扩散?
- feed流,到底什么是写扩散?
每一篇都是细致展开的案例,绝无花哨的装B。
画外音:每一篇,都先说业务场景,再聊N个方案,以及方案的优缺点,细细品味,定有收获。
点击标题,立刻阅读相关文章。
《系统通知,究竟是推送还是拉取?》
- 系统对1通知场景
- 系统对n通知场景
- 你以为是推?
《状态同步,究竟是推送还是拉取?》
- 服务端状态+客户端状态
- 好友状态+群友状态
- 你以为是推?
《网页消息,究竟是推送还是拉取?》
- 拉,实时性与效率如何保证?
- 推,实时性与效率如何保证?
- 你以为是拉?
《群已读回执,究竟是推送还是拉取?》
- 群消息是如何投递的?
- 群已读回执是如何投递的?
- 群已读回执应该如何优化?
《群消息,究竟存一份还是多份?》
- 存多份,要怎么存?
- 存一份,要怎么存?
《feed流,究竟什么是读扩散?》
《feed流,究竟什么是写扩散?》
- 什么是feed流业务?
- 读扩散的优缺点是啥?
- 写扩散的优缺点是啥?
脱离场景的技术讨论,都是耍流氓。
架构师之路-分享通俗易懂的技术文章
推荐阅读:
《“立体化监控告警平台”-年终总结(一)》
《“区块链与比特币”-年终总结(二)》
《“杀熟杀豪与互联网推荐”-年终总结(三)》
这一系列,花了不少心思,帮转一下?