想象一下本地 Groupon 克隆。现在想象一个吸引了 10 倍正常访问者的交易，并且由于访问者试图在并行 MySQL 数据库中购买交易，因此超出了交易的最大购买限制。
我正在寻找高负载网站支付处理的最佳实践，它将并行处理有限数量的产品的支付。
目前，当客户尝试在第三方支付处理器的页面上购买时，最简单的选项似乎是锁定/解锁交易。
有什么想法吗？
问问题
816 次
3 回答
2
在您开始谈论第 3 方支付处理器页面之前，我一直与您同在。在将用户带到第三方网站时很难控制用户的体验，因为您不知道他们在那儿时在做什么，如果他们走偏了，他们需要多长时间才能完成交易，如果他们完成了交易，等等。
如果在本地处理付款不是一种选择，那不一定是问题 - 它只是提出了一个问题，即您必须如何实际考虑处理您的交易。
所以，如果是我，现在不考虑第三次聚会——我们先搁置一分钟。显然，我会 #1 确保我的 MySQL 数据库具有足够的弹性，不会出现故障，因为这会给协调事务带来巨大的问题。但是，事情发生了，所以你需要一个备份。
我的建议是使用一个缓存系统来跟踪产品，以及当前可用的产品数量。Memcache 可能对此有好处，因为它只是一条很容易抓取的记录。您根本不必访问数据库来获取有关您的产品（可用性）的信息，如果它出现故障，您的用户/应用程序将不再明智，因为您将直接从 Memcache 获取有关您的项目的信息（不需要mysql）。
这带来了存储支付记录的问题（当数据库出现故障时）。当您收款时，您显然需要数据库中的交易信息，如果您的数据库出现故障，那就是个问题。Memcache 并不是一个很好的解决方案，因为你受限于你的值的大小，你必须知道你关心的每一个键。最重要的是，Memcache 没有集合或集合操作，因此您不能附加到一个值而不必担心会破坏某些数据。
所以，让我们添加一个不同的技术，Redis。
事务问题的解决方案是在您的 MySQL 服务器不可用的情况下将它们写入 redis（或者如果您真的想写入两者，但您并不真的需要这样做）。然后有一个后台进程，它知道如何从 redis 获取事务详细信息，并在它重新联机时将它们写入您的 MySQL 表。Redis 对崩溃具有很强的弹性，并且能够大量运行。它还具有集合操作，因此您可以轻松地将数据附加到集合中，而不必担心在读/更改/写操作期间出现竞争条件。
因此，您可以将所有事务作为一个集合存储在一个 redis 键中（如果您愿意，可以将它们存储为 json 字符串，这很容易），然后当您的数据库崩溃时，您可以从 Redis 获取该数据并写入当它重新联机时，它会发送到 MySQL。
为简单起见，如果您打算使用 redis 存储事务，您也可以使用它来存储产品缓存，而不是 memcache - 保持堆栈简单。
这会注意不访问数据库以获取您的产品详细信息，并在 MySQL 崩溃时跟踪您（可能）错过的交易。但它不能处理在 MySQL 关闭时跟踪产品库存的问题，并确保您不会过度销售产品。
为了处理这种情况，当交易被保存时，您可以减少可用产品的数量（将其保留为固定数字，这样您就不会在页面加载时不断地重新计算它）。这将立即告诉您产品是否超卖。但是，这并不能保护“产品在购物车中”的时间。一旦用户将产品放入购物车（您允许这样做，因为您说您有库存），您就会遇到确保在他们结账之前它不会售罄的问题。
此问题的解决方案也可以作为您对 3rd 方交易问题的解决方案。因此，您正在为您的产品使用缓存机制，并为您的交易使用回退机制。您现在应该做的是，当用户尝试购买产品时（或者将其放入购物车，或者被送到第 3 方处理器）为他们创建一个“产品预订”。为这些中的每一个创建一个 redis 条目可能是最简单的。让产品预订有一个到期时间，比如 5 或 10 分钟，如果你愿意，甚至可以是 15 分钟。每次在您的网站上看到用户时，刷新超时以确保他们不会超时（显然，如果您愿意，可以在其中添加更多逻辑）。当交易完成并从待处理变为已付款时，您将创建交易记录（mysql 或 redis，
然后，除了未过期的预订信息外，您还可以使用可用数量信息来确定可供销售的数量。如果这个数字下降到零，那么您实际上已经售罄；但是，如果您的一定数量的用户没有转换它会释放他们没有购买的库存，让您可以冲洗并重复该过程，直到您实际上售罄。
这是一个相当健壮的系统的相当长的解释，如果你遇到了 MySQL 服务器崩溃和 redis 崩溃的情况，你会被搞砸的；因此，在这里对这两个系统进行故障转移是有意义的（这是完全可行和可能的）。它应该使结帐/库存管理过程非常可靠。
希望能帮助到你。
于 2012-05-22T13:22:18.020 回答
0
您是否考虑补偿服务交易？
于 2012-05-22T13:08:37.053 回答