编者按：春节将至，以往赶上大年三十，我们都会和家人围坐在电视机前，嗑着瓜子一起看春节晚会。而现在我们又多了一个娱乐项目，那就是拿着手机随时吐槽春晚节目。其中不乏妙语连珠，比春晚节目本身还更精彩。当然在这期间，微博的后台IT系统将经历非常严峻的考验，甚至春晚进行中峰值的请求量会达到上千万每秒的级别。对此，新浪数据系统服务平台的负责人杨海潮（@jackbillow）发表了一篇文章，详细讲述了微博数据团队在背后所做出的努力，希望大家能从中吸取一些实用经验。

杨海潮：我们是一个2013年Q1刚刚成立的团队，很多新加入的小伙伴们还没来得及熟悉环境，就要在春节期间面临史无前例的挑战。曾经在一些官方和非官方的场合，提到我们以Memcache为核心的缓存平台和以Redis为核心的内存数据库平台，目前日请求量量已经超过1.5万亿！峰值请求量超过1500万/秒！40TB的内存容量，承担着微博99%的请求，是新浪数据服务系统中最核心的力量。面对海量社交衍生数据的爆发，分布式系统呼之欲出，以HBase为代表的分布式数据平台中已经存储着65TB的数据，在线业务已有单表超过9TB！

一方面要面对家常便饭式的服务器宕机，机房调整，网络中断。另一方面要面对类似微博阅读数的每秒数百万的更新，春晚+红包飞的海量在线用户并发抽奖，粉丝服务平台大V数百万每秒的消息群发，跨年一秒数十倍写入峰值，随时可能出现得微博热点等等“疯狂”的业务需求。不能因为几十台服务器宕机就出现整体系统的波动，仅仅做到能应对这些波动对于我们来说只有60分，我们要保证的是在如此海量的高并发访问下，7×24小时的绝对稳定和超高速响应！

1.NoSQL平台如何应对高并发读取与写入的海量数据存储？

邂逅NoSQL：NoSQL实际上是相对RDBMS（关系型数据库）得一场运动，是对传统关系型数据库深刻得反思，我们也生产环境上对NoSQL类得数据库上进行了大规模得实践和应用。

替代原有得Memcache+MySQL架构，我们在计数器，用户关系等场景上使用Redis取得了非常好的效果，提升开发效率得同时，也简化了系统架构。

为了解决断点重传，共享aof的position，群发等带来的网卡流量等问题，我们改造了redis的同步机制，解决了无数重要服务的同步隐患。

在面对微博对象海量存储场景我们使用分布式数据库HBase来应对，减去了大量的数据拆分迁移成本。

2.异步消息队列服务（消息平台）如何处理削峰填谷？

如何应对跨年零点微博峰值写入？！缓存一致性如何维护？跨机房消息如果同步？所有这些问题得解决异步队列消息服务在其中都承担了重要角色。

微博异步消息处理机制

为了应对春节峰值写入得快速扩容和变更，我们引入configserver:

3.RamisDisk的缓存平台如何不怕宕机？

是否遇到缓存一宕机就跑死数据库引起系统雪崩？频繁扩容迁移，无法落地得缓存服务如何无缝切换？如何轻松扩展和应对超级热门数据的高并发访问？Multi-Layered Memcache的设计就是为了解决这些问题。

为了应对海量高并发读取和复杂缓存更新逻辑，我们引入了configserver和cache Service:

如何屏蔽后端资源扩容迁移变更对业务得影响，提供整体得数据解决方案，帮助业务快速迭代上线，我们还有很多路要走，Data As A Service！2014需要马上加油！

4.Plans in 2014

业务既要维护缓存还有拆分存储？！HBase+Redis/Memcached的一体化存储方案就是要解决这些问题，真正做到数据即服务。预热Memcached需要一天之久？Memcached的内存dump和内存同步，就是要解决这个问题，达到快速扩容和调整得目的。Redis全内存得方案成本太高？！基于Flash的Redis存储，彻底解决存储成本问题。