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

#微架构设计# 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        

• 分库策略      按微博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 |

• 逻辑设计

网页名称：#微架构设计#快速表态存储设计
文章出自：http://www.csdahua.cn/qtweb/news11/41211.html

网站建设、网络推广公司-快上网，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 快上网