这是我参与「第五届青训营 」伴学笔记创作活动的第 13 天
社交方向
关系部分
总体设计
在进行关系部分的设计时，尝试了两种存储方案：
- 使用关系型数据库进行用户关系的存储
在开发初期，对于用户之间关系的存储使用了Mysql这样的关系型数据库进行存储。因为这样比较直观，易于初步实现。
表结构示意如下：
| id | user_id | follow_id |
|---|---|---|
| 1 | A | B |
| 2 | B | C |
但是在开发过程中发现，开发请求查询用户关注列表与粉丝列表时表现尚可，但是在开发请求查询好友列表时发现查询需要进行子查询，查询复杂度比较高，这样可能会在大规模访问的时候，造成很差的性能。
而且考虑到未来大规模数据下可能需要分库分表，那么此时如何分库分表将成为一个难题。
因此考虑使用非关系型数据库进行存储。
- 使用非关系型数据库进行用户关系的存储。
后期开发用户关系部分时，使用如Redis这样的非关系型数据库进行存储。按照最直观的存储方式，对于每一个用户都使用两个列表分别存储该用户的关注列表与粉丝列表。
结构示意如下：
- {userfollowlist}:A->B,C
- {userfollowlist}:B->C
- {userfollowerlist}:B->A
- {userfollowerlist}:C->A,B
在使用非关系型数据库时，需要考虑使用redis中的哪种数据结构来存储用户列表。
这里考虑使用sorter set作为数据结构来实现。使用sorted set的原因有二：
- 通过对于业务内容的分析，我们发现会有许多交集操作需要被执行，比如在登录用户访问其他用户的关注列表等内容时，需要判断这些用户是否被当前登录用户所关注，这就是一个交集操作。而sorted set可以直接取并集，非常方便并且迅速。
- 通过平常对于抖音微博这种APP的使用，可以发现关注列表等都是按照从时间顺序排列的，如关注列表就会从最近的关注到最久以前的关注排列。因此，使用sorted set可以将关注时间作为排序依据的分数，从而获取一个按操作时间有序的关注列表。
