#微架構(gòu)設(shè)計# V5版微博推出表態(tài)業(yè)務(wù)，用戶可以快速表達(dá)意見。假設(shè)對表態(tài)業(yè)務(wù)進(jìn)行簡化，只保留最新三條表態(tài)，多余的表態(tài)不再展示。表態(tài)類似于評論，熱度非常明顯，一條微博的表態(tài)可能有上千個，峰值寫入也會超過1000/s，如何精簡存儲那？MC+Mysql or Redis or ？

分析快速表態(tài)，一條微博存3個表態(tài)，而每天有上億微博，存儲量是微博的3倍，量極大。

最新的3條表態(tài)，對更新要求高，每發(fā)一條新表態(tài)，就要去更新，寫入量瞬間峰值也會非常大，甚至到達(dá)1000次/秒。

可見我們面對的主要挑戰(zhàn)有兩個：海量的表態(tài)數(shù)據(jù)存儲和每秒上千次的并發(fā)寫入。

具體分析如下：

• 數(shù)據(jù)特點

1. key無限（與微博數(shù)量相當(dāng)）
2. 數(shù)據(jù)冷熱程度明顯（最近幾天的微博的表態(tài)訪問量較大）
3. 只需要存儲最新的3條表態(tài)

• 方案對比

針對上面數(shù)據(jù)的特點，可以考慮的存儲方案有redis、mc+mysql、HBase等。下面從幾個維度對這幾個方案進(jìn)行對比：

我們在滿足并發(fā)讀寫量的需求時，還要盡量節(jié)儉存儲，從前面的提示可知，快速表態(tài)業(yè)務(wù)的并發(fā)寫入量可能會達(dá)到1000次/s，HBase顯得大材小用，而redis能很好滿足，但是經(jīng)過實際業(yè)務(wù)統(tǒng)計，發(fā)現(xiàn)同一微博的表態(tài)，每秒同時并發(fā)寫入量只有幾十次每秒，因此可以忽略mysql并發(fā)寫的問題，又考慮到redis的故障恢復(fù)成本較高。因此，mc+mysql相比于redis更加適合這個業(yè)務(wù)場景。

• 容量規(guī)劃

下面分析采用mc+mysql的存儲方案時，如何進(jìn)行具體的容量規(guī)劃。

假設(shè)，每天發(fā)表的微博數(shù)1億，有表態(tài)的占10%，則：

1. mc   1億*10%*7*100B=7G（每天發(fā)表微博數(shù)*有表態(tài)的比例*一周*mc中每條記錄大?。新试?9%以上。
2. mysql 每天增加1億*10%=1000W行，峰值1000次/秒

• 存儲設(shè)計

主要涉及mc的設(shè)計和mysql的表結(jié)構(gòu)設(shè)計。

1. mc              key: 微博id， value：list（存放3個表態(tài)id）
2. mysql