共计 1719 个字符，预计需要花费 5 分钟才能阅读完成。
最近某披萨品牌与出名游戏的联动再次冲上热搜，只不过起因是许多用户在领取过程中遇到问题，呈现长时间无奈领取，反复领取等异常情况。本文想要从个别的秒杀及领取零碎的设计方面探讨一下故障呈现的可能起因，以及预防计划，最初聊一聊区块链在这方面的解决方案。因为作者并不理解本次故障具体的技术细节，所以文中可能蕴含大量的主观揣测，还请读者见谅。
流程复盘
流动开始当日上午 9 点，披萨 APP 上开启流动产品的预约，不久，产品就已售罄。同时，社交网络上开始呈现“披萨 APP 解体“的用户反馈。次要反馈的问题有：
- 订单曾经领取，然而显示领取未实现
- 一份订单领取胜利两次
- 订单无奈领取（提醒网络异样）
在大量用户反馈问题之后，披萨品牌示意会将订单的可领取工夫由半小时缩短到 24 小时。
问题剖析
本次流动的次要步骤能够合成为：1. 创立订单；2. 领取订单。
在创立订单这一步是没有呈现用户反馈问题的，只管同时抢购的用户数量很多，然而个别只须要正当地将用户进行分区，例如，假如产品限量 10 万份，能够创立 10 个并行的服务，每个服务上搁置事后生成的 1 万份产品编码，咱们这里用 token 来示意。而后应用哈希将用户分流到这 10 个服务上。每个服务就只须要保护 1 万 token 的汇合。
次要问题是在领取订单这一步，首先，只有取得 token 的用户才有资格进行领取。那么当服务器拿到用户发来的 token 的时候，须要做以下工作：1. 验证此 token 是否是实在的；2. 验证此 token 是否过期；3. 验证此 token 是否被应用过。
第一步是比较简单的，能够应用数字签名技术来验证，比方每个 token 都是有商家私钥签名的。第二步也很简略，token 内的工夫戳和以后的工夫比照一下，就晓得有没有过期。真正简单的是第三步，咱们方才提到了，总共有 10 万份产品，那么至多就有 10 万个 token，且它们始终在更新（每时每刻都有订单领取胜利，领取胜利，token 生效）。这意味着这一步是无奈并行的，一旦并行，就有可能呈现双花 ———— 一个 token 被应用两次。
这一步里极大的串行工作的沉积，有可能是导致服务解体的次要起因。
另外，有用户示意同一笔订单领取了两次，这是因为大多数用户应用的是第三方领取服务，在“领取胜利 ->token 生效“这个过程中，如果两头断开了，就可能导致领取两次。
解决方案
首先咱们探讨一下在业务层面的解决方案，能够采纳预付订金的机制，比方，在流动开始前的一周里，用户能够预付订金参加抽签，流动开始当日颁布抽签后果，未中签的用户主动退还订金。将领取的工作分散开来。
如果不想扭转业务逻辑，咱们还能够在 token 上做文章，比方，将全副 token 分为 n 组，并在 token 上标注分组编号；同时启用 n 个验证服务，每个服务只负责保护对应分组的 token 汇合，相当于把串行工作分为了 n 个并行任务。
区块链的利用
依据白皮书 “A Peer-to-Peer Electronic Cash System” 实现的区块链零碎实践上是能够有限扩容的，并且由其特有的工作量证实（POW）机制，可能超过分布式系统不可能三角（CAP），无效解决领取过程中的双花问题。
这里咱们尝试设计一个使用区块链零碎的解决方案。首先，商家发行 10 万个 token，每个 token 是一个 UTXO（未破费输入），其中蕴含的金额能够是 1 聪（区块链上最小的金额单位）。
另外，咱们须要第三方领取也反对这一区块链零碎，例如当初的数字人民币零碎。
在用户取得了 token，进行领取的时候，用户将发动一笔区块链交易，这笔交易的会耗费 token，并向商家领取对应的金额。当商家从区块链的“交易解决商”（俗称矿工）那里理解到这笔交易曾经有极大概率胜利 ———— 这个过程只实践上不到 1 秒钟，理论取决于区块链零碎中矿工的网络情况 ———— 就能够认为这个 token 曾经生效，且领取已胜利，这是一个原子操作。
如果交易不胜利，那么 token 不生效，且领取不会胜利。
结语
以上，是作者对某披萨品牌这次联动事变的简略剖析，和尝试提出的解决方案。咱们置信在现有的网络服务技术下，是有可能实现此类大型流动的。而在采纳一些新技术，例如区块链，则有机会大大降低硬件老本和操作难度。本文乃作者一家之言，如有谬误之处，请不吝赐教。
