沪江订单系统分表项目实践(订单数据系统查询迁移)，沪江产品。

数据的写入和查询分散到多个表，好处非常明显：

同时对现有系统影响范围大：

根据订单冷热数据特点以及与相关的订单系统分组情况，可以把冷数据和热数据单独存储。
这种方案有以下优势：

同时有存在一些缺点:

通过方案2+方案3，它既能解决单表容量过大问题又能满足当前业务的发展。
首先数据分离降低活动库的单表数据容量，依据当前的系统并发量活动库单表容量能够保持在合理的范围内。
同时冷数据所在库进行水平分表操作，能够保证单表容量在可控范围。

水平分表后，非分片规则的查询变的复杂。
避免遍历所有子表的方式就是存储全局的分片键与查询条件的关系。
全局的映射关系可以通过以下方式实现：

确定使用方案4后再次复盘所有业务需求，对于少数直接依赖订单库的系统，决定暂时提供一个全量的数据仓库供业务方使用，订单内部服务均不使用此数据仓库。
最终订单数据存储分为以下4个部分：

活动库存储实时产生的数据。
历史库存储2个月前的数据。
全量仓库存储所有数据。
ES存储历史库中订单索引数据。

当前应用服务与数据存储的架构如下图所示：

经过这次改造后变为下图所示结构：

方案执行

执行过程中，主要精力放在下面几个方面：

数据迁移主要通过定时任务把冷数据搬到历史库，主要遵循以下规则：

具体规则如下：

历史库的索引创建通过以下2种方式创建：

发送消息成功但是订单系统无法得知搜索引擎创建结果，因此部署定时巡检任务检查历史库订单是否已成功创建索引。

由于在第1步冷数据迁移过程中规定必须按顺序迁移订单，因此成功创建索引的订单号可以作为订单迁移的分界点，具体业务逻辑如下：

因此在定时巡检任务检查过程中，把已成功创建索引的最大订单号存储到订单分界表和缓存中，便于其它订单业务逻辑使用（例如查询服务，定时删除任务等）。

订单全量库同步

引用阿里开源项目 Otter 作为准实时同步工具，它基于 MySql binlog 实现，稳定性高，同时支持高可用部署。
为了避免 DELETE 语句同步到目标库，修改Otter 中部分源码实现 DELETE 语句过滤。
具体原理参考 Otter 官网介绍，我们采用的是单机房部署模式。
同时部署定时巡检任务，核查实时同步结果。

针对冷数据迁移过程中可能出现的丢订单或者数据不一致问题，通过以下措施解决：

针对全量仓库的一致性保证，除了 Otter 本身基于 binlog 的一套保障机制外，我们增加定时巡检任务检查1个小时内全量仓库与活动库的数据是否一致。

订单查询使用2个库：活动库和历史库。
具体执行过程如下：

订单查询服务包含两种分页查询方式：

多数据源分页问题本质是多个有序集合的分页问题。
对于第1种查询方式，每次查询都会知道上一次的起始或者结束位置，因此只需在查询条件中添加起始或者结束位置可以定位到哪几个数据源。
对于第2种查询方式，需要通过遍历数据源获取数据总量，计算总页码数，并且记录每个数据源满足条件的数据总量，然后根据当前请求页码和每页个数判断数据落在哪几个数据源。

实现过程中，我们遇到的问题是搜索服务存在深度分页限制（最多返回1000条记录），例如：每页20条记录，则只能翻到第50页。
而实际情况下后台某些运营查询业务超过这种限制。
因此我们采取修改查询条件的策略实现深度分页，下面简化描述深度分页实现：假设搜索服务中有10条记录，查询接口通过offset 和 limit 实现分页，具体如下图

如果分页没有限制的情况下，每页2条数据，则查询第1,2,3页数据语法如下： 第1页，offset=0,limit=2,返回100,102 第2页，offset=2,limit=2,返回110,200 第3页，offset=4,limit=2,返回201,300 现在offset和limit添加如下限制：offset<=1,limit<=2,则实际分页中这两个变量都有可能超过限制，解决思路如下：

public static void paging(int offset, int limit) {List<Integer> result = null;if (offset <= MAX_OFFSET) {result = pagingForLimit(offset, limit, null);} else if (offset > MAX_OFFSET) {int skipSize = offset; //需跳跃个数Integer currentItem = skip(skipSize);result = pagingForLimit(0, limit, currentItem);}if (result != null) {System.out.println(result.toString());} else {System.out.println("无值");}}

如果 offset 大于限制数（offset>MAX_OFFSET），则需要找到前一个满足条件的订单号，从而修改查询条件使 offset=0。
代码如下：

else if (offset > MAX_OFFSET) {int skipSize = offset; //需跳跃个数Integer currentItem = skip(skipSize);result = pagingForLimit(0, limit, currentItem);}

查找前一个订单号的主要方法是 skip，找到订单号后就可以修改 offset=0 解决offset 限制。
下面列出 skip 方法部分代码，如下所示。

/ @param size 表示前一个订单号的位置 @return 返回前一个订单号/private static Integer skip(int size) {int maxSkipStep = MAX_OFFSET + MAX_LIMIT;//最大跳跃步长if (size <= maxSkipStep) {return get(size, null);} else {Integer preInteger = null;while (size > maxSkipStep) {List<Integer> tmp = query(MAX_OFFSET, MAX_LIMIT, preInteger);preInteger = tmp.get(tmp.size() - 1);size -= maxSkipStep;}return get(size, preInteger);}}

主要利用搜索服务最大查询个数跳跃查询，减少查找次数。
解决 offset 的限制后，开始着手处理 limit 的限制。
同样通过修改前一个订单号多次查询获取当前页的所有数据。

/ 带限制的分页 @param offset 请求偏移量 @param limit 请求个数 @param currentItem 前一个订单号 @return/private static List<Integer> pagingForLimit(int offset, int limit, Integer currentItem) {if (limit <= MAX_LIMIT) {return query(offset, limit, currentItem);} else {List<Integer> result = query(offset, MAX_LIMIT, currentItem);limit -= MAX_LIMIT;while (limit > MAX_LIMIT) {Integer pre = null;if (result != null) {pre = result.get(result.size() - 1);}result.addAll(query(0, MAX_LIMIT, pre));limit -= MAX_LIMIT;}if (limit > 0) {Integer preInteger = result.get(result.size() - 1);result.addAll(query(0, limit, preInteger));}return result;}}上线发布

为了保证平稳上线，整个项目分6个步骤，4次发布，具体执行计划如下:

第1批发布：

第2批发布：

第3批发布：

第4批发布：

通过这次项目，订单单表容量得到有效控制，用户端订单查询 QPS 提升2倍，运营端历史订单查询提升4倍。
当前方案也存在一些问题：全量仓库容量问题，此全量仓库主要目的是减少直接依赖交易库的外围系统的改动。
接下来需要与外围系统制定更合理的获取订单全量数据的方式，去除全量仓库的依赖。

作者:何江华

来源-微信公众号:沪江技术

出处:https://mp.weixin.qq.com/s/TGJiwqd4wcQ4KWsbJLLvfA