社交平台中像微博点赞、关注这类 “长列表” 场景的数据库处理藏着很多门道，没处理好很容易出大问题，接下来咱们就仔细聊聊。
“长列表” 场景共性
数据规模差异显著。数据量和内容类相比明显更高，发微博需要用户深思熟虑，但点赞、关注属于无意识操作，很容易形成大量数据。像 2022 年，有用户一年点赞、关注的数量可能达到几千条，而发布的微博数量可能才几十条。
数据分布极度不均。大 V 和普通小透明数据量天差地别。知名大 V 每条微博可能轻松获得几百万赞和关注，而普通用户可能只有几个赞和关注。例如某明星发一条微博能有 500 万点赞，而普通用户可能只有 3 到 5 个。
反向查询需求
用户有互动查看的需要。比如用户 A 点赞了用户 B 的微博，在 B 的微博下面会列出点赞者的列表，方便 B 知道哪些人认可了他的内容。同时 A 也可以在自己的个人页面看到自己点赞过的微博列表，便于回忆和再次查看。
影响社交互动体验。这种反向查询为用户创造了交流的基础，让社交平台更加活跃。要是查询功能不好用或出错，就会严重影响用户的参与感和使用意愿。
基数查询需求
满足查看计数需求。用户既想知道自己微博的点赞数，也想看到自己点赞过的数量，这是对社交影响力和个人兴趣的一种量化体现。以一个职场博主为例，他会关注自己的点赞数来评估内容受欢迎程度，也会查看自己给同行点赞数量来审视自己的学习情况。
辅助内容创作方向。点赞数量和被点赞数量能为用户提供反馈，帮助他们调整在平台上的操作。如果发现某类内容点赞多，就可以多创作这类内容。
早期处理方式弊端
存储瓶颈凸显。早期用单表点赞/被点赞和反向索引，随着用户增多，数据规模剧增，存储难以承载大量数据。比如某个热门话题下的微博点赞，短时间产生几十万的点赞数据，单表很快就会满负荷。
性能与稳定性堪忧。计数类操作开销大，在查询大 V 数据时容易崩溃，而且如果没有分页查全部数据，服务器压力会极大，可能导致系统无法响应。
小规模数据应对策略
缓存与读写分离结合。对于一条微博几十万点赞这种规模的数据，如果是一个 shard 上突发的热点数据访问，可以通过缓存和读写分离解决大部分问题。不少社交平台都是用这种方法优化系统，能提高数据读取和响应的速度。
有效缓解压力。缓存部分常用数据，读写分离可以分配读写任务，减轻数据库压力，确保系统稳定运行。
具体设计方案
Schema 设计优化。避免反向索引，允许分库分表，由于单表多维度查询让数据表难以 shard，可采用业务层双写或统一在关系服务中实现双写逻辑。这样能提高数据的存储和读取效率。
业务层和架构优化。业务层要缓存数据，甚至用 redis 存储，点赞操作更新缓存而非失效缓存；计数类操作也要缓存并先增加计数。开发 “关系服务” 统一解决扩展性问题，让系统更稳定。
你在使用社交平台时，更关注自己的被点赞数还是点赞数？觉得这篇文章有帮助的话，不妨点赞和分享给更多人！
