阅读笔记（十一）

在距离618前两个月时，京东商城商品虚拟研发部对系统做了整体预估，订单量快速增长及618大促的到来都将带来单量剧增，届时势必会对数据库容量和负载造成压力。

通过技术改造，从整体上来说实现三个目标：

1. 底层路由策略实现；

2. 历史数据迁移；

3. 业务改造。下面详细介绍本次改造的过程

分库分表最重要的是要先做容器预估，依据数据量和业务特性估算出容器/库/表的数量及分库分表规则。

 分库分表路由策略是基础，影响整个系统架构，后期业务需求是否满足和支持，使用是否方便都与此有关。路由策略设计合理，上层业务使用会很方便。一元抢宝项目的路由策略适配和实现是在DAO层实现，对上层业务层透明，可不用关心具体实现，并且路由策略不涉及结构上的改动，对上层不会产生影响。

hash路由，分区路由（增量区间路由）

一元抢宝项目的业务场景，有根据项id和期id查询订单参与纪录的场景，所以要考虑通过这两个维度能查到订单。另外，使用区间作为分表策略，可以动态扩展，即使每次查询经过路由表，这点开销可以忽略，而且都是通过缓存加载。

路由的维度有哪些呢？

1. 通过订单id路由:订单号按照一定规则生成，其存储了库和表的信息，可以根据订单号直接定位到相应的库和表；

2. 通过抢宝项id和抢宝期id路由：抢宝项hash定位到库，抢宝期查询路由策略表定位到表。

为什么通过MQ消息呢？还可以用以上两点来解释，一是消息支持失败重试，存储失败后抛异常，等待下次处理，二是系统间解耦。细心的朋友可以看到，一个消息队列，通过多个消费订阅（可以理解为每个消费者的队列都是镜像复制的）。这样做为了在存储时不相互影响；如果使用一个订阅者处理，存储ES失败，其他两个聚合存储成功，那也要抛异常或其他处理方式，下次消费时，另两个聚合还要存储一次。

一个系统从设计到最终完成，依赖于整个团队，每个人的想法、不同思路的碰撞和付出；再有前期合理细致的设计尤为重要，每个时间点和具体上线步骤和回滚方案做好详细计划；另外，就是细致深入测试，测试环境和线上多轮测试和回归，也是正常上线的重要保证。

原文部分转载：

京东618实践：一元抢宝系统的数据库架构优化