您可以捐助,支持我们的公益事业。

金额: 1元 10元 50元

姓名:

邮件:

电话:

公司:

说明:

认证码: 验证码,看不清楚?请点击刷新验证码 必填



  要资料 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 讲座吧   专家招募  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
 订阅
  捐助
解密京东高并发抢购系统的核心逻辑与架构实现
 
 来源:网络 发布于: 2017-4-17
来自于要资料   443 次浏览     评价:      
 

1、服务介绍

限时抢购又称闪购,英文Flash sale,起源于法国网站Vente Privée。闪购模式即是以互联网为媒介的B2C电子零售交易活动,以限时特卖的形式,定期定时推出国际知名品牌的商品,一般以原价1-5折的价格供专属会员限时抢购,每次特卖时间持续5-10天不等,先到先买,限时限量,售完即止。顾客在指定时间内(一般为20分钟)必须付款,否则商品会重新放到待销售商品的行列里。

模式特征:

品牌丰富 —— 推出国内外一二线名牌商品,供消费者购买选择?/p>

时间短暂 —— 每个品牌推出时间短暂,一般为5—10天,先到先买,限量售卖,售完即;

折扣超低 —— 以商品原价1—5折的价格销售,折扣力度大。

摘自【百度百科】,通过这段简介相信对限时抢购有了一定的了解,我们内部称之为抢购系统。

对于抢购系统来说,首先要有可抢购的活动,而且这些活动具有促销性质,比如直降500元。其次要求可抢购的活动类目丰富,用户才有充分的选择性。618(6.1-6.20)期间增量促销活动量非常多,可能某个活动力度特别大,大多用户都在抢,必然对系统是一个考验。这样抢购系统具有秒杀特性,并发访问量高,同时用户也可选购多个限时抢商品,与普通商品一起进购物车结算。这种大型活动的负载可能是平时的几十倍,所以通过增加硬件、优化瓶颈代码等手段是很难达到目标的,所以需要专门设计的抢购系统。

服务主要功能

创建促销服务:采销创建促销后,促销管理系统审核通过后,会调用抢购系统创建促销;

抢服务:为符合条件的订单操作剩余数,主要是扣减剩余数;

针对哪些SKU

目前主要为单品促销,直降或者一口价,比如:

  

主要渠道:移动APP、微信、手Q和主站

限购类型:限数量、限ip、限pin和限制ip与pin

2、系统设计要点

如何实现实时库存?

这里说的库存不是真正意义上的库存,其实是该促销可以抢购的数量,真正的库存在基础库存服务。用户点击『提交订单』按钮后,在抢购系统中获取了资格后才去基础库存服务中扣减真正的库存;而抢购系统控制的就是资格/剩余数。传统方案利用数据库行锁,但是在促销高峰数据库压力过大导致服务不可用,目前采用Redis集群(16分片)缓存促销信息,例如促销id、促销剩余数、抢次数等,抢的过程中按照促销id散列到对应分片,实时扣减剩余数。当剩余数为0或促销删除,价格恢复原价。

如何设计抢购Redis数据结构?

采销人员发布促销后,在抢购Redis中生成一笔记录,给抢服务提供基本信息。每一个促销对应一个促销id,促销信息是Hashes结构。

例如促销A,对应的类型为单品促销,我们暂且认为类型值为1,对应Redis中的key为C_A_1,数据结构内容类似于如下:

 
o: 100 // 原始数量
  b: 99 // 可抢购数量,假如抢购了一个剩下了99
  c: 1 // 抢购次数记录,用来限流,后面会介绍到

如何保证不超卖?

因为扣减资格是一组操作,我们利用EVAL操作Redis剩余数实现原子化操作,伪代码如下:

  
local key = KEYS[1]
  local tag = "b"
  local num = tonumber(ARGV[1]);
  local lastNum = redis.call('HINCRBY',key,tag,-num);
  if业务性判断ortonumber(lastNum) == 0then
  return lastNum
  end

如上代码会返回剩余数,如果小于等于0了,则没有库存了。

如何提高吞吐量?

减少网络交互(一次抢数据通过 EVALSHA 一次性提交给Redis集群);数据库操作异步化(使用JMQ异步记录日志)。

如何保证可用性?

采用JSF(京东内部SOA框架)对外开放服务(抢服务和发布促销服务),可降级为系统自身webservice服务;

抢购系统主要依赖于Redis集群,Redis采用一主三从集群方案,部署在两个机房,每个集群16个分片,每两分片共用一台物理机,可通过配置中心切换主从;

如果Redis挂掉了,如何恢复呢?通过汇总MySQL中的抢购和取消流水日志,并恢复Redis的抢购数量。

3、系统架构

这里主要涉及抢服务架构剖析,因为它具有典型的高并发特性,下面是基本架构概图:

     

注:此处的库存是可抢购数量设置,或者叫做资格/剩余数,并非真正的实际库存。

4、抢服务流程

Redis使用单个Lua解释器去运行所有脚本,并且Redis也保证脚本会以原子性(atomic)的方式执行:当某个脚本正在运行的时候,不会有其他脚本或Redis命令被执行。这种特性很好地解决了抢服务流程中并发带来的问题。

  

  

Redis+Lua抢购子流程:

此流程通过lua 脚本实现,我们暂时命名为q.lua(主要功能限流和扣减促销活动剩余数)。这样把抢购流程与脚本结合,一次性提交给Redis减少网络交互,使得性能大大提升。

  
q.lua伪代码:
  --[[
  --!@brief 促销Id下限流:可以防止某个促销过热导致服务不可以用
  --]]
  local function limited()
  -- todo: 实现
  end
  --[[
  --!@brief 限制逻辑(ip和pin):比如有的促销是限制ip,这里校验ip是否存在,如果为限ip类型抢购活动,
存在抛出异常告知ip已经存在不能抢购
  --]]
  local function check_ip_pin()
  -- todo: 实现
  end
  --[[
  --!@brief 记录订单号:主要目的实现抢方法幂等性,调用方网络超时可以重复调用,存在订单号直接返回抢购成功,不至于超卖
  --]]
  local function record_order_id()
  -- todo: 实现
  end
  --[[
  --!@brief 扣减剩余数
  --]]
  local function scalebuy()
  --
  local lastNum = redis.call('HINCRBY',key,tag,-num);
  --
  end
  -- 调用顺序不可调整
  -- 1 限流
  local status,msg = limited()
  if status == 0then
  return msg
  end
  -- 2 校验
  status,msg = check_ip_pin()
  if status == 0 then
  return msg
  end
  -- 3 记录订单
  status,msg = record_order_id()
  if status == 0 then
  return msg
  end
  -- 4 扣减剩余数
  status,msg = scalebuy()
  if status == 0 then
  return msg
  end
  -- 5 返回成功标示
  return 1

子流程具体如下:

1、解析请求参数,根据促销Id按照Jedis中MurmurHash算法获取分片,然后按照分片包装Pipeline批量发送请求参数argList;

2、获取系统初始化时 LOAD加载q.lua返回的串shaValue;

3、执行EVALSHA,伪代码如下:

 
// 其他操作
  Pipeline p;
  // 初始化p
  p.evalsha(shaValue,keyList, argList);
  // 其他操作

4、处理返回结果,只要有一个分片失败,本次抢购就失败。

补充:详细操作可以参考Jedis中ingCommandsTest。

JMQ发送子流程:

执行Redis+Lua抢购子流程成功仅仅代表着操作Redis成功,发送JMQ(京东MQ基础服务)成功(后端异步将实时库存更新到MySQL)才算一笔抢购成功,否则算抢购失败。这么设计的原因主要是保证抢购Redis和MySQL记录最终一致,发送失败需要回滚Redis+Lua抢购子流程(恢复Redis的库存和抢购资格)。当然要考虑降级,JMQ不可用时,直接切到JSF服务模拟JMQ,也就是直接写MySQL库,前提是限流次数调小,否则数据库有压力过大的风险。这样虽然用户体验下降了,但是服务依然可用。开关都在配置中心操作,一分钟内生效。

资格回滚子流程:

发送JMQ失败必须回滚,否则就出现了超卖现象,具体流程同Redis+Lua抢购子流程类似,是它的逆向流程,只不过运行脚本不同罢了。

限流处理

方法级限流,限流阈值通过配置中心配置,一分钟生效,伪代码如下:

 
private static AtomicInteger atomic = new AtomicInteger(0);
  public void test() {
  try {
  // 限流
  int limitNum = XXX.getLimitNum();
  int nowConcurrent = atomic.incrementAndGet();
  if(nowConcurrent > limitNum) {
  // 异常处理
  }
  // 正常业务逻辑
  } catch(Exception e) {
  // 异常处理
  } finally {
  atomic.decrementAndGet();
  }
  }

q.lua中促销级别的限流,主要利用C_A_1中c的抢次数和阈值比对。比如促销A,60秒内只能抢60000次,超过阈值60000该促销就会抢购失败。

到此抢购系统的核心逻辑就介绍完了,这里边还有一些细节问题需要大家在设计时思考,如限购(如每个人限购2个)、真实库存不足取消、用户取消订单归还资格、Redis挂了恢复数据、停促销(时间过期停、库存不足停)等等。

   
 订阅
  捐助
相关文章

阻碍使用企业架构的原因及克服方法
世界级企业架构的行业挑战
企业架构和SOA架构的角色将融合
什么最适合您的组织?
相关文档

企业架构与ITIL
企业架构框架
Zachman企业架构框架简介
企业架构让SOA落地
相关课程

企业架构设计
软件架构案例分析和最佳实践
嵌入式软件架构设计—高级实践
企业级SOA架构实践

 

相关文章


专家视角看IT与架构
软件架构设计
面向服务体系架构和业务组件
人人网移动开发架构
架构腐化之谜
谈平台即服务PaaS

相关培训课程


面向应用的架构设计实践
单元测试+重构+设计模式
软件架构师—高级实践
软件架构设计方法、案例与实践
嵌入式软件架构设计—高级实践
SOA体系结构实践

相关咨询服务
应用架构设计与构建

成功案例


锐安科技 软件架构设计方法
成都 嵌入式软件架构设计
上海汽车 嵌入式软件架构设计
北京 软件架构设计
上海 软件架构设计案例与实践
北京 架构设计方法案例与实践
深圳 架构设计方法案例与实践
嵌入式软件架构设计—高级实践
更多...   
 
 
实录 多租户架构数据库虚拟化
主讲:梁涛
Oracle研发中心,性能优化架构师
 
实录 模型驱动三维管理
 主讲:俎涛
火龙果软件工程创始人
 
 
 
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号