歡迎來到 常識詞典網(wǎng) ， 一個專業(yè)的常識知識學(xué)習(xí)網(wǎng)站！
[ Ctrl + D 鍵 ]收藏本站
答案 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ù)預(yù)先計算出的數(shù)據(jù)集合，再通過客戶端每30秒的輪詢請求返回，并非請求后的實時計算，因此壓力可能更多的集中在cac-e層上。答案 3：
這個問題的答案好像很復(fù)雜?？梢钥聪滦吕宋⒉┘軜?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)嗎？ 上一篇 【方向鍵 ( ← )上一篇】
快搜
