高性能服务端优化之路

业务场景

达达是全国领先的最后三千米物流配送平台。 达达的业务模式与滴滴以及Uber很类似，以众包的方式利用社会闲散人力资源，解决O2O最后三千米即时性配送难题。 达达业务主要包含两部分：商家发单，配送员接单配送，以下图所示。

达达的业务规模增加极大，在1年左右的时间从零增加到天天近百万单，给后端带来极大的访问压力。压力主要分为两类：读压力、写压力。读压力来源于配送员在APP中抢单，高频刷新查询周围的订单，天天访问量几亿次，高峰期QPS高达数千次/秒。写压力来源于商家发单、达达接单、取货、完成等操做。达达业务读的压力远大于写压力，读请求量约是写请求量的30倍以上。

下图是达达过去6个月，天天的访问量及QPS变化趋势图变化趋图，可见增加极快

极速增加的业务，对技术的要求愈来愈高，咱们必须在架构上作好充分的准备，才能迎接业务的挑战。接下来，咱们一块儿看看达达的后台架构是如何演化的。

最初的技术选型

做为创业公司，最重要的一点是敏捷，快速实现产品，对外提供服务，因而咱们选择了公有云服务，保证快速实施和可扩展性，节省了自建机房等时间。在技术选型上，为快速的响应业务需求，业务系统使用python作为开发语言，数据库使用Mysql。以下图所示，应用层的几大系统都访问一个数据库。

读写分离

随着业务的发展，访问量的极速增加，上述的方案很快不能知足性能需求。每次请求的响应时间愈来愈长，好比配送员在app中刷新周围订单，响应时间从最初的500毫秒增长到了2秒以上。业务高峰期，系统甚至出现过宕机，一些商家和配送员甚至所以而怀疑咱们的服务质量。在这生死存亡的关键时刻，经过监控，咱们发现高期峰Mysql CPU使用率已接近80%，磁盘IO使用率接近90%，Slow query从天天1百条上升到1万条，并且一天比一天严重。数据库俨然已成为瓶颈，咱们必须得快速作架构升级。

以下是数据库一周的qps变化图，可见数据库压力的增加极快。

当Web应用服务出现性能瓶颈的时候，因为服务自己无状态（stateless），咱们能够经过加机器的水平扩展方式来解决。 而数据库显然没法经过简单的添加机器来实现扩展，所以咱们采起了Mysql主从同步和应用服务端读写分离的方案。

Mysql支持主从同步，实时将主库的数据增量复制到从库，并且一个主库能够链接多个从库同步（细节参考Replication）。利用此特性，咱们在应用服务端对每次请求作读写判断，如果写请求，则把此次请求内的全部DB操做发向主库；如果读请求，则把此次请求内的全部DB操做发向从库，以下图所示。

实现读写分离后，数据库的压力减小了许多，CPU使用率和IO使用率都降到了5%内，Slow Query也趋近于0。主从同步、读写分离给咱们主要带来以下两个好处：

减轻了主库（写）压力：达达的业务主要来源于读操做，作读写分离后，读压力转移到了从库，主库的压力减少了数十倍。

从库（读）可水平扩展（加从库机器）：因系统压力主要是读请求，而从库又可水平扩展，当从库压力太时，可直接添加从库机器，缓解读请求压力

以下是优化后数据库qps的变化图：

读写分离前主库的select qps

读写分离后主库的select qps

固然，没有一个方案是万能的。读写分离，暂时解决了Mysql压力问题，同时也带来了新的挑战。业务高峰期，商家发完订单，在个人订单列表中却看不到当发的订单（典型的read after write）；系统内部偶尔也会出现一些查询不到数据的异常。经过监控，咱们发现，业务高峰期Mysql可能会出现主从延迟，极端状况，主从延迟高达10秒。

那如何监控主从同步状态？在从库机器上，执行show slave status，查看Seconds_Behind_Master值，表明主从同步从库落后主库的时间，单位为秒，若主从同步无延迟，这个值为0。Mysql主从延迟一个重要的缘由之一是主从复制是单线程串行执行。

那如何为避免或解决主从延迟？咱们作了以下一些优化：

优化Mysql参数，好比增大innodb_buffer_pool_size，让更多操做在Mysql内存中完成，减小磁盘操做。

使用高性能CPU主机

数据库使用物理主机，避免使用虚拟云主机，提高IO性能

使用SSD磁盘，提高IO性能。SSD的随机IO性能约是SATA硬盘的10倍。

业务代码优化，将实时性要求高的某些操做，使用主库作读操做

垂直分库

读写分离很好的解决读压力问题，每次读压力增长，能够经过加从库的方式水平扩展。可是写操做的压力随着业务爆发式的增加没有颇有效的缓解办法，好比商家发单起来越慢，严重影响了商家的使用体验。咱们监控发现，数据库写操做愈来愈慢，一次普通的insert操做，甚至可能会执行1秒以上。

下图是数据库主库的压力， 可见磁盘IO使用率已经很是高，高峰期IO响应时间最大达到636毫秒，IO使用率最高达到100%。

同时，业务愈来愈复杂，多个应用系统使用同一个数据库，其中一个很小的非核心功能出现Slow query，经常影响主库上的其它核心业务功能。咱们有一个应用系统在MySql中记录日志，日志量很是大，近1亿行记录，而这张表的ID是UUID，某一天高峰期，整个系统忽然变慢，进而引起了宕机。监控发现，这张表insert极慢，拖慢了整个MySql Master，进而拖跨了整个系统。（固然在mysql中记日志不是一种好的设计，所以咱们开发了大数据日志系统，敬请关注本博客后续文章。另外一方面，UUID作主键是个糟糕的选择，在下文的水平分库中，针对ID的生成，有更深刻的讲述）。

这时，主库成为了性能瓶颈，咱们意识到，必需得再一次作架构升级，将主库作拆分，一方面以提高性能，另外一方面减小系统间的相互影响，以提高系统稳定性。这一次，咱们将系统按业务进行了垂直拆分。以下图所示，将最初庞大的数据库按业务拆分红不一样的业务数据库，每一个系统仅访问对应业务的数据库，避免或减小跨库访问。

下图是垂直拆分后，数据库主库的压力，可见磁盘IO使用率已下降了许多，高峰期IO响应时间在2.33毫秒内，IO使用率最高只到22.8%。

将来是美好的，道路是曲折的。垂直分库过程，咱们也遇到很多挑战，最大的挑战是：不能跨库join，同时须要对现有代码重构。单库时，能够简单的使用join关联表查询；拆库后，拆分后的数据库在不一样的实例上，就不能跨库使用join了。好比在CRM系统中，须要经过商家名查询某个商家的全部订单，在垂直分库前，能够join商家和订单表作查询，以下如示：

select * from tborder where supplierid in (select id from supplier where name=‘上海海底捞’)；

分库后，则要重构代码，先经过商家名查询商家id，再经过商家Id查询订单表，以下所示：

supplierids = select id from supplier where name=‘上海海底捞’

select * from tb_order where supplierid in (supplierids )

垂直分库过程当中的经验教训，使咱们制定了SQL最佳实践，其中一条即是程序中禁用或少用join，而应该在程序中组装数据，让SQL更简单。一方面为之后进一步垂直拆分业务作准备，另外一方面也避免了Mysql中join的性能较低的问题。

通过一个星期紧锣密鼓的底层架构调整，以及业务代码重构，终于完成了数据库的垂直拆分。拆分以后，每一个应用程序只访问对应的数据库，一方面将单点数据库拆分红了多个，分摊了主库写压力；另外一方面，拆分后的数据库各自独立，实现了业务隔离，再也不互相影响。

水平分库（sharding）

读写分离，经过从库水平扩展，解决了读压力；垂直分库经过按业务拆分主库，缓存了写压力，但系统依然存在如下隐患：

单表数据量愈来愈大。如订单表，单表记录数很快将过亿，超出MySql的极限，影响读写性能。

核心业务库的写压力愈来愈大，已不能再进一次垂直拆分，Mysql 主库不具有水平扩展的能力

之前，系统压力逼迫咱们架构升级，这一次，咱们需提早作好架构升级，实现数据库的水平扩展(sharding)。业务相似于咱们的Uber在公司成立的5年后（2014）年才实施了水平分库（mezzanine-migration）,但咱们的业务发展要求咱们在成立18月就要开始实施水平分库。逻辑架构图以下图所示：

水平分库面临的第一个问题是，按什么逻辑进行拆分。一种方案是按城市拆分，一个城市的全部数据在一个数据库中；另外一种方案是按订单ID平均拆分数据。按城市拆分的优势是数据聚合度比较高，作聚合查询比较简单，实现也相对简单，缺点是数据分布不均匀，某些城市的数据量极大，产生热点，而这些热点之后可能还要被迫再次拆分。按订单ID拆分则正相反，优势是数据分布均匀，不会出现一个数据库数据极大或极小的状况，缺点是数据太分散，不利于作聚合查询。好比，按订单ID拆分后，一个商家的订单可能分布在不一样的数据库中，查询一个商家的全部订单，可能须要查询多个数据库。针对这种状况，一种解决方案是将须要聚合查询的数据作冗余表，冗余的表不作拆分，同时在业务开发过程当中，减小聚合查询。

反复权衡利弊，并参考了Uber等公司的分库方案后，咱们最后决定按订单ID作水平分库。从架构上，咱们将系统分为三层：

应用层：即各种业务应用系统

数据访问层：统一的数据访问接口，对上层应用层屏蔽读写分库、分库、缓存等技术细节。

数据层：对DB数据进行分片，并可动态的添加shard分片。

水平分库的技术关键点在于数据访问层的设计，数据访问层主要包含三部分：

ID生成器：生成每张表的主键

数据源路由：将每次DB操做路由到不一样的shard数据源上

缓存： 采用Redis实现数据的缓存，提高性能（之后会有详细文章）

ID生成器是整个水平分库的核心，它决定了如何拆分数据，以及查询存储-检索数据。ID须要跨库全局惟一，不然会引起业务层的冲突。此外，ID必须是数字且升序，这主要是考虑到升序的ID能保证Mysql的性能（如果UUID等随机字符串，在高并发和大数据量状况下，性能极差。对比性能测试数据可供参考uuid-vs-int-insert-performance）。同时，ID生成器必须很是稳定，由于任何故障都会影响全部的数据库操做。

咱们的ID的生成策略借鉴了Instagram的ID生成算法（sharding-ids-at-instagram）。具体方案以下：

整个ID的二进制长度为64位

前36位使用时间戳，以保证ID是升序增长

中间13位是分库标识，用来标识当前这个ID对应的记录在哪一个数据库中

后15位为自增序列，以保证在同一秒内并发时，ID不会重复。每一个shard库都有一个自增序列表，生成自增序列时，从自增序列表中获取当前自增序列值，并加1，作为当前ID的后15位。