There is no process lock in PHP, is there any solution?

There seems to be no process lock mechanism in PHP, but a process lock is required for concurrent order Processing, do you know if there is no ready solution? My consideration is to use the Flock method, generate a file lock, the file lock detection, if the lock is dormant 1 seconds after the detection again, until the lock-Free State and then return to execution, do not know if such a scheme is feasible?

Reply content:

There seems to be no process lock mechanism in PHP, but a process lock is required for concurrent order Processing, do you know if there is no ready solution? My consideration is to use the Flock method, generate a file lock, the file lock detection, if the lock is dormant 1 seconds after the detection again, until the lock-Free State and then return to execution, do not know if such a scheme is feasible?

PHP extensions, or file locks, are obviously not.
In the case of distributed deployment, there will be a problem.

And even for distributed deployments, databases are generally unique.
So you can use MySQL to create a new field to record the lock situation.
This is 数据库乐观锁技术 see:

http://chenzhou123520.iteye.com/blog/1863407

Of course, this approach is not perfect, but it is much more elegant than the solution and the PHP extension.

The PHP file lock flock($fp,LOCK_EX) is not used to control the order concurrency.
Order concurrency Why not use database transactions? MySQL's default engine InnoDB supports transactions.

$db = new mysqli('127.0.0.1','user','pass','dbname',3306);$db->query('SET AUTOCOMMIT=0');$db->query('START TRANSACTION');$db->query($sql);$db->query('COMMIT');$db->query('SET AUTOCOMMIT=1');

If you do not want to use transactions, or if the engine such as MyISAM does not support transactions,
You can consider using the CAS (Check and Set) version number optimistic lock to ensure high concurrency of data consistency.
The above is a transaction plus pessimistic lock to control the database concurrency, but if the system concurrency is very large,
Pessimistic locking can cause a large performance problem for the database (other transactions to wait),
Consider the option to use the version number optimistic locking method.
Just like preventing multi-person edits, get a version number field for the table.
Get the data when the version number and balance, write the version number, the same is inserted, and the version number is added 1.

SELECT balance,version FROM user WHERE id=1 AND balance>10;UPDATE user SET balance=balance-10,version=last_version+1 WHERE id=1 AND version=last_version;

Affected_rows returns 0 to indicate that the operation failed.
Note The version number of this read-write that is obtained by Last_version for select in the update.
The above version number method draws on the memcached's CAs (Check and Set) collision detection mechanism, which is an optimistic lock, can guarantee the high concurrency of data security.
This approach does not require support for database transactions, and there is no problem with the time span of the select operation and the update operation.

PHPThere is an Semaphore extension that can borrow the system semaphore for process lock, compile-time plus --enable-sysvsem or from pecl installation. System is not supported Windows .

Isn't there a lock in the database?

