新浪微博数据库是如何设计的？
2012-01-19 20:12:34   来源：   点击：

8 个答案

• 答案 1：

  我从4个层面上面来说，1. Database，其实 @mysqlops 回答就是微薄最基本的数据库方式，我在上面做一下扩展。

  微薄内容表A：tid uid src_tid content timeline，其中 tid 是微薄的 ID （自增量），src_tid[1]为转发的源 tid 。

  话题表B：kid title lastupdatime total，total是话题总数，kid 是话题的ID（自增量）

  话题关联表C：id tid kid，id无意义

  @用户关联表D：id uid tid，这里的uid是指被提及人的uid，id无意义

  收听用户关联表E：id uid follow_uid

  上面的 timeline、lastupdatime 均为“发帖时间”，其中timeline是永久不变的字段，lastupdatime 为“该话题最后发帖时间”，属于冗余字段，等同于 SELECT TOP 1 timeline FROM A INNER JOIN C ON C.tid = A.tid WHERE C.kid = #话题id# ORDER BY A.timeline DESC。[1] src_tid 为何可以这样设计的原因请阅读 "4.发微薄"SQL：

  follow 用户列表：SELECT follow_uid FROM E WHERE uid = 102

  微薄首页微薄列表：SELECT content,(SELECT content FROM A AS a2 WHERE a2.tid = a1.src_tid AND a1.src_tid > 0) AS src_content FROM A AS a1 WHERE uid IN （SELECT follow_uid FROM E WHERE uid = 102） ORDER BY timeline DESC

  某 #话题# 列表：SELECT A.content,(SELECT content FROM A AS a2 WHERE a2.tid = a1.src_tid AND a1.src_tid > 0) AS src_content FROM A AS a1 INNER JOIN C ON C.tid=A.tid WHERE C.kid=#话题id# ORDE BY A.timeline DESC

  @我 的列表：SELECT A.content,(SELECT content FROM A AS a2 WHERE a2.tid = a1.src_tid AND a1.src_tid > 0) AS src_content FROM A AS a1 INNER JOIN D ON D.tid=A.tid WHERE D.uid=102 ORDE BY A.timeline DESC

  转播列表：SELECT content,uid FROM A WHERE src_tid = 源tid ORDE BY A.timeline DESC

  2. Cache，主要在cache层是最麻烦的，这需要很多主机和很多分布内存，主要以 hashmap 方式存储（memcache）。hashmap 查询时间会比较稳定。

  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 的，就记录下提到你的数量。

  话题页面Ajax请求: post你的 t1 和话题 kid

  更新多少条：查找 cache2 中 kid 的最后更新时间，如果 lastupdatime > t1 则去读取 cache4 的内容和数量。

  然后更改前台最后微薄的时间t1为最后一条微薄的时间4. 发微薄

  submit；

  通过正则分析出 #话题# 和 @人 的内容；

  提交到对应的数据库：添加“微薄内容”到 表A添加 #话题# 关联到 表C，如果该话题不存在，要先在 表B 中 INSERT更新 #话题# lastupdatime添加 @人 到 表D

  更新对应的cache。

  转播他人话题，实际上也是先分析你撰写的转播内容中的 #话题# 和 @人唯一是多一个 src_tid 提交====================================我这是最基本的数据结构，中间存在很多值得优化的地方。楼主特别提出了关注1万人，我记得国内微薄收听有限制吧。如果收听人数过多，查询肯定会慢，不过优化 cache1 就能应对，方法比如拆分、存址都可以。Cache 的话一般选择分布式，就是给机器编号，每个电脑存储不同uid块

• 答案 2：

  谈谈个人看法：微博技术架构的关键点在于如何优化Cache和消息队列的使用效率，以及合理规划数据存储方式。如此海量的数据推送必然是通过异步消息队列处理，而不是简单的数据库直接写入，因此系统的负载压力会逐层分散到后端数据库上，并不是集中于某几台数据库上。新数据通知，应该通过各种基础服务预先计算出的数据集合，再通过客户端每30秒的轮询请求返回，并非请求后的实时计算，因此压力可能更多的集中在cache层上。

• 答案 3：

  这个问题的答案好像很复杂。可以看下新浪微博架构师TimYang的《构建高性能的微博系统——再谈新浪微博架构》infoq.com/cn/articl...-----------------不好意思，贴错了链接。 这个才是对的 infoq.com/cn/presen...

• 答案 4：

  了解推和拉2种模式，其中一楼的朋友说的非常对，这样的应用都是：MC+消息队列+数据库的应用，而且数据库肯定进行垂直+水平拆分的参考链接：mysqlops.com/2011...

• 答案 5：

  有新微博和comemnts提示很容易实现的.看你的思路了

• 答案 6：

  可以了解下推模式和拉模式这个不单单是数据库的设计

• 答案 7：

  这个分析得这么透彻。

• 答案 8：

  不是Redis么