写点什么

有赞零售移动端收银商品实践

  • 2019-07-08
  • 本文字数:5733 字

    阅读完需:约 19 分钟

有赞零售移动端收银商品实践

面对线下收银场景,针对商品收银业务,如何提升商家收银的效率?如何保证即使在弱网或无网条件下商家正常的收银?如何设计大量商品时搜索方案?如何对业务模块进行解耦和各种复杂的业务场景交互?都是在设计零售收银业务时,需要去认真思考的问题。


有赞零售移动团队在业务快速地迭代中,沉淀出商品收银的一套可行方案。


  • 模块化设计

  • 得益于零售移动的组件化框架,对业务线划分为店铺、交易、商品、营销等模块

  • 路由负责页面跳转与组件间通信

  • 私有化商品模块数据,商品模块提供查询接口

  • 离线商品数据

  • 客户端本地存储商品商品,即使在无网时,商家仍可正常收银

  • 提供商品名拼音搜索、扫码枪的商品条码扫码能力

  • 商品收银与营销活动

  • 支持门店商品收银时营销活动的数据组装

  • 支持不同营销活动时门店商品页面数据渲染

  • 硬件支持

  • 扫码枪、电子秤等多种硬件设备支持,提升商品搜索与收银效率

一、模块化设计

最初的零售移动多业务线共用本地数据库,调用时业务方式直接访问数据库 DAO 类查询数据,虽然使用上来说各个业务 Module 无须重新定义 DAO 数据类,但是业务之间耦合反而加重,违背了业务组件化的初衷。因此决定对数据库进行拆库:


  1. 按照业务线将数据库进行拆库

  2. 业务 Module 统一数据访问的入口

  3. 路由调用方法



上图是商品模块进行数据库拆分之后的基本模型。拆分之后:


  1. 单个数据库职责更单一,清晰明了,耦合降低

  2. 商品模块统一各个业务线访问商品数据的入口。

  3. 商品业务或底层数据变更时,其他业务线无须关心数据模型变更

  4. 各个业务组件之间数据通过 JSON 或商定好的协议进行数据传递


模块化设计把与业务强耦合的数据封装到业务模块内,调用方无须关心具体的业务细节;同时业务有变更或重构时,只要能够保证接口新旧一致性,上层业务方做到无感知,业务变更影响面减少,代码便于维护,一举两得。


业务模块化解决了业务模块间的耦合问题,那么如何设计商品离线数据同步机制?先思考一个问题:为什么要做商品离线同步?答案很显然:


  1. 线下门店与线上网店不同,在弱网或无网条件时,仍需要保证商品收银可用。

  2. 本地商品搜索效率上来说要比只依赖与网络接口请求要高效很多

  3. 门店收银要涉及到对接硬件的场景,在这些场景下,离线数据也有天然的优势


那么回到问题上如何设计商品离线数据的同步机制?应该至少考虑以下几个要求:


  1. 保证尽可能少的数据传输量

  2. 同步任务启动时机:网络重连后要进行数据同步等

  3. 同步任务尽可能地简单高效,便于维护

  4. 服务端数据变更后能够实时同步到客户端

  5. 同步数据的一致性与稳定性

二、离线商品同步设计

2.1 全量同步还是增量同步?

从设计复杂角度来说,全量同步是最容易实现的,数据的一致性容易保证。然而随着数据量的增加,每次全量同步消耗的资源和同步时间会越来越多,而且服务端数据变更后都要进行一次全量更新。与增量同步相比缺点比较明显。


相比于全量数据同步,增量同步只在初始时批量拉取服务端的商品数据。在本地已有商品时,通过本地最新的同步时间拉取商品,在数据传输量亦比全量同步更少,降低同步时间与流量消耗。


在选型上零售移动采用后者作为商品离线数据方案,通过同步时间来进行增量更新拉取最新的门店商品数据。


同步任务采用 单任务方式(即同步时只有一个同步任务在执行)减少多线程带来的并发问题维护成本,数据的一致性得到保证。


基本的同步过程:


  1. 移动端读取本地最新同步时间,根据时间请求服务端

  2. 服务端下发增量数据

  3. 客户端对比本地时间和增量数据的时间,判断是否已拉取最新数据

  4. 如果本地已是最新数据,停止同步;否则继续增量拉取数据,重复步骤 1


忽略掉各种边界条件和异常状况,一个简化的增量拉取流程可以抽象为下图:



对于商品数据新增和更新,上面的同步能够保证,那么数据的删除操作呢?


零售商品数据对删除操作只做逻辑删除,这样删除操作也可以归为数据更新。从而解决商品删除操作的问题。


商品数据同步任务确定后,需要考虑同步任务的触发时机。

2.2 同步任务触发时机

未接入长连接消息前,采用客户端主动触发同步任务:


  1. APP 在用户登录后

  2. 断网重连后

  3. 用户在商品页,手动触发同步


基本上满足那些商品数据基本不怎么变更的商家,但不能符合大多数的商家的使用场景。如:在 PC 后台创建一个门店商品或更改门店商品价格,移动端需要保证本地的商品数据实时更新,才是一个比较合理的设计。

2.3 长连接同步

长连接,这里所说的是 TCP 协议经过三次握手建立的连接。IM(即时通讯)的实现方案亦是维护 Socket 长连接作为消息通道,进行收发消息。


IM 消息接收流程


  • 发送方发送消息,经过服务器转发;

  • 对于在线的接收方,选择推送消息;

  • 在线推送失败或离线接收方,消息持久化到离线库;

  • 当接收方重新连接时,主动拉取去离线消息;


IM 形式的长连接方式,消息数据通过推送发送给接收方,接收方解析消息数据,本地做持久化存储。需要考虑消息去重、消息丢失等多种复杂的场景处理。


从业务方角度来说,实现和维护 IM 的功能成本较大。零售业务线对接有赞 IM SDK 收发消息。商品数据的同步采用 轻消息的方式来保证数据变更的实时性。


所谓 轻消息,消息不包含具体的业务线数据,仅有业务线类型。移动端解析业务线类型数据,判断数据变更类型如:商品更新、商品删除、商品创建等,触发数据同步任务。


一个简化的商品长连接同步时序图:



个端(APP/前端)在对商品操作后,商品后端发送商品变更的消息给消息中心,消息中心推送商品变更消息,移动端接收到消息解析,同步商品数据。


好处


  • 商品数据变更实时性能够保证

  • 业务线只关心消息类型,无须处理复杂消息长连接的问题

  • 商品数据持久化一致性能够得到保证


不足


  • 实时性依赖消息长连接的稳定性


场景增量同步+长连接推送满足零售商品离线数据满足线下商品收银,基本需求能够得到保证。但面对千上万的商品数据如何提升商家的收银效率呢?因此商品搜索场景必不可少。

三、门店商品搜索

考虑线下门店商品数量,需要设计可行的搜索方案。方案需要考虑的问题:


  1. 门店商品的模糊搜索。在商品页面可以根据商品的拼音全拼或首字母模糊匹配商品数据

  2. 门店使用扫码枪设备时,支持商品扫码的精确匹配


由于要对接扫码枪,而扫码枪属于特殊的硬件键盘,而在 APP 页面存在输入框在获取焦点时,会拦截掉扫码枪的输入事件。所以:


  • 在页面设计时,对于输入框使用 TextView(Android)替换。

  • 自定义支持英文字母和特殊符号的软件盘


在设计层面规避输入框的存在造成扫码枪事件被拦截的问题。但也导致无法使用系统软键盘或中文输入法,只能够使用商品名的拼音进行模糊搜索。


增量下发的门店商品没有拼音字段,要求移动端在持久数据时,对商品的中文转换为对应的拼音。

3.1 商品名中文转拼音

对于中文转拼音,App 层都现成的转换方案,Android 端有 Pinyin4J 库,iOS 端系统提供了汉字转拼音的 API。但都有大大小小的问题:


  • iOS 与 Android 的转换的拼音不一致,如 :Android 转换为 nv;iOS 转为 nu

  • 不支持多音字,两端均是取字库中的默认音


一个理想的拼音库应该满足以下条件:


  1. 多端结果一致

  2. 转换速度快

  3. 内存占用低

  4. 转换结果长度可控

  5. 字库、词库可动态下发

3.1.1 基于 JS 引擎的汉字转拼音方案

在跨平台技术选型上,零售移动选择 JS 引擎解决两端数据一致性问题。JS 引擎能够解析执行 JS 脚本,帮助移动端进行跨平台开发。业界流行的移动端跨平台方案如 Facebook 的 ReactNative、阿里的 Weex 均是依赖 V8(Android)与 JSCore(iOS)的 JS 引擎实现的跨平台前端动态方案。iOS 曾流行的 JSPatch 补丁库,亦归功于 JSCore 的优秀的动态化。


在执行速度上,V8 引擎将 JS 代码变为机器码并进行优化,加快执行速度。对于垃圾回收,V8 使用一种传统的分代式标记清除的方式去清除老生代的数据。


一个简化的汉字转拼音的流程:



流程中遍历商品名称,根据字在汉字拼音表中对应的拼音数量,判断是否为多音字。如果是多音字则查找字在多音字词语中的精准读音。

3.1.2 汉字拼音表

汉字与拼音的对应关系表。如果是多音字,则对应多个拼音。如:


dict[0x96f6] = "ling"; /* 零 */
dict[0x91cd] = "zhong,chong"; /* 重 */
复制代码


对于声调不同的多音字,如 shànshān两种声调,汉字拼音表只维护一个无声调的拼音 shan


dict[0x6247] = "shan"; /* 扇 */
复制代码


因为拼音搜索时,不区分声调不同导致的多音字。

3.1.3 多音字词表

常见的多音词表格式


"阿Q": [["ā"], ["Q"]],
"阿爸": [["ā"], ["bà"]],
"阿鼻": [["ā"], ["bí"]],
...
复制代码


使用上面格式的多音词表来判断多音字的正确读音时,要遍历整张多音字表,汉字常用有 4 万+多音字词,遍历效果并不理想。因此需要对原有的多音字词表进行改造优化。

3.1.4 改造后的多音字词表

...
dict[0x62d7] = ["拗断,ao,0","拗口,ao,0","违拗,ao,1","执拗,niu,1","拗不过,niu,0",
"拗口令,ao,0","强嘴拗舌,niu,2","三不拗六,niu,2","四不拗六,niu,2"];
...
复制代码


多音字在不同词语或邻词中的读音关系映射。如 "拗断,ao,0"表示 拗断中的正确读音为 ao在分词中的索引位置为 0


在确定多音字的读音时,只要找到多音字词表中该多音字对应的多音字读音即可。

3.1.5 多音字拼音的判断流程


现实生活瞬息万变,一个字的读音亦可能会发生变更,尤其是在互联网。多音字词表不能保证维护多音字的全部读音。在汉字的不同语境又是强上下文关联,也不能保证多音字拼音转换的准确性。


针对这种情况,多音字的拼音转换考虑笛卡尔积的形式生成拼音。如 重庆的咖喱牛肉,假定多音字词表未收录 重庆对应的拼音,根据 在汉字拼音表的中的多个读音进行拼装。


chongqingdegaliniurou|zhongqingdegaliniurou|..
复制代码


笛卡尔积的方式解决了多音字词表未匹配的问题。但是相应的增加了最终生成的多音字拼音的长度,对搜索速度会有影响。所以限制生成的拼音字符的最大长度的阈值。在使用笛卡尔积形式时判断生成的字符串是否超过指定的长度阈值,若有超过阈值的问题,则多音使用汉字拼音表中默认的拼音。

3.1.6 商品名拼音首字母

搜索除了拼音全拼,拼音首字母也是很常见的场景。不过有了全拼的解决方案后,拼音首字母相对来简单很多,只须在获取获取汉字拼音时,取到拼音的首字母后组合即可。


解决了商品名中文转拼音问题后,就可以愉快地进行搜索本地商品啦。

3.2 商品模糊搜索

应用场景:收银也拼音模糊匹配,搜索商品


商品搜索逻辑相对比较简单:搜索时模糊匹配商品的拼音或条码。输入内容时,调用商品模块提供的搜索接口,匹配本地商品的拼音中含有指定文本的门店商品。可以方便快速查找商品,节省时间。



简单的 SQL 搜索语句


SELECT title, price, code, pinyin, pinyinletter
FROM goods
WHERE pinyin LIKE '%xx%'
OR pinyinletter LIKE '%xx%'
OR code LIKE '%xx%'
AND shopid = '店铺id'
ORDER BY 'sortName'
OFFSET 'pageNo'
LIMIT 'pageSize'
复制代码

3.3.1 扫码枪的场景

收银员在收银界面,使用扫码枪扫描商品条码或条码秤的 PLU码,通过条码查找到商品,添加到购物车。


商品条码由一组规则排列的条、空及其对应代码组成,表示商品代码的条码符号。


与商品模糊搜索场景不同,条码可以确定唯一商品,所以扫码枪的场景为


  • 扫码枪精确匹配对应条码的商品

  • 相同商品不同厂商会多个条码(一品多码)


设计上采用商品搜索表满足扫码枪的快速搜索与 一品多码的业务需求

3.3.2 商品搜索表设计

  1. 条码与商品 ID 映射

  2. 以条码字段创建索引


扫码枪的商品搜索流程:


3.3.3 商品未同步时的补偿机制

因为扫码枪搜索的是本地商品数据,在门店初次启动零售 APP,使用扫码枪扫码时商品可能尚未同步到本地,影响门店的收银效率。


所以在扫码枪的使用场景,需要加上商品搜索的补偿机制:在扫码枪未在本地搜索到对应条码的商品,则调用后端接口获取商品信息。考虑到网络不稳定,对接口调用做 2 秒的超时限制,超过 2 秒则取消请求,并给出提示文案。



在无网时,本地若未搜索到则直接给出 未搜索到指定商品的提示。

四、收银与营销活动

4.1 商品、收银、营销

零售商品属于基础业务,要为收银、营销等业务提供数据。若抛开其他业务线,只谈商品是没有任何价值的。


最初有赞零售业务线尚未成形,营销活动与商品、收银互相耦合。随着营销业务增长,业务耦合的现状不能够满足的业务迭代与维护,因此进行了业务重构


  • 划分商品、收银、营销活动业务为三个模块

  • 离线数据库按照业务线进行划分并封装到业务模块内部

  • 数据模型依赖关系解除

  • 业务模块之间通信通过路由方法调用


一个解耦后的商品、收银、营销的业务模型



营销 -> 商品


营销唤起商品页面时,传入营销活动。商品页解析营销参数,调用营销模块远程接口,获取页面渲染数据与交互样式。


商品 -> 收银


在商品页选中商品后,判断是否有营销活动数据。若有营销相关信息,传回商品数据模型给营销页面。营销在商品模型基础上,添加营销详细数据,传给收银模块(购物车)。


收银 -> 营销


收银模块收到添加商品的请求,无营销数据则解析商品数据,组成为购物车数据模型。若有营销活动信息则通过营销数据请求营销接口,计算详细的营销信息,组装购物车数据模型。

4.2 营销活动组合门店商品

门店的营销活动与门店商品业务解耦,商品模块需要给营销活动模块提供门店商品查询的能力,营销活动模块组合门店商品与营销信息展示。


营销模块组装商品流程



营销活动请求指定门店商品信息时,可能会存在门店商品尚未离线到本地。如果门店商品未拉取到本地,则请求服务器对应的门店商品数据,存储到本地后返回给统一返回给营销模块。

4.3 门店商品渲染营销 UI

在营销活动模块,启动商品模块的商品规格选择页面时。规格选择页通过不同的活动类型来渲染展示。



请求:商品信息、营销活动信息


{
"pain_type" : "活动类型",
"activity_value" : "活动信息json",
"goods_value": {
"price": 0,
"property_price": 1,
"amount": 0,
"unit": "件",
...
}
}
复制代码


返回:营销渲染数据


{
"sku_price" : "¥12.00",
"total_price" : "¥12.00",
"available_skus" : [12980,12121],
"limited_amount" : 0,
"info_content" : ""
`}`
复制代码


五、展望

零售移动商品商品只是零售商品业务的部分,对于移动来说收银又是非常重要的一环。作为基础模块,经历两年的业务与技术沉淀,已基本覆盖线下门店商品管理、收银场景。后续重点在快速业务迭代同时,保证核心功能稳定;探索如何提升商家经营效率;完善商品的日志,问题快速响应。


本文转载自公众号有赞 coder(ID:youzan_coder)


原文链接


https://mp.weixin.qq.com/s/KUIoCuc5NsvlVe31cXvazw


2019-07-08 08:003530

评论

发布
暂无评论
发现更多内容

utf8mb4 默认排序规则引起的索引失效

TiDB 社区干货传送门

应用适配 数据库连接

GPT被封锁了怎么办?轻松获取高质量的数据,训练自己的人工智能和大语言模型。

热爱编程的小白白

API Token 是什么?深入介绍与实践指南

Apifox

程序员 安全 Token API

FinClip 强势登陆 AWS Marketplace,全球扩展战略迈出关键一步

FinClip

基于LangChain手工测试用例生成工具

测吧(北京)科技有限公司

测试

2024 TDengine 用户大会:顶尖专家带你决胜 AI 新时代

TDengine

初识langchain:LLM大模型+Langchain实战[qwen2.1、GLM-4]+Prompt工程

汀丶人工智能

AI大模型

铜线工厂生产管理MES系统解决方案

万界星空科技

mes 万界星空科技 铜线mes 生产管理软件 铜线工厂

解读「快意」大模型关键技术,揭秘实践中的挑战与创新

快手技术

NLP 大模型 #大模型

Pgsql 全量+增量迁移 tidb7.5

TiDB 社区干货传送门

7.x 实践

FlagEval 7月榜丨新增29个模型评测结果,智源发布评估技术报告《AI大模型能力全景扫描》

智源研究院

人工智能与情感分析:理解情感,驱动未来

天津汇柏科技有限公司

情感分析 人工智能’

基于 Three.js 的 3D 模型加载优化

vivo互联网技术

rust webassembly 3D模型 three.js web3d

AI心灵伙伴:数业智能心大陆如何提升年轻成人的心理健康?

心大陆多智能体

压力 智能体 AI大模型 心理健康 数字心理

Loopback for Mac:打造专业音频环境,一键开启高效录音之旅!

Rose

江苏企业采购堡垒机推荐哪家?为什么?

行云管家

堡垒机 过等保 江苏

Autodesk AutoCAD 2021中文版详细图文安装教程 mac/win

Rose

什么?for循环也会出问题?

阿里技术

for循环 故障排查

降成本,提人效:火山引擎VeDI实验平台架构升级

字节跳动数据平台

大数据 A/B 测试 数字化增长

玳数科技集成 Flink CDC 3.0 的实践

Apache Flink

大数据 flink Flink CDC chunjun

TiDB实践—索引加速+分布式执行框架创建索引提升70+倍

TiDB 社区干货传送门

7.x 实践

【第七在线】智能推算辅助选品组货 驱动零售品牌业绩增长

第七在线

国内大模型LLM选择以及主流大模型快速使用教程[GLM4/Qwen/Baichuan/Coze/Kimi]

汀丶人工智能

AI大模型

tidb7.5.1压测

TiDB 社区干货传送门

性能测评 7.x 实践

过等保时候常提到的堡垒机是什么?有什么用?

行云管家

等保 堡垒机 等级保护 过等保

降低大模型推理87%时延!华为云论文入选顶会USENIX ATC'24

华为云开发者联盟

人工智能 存储 华为云开发者联盟 LLM 企业号2024年7月PK榜

基于LangChain手工测试用例生成工具

测试人

软件测试

tidb源码研究分析日常碰到的bug

TiDB 社区干货传送门

TiDB 源码解读 6.x 实践 TiKV 源码解读

星辰考古:TiDB v4.0 进化前夜

TiDB 社区干货传送门

版本升级 版本测评 新版本/特性解读

基于YMP工具实现Oracle迁移YashanDB

YashanDB

yashandb 崖山数据库 崖山DB

CVPR2024论文解读|对齐人类审美!MPS让图像生成评估更“懂你”

快手技术

开源 #大模型

有赞零售移动端收银商品实践_移动_Alex、Siam_InfoQ精选文章