简介
PHP 的异步进程助手，借助于 AMQP 实现异步执行 PHP 的方法，将一些很耗时、追求高可用、需要重试机制的操作放到异步进程中去执行，将你的 HTTP 服务从繁重的业务逻辑中解脱出来。以一个较低的成本将传统 PHP 业务逻辑转换成非阻塞、高可用、可扩展的异步模式。
依赖
- PHP 5.6+
- ext-bcmath
- ext-amqp 1.9.1+
- ext-memcached 3.0.3+
安装
通过 composer 安装
或直接下载项目源码
使用范例
业务逻辑：这里定义了很多等待被调用的类和方法，在你的项目中这可能是数据模型、或是一个发送邮件的类。
生产者：通常是 HTTP 服务，传统的 PHP 项目或是一个命令行程序，接收到某个请求或指令后进行一系列的操作。
// 这是同步的模式去<a href="https://www.jb51.cc/tag/fasongyoujian/" target="_blank" class="keywords">发送邮件</a>，如果<a href="https://www.jb51.cc/tag/youjian/" target="_blank" class="keywords">邮件</a>服务响应迟缓或异常，就会直接影响该请求的响应时间，甚至丢失这封重要<a href="https://www.jb51.cc/tag/youjian/" target="_blank" class="keywords">邮件</a>
// SendMailHelper::request($mail);}
}
消费者：PHP 的异步进程，监听消息队列，执行你指定的方法。并且该消费者进程是可扩展的高可用的服务，这一切都得益于 AMQP，这是系统解耦、布局微服务的最佳方案。
consume.PHP
use l669\CacheHelper;
$cache_helper = new CacheHelper('127.0.0.1',11211);
while(true){
try{
$async_helper = new AsyncHelper([
'host' => '127.0.0.1','vhost' => '/','cacheHelper' => $cache_helper
]);
$async_helper->consume();
}catch(Exception $e){
// 可以在这里记录一些日志
sleep(2);
}
}
# 在命令行下启动消费者进程，推荐使用 supervisor 来管理进程
支持事务：需要一次提交执行多个异步方法，事务可以确保完成性。
阻塞式重试：当异步进程执行一个方法，方法内部抛出异常时进行重试，一些必须遵循执行顺序的业务就要采用阻塞式的重试，通过指定重试最大阻塞时长来控制。
// 如果方法中需要抛出异常来结束程序，又不希望被异步进程重试，可以抛出以下几种错误码，进程捕获到这些异常后会放弃重试：
// l669\AsyncException::PARAMS_ERROR
// l669\AsyncException::METHOD_DOES_NOT_EXIST
// l669\AsyncException::KNOWN_ERROR
非阻塞式重试：当异步执行的方法内部抛出异常，async-helper 会将该方法重新放进队列的尾部，先执行新进入队列的方法，回头再重试刚才执行失败的方法，通过指定最大重试次数来控制。
应用和解惑
- 我们采用的是开源的 RabbitMQ 来为我们提供的 AMQP 服务。
- 你的项目部署在拥有很多服务器节点的集群上，每个节点的程序都需要写日志文件，现在的问题就是要收集所有节点上面的日志到一个地方，方便我们及时发现问题或是做一些统计。所有节点都可以使用 async-helper 异步调用一个写日志的方法，而执行这个写日志的方法的进程只需要在一台机器上启动就可以了，这样所有节点的日志就都实时掌握在手里了。
- 做过微信公众号开发的都知道，腾讯微信可以将用户的消息推送到我们的服务器，如果我们在 5s 内未及时响应，腾讯微信会重试 3 次，其实这就是消息队列的应用，使用 async-helper 可以轻松的做和这一样的事情。
- 得益于 RabbitMQ，你可以轻松的横向扩展你的消费者进程的能力，因为 RabbitMQ 天生就支持集群部署，你可以轻松的启动多个消费者进程，或是将消费者进程分布到多台机器上。
- 如果 RabbitMQ 服务不可用怎么办呢？部署 RabbitMQ 高可用服务是容易的，对外提供单一 IP，这个 IP 是个负载均衡，背后是 RabbitMQ 集群，负载均衡承担对后端集群节点的健康检查。
- async-helper 能否承受高并发请求？async-helper 生产者使用的是短连接，也就说在你的 HTTP 还没有响应浏览器的时候 async-helper 就已经结束了工作，你连接 RabbitMQ 的时间是百分之百小于 HTTP 请求的时间的，换言之，只要 RabbitMQ 承受并发的能力超过你的 HTTP 服务的承受并发的能力，RabbitMQ 就永远不会崩，通过横向扩展 RabbitMQ 很容易做到的。
