#微架构设计#快速表态存储设计

#微架构设计# V5版微博推出表态业务，用户可以快速表达意见。假设对表态业务进行简化，只保留最新三条表态，多余的表态不再展示。表态类似于评论，热度非常明显，一条微博的表态可能有上千个，峰值写入也会超过1000/s，如何精简存储那？MC+Mysql or Redis or ？

分析快速表态，一条微博存3个表态，而每天有上亿微博，存储量是微博的3倍，量极大。

最新的3条表态，对更新要求高，每发一条新表态，就要去更新，写入量瞬间峰值也会非常大，甚至到达1000次/秒。

可见我们面对的主要挑战有两个：海量的表态数据存储和每秒上千次的并发写入。

具体分析如下：

数据特点
key无限（与微博数量相当）数据冷热程度明显（最近几天的微博的表态访问量较大）只需要存储最新的3条表态
方案对比

针对上面数据的特点，可以考虑的存储方案有redis、mc+mysql、HBase等。下面从几个维度对这几个方案进行对比：




我们在满足并发读写量的需求时，还要尽量节俭存储，从前面的提示可知，快速表态业务的并发写入量可能会达到1000次/s，HBase显得大材小用，而redis能很好满足，但是经过实际业务统计，发现同一微博的表态，每秒同时并发写入量只有几十次每秒，因此可以忽略mysql并发写的问题，又考虑到redis的故障恢复成本较高。因此，mc+mysql相比于redis更加适合这个业务场景。

容量规划

下面分析采用mc+mysql的存储方案时，如何进行具体的容量规划。

假设，每天发表的微博数1亿，有表态的占10%，则：

mc 1亿*10%*7*100B=7G（每天发表微博数*有表态的比例*一周*mc中每条记录大小），命中率在99%以上。mysql 每天增加1亿*10%=1000W行，峰值1000次/秒

存储设计

主要涉及mc的设计和mysql的表结构设计。

mc key: 微博id， value：list（存放3个表态id）mysql

分库策略 按微博id进行hash，分为32个库分表策略 根据微博id按月分表表结构设计

+-----------+---------------------+------+-----+---------+-------+

| Field | Type | Null | Key | Default | Extra |

+-----------+---------------------+------+-----+---------+-------+

| status_id | bigint(20) unsigned | NO | PRI | NULL |微博id |

| attitude_ids | varchar(50) | NO | | NULL |评论id |




逻辑设计








1楼mrtalon1小时前

都开始技术博客了啊