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

http://mp.weixin.qq.com/s?__biz=MzIyNjE4NDcyMA==&mid=2247483732&idx=1&sn=1e027b3dce33ec16cc3410d6e38cfaa9&chksm=e8751a2bdf02933de087684a097793dadd02d4ae5f2d59df70e6f69938b6c96722773583c9fa&mpshare=1&scene=1&srcid=1013zpydsdTVFQZy6grmTpPE#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部分可废弃。

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

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


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值