达达-高性能服务端优化之路

业务场景

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

         

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

下图是达达过去6个月，每天的访问量变化趋图，可见增长极快。

下图是达达过去6个月，高峰期请求QPS的变化趋势图，可见增长极快。

      

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

最初的技术选型

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

        

        

读写分离

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

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