抖音，作为短视频社交应用的佼莊，据数据显示，其总用户数量已超越八亿大关，每日活跃用户达到七亿之众，人均单日使用时长超过两小时。在如此庞大的用户基数之下，每一个小功能背后都可能蕴藏着复杂的设计逻辑。以用户服务为例，存储八亿用户的数据已经远远超出了单一MySQL数据库单表的极限。本文将探讨在这样的用户规模下，如何实现关注列表与粉丝列表的功能。
抖音上的人与人之间的关系更倾向于一种弱连接的社交模式，即可以单方向进行关注，这一点与微博、等平台颇为相似。相较之下，微信则更注重人与人之间的强连接关系，需要双方互为好友。
打开抖音应用，我们可以清晰地看到三个标签：朋友、关注、粉丝。这三个标签分别对应着不同的功能与操作。
具体来说，关注列表与粉丝列表的运作机制如下：
1. 关注列表支持用户查询自己关注的人，并提供了搜索功能。
2. 粉丝列表则允许用户查看关注自己的粉丝，同样支持搜索操作。
除了基本的读操作外，还有写操作如关注、取消关注、拉黑以及取消拉黑等。
据经验判断，大多数用户的关注数量不会超过五千；而一个普通用户的粉丝数量也是有限的。但像“刘德华”、“邓紫棋”这样的超级大V，其粉丝数量却能轻松突破千万级别。对于这样的超级大V，虽然我们无法为其定制化一张MySQL表，但我们仍需设计一种灵活且高效的存储架构来应对这种极端情况。
在设计存储架构时，我们需要考虑几个关键因素：持久化存储、数据一致性、高性能以及架构的简洁性和资源占用的可接受性。
在数据存储方面，我们可能会采用分库分表的方式来应对庞大的用户数据量。但这也带来了新的挑战，如如何确保在不同分片上的数据读写效率以及分页问题的解决。
为了保持数据的一致性，我们需要在设计时权衡C（一致性）、A（可用性）和P（分区容错性）之间的取舍。在分布式系统中，这三者往往无法同时满足。在粉丝场景中，我们可能需要采用最终一致性方案，通过优先将数据写入一个“关注表”，再通过消费Binlog的方式更新到“粉丝表”。
随着手机配置的不断提升，我们可以考虑将部分数据缓存到手机端的App中，以减少对服务器的依赖并提高响应速度。例如，粉丝列表和关注列表这样的数据就可以缓存到App的本地存储中，并通过一定的更新机制保证服务端和客户端的数据一致性。