【设计】关系类业务

后端设计中，常常有一种场景，就是关系类的存储。比如订阅或者关注等。就以关注为例。

通常来说，记录关注关系，需要落地到db，那么表结构大概是怎样的？

很容易想到的一个表结构：

id：自增id；

userId：被关注用户id；

followerId：关注用户id

核心信息其实就这几个。这个表可以解决简单的场景。

但是当数据量越来越大，可能需要搞缓存。那么缓存怎么存？第一反应应该是一个set。并且，对于关系类的查询，应该需要两个缓存。一个查某一个用户关注的人（关注列表），另一个查某一个用户被哪些人关注（粉丝列表）。这俩缓存都是可以从上述db里面回源到。

（这里也反映了关系型数据库和对象模型的区别）

有了缓存又可以支持一定的请求量了。

但是终究有一天db还是扛不住。可能需要分表。这时就有问题了，如果我按照userId分表，那么只能查询某一个用户被哪些人关注了（粉丝列表）。如果我要查关注列表只能遍历所有的分表。所以，只能再搞一个db，原来的按照userId分表，查粉丝列表。新的db按照followerId分表，用来查询关注列表。

这个设计应该是可以满足绝大多数场景了。

所以对于关系类的存储，设计上可能需要两份缓存和db。