我应该使用排队系统来处理付款吗? [英] Should I Use A Queueing System To Handle Payments?
问题描述
我将 Slim 与 Stripe 的 PHP 库 来处理我的应用程序中的付款.
I'm using Slim in conjunction with Stripe's PHP Library to process payments in my application.
一切都很好，但是直到最近，我发现我的系统中出现了一个令人震惊的错误，我认为这可能是一个比我想象的要大得多的问题.在我的逻辑中，在付款过程的三个独立检查点，我检查我的 (MySQL) 数据库中的库存，以确保用户购买的产品不会超过可用产品.
All is well, however up until recently, I have discovered an alarming fault in my system that I believe may be a much larger issue than I probably think. In my logic, at three separate checkpoints of the payment process I inspect the inventory in my (MySQL) database to ensure a user isn't purchasing more products than is available.
但是，当多个用户在彼此大约 500 毫秒内发出请求时，支付系统似乎会同时处理这些请求，从而导致一系列问题，包括库存不正确和不平衡，以虚假的用户确认成功付款.
However, when multiple users make a request within approximately 500ms of each other, the payment system seems to process these requests all at once, resulting in a slew of issues ranging from incorrect and unbalanced inventory, to false user confirmation of successful payments.
通过一些尽职调查，我将解决方案缩小到两个选项(尽管我可能会卖空自己):
Through some due diligence, I have narrowed a solution down to two options (although I may be selling myself short):
1) 使用 排队系统 根据我的理解，它将对这些请求进行排队并一次处理一个，从而形成一种先到先得的基础.
1) Use a Queueing System that, from my understanding, will queue these request and process them one at a time, creating a sort've first-come, first-serve basis.
2) 将一些中间件附加到每个请求上，这些中间件将充当队列并尝试同步处理每个请求(尽管这可能与我已有的类似)
2) Attach some middleware on to each request that will act as a queue and attempt to process each request synchronously (although this may be similar to what i already have in place)
话虽如此，对这些选项有什么建议/意见吗?显然可以完全放弃我的想法并为我指明不同的方向.
Now with that said, any suggestions/opinions on these options? and obviously feel free to totally scrap my idealogy and point me in a different direction.
推荐答案
使用 TRANSACTIONS 对此会有好处，因为您似乎遇到了所谓的竞争条件.
Using TRANSACTIONS would be beneficial for this, since it appears that you've been faced with what is called a race condition.
来自 https://www.w3resource.com/mysql/mysql-transaction.php 和我引用:
事务是包含一个或多个 SQL 语句的逻辑工作单元.事务是可以提交或回滚的原子工作单元.当一个事务对数据库进行多次更改时，要么在提交事务时所有更改都成功，要么在回滚事务时撤消所有更改.
A transaction is a logical unit of work that contains one or more SQL statements. Transactions are atomic units of work that can be committed or rolled back. When a transaction makes multiple changes to the database, either all the changes succeed when the transaction is committed, or all the changes are undone when the transaction is rolled back.
一个事务从第一个可执行的 SQL 语句开始.事务在提交或回滚时结束，可以使用 COMMIT 或 ROLLBACK 语句显式执行，也可以在使用 DDL(数据定义语言 (DDL) 管理表和索引结构以及 CREATE、ALTER、RENAME、DROP 和 TRUNCATE 语句)时隐式结束仅列举几个数据定义元素)声明发布.
A transaction begins with the first executable SQL statement. A transaction ends when it is committed or rolled back, either explicitly with a COMMIT or ROLLBACK statement or implicitly when a DDL (Data Definition Language (DDL) is used to manage table and index structure and CREATE, ALTER, RENAME, DROP and TRUNCATE statements are to name a few data definition elements) statement is issued.
在事务期间锁定表将有助于防止竞争条件.
LOCKING the table during a transaction will help prevent against a race condition.
从同一个资源中提取:
LOCK TABLES
tbl_name [[AS] alias] lock_type
[, tbl_name [[AS] alias] lock_type] ...
lock_type:
READ [LOCAL]
| [LOW_PRIORITY] WRITE
UNLOCK TABLES
更多信息和语法可以在(官方)MySQL 网站上找到:
More information and syntax can be found on the (official) MySQL website:
- https://dev.mysql.com/doc/refman/5.7/en/sql-syntax-transactions.html
- https://dev.mysql.com/doc/refman/5.7/en/commit.html
关于交易"， 摘自 https://www.informit.com/articles/article.aspx?p=29312
事务是一组连续的数据库操作操作，就像一个单独的工作单元一样执行.换句话说，除非组内的每个单独操作都成功，否则事务将永远不会完成.如果事务中的任何操作失败，则整个事务都将失败.
A transaction is a sequential group of database manipulation operations, which is performed as if it were one single work unit. In other words, a transaction will never be complete unless each individual operation within the group is successful. If any operation within the transaction fails, the entire transaction will fail.
这篇关于我应该使用排队系统来处理付款吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
