1号店订单系统水平分库的实践之路以及关键步骤(转)

转载来源：http://mp.weixin.qq.com/s?__biz=MzA5Nzc4OTA1Mw==&mid=410615920&idx=1&sn=68e2a57aa4dcf2f047703cf4e4a0427a#rd

随着大型互联网应用的发展，海量数据的存储和访问成为系统设计的瓶颈，分布式处理成为不二选择。数据库拆分，特别是水平分库是个高难度的活，涉及一系列技术决策。

本人有幸负责1号店订单水平分库的方案设计及实施落地，本人结合项目实践，对水平分库作一个系统地剖析，但愿为你们水平分库（包括去IOE）改造提供整体思路，主要内容包括：

1. 水平分库说明

2. 分库维度-- 根据哪一个字段分库

3. 分库策略-- 记录如何分配到不一样库

4. 分库数量-- 初始库数量及库数量如何增加

5. 路由透明-- 如何实现库路由，支持应用透明

6. 分页处理-- 跨多个库的分页case如何处理

7. Lookup映射—非分库字段映射到分库字段，实现单库访问

8. 总体架构-- 分库的总体技术架构

9. 上线步骤-- 分库改造实施上线

10. 项目总结

一. 水平分库说明 

　　数据库拆分有两种：

　　1)   垂直分库: 数据库里的表太多，拿出部分到新的库里，通常是根据业务划分表，关系密切的表放同一数据库，应用修改数据库链接便可，比较简单。

　　2)   水平分库: 某张表太大，单个数据库存储不下或访问性能有压力，把一张表拆成多张，每张表存放部分记录，保存在不一样的数据库里，水平分库须要对系统作大的改造。

　　

　　1号店核心的订单表存储在Oracle数据库，记录有上亿条，字段有上百个，访问的模式也是复杂多样，随着业务快速增加，不管存储空间或访问性能都面临巨大挑战，特别在大促时，订单库已成为系统瓶颈。

　　一般有两种解决办法：

1. Scale up，升级Oracle数据库所在的物理机，提高内存/存储/IO性能，但这种升级费用昂贵，而且只能知足短时间须要。

2. Scale out，把订单库拆分为多个库，分散到多台机器进行存储和访问，这种作法支持水平扩展，能够知足长远须要。

　　1号店采起后一种作法，它的订单库主要包括订单主表/订单明细表（记录商品明细）/订单扩展表，水平分库即把这3张表的记录分到多个数据库中，订单水平分库效果以下图所示：

　　

 　　原来一个Oracle库被多个MySQL库取代，支持1主多备和读写分离，主备之间经过MySQL自带的数据同步机制（SLA<1秒），全部应用经过订单服务访问订单数据。

二. 分库维度 

　　水平分库首先要考虑根据哪一个字段做为分库维度，选择标准是尽可能避免应用代码和SQL性能受影响，这就要求当前SQL在分库后，访问尽可能落在单个库里，不然单库访问变成多库扫描，读写性能和应用逻辑都会受较大影响。

　　对于订单拆分，你们首先想到的是按照用户Id拆分，结论没错，但最好仍是数听说话，不能拍脑壳。好的作法是首先收集全部SQL，挑选where语句最常出现的过滤字段，好比用户Id/订单Id/商家Id，每一个字段在SQL中有三种状况：

1. 单Id过滤，如用户Id=？

2. 多Id过滤，如用户Id IN (?,?,?)

3. 该Id不出现

　　而后进一步统计，假设共有500个SQL访问订单库，3个过滤字段出现状况以下：

过滤字段	单Id过滤	多Id过滤	不出现
用户Id	120	40	330
订单Id	60	80	360
商家Id	15	0	485

　　结论明显，应该选择用户Id进行分库。

　　等一等，这只是静态分析，每一个SQL访问的次数是不同的，所以还要分析每一个SQL的访问量。咱们分析了Top15执行最多的SQL (它们占总执行次数85%)，若是按照用户Id分库，这些SQL 85%落到单个数据库, 13%落到多个数据库，只有2%须要遍历全部数据库，明显优于使用其余Id进行分库。

　　经过量化分析，咱们知道按照用户Id分库是最优的，同时也大体知道分库对现有系统的影响，好比这个例子中，85%的SQL会落到单个数据库，这部分的访问性能会优化，坚决了各方对分库的信心。

三. 分库策略

　　分库维度肯定后，如何把记录分到各个库里呢？通常有两种方式：

• 根据数值范围，好比用户Id为1-9999的记录分到第一个库，10000-20000的分到第二个库，以此类推。

• 根据数值取模，好比用户Id mod n，余数为0的记录放到第一个库，余数为1的放到第二个库，以此类推。

　　两种分法的优劣比较以下：

评价指标	按照范围分库	按照Mod分库
库数量	前期数目比较小，能够随用户/业务按需增加	前期即根据mode因子肯定库数量，数目通常比较大
访问性能	前期库数量小，全库查询消耗资源少，单库查询性能略差	前期库数量大，全库查询消耗资源多，单库查询性能略好
调整库数量	比较容易，通常只需为新用户增长库，老库拆分也只影响单个库	困难，改变mod因子致使数据在全部库之间迁移
数据热点	新旧用户购物频率有差别，有数据热点问题	新旧用户均匀到分布到各个库，无热点

　　实践中，为了处理简单，选择mod分库的比较多。同时二次分库时，为了数据迁移方便，通常是按倍数增长，好比初始4个库，二次分裂为8个，再16个。这样对于某个库的数据，一半数据移到新库，剩余不动，对比每次只增长一个库，全部数据都要大规模变更。

　　补充下，mod分库通常每一个库记录数比较均匀，但也有些数据库，存在超级Id，这些Id的记录远远超过其余Id，好比在广告场景下，某个大广告主的广告数可能占整体很大比例。若是按照广告主Id取模分库，某些库的记录数会特别多，对于这些超级Id，须要提供单独库来存储记录。

四. 分库数量 

　　分库数量首先和单库能处理的记录数有关，通常来讲，Mysql 单库超过5000万条记录，Oracle单库超过1亿条记录，DB压力就很大(固然处理能力和字段数量/访问模式/记录长度有进一步关系)。

　　在知足上述前提下，若是分库数量少，达不到分散存储和减轻DB性能压力的目的；若是分库的数量多，好处是每一个库记录少，单库访问性能好，但对于跨多个库的访问，应用程序须要访问多个库，若是是并发模式，要消耗宝贵的线程资源；若是是串行模式，执行时间会急剧增长。

　　最后分库数量还直接影响硬件的投入，通常每一个分库跑在单独物理机上，多一个库意味多一台设备。因此具体分多少个库，要综合评估，通常初次分库建议分4-8个库。 

五. 路由透明 

　　分库从某种意义上来讲，意味着DB schema改变了，必然影响应用，但这种改变和业务无关，因此要尽可能保证分库对应用代码透明，分库逻辑尽可能在数据访问层处理。固然彻底作到这一点很困难，具体哪些应该由DAL负责，哪些由应用负责，这里有一些建议：

1. 对于单库访问，好比查询条件指定用户Id，则该SQL只需访问特定库。此时应该由DAL层自动路由到特定库，当库二次分裂时，也只要修改mod 因子，应用代码不受影响。

2. 对于简单的多库查询，DAL负责汇总各个数据库返回的记录，此时仍对上层应用透明。

3. 对于带聚合运算的多库查询，如带groupBy/orderby/min/max/avg等关键字，建议DAL汇总单个库返回的结果，上层应用作进一步处理。一方面DAL全面支持各类case，实现很复杂；另外一方面，从1号店实践来看，这样的例子很少，在上层应用做针对性处理，更加灵活。

　　DAL可进一步细分为JDBC和DAL两层，基于JDBC层面实现分库路由，系统开发难度大，灵活性低，目前也没有很好的成功案例；通常是基于持久层框架进一步封装成DDAL(分布式数据访问层)，实现分库路由，1号店DAL即基于iBatis进行上层封装而来。

六. 分页处理 

　　分库后，有些分页查询须要遍历全部库，这些case是分库最大的受害者L。

　　举个分页的例子，好比要求按时间顺序展现某个商家的订单，每页100条记录，因为是按商家查询，须要遍历全部数据库，假设库数量是8，咱们来看下分页处理逻辑：

1. 若是取第1页数据，则须要从每一个库里按时间顺序取前100条记录，8个库汇总后有800条，而后对这800条记录在应用里进行二次排序，最后取前100条。

2. 若是取第10页数据，则须要从每一个库里取前1000(100*10)条记录，汇总后有8000条记录，而后对这8000条记录二次排序后取（900,1000）条记录。

　　分库状况下，对于第k页记录，每一个库要多取100*(k-1)条记录，全部库加起来，多取的记录更多，因此越是靠后的分页，系统要耗费更多内存和执行时间。

　　对比没分库的状况，不管取那一页，都只要从单个DB里取100条记录，并且无需在应用内部作二次排序，很是简单。

　　那如何解决分库状况下的分页问题呢？有如下几种办法：

1. 若是是在前台应用提供分页，则限定用户只能看前面n页，这个限制在业务上也是合理的，通常看后面的分页意义不大（若是必定要看，能够要求用户缩小范围从新查询）。

2. 若是是后台批处理任务要求分批获取数据，则能够加大page size，好比每次获取5000条记录，有效减小分页数（固然离线访问通常走备库，避免冲击主库）。

3. 分库设计时，通常还有配套大数据平台汇总全部分库的记录，有些分页查询能够考虑走大数据平台。

七. Lookup映射 

　　分库字段只有一个，好比这里是用户Id，但订单表还有其余字段可惟一区分记录，好比订单Id，给定一个订单Id，相应记录必定在某个库里。若是盲目地查询全部分库，则带来没必要要的开销，Lookup映射可根据订单Id，找到相应的用户Id，从而实现单库定位。

　　能够事先检索全部订单Id和用户Id，保存在Lookup表里，Lookup表的记录数和订单库记录总数相等，但它只有2个字段，因此存储和查询性能都不是问题。实际使用时，通常经过分布式缓存来优化Lookup性能。对于新增的订单，除了写订单表，同时要写Lookup表。  

八. 总体架构 

　　1号店订单水平分库的整体技术架构以下图所示：

 　　

1. 上层应用经过订单服务/分库代理和DAL访问数据库。

2. 代理对订单服务实现功能透明，包括聚合运算，非用户Id到用户Id的映射。

3. Lookup表用于订单Id/用户Id映射，保证按订单Id访问时，能够直接落到单个库，Cache是Lookup的内存数据映像，提高性能，cache故障时，直接访问Lookup表。

4. DAL提供库的路由，根据用户Id定位到某个库，对于多库访问，DAL支持可选的并发访问模式，并支持简单记录汇总。

5. Lookup表初始化数据来自于现有分库数据，新增记录时，直接由代理异步写入。

九. 上线步骤 

　　订单表是核心业务表，它的水平拆分影响不少业务，自己的技术改造也很大，很容易出纰漏，上线时，必须谨慎考虑，1号店整个方案实施过程以下：

　　首先实现Oracle和MySQL两套库并行，全部数据访问指向Oracle库，经过数据同步程序把数据从Oracle拆分到多个MySQL分库，好比3分钟增量同步一次。

1. 按照上述架构图搭建整个体系，选择几个对数据实时性不高的访问例子（如访问历史订单），转向MySQL分库访问，而后逐渐增长更多非实时case，以检验整套体系可行性。

2. 若是性能和功能都没问题，再一次性把全部实时读写访问转向MySQL，废弃Oracle。

　　这个上线步骤多了数据同步程序的开发（大约1人周工做量，风险很低），但分散了风险，把第一步的技术风险（Lookup/DAL等基础设施改造）和第二步的业务功能风险（Oracle改MySQL语法）分开。1号店两阶段上线都是一次性成功，特别是第二阶段上线，100多个依赖方应用简单重启即完成升级，中间没有出现一例较大问题。

十. 项目总结 

　　1号店完成订单水平分库的同时，把订单库从Oralce迁到MySQL，设备从小型机换成X86服务器，经过水平分库和去IOE，不但支持订单量将来增加，而且整体成本也大幅降低。

　　因为去IOE和订单分库一块儿实施，带来双重的性能影响，咱们花了很大精力作性能测试，为了模拟真实场景，你们经过Tcpcopy把线上实际的查询流量引到测试环境，前后通过13轮的性能测试，最终6个MySQL库相对一个Oracle，平均SQL执行时间基本持平，性能不下降的状况下，优化了架构，节省了成本。

　　对核心表作水平分库以前，必须先作好服务化，即外部系统经过统一的订单服务访问相关表，否则很容易遗漏一些SQL。

　　1号店最终是根据用户Id后三位取模，初始分6个库，理论上支持多达768个库，而且对订单Id生成规则作了改造，使其包括用户Id后三位，这样新订单Id自己包含库定位所需信息，无需走Lookup机制，随着老订单归档到历史库，上述架构中lookup部分可废弃。

　　水平分库是一项系统性工做，首先须要在理论模式指导下，结合实际状况，每一个方面作出最优选择。其次对于特殊场景，如跨库分页，没有银弹，能够灵活处理，不走常规路。最后控制好节奏，系统改造、数据迁移、上线实施等各个环节作好衔接，全局一盘棋。

　　大胆设计，当心求证，谨慎实施，分库并不难。

 

 做者介绍 

　　王庆友，前1号店首席架构师，前后就任于ebay、腾讯、1号店等公司，精通电商业务，擅长复杂系统业务建模和架构分析，同时在构建大规模的分布式系统方 面有丰富实践，尤为在大型系统的SOA改造方面有很深刻的理论和实践，目前在寻找合做机会，微信号Brucetwins，我的公众号”架构之道”，欢迎一块儿聊架构。