微博关注是根据什么来知道你关注我，我关注你了？数据库怎么设计？

Question

如题，我想做个微博，但是关注这快 该怎么操作 用php写。。

Answer 1

建一张表，两个字段：
关注者id
被关注者id

Answer 2

mysql的话，就不说了。这些都属于热数据，如果真的是具备一定规模的微博，查mysql直接死翘翘了。用redis的话，用n个list或sets或hash table+list。名字为前缀+被关注者id,内容就是关注者的id列表或集合。类似:owner:1 = {3,1,5,8,12,64...}
owner:2 = {32,56,22,11,4...}
...
其实最难的设计点在于被关注者发一条微博，而他的所有粉丝需要收到这个消息。楼主想过这个如何实现嘛？
尤其是一个明星，他有上百万上千万粉丝。解决方案有两个思路：1 由被关注者主动推数据
2 由被关注者向粉丝推送一个通知，然后由粉丝去拉数据不过这样就意味着他发一条消息需要有千万个人来访问这张消息表或发一条消息需要写向千万个粉丝的消息表写数据。由于redis的数据结构过于简单，所以完全用其建表虽然可以实现但确实非常麻烦，其实用mongo比较合适。

Answer 3

其实这个我也是看新浪微博的架构师说的,他只说了大概思路，我是根据他的思路联想存储结构如何设计，所以不一定完全正确。第一种方案，应该是每个人都有一张自己的消息表。当被关注者发消息时，会将此消息写入关注者的消息表中，内容大概有被关注者id、消息内容、发送时间。这里最大的问题在于要向千万张表写数据。第二种方案，每个人的消息只存储在自己的消息表中，当自己发消息后，写入。然后由其所有关注者定时从这张表中取数据。或者当自己发消息后，向所有关注者发一个通知，比如发个1,关注者就来自己的消息表取数据。这种方法当某人粉丝数量很多时，会造成这张表的并发读操作非常高。简单的看，两种方案都有利弊。但都还有很大优化空间。新浪微博两种方案都用过。并且在这过程中也摸索出了一些经验。第一种方案他们采取过分批推送的策略，会将用户按活跃度划分几个等级，推送顺序是按照用户活跃度等级来决定的。分批推送一定程度上减轻了负担。第二种方案可以采用冗余多份数据负载均衡的办法将那一张表的并发读操作均衡开。比如我有一张消息表，但这张消息表存储n份，在n台服务器上，内容完全一致。当我发消息时同时向这几台服务器的表写数据，或者分批写入，然后我不同的粉丝，会根据一定策略来决定去哪台服务器读。这里也可以将用户活跃度作为参数，活跃度高的粉丝去服务器a读(服务器a中的消息表在分批写入时最优先被写入)想来想去，方案似乎就两种，但可优化的地方还很多，例如在读取数据时，加入cache层，cache层只存储每个用户最近发表的消息，数据定期归档。

Answer 4

ShadowSniper 你说了一个用户一个消息表，这可能吗？据说新浪有5000万用户，5000万个表是多么庞大的数量阿。

Answer 5

我说的时redis的list或sets结构，不是说mysql的表。建5000万个list和一个list 5000万数据所占内存差别不大。
如果是mysql，建5000万个表不现实，mysql单库也有数量限制。不过根据分表策略肯定要用上。根据用户id算出一个hash值，将5000万用户分别存在n张表，这n张表可能在不同的db服务器上，这也是很常见的策略。

Answer 6

要mysql的话确实是这样建表。
但对于新浪微博这么大的并发量，能实时读写mysql嘛？对于这种热数据，肯定是直接读写内存，然后定期更新至mysql、mongo这些持久化存储引擎。