在越来越多的应用智能化，很多后台功能不能及时反馈给用户，但是又不影响用户的体验，大量的任务后台化，由服务器处理完之后再反馈给用户。
随着这种功能的广泛应用，任务到底有没有执行成为维护的难题，毕竟很多小公司开发和维护是一体的。
为了解决这种任务式的难题，特借鉴了张宴的架构思想：轻量级开源简单队列服务 HTTPSQS 1.2 版本发布[原创][张宴]
在这基础上，思考了几个问题：
1. HTTPSQS未记录任务信息
2. 任务失败后HTTPSQS数据被覆盖丢失
3. 任务处理过程中被中断又没有被catch到异常（导致变成脏任务）
4. 任务被重复put （多次执行，毫无意义）
在这基础上面辅助使用了Mysql+HTTPSQS+Mutex的模式来实现应用的稳定，任务处理并发性。
简单一架构图如下：
Mutex Task ：使用redis实现的一种互斥锁，主要功能用于并发、任务重复执行的控制。
流程步骤：
1. 同时在mysql和Httpsqs插入任务，任务的标识为WAIT。
2. 后台SERVICE从HTTPSQS中读取数据
3. Mutex Task任务标识为DOING
4. Mysql Task任务标识为DOING
5. 业务逻辑处理
6. 处理完毕，业务处理失败：Mutex Task为ERROR同时Mysql Task为ERROR。
辅助程序：
1. ERROR Task重新入HTTPSQS，执行以上步骤，根据业务需要控制重试次数，可扩展Mutex Task来实现重试次数
简单二架构图如下：
流程步骤：
1. 在mysql插入任务，任务的标识为WAIT。
2. 辅助程序put任务进入HTTPSQS，Mysql Task标识为READY。
2. 后台SERVICE从HTTPSQS中读取数据
3. Mutex Task任务标识为DOING
4. Mysql Task任务标识为DOING
5. 业务逻辑处理
6. 处理完毕，业务处理失败：Mutex Task为ERROR同时Mysql Task为ERROR。
辅助程序：
1. 辅助程序put任务进入HTTPSQS，Mysql Task标识为READY。
2. ERROR Task更改任务状态ERROR => WAIT，辅助程序自动按照新任务执行。执行以上步骤，根据业务需要控制重试次数，可扩展Mutex Task来实现重试次数。
架构2已应用于正式环境。
正式环境实施有以下状况出现：
1. 任务DOING状态，由于PHP异常机制不是很完善，可以还原当时环境，测试修正。
2. 任务为READY状态，由于Mutex Task的控制，该任务为重复任务，是否继续执行看业务需要。
3. SERVICE无需写成while(true){//doing task} ，可以使用CRON定时+执行次数控制，可以并发，可以防止主程序僵死状态。
特推荐 Mutex Task (源码) ：
Cache应用/任务Mutex，用于高并发任务处理经过多个项目使用
特推荐 Abstract Service (源码) ：
可私信oShine索取