58速运订单调度架构演进（一）

58速运订单调度架构演进（一）

今天很荣幸给大家介绍58速运从艰苦创业到成为同城货运行业领头人的整个系统演进过程。58速运业务简单说就是同城货运，比如去买一个大型家具，自己的家用车肯定是装不下的，这时可能需要找路边的小型面包车或者金杯车来帮你搬运。一般来讲，很容易遇到黑车，而且价格不标准，我们做的这个行业就是将这种传统的黑车行业进行线上化，在产品形态上可理解为滴滴打车的出租车版

1

背景

58速运在2014年是作为58集团下20多个孵化业务中的其中之一，平均三个星期一个业务孵化上线，当时有20多个业务孵化同时进行，这个时间我们不断的试错，不断去寻找58同城新的增长点

从上图中的大家可以看出所有的服务都基于在一个数据库来运行，这个系统之间只需要通过一些简单的tag标记就可以区分开业务，系统迭代非常快。新孵化的业务，增加一些简单的业务逻辑就能实现这个产品的快速上线

2

痛点

系统不稳定，一个慢SQL，全业务受影响。所有业务都集中在一个数据库中，一个慢SQL就会把数据库的所有连接占满，导致所有的服务不可用

多业务并存，订单表索引多，性能下降。 多业务并存，每一个业务都会根据它自己的业务需求去在订单表中建立索引，结果索引越来越多，整体性能越来越差

订单字段冗余，新增和修改字段非常痛苦。 每个业务都有特殊的业务字段，单标数据量已经到达了千万级，每增加一个字段和修改一个字段，都需要耗费很长的时间，而且会造成锁库导致系统异常

业务增长迅猛，数据库已成瓶颈。 58速运整体的订单增长非常迅速，在成立三个月以后，每天的单已达到了1万+，系统性能已成为瓶颈

3

技术演进方案

工程解耦，工程代码模块从历史模块中拆离，比较简单，不再详细描述

数据库迁移，从整体大库中独立出来。下面详细描述一下数据库的迁移方案

  最简单的方案就是停服，把所有的服务停掉，然后把数据库抽离出来，相对来讲这是成本最简单的

停服会产生的影响：

1）凌晨时间业务仍然有订单，会影响到用户访问

2）需要给用户发公告

3）停服迁移如果失败，无法向业务方解释，会丧失信任

我们的迁移方案：

将订单表放在新的数据库里，两个数据库之间使用双向同步

双向同步需要解决时问题：

主键冲突：速运的订单会标记一个比较特殊的标记ID（如80开头标记为速运，其他业务都是10开头的），与其它的业务线区分开，这样就可以保证它在双向同步时不会出现主键冲突的问题

更新覆盖：update的操作在同步的过程中因为时间差的问题可能存在写覆盖的情况，采用订单日志的记录，迁库完成后做数据的校验

举个例子详细说明一下：我们有1个集群，他部署了4台机器

迁移步骤：

因为要进行迁库，数据库的IP改变了，所以服务需要修改数据库连接的配置文件

当上线的时候。先重启机器A，然后A的insert和update就写到新的数据库了，但是机器B、C、D还写到老库上面

因为新库和旧库是开启着数据同步的，所以两个库的数据会完全一致，所以业务侧完全不会受到影响

当集群全部完成上线后，断开数据库之间的双向同步

4

演进成果

如上图所示：经过多次的迁移，将原有的数据库按照业务划分成了订单库、结算库、配置库和轨迹库等，每个数据库会根据业务量容量的大小来配置数据库物理机的内核、内存，减少成本