饿了么DBA经理虢国飞：饿了么数据库架构变迁

　　在2016年3月18日-19日，由CSDN重磅打造的数据库核心技术与实战应用峰会、互联网应用架构实战峰会将在上海举行。届时，CSDN将采访一些与会讲师，谈谈他们将在会上分享的内容。

　　本期我们采访的讲师是虢国飞先生，现任饿了么DBA经理，混迹数据库行业多年，先后在5173、新蛋网、沪江网等担任DBA和DBA Leader职务，关注于数据库管理自动化建设、MySQL、MSSQL、PostgreSQL、NoSQL等领域的技术研究 。他将在数据库核心技术与实战应用峰会中带来《饿了么数据库架构变迁》的干货分享。下面则是CSDN小编对虢国飞先生的会前专访，以下为专访具体内容：

　　上图为饿了么DBA经理 虢国飞

　　CSDN：首先请您简单介绍下自己、公司以及目前所负责的领域。

　　虢国飞：大家好，我叫虢国飞，网名“飞扬过海”，一直从事数据库领域的工作，熟悉的数据库产品有MySQL、MSSQL、PostgreSQL以及部分NoSQL，先后在5173、新蛋网、沪江网从事过DBA方面的工作，现在在“饿了么”公司担任DBA经理职务，主要是负责饿了么数据库的维护和数据库团队的管理工作。

　　CSDN：您在数据库行业多年，掌握着丰富的数据库开发与设计经验，那么您是如何保持对这份技术热情的呢?

　　虢国飞：我个人认为，可以在一个领域里面保持持续的热情，主要取决于兴趣、成就感与好奇心，只有热爱这个行业、这份工作，才会不断的想去学习、研究和思考，如果再能在此基础上做出一些有意思的事情，取得一些成绩，然后结交一些朋友，相信这份成就感会继续支持你在这个行业里面走下去;还有需要保持一颗好奇心，乐于接受新的事物和技术，能打破自己已有的知识体系，融入新的思想，再从新组织起来，形成新的体系，这样才能不断丰富、提升自己。

　　CSDN：您在饿了么期间，有没有很有意思的事情发生，让您至今记忆犹新呢?

　　虢国飞：我觉得DBA最印象深刻的是故障，尤其是大的故障，我记得在饿了么经历了一个比较大的事故是int字段溢出的问题，碰巧的是我们业务代码之前就有对这个表的插入失败情况，于是抛出的错都被业务丢弃了，当时正是业务高峰期，订单状态都不轮转了，我们的各项监控指标都在安全水位，而且没有错误日志，大家都找到问题;后来还是一位熟悉业务的架构师发现这个现象后，再对表进行测试才找到原因;这个事情让我感受最深的是做DBA很多事情不能停留在表面，我们对各种性能指标都有监控，但是这个还是不够的，还必须深入到业务，才能真正在问题出现时及时定位;现在我们的监控会加入对业务对数据的监控，这需要深入了解业务的特点，这样我们才能制定有效的监控指标，有的放矢，自证清白(即便故障时没有业务代码的错误信息，我们也能知道DB到底有没有问题)。

　　CSDN：您能和我们分享下饿了么订单从每天几十万单到如今的几百万订单过程中，在数据库架构方面是如何调整变化的，以及每个阶段面临了哪些问题，又是如何应对的呢?

　　虢国飞：我最初到饿了么的时候，那时候每天几十万的单量，但是因为饿了么之前一直没有专门的DBA，使得数据库面临的问题很多，包括磁盘空间不足、主从延时、连接数不够、无规范、无规则、大量慢SQL等问题一应俱全;我过去后做了三件事情：1. 先解决一些救火方面的问题，比方磁盘空间、延时、连接数等，2. 推动数据库设计、开发的规则、规范和数据库部署安装的规范，3. 收集了数据库运行数据、加上了监控报警;三项措施其实瞄准了三个方向：稳定现在、收紧入口、把控数据;尤其是把控数据方面，为我们后面的架构调整和DB优化提供了数据、指明了方向。

　　数据库架构调整大概经历了四个阶段：硬件和DB升级、垂直拆分、sharding、异地容灾。

　　硬件与DB升级：

　　这个是最开始为解决磁盘空间、延时、SlowSQL等问题采取的一些救火措施，我们上了SSD盘、升级MySQL5.5到5.6、增加slave将不同业务划分到单独的slave上面 (做隔离，单个业务Slow SQL不影响全局 )、同时还进行了机房的搬迁，这其中遇到MySQL升级到5.6 业务代码不兼容的问题(主要是时间和null值不兼容，前期测试也做得不完善)，导致真正实施的时候排查了比较久。

　　垂直拆分：

　　随着我们订单量的不断上涨，主库的压力增加明显，我们通过之前收集的运行数据，再对比我们压测数据，发现原有的架构下，订单上升到200万单左右，核心数据库TPS就支持不了啦，同时Slave延时的问题还会继续出现，连接数也不够，于是我们将核心的主库按业务和TPS的比例拆分成了五套集群，其他相关的业务库也按照我们的运行数据和压测效果一一拆分，最终平稳支持了300多万单的冲击;这个阶段其实主要的问题在于，如何有节奏的推动开发人员配合我们来做DB的拆分，那在拆分之前我们会通过我们的数据来告知到老板和开发负责人我们DB会面临哪些问题?瓶颈在哪里?不调整的话最多能支撑的订单量是多少?我们会拿运行数据、压测数据以及我们拆分后的预期数据来展示给他们，有了数据的支撑和专业的对比分析，老板也会帮我们推动拆分的事;其实还没完，等拆分完成后我们会拿实际运行的数据和之前预期的数据做对比，做成分析报告发给老板和相关的开发人员，让大家感觉到咱们做的事情是有效果、有价值的。

　　sharding：

　　这个阶段，系统要求是10x容量设计，这个阶段对DBA来讲，其实比较痛苦，首先是方案的确定会比较麻烦，最重要的是依赖的因素太多了，很多事情DBA并不能把控，需要很多资源的投入;因为业务比较复杂，光讨论sharding的切片方案就耗时1个多月，还有sharding的方案选型、实施方案、灰度方案、回滚方案以及业务代码的改造等;最终我们将核心的DB拆分为两个维度(用户和商家维度)，分了120个片(可以支持1024片)，从一套集群变成了12套集群，引入了DAL层(对业务透明)，改造后经过压测分析，可以支持到3000w订单/天的量;当然这种调整也带来了新的问题，如sharding之后数据一致性(两个分片)、DAL本身的容灾机制、DB维护量增加等;我们后面开发了数据差异对比和自动数据订正工具来保障数据的一致性，同时也在DAL这一层做了冗余的灾备机制，DB维护我们也通过工具来简化DBA的操作。

　　异地容灾：

　　这个是我们正在进行的阶段，异地灾备投入比较大，而且风险也比较高，目前因为我们并没有在MySQL源码上面做一些工作，有没有开发drc类似的工具(当然这个是我们努力的方向)，所以方案的研究和测试都是在考虑MySQL缺陷下进行的，比如一开始我们就是基于切换的时候两边的数据有差异的前提下来讨论方案的(当然数据是不能丢的，我们需要知道哪些数据出现了问题)，因为数据的延时，带来比较严重的问题是数据的冲突和业务数据状态的一致性，对这些数据的丢失或者不一致问题，我们是通过业务方和DBA分别跑脚本来应对的，即业务会负责业务数据状态不一致的修复，DBA会负责修复数据的冲突(比方切换前自增列我们会统一将自增因子调大或者一开始两边就是奇偶递增，避免新写入的数据和老的数据冲突)，等机房恢复后，我们再来通过脚本比对差异的数据，跟进业务方案来修复，目前方案还在测试验证当中。

　　CSDN：在您看来，您觉得数据库技术接下来会面临着哪些挑战?它的发展趋势又如何?

　　虢国飞：现在互联网对数据库的使用方式发生了很多变化，数据库不再像过去那样笨重，变成了很轻的东西，因为大家对数据库的吞吐量有更高的要求;而且现在硬件性能提升很快，数据库以前的瓶颈以前说是在磁盘IO上，后面可能转变到数据库代码能否将这些强悍的硬件性能使用好的情况。

　　个人感觉，数据库技术会往三个方向发展，第一是提高数据库本身的吞吐量，在保证数据的一致性的前提下，如何减少锁或者提高锁效率、提高并发度、细化管理方式和提示信息等方面，像MySQL这类开源数据库，还是有很多地方可以继续完善;第二是分布式数据库技术发展，目前大部分公司在做分布式数据库时都会依赖中间件，没有能力做中间件的公司，要做数据库的sharding会比较痛苦，开发人员需要改造很多代码，而且升级、维护都会比较麻烦，不过中间件的引入会带来新的问题，拖慢了效率，增加一个新的风险点，增加了沟通成本，出问题时排查的路线也会更长;如果能让数据库本身实现中间件的机制，那对DBA来讲会是很给力的支持，DBA完全能够自己把控，现在有一些公司在做这个研究;第三是云数据库，CDB目前发展也比较迅速，高配的CDB 越来越多，有丰富的工具支持，中小型的业务完全可以使用CDB，如果不关注状态的业务也可以在多个CDB之间做灾备(比方发送短信的业务)，不过数据量大、并发高、要求高的业务，还是推荐自己来维护。

　　CSDN：以您对数据库技术的多年研究，如何才能更好的掌握数据库这门技术呢?

　　虢国飞：个人认为以下几点：感兴趣、爱学习、勤思考、多动手、善总结，首先深入学习某一款数据库，然后再扩展到其他，搭建T型知识体系，最终能形成一套自己的维护管理DB的方式方法。

　　CSDN：您最期待在本次SDCC数据库峰会上听到哪些内容?

　　虢国飞：数据库架构和技术发展上面其他同仁的一些新的想法和实践，还有遇到过的问题。

　　CSDN：在本次SDCC数据库峰会上分享的话题是?

　　虢国飞：“饿了么数据库架构变迁”，希望和大家分享下我们在业务快速增长下是怎么来调整数据库架构的，同时和大家探讨下各种架构的优劣。