1. 达达系统架构升级经验总结
1.1. 概述
- 达达是全国领先的最后三公里物流配送平台。达达业务主要包含两部分：商家发单，配送员接单配送。
- 达达的业务规模增长极大，在1年左右的时间从零增长到每天近百万单，给后端带来极大的访问压力。压力主要分为两类：读压力、写压力。读压力来源于配送员在APP中抢单，高频刷新查询周围的订单，每天访问量几亿次，高峰期QPS高达数千次/秒。写压力来源于商家发单、达达接单、取货、完成等操作。达达业务读的压力远大于写压力，读请求量约是写请求量的30倍以上。
1.2. 初始架构
- 随着业务的发展，访问量的极速增长，上述的方案很快不能满足性能需求。每次请求的响应时间越来越长，比如配送员在app中刷新周围订单，响应时间从最初的500毫秒增加到了2秒以上。业务高峰期，系统甚至出现过宕机，一些商家和配送员甚至因此而怀疑我们的服务质量。在这生死存亡的关键时刻，通过监控，我们发现高期峰MySQL CPU使用率已接近80%，磁盘IO使用率接近90%，Slow Query从每天1百条上升到1万条，而且一天比一天严重。数据库俨然已成为瓶颈，我们必须得快速做架构升级。
1.3. 读写分离
- 实现读写分离后，数据库的压力减少了许多，CPU使用率和IO使用率都降到了5%内，Slow Query也趋近于0。主从同步、读写分离给我们主要带来如下两个好处：
- 减轻了主库（写）压力：达达的业务主要来源于读操作，做读写分离后，读压力转移到了从库，主库的压力减小了数十倍。
- 从库（读）可水平扩展（加从库机器）：因系统压力主要是读请求，而从库又可水平扩展，当从库压力太时，可直接添加从库机器，缓解读请求压力。
1.4. 主从延迟
- 当然，没有一个方案是万能的。读写分离，暂时解决了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倍。
- 业务代码优化，将实时性要求高的某些操作，使用主库做读操作。
1.5. 数据库拆分
- 同时，业务越来越复杂，多个应用系统使用同一个数据库，其中一个很小的非核心功能出现Slow query，常常影响主库上的其它核心业务功能。
这时，主库成为了性能瓶颈，我们意识到，必需得再一次做架构升级，将主库做拆分，一方面以提升性能，另一方面减少系统间的相互影响，以提升系统稳定性。这一次，我们将系统按业务进行了垂直拆分。如下图所示，将最初庞大的数据库按业务拆分成不同的业务数据库，每个系统仅访问对应业务的数据库，避免或减少跨库访问。
垂直分库过程，也遇到不少挑战，最大的挑战是：不能跨库join，同时需要对现有代码重构。单库时，可以简单的使用join关联表查询；拆库后，拆分后的数据库在不同的实例上，就不能跨库使用join了。比如在CRM系统中，需要通过商家名查询某个商家的所有订单，在垂直分库前，可以join商家和订单表做查询，分库后，则要重构代码，先通过商家名查询商家id，再通过商家Id查询订单表。
垂直分库过程中的经验教训，使我们制定了SQL最佳实践，其中一条便是程序中禁用或少用join，而应该在程序中组装数据，让SQL更简单。一方面为以后进一步垂直拆分业务做准备，另一方面也避免了MySQL中join的性能较低的问题。
1.6. 水平分库
- 读写分离，通过从库水平扩展，解决了读压力；垂直分库通过按业务拆分主库，缓存了写压力，但系统依然存在以下隐患：
- 单表数据量越来越大。如订单表，单表记录数很快将过亿，超出MySQL的极限，影响读写性能。
- 核心业务库的写压力越来越大，已不能再进一次垂直拆分，MySQL 主库不具备水平扩展的能力。
- 水平分库面临的第一个问题是，按什么逻辑进行拆分。一种方案是按城市拆分，一个城市的所有数据在一个数据库中；另一种方案是按订单ID平均拆分数据。按城市拆分的优点是数据聚合度比较高，做聚合查询比较简单，实现也相对简单，缺点是数据分布不均匀，某些城市的数据量极大，产生热点，而这些热点以后可能还要被迫再次拆分。
- 按订单ID拆分则正相反，优点是数据分布均匀，不会出现一个数据库数据极大或极小的情况，缺点是数据太分散，不利于做聚合查询。比如，按订单ID拆分后，一个商家的订单可能分布在不同的数据库中，查询一个商家的所有订单，可能需要查询多个数据库。针对这种情况，一种解决方案是将需要聚合查询的数据做冗余表，冗余的表不做拆分，同时在业务开发过程中，减少聚合查询。
- 最终从架构上，我们将系统分为三层：
- 应用层：即各类业务应用系统。
- 数据访问层：统一的数据访问接口，对上层应用层屏蔽读写分库、分库、缓存等技术细节。
- 数据层：对DB数据进行分片，并可动态的添加shard分片。
- 水平分库的技术关键点在于数据访问层的设计，数据访问层主要包含三部分：
- ID生成器：生成每张表的主键
- 数据源路由：将每次DB操作路由到不同的shard数据源上
- 缓存： 采用Redis实现数据的缓存，提升性能
- ID生成器是整个水平分库的核心，它决定了如何拆分数据，以及查询存储-检索数据。ID需要跨库全局唯一，否则会引发业务层的冲突。此外，ID必须是数字且升序，这主要是考虑到升序的ID能保证MySQL的性能。同时，ID生成器必须非常稳定，因为任何故障都会影响所有的数据库操作。
- ID的生成策略借鉴了Instagram的ID生成算法。具体方案如下：
1.7. 总结
- 前期为了快速满足业务需求，我们采用简单高效的方案，如使用云服务、应用服务直接访问单点DB；后期随着系统压力增大，性能和稳定性逐渐纳入考虑范围，而DB最容易出现性能瓶颈，我们采用读写分离、垂直分库、水平分库等方案。面对高性能和高稳定性，架构升级需要尽可能超前完成，否则，系统随时可能出现系统响应变慢甚至宕机的情况。
1.8. 流程梳理
从一开始单个数据库 -> 到读写分离 -> 解决主从延迟 -> 数据库业务拆分 -> 数据水平拆分- 这个升级流程很多地方都能看到，大同小异，但是都没有明确的数据层面的参考，从这个流程我感触最深的就是，系统的压力真的大部分来自数据库，对服务层系统，做到能水平扩展，系统就已经可以承受很大的压力了
参考 https://blog.csdn.net/czbing308722240/article/details/52350219#commentBox