万花镜
    首页社会国际娱乐科技时尚军事汽车探索美食旅游历史健康育儿

    一个可供参考的订单系统分库分表实践

    2017年3月20日 来源: 互联网
    一个可供参考的订单系统分库分表实践

    作者|华慰

    编辑|小智

    “分库分表”是谈论数据库架构和优化时经常听到的关键词。对于这些业务量正在高速增长的公司,它并不那么容易实践。这是来自大众点评团队的技术实践,仅供参考。

    注:本文授权转自微信公众号「美团点评技术团队」

    写在前面

    原大众点评的订单单表早已突破两百G,由于查询维度较多,即使加了两个从库,优化索引,仍然存在很多查询不理想的情况。去年大量抢购活动的开展,使数据库达到瓶颈,应用只能通过限速、异步队列等对其进行保护;业务需求层出不穷,原有的订单模型很难满足业务需求,但是基于原订单表的DDL又非常吃力,无法达到业务要求。随着这些问题越来越突出,订单数据库的切分就愈发急迫了。

    这次切分,我们的目标是未来十年内不需要担心订单容量的问题。

    垂直切分

    先对订单库进行垂直切分,将原有的订单库分为基础订单库、订单流程库等,本文就不展开讲了。

    一个可供参考的订单系统分库分表实践

    水平切分

    垂直切分缓解了原来单集群的压力,但是在抢购时依然捉襟见肘。原有的订单模型已经无法满足业务需求,于是我们设计了一套新的统一订单模型,为同时满足C端用户、B端商户、客服、运营等的需求,我们分别通过用户ID和商户ID进行切分,并通过PUMA(我们内部开发的MySQL binlog实时解析服务)同步到一个运营库。

    一个可供参考的订单系统分库分表实践

    切分策略

    1. 查询切分

    将ID和库的Mapping关系记录在一个单独的库中。

    一个可供参考的订单系统分库分表实践

    优点:

    缺点:

    2. 范围切分

    比如按照时间区间或ID区间来切分。

    一个可供参考的订单系统分库分表实践

    优点:

    缺点:

    3. Hash切分

    一般采用Mod来切分,下面着重讲一下Mod的策略。

    一个可供参考的订单系统分库分表实践

    数据水平切分后我们希望是一劳永逸或者是易于水平扩展的,所以推荐采用mod 2^n这种一致性Hash。

    以统一订单库为例,我们分库分表的方案是32*32的,即通过UserId后四位mod 32分到32个库中,同时再将UserId后四位Div 32 Mod 32将每个库分为32个表,共计分为1024张表。线上部署情况为8个集群(主从),每个集群4个库。

    为什么说这种方式是易于水平扩展的呢?我们分析如下两个场景。

    场景一:数据库性能达到瓶颈

    方法一

    按照现有规则不变,可以直接扩展到32个数据库集群。

    一个可供参考的订单系统分库分表实践

    方法二

    如果32个集群也无法满足需求,那么将分库分表规则调整为(32*2^n)*(32/2^n),可以达到最多1024个集群。

    一个可供参考的订单系统分库分表实践

    场景二:单表容量达到瓶颈(或者1024已经无法满足你)

    方法:

    一个可供参考的订单系统分库分表实践

    假如单表都已突破200G,200*1024=200T(按照现有的订单模型算了算,大概一万千亿订单,相信这一天,嗯,指日可待!),没关系,32*(32*2^n),这时分库规则不变,单库里的表再进行裂变,当然,在目前订单这种规则下(用userId后四位 mod)还是有极限的,因为只有四位,所以最多拆8192个表,至于为什么只取后四位,后面会有篇幅讲到。

    另外一个维度是通过ShopID进行切分,规则8*8和UserID比较类似,就不再赘述,需要注意的是Shop库我们仅存储了订单主表,用来满足Shop维度的查询。

    唯一ID方案

    这个方案也很多,主流的有那么几种:

    1. 利用数据库自增ID

    优点:最简单。

    缺点:单点风险、单机性能瓶颈。

    2. 利用数据库集群并设置相应的步长(Flickr方案)

    优点:高可用、ID较简洁。

    缺点:需要单独的数据库集群。

    3. Twitter Snowflake

    优点:高性能高可用、易拓展。

    缺点:需要独立的集群以及ZK。

    4. 一大波GUID、Random算法

    优点:简单。

    缺点:生成ID较长,有重复几率。

    我们的方案

    为了减少运营成本并减少额外的风险我们排除了所有需要独立集群的方案,采用了带有业务属性的方案:

    时间戳+用户标识码+随机数

    有下面几个好处:

    方便、成本低。

    基本无重复的可能。

    自带分库规则,这里的用户标识码即为用户ID的后四位,在查询的场景下,只需要订单号就可以匹配到相应的库表而无需用户ID,只取四位是希望订单号尽可能的短一些,并且评估下来四位已经足够。

    可排序,因为时间戳在最前面。

    当然也有一些缺点,比如长度稍长,性能要比int/bigint的稍差等。

    其他问题

    事务支持:我们是将整个订单领域聚合体切分,维度一致,所以对聚合体的事务是支持的。

    复杂查询:垂直切分后,就跟join说拜拜了;水平切分后,查询的条件一定要在切分的维度内,比如查询具体某个用户下的各位订单等;禁止不带切分的维度的查询,即使中间件可以支持这种查询,可以在内存中组装,但是这种需求往往不应该在在线库查询,或者可以通过其他方法转换到切分的维度来实现。

    数据迁移

    数据库拆分一般是业务发展到一定规模后的优化和重构,为了支持业务快速上线,很难一开始就分库分表,垂直拆分还好办,改改数据源就搞定了,一旦开始水平拆分,数据清洗就是个大问题,为此,我们经历了以下几个阶段。

    第一阶段

    一个可供参考的订单系统分库分表实践

    数据库双写(事务成功以老模型为准),查询走老模型。

    每日job数据对账(通过DW),并将差异补平。

    通过job导历史数据。

    第二阶段

    一个可供参考的订单系统分库分表实践

    历史数据导入完毕并且数据对账无误。

    依然是数据库双写,但是事务成功与否以新模型为准,在线查询切新模型。

    每日job数据对账,将差异补平。

    第三阶段

    一个可供参考的订单系统分库分表实践

    老模型不再同步写入,仅当订单有终态时才会异步补上。

    此阶段只有离线数据依然依赖老的模型,并且下游的依赖非常多,待DW改造完就可以完全废除老模型了。

    简单总结

    并非所有表都需要水平拆分,要看增长的类型和速度,水平拆分是大招,拆分后会增加开发的复杂度,不到万不得已不使用。

    在大规模并发的业务上,尽量做到在线查询和离线查询隔离,交易查询和运营/客服查询隔离。

    拆分维度的选择很重要,要尽可能在解决拆分前问题的基础上,便于开发。

    数据库没你想象的那么坚强,需要保护,尽量使用简单的、良好索引的查询,这样数据库整体可控,也易于长期容量规划以及水平扩展。

    最后感谢一下棒棒的DBA团队和数据库中间件团队对项目的大力协助!

    活动彩蛋

    华为软件开发云是一个智能化软件研发管理平台,

    通过云服务的方式开放华为20多年积累的软件工程能力,

    助力软件开发团队打造一流的软件产品。

    风起云又聚,华为企业云邀你共赢未来,

    3月22日,我们在华为青岛软件开发云大会见!

    戳 「 阅读原文 」,即刻报名!

    一个可供参考的订单系统分库分表实践今日荐号一个可供参考的订单系统分库分表实践StuQ

    InfoQ推出的IT教育平台——斯达克学院(StuQ ) 为技术人提供系统实战课程 学习微服务,机器学习,iOS开发最潮流技术 回复“课程”获得热门课程介绍和优惠码

    微信ID:stuq2015

    今日荐文

    点击下方图片即可阅读

    一个可供参考的订单系统分库分表实践

    2月最受欢迎的10篇技术好文

    位置:首页 > 科技
    加载更多评论...
    本类推荐
    下雨时怎样找到晴雨分界线?|No.56
    下雨时怎样找到晴雨分界线?|No.56

    你是否也有这样的童年?雨天的时候界限分明的下雨和不下雨的分界线如果找到它就可以一脚踩在下雨区一脚踩在晴朗区一只眼看烟雨迷蒙一只眼看晴空万里然而本小编十分不幸至今从未见过这条魔幻的分界线机智幸运如你可曾见过它的样子吗?

    论文推荐|王宁波:不同NeQuick电离层模型参数的应用精度分析
    论文推荐|王宁波:不同NeQuick电离层模型参数的应用精度分析

    《测绘学报》构建与学术的桥梁 拉近与权威的距离测绘地理信息与导航高端论坛 ——《测绘学报》创刊60周年学术研讨会通知(第一号)王宁波1,221221. 中国科学院光电研究院, 北京 100094;2. 中国科学院测量与地球物理研究所大地测量与地球动力学国家重点实验室...

    MongoDB干货集合:优势、限制和选型建议,在高德的实践
    MongoDB干货集合:优势、限制和选型建议,在高德的实践

    云栖社区(欢迎订阅微信)原文链接:yq.aliyun.com/articles/7557如需内容转载合作,请联系:yqeditor@list.alibaba-inc.com2016年3月5日,MongoDB杭州用户交流会在阿里巴巴西溪园区顺利举行...

    高可用失灵:交换机导致Oracle集群故障致机场停运
    高可用失灵:交换机导致Oracle集群故障致机场停运

    最近日本的一则数据库故障引发了全日航空(ANA)航班停运,被广泛关注。据日本《产经新闻》3月22日报道,日本全日空航空公司(ANA)的国内航班系统22日8时20分开始发生故障,导致旅客无法办理登机手续,目前正在逐步恢复。

    专访搜狗DBA负责人王林平:为何从Oracle转向MySQL?
    专访搜狗DBA负责人王林平:为何从Oracle转向MySQL?

    王林平CSDN:首先,请做个自我介绍,目前所负责的领域以及所在公司。王林平:大家好,我是王林平,目前在搜狗商业平台研发部工作。主要负责商业广告数据库的维护、优化、架构设计、流程体系建设、自动化运维平台建设等工作,目前比较关注数据库备份恢复、性能优化、运维自动化等几个领域。

    亿级商品数量下,当当这样构建平台化架构
    亿级商品数量下,当当这样构建平台化架构

    “架构平台化是一个很大的话题,本文只针对中间层解决方案阐述,资源层不在讨论范围。本文分享的内容大部分都已开源。回复关键词「平台」,获取本文讲师在QCon 2016 北京站的演讲PPT。当当业务体系简介请先看当当的业务特征...

    利用openfire来搭建基于XMPP协议的推送、IM服务器
    利用openfire来搭建基于XMPP协议的推送、IM服务器

    对于推送,IM服务器,前几章节,我曾经说过目前可以使用一些厂家提供的SDK来实现,但是我们的老板又总是担心使用别人的SDK,假如别人的服务出现问题,或者别人偷看咱们的信息,那岂不是出现很大问题了,况且还存在一定的价格问题...

    这座花了5年才建成的小镇,当看到里面模型中的模型会让你超爱!
    这座花了5年才建成的小镇,当看到里面模型中的模型会让你超爱!

    这是英国科茨沃尔德的水上柏顿 (Bourton-on-the-Water) 小镇,这里河水相连,处处可见宜人景致,且到处充满石砖小屋与古树,是座历史悠久的小镇 。不过这里除了优美的景致和建筑之外,还有一样非常独特的地方,那就是它的小镇模型。

    这应该是迄今为止最全的一份Java就业指导书
    这应该是迄今为止最全的一份Java就业指导书

    想要成为合格的Java程序员或工程师到底需要具备哪些专业技能,面试者在面试之前到底需要准备哪些东西呢?本文陈列的这些内容既可以作为个人简历中的内容,也可以作为面试的时候跟面试官聊的东西,你可以把这些内容写到你的简历中,当然更需要的是你在面试的时候向面试官展示这些专业技能。

    详述车道检测的艰难探索:从透视变换到深度图像分割(附代码)
    详述车道检测的艰难探索:从透视变换到深度图像分割(附代码)

    王小新 编译自 Medium量子位 出品 | 公众号 QbitAI找到马路上的车道线,对于人类来说非常容易,但对计算机来说,一点阴影、反光、道路颜色的微小变化、或者车道线被部分遮挡,都会带来很大的困难。

    杨强教授第四范式内部分享:漫谈《西部世界》、GAN及迁移学习
    杨强教授第四范式内部分享:漫谈《西部世界》、GAN及迁移学习

    本文转载自第四范式公众号,量子位已获授权。「范式大学」由第四范式发起,致力于成为“数据科学家”的黄埔军校,校长为第四范式首席科学家,华人界首个国际人工智能协会AAAI Fellow、唯一的AAAI 华人执委杨强教授。

    可能是建模过程中最好用的数值模拟软件,COMSOL迎来重大更新
    可能是建模过程中最好用的数值模拟软件,COMSOL迎来重大更新

    仿真模拟问题这下容易解决了最近老有模友吐槽超模君好久没讲过关于数学建模的内容。超模君一脸心塞(我容易吗我):各位模友,别急,那今晚的主角还是留给数学建模。说起数学建模,大部分模友应该顺势也就会想MATLAB、SPSS、R语言等软件,确实,这可是数学建模的命脉。

    延伸热词
    首页社会国际娱乐科技时尚军事汽车探索美食旅游历史健康育儿
    万花镜 版权所有 京ICP备14059027号
    值班QQ:3012642954
    邮箱:wanhuajingnews@qq.com