e-commerce - 亚马逊/苹果等电子商务如何在高峰时段维护实时聚合计数器？

像亚马逊和苹果这样的公司有几天他们的在线流量很大。对于苹果来说，可能是在新 iPhone 发布期间，而对于亚马逊来说，可能是在黑色星期五/网络星期一期间。处理服务器负载本身是一个需要高度扩展的问题，但是当有这么多人购买相同的东西时，这些公司如何管理库存？

汇总柜台可以是本身可用的库存，也可以只是这些电子商务平台向特定日期前 100 位购物客户提供的优惠券。

本质上，我想知道人们如何处理一个简单的场景：给前 10000 名成员提供他们可以在周末使用的独特优惠券。这种方法的第一个问题是实时识别前 100000 名成员，因为您想通知他们他们赢得了优惠券。我在这里看到的第二个挑战是只给一个成员一张特定的优惠券。

第一个似乎是维护原子计数器的问题。电子商务网站是否使用 ZooKeeper 之类的东西来实现这种计数器？

第二个似乎是分布式队列的问题，您必须将 10000 个客户中的每一个与您可用的 10000 张优惠券进行匹配。即使不需要 FCFS，您也需要在高流量环境中将特定优惠券实时分配给单个成员，您的前 10000 名客户可能在销售的前 1 分钟内完成交易。

大型电子商务平台是否实时解决了这些问题？他们是否会将这些决策以适当的时间延迟异步发生？

标签： e-commerceatomicdistributed-computing

在大范围内，您可以简化任何事情。

你必须发出正好N张优惠券吗？不可以。您可以轮询各个服务器，了解他们在本地数据库中发布了多少优惠券。当总和超过阈值时，您向他们发出停止信号。

至于优惠券代码，您不需要中央服务器来检查是否发布了任何特定代码。您可以将它们本地存储在节点上，甚至可以即时生成。使用优惠券不需要立即使用这一事实，因此您有时间在需要时将它们收集在一个地方。

如果您绝对需要发布确切的计数，则将优惠券存储在节点上并接受一个节点可以先于其他节点耗尽的事实，这将是几秒钟的差异。如果您不能接受，请使用服务器在节点快用完时将优惠券分批分配给节点。这样不平衡不会超过批量大小。

您可能会以指数级更高的价格将事情推得更远。

作为对大规模世界的介绍，请参阅 Google 工程师关于他们如何处理事情的免费书籍“站点可靠性工程”： https ://sre.google/books/