爱思考小美在设计完成# 解密亿级流量【社交关注关系】系统设计后，猛然想起曾经的leader王哥提到的一句话。“系统设计之初就要考虑，未来如何实现平台化，接入更多的产品线”。
小美开始思考，公司内除了主要的App产品，一直在尝试探索新的业务，每年都会推出新的App。
“如果有社交关系中台（平台），可以接入多个业务线，那么将会大大降低新产品的开发工作量，减少了公司的重复建设”。小美在心中已经盘算，如何改进之前的方案设计以便支持新业务的接入。
需求场景的分析
小美分析，社交或内容类App 关注关系的场景是比较通用的。用户的行为包括核心的关注、取消关注、拉黑等。查询的场景包括查看关注列表、粉丝列表。系统会不同的页面也会查询A是否关注了B、A是否关注了这些用户、用户A B的共同关注。 还有一些其他功能依赖于推荐系统，比如 用户A可能认识的人功能。基本诉求基本都是通用的，个性化的诉求并不多。
小美认为 无论是内容式、社交类产品关注关系的需求基本都是通用的，新的App无需重复性设计，那样既费时费力还浪费系统资源（需要大的redis集群、分库分表、服务器等）。于是小美重新改进了之前的方案设计
产品线的定义
新接入的业务需要分配一个新的产品线 bizId。
系统设计的修改
关注关系系统的基本读写操作都需要指定产品线Id。包括关注、取消关注、查看粉丝列表、查关注列表、查是否关注等接口上游在调用时需要明确自己是哪个产品线。
因此小美对原有的存储模型进行了改动。
classDiagram
class Follow 分表键fromUserId {
long id,
int bizId, ##新增产品线Id
long fromUserId, //主动关注者
long toUserId, //被关注者
long source, //关注页来源
int status, //状态
long ctime,
}
class Fans 分表键 toUserId{
long id,
int bizId,##新增产品线Id
long fromUserId, //主动关注者
long toUserId, //被关注者
long source, //关注页来源
int status, //状态
long ctime,
}
小美在Follow表和Fans表都新增产品线字段。Follow表的唯一键是FromUserId+toUserId。现在也需要改成bizId+FromUserId+toUserId。Fans表反之同理。
这样关注关系的底层存储唯一键改动，可支持多个业务的关系存储。有了产品线Id做隔离，用户A在多个产品的关注列表就不会冲突。
小美同时改动了Redis的存储方案。方式也是如此，存储依然使用Hash结构，在大key UserId前增加了产品线Id前缀，小key依然是用户关注的UserId。
在读写关系系统的每一个接口都新增了产品线字段。同时为了避免上游使用错bizId，进行误调用。小美为不同业务线封装对应的Client。这样每个上游使用的Client接口都不相同，小美在Client中帮他们屏蔽了产品线Id字段。
在设计完这些后 小美不禁感慨 “在系统设计之初，新增一个产品线字段，成本低收益高”。
“一个小小的产品线字段就能让系统从单一业务系统，变成通用的基建平台。 还有比这性价比更高的设计吗？ ”。小美开心的想。
各位兄弟姐妹们，如果觉得本文没有注水，关注、点赞、收藏转发，怎么方便怎么来，小弟在此拜谢了。你的一次点赞就足够让我开心一上午。比心
