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

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

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

可見我們面對的主要挑戰有兩個：海量的表態數據存儲和每秒上千次的并發寫入。

具體分析如下：

• 數據特點

1. key無限（與微博數量相當）
2. 數據冷熱程度明顯（最近幾天的微博的表態訪問量較大）
3. 只需要存儲最新的3條表態

• 方案對比

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

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

• 容量規劃

下面分析采用mc+mysql的存儲方案時，如何進行具體的容量規劃。

假設，每天發表的微博數1億，有表態的占10%，則：

1. mc   1億*10%*7*100B=7G（每天發表微博數*有表態的比例*一周*mc中每條記錄大小），命中率在99%以上。
2. mysql 每天增加1億*10%=1000W行，峰值1000次/秒

• 存儲設計

主要涉及mc的設計和mysql的表結構設計。

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