在你开始谈论第三方付款处理器页面之前,我一直与你在一起,直到你开始谈论第三方付款处理器页面。很难控制用户的经验,同时将他们打到第三方网站,因为你根本不知道他们在进行交易时他们在做什么,如果他们被绕过轨道,他们要花多久才能完成交易,如果他们完成交易,等等。

如果在当地处理付款不是一个选项,那么这不一定是一个问题,它只是提出了一个问题,即你必须如何实际思考如何处理您的交易。

所以,如果是我的话,如果现在不考虑第三党的话,我们就先搁置一会儿。很显然,我会确保我的MySQL数据库具有足够的弹性,不会下降,因为这对调和交易造成了巨大的问题。但是,事情会发生,所以你需要一个备份。

我的建议是使用一个缓存系统来跟踪产品和现有产品当前##。 缓存系统可以对此有所帮助,因为它只是一份很容易抓取的记录。 你不必去数据库获取产品信息( 可用性), 如果交易失败, 您的用户/ 应用程序也不会更明智, 因为您直接从Memcache那里获得关于您项目的信息( 不需要 Mysql ) 。

这提出了存取支付记录的问题( 当数据库下降时 ) 。 当你收集资金时, 您显然需要数据库中的交易信息, 如果您的数据库被关闭了, 那么问题就大了。 Memcache 并不是解决该问题的好办法, 因为您限制在您价值的大小, 您必须知道您所关心的每一个密钥 。 此外, Memcache 没有设置或设置操作, 因此您可以不必害怕一些数据, 将交易信息附加到一个值上 。

所以,让我们添加一个不同的技术, Redis。

交易问题的解决方案是,在您的 MySQL 服务器不可用的情况下, 写入它们进行重写( 或者如果您真的想要, 则写给两者, 但您并不真的需要这样做 ) 。 然后有一个背景进程, 它将知道如何从 redis 获取交易细节, 并将细节写入您的 MySQL 表格 。 Redis 相当适应崩溃, 并且能够大量运行。 它还设置了操作, 这样您就可以在读/ 换/ 写操作中很容易地将数据附加到一组中, 而不必担心种族状况 。

所以,您可以将所有交易都存储在一个复立键中作为单一的组合( 存储为json字符串, 如果您喜欢的话, 很容易) 。 当您的 DB 撞车时, 您可以从 Redis 获得数据, 并在数据返回网络时将其写入 MySQL 。

为了保持简单,如果你打算使用再储存存储交易, 你也可以使用它来存储你的产品缓存, 而不是用Memcache来保持堆叠的简单。

这样可以避免您访问数据库中的产品细节, 并跟踪( 可能) MySQL 崩溃时您( 潜在) 丢失的交易 。 但是它不会处理在 MySQL 下降时新交易出现时跟踪产品库存的问题, 并且确保您不会过度销售产品 。

要处理此案例, 当交易被保存时, 您可以减少可用的产品 # # ( 保留一个固定的编号, 这样您就不会在页面加载时不断重新计算它 ) 。 这将立即告诉您产品是否超销 。 但是, 这并不能保护“ 产品在车内” 的时间 。 一旦用户将产品放进车内( 您之所以允许这样做, 是因为您有盘点), 您就很难在检查前确保产品不售出 。

这个问题的解决方案也加倍作为第三方交易问题的解决方案。 因此, 您正在使用产品缓存机制, 以及交易的后备机制。 您现在应该做的是, 当用户试图购买产品( 要么把它放在手推车上, 要么被击落到第三方处理器) 为他们创建了“ 产品保留 ” 。 对这些产品进行重新分解可能是最容易的。 产品保留有过期时间, 比如 5 或 10 分钟, 或者 15 分钟 。 每次您在网站上看到一个用户, 都会刷新时间, 以确保它们不会耗尽时间( 如果您想要的话, 您可以在此添加更多的逻辑 ) 。 当交易完成后, 您会创建您的交易记录( Myql 或 redis, 取决于数据库的可用性), 取消您可用的数量, 并删除您的保留记录 。

d 然后,除未过期的保留意见信息外,使用现有数量信息来确定可供销售的数量。如果这一数字降至零,那么你实际上就被卖掉了;但如果某部分用户不转换,它就会释放出他们没有购买的库存,允许你冲洗和重复这一过程,直到你变卖为止。

这是对一个相当强大的系统的相当长的诠释, 如果你遇到过一个您的 MySQL 服务器崩溃、 和再崩溃的情况, 你就会被搞砸; 因此在这里对这两个系统都发生故障是有道理的( 这是完全可行和可能的 ) 。 它应该让一个非常坚固的 校验/ 库存管理过程成为现实 。

希望能帮上忙

使用带有读/ write 连接的主奴隶 Mysql 配置 。

尽可能多地使用缓存 (redis 是好主意)。

尝试将一些逻辑输入 redis, 这样它不会增加与 Mysql 的连接 + 将会更快 。

对于交易,也许明智的做法是使用某种信息排队系统(rabbbitM/a>)。 它允许您将一些任务推进到背景中 。