数据系统服务平台保障技术揭秘

前言

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

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

 

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

• 替代原有得Memcache+MySQL架构，我们在计数器，用户关系等场景上使用Redis取得了非常好的效果，提升开发效率得同时，也简化了系统架构。
• 在面对微博对象海量存储场景我们使用分布式数据库HBase来应对，减去了大量得数据拆分迁移成本。
• 为了解决断点重传，共享aof的position，群发等带来的网卡流量等问题，我们改造了redis的同步机制，解决了无数重要服务的同步隐患。

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

• 我们使用消息队列服务来削峰填谷。解决基础设施的投入。
• 为了应对春节峰值写入得快速扩容和变更，我们引入configserver:

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

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

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

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

另外借此机会也希望能再次能遇到志同道合之士，围绕数据为核心的服务体系，不管你是SA/DBA/DevOPs还是C/JAVA数据开发方面得高手，愿意迎接支撑微博每秒千万级的请求量，复杂分布式数据系统的各种挑战，简历至haizhao#staff.sina.com.cn，qipan#staff.sina.com.cn