新浪微博数据库是如何设计的
从4个层面上面来说:
?
1. Database，其实 @mysqlops 回答就是微薄最基本的数据库方式，我在上面做一下扩展。
cache1，用户最后更新时间 Cache：uid 为 key，timeline[1] 和"帖子列表"[2]为value。 cache2，话题最后更新时间 Cache：kid 为 key，lastupdatime[3] 和"帖子列表"[2]为 value。 cache3，@用户最后更新时间 Cache：uid为key，timeline[4] 和"帖子列表"[2]为value。 cache4，微薄内容表：tid 为 key，timeline[1] 和 content 和 src_tid[5] 为value
?
[1] 这里的 timeline 均为 “微薄内容表A” 中的 timeline
[2] 与该 cache 相关的最后N条微薄内容：array(tid,timeline)，如果有可能的话，可以指向 cache4 中的地址。
[3] 这里的?lastupdatime 为 “话题表B” 中的?lastupdatime?
[4]?这里的 timeline 为 SELECT A.timeline FROM D INNER JOIN A ON a.tid = b.tid
[5] src_tid 可以直接指向 cache4 中对于的内存地址
3.前台页面打开后
首页、话题页面第一次打开：
请参见上面的SQL，换算成Cache也不难 页面前台 < script > 记录SQL返回的第一条微薄的时间?t1。（SELECT TOP 1 ... ORDER BY DESC）?
?
微薄首页Ajax请求： ? ? post你的 t1，和 uid
更新多少条：获取你收听用户的 my_follow_uid_list，循环?my_follow?_uid 查询 cache1 ，如果timeline > t1，就根据 my_follow?_uid 去读取 cache4 的内容和数量。 提到你的：如果 cache3 的内容 timeline > t1 的，就记录下提到你的数量。
然后更改前台最后微薄的时间t1为最后一条微薄的时间
?
4. 发微薄
转播他人话题，实际上也是先分析你撰写的转播内容中的 #话题# 和 @人
唯一是多一个 src_tid 提交
?
这是最基本的数据结构，中间存在很多值得优化的地方。
楼主特别提出了关注1万人，我记得国内微薄收听有限制吧。如果收听人数过多，查询肯定会慢，不过优化 cache1 就能应对，方法比如拆分、存址都可以。
Cache 的话一般选择分布式，就是给机器编号，每个电脑存储不同uid块
?
