什么是單點故障？
假想，如果一顆大樹，樹根讓人給刨了，設想，它的樹葉還有活路，它的枝干還有意義么。
那么用稍微專業一點的說法：在分布式架構中通常會采用一種模式：主從模式；（一個主服務配合多個子服務完成業務處理工作，主服務的作用，主要通過接受用戶請求，進行任務分發工作，然后子服務負責接收到任務，然后處理自己專職內的業務）如果主服務掛了，出現故障了，那么他將引發的是整個系統的癱瘓，所以我們稱此現象為單點故障。
那么上面所說的現象是很可怕的一件事情，都可以算是事故性問題了，那么我們肯定要有應對措施：
一般，我們此類的主服務，負責任務分發的，我們可以開啟一個備用服務，與主服務功能一樣。備用服務會定時向主服務發送一個請求，當主服務會進行響應的時候，則認為主服務還在正常運行；如果備用服務未接受到響應的時候，那么備用服務將立刻替代主服務工作，維持系統的正常運行。通常來說，我們是采用的ping丟包形式來判斷服務是否正常運行。
但是僅僅通過ping丟包形式來判斷一個服務是否正常運行是不嚴謹的，如果出現一些網絡波動，或者主服務當時正在滿核處理其他業務邏輯的時候，響應不夠即時，那么這樣會導致備用服務誤認為主服務癱瘓，從而直接接替主服務工作，從而導致兩個服務在執行任務分發工作。那么我們就需要對此用到分布式鎖。
分布式鎖
分布式鎖的作用就是，當某一個請求產生高並發等操作時，會對其進行限定，保證其數據的准確性。通俗點講就是：我在拜訪一戶人家的時候，我進門后立即把門關上，等我訪問結束后，我出來，再把門打開，你們再去爭，去搶，誰搶到了，再學我的步驟，挨次拜訪。當然會出現一些鎖超時的現象：拜訪人家的時候，賴着不走了，也不出來，別人也進不去，那么這類人我們會強制將其拖走，繼續進行有序拜訪。對於分布式鎖可以采用redis緩存共享實現。
那么我們通過分布式鎖控制主服務的數量，保證其單一主服務。
此處分布式鎖主要由Zookeeper實現，兩個主節點會在Zookeeper注冊一個節點，注冊完成后，編號最小的節點，將會直接被任命為主服務，而其他的服務會被加鎖而阻塞，在一旁備用。Zookeeper會給主服務不定時的ping包，主服務也會給Zookeeper響應包，當Zookeeper收到響應認為主服務正常運行，收不到那么立即大王爺繼位，而那個沒有響應的皇帝立即被T除，如果因為上面說到的滿載，網絡震盪等問題沒有響應，那么也會認為你癱瘓，也會直接刪除該主服務。如果當你這個主服務蘇醒過來，（不斷ping包，響應則認為蘇醒）那么也可以作為備用主服務，繼續注冊，繼續排隊。
其實說了這么多，都是有一個中間件服務在控制整體服務的運行，比如消息隊列（MQ）之類的控制服務的有序進行，不可並存等。