php同步与互斥,web业务开发中的同步互斥与异步回调

最近的工作中遇到一些挑战，挑战中也找到了新的学习点。

同步互斥与异步回调这两个概念大家都不会陌生，学过计算机的人都知道跟进程，并发等等有关系。但如果真的深入下去，这两个概念都是大有文章可做的。我想结合最近自己工作的实际内容大致讲解下这两个概念，遇到的问题以及解决的办法。一方面分享自己的观点，另一方面也给自己最近一段的工作做个总结。

首先说同步互斥

最近有个这样的业务，每次用户成功发起下单http请求后，程序在完成基本业务逻辑的同时，会创建一个异步回调请求来做一些耗时较长的统计任务(理论上一个下单请求只会统计一次)。这样可以避免http请求的超时，提高请求的成功率。但是却偶发地遇到异常情况，一个下单请求统计了两次。通过日志发现是异步回调服务出现偶发错误，并发了异步请求。这种情况说明异步回调服务和本地逻辑都存在问题。首先异步回调服务存在bug，异步服务采用的是redis队列的形式，正常情况下队列是一个一个处理的，但是却出现并发。其次本地程序没做好同步互斥，如果同步互斥做得好，完全可以避免这种并发的情况。

最恰当地解决办法当然是本地逻辑做好同步互斥。异步回调请求中实际的业务逻辑是：首先检查MySQL数据表中回调状态(创建异步回调请求时，记录状态为创建中)，如果状态是创建中，则往下修改统计数据表，修改完成后，则将回调状态更改为成功。当两个请求并发时，回调状态都为创建中，则会两次修改统计表。

因为业务逻辑由php开发。php不支持多线程，所以没有从语言层面支持锁。此时想到的同步互斥解决办法有两种。一是加文件锁，flock来实现。不过文件锁机制会调用到宿主操作系统上的文件锁特性，因此在使用时一定要检查服务器操作系统是否为PHP环境提供了完善可靠的文件锁机制。二是利用MySQL的锁定机制来实现互斥。因为回调业务逻辑里面本身就是对mysql数据表操作，所以采用第二种方法来解决这个问题。

回调请求检查回调状态时，MySQL加事务和行锁(for update)。首先解释事务：事务(Transaction)是并发控制的基本单位。所谓的事务，它是一个操作序列，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。例如，银行转账工作：从一个账号扣款并使另一个账号增款，这两个操作要么都执行，要么都不执行。所以，应该把它们看成一个事务。事务是数据库维护数据一致性的单位，在每个事务结束时，都能保持数据一致性。

在回调业务中，会涉及到多个数据表的操作(回调状态的修改，统计表的修改)。如果执行过程中，任何一个数据库操作出现错误，会出现数据的不一致。举个极端的例子，如果最后修改回调状态因为某种原因一直失败，那么异步回调会一直请求，每次请求都会增加统计。加了事务，任何数据表操作失败，就会回滚所有的操作，避免了数据不一致的异常。

再解释行锁(for update)。mysql执行select操作时，如果后面加上for update操作，该行就会被锁住。事务提交后，才能释放锁。

在回调业务中，如果两个请求并发，第一请求读到该数据并加上行锁，第二个请求只能等第一个请求完成才能读取到数据。第一个请求完成后会把回调状态修改为成功。第二个请求在锁释放后，读取到回调状态为成功，就会返回，不做任何操作。通过事务+行锁，就避免了并发请求中数据库重复操作的情况。

update:近期发现一个新的问题。数据库加行锁，容易出现死锁，导致请求彻底失败。为了解决这种情况，采用mc加锁的方式。add一条记录，请求完成，释放记录。如果并发过来的请求add记录，则会返回false。对add的记录加上过期时间，可避免死锁。具体可见timyang的一篇文章：Memcache mutex设计模式 – 后端技术 by Tim Yang。伪码(Pseudocode)见下面：if (memcache.get(key) == null) {

// 3 min timeout to avoid mutex holder crash

if (memcache.add(key_mutex, 3 * 60 * 1000) == true) {

value = db.get(key);

memcache.set(key, value);

memcache.delete(key_mutex);

} else {

sleep(50);

retry();

}

}

下面再讲异步回调

异步回调不同于多线程，是一种类似消息或者事件的机制。 异步回调的作用主要是减轻主程序的负担，将一些cpu密集型的任务放在一个新进程中去执行。概念上理解很简单，但是在实际业务中用好异步回调却不是一件容易的事情。

工作中有两块内容涉及到异步回调。首先是nodejs，nodejs是异步回调的典范。这种异步回调可以充分利用cpu的资源，提高程序的执行效率。但是在实际情况，异步回调也给开发者带来很大的困扰，第一个是程序排版问题，逻辑稍微复杂的程序，回调程序就会像一个斜下的瀑布一样难看。第二个是绝大部分程序不需要用到回调。有篇文章仔细讲解了nodejs的回调大坑-callback hell: http://www.infoq.com/cn/articles/nodejs-callback-hell/。为了避免这种问题，Node版本>=0.11.2提供了generator。generator属于一种迭代器，将异步回调顺序化。具体实现方式也可以参见上面链接。自从用了generator后，nodejs程序写的顺手多了，腰不酸了，腿不痛了，连加班都有兴趣了，~^-^~。

第二块涉及到异步回调的内容在前面讲同步互斥时已经多次提起过。还是下单业务，创建异步回调请求时的逻辑。偶发出现的情况是回调了次数达到了限制，但统计数据没有更新。后来通过日志发现，回调程序在正常执行程序之前返回，但回调程序依赖正常执行程序逻辑，导致统计操作失败。这时的问题就是回调程序与正常执行程序的时序性出现偏差。更进一步总结就是顺序程序与回调程序之间的逻辑一定要搞清楚。后来的解决办法时，将回调程序依赖正常执行程序的那一部分放在异步回调任务创建之前。

web开发中后端逻辑一般都很复杂，回调不好控制。这也是为什么nodejs写后端并不是很普及的原因。

为了让大家能够更加明确地了解业务，我将新旧逻辑的架构图放在这里对比，大家看看架构的更改对同步互斥和异步回调带来了哪些改变。

旧逻辑架构图：

新逻辑架构图：