肖鹏：微博数据库那些事儿（图灵访谈）

非商业转载请注明做译者、出处，并保留本文的原始连接：http://www.ituring.com.cn/article/211461

肖鹏，微博研发中心技术经理，主要负责微博数据库（MySQL/Reids/HBase/Memcached）相关的业务保障、性能优化、架构设计，以及周边的自动化系统建设。经历了微博数据库各个阶段的架构改造，包括服务保障及SLA体系建设、微博多机房部署、微博平台化改造等项目。10年互联网数据库架构和管理经验，专一于数据库的高性能和高科用技术保障方向。

问：您是如何与MySQL结缘，并成为数据库方面的专家的？

与MySQL结缘主要也是源于兴趣，第一份工做在一家小公司，各个领域的工做都会有接触，全都作下来发现仍是对数据库最感兴趣，因此就一直从事和数据库相关的技术工做了。随着工做年限的增长，我在数据库方面积累的经验也逐步增长，愈来愈发现数据库管理员（DBA）是一个偏实践的工种，不少理论上的东西在现实中会有各类的变化，好比「反范式」设计等等。因此我建议你们：若是想成为数据库方面的专家，必定要挑选好环境，大平台不少时候会因为量变引起质变产生不少有挑战的问题，而解决这些问题是成为技术专家的必经之路。

问：一路走来，微博的数据规模和业务场景都发生了很大的改变，请问新浪MySQL集群结构发展到今天都经历了哪些阶段？

微博到今天已经有6年了，很是有幸全程参与了这6年的变化。新浪的MySQL集群结构主要经历了3次重大的变化。

第一阶段：初创阶段

初期微博做为一个内部创新产品，功能比较简洁，而数据库架构也采用1M2S1MB的标准结构，按照读写分离设计，主库承担写入，而从库承担访问。若是访问压力过大，能够经过扩容从库的数量得到scale out的能力。

第二阶段：爆发阶段

微博上线以后，随着用户活跃度的增长，数据库的压力也与日俱增。咱们首先经过采购高性能的硬件设备来对单机性能进行scale up，以知足支撑业务的高速发展的需求。而后，经过使用高性能设备争取来的时间对微博进行总体上的业务垂直拆分，将用户、关系、博文、转发、评论等功能模块分别独立存储，并在垂直拆分的基础上，对一些预期会产生海量数据的业务模块再次进行了二次拆分。

以博文为例，博文是微博用户主要产生的内容，能够预见会随着时间维度不断增大，最终会变得很是巨大。如何在知足业务性能需求的状况下，尽量使用较少的成本存储，这是咱们面临的一个比较有挑战的问题。

• 首先，咱们将索引同内容进行了拆分，由于索引所需存储的空间较少，而内容存储所需空间较大，且对这二者的使用需求也不尽相同。

• 而后，分别对索引和内容采用hash，而后再按照时间维度拆分的方式进行水平拆分，尽可能保障每张表的容量在可控范围以内，保障查询的性能指标。

• 最后，业务先经过索引得到实际所需内容id，而后再经过内容库得到实际的内容，并经过部署memcached来加速整个过程。虽然看上去步骤变多，可是实际效果彻底能够知足业务需求。

第三阶段：沉淀阶段

在上一个阶段，微博的数据库经历了不少的拆分改造，这也就直接形成了规模的成倍增加，而随着业务经历了高速增加以后，也开始趋于稳定。在这个阶段，咱们开始着重进行自动化的建设。将以前在快速扩张期间积攒下来的经验转变为自动化工具，对外造成标准化和流程化的平台服务。咱们相继改造了备份系统、监控系统、AutoDDL系统、MHA系统、巡检系统、慢查系统、maya中间件系统等。为了提升业务使用效率和下降沟通成本，相对于内部管理系统而言，咱们从新开发了iDB系统对数据库平台的用户使用。经过iDB系统，用户能够便捷地了解本身业务数据库的运行状态，并能够直接提交对数据库的DDL修改需求。DBA仅需点击审核经过，便可交由Robot在线上执行，不但提升了工做效率，也提升了安全性和规范性。

问：在过去的2015年，新浪数据库平台都作了哪些重大的改进和优化？

数据库平台并不只有MySQL，还有Redis、Memcached、HBase等数据库服务，而在缓存为王的趋势下，2015年咱们重点将研发精力投入在Redis上。

Redis中间件

2015年，咱们自研的Redis中间件tribe系统完成了开发和上线。tribe采用有中心节点的proxy架构设计，经过configer server管理集群节点，并借鉴官方Redis cluster的slot分片设计思路来完成数据存储。最终实现了路由、分片、自动迁移、fail over等功能，而且预留了操做和监控的API接口，以便同其余的自动化运维系统对接。

Databus

因为咱们先有MySQL后有Redis和HBase等数据库，因此存在一种场景，就是目前数据已经写入到MySQL中，可是须要将这些数据同步到其余数据库软件中。为此咱们开发了Databus，能够基于MySQL的binlog将数据同步到其余异构的数据库中，而且支持自定义业务逻辑。目前已经实现了MySQL到Redis和MySQL到HBase的数据流向，下一步计划开发Redis到MySQL的数据流向。

问：微博用户库设计采用了反范式设计，可是反范式设计也有本身的问题，好比在规模庞大时，数据冗余多，编码及维护的困难增长。请问大家是如何解决这些问题的？

反范式设计带来便利的同时确实也带来了一些问题，尤为是在数据规模变大以后，一般来讲会有以下几种解决方案。

• 预拆分，接到需求的时候提早针对于容量进行评估，并按照先垂直后水平进行拆分，若是能够按照时间维度设计，那就归入归档机制。经过数据库的库表拆分，解决容量存储问题。

• 引入消息队列，利用队列的一写多读特性或多队列来知足冗余数据的多份写入需求，但仅能保障最终的一致性，中间可能会出现数据延迟。

• 引入接口层，经过不一样业务模块的接口将数据进行汇总以后再返回给应用层，下降应用层开发的编码复杂度。

问：微博平台当前在使用并维护着多是世界上最大的Redis集群，在应用Redis的过程当中，大家都产生了哪些具备首创性的解决方案？

微博使用Redis的时间较早，而且一开始量就很大，因而在实际使用过程当中遇到了不少实际的问题，咱们的内部分支版本都是针对这些实际问题进行优化的。比较有特色的有以下三个。

增长基于pos位同步功能

在2.4版本中，Redis的同步一旦出现中断就会从新将主库的数据所有传输到从库上，这就会形成瞬时的网络带宽峰值，而且对于数据量较大的业务，其从库恢复的时间较为缓慢。为此咱们联合架构组的同事借鉴MySQL的主从同步复制机制，将Redis的aof改造为记录pos位，并让从库记录已经同步的pos位置。这样，在网络出现波动的时候，即便重传也只是一部分数据，并不会影响到业务。

在线热升级

使用初期，因为不少新功能的加入，Redis版本不断升级，每次升级时为了避免影响业务都须要进行主库切换，这对于运维带来了很大的挑战。因而咱们开发了热升级机制，经过动态加载libredis.so来实现版本的改变，再也不须要进行主库切换，极大地提高了运维的效率，也下降了变动带来的风险。

定制化改造

在使用Redis的后期，因为微博产品上技术类的需求很是多，因此咱们为此专门开发了兼容Redis的redisscounter存储技术类的数据。经过使用array替换hash table极大下降了内存占用。而在此以后，咱们开发了基于bloom filter的phantom解决判断类场景需求。

问：在一次分享中您曾经透露新浪数据库备份系统正计划结合水位系统实现智能扩容，请问如今实现到哪一步了？

目前这个事情的进展不是很理想，主要是咱们发现MySQL的扩容速度跟不上业务的变化，有些时候扩容完毕以后业务的高峰已通过去了，接下来就须要作缩容，等于作了无用功。因此，目前咱们的思路改成扩缩容cache层。首先实现cache层的自动扩缩容，而后同业务监控系统或者接入层的自动化系统进行联通，好比，若是计算节点扩容100个node，那么咱们的cache层就联动扩容20node，以此来达到业务联动。

问：将来5年内新浪数据库还将作出什么样的改变？

随着业务的发展，会遇到愈来愈多的场景，咱们但愿能够引进最适合的数据库来解决场景问题，好比PostgreSQL、SSDB等。同时，利用MySQL新版本的特性（好比5.7的并行复制、GTID、动态调整BP），不断优化现有服务的性能和稳定性。

另外，对于现有的NoSQL服务，推动服务化，经过使用proxy将存储节点进行组织以后对外提供服务。对外下降开发人员的开发复杂度和获取资源的时间，对内提升单机利用率并解决资源层横向扩展的瓶颈问题。

同时，尝试利用各大云计算的资源，实现cache层的动态扩缩容；充分利用云计算的弹性资源，解决业务访问波动的问题。

问：您如何看待新兴的NewSQL？

数据库圈子的变化确实很快，NoSQL还刚刚方兴未艾，NewSQL又开始你方唱罢我登场。我我的并不认为某种数据库会取代另外一种数据库，就如同NoSQL刚刚兴起的时候不少声音认为它会完全取代MySQL，可是从实际状况看依然仍是互依并存的关系。以我负责的集群来讲，反却是MySQL更多一些。我我的认为，每种数据库都有其最擅长的场景，在特定场景下它就是最佳的数据库，可是若是脱离了场景则很难说谁优谁劣。

问：可否请您横向对比一下MySQL、MongoDB以及PostgreSQL？

我我的对MySQL使用得较多，MongoDB和PostgreSQL都有过一些接触，MySQL做为LAMP中的一员，老实说对大部分场景都是合适的，尤为是在并发和数据库量并无达到一个很大值的时候。可是，在某些场景下MongoDB和PostgreSQL确实更胜一筹。

好比咱们在门户的新闻发布系统中使用了MongoDB，其schema less的设计模式和新闻很是贴合，而其sharding功能又解决了容量上的横向扩张问题，在这个场景下，MySQL并不具有什么优点。

而在LBS（基于地理位置信息服务）相关的方面，PostgreSQL和PostGIS更具备优点，利用其空间数据索引R-tree和实体类型点、线、线段、方形，以及特定的函数，能够很方便地实现空间计算需求。

就我我的来讲，每种数据库都有其擅长的场景。若是没有特殊的架构需求，通常选择MySQL都不会出问题。若是有特殊的架构需求，那么就须要根据需求的特色来选择不一样的数据库。

问：对于想要掌握MySQL的同窗，您有哪些学习上的建议？

首先，多读书，至少将High Performance MySQL通读一遍。

其次，有条件的话，最好找一些大平台历练一下，在不少状况下经验和能力等同于你解决过的问题的广度和深度，而环境决定你遇到的问题。

最后，有机会的话多作一些技术分享，不少知识点本身明白和能给别人讲明白是两个彻底不一样的境界。

---

更多精彩，加入图灵访谈微信！