京东618：一个中心五个原则，谈谈物流系统的大促优化实践
|
副标题[/!--empirenews.page--]
《京东618：一个中心五个原则，谈谈物流系统的大促优化实践》要点：
作者:者文明 编辑:木环、郭蕾 在京东的订单流链路中,可以简单的划分为订单前和订单后两部分,我们在京东主站上搜索商品、浏览商品详情、把商品加入购物车、提交并支付订单等环节属于订单前,订单提交之后,订单信息流就进入订单后的物流系统部分.每逢 618 大促期间,大家可能会更多的聚焦到网站 PV、秒杀系统、交易数据、广告收入等等.其实对于京东来说,其很核心的优势来源于精准的时效承诺、极速的送货体验和极致的售后服务,在大促期间,其物流系统的表现对客户体验至关重要. 京东物流系统简介京东物流系统属于订单生产系统,主要包括订单履约、仓储、配送、客户服务和逆向处置中心等等.图 1 示意了一个简单的正向订单生产流程,逆向生产流程主要由逆向处置中心发起,主要包括售后服务单(退换货等)和安装维修单.
图 1 订单生产流程 京东物流系统有如下 3 大特性：
以上特性也决定了物流系统的大促备战和电商网站、订单交易、秒杀、搜索推荐、广告等系统会大有不同,在很大程度上系统 70% 以上的性能(容量)取决于 DB 的性能(容量).因此,DB 是我们每次大促备战的重点.围绕 DB 侧的备战工作,主要聚焦在慢 SQL、垂直和水平拆分、读写分离、生产库和报表库分离、连接池优化、参数调优等方面. 打不死的小强—慢 SQL记得刚加入京东第一次负责 618 的时候,在 618 当天就遇到了两次业务反馈系统卡顿的现象,紧急排查发现 DB 中大量连接堆积,再通过查看当前线程发现是一个慢 SQL(耗时 10 多秒)导致了连接堆积,后来把慢 SQL 紧急优化上线后系统恢复正常.从那天以后,我深深感受到了慢 SQL 对我们系统的影响,同时也明白了一点,一个慢 SQL 对我们的系统总是致命的,我们不能放过任何一个慢 SQL.为了说明一个慢 SQL 对系统的影响,截取了两张数据库 CPU 使用率在一个慢 SQL 优化前后的对比图(如图 2),从图中也可以看出,前后对比是非常明显的.
图 2 一个慢 SQL 优化前后 CPU 负载对比 在数据库优化方面,慢 SQL 优化是最重要且效果最好的一项工作,如果要用一个比喻去形容慢 SQL,打不死的小强是再贴切不过的了,慢 SQL 在我们的系统中是灭了一茬又一茬,似乎永远消灭不完.通常情况下,慢 SQL 的出现可能是因为过滤条件中没有索引、SQL 语句写的过于复杂、表中数据量过大,做了全表扫描等等,因此我们在进行慢 SQL 优化时,优先会通过添加索引解决,索引解决不了的才会去优化语法,拆解 SQL 语句,将大事务化小,通过适当冗余来减少关联,优化数据模型,通过历史数据结转减少数据量等等.总之优化慢 SQL 的方法很多,各系统要根据各自的特性和场景选择最优且成本最低的方案. 近几年来,京东的业务一直处于持续膨胀之中,系统中总会不断涌入很多新的业务需求,这样也就不可避免的引入了新的慢 SQL,所以每次大促,慢 SQL 优化是一大备战重点. 数据库垂直和水平拆分跟传统的企业应用系统一样,京东的仓储系统也经历过 C/S 和 B/S 时代,V3.0 之前用的是 SQLServer 和.Net 平台,而且整个仓储管理是一个系统,包括基础资料、库存、入库、出库、在库等,随着京东业务规模的迅速增长,每次大促的单量峰值也由早期的万级增长到了现在的亿级,这中间仓储系统进行了垂直拆分,将基础资料、库存、入库、出库、在库等拆分为独立系统独立部署(如图 3) .垂直拆分之后仓储系统一分为多,系统的容量也就成倍上升.
图 3 仓储系统数据库垂直拆分 除了仓储系统,其他很多系统(包括配送系统)都经历了垂直拆分的过程,垂直拆分不但可以很好的解耦系统,还能成倍提升系统容量. 京东的配送系统流量比仓储系统还要大,垂直拆分之后的系统容量不足以支撑大促期间的单量冲击,于是在垂直拆分的基础上又做了水平拆分,水平拆分除了常用的分库分表之外,还有部分复杂业务表的模型水平拆分,比如运单表,拆分成基础数据、扩展数据和状态管理三个表,有的表也会按读写比例进行拆分,比如将读多写少的列放一张表,读少写多的列放另一张表.图 4 是配送系统进行水平拆分的一个示意图.水平拆分之后,目前系统可以轻松应对大促期间的亿级单量,流量还远远未到系统的容量上限.
图 4 配送系统数据库水平拆分 分离技术分离技术也是我们每次大促备战中的常用方法,主要包括读 / 写分离,生产 / 监控分离和在线 / 离线分离. 我们大部分系统读写比例大约 10:1,对于关系型数据库来说,主要消耗来源于查询,尤其是复杂查询,所以为了提升数据库端的总体容量,必须尽可能的将查询 SQL 分离到从库上,主库只提供写服务和一些必要的读服务,图 5 中 B 为备份库,R 为从库,所有从库均可提供读服务,一个主库下可能会挂多个从库,多个从库根据业务场景需求可以做成负载均衡,也可以按业务优先级进行隔离并支持灵活切换.这样主库就只负责生产,避免了那些比较消耗性能的复杂查询影响到生产,同时系统的总体容量也会得到大大提升. （编辑：上饶站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
