常见系统设计题系列-微博计数系统

数据库

数据库 + 分库分表

方案的问题：

1. 如果不分库，性能扛不住
2. 如果按照时间分库分表，存在热表问题（越新的微博，越容易被访问）
3. 如果按照id取模的方式，扩展性不够。

数据库 + 缓存

最大的问题：

1. cache需要访问好多空数据（好多微博的count为0）
2. cache 太贵了，尤其是redis，redis的有效内存利用率比较低。（如果key特别特别多，用redis特别昂贵，这个时候需要考虑自研服务了）

方案三: 自研Counter服务

可以利用的点：

1. 大量微博(一半以上)是没有转发，或者没有评论，甚至是没有转发也没有评论
2. 各种计数（评论数、转发数）通常一起展现。
3. 大量的微博的count并不会很大，是没有必要寸long类型的。那那些超过65535的呢？

参考：https://www.cnblogs.com/kenshinobiy/p/4316217.html

---

系统通知未读数：全量用户， 全局递增ID相减

系统通知的小红点：每一个人有一个时间戳 PK 全局时间戳

关注的未读数 = SumOf（每一个关注的人的最新值 - 上一次访问快照中的历史值）