#微架构设计#快速表态存储设计
#微架构设计# V5版微博推出表态业务，用户可以快速表达意见。假设对表态业务进行简化，只保留最新三条表态，多余的表态不再展示。表态类似于评论，热度非常明显，一条微博的表态可能有上千个，峰值写入也会超过1000/s，如何精简存储那？MC+Mysql or Redis or ？
分析快速表态，一条微博存3个表态，而每天有上亿微博，存储量是微博的3倍，量极大。
最新的3条表态，对更新要求高，每发一条新表态，就要去更新，写入量瞬间峰值也会非常大，甚至到达1000次/秒。
可见我们面对的主要挑战有两个：海量的表态数据存储和每秒上千次的并发写入。
具体分析如下：
针对上面数据的特点，可以考虑的存储方案有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 |
