`
IXHONG
  • 浏览: 450032 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

【转】京东一元抢宝系统的数据库架构优化

阅读更多

[京东技术]声明:本文转载自微信公众号“开涛的博客”,转载务必声明。

 

作者:匙凯明,京东高级开发工程师,在京东负责一元抢宝系统架构和开发工作;多年互联网经验,对于系统架构和设计有自己的见解和经验。

 

本文是根据凯明在京东内部进行的#京东技术节#《一元抢宝分库分别策略与实现》技术分享整理而成。

 

一元抢宝系统是京东虚拟新兴的一个业务系统,上线以来订单量一直持续增长。在距离618前两个月时,京东商城商品虚拟研发部对系统做了整体预估,订单量快速增长及618大促的到来都将带来单量剧增,届时势必会对数据库容量和负载造成压力。分析结果表明数据库很可能成为影响性能的瓶颈,并决定对数据库底层做分库分表改造,确保数据水平动态扩展能力,满足数据容量持续增长的需求,并提高下单效率。

一、业务介绍

图片描述

上图是一元抢宝商品详情页,从图中可以看出,一元抢宝的商品即商品项,其不同于其他京东商品的地方在于:有期次、总人次和剩余人次的概念;假设一个商品项有100个库存,则会分100期次售卖,每期次一个售卖的是一个库存;总人次即设置的每一期抢宝商品价格,假设1000人次,则商品总价是1000元(每人1元);当剩余人次为0时,本期抢宝结束,然后按照相应算法产生抢宝者;然后进行下一期抢宝。

通过技术改造,从整体上来说实现三个目标:

  1. 底层路由策略实现;
  2. 历史数据迁移;
  3. 业务改造。下面详细介绍本次改造的过程。

二、数据库容器预估

分库分表最重要的是要先做容器预估,依据数据量和业务特性估算出容器/库/表的数量及分库分表规则。

假设一天100万订单,一年则产生3.6亿订单量;假设数据结构是这样的:订单表10个字段,一个字段50个字符;一条订单则需要500字节存储,那么3.6亿订单则需要大约170GB存储空间;假设每台机器存储空间为200GB,则每年增加一台机器即可满足容量需求。而实际需求要根据压测结果来决定;如压测其他一些指标是否满足需求,如QPS、响应时间等。

三、底层路由策略选择及实现

分库分表路由策略是基础,影响整个系统架构,后期业务需求是否满足和支持,使用是否方便都与此有关。路由策略设计合理,上层业务使用会很方便。一元抢宝项目的路由策略适配和实现是在DAO层实现,对上层业务层透明,可不用关心具体实现,并且路由策略不涉及结构上的改动,对上层不会产生影响。

我们知道常见的分表策略有两种:

hash路由

  • 优点:可实现数据分散,热点分散;
  • 不足:增加数据库节点时,会影响路由策略,需做数据迁移;

分区路由(增量区间路由)

  • 优点:策略支持动态扩容,理论上可无限扩展;
  • 不足:存在数据热点问题,新产生的表,读写频率较高;每次查询需要经过路由策略表。

当然每种策略都不是完美的,只有最适合业务场景的策略才是好的。该项目采用的是两种方式的结合。

首先按抢宝项hash分库,然后按抢宝期区间段分表,如下图所示:

图片描述

期的路由策略表规则如下:

图片描述

为什么使用这种策略?

抢宝项是业务上层维度,可以理解为商品,大部分表中都有这个字段;此id生成时是连续的,长期来看,hash分库后数据是均衡的。抢宝期是抢宝项下的一个维度,如一个项库存是100,不停售前提下,会生成100期,在售的期次只有一个。为什么选择期id区间作为分表路由策略呢,有朋友会认为也可以选择订单id,从路由策略上来说,没有问题,但一元抢宝项目的业务场景,有根据项id和期id查询订单参与纪录的场景,所以要考虑通过这两个维度能查到订单。另外,使用区间作为分表策略,可以动态扩展,即使每次查询经过路由表,这点开销可以忽略,而且都是通过缓存加载。

那以上策略,可以路由的维度有哪些呢?

  1. 通过订单id路由:订单号按照一定规则生成,其存储了库和表的信息,可以根据订单号直接定位到相应的库和表;
  2. 通过抢宝项id和抢宝期id路由:抢宝项hash定位到库,抢宝期查询路由策略表定位到表,具体图示如下:

图片描述

四、聚合查询及聚合数据同步的实现

有分就涉及到聚合查询,我们如何实现呢?先看如下架构图:

图片描述

上图是数据层改造后的架构图,之前是单表主从模式,改造后为多个分库、基础库。聚合采用了elastic search (以下简称ES)。

为什么使用它呢,首先,简单便捷,容易接入;其次,支持动态扩容分片,对业务层透明等。系统中的聚合查询主要使用了ES,当然我们有很多降级方案,后面会讲到。ES不能当作库来使用,它并不能百分之百保证数据完整性,所以一定要有数据备份,我们使用了聚合表,保存一段时间内的数据,用于降级使用,一旦ES有延迟或集群不可用,就会降级查询聚合表。

同步ES我们是怎么做的呢?我们使用了canal。有的朋友可能说了,为什么不在直接在代码中插入时去同步,可以这样做,但有两个问题,一是同步失败如何处理,如何保证事务,二是与业务代码强耦合,借用术语,不beautify。使用canal,代码解耦,不侵入与代码。它其实是模拟了数据库主从复制机制,伪装为一个从库,当数据库(为不影响主库生产,我们监听的是从库)binlog有变化时,canal监听到,通过解析服务解析过滤binlog,把需要的日志过滤出来。解析后,我们通过发送MQ消息,消息体是表名和主键id,不是整条数据,消费端接到变化的表名和id,实时从库中查询最新数据,同步到ES、聚合表。

为什么通过MQ消息呢?还可以用以上两点来解释,一是消息支持失败重试,存储失败后抛异常,等待下次处理,二是系统间解耦。细心的朋友可以看到,一个消息队列,通过多个消费订阅(可以理解为每个消费者的队列都是镜像复制的)。这样做为了在存储时不相互影响;如果使用一个订阅者处理,存储ES失败,其他两个聚合存储成功,那也要抛异常或其他处理方式,下次消费时,另两个聚合还要存储一次。

以上就是我们聚合和同步聚合的设计。查询时,一部分业务会先查询缓存,不存在再查询ES,如果降级,才会查库,正常的聚合查询都不会查到库。

五、历史数据迁移

由于我们系统上线时是单库,分库是上线几个月后做的技改,所以数据需要迁移,主要迁移步骤如下:

图片描述

前半部分,从扫描到同步到分库是新代码,后面canal到同步ES、聚合表都是复用上面逻辑,这样设计,降低我们整体工作量,并且保证数据迁移完整。

具体迁移细节如下:

图片描述

可以看出,主要分为两部分,停机前和停机后。停机前是迁移历史数据,支持重复迁移;停机后,只迁移增量部分,这样,大大缩短我们的上线时间。停机后只需要迁移很少的数据量。

迁移就涉及到数据校验,校验逻辑整体来说比较简单:

图片描述

三个维度分别和基础库做对比,如果不同,重新迁移某一天数据。

六、系统关键节点降级

这一部分也很重要,我们的降级主要有两点,一是canal同步延迟降级,一是ES不可用降级。第一种如下:

图片描述

如果canal同步延迟,或者从库挂掉,开启开关,扫描主库数据(最近几小时)直接同步到ES、聚合表;这样,即使从库挂掉,也不影响业务数据,这一点很重要,实际业务场景中我们也遇到过。

ES降级,ES不可用时,关闭ES开关,直接查询聚合表。

图片描述

七、总结

一个系统从设计到最终完成,依赖于整个团队,每个人的想法、不同思路的碰撞和付出;再有前期合理细致的设计尤为重要,每个时间点和具体上线步骤和回滚方案做好详细计划;另外,就是细致深入测试,测试环境和线上多轮测试和回归,也是正常上线的重要保证。

以上就是京东一元抢宝项目分库分表的主要思想,希望有同样想法的朋友可以深入交流,互相提升系统架构。

分享到:
评论

相关推荐

    京东云数据库架构实践

    在京东云数据库架构实践中,我们深入探讨了云环境中数据库的关键设计和实现,这对于任何希望优化其数据基础设施的架构师和数据库专业人士来说都是极其重要的。京东作为国内领先的电商平台,其数据库架构的设计与实施...

    京东青龙系统数据库架构演进.pdf

    《京东青龙系统数据库架构演进》是一份详细介绍京东青龙系统从传统架构到云架构转变过程的技术文档。青龙系统作为京东的核心物流系统,涵盖了7个智能物流中心,运营着254个大型仓库,仓储面积达到550万平方米,并...

    京东青龙系统架构篇.pptx

    京东青龙系统架构篇 京东青龙系统架构是京东集团研发的电子商务平台架构,旨在提供高效、可靠、灵活的电子商务解决方案。下面是对京东青龙系统架构的详细分析: 架构组件 京东青龙系统架构主要由以下几个组件组成...

    京东云数据库架构实践.pptx

    【京东云数据库架构实践】 京东云数据库架构是一个复杂而精细的体系,旨在满足不同规模和需求的业务场景。随着业务的扩展,从最初的简单架构逐渐演变为多层面、跨数据中心的分布式架构,以应对海量数据处理、高并发...

    京东Iphone一元夺宝辅助工具

    IPhone一元夺宝模拟软件,可以根据投注数模拟中奖结果

    京东数据库设计.docx

    京东数据库设计是一个全面的系统架构,它涉及到多个关键的数据实体,包括账户管理、活动记录、活动结算、第三方支付结算以及咨询信息等。这份文档详细阐述了这些核心表的设计,为理解京东的业务流程和数据存储提供了...

    大数据智能物流管理系统-京东青龙系统架构分析.pdf

    在大数据智能物流管理系统领域,京东青龙系统是一个具有代表性的创新应用,它的系统架构分析对于理解当前智能物流的运作模式和技术支撑具有重要意义。根据标题和描述,本文将详细探讨京东青龙系统的架构特点以及其...

    京东弹性数据库中间件-JED.pdf

    京东弹性数据库中间件(JED)是京东自主研发的一种数据库中间件解决方案,旨在解决互联网环境下对于数据库性能、可用性和灵活性的高要求。JED支持多种数据库协议,包括MySQL、PostgreSQL、Oracle和SqlServer,适合在...

    【免授权新增利息宝】京东淘宝唯品会自动抢单系统源码.zip

    【免授权新增利息宝】京东淘宝唯品会自动抢单系统源码是一个针对电商平台自动抢单功能的软件系统。此源码主要适用于京东、淘宝、唯品会等平台,旨在帮助用户快速、自动地捕捉到商品的抢购机会,尤其在面对限量秒杀或...

    V10抢单系统唯品会京东淘宝自动抢单区块系统源码.rar

    全新V10抢单系统唯品会京东淘宝自动抢单区块系统源码 完美运营 可封装app 某宝5000元的全新修复级自动抢单V10源码,跟传统抢单大的区别就是平台取用第三方匹配平台,自动匹配订单,简单化了程序,效率更高,收益...

    最新京东省市区街道地址数据库

    省市区县乡四级地址MYSQL数据库。获取自京东地址接口。不定时更新,可重新下载。京东接口地址https://d.jd.com/area/get?fid=4744,可自行验证获取。

    京东金融数据库多场景架构介绍.docx

    京东金融作为国内领先的金融科技公司,其数据库架构设计对于支撑大规模业务、处理海量数据至关重要。本文将深入探讨京东金融在数据库架构方面所采用的多种场景下的解决方案。 首先,京东金融的数据库架构必须具备高...

    京东抢购源码.zip_python京东抢卷_python抢购京东_京东抢券 python_京东抢购脚本_京东源码

    基于python的京东抢券脚本,通过获取URL利用bp4进行自动访问,实现自动抢券 (The Jingdong voucher script based on the python)

    京东弹性数据库技术架构.pptx

    京东弹性数据库技术架构是针对大型电商平台数据库系统的高效解决方案,旨在解决单机性能瓶颈、资源利用率不均以及数据迁移频繁等问题。随着业务的发展,京东在2011年初期依赖于传统的关系型数据库系统,如Oracle、...

    京东金融平稳高效的数据库运维体系研究

    本文档为京东金融的数据库运维技术分享,对于研究数据库运维体系有非常好的指导意义,建议架构师和从业人员研读。

    抢单系统京东淘宝自动抢单区块源码.zip

    抢单系统京东自动抢单区块系统源码

    最新版-淘宝京东拼多多唯品会商城自动抢单系统源码.zip

    "最新版-淘宝京东拼多多唯品会商城自动抢单系统源码.zip" 这个标题提到了几个关键元素,首先,"最新版"表明这是该软件或系统的最新开发版本,通常意味着包含了最新的功能改进和修复。其次,"淘宝京东拼多多唯品会...

    京东云无线宝一代AC2100,第三方系统刷回原系统资料,包含固件和breed

    然而,有时候用户可能希望回归原厂设置,将路由器恢复到出厂状态,这时就需要用到“京东云无线宝一代AC2100,第三方系统刷回原系统资料”中的固件和Breed。 固件(Firmware)是存储在硬件设备内的软件,它控制设备...

    京东金融数据库多场景架构实践.pdf

    【京东金融数据库多场景架构实践】是京东金融在数据库架构设计和管理方面的一次深入探讨。这个实践主要涉及以下几个核心知识点: 1. **发展历程**:从2014年到2017年,京东金融数据库经历了从部署、灾备、监控的高...

    京东应用架构设计与治理.pdf

    文档中提到的618经验包括架构的弹性扩展、应对高并发场景的策略、数据库的优化、系统的容灾备份等方面,强调了在大型活动期间系统稳定性和性能的保持。 ### 结论 综上所述,京东的应用架构设计充分体现了其在大型...

Global site tag (gtag.js) - Google Analytics