饿了么数据库演进之路——质量、效率与原则的思考

按：我们考虑一个系统的时候，要考虑哪些要素？有4个核心要素：质量、成本、效率、收益、架构要素。良好的架构可以巩固和增强其它4个因素。本文来自虢国飞老师的分享。他主要介绍了质量、效率和架构原则三个方面。

今天我想和大家分享饿了么作为高速发展的互联网企业之一，在发展历程中数据库技术如何跟随企业发展并不断满足业务的需求，会大致介绍下数据库经历了哪些阶段，以及我们做了怎样的一些事情。

分享内容大致涉及到以下5点：

• 数据库架构怎么满足业务、支撑业务发展；

• 怎么提高数据库的可用性；

• 如何对数据流进行相应的控制和保护；

• 规模大了以后如何提高数据库运维的效率；

• 一些个人认为重要原则的总结。

 

首先简单介绍一下饿了么的概况，点过外卖的同学应该都知道饿了么吧？

 

 

饿了么发展最快阶段也是最近四五年的事情，我是2015年进入饿了么的，那时每天才几十万的订单，服务器也不多；到了2016年时每天订单达到了几百万，商户也更多了；而2017年不管是订单、运单都是千万以上，直到现在都还在快速增长。

 

这么多数据的产生对底层数据存储是非常大的挑战，而且那个时候要在非常短的时间内应对业务的爆发性的增长，所以当时底层的技术挑战也是非常大的。

 

一、数据库架构

1、垂直拆分

在数据库架构方面饿了么开始的时候也是比较原始的阶段，最初是一主多从的架构；发展到后面发现订单数据库很难再满足业务往上增长的需求了；过百万之后一主不管几从都很难满足业务的需求（因为写太大），这就面临着需要拆分的情况，需要把热点业务单独拆出来，把一套数据库拆成多套，进行垂直的业务拆分。

数据库架构-垂直

拆分根据什么原则呢？又怎么来预算订单库现在的架构能承载多少的TPS和QPS呢？

 

我们当时是结合订单量、对应的QPS、TPS数据，再根据半年后的增长情况来推算出每个业务大概会产生出多少的QPS、TPS，然后结合每套集群能承载的TPS、QPS数量（基于压测），就能估算出需要拆分成什么样的结构、以及拆分后每一套（半年后）大致需要承载多少TPS、QPS。

 

当时按业务垂直拆分后，这一套方案承载了200、300万订单的规模，垂直拆分的优势是代价小见效快（业务代码改动并不大），能快速有效的支撑业务。

 

2、水平拆分

虽然按垂直架构拆分完了，但是热点的地方依然还是热点，比如说订单随着下单量的增长依然会变成很大的瓶颈。那如何打破瓶颈呢？

我们需要把订单这个热点再单独拆分成多套。

数据库架构-水平

 

也就是行业里说得比较多的“水平拆分”，把原来的一张订单表在底层拆成1000张小表，放在不同的集群上。这样即使这一个订单的量再大，也能够通过不断水平扩容机器来将压力拆分到更多的集群上，从而满足了热点的性能承载。

我们可以通过压测计算出每套集群能承载出多少QPS和TPS，再结合现在的业务情况就能估算出多少订单会对应产生多少的QPS和TPS，进而也能知道拆分成多少套集群能承载多少的业务量，所以也就知道了要扩多少机器才能满足半年或者一年后的业务增长。

如果说底层因为扩容做了分片策略，但是这个改动对业务不是透明的话，那就意味着业务需要做很多改造来适应底层的分片逻辑，一般业务是很难接受的。

所以，我们的水平拆分为了对业务做到透明，需要做一层代理层（我们叫DAL），代理层会帮助业务代码做到对数据库底层拆分逻辑的访问透明，业务看到的还是一张订单表，但是底层变了1000张表。

完成水平扩容后基本上所谓的热点也不会存在太大的瓶颈，如果再往上增长的话可以继续拆小，继续添加更多的机器来承载。

 

3、多活架构

垂直拆分之后，我们就没有性能瓶颈了吗？

其实机房也会成为我们的瓶颈。一般来讲企业都是租赁供应商的机房，一个机房能进多少机器不是无限的，供应商也不可能给你预留太多的位置。

当你服务所在的机房放不进去机器以后，你会发现虽然技术架构能满足水平扩容，但是在物理上不能再加机器了，性能瓶颈依然会到来。

为打破单个机房面临的容量瓶颈，我们需要扩容到更多的机房&#x