一、背景
几年前我曾经服务过的一家电商公司，随着业务增长我们每天的订单量很快从30万单增长到了100万单，订单总量也突破了一亿。
当时用的Mysql数据库。根据监控，我们的每秒最高订单量已经达到了2000笔（不包括秒杀，秒杀TPS已经上万了）。
不过，直到此时，订单系统还是单库单表，幸好当时数据库服务器配置不错，我们的系统才能撑住这么大的压力。
业务量还在快速增长，再不重构系统早晚出大事，我们花了一天时间快速制定了重构方案。
重构？说这么高大上，不就是分库分表吗？的确，就是分库分表。不过除了分库分表，还包括管理端的解决方案，比如运营，客服和商务需要从多维度查询订单数据，分库分表后，怎么满足大家的需求？
分库分表后，上线方案和数据不停机迁移方案都需要慎重考虑。为了保证系统稳定，还需要考虑相应的降级方案。
二、为什么要分库分表？
当数据库产生性能瓶颈：IO瓶颈或CPU瓶颈。两种瓶颈最终都会导致数据库的活跃连接数增加，进而达到数据库可承受的最大活跃连接数阈值。
终会导致应用服务无连接可用，造成灾难性后果。可以先从代码，sql，索引几方面进行优化。如果这几方面已经没有太多优化的余地，就该考虑分库分表了。
1、IO瓶颈
磁盘读IO瓶颈。由于热点数据太多，数据库缓存完全放不下，查询时会产生大量的磁盘IO，查询速度会比较慢，这样会导致产生大量活跃连接，最终可能会发展成无连接可用的后果。
可以采用一主多从，读写分离的方案，用多个从库分摊查询流量。或者采用分库+水平分表（把一张表的数据拆成多张表来存放，比如订单表可以按user_id来拆分）的方案。
第二种：磁盘写IO瓶颈。由于数据库写入频繁，会产生频繁的磁盘写入IO操作，频繁的磁盘IO操作导致产生大量活跃连接，最终同样会发展成无连接可用的后果。
这时只能采用分库方案，用多个库来分摊写入压力。再加上水平分表的策略，分表后，单表存储的数据量会更小，插入数据时索引查找和更新的成本会更低，插入速度自然会更快。
2、CPU瓶颈
SQL问题。如果SQL中包含join，group by，order by，非索引字段条件查询等增加CPU运算的操作，会对CPU产生明显的压力。 这时可以考虑SQL优化，创建适当的索引，也可以把一些计算量大的SQL逻辑放到应用中处理。
单表数据量太大。由于单张表数据量过大，比如超过一亿，查询时遍历树的层次太深或者扫描的行太多，SQL效率会很低，也会非常消耗CPU。这时可以根据业务场景水平分表。
三、分库分表方案
分库分表主要有两种方案：
1、利用MyCat，KingShard这种代理中间件分库分表。好处是和业务代码耦合度很低，只需做一些配置即可，接入成本低。缺点是这种代理中间件需要单独部署，所以从调用链路上又多了一层。
而且分库分表逻辑完全由代理中间件管理，对于程序员完全是黑盒，一旦代理本身出问题（比如出错或宕机），会导致无法查询和存储相关业务数据，引发灾难性的后果。
如果不熟悉代理中间件源码，排查问题会非常困难。曾经有公司使用MyCat，线上发生故障后，被迫修改方案，三天三夜才恢复系统。
2、利用Sharding-Jdbc，TSharding等以Jar包形式呈现的轻量级组件分库分表。缺点是，会有一定的代码开发工作量，对业务有一些侵入性。
好处是对程序员透明，程序员对分库分表逻辑的把控会更强，一旦发生故障，排查问题会比较容易。
3、直接使用云平台的分布式数据库服务，这些数据库很多都支持分库分表。例如，阿里云的分布式数据库服务PolarDB-X。优点是基本没什么接入成本，配置一下，几乎不用改代码就可以了。
缺点是分库分表逻辑都在分布式数据库服务内部，可靠性完全靠云平台，万一出问题你一点办法都没有。
稳妥起见，我们选用了第二种方案，使用更轻量级的Sharding-Jdbc。
做系统重构前，我们首先要确定重构的目标，其次要对未来业务的发展有一个预期，这个可以找相关业务负责人了解。
根据目标和业务预期来确定重构方案。例如，我们希望经过本次重构，系统能支撑两年，两年内不再大改。业务方预期两年内日单量达到1000万。相当于两年后日订单量要翻10倍。
根据上面的数据，我们分成了16个数据库。按日订单量1000万来算，每个库平均的日订单量就是62.5万（1000万/16），每秒最高订单量理论上在1250左右 2000*（62.5万/100万）。
（注：文章前面描述过，100万是当前每天的订单量，2000是当前每秒钟的订单峰值）。这样数据库的压力基本上是可控的，而且基本不会浪费服务器资源。
每个库分了16张表，即便按照每天1000万的订单量，两年总单量是73亿（73亿=1000万*365*2），每个库的数据量平均是4.56亿（4.56亿=73亿/16），每张表的数据量平均是2850万（2850万=4.56亿/16）。
可以看到未来两到三年每张表的数据量也不算多，完全在可控范围。
分库分表主要是为了用户端下单和查询使用，按user_id的查询频率最高，其次是order_id。所以我们选择user_id做为sharding column，按user_id做hash，将相同用户的订单数据存储到同一个数据库的同一张表中。
这样用户在网页或者App上查询订单时只需要路由到一张表就可以获取用户的所有订单了，这样就保证了查询性能。
另外我们在订单ID（order_id）里掺杂了用户ID（user_id）信息。简单来说，order_id的设计思路就是，将order_id分为前后两部分，前面的部分是user_id，后面的部分是具体的订单编号，两部分组合在一起就构成了order_id。
这样我们很容易从order_id解析出user_id。通过order_id查询订单时，先从order_id中解析出user_id，然后就可以根据user_id路由到具体的库表了。
另外，数据库分成16个，每个库分16张表还有一个好处。16是2的N次幂，所以hash值对16取模的结果与hash值和16按位“与运算”的结果是一样的。我们知道位运算基于二进制，跨过各种编译和转化直接到最底层的机器语言，效率自然远高于取模运算。
有读者可能会问，查询直接查数据库，会不会有性能问题？是的。所以我们在上层加了Redis，Redis做了分片集群，用于存储活跃用户最近50条订单。
这样一来，只有少部分在Redis查不到订单的用户请求才会到数据库查询订单，这样就减小了数据库查询压力，而且每个分库还有两个从库，查询操作只走从库，进一步分摊了每个分库的压力。
有读者可能会问，为什么没采用一致性hash方案？用户查询最近50条之前的订单怎么办？
四、更好的分库分表方案
通过前面的描述，不难看出我们的分库分表方案有一些缺陷，比如采用hash取模的方式会产生数据分布不均匀的情况，扩容缩容也非常麻烦。
这些问题可以用一致性hash方案解决。基于虚拟节点设计原理的一致性hash可以让数据分布更均匀。
而且一致性hash采用环形设计思路，在增减节点时，使得数据迁移的成本会更低，只需要迁移临近节点的数据。
不过需要扩容时基本上要成倍扩容，在hash环上每个节点间隙都增加新的节点，这样才能分摊所有原有节点的访问和存储压力。
五、关于数据倾斜问题
分库分表，采用Hash取模的方式路由库表，经常会出现数据倾斜问题，比如可能会导致某些表的数据特别多，远超过其他表。严重时，甚至可能影响系统性能和稳定性。
数据倾斜特别严重时，就要考虑二次分表了，也就是添加一定数量的表，然后按照相应规则将对应的数据迁移到新表中。
上面我们提到了一致性哈希算法，这里我们就可以利用一致性哈希算法对倾斜的数据表进行二次分表。
首先，一致性哈希算法可以动态添加虚拟节点，在不增加表的情况下，减少数据倾斜。其次，一致性Hash算法在应对增加一张表这种场景时，只会引发部分数据迁移，不会像普通的Hash算法一样导致需要迁移几乎所有数据。
如果没明白上面两句话的意思，不要紧，继续往下看。
一致性hash采用环形设计思路，根据节点（库，表）的Hash值将所有节点映射到Hash环上，在我们查询和写入数据时，会根据该数据的Hash值计算出该数据在Hash环上的位置，
然后从该位置开始按顺时针方向找到Hash环上最近一个节点，这个节点就是该数据对应的节点（库，表）。
实际使用中，由于服务器节点数量有限，很有可能出现数据分布不均匀的情况。这个时候会出现大量数据都被映射到某一个节点的情况，
如下图左侧所示。
为了解决这个问题，一致性Hash算法巧妙利用了虚拟节点。虚拟节点是实际节点在Hash环上的复制品，一个实际节点可以对应很多的虚拟节点。虚拟节点越多，Hash环上的节点也就越多，数据分布也会越均匀。
如上图右侧所示，B'、C'、D' 是原始节点复制出来的虚拟节点，原本映射到节点D上的数据1和4，分别被映射到了B'和D'，最终会落到对应的真实节点B和D上。我们可以看到，虚拟节点让数据分布更均匀了。
如果需要增加新的节点（库，表）。例如新增了节点D，位置落在数据2和3之间。按照顺时针原则，数据2依然在节点C上，而数据3就会路由到节点D。
所以利用一致性Hash算法，在增加节点后我们只需要将很少的数据迁移到新节点上，在这里只需要将C节点的部分数据迁移到D上。
六、管理端技术方案
分库分表后，不同用户的订单数据散落在不同的库和表中，如果需要根据用户ID之外的其他条件查询订单。
例如，运营同学想从后台查出某天iphone7的订单量，就需要从所有数据库的表中查出数据然后在聚合到一起。这样代码实现非常复杂，而且查询性能也会很差。
所以我们需要一种更好的方案来解决这个问题。
我们采用了ES（Elastic Search）+HBase组合的方案，将索引与数据存储隔离。
可能参与条件检索的字段都会在ES中建一份索引，例如商家，商品名称，订单日期等。所有订单数据全量保存到HBase中。
我们知道HBase支持海量存储，而且根据rowkey查询速度超快。而ES的多条件检索能力非常强大。可以说，这个方案把ES和HBase的优点发挥地淋漓尽致。
看一下该方案的查询过程：先根据输入条件去ES相应的索引上查询符合条件的rowkey值，然后用rowkey值去HBase查询，后面这一步查询速度极快，查询时间几乎可以忽略不计。
如下图：
该方案，解决了管理端通过各种字段条件查询订单的业务需求，同时也解决了商家端按商家ID和其他条件查询订单的需求。如果用户希望查询最近50条订单之前的历史订单，也同样可以用这个方案。
每天产生数百万的订单数据，如果管理后台想查到最新的订单数据，就需要频繁更新ES索引。在海量订单数据的场景下，索引频繁更新会不会对ES产生太大压力？
ES索引有一个segment（片段）的概念。ES把每个索引分成若干个较小的 segment 片段。每一个 segement 都是一个完整的倒排索引，在搜索查询时会依次扫描相关索引的所有 segment。
每次 refresh（刷新索引） 的时候，都会生成一个新的 segement，因此 segment 实际上记录了索引的一组变化值。由于每次索引刷新只涉及个别segement片段，更新索引的成本就很低了。
所以，即便默认的索引刷新（refresh）间隔只有1秒钟，ES也能从容应对。
不过，由于每个 segement 的存储和扫描都需要占用一定的内存和CPU等资源，因此ES后台进程需要不断的进行segement合并来减少 segement 的数量，从而提升扫描效率以及降低资源消耗。
Mysql中的订单数据需要实时同步到Hbase和ES中。同步方案是什么？
我们利用Canal实时获取Mysql库表中的增量订单数据，然后把订单数据推到消息队列RocketMQ中，消费端获取消息后把数据写到Hbase，并在ES更新索引。
上面是Canal的原理图，
（1）Canal模拟mysql slave的交互协议，把自己伪装成mysql的从库；
（2）向mysql master发送dump协议；
（3） mysql master收到dump协议，发送binary log给slave（Canal)；
（4）Canal解析binary log字节流对象，根据应用场景对binary log字节流做相应的处理；
为了保证数据一致性，不丢失数据。我们使用了RocketMQ的事务型消息，保证消息一定能成功发送。另外，在Hbase和ES都操作成功后才做ack操作，保证消息正常消费。
七、不停机数据迁移
在互联网行业，很多系统的访问量很高，即便在凌晨两三点也有一定的访问量。由于数据迁移导致服务暂停，是很难被业务方接受的！下面就聊一下在用户无感知的前提下，我们的不停机数据迁移方案！
数据迁移过程我们要注意哪些关键点呢？第一，保证迁移后数据准确不丢失，即每条记录准确而且不丢失记录；第二，不影响用户体验，尤其是访问量高的C端业务需要不停机平滑迁移；第三，保证迁移后的系统性能和稳定性。
常用的数据迁移方案主要包括：挂从库，双写以及利用数据同步工具三种方案。下面分别做一下介绍。
1、挂从库
在主库上建一个从库。从库数据同步完成后，将从库升级成主库（新库），再将流量切到新库。
这种方式适合表结构不变，而且空闲时间段流量很低，允许停机迁移的场景。一般发生在平台迁移的场景，如从机房迁移到云平台，从一个云平台迁移到另一个云平台。
大部分中小型互联网系统，空闲时段访问量很低。在空闲时段，几分钟的停机时间，对用户影响很小，业务方是可以接受的。所以我们可以采用停机迁移的方案。步骤如下：
（1）新建从库（新数据库），数据开始从主库向从库同步。
（2）数据同步完成后，找一个空闲时间段。为了保证主从数据库数据一致，需要先停掉服务，然后再把从库升级为主库。如果访问数据库用的是域名，直接解析域名到新数据库（从库升级成的主库），如果访问数据库用的是IP，将IP改成新数据库IP。
（3）最后启动服务，整个迁移过程完成。
这种迁移方案的优势是迁移成本低，迁移周期短。缺点是，切换数据库过程需要停止服务。我们的并发量比较高，而且又做了分库分表，表结构也变了，所以不能采取这种方案！
2、双写
老库和新库同时写入，然后将老数据批量迁移到新库，最后流量切换到新库并关闭老库读写。
这种方式适合数据结构发生变化，不允许停机迁移的场景。一般发生在系统重构时，表结构发生变化，如表结构改变或者分库分表等场景。
有些大型互联网系统，平常并发量很高，即便是空闲时段也有相当的访问量。几分钟的停机时间，对用户也会有明显的影响，甚至导致一定的用户流失，这对业务方来说是无法接受的。
所以我们需要考虑一种用户无感知的不停机迁移方案。
聊一下我们的具体迁移方案，步骤如下：
（1）代码准备。在服务层对订单表进行增删改的地方，要同时操作新库（分库分表后的数据库表）和老库，需要修改相应的代码（同时写新库和老库）。准备迁移程序脚本，用于做老数据迁移。准备校验程序脚本，用于校验新库和老库的数据是否一致。
（2）开启双写，老库和新库同时写入。注意：任何对数据库的增删改都要双写；对于更新操作，如果新库没有相关记录，需要先从老库查出记录，将更新后的记录写入新库；为了保证写入性能，老库写完后，可以采用消息队列异步写入新库。
（3）利用脚本程序，将某一时间戳之前的老数据迁移到新库。
注意：a，时间戳一定要选择开启双写后的时间点，比如开启双写后10分钟的时间点，避免部分老数据被漏掉；
b，迁移过程遇到记录冲突直接忽略，因为第2步的更新操作，已经把记录拉到了新库；
c，迁移过程一定要记录日志，尤其是错误日志，如果有双写失败的情况，我们可以通过日志恢复数据，以此来保证新老库的数据一致。
（4）第3步完成后，我们还需要通过脚本程序检验数据，看新库数据是否准确以及有没有漏掉的数据
（5）数据校验没问题后，开启双读，起初给新库放少部分流量，新库和老库同时读取。由于延时问题，新库和老库可能会有少量数据记录不一致的情况，所以新库读不到时需要再读一遍老库。
然后再逐步将读流量切到新库，相当于灰度上线的过程。遇到问题可以及时把流量切回老库
（6）读流量全部切到新库后，关闭老库写入（可以在代码里加上热配置开关），只写新库
（7）迁移完成，后续可以去掉双写双读相关无用代码。
3、利用数据同步工具
我们可以看到上面双写的方案比较麻烦，很多数据库写入的地方都需要修改代码。有没有更好的方案呢？
我们还可以利用Canal，DataBus等工具做数据同步。以阿里开源的Canal为例。
利用同步工具，就不需要开启双写了，服务层也不需要编写双写的代码，直接用Canal做增量数据同步即可。相应的步骤就变成了：
（1）代码准备。准备Canal代码，解析binary log字节流对象，并把解析好的订单数据写入新库。准备迁移程序脚本，用于做老数据迁移。准备校验程序脚本，用于校验新库和老库的数据是否一致。
（2）运行Canal代码，开始增量数据（线上产生的新数据）从老库到新库的同步。
（3）利用脚本程序，将某一时间戳之前的老数据迁移到新库。
注意：a，时间戳一定要选择开始运行Canal程序后的时间点（比如运行Canal代码后10分钟的时间点），避免部分老数据被漏掉；
b，迁移过程一定要记录日志，尤其是错误日志，如果有些记录写入失败，我们可以通过日志恢复数据，以此来保证新老库的数据一致。
（4）第3步完成后，我们还需要通过脚本程序检验数据，看新库数据是否准确以及有没有漏掉的数据
（5）数据校验没问题后，开启双读，起初给新库放少部分流量，新库和老库同时读取。由于延时问题，新库和老库可能会有少量数据记录不一致的情况，所以新库读不到时需要再读一遍老库。
逐步将读流量切到新库，相当于灰度上线的过程。遇到问题可以及时把流量切回老库
（6）读流量全部切到新库后，将写入流量切到新库（可以在代码里加上热配置开关。注：由于切换过程Canal程序还在运行，仍然能够获取老库的数据变化并同步到新库，所以切换过程不会导致部分老库数据无法同步新库的情况）
（7）关闭Canal程序
（8）迁移完成。
九、降级方案
在大促期间订单服务压力过大时，可以将同步调用改为异步消息队列方式，来减小订单服务压力并提高吞吐量。
大促时某些时间点瞬间生成订单量很高。我们采取异步批量写数据库的方式，来减少数据库访问频次，进而降低数据库的写入压力。
详细步骤：后端服务接到下单请求，直接放进消息队列，订单服务取出消息后，先将订单信息写入Redis，每隔100ms或者积攒10条订单，批量写入数据库一次。
前端页面下单后定时向后端拉取订单信息，获取到订单信息后跳转到支付页面。用这种异步批量写入数据库的方式大幅减少了数据库写入频次，从而明显降低了订单数据库写入压力。
不过，因为订单是异步写入数据库的，就会存在数据库订单和相应库存数据暂时不一致的情况，以及用户下单后不能及时查到订单的情况。
因为毕竟是降级方案，可以适当降低用户体验，我们保证数据最终一致即可。根据系统压力情况，可以在大促开始时开启异步批量写的降级开关，大促结束后再关闭降级开关。流程如下图：
