[b]INFORM消息背後的原理[/b]
因爲observer不會接收proposal並參與投票，leader不會發送proposal給observer。leader發送給follower的commit消息只包含zxid，並沒有proposal本身。所以，只發送commit消息給observer則不會讓observer得知已提交的proposal。這就是使用INFORM消息的原因，此消息本質上是一個包含了已被commit的proposal的commit消息。
簡而言之，follower會得到兩個消息，而observer只會得到一個。follower通過廣播得到proposal的內容，接下來獲得一個簡單commit消息，此消息只包含了zxid。相反，observer得到一個包含了已被commit的proposal的INFORM消息。
參與了決定是否commit一個proposal的投票的server就稱爲PARTICIPANT server，leader和follower都屬於這種server。observer則稱爲OBSERVER server。
使用observer模式的一個主要的理由就是對讀請求進行擴展。通過增加更多的observer，可以接收更多的請求的流量，卻不會犧牲寫操作的吞吐量。注意到寫操作的吞吐量取決於quorum的size。如果增加更多的server進行投票，quorum會變大，這會降低寫操作的吞吐量。然而增加observer並不會完全沒有損耗，每一個新的observer在每提交一個事務後收到一條額外的消息，這就是前面提到的INFORM消息。這個損耗比起加入follower來投票來說損耗更少。
使用observer的另一個原因是跨數據中心部署。把participant分散到多個數據中心可能會極大拖慢系統，因爲數據中心之間的網絡的延遲。使用observer的話，更新操作都在一個單獨的數據中心來處理，併發送到其他數據中心，讓其他數據中心的client消費數據。阿里開源的跨機房同步系統Otter就使用了observer模式，可以參考。
注意observer的使用並無法完全消除數據中心之間的網絡延遲，因爲observer不得不把更新請求轉發到另一個數據中心的leader，並處理INFORM消息，網絡速度極慢的話也會有影響，它的優勢是爲本地讀請求提供快速響應。
[b]
配置[/b]
爲了使用observer模式，在任何想變成observer模式的配置文件中加入如下配置：
Java代碼 收藏代碼
peerType=observer 並在所有server的配置文件中，配置成observer模式的server的那行配置追加:observer，例如：
Java代碼 收藏代碼
server.1:localhost:2181:3181:observer