草庐IT

vivo 全球商城：电商平台通用取货码设计

Zhou Longjian 2023-03-28 原文
作者｜vivo官网商城开发团队 - Zhou Longjian

一、背景

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

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

  • 取货码长度相对较短，比起动辄十几二十位订单号，几位的数字码更方便记忆和输入；
  • 除了数字取货码，还提供二维码，方便终端进行扫描并核销。
取货码使用起很简单，然而像“冰山”一样，隐藏在简单外表下面却需要严谨的设计和细致的逻辑，可以说麻雀虽小五脏俱全。本文介绍的设计也比较有趣，而且按此思路可以实现市面上大多数核销类券码的生成，同时也能满足业务的SaaS化，算是一个相对通用的能力，在此把整个设计分享给大家。

二、简单系统的单表业务

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

表的设计如下图：

不过需要注意的是一般订单号都是比较长的，通常都在十几二十位（当然也有比较短的订单号，如果订单号比较短，取货码也可采用订单号）我们假设订单号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全球strongdata-iddata移动开发移动应用$取货码电商平台

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

  1. ruby-on-rails - Rails - 子类化模型的设计模式是什么？ - 2

    我有一个模型:classItem项目有一个属性“商店”基于存储的值，我希望Item对象对特定方法具有不同的行为。Rails中是否有针对此的通用设计模式？如果方法中没有大的if-else语句，这是如何干净利落地完成的？ 最佳答案 通常通过Single-TableInheritance. 关于ruby-on-rails-Rails-子类化模型的设计模式是什么？，我们在StackOverflow上找到一个类似的问题： https://stackoverflow.co

  2. ruby-on-rails - 使用 rails 4 设计而不更新用户 - 2

    我将应用程序升级到Rails4，一切正常。我可以登录并转到我的编辑页面。也更新了观点。使用标准View时，用户会更新。但是当我添加例如字段:name时，它​​不会在表单中更新。使用devise3.1.1和gem'protected_attributes'我需要在设备或数据库上运行某种更新命令吗？我也搜索过这个地方，找到了许多不同的解决方案，但没有一个会更新我的用户字段。我没有添加任何自定义字段。 最佳答案 如果您想允许额外的参数，您可以在ApplicationController中使用beforefilter，因为Rails4将参数

  3. LC滤波器设计学习笔记（一）滤波电路入门 - 2

    目录前言滤波电路科普主要分类实际情况单位的概念常用评价参数函数型滤波器简单分析滤波电路构成低通滤波器RC低通滤波器RL低通滤波器高通滤波器RC高通滤波器RL高通滤波器部分摘自《LC滤波器设计与制作》，侵权删。前言最近需要学习放大电路和滤波电路，但是由于只在之前做音乐频谱分析仪的时候简单了解过一点点运放，所以也是相当从零开始学习了。滤波电路科普主要分类滤波器：主要是从不同频率的成分中提取出特定频率的信号。有源滤波器：由RC元件与运算放大器组成的滤波器。可滤除某一次或多次谐波，最普通易于采用的无源滤波器结构是将电感与电容串联，可对主要次谐波（3、5、7）构成低阻抗旁路。无源滤波器：无源滤波器，又称

  4. 计算机毕业设计ssm+vue基本微信小程序的小学生兴趣延时班预约小程序 - 2

    项目介绍随着我国经济迅速发展,人们对手机的需求越来越大,各种手机软件也都在被广泛应用,但是对于手机进行数据信息管理,对于手机的各种软件也是备受用户的喜爱小学生兴趣延时班预约小程序的设计与开发被用户普遍使用,为方便用户能够可以随时进行小学生兴趣延时班预约小程序的设计与开发的数据信息管理,特开发了小程序的设计与开发的管理系统。小学生兴趣延时班预约小程序的设计与开发的开发利用现有的成熟技术参考,以源代码为模板,分析功能调整与小学生兴趣延时班预约小程序的设计与开发的实际需求相结合,讨论了小学生兴趣延时班预约小程序的设计与开发的使用。开发环境开发说明：前端使用微信微信小程序开发工具：后端使用ssm：VU

  5. ruby-on-rails - 设计注册确认 - 2

    我在我的项目中有一个用户和一个管理员角色。我使用Devise创建了身份验证。在我的管理员角色中，我没有任何确认。在我的用户模型中，我有以下内容:devise:database_authenticatable,:confirmable,:recoverable,:rememberable,:trackable,:validatable,:timeoutable,:registerable#Setupaccessible(orprotected)attributesforyourmodelattr_accessible:email,:username,:prename,:surname,:

  6. ruby-on-rails - 设计通过 reset_password_token 获取用户 - 2

    我正在尝试创建密码规则来设计可恢复的密码更改。我通过passwords_controller.rb做了一个父类(superclass)，但我需要在应用规则之前检查用户角色，但我所拥有的只是reset_password_token。 最佳答案 假设您的模型是用户:User.with_reset_password_token(your_token_here)Source 关于ruby-on-rails-设计通过reset_password_token获取用户，我们在StackOverflow

  7. ruby-on-rails - Rails 5，公寓和设计 : sign in with subdomains are not working - 2

    我已经使用Apartment设置了一个Rails5应用程序(1.2.0)和Devise(4.2.0)。由于某些DDNS问题，应用只能在app.myapp.com下访问(请注意子域app)。myapp.com重定向到app.myapp.com。我的用例是每个注册该应用的用户(租户)都应该通过他们的子域(例如tenant.myapp.com)访问他们的特定数据。用户不应限定在其子域内。基本上应该可以从任何子域登录。重定向到租户的正确子域由ApplicationController处理。根据Devise标准，登录页面位于app.myapp.com/users/sign_in。这就是问题开始的

  8. ruby-on-rails - 设计中的 ArgumentError::RegistrationsController#new 错误的参数数量(2 代表 0..1) - 2

    我在关注RyanbatesRailsCast的devise和omniauth(第235集-devise-and-omniauth-revised)。当我尝试使用Twitter登录时，标题中不断出现错误。defself.new_with_session(params,session)ifsession["devise.user_attributes"]new(session["devise.user_attributes"],without_protection:true)do|user|user.attributes=paramsuser.valid?end完整跟踪:C:/Ruby20

  9. ruby-on-rails - 使用用户或管理员模型和 Basecamp 样式子域设计登录 - 2

    我为Devise用户和管理员提供了不同的模型。我也在使用Basecamp风格的子域。除了我需要能够以用户或管理员身份进行身份验证的一些Controller和操作外，一切都运行良好。目前我有authenticate_user!在我的application_controller.rb中设置，对于那些只有管理员才能访问的Controller和操作，我使用skip_before_filter跳过它。不幸的是，我不能简单地指定每个Controller的身份验证要求，因为我仍然需要一些Controller和操作才能被用户或管理员访问。我尝试了一些方法都无济于事。看来，如果我移动authentica

  10. ruby-on-rails - 自定义设计 Cookie - 2

    我在我的Rails应用程序中使用设计。我在租户庄园中配置了它，其中帐户/session的范围限定为子域。例如:http://subdomain1.example.com/http://subdomain2.example.com/...这很好用，但我想为“super管理员”添加一个子域，允许这些用户导航到所有其他子域而无需重新验证。这将是这样的:http://admin.example.com/是否可以自定义仅在管理子域上生成的cookie，以便它在所有其他子域上都有效？ 最佳答案 Cookie域的定义越不具体，它们的包容性就越大，

随机推荐