vivo官网商城开发团队 - Zhou Longjian

一、背景

随着O2O线上线下业务的不断扩展,电商平台也在逐步完善交易侧相关的产品功能。在最近的需求版本中,业务方为进一步提升用户的使用体验,规划了取货码生成及订单核销相关逻辑,目的是让线上的用户在付完款之后能够到店取货或者安排导购派送。

日常生活中,我们对取货码、核销这类功能使用的经历大部分都来自:看电影前取票、吃饭后出示券码、快递柜取包裹等等,它们都有一些类似的特点,比如:

  • 取货码长度相对较短,比起动辄十几二十位订单号,几位的数字码更方便记忆和输入;

  • 除了数字取货码,还提供二维码,方便终端进行扫描并核销。

取货码使用起很简单,然而像“冰山”一样,隐藏在简单外表下面却需要严谨的设计和细致的逻辑,可以说麻雀虽小五脏俱全。本文介绍的设计也比较有趣,而且按此思路可以实现市面上大多数核销类券码的生成,同时也能满足业务的SaaS化,算是一个相对通用的能力,在此把整个设计分享给大家。

(图片来源:pixabay.com

二、简单系统的单表业务

如果业务的体量不大,店铺流量比较小,未形成平台的规模,比如给个体经营者使用的系统。那么取货码或券码的实现就比较简单,跟订单共享一张大横表或者使用扩展表跟订单进行关联就行了,这个阶段也无需做过度设计。

表的设计如下图:

不过需要注意的是一般订单号都是比较长的,通常都在十几二十位(当然也有比较短的订单号,如果订单号比较短,取货码也可采用订单号)我们假设订单号18位,取货码8位,即订单号的取值范围远大于取货码,那么在订单号的生命周期内,取货码是有很大几率存在重复的。解决起来相对简单,我们只需要保证在任意条件下,未核销状态的数字码不重复即可,也即已核销的数字码可以回收利用。

那么取货码的生成逻辑就很清晰了,下面用伪代码模拟真实的实现逻辑:

伪代码实现

for (;;) {
step1 获取随机码:String code = this.getRandomCode();
step2 执行SQL:SELECT COUNT(1) FROM order_main WHERE code = ${code} AND write_off_status = 0;
step3 判断是否可以插入:if ( count > 0) { continue; }
step4 执行数据写入:UPDATE order_main SET code = ${code}, qr_code = ${qrCode}, write_off_status = 0 WHERE order_no = ${orderNo}
}

*注意:这里step2和step4不是原子操作,存在并发问题,实际应用中最好使用分布式锁,把操作锁住。

三、 复杂平台的分库分表业务

通过简单的单表设计,我们能管窥一斑,了解取货码大致的实现逻辑。不过我们在把简单方案往大型项目上进行落地的时候,就需要考虑很多方面,设计也需要更精巧。SaaS化的电商平台会比简单的单表业务复杂很多,重点体现在:

  1. SaaS 产品涉及的店铺很多且订单量大,需要设计大容量存储,所以订单表基本使用分库分表,显然作为订单附属的取货码表也得使用相同的策略;

  2. B端和C端用户的体验非常重要,服务端接口的设计需要充分考虑鲁棒性,完善最基本的重试及容错能力;

  3. 不同业务方对于取货码的要求可能不太一样,取货码的设计需要具有通用性以及个性化的配置属性。

3.1 详细设计

取货码表的设计推荐使用和订单一致的分库分表策略,好处是:

  1. 和订单一样,支撑海量订单行的存储;

  2. 方便利用同样的分库分表因子进行查询(例如:open_id、member_id)。

在考虑落地实现上,我们遇到了第一个讨论的点,那就是取货码是做到“门店唯一”还是“全局唯一”?

3.2 门店唯一方案

刚开始考虑使用类似饭馆取餐码类似的逻辑,保证取货码在各自门店保持唯一就行了。类似如下图交互,图中用户A和用户B持有相同的取货码,用户A、B分别去他们对应的店铺完成核销,整个交易过程就结束了。但是这得保证用户A和B能正确地在各自订单归属的店铺完成核销,显然这个方案是带有风险的!

下图所示的这种情况下,用户A、B也能正常核销,不过串单了,原本属于用户A的订单被用户B核销了。这种问题出现的本质原因在于纯粹的数字码无法带有用户的标识,虽然可以在核销前做人为的核验身份来避免,但依然属于高风险的系统设计,所以门店唯一方案不可取!

3.3 全局唯一方案

全局唯一方案风险小,但实现难度稍高一点。核心问题在于如何判定随机生成的取货码是全局唯一的,当然如果系统本身依赖ES这类存储介质,可以在插入前先查询ES,不过查询和写入ES对于实时性接口来说稍微有点重,没有直接查库表来得直接。假设某业务方分成了4个库4张表,总计16表,取货码的长度确定为8位,那如何在多库多表的Mysql中查询并保证全局唯一呢?遍历表的方式肯定不可取!

为解决上述的疑问,我们在设计的时候可以在取货码的编排上做点文章,如下步骤做具体详解:

步骤①: 可以将8位的取货码分成两个区域,“随机码区域”+“库表位置”,下图示例:

步骤②: 随机码区域暂不介绍,我们来看下2位库表如何映射到4库4表组成的16张表中。

这里也有两套方案:

【方案一】可以选择2位库表的首位作为库编号,末位作为表编号。好处是映射较为简单,但是容量不够大,如果分的库或表>9,扩展就会有点麻烦。如下图,我们把末尾“12”逻辑映射到了“1库的编号为2的表”;

【方案二】将4库4表二维结构转成一维,以0为初始值进行递增,(0库, 0表) → 00, (0库, 1表) → 01... , (3库, 3表) → 15。好处是容量变大了,最大支持99张表,不受库或表单一条件的限制,缺点就是映射逻辑写起来麻烦点,不过这不是问题。

取货码经过简单编排,我们完成了取货码的到库表的映射逻辑,解决了取货码存取的问题。其实仔细想想,关于全局唯一的问题其实也解决掉了,我们只要保证前6位随机码在单表里保证唯一即可,理论上支持单表在未核销状态下范围为:000000 ~ 999999条记录,容量是足够的。关键我们把多库多表的查询就简化成了只跑一个SQL,效率大大提升。

3.4 方案落地遇到的问题

既然本篇是介绍SaaS化的完整方案,在落地的时候或多或少会遇到一些问题,这边介绍三个实际遇到的典型问题,并给出一些解决方案:

【问题一】使用Math.random()生成的6位随机码和表里的重复了,如何处理?

【解决】其实重复的情况有两种:

  1. 可能是表里已经存在数字相同未核销的取货码;

  2. 另外一种情况就是别的事务在正在操作,正好有个分布式事务锁住了一样的数字码(概率很低,但是是有可能的)。

这两种情况的出现就需要我们进行优雅地重试了!大致思路如下伪代码:

// step1 根据分库分表因子获取库表编号,userCode-用户编号、tenantId-租户编号
String suffix = getCodeSuffix(userCode, tenantId); // step2 批量获取6位随机码
for (int i=1; i<=5; i++) {
// 批量获取随机数。每次重试,取2的指数级量进行过滤,相比暴力执行for循环,这种方式能减少和DB的交互
List<String> tempCodes = getRandomCodes(2 << i);
// 过滤掉分布式锁
filterDistributeLock(tempCodes);
// 过滤掉数据库存在的随机码
filterExistsCodes(tempCodes);
return tempCodes;
} // step3 处理随机码,随机码入库
for (String code : codes) {
// 加锁,判断加锁是否成功。推荐使用Redis分布式锁
boolean hasLockd = isLocked(code);
try {
// 执行入库
insert(object);
} finally {
// 解锁
}
} // step4 执行后置二维码图片等逻辑

【注意】

  1. 推荐使用指数级重试的方式(2 << i),逐次递增random的数量,减少和DB的交互;

  2. 建议数字码生成完毕后加锁并执行INSERT,生成图片地址等耗时严重的动作可以后置UPDATE上去。

【问题二】项目中使用了分库分表的组件(比如:ShardingSphere-JDBC),怎么动态修改数据源?也就是同时支持分库分表因子(比如:member_id、open_id等)以及根据取货码计算的库表动态查询。

【解决】我们以ShardingSphere-JDBC作为为案例来给出一些配置及伪代码,具体可以参考:《强制路由::ShardingSphere》,其他开源的分库分表组件或者自研产品不做赘述,可以自己手动写个插件,别怕,即使再难,也要相信有光!

配置及伪代码

// ShardingSphere-JDBC依赖的配置文件jdbc-sharding.yaml
...
shardingRule:
tables:
...
# 取货码表
order_code:
actualDataNodes: DS00$->{0..3}.order_pick_up_0$->{0..3}
# 配置库的计算逻辑
databaseStrategy:
hint:
algorithmClassName: com.xxx.xxxxx.xxx.service.impl.DbHintShardingAlgorithm
# 配偶之表的计算逻辑
tableStrategy:
hint:
algorithmClassName: com.xxx.xxxxx.xxx.service.impl.DbHintShardingAlgorithm
... // java代码
try (HintManager hintManager = HintManager.getInstance()) {
hintManager.addDatabaseShardingValue("order_code"/** 取货码表 */, DbHintShardingAlgorithm.calDbShardingValue(tenantId, code));
hintManager.addTableShardingValue("order_code"/** 取货码表 */, DbHintShardingAlgorithm.calTabShardingValue(tenantId, code)); Object xxx = xxxMapper.selectOne(queryDTO);
}

【注意】

  1. 这里介绍一种编程式的解决方案,好处是配置简单、比较灵活,缺点就是代码稍微多一点。其实ShardingSphere还支持注解的方式,可以自己研究下;

  2. 第一条说了比较灵活,体现在自己实现的 “DbHintShardingAlgorithm.calDbShardingValue(tenantId, code)” 方法上,这个方法可以自己定义,所以我们的入参可以是通用的分库分表因子,也可以是自定义的取货码的“库表位置”字段,非常灵活。

【问题三】如何做到更强的扩展性,适用SaaS平台以及不同的业务场景?

【解决】细心的小伙伴应该注意到了 "tenantId" 这个字段,这是个租户的编码,在实际编码会进行透传。我们可以利用这个字段针对不同的租户(或叫业务方)来做不同的配置,比如:取货码的长度、取货码编排的方式、取货码映射库表位置的策略等等做成可配,只要把主干逻辑进一步抽象,并使用策略模式进行个性化编码。

四、总结

实现取货码逻辑的时候,发现网上券码这块的方案、技术文章比较少,当时萌生了写篇文章抛砖引玉做个分享的想法。事实上,我相信大多数公司可能或多或少也是这么做的,哪怕采取了别的方案也能殊途同归。本篇文章整体只是介绍了一个思路,而这个思路类似一个简化版的订单分库分表,但这就是神奇所在,事实上我们还可以将一些常用的技术方案落地到不同的应用场景,大胆地做一些尝试,多走一些未曾设想过的道路!

主题系列文章:

vivo 全球商城:电商平台通用取货码设计的更多相关文章

  1. Java生鲜电商平台-优惠券系统的架构设计与源码解析

    Java生鲜电商平台-优惠券系统的架构设计与源码解析 电商后台:实例解读促销系统 电商后台系统包括商品管理系统.采购系统.仓储系统.订单系统.促销系统.维权系统.财务系统.会员系统.权限系统等,各系统 ...

  2. Java生鲜电商平台-促销系统的架构设计与源码解析

    Java生鲜电商平台-促销系统的架构设计与源码解析 说明:本文重点讲解现在流行的促销方案以及源码解析,让大家对促销,纳新有一个深入的了解与学习过程. 促销系统是电商系统另外一个比较大,也是比较复杂的系 ...

  3. 点菜网---Java开源生鲜电商平台-商品基础业务架构设计-商品分类(源码可下载)

    点菜网---Java开源生鲜电商平台-商品基础业务架构设计-商品分类 (源码可下载) 说明:我们搞过电商的人都可以体会到,搞生鲜电商是最复杂的,为什么复杂呢?我总结了有以下几个业务特性决定的: 1. ...

  4. Java生鲜电商平台-商品基础业务架构设计-商品设计

    Java生鲜电商平台-商品基础业务架构设计-商品设计 在生鲜电商的商品中心,在电子商务公司一般是后台管理商品的地方.在前端而言,是商家为了展示商品信息给用户的地方,它是承担了商品的数据,订单,营销活动 ...

  5. Java生鲜电商平台-会员积分系统的设计与架构

    Java生鲜电商平台-会员积分系统的设计与架构 说明:互联网平台积分体系主要用于激励和回馈用户在平台的消费行为和活动行为,一个良好的积分体系可以很好的提升用户的粘性及活跃度. 一.互联网平台积分体系设 ...

  6. Java生鲜电商平台-RBAC系统权限的设计与架构

    Java生鲜电商平台-RBAC系统权限的设计与架构 说明:根据上面的需求描述以及对需求的分析,我们得知通常的一个中小型系统对于权限系统所需实现的功能以及非功能性的需求,在下面我们将根据需求从技术角度上 ...

  7. Java开源生鲜电商平台-财务系统模块的设计与架构(源码可下载)

    Java开源生鲜电商平台-财务系统模块的设计与架构(源码可下载) 前言:任何一个平台也好,系统也好,挣钱养活团队这个是无可厚非的,那么对于一个生鲜B2B平台盈利模式( 查看:http://www.cn ...

  8. 点菜网---Java开源生鲜电商平台-技术选型(源码可下载)

    点菜网---Java开源生鲜电商平台-技术选型(源码可下载) 1.内容简介 点菜网目前选用的是最流行的微服务架构模式,采用前后端分离的开发模式,具备高可用,高负载,支持千万级别的数据量的请求. 2. ...

  9. Java生鲜电商平台-订单模块状态机架构设计

    Java生鲜电商平台-订单模块状态机架构设计 说明:在Java生鲜电商平台中订单的状态流转业务        我们知道 一个订单会有很多种状态:临时单.已下单.待支付.待收货.待评价.已完成,退货中等 ...

随机推荐

  1. Oracle 创建表空间及用户授权、dmp数据导入、表空间、用户删除

    1.创建表空间 // 创建表空间 物理位置为'C:\app\admin\oradata\NETHRA\NETHRA.DBF',初始大小100M,当空间不足时自动扩展步长为10M create tabl ...

  2. Calendar类介绍_获取对象的方式和Calendar类的常用成员方法

    java.util.Calendar类:日历类 Calendar类是一个抽象类,里边提供了很多操作日历字段的方法(YEAR.MONTH.DAY_OF_MONTH.HOUR ) Calendar类无法直 ...

  3. P1087 FBI树 [2004普及]

    这是个正常的.很简单的分治,然后我成功地将这个题搞成了一个贼难搞的东西 还是说一下我那个非常麻烦的思路: 1. 建树 2. 后序遍历 然后就在建树的过程中死循环了,然后还一堆毛病 看了一个AC代码,该 ...

  4. JAVA学习的第一周

    这是发表的第一篇博客,关于Java编程的学习体会如下 1.了解Java的产生与发展时机:1995左右出现Java语言,然后Java的最主要的特点是"跨平台".对于跨平台我不太理解, ...

  5. Educational Codeforces Round 132 (C,D) 题解 cf#1709

    昨晚打了这把EDU,赛后看了dalao们的C题代码豁然开朗恍然大悟 实在是太巧妙了 这场来说,D题的通过率比C题高太多了(估计很多人都在C题卡了然后没做D 先放题目链接 题目链接 C - Recove ...

  6. 【一本通提高博弈论】[ZJOI2009]取石子游戏

    [ZJOI2009]取石子游戏 题目描述 在研究过 Nim 游戏及各种变种之后,Orez 又发现了一种全新的取石子游戏,这个游戏是这样的: 有 n n n 堆石子,将这 n n n 堆石子摆成一排.游 ...

  7. 使用JAVA CompletableFuture实现流水线化的并行处理,深度实践总结

    大家好,又见面啦. 在项目开发中,后端服务对外提供API接口一般都会关注响应时长.但是某些情况下,由于业务规划逻辑的原因,我们的接口可能会是一个聚合信息处理类的处理逻辑,比如我们从多个不同的地方获取数 ...

  8. display: table-cell里面文字打点的方法

    <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8&quo ...

  9. python 操作xml、html文件

    简介 在一些项目中可能会使用到解析html文件,尤其是爬虫相关的,需要解析获取到的html内容,通常我们会使用lxml模块去进行html文件的解析. html文件 当前存在一个简单的html < ...

  10. Linux学习系列--用户(组)新增、查看和删除

    在实际的工作中,在接触Linux的用户组管理的时候,一般来说都是在系统开建设的时候设置好,root权限由特定的负责人保管用户密码,避免误操作带来不必要的麻烦. 在具体使用的时候,会利用相关的命令设置一 ...