达达O2O后台架构演进实践：从0到4000高并发请求背后的努力
1、引言
达达创立于2014年5月，业务覆盖全国37个城市，拥有130万注册众包配送员，日均配送百万单，是全国领先的最后三公里物流配送平台。 达达的业务模式与滴滴以及Uber很相似，以众包的方式利用社会闲散人力资源，解决O2O最后三公里即时性配送难题（2016年4月，达达已经与京东到家合并）。
达达的业务组成简单直接——商家下单、配送员接单和配送，也正因为理解起来简单，使得达达的业务量在短时间能实现爆发式增长。而支撑业务快速增长的背后，正是达达技术团队持续不断的快速技术迭代的结果，本文正好借此机会，总结并分享了这一系列技术演进的第一手实践资料，希望能给同样奋斗在互联网创业一线的你带来启发。
（本文同步发布于：http://www.52im.net/thread-2141-1-1.html）
2、相关文章
《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
3、技术背景
达达业务主要包含两部分：
1）商家发单；
2）配送员接单配送。
达达的业务逻辑看起来非常简单直接，如下图所示：
达达的业务规模增长极大，在1年左右的时间从零增长到每天近百万单，给后端带来极大的访问压力。压力主要分为两类：读压力、写压力。读压力来源于配送员在APP中抢单，高频刷新查询周围的订单，每天访问量几亿次，高峰期QPS高达数千次/秒。写压力来源于商家发单、达达接单、取货、完成等操作。达达业务读的压力远大于写压力，读请求量约是写请求量的30倍以上。
下图是达达在成长初期，每天的访问量变化趋图，可见增长极快：
下图是达达在成长初期，高峰期请求QPS的变化趋势图，可见增长极快：
极速增长的业务，对技术的要求越来越高，我们必须在架构上做好充分的准备，才能迎接业务的挑战。接下来，我们一起看看达达的后台架构是如何演化的。
小知识：什么是QPS、TPS？
QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
TPS：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
4、最初的技术架构：简单直接
作为创业公司，最重要的一点是敏捷，快速实现产品，对外提供服务，于是我们选择了公有云服务，保证快速实施和可扩展性，节省了自建机房等时间。在技术选型上，为快速的响应业务需求，业务系统使用Python做为开发语言，数据库使用MySQL。
如下图所示，应用层的几大系统都访问一个数据库：
5、中期架构优化：读写分离
5.1 数据库瓶颈越来越严重
随着业务的发展，访问量的极速增长，上述的方案很快不能满足性能需求：每次请求的响应时间越来越长，比如配送员在app中刷新周围订单，响应时间从最初的500毫秒增加到了2秒以上。业务高峰期，系统甚至出现过宕机，一些商家和配送员甚至因此而怀疑我们的服务质量。在这生死存亡的关键时刻，通过监控，我们发现高期峰MySQL CPU使用率已接近80%，磁盘IO使用率接近90%，Slow Query从每天1百条上升到1万条，而且一天比一天严重。数据库俨然已成为瓶颈，我们必须得快速做架构升级。
如下是数据库一周的qps变化图，可见数据库压力的增长极快：
5.2 我们的读写分离方案
当Web应用服务出现性能瓶颈的时候，由于服务本身无状态（stateless），我们可以通过加机器的水平扩展方式来解决。 而数据库显然无法通过简单的添加机器来实现扩展，因此我们采取了MySQL主从同步和应用服务端读写分离的方案。
MySQL支持主从同步，实时将主库的数据增量复制到从库，而且一个主库可以连接多个从库同步。
利用MySQL的此特性，我们在应用服务端对每次请求做读写判断：
1）若是写请求，则把这次请求内的所有DB操作发向主库；
2）若是读请求，则把这次请求内的所有DB操作发向从库。
如下图所示：
实现读写分离后，数据库的压力减少了许多，CPU使用率和IO使用率都降到了5%内，Slow Query也趋近于0。
主从同步、读写分离给我们主要带来如下两个好处：
1）减轻了主库（写）压力：达达的业务主要来源于读操作，做读写分离后，读压力转移到了从库，主库的压力减小了数十倍；
2）从库（读）可水平扩展（加从库机器）：因系统压力主要是读请求，而从库又可水平扩展，当从库压力太时，可直接添加从库机器，缓解读请求压力。
如下是优化后数据库QPS的变化图：
▲ 读写分离前主库的select QPS
▲ 读写分离后主库的select QPS
5.3 新状况出现：主从延迟问题
当然，没有一个方案是万能的。
读写分离，暂时解决了MySQL压力问题，同时也带来了新的挑战：
1）业务高峰期，商家发完订单，在我的订单列表中却看不到当发的订单（典型的read after write）；
2）系统内部偶尔也会出现一些查询不到数据的异常。
通过监控，我们发现，业务高峰期MySQL可能会出现主从延迟，极端情况，主从延迟高达10秒。
那如何监控主从同步状态？在从库机器上，执行show slave status，查看Seconds_Behind_Master值，代表主从同步从库落后主库的时间，单位为秒，若同从同步无延迟，这个值为0。MySQL主从延迟一个重要的原因之一是主从复制是单线程串行执行。
那如何为避免或解决主从延迟？我们做了如下一些优化：
1）优化MySQL参数，比如增大innodb_buffer_pool_size，让更多操作在MySQL内存中完成，减少磁盘操作；
2）使用高性能CPU主机；
3）数据库使用物理主机，避免使用虚拟云主机，提升IO性能；
4）使用SSD磁盘，提升IO性能。SSD的随机IO性能约是SATA硬盘的10倍；
5）业务代码优化，将实时性要求高的某些操作，使用主库做读操作。
5.4 主库的写操作变的越来越慢
读写分离很好的解决读压力问题，每次读压力增加，可以通过加从库的方式水平扩展。但是写操作的压力随着业务爆发式的增长没有很有效的缓解办法，比如商家发单起来越慢，严重影响了商家的使用体验。我们监控发现，数据库写操作越来越慢，一次普通的insert操作，甚至可能会执行1秒以上。
下图是数据库主库的压力：
▲ 可见磁盘IO使用率已经非常高，高峰期IO响应时间最大达到636毫秒，IO使用率最高达到100%
同时，业务越来越复杂，多个应用系统使用同一个数据库，其中一个很小的非核心功能出现Slow query，常常影响主库上的其它核心业务功能。
我们有一个应用系统在MySQL中记录日志，日志量非常大，近1亿行记录，而这张表的ID是UUID，某一天高峰期，整个系统突然变慢，进而引发了宕机。监控发现，这张表insert极慢，拖慢了整个MySQL Master，进而拖跨了整个系统。（当然在MySQL中记日志不是一种好的设计，因此我们开发了大数据日志系统。另一方面，UUID做主键是个糟糕的选择，在下文的水平分库中，针对ID的生成，有更深入的讲述）。
5.5 进一步对主库进行拆分，优化主库写操作慢的问题
这时，主库成为了性能瓶颈，我们意识到，必需得再一次做架构升级，将主库做拆分：
1）一方面以提升性能；
2）另一方面减少系统间的相互影响，以提升系统稳定性。
这一次，我们将系统按业务进行了垂直拆分。
如下图所示，将最初庞大的数据库按业务拆分成不同的业务数据库，每个系统仅访问对应业务的数据库，避免或减少跨库访问：
下图是垂直拆分后，数据库主库的压力，可见磁盘IO使用率已降低了许多，高峰期IO响应时间在2.33毫秒内，IO使用率最高只到22.8%：
未来是美好的，道路是曲折的。
垂直分库过程，也遇到不少挑战，最大的挑战是：不能跨库join，同时需要对现有代码重构。单库时，可以简单的使用join关联表查询；拆库后，拆分后的数据库在不同的实例上，就不能跨库使用join了。
比如在CRM系统中，需要通过商家名查询某个商家的所有订单，在垂直分库前，可以join商家和订单表做查询，如下如示：
分库后，则要重构代码，先通过商家名查询商家id，再通过商家Id查询订单表，如下所示：
垂直分库过程中的经验教训，使我们制定了SQL最佳实践，其中一条便是程序中禁用或少用join，而应该在程序中组装数据，让SQL更简单。一方面为以后进一步垂直拆分业务做准备，另一方面也避免了MySQL中join的性能较低的问题。
经过一个星期紧锣密鼓的底层架构调整，以及业务代码重构，终于完成了数据库的垂直拆分。拆分之后，每个应用程序只访问对应的数据库，一方面将单点数据库拆分成了多个，分摊了主库写压力；另一方面，拆分后的数据库各自独立，实现了业务隔离，不再互相影响。
6、为未来做准备，进一步升级架构：水平分库（sharding）
通过上一节的分享，我们知道：
1）读写分离，通过从库水平扩展，解决了读压力；
2）垂直分库通过按业务拆分主库，缓存了写压力。
但技术团队是否就此高枕无忧？答案是：NO。
上述架构依然存在以下隐患：
1）单表数据量越来越大：如订单表，单表记录数很快将过亿，超出MySQL的极限，影响读写性能；
2）核心业务库的写压力越来越大：已不能再进一次垂直拆分，MySQL 主库不具备水平扩展的能力。
以前，系统压力逼迫我们架构升级，这一次，我们需提前做好架构升级，实现数据库的水平扩展(sharding)。我们的业务类似于Uber，而Uber在公司成立的5年后（2014）年才实施了水平分库，但我们的业务发展要求我们在成立18月就要开始实施水平分库。
本次架构升级的逻辑架构图如下图所示：
水平分库面临的第一个问题是，按什么逻辑进行拆分：
1）一种方案是按城市拆分，一个城市的所有数据在一个数据库中；
2）另一种方案是按订单ID平均拆分数据。
按城市拆分的优点是数据聚合度比较高，做聚合查询比较简单，实现也相对简单，缺点是数据分布不均匀，某些城市的数据量极大，产生热点，而这些热点以后可能还要被迫再次拆分。
按订单ID拆分则正相反，优点是数据分布均匀，不会出现一个数据库数据极大或极小的情况，缺点是数据太分散，不利于做聚合查询。比如，按订单ID拆分后，一个商家的订单可能分布在不同的数据库中，查询一个商家的所有订单，可能需要查询多个数据库。针对这种情况，一种解决方案是将需要聚合查询的数据做冗余表，冗余的表不做拆分，同时在业务开发过程中，减少聚合查询。
反复权衡利弊，并参考了Uber等公司的分库方案后，我们最后决定按订单ID做水平分库。
从架构上，我们将系统分为三层：
1）应用层：即各类业务应用系统；
2）数据访问层：统一的数据访问接口，对上层应用层屏蔽读写分库、分库、缓存等技术细节；
3）数据层：对DB数据进行分片，并可动态的添加shard分片。
水平分库的技术关键点在于数据访问层的设计。
数据访问层主要包含三部分：
1）ID生成器：生成每张表的主键；
2）数据源路由：将每次DB操作路由到不同的shard数据源上；
3）缓存： 采用Redis实现数据的缓存，提升性能。
ID生成器是整个水平分库的核心，它决定了如何拆分数据，以及查询存储-检索数据：
1）ID需要跨库全局唯一，否则会引发业务层的冲突；
2）此外，ID必须是数字且升序，这主要是考虑到升序的ID能保证MySQL的性能；
3）同时，ID生成器必须非常稳定，因为任何故障都会影响所有的数据库操作。
我们的ID的生成策略借鉴了Instagram的ID生成算法。
我们具体的ID生成算法方案如下：
如上图所示，方案说明如下：
1）整个ID的二进制长度为64位；
2）前36位使用时间戳，以保证ID是升序增加；
3）中间13位是分库标识，用来标识当前这个ID对应的记录在哪个数据库中；
4）后15位为MySQL自增序列，以保证在同一秒内并发时，ID不会重复。每个shard库都有一个自增序列表，生成自增序列时，从自增序列表中获取当前自增序列值，并加1，做为当前ID的后15位。
7、写在最后
创业是与时间赛跑的过程，前期为了快速满足业务需求，我们采用简单高效的方案，如使用云服务、应用服务直接访问单点DB。
后期随着系统压力增大，性能和稳定性逐渐纳入考虑范围，而DB最容易出现性能瓶颈，我们采用读写分离、垂直分库、水平分库等方案。
面对高性能和高稳定性，架构升级需要尽可能超前完成，否则，系统随时可能出现系统响应变慢甚至宕机的情况。
附录：架构设计相关文章汇总
[1] 有关IM架构设计的文章：
《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》
《IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》
《IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》
《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》
《WhatsApp技术实践分享：32人工程团队创造的技术神话》
《王者荣耀2亿用户量的背后：产品定位、技术架构、网络方案等》
《IM系统的MQ消息中间件选型：Kafka还是RabbitMQ？》
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路》
《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》
>> 更多同类文章 ……
[2] 更多其它架构设计相关文章：
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路》
《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》
《达达O2O后台架构演进实践：从0到4000高并发请求背后的努力》
>> 更多同类文章 ……
（本文同步发布于：http://www.52im.net/thread-2141-1-1.html）
达达O2O后台架构演进实践：从0到4000高并发请求背后的努力的更多相关文章
- 朱晔的互联网架构实践心得S2E6:浅谈高并发架构设计的16招
朱晔的互联网架构实践心得S2E6:浅谈高并发架构设计的16招 概览 标题中的高并发架构设计是指设计一套比较合适的架构来应对请求.并发量很大的系统,使系统的稳定性.响应时间符合预期并且能在极端的情况下自 ...
- APP后台架构开发实践笔记
1 App后台入门 1.1 App后台的功能 (1)远程存储数据: (2)消息中转. 1.2 App后台架构 架构设计的流程 (1) 根据App的设计,梳理出App的业务流程: (2) 把每个业务流程 ...
- 从游击队到正规军：马蜂窝旅游网的IM系统架构演进之路
本文引用自马蜂窝公众号,由马蜂窝技术团队原创分享. 一.引言 今天,越来越多的用户被马蜂窝持续积累的笔记.攻略.嗡嗡等优质的分享内容所吸引,在这里激发了去旅行的热情,同时也拉动了马蜂窝交易的增长.在帮 ...
- 从游击队到正规军(二)：马蜂窝旅游网的IM客户端架构演进和实践总结
一.引言 移动互联网技术改变了旅游的世界,这个领域过去沉重的信息分销成本被大大降低.用户与服务供应商之间.用户与用户之间的沟通路径逐渐打通,沟通的场景也在不断扩展.这促使所有的移动应用开发者都要从用户 ...
- 图解 Kafka 超高并发网络架构演进过程
阅读本文大约需要 30 分钟. 大家好,我是 华仔, 又跟大家见面了. 上一篇作为专题系列的第一篇,我们深度剖析了关于 Kafka 存储架构设计的实现细节,今天开启第二篇,我们来深度剖析下「Kafka ...
- Netty 100万级到亿级流量 高并发 仿微信 IM后台 开源项目实战
目录 写在前面 亿级流量IM的应用场景 十万级 单体IM 系统 高并发分布式IM系统架构 疯狂创客圈 Java 分布式聊天室[ 亿级流量]实战系列之 -10[ 博客园 总入口 ] 写在前面 大家好 ...
- Java生鲜电商平台-高并发的设计与架构
Java生鲜电商平台-高并发的设计与架构 说明:源码下载Java开源生鲜电商平台以及高并发的设计与架构文档 对于高并发的场景来说,比如电商类,o2o,门户,等等互联网类的项目,缓存技术是Java项目中 ...
- Redis的高并发、持久化、高可用架构设计
就是如果你用redis缓存技术的话,肯定要考虑如何用redis来加多台机器,保证redis是高并发的,还有就是如何让Redis保证自己不是挂掉以后就直接死掉了,redis高可用 我这里会选用我之前讲解 ...
- JAVA架构师眼中的高并发架构，分布式架构 应用服务器集群
前言 高并发经常会发生在有大活跃用户量,用户高聚集的业务场景中,如:秒杀活动,定时领取红包等. 为了让业务可以流畅的运行并且给用户一个好的交互体验,我们需要根据业务场景预估达到的并发量等因素,来设计适 ...
随机推荐
- charles修改接口返回值
我们在测试app时,如果想看大数据量的展示情况,可以通过charles修改接口返回值来实现. 步骤1:手机连接代理 步骤2:app端请求接口,查看charles抓包情况 步骤3:选择想要修改返回值的接 ...
- Python中__init__和self的意义和作用
由于类可以起到模板的作用,因此,可以在创建实例的时候,把一些我们认为必须绑定的属性强制填写进去.以学生类为例,通过定义一个特殊的__init__方法,在创建实例的时候,就把name,score等属性绑 ...
- ASP.NET Core 添加NLog日志支持(VS2015update3&VS2017)
1.创建一个新的ASP.NET Core项目 2.添加项目依赖 NLog.Web.AspNetCore 3.在项目目录下添加nlog.config文件: <?xml version=" ...
- 国内最火的10款Java开源项目，都是国人开发，CMS居多
原文链接:https://www.cnblogs.com/jimcsharp/p/8266954.html 国内的开源环境已经相当好,但是国内开发注重是应用,创新有但不多,从榜单可以看出,专门搞技术的 ...
- mysql修改用户密码命令
C:\Users\20160216>mysql -h 10.180.6.183 -u root -pEnter password: ******Welcome to the MySQL moni ...
- 某app的安全性分析过程
交互过程如下,可以发现问题很多 http://www.ixxxx.com//api/index/app图片验证码:{"data":{"imgCode":&quo ...
- 电商项目-商品表（spu）、规格表（sku）设计
之前在工作中,需要实现商品规格功能,做了很长一段时间,现在回过头来整理下设计思路. sku,spu概念: SPU = Standard Product Unit (标准化产品单元),SPU是商品信息聚 ...
- CSL的字符串
链接:https://ac.nowcoder.com/acm/contest/551/D 来源:牛客网 时间限制:C/C++ 1秒,其他语言2秒 空间限制:C/C++ 524288K,其他语言1048 ...
- Idea增加Idiff merger工具
File -- setting --- tolls -- diff & merge 选择使用外部diff工具和外部merge工具,选择winmerge工具目录. 就可以再version con ...
- 七、PyQT5控件——QSlider，QSpinBox
一.Qslider QSlider是一个滑动条,可以设置成水平或垂直放置.最常用的方法允许用户在某一范围内互动该滑块,并将滑块的位置转换成一个整数值(int类型),这种方式可以在某一个范围内平顺的变动 ...