从新浪微博看海量数据存储

从新浪微博看海量数据存储

2014-01-05 20:13:34| 分类：实验报告 | 标签：海量存储|举报|字号订阅

从新浪微博看海量数据存储

一、新浪微博简介及特点

（一）新浪微博简介

新浪微博是一个由新浪网推出，提供微型博客服务的类Twitter网站。用户可以通过网页、WAP页面、手机客户端、手机短信、彩信发布消息或上传图片。新浪可以把微博理解为“微型博客”或者“一句话博客”。用户可以将看到的、听到的、想到的事情写成一句话，或发一张图片，通过电脑或者手机随时随地分享给朋友，一起分享、讨论；还可以关注朋友，即时看到朋友们发布的信息。

（二）新浪微博的特点

1.操作简单，信息发布门槛极低

140个字发布信息，在文字的基础上可以同时上传图片，视频等连接。内容不限制，所见所闻，所思所想，生活琐碎和宏大主题均可发布。

2.平台广泛，随时随地传播信息

除了电脑以外，手机的在线发布，使得使用广泛。支持手机等平台，通过手机发布，实现了全息发布方式，真正实现了随时随地发布和接收信息。

3.传播速度快，传播方式呈裂变

利用各种转发，名人推荐，媒体合作等，以不同的话题和主题，博得潜在消费人群的关注。新浪微博的传播路径：一个是“粉丝路径”。 A 发布信息后，A 的所有粉丝，都可以实时接收信息；另一个是“转发路径”。如果甲觉得A 的某条微博不错，他可以“一键”转发，这条信息立即同步到甲的微博里，同时，甲的所有粉丝，又都可以实时接收信息，然后以此类推，实现“病毒式”传播。

4. 信息交互简便快捷

除了上面所述的关注和转发功能，新浪微博还有“评论功能”、“回复功能”、“私信功能”，同时每次信息交互产生后给予用户新消息的提示，达到实时交互。这些功能为用户之间的信息交互提供了保证。

作为互联网3.0时代的产品，我认为其特点的核心为“微·快”。相比1.0和2.0时代下的网站和博客论坛，微博的发布对用户要求大大降低（无论是所需技术还是时间），发布信息微小符合快速阅读下的“快餐文化”。同时“快”还体现其传播速度之快，常常短时间引发巨大的讨论。

二、新浪微博数据库

新浪微博的特点决定了其使用的数据库，而且不断增加的用户数和访问量也导致其架构和数据库上的改变。

（一）MySQL数据库

新浪微博这个产品从架构上来分析，它需要解决的是发表和订阅的问题。最开始采用的是推的消息模式。新浪微博首席架构师杨卫华是这么描述的“假如说我们一个明星用户他有10万个粉丝，那就是说用户发表一条微博的时候，我们把这个微博消息攒成10万份，这样就是很简单了，第一版的架构实际上就是这两行字。”第一版的技术细节，典型的LAMP架构（Linux作为操作系统，Apache 和Nginx作为Web服务器，MySQL作为数据库，PHP/Perl/Python作为服务器端脚本解释器），是使用Myisam搜索引擎，它的优点就是速度非常快。

后来随着用户越来越多，访问量剧增。每时每刻都有大量的信息被发布，最初的架构就有延迟的问题，而用户需要的是根据关注关系实时投递。后来就有了分片（分库分表）、拆分、异步处理和分布式系统。

1.sharding（分片）

Sharding（分片）只用于数据量大同时有性能瓶颈的库，大部分库不进行sharding处理。对于数据量比较大的库，在一开始就考虑sharding策略，例如索引数据和内容数据分开设计，每类数据库根据业务逻辑选择恰当的partitioning key，拆分成一定数量的表。（见图一）然后随着压力的增加进行垂直拆分，垂直拆分后的库再遇到性能瓶颈时首先考虑用硬件来解决。当硬件解决不了时才开始考虑水平拆分。在选择sharding方案时仔细考虑业务逻辑。对于读密集型应用，基本上通过增加slave来解决，对于写密集型应用才进行垂直和水平拆分工作。（图二）

图一按不同partitioning key进行拆分

图二master/slave的拆分

跨越越多的sharding，带来的开销就越大，这个数量是如何控制的？新浪首席DBA杨海潮这样回答的“目前我在设计之前就避免跨表操作，选择适当的paritioning key，也即合适的拆分维度，避免对后期业务的影响。根据业务逻辑的重要程度，如果业务逻辑是查询某一个用户的信息，那么会按用户进行拆分，那么保证一个用户的数据是落在一张表里面。按时间维度进行拆分，那么会分析数据的冷热程度，把80%以上的数据放在一个表，避免过多的跨表查询。在这种拆分维度满足不了业务需求时，我们会利用空间换时间的思想，同一份数据按多种维度进行拆分，让每种业务逻辑的查询语句都有很高的效率。”

关于sharding（分片）和partitioning（划分），sharding通常是指垂直拆分和水平拆分，是一个总体的概念，mysql的partitioning是实现sharding 的一种技术。

同时杨海潮认为Sharding的原则有以下几点：一开始就关注架构设计；Scale up--Scale out--Scale up；成本可控下硬件是首选；逐步解决拆分中成本问题。

2.异步处理

异步处理，发布是一个非常繁重的操作，它要入库、统计索引、进入后台，如果要把所有的索引都做完用户需要前端等待很长的时间，如果有一个环节失败的话，用户得到的提示是发表失败，但是入库已经成功。所以新浪微博做了一个异步操作，就是发表成功就提示成功，然后在后台慢慢的消息队列慢慢的做完。另外新浪发表了一个很重要的产品叫做MemcacheQ，一个单纯的分布式消息队列服务。

3.分布式系统

第一个是Master/Slave（图二），但是它有两个缺点，第一个是Master是中心化的，如果Master在北京那广州访问就非常慢。第二种就是Multi-Master 方案，它需要应用避免冲突，就是不能多处改变。这个对于微博来说不会特别难，用户通常只会再一个地方发布微博，很难既在广州又在北京发表或者是修改自己的资料。第三个就是Paxos就是可以达到强一致写，就是一条数据如果成功肯定是多个机房都成功了，这个也显而易见就是延迟性非常大。因此总结一下

Multi-Master是最成熟的策略，但是MySQL只支持一对多的主从复制，而不支持多主（multi-master）复制。

（二）NoSQL数据库

随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。

Redis是一个基于内存的Key-Value存储的NoSQL引擎。与其他Key-Value 引擎不同，Redis的Value可以支持多种数据结构，如哈希、List、Set等。

可以通过RBR解析BINLOG将MySqL同步到redis。Redis提供特定数据结构的读写操作，实现关系型数据转变成队列数据和通过replication接口同时写入到MySQL。用解决rdb和aof模式解决replicaton问题，以及加入position思想来解决容灾问题。

但是一直以来，Redis的持久化方案并非完美。从rdb到aof，再到已经夭折的vm，Redis的持久化之路一直走的很坎坷。由于持久化的不完美，以及全部