不依赖系统，以及不依赖yii事物机制，则考虑人为触发。触发可以写在总体的公共页面上，但是考虑到对数据库以及WWW服务器的压力问题，程序的延迟问题，需要对执行函数进行一些优化。

首先，我们考虑对数据库的压力，每次点击页面，我们都让他触发监听系统，监听系统首先要判断此时是否需要更新我们的任务队列（任务队列我把他存在了缓存文件里），如果不需要更新，则只需要对缓存文件里的执行队列进行时间正排序，对已经超时的队列进行执行即可。但我们要考虑什么时候更新队列文件，以及如何更新，这样才能减轻系统压力。

我的思路是，首先，缓存文件可能会被人为删除或者超时失效，则每次先检测是否存在缓存文件（按任务/用户/类型进行分别生成缓存），如果不存在，重新查询数据库，生成缓存文件（已经超时的直接执行，执行不成功的再扔进缓存队列）。

接下来是每次访问，如果有缓存文件，先对文件中的超时任务处理，然后更新缓存文件。此时遇到一个问题，就是操作时对缓存队列的影响，可能我们会需要在缓存队列的开头或者中间的某个位置插入待执行队列，这时我们可以手动删除已存在的队列就好了，下一次触发时，由于找不到缓存文件，则会重新生成最新的缓存队列。

当我们执行完一个任务的时候，队列中的这个条目会删除，如果队列为空，则重新查询，生成队列，这样就能保证最小次数的访问数据库。还有一个问题，比如对订单自动确认收货的监控，如果是用户前台的更新，则需要同时删除此用户的缓存和该用户所属的后台管理员的缓存，这样才能保证相关人员在浏览这个订单的时候，看到的都是最新的状态。同理，后台管理员的修改订单，也应同时删除所有相关人员的缓存队列。