Master-slave synchronization delay causes pits

background:

There are multiple duplicate records registered by the user online

Troubleshoot:

• The first one was suspected at first if it was caused by a concurrency problem. Later, most of them were checked every few seconds, and the probability of concurrency was small.
• The second is to look at the time when duplicate data occurs, and then see the problem of delayed replication from the library online, which is the key to the problem.

The original code logic:

First query whether the passed openid exists in the slave library, and insert it into the master library if it does not exist.

Key points of the problem:

When the front end requests for the first time, it is judged that the slave library does not exist, and then the master library inserts the registration data. Due to the replication delay, the second request from the front end came, and the query from the library still did not exist because of the delay, so it was GG, and another one was inserted repeatedly.

Solution:

There are many methods, to list some
- we use the multi-lock judgment when registering, if repeated registration within so many minutes means repeated registration, and subsequent requests will be returned directly.
- can be restricted by a unique index
- or insert ... select ... where not exist this way

Extending some also obvious master-slave replication errors:

$intStatus = $arrInput[‘status’];
$this->objActTmp->updateInfoByAId($intActId, $intStatus);
// 更新后，马上查
$arrActContent = $this->objActTmp->getActByStatus($intStatus);

This is where the master-slave delay appears. After update, get immediately.

Reference link:

http://itindex.net/detail/57223-mysql-%E5%A4%8D%E5%88%B6-%E5%BB%B6%E8%BF%9F