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

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

    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篇技术好文

    位置:首页 > 科技
    加载更多评论...
    本类推荐
    简洁又美丽的标准模型方程
    简洁又美丽的标准模型方程

    我记得最清楚的是,当我提出一个自认为能使人信服而又合理的建议时,爱因斯坦一点也不表示反对,而只是说,“啊,多么丑!”当他遇到一个他认为丑的方程时,他只是对它不感兴趣,并且不能理解为什么有些人愿意花费那么多时间在它上面。

    深度学习模型太大?这家公司直接跑在了树莓派上
    深度学习模型太大?这家公司直接跑在了树莓派上

    深度学习当前面临的一大热点问题是很多深度学习的模型太大而不方便在移动设备和嵌入式设备上使用。现在常见的模型比如图像分类模型基本都在500兆以上,自然语言处理的一些模型例如语言模型很多都在1G以上,机器翻译的模型也都是500兆以上。

    如何区分人工智能、机器学习和深度学习?
    如何区分人工智能、机器学习和深度学习?

    本文内容来自于硅谷投资人Lake Dai,LDV Partners合伙人。严肃编辑整理。人工智能(Artificial Intelligence)是一个最广泛的概念,人工智能的目的就是让计算机这台机器能够象人一样思考...

    方法论:用AARRR模型做数据分析
    方法论:用AARRR模型做数据分析

    数据分析是一项实战性的工作内容,只有在不停的优化中才能越做越好。对一个刚入门的产品经理来说,为一个全新的产品或项目做数据分析,都会有手足无措的感觉。现在,笔者把自己在数据分析这块工作上的所遇所思写成文章分享给大家,按照文章的步骤,你也能做出一个基本的数据分析。

    宜人贷系统架构-高并发下的进化之路
    宜人贷系统架构-高并发下的进化之路

    演讲嘉宾:宜人贷架构师孙军,拥有10 年的 Java 开发经验,先后在人民银行、1 号店、人人网、当当网从事软件开发与技术架构工作。本次分享以宜人贷的系统迭代发展过程为主,着重介绍系统发展过程中遇到的实际问题和解决的办法,并重点介绍宜人贷出借系统和借款系统的高并发解决方案。

    MySQL分布式数据库高可用实践:架构、复制机制、多机房
    MySQL分布式数据库高可用实践:架构、复制机制、多机房

    大家好!我是网易数据运维工程师杜明友,大家可以叫我老杜。首先介绍一下网易云,是网易集团旗下云计算和大数据品牌,本文要深入分析的案例是网易云旗下的即时通讯云平台业务,开发者通过集成客户端SDK和云端OPEN API...

    论文推荐|董杨:主成分分析的匹配点对提纯方法
    论文推荐|董杨:主成分分析的匹配点对提纯方法

    《测绘学报》构建与学术的桥梁 拉近与权威的距离测绘地理信息与导航高端论坛 ——《测绘学报》创刊60周年学术研讨会通知(第一号)董杨, 范大昭, 纪松, 雷蓉 信息工程大学, 河南 郑州 450000收稿日期:2016-05-24;

    深度|提升深度学习模型的表现,你需要这20个技巧(附论文)
    深度|提升深度学习模型的表现,你需要这20个技巧(附论文)

    选自machielearningmastery参与:杜夏德、陈晨、吴攀、Terrence、李亚洲你可以怎样让你的深度学习模型实现更好的表现?这是一个我常被问到的问题:「我该怎么提升准确度?」或者「如果我的神经网络表现很糟糕我该怎么办?

    保证分布式系统数据一致性的6种方案
    保证分布式系统数据一致性的6种方案

    编者按:本文由「高可用架构后花园」群讨论整理而成,后花园是一个面向架构师的增值服务,如需了解,请关注「高可用架构」后回复 VIP有人的地方,就有江湖有江湖的地方,就有纷争问题的起源在电商等业务中,系统一般由多个独立的服务组成,如何解决分布式调用时候数据的一致性?

    Google重磅突破相比LSTM,NLP关键任务提升20%
    Google重磅突破相比LSTM,NLP关键任务提升20%

    新智元编译 自然语言理解(NLP)是人工智能领域使用程度最高的技术之一。受益于最近 自然语言理解技术的发展,现在已经可以应用在很多领域,例如航班预定、客服服务、任务管理、聊天助手等。“自然语言处理已经成为了数据经济掌控之战的制高点...

    Python爬虫:喜马拉雅FM
    Python爬虫:喜马拉雅FM

    编程派微信号:codingpy,本文为阳光树林投稿,授权编程派原创发布。自己喜欢在上班的途中听点有声书,所以经常在喜马拉雅上找资源,要找到一个好听的节目不容易,虽然在喜马拉雅官网上可以按分类来看,但是却不能按点赞数或者评论内容排序找,不是很方便。

    教学使用的人骨模型居然是真人骨!?
    教学使用的人骨模型居然是真人骨!?

    学校里使用的人骨模型一般是用PVC(聚氯乙烯)材料制造的。没什么可怕,对不对!!然而,要是真的人骨呢?英国Merseyside 一高中(Haydock High School)有一具使用了40年的“人骨模型”,因传说这是真人骨。

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