Architecture 事件票务系统设计中的顺序和并发处理

假设一个事件票证网站要处理数量和并发性，票证分布在不同的服务器和数据库上

例如，在“服务器1”上，剩余10张票证，在“服务器2”上，剩余5张票证。如果同时“User1”（其请求被转发到server1）向book 12 tickets发送请求，“user2”（其请求被转发到server2）向book 3 tickets发送请求。“User3”（其请求被转发到server2）向Book2票据发送请求

虽然系统中有15张票可用，但服务器1会告诉用户1有12张票不可用，但用户2和用户3可以预订他们的票。这将对user1不公平

---

关于如何处理这种情况，您有什么想法吗？

您不能在每个服务器都有自己的票证计数的情况下执行此操作。您将需要一个每个服务器都可以访问的中央数据库来获取真相的来源，或者您将需要一个具有分布式锁定机制的分布式数据库（其核心是相同的，只是具有用于读取的分布式缓存）

---

我使用过基于ApacheZooKeeper和Redis的分布式锁管理器，但您可能应该自己研究，以找到适合您特定需求的锁管理器，但是，它们是一个很好的起点。

您能否进一步解释一下分布式锁定的核心是如何类似于用于读取的分布式缓存的？分布式数据库也有同样的问题，因为仍然存在一个单一的扩展点，这将限制您的吞吐量。你最好扩大你的中心真相来源，在这个集中化的数据库中更好地处理你的锁，而不是像票数一样分发原子的东西。我可以看到做一些有趣的事情，比如创建每个座位的锁，而不是锁票数，以便更好地分发它。你需要一些好的推测性锁定算法来找到客户想要的座位（例如所有的座位），但这绝对是可行的。我喜欢分配原子票数的想法。但是问题是否仍然会出现，因为当user1请求12张票证，而server1的票证计数为10，server2的票证计数为5时，server1不会拒绝请求吗。或者，如果请求的票证数大于其票证数，服务器1应询问其他服务器的票证数？