社交网络里的关注实现（类似 V2EX 的关注）

[hambman]

需求：用户关注一批用户，获取他们的动态。

特大规模类比新浪微博 但是对于中等应用，比如一个用户关注～ 100 个用户左右 (明星用户有～ 1 万个关注者），简单的数据库查询，如果暂不考虑 redis 等 cache 方案的话，能否支持 10 万左右的用户体量。

可以请 @livid 分享一些经验？

select topics where author_id in (用户关注的用户列表，100 人左右)。

[Mitt]

这点量还不成问题吧，做好索引就行了

[js8510]

如果是纯考虑 sql 数据库的话，假设考虑用户访问同一个 DC： （ 1 ）做一些 sharding 这样可以并发 select 请求。 (2) 做 replicates， 一个 master write only 然后 replicates read-only. 因为“动态” 听起来对一致性要求不高，而更在乎 延迟 (3) sql 数据库里只放纯 metadata(id, e.g topic id, item id, post id etc) 这样可以减少 DB read/write bandwith cost 把具体内容的分发剥离出去 暂时考虑这么多。


一个很好的演讲全面的介绍了 Twitter 的很多年前的解决方案。
Operations at Twitter: Scaling Beyond 100 Million Users": <amp-youtube data-videoid="z8LU0Cj6BOU" layout="responsive" width="480" height="270"></amp-youtube>&t=1s

[sugarkeek]

10 万不多吧，又不是同时十万个人关注，淅淅沥沥的那几个量，常见的数据库都没啥问题

[owenliang]

实际工程上会用 hbase，现在也可以看看 tidb 了。

[hantsy]

用 key/value 数据库啦，我是搞不懂为什么国内都是喜欢什么东西都是往 RDBMS 里面塞。

[BiteTheDust]

有一种做法似乎是 维护用户的时间线 在一个人发送了动态后向所有关注者的时间线插入数据

[love]

老问题了，一搜一大把。有推和拉二种，一般用推是保险做法，用拉以后可能会出大性能问题。

[areless]

in 配合 exists，在大用户上使用 exists，10 万用户应该扛得住。不要给页码，只有上一页下一页以及超时直接抛错，慢查询独立处理。

[buliugu]

新浪微博貌似是大规模使用 redis 的

[chengxiao]

印象中 KV 数据库在国内大规模的兴起和使用,就是因为社交网络

[hambman]

@BiteTheDust 恩，这个是“推”模式，用户少的时候也可以。

[hambman]

@chengxiao @hantsy 这个场景，请问用 key/value store 的优势是哪方面？ 要两个查询，第一步得到关注的对象，第二步查询这些关注对象的文章。 是量大以后 scale 的优势吗？

[hambman]

@love 恩，我查询了一些经验。我理解是反过来？如果一个用户有 1 万人关注，他每发一条帖子数据库要插入 1 万条记录？

[hambman]

@areless 请问不给页码的优势是？我实现上一页，下一页，是用?page=(n-1) 和 ?page=(n+1)的方法，和页码本质是一样的，有更好的方法吗？

[hambman]

@js8510 谢谢建议，恩，应该会用到 2)和 3 ），如果数据量大的话也会用 sharding.

[love]

@hambman 对呀，现在有每个人有个接受邮箱，大 V 发个帖就是群发，其实只是看着有点可怕，毕竟又不是人人都是大 V 。比如 10 万个人每个人的接收队列每天会收到 100 条消息，那相当于一天中每秒只要插入 100 条记录就行了。

[e583409]

本质上是一个 feed 流实现了吧
关系只是一部分，另一部分是 feed 流
关系可以存 kv，mongodb 这些，feed 流这块比较复杂 没有多少经验

[e583409]

可以看看微博架构 演进路线