分類: 問答 常識詞典 編輯 : 常識 發(fā)布 : 10-04

閱讀 :435

新浪微博數(shù)據(jù)庫是如何設(shè)計的？如果一個用戶關(guān)注了10000個人,如果這些人有更新了,系統(tǒng)會提示有新微博,這是如何實現(xiàn)的？如果有人給你評論了,系統(tǒng)也會提示出來,我知道頁面會定時-新，但是這后臺負擔也太大了吧？ 在這方面有沒有高性能的架構(gòu)或技術(shù)什么的呢？8 個答案

答案 1：

我從4個層面上面來說，1. Database，其實 @mysqlops 回答就是微薄最基本的數(shù)據(jù)庫方式，我在上面做一下擴展。

微薄內(nèi)容表A：tid uid src_tid content timeline，其中 tid 是微薄的 ID （自增量），src_tid[1]為轉(zhuǎn)發(fā)的源 tid 。

話題表B：kid title lastupdatime total，total是話題總數(shù)，kid 是話題的ID（自增量）

話題關(guān)聯(lián)表C：id tid kid，id無意義

@用戶關(guān)聯(lián)表D：id uid tid，這里的uid是指被提及人的uid，id無意義

收聽用戶關(guān)聯(lián)表E：id uid follow_uid

上面的 timeline、lastupdatime 均為“發(fā)帖時間”，其中timeline是永久不變的字段，lastupdatime 為“該話題最后發(fā)帖時間”，屬于冗余字段，等同于 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 為何可以這樣設(shè)計的原因請閱讀 "4.發(fā)微薄"-L：

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

轉(zhuǎn)播列表：SELECT content,uid FROM A WHERE src_tid = 源tid ORDE BY A.timeline DESC

2. Cac-e，主要在cac-e層是最麻煩的，這需要很多主機和很多分布內(nèi)存，主要以 -as--p 方式存儲（memcac-e）。-as--p 查詢時間會比較穩(wěn)定。

cac-e1，用戶最后更新時間 Cac-e：uid 為 key，timeline[1] 和"帖子列表"[2]為value。

cac-e2，話題最后更新時間 Cac-e：kid 為 key，lastupdatime[3] 和"帖子列表"[2]為 value。

cac-e3，@用戶最后更新時間 Cac-e：uid為key，timeline[4] 和"帖子列表"[2]為value。

cac-e4，微薄內(nèi)容表：tid 為 key，timeline[1] 和 content 和 src_tid[5]為value

[1] 這里的 timeline 均為 “微薄內(nèi)容表A” 中的 timeline[2] 與該 cac-e 相關(guān)的最后N條微薄內(nèi)容：array(tid,timeline)，如果有可能的話，可以指向 cac-e4 中的地址。[3] 這里的lastupdatime 為 “話題表B” 中的lastupdatime[4]這里的 timeline 為 SELECT A.timeline FROM D INNER JOIN A ON a.tid = b.tid[5] src_tid 可以直接指向 cac-e4 中對于的內(nèi)存地址3.前臺頁面打開后，首頁、話題頁面第一次打開：

請參見上面的-L，換算成Cac-e也不難

頁面前臺 < script > 記錄-L返回的第一條微薄的時間t1。（SELECT TOP 1 ... ORDER BY DESC）

微薄首頁Ajax請求： post你的 t1，和 uid

更新多少條：獲取你收聽用戶的 my_follow_uid_list，循環(huán)my_follow_uid 查詢 cac-e1 ，如果timeline > t1，就根據(jù) my_follow_uid 去讀取 cac-e4 的內(nèi)容和數(shù)量。

提到你的：如果 cac-e3 的內(nèi)容 timeline > t1 的，就記錄下提到你的數(shù)量。

話題頁面Ajax請求: post你的 t1 和話題 kid

更新多少條：查找 cac-e2 中 kid 的最后更新時間，如果 lastupdatime > t1 則去讀取 cac-e4 的內(nèi)容和數(shù)量。

然后更改前臺最后微薄的時間t1為最后一條微薄的時間4. 發(fā)微薄

submit；

通過正則分析出 #話題# 和 @人 的內(nèi)容；

提交到對應(yīng)的數(shù)據(jù)庫：添加“微薄內(nèi)容”到 表A添加 #話題# 關(guān)聯(lián)到 表C，如果該話題不存在，要先在 表B 中 INSERT更新 #話題# lastupdatime添加 @人 到 表D

更新對應(yīng)的cac-e。

轉(zhuǎn)播他人話題，實際上也是先分析你撰寫的轉(zhuǎn)播內(nèi)容中的 #話題# 和 @人唯一是多一個 src_tid 提交====================================我這是最基本的數(shù)據(jù)結(jié)構(gòu)，中間存在很多值得優(yōu)化的地方。樓主特別提出了關(guān)注1萬人，我記得國內(nèi)微薄收聽有限制吧。如果收聽人數(shù)過多，查詢肯定會慢，不過優(yōu)化 cac-e1 就能應(yīng)對，方法比如拆分、存址都可以。Cac-e 的話一般選擇分布式，就是給機器編號，每個電腦存儲不同uid塊

答案 2：

談?wù)剛€人看法：微博技術(shù)架構(gòu)的關(guān)鍵點在于如何優(yōu)化Cac-e和消息隊列的使用效率，以及合理規(guī)劃數(shù)據(jù)存儲方式。如此海量的數(shù)據(jù)推送必然是通過異步消息隊列處理，而不是簡單的數(shù)據(jù)庫直接寫入，因此系統(tǒng)的負載壓力會逐層分散到后端數(shù)據(jù)庫上，并不是集中于某幾臺數(shù)據(jù)庫上。新數(shù)據(jù)通知，應(yīng)該通過各種基礎(chǔ)服務(wù)預先計算出的數(shù)據(jù)集合，再通過客戶端每30秒的輪詢請求返回，并非請求后的實時計算，因此壓力可能更多的集中在cac-e層上。

答案 3：

這個問題的答案好像很復雜。可以看下新浪微博架構(gòu)師TimYang的《構(gòu)建高性能的微博系統(tǒng)——再談新浪微博架構(gòu)》infoq/cn/articl...-----------------不好意思，貼錯了鏈接。 這個才是對的 infoq/cn/presen...

答案 4：

了解推和拉2種模式，其中一樓的朋友說的非常對，這樣的應(yīng)用都是：MC+消息隊列+數(shù)據(jù)庫的應(yīng)用，而且數(shù)據(jù)庫肯定進行垂直+水平拆分的參考鏈接：mysqlops/2011...

答案 5：

有新微博和comemnts提示很容易實現(xiàn)的.看你的思路了

答案 6：

可以了解下推模式和拉模式這個不單單是數(shù)據(jù)庫的設(shè)計

答案 7：

這個分析得這么透徹。

答案 8：

不是Redis么

下一篇:WWF 每年收入能有多少？ 下一篇 【方向鍵 ( → )下一篇】

上一篇:kindle3真的有必要去安裝多看系統(tǒng)嗎？ 上一篇 【方向鍵 ( ← )上一篇】