自己的理解：handlers用來用來解決觸發時間的，也就是當一個tasks真正的執行後，結果發生了變化。會去觸發另一個task。
現實中的應用場景：
當我們修改了某些程序的配置文件以後，有可能需要重啓應用程序，以便能夠使新的配置生效，那麼，物品，麼如何使用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.