离线同步时会发生什么？影响离线收银系统成败的隐藏时刻
我们开发了Pultrack，这是一款为小型零售商构建的收银和库存应用，支持双币种离线优先操作，因此我们花费大量精力不仅在思考系统是否能离线工作，还在思考它重新连接那一刻会发生什么。第二个问题获得的关注远远不够。
为什么最近大家都在讨论离线优先架构？
关于收银系统的最近架构文章趋向一致的主题：连接应该被视为同步层，而不是依赖。本地存储、排队写入和网络恢复时的自动核对正在成为标准模式，而不再是高级功能。对于处于网络和电力间断市场中的店铺来说，这个转变很重要，因为一旦连接断开，销售不能简单地暂停。持续出现的区分是"离线可用"——一种降级的备用模式——和"离线优先"，其中本地设备是真实数据的主要来源，云端是次要的。 这不是学术问题。一个仅仅能容忍断开连接的收银机可能会在信号断开时阻止折扣、隐藏部分商品或拒绝打印收据。真正的离线优先设计使定价规则、库存数量和收据生成完全在本地运行，因此店主永远不会注意到好坏连接日期之间的差异。
连接恢复时实际上会发生什么？
这是供应商讨论较少的部分，也是决定离线优先是否真正在日常使用中有效的部分。当手机或终端在离线数小时或数天后重新连接时，它需要将本地事务队列与其他设备或云端在此期间发生的任何情况进行核对。设计良好的系统使用幂等应用编程接口，这样意外提交两次的销售不会被记录两次，并且它们对冲突情况应用解决规则，比如两名员工在任一设备看到对方的更新之前，都从两个不同的收银机上销售了同一商品的最后一个单位。 对于小店铺来说，这不是假设情景。考虑一个有一台连接无线网络的平板电脑和一部在断电期间用作备用收银机的手机的小卖部。如果两者都在离线时对同一库存商品进行销售，必然会出现超卖——唯一的问题是系统在同步过程中是否清楚地标记它，还是无声地用一笔销售的库存调整覆盖另一笔销售的调整。从构建这些系统的实际经验中，强调要优先处理某些操作（比如完成打印的收据）而不是其他操作，并设计同步队列使关键写入不会丢失或不正确地重新排序。
"离线优先"是否意味着店铺运行完全像在线一样？
原则上，是的——这就是承诺。当前产品文献中描述的离线模式应该足够完整以运行业务，而不是精简的应急模式：完整的商品目录访问、定价和折扣规则、收据打印和库存更新都应该在本地工作。实际上，该离线模式的完整性因供应商和"库存更新"在底层的实际含义而大不相同。 在假设系统真正独立运行之前，有几点值得询问：
- 离线模式是否支持完整的价格列表和折扣规则，还是仅支持缓存的子集？
- 它能否完全没有网络地打印有效收据，包括任何必需的税务字段？
- 两台在同一时间分别离线的设备的库存数量会发生什么？
- 当同步过程解决冲突时，是否有可见的日志或通知，还是以无声方式发生？
- 店主能否看到哪些销售"待同步"与确认，这样他们就知道他们的账目是临时性的？
为什么这对新兴市场特别重要？
在频繁断电的市场中，同步时刻发生的频率远高于网络连接稳定的市场。一个每天下午失去连接两小时的店铺不是每年一次遇到边界情况——它每天都在命中核对路径。这会提高正确处理冲突解决的风险，因为小错误会累积：每次同步后库存数量偏差一两个单位最终会导致货架与账目不匹配，这正是让店主停止信任软件并回到笔记本的那种差异。 诚实地说明证据基础也很重要：目前关于离线优先收银架构发布的大部分内容来自供应商博客、产品营销页面和个别工程师描述他们自己的构建，而不是独立研究或大规模研究。架构推理是合理的，模式——本地优先存储、后台同步、幂等写入——在来源中是一致的，但关于可靠性或"不可阻挡"的正常运行时间的声明应该被理解为供应商定位，而不是经过验证的结果。
店主在选择系统前实际上应该检查什么？
鉴于基础模式已经变得如此标准化——本地数据库优先、之后后台同步、关键任务的冲突解决（比如打印）——产品之间的区分更少是"它是否能离线工作"，更多是"它重新上线时表现得多优雅"。在Pultrack，这是我们视为核心而非装饰性的部分：双币种总额、库存水平和收据需要在设备之间和没有连接的日期之间干净地核对，店主应该能够用简明的术语看到哪些销售仍在待同步与完全确认。这是一个比"离线工作"更窄且更可检验的声明，我们认为它真正预测系统是否会在大多数下午断电的店铺中坚持。 如果你在评估任何离线优先收银系统——我们的或任何其他人的——要求查看故意断开连接的测试运行后的同步日志。一个能向你展示它如何解决冲突库存更新的供应商正在演示一些真实的东西。一个只能告诉你应用"不用互联网工作"的供应商还没有向你展示最重要的部分。