------解决方案--------------------表结构 估计像双链表
------解决方案--------------------建一张表，两个字段：
关注者id
被关注者id
------解决方案--------------------我想微博这么火，应该是赶上智能手机发展的时机了 呵呵
------解决方案--------------------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比较合适。
------解决方案--------------------
这个问题我一直想不明白，只有膜拜的份了
------解决方案--------------------
其实这个我也是看新浪微博的架构师说的,他只说了大概思路，我是根据他的思路联想存储结构如何设计，所以不一定完全正确。
第一种方案，应该是每个人都有一张自己的消息表。当被关注者发消息时，会将此消息写入关注者的消息表中，内容大概有被关注者id、消息内容、发送时间。这里最大的问题在于要向千万张表写数据。
第二种方案，每个人的消息只存储在自己的消息表中，当自己发消息后，写入。然后由其所有关注者定时从这张表中取数据。或者当自己发消息后，向所有关注者发一个通知，比如发个1,关注者就来自己的消息表取数据。这种方法当某人粉丝数量很多时，会造成这张表的并发读操作非常高。
简单的看，两种方案都有利弊。但都还有很大优化空间。新浪微博两种方案都用过。并且在这过程中也摸索出了一些经验。
第一种方案他们采取过分批推送的策略，会将用户按活跃度划分几个等级，推送顺序是按照用户活跃度等级来决定的。分批推送一定程度上减轻了负担。
第二种方案可以采用冗余多份数据负载均衡的办法将那一张表的并发读操作均衡开。比如我有一张消息表，但这张消息表存储n份，在n台服务器上，内容完全一致。当我发消息时同时向这几台服务器的表写数据，或者分批写入，然后我不同的粉丝，会根据一定策略来决定去哪台服务器读。这里也可以将用户活跃度作为参数，活跃度高的粉丝去服务器a读(服务器a中的消息表在分批写入时最优先被写入)
想来想去，方案似乎就两种，但可优化的地方还很多，例如在读取数据时，加入cache层，cache层只存储每个用户最近发表的消息，数据定期归档。
------解决方案--------------------我觉得这个真正难的地方是服务器架构设计，而不是实现方法。再优秀的方法，也无法应对日益增大的数据量，只有调整服务器架构，将压力均衡开，才是长期发展之路。
------解决方案--------------------你就不能说点让人明白的吗？
------解决方案--------------------
跑题了
------解决方案--------------------你们想的太复杂了,确实如此而已:
------解决方案--------------------
