自己的理解：handlers用来用来解决触发时间的，也就是当一个tasks真正的执行后，结果发生了变化。会去触发另一个task。

handlers和notify结合使用触发条件：

·Handlers（触发器）

　　是task列表，这些task与前述的task并没有本质上的不同，用于当关注的资源发生变化时，才会采取一定的操作。

·Notify（通知）

　　此action可用于在每个play的最后被触发，这样可以避免多次有改变发生时每次都执行指定的操作，仅在所有的变化发生完成最后一次性地执行指定操作。在notify中列出的操作称为handler，也即notify中调用handler中定义的操作。

现实中的应用场景：

        当我们修改了某些程序的配置文件以后，有可能需要重启应用程序，以便能够使新的配置生效，那么，物品，么如何使用playbook？

例子：加入我们要修改server的端口从80改成8080，并且在修改配置之后重启nginx。剧本如下：

那么想想如果我们不加上handlers的效果，不加handlers，修改配置的task和重启服务的task并没有逻辑性，依赖性。第一次执行这个playbook不会有什么问题，当第二次执行时，会发现根据幂等性特性修改配置文件的task并没有执行，而重启服务的task还是会执行，显然这是不合理的，我们要求是只有配置文件发生变化之后再重启服务。

针对handlers的理解：

handlers可以理解成另一种tasks，handlers是另一种’任务列表‘，handlers的任务会被tasks中的任务进行”调用“，但是，被”调用“并不意味着一定会执行，只有当tasks中的任务”真正执行“以后，handlers中被调用的任务才会执行，如果tasks中的任务并没有做出任何实际的操作，那么handlers中的任务即使被’调用‘，也并不会执行。

如上所说，handlers是另一种任务列表，可以理解handlers和tasks是’平级关系‘，所以他们的缩进相同，上面的handlers中只有一个任务，任务的名称为restart nginx，这个名词被tasks中的modify the configuration这个任务调用了，notify字段就是调用handlers任务，当modify the configuration这个任务执行之后并发生了改变，就会去执行handlers中的相应的任务。

handlers是另一种任务列表，所以handlers中可以有多个任务，被tasks中不同的任务notify，如下：

如上所示，tasks和handlers都是任务列表，只是handlers中的人物被tasks中的任务notify罢了，那么我们来执行一下上述playbook，如下图所以：

从上图看出，handlers执行的顺序与handlers在playbook中定义的顺序是相同的，与handlers被notify的顺序无关，默认情况下，所有的task执行完毕后，才会执行各个handles，并不是执行完某个task后，立即执行相应的handler，如果想要在执行完某些task以后立即执行对应的handlre，那么需要使用meta模块。

结果显示顺序： task1--->task2--->handler1--->handler2--->task3--->handler3.