粉丝关系链，10亿数据，如何设计？

这次不是需要一个周期扫描的离线工具了，而是一个实时订阅消息的服务不停的收消息。假设正常情况下，msg1和msg2的接收时间应该在3s以内，如果检测服务在收到msg1后没有收到msg2，就尝试检测数据的一致性，不一致时进行补偿修复

优点：

• 效率高
• 实时性高

缺点：

• 方案比较复杂，上线引入了消息总线这个组件
• 线下多了一个订阅总线的检测服务

however，技术方案本身就是一个投入产出比的折衷，可以根据业务对一致性的需求程度决定使用哪一种方法。

总结

(1) 关系链业务是一个典型的多对多关系，又分为强好友与弱好友

(2) 数据冗余是一个常见的多对多业务数据水平切分实践

(3) 冗余数据的常见方案有三种

• 服务同步冗余
• 服务异步冗余
• 线下异步冗余

(4) 数据冗余会带来一致性问题，高吞吐互联网业务，要想完全保证事务一致性很难，常见的实践是最终一致性

(5) 最终一致性的常见实践是，尽快找到不一致，并修复数据，常见方案有三种

• 线下全量扫描法
• 线下增量扫描法
• 线上实时检测法

希望大家有所启示，思路比结论重要。

【本文为51CTO专栏作者“58沈剑”原创稿件，转载请联系原作者】

戳这里，看该作者更多好文

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!