Amazon/Apple 等电子商务如何在高峰时段维护实时聚合计数器？
How do ecommerce like Amazon/Apple maintain real-time aggregate counters during peak times?
像亚马逊和苹果这样的公司有几天在线流量很大。对于 Apple，可能是在新的 iPhone 发布期间，而对于 Amazon，可能是在黑色 Friday/Cyber 星期一期间。处理服务器负载本身是一个需要高扩展性的问题，但是当有这么多人购买相同的东西时，这些公司如何管理库存？
汇总柜台本身可以是可用库存，也可以只是这些电子商务平台提供给在特定日期购物的前 100 位客户的优惠券。
基本上，我想知道人们如何处理一个简单的场景：为前 10000 名会员提供他们可以在周末使用的独特优惠券。这种方法的第一个问题是实时识别前 100000 名会员，因为您要通知他们他们赢得了优惠券。我在这里看到的第二个挑战是只给一个会员一张特定的优惠券。
第一个好像是维护原子计数器的问题。电子商务网站是否使用 ZooKeeper 之类的东西来实现这种计数器？
第二个似乎是分布式队列的问题，您必须将 10000 名客户中的每一个与您可用的 10000 张优惠券进行匹配。即使不需要 FCFS，您也需要在高流量环境中实时仅向单个会员分配特定的优惠券，在这种情况下，您的前 10000 名客户可能会在销售的前 1 分钟内完成交易。
大型电子商务平台是否实时解决这些问题，或者它们是否以适当的时间延迟将这些决策推迟到异步发生？
在大规模情况下，您可以尽可能地简化。
一定要刚好发N张优惠券吗？不可以。您可以轮询各个服务器，了解他们在本地数据库中发行了多少优惠券。当总和超过阈值时，您向他们发出停止信号。
至于优惠券代码，您不需要中央服务器来检查是否发布了任何特定代码。您可以将它们本地存储在节点上，甚至可以动态生成。利用不需要立即使用优惠券这一事实，因此您有时间在需要时将它们收集在一个地方。
如果你绝对需要发布准确的计数，你将优惠券存储在节点上并接受一个节点可以先于其他节点耗尽的事实，这将是秒差的问题。如果您不能接受，请使用一个服务器，在节点接近耗尽时将优惠券分批分配给节点。这样不平衡就不会超过batch size
您可能会以指数级更高的价格将事情推得更远。
作为对大规模世界的介绍，请参阅 Google 工程师的免费书籍“站点可靠性工程”，了解他们如何处理事情：
https://sre.google/books/
像亚马逊和苹果这样的公司有几天在线流量很大。对于 Apple，可能是在新的 iPhone 发布期间，而对于 Amazon，可能是在黑色 Friday/Cyber 星期一期间。处理服务器负载本身是一个需要高扩展性的问题，但是当有这么多人购买相同的东西时，这些公司如何管理库存？
汇总柜台本身可以是可用库存，也可以只是这些电子商务平台提供给在特定日期购物的前 100 位客户的优惠券。
基本上，我想知道人们如何处理一个简单的场景：为前 10000 名会员提供他们可以在周末使用的独特优惠券。这种方法的第一个问题是实时识别前 100000 名会员，因为您要通知他们他们赢得了优惠券。我在这里看到的第二个挑战是只给一个会员一张特定的优惠券。
第一个好像是维护原子计数器的问题。电子商务网站是否使用 ZooKeeper 之类的东西来实现这种计数器？
第二个似乎是分布式队列的问题，您必须将 10000 名客户中的每一个与您可用的 10000 张优惠券进行匹配。即使不需要 FCFS，您也需要在高流量环境中实时仅向单个会员分配特定的优惠券，在这种情况下，您的前 10000 名客户可能会在销售的前 1 分钟内完成交易。
大型电子商务平台是否实时解决这些问题，或者它们是否以适当的时间延迟将这些决策推迟到异步发生？
在大规模情况下，您可以尽可能地简化。
一定要刚好发N张优惠券吗？不可以。您可以轮询各个服务器，了解他们在本地数据库中发行了多少优惠券。当总和超过阈值时，您向他们发出停止信号。
至于优惠券代码，您不需要中央服务器来检查是否发布了任何特定代码。您可以将它们本地存储在节点上，甚至可以动态生成。利用不需要立即使用优惠券这一事实，因此您有时间在需要时将它们收集在一个地方。
如果你绝对需要发布准确的计数，你将优惠券存储在节点上并接受一个节点可以先于其他节点耗尽的事实，这将是秒差的问题。如果您不能接受，请使用一个服务器，在节点接近耗尽时将优惠券分批分配给节点。这样不平衡就不会超过batch size
您可能会以指数级更高的价格将事情推得更远。
作为对大规模世界的介绍，请参阅 Google 工程师的免费书籍“站点可靠性工程”，了解他们如何处理事情： https://sre.google/books/