參考資料:ØMQ - The Guide(英文)
參考資料:ØMQ - The Guide(中文)
本文是對ØMQ - The Guide 第四章 Reliable Request-Reply Pattern的整理和總結,具體代碼實現請查閱ØMQ - The Guide .
本文只討論Request-Reply Pattern中的可靠性模式.
本文旨在對各種Request-Reply Pattern有個直觀,感性的介紹,並介紹各種模式的異同.
每種模型都有適合自己的使用場景,沒有絕對的好與壞.使用時根據實際需求選擇不同的模式.
What’s Reliability ?
可靠性指的是系統在出現故障的時候仍然能夠正常工作.
在這裏不涉及天災等不可控的因素造成的故障,也不涉及惡劣的代碼造成的故障,只涉及人爲可控的,可通過程序設計來避免的故障.
Client-Side Reliability (Lazy Pirate Pattern)
該模式解決的問題:
解決了REQ-REP模式中消息丟失,導致Client和server都阻塞等待的問題.
該模式的設計思路:
爲Client端引入重連機制.當在預定時間沒有收到回覆時,就放棄該連接,重新建立連接.
該模式存在的問題:
該模式雖然可以讓Client重連,但不能檢測到server的崩潰.
Lazy Pirate Pattern
Basic Reliable Queuing (Simple Pirate Pattern)
該模式解決的問題:
解決了Client-Side Reliability (Lazy Pirate Pattern)中server崩潰導致服務終止的問題.
該模式的設計思路:
在Client-Side Reliability的基礎上,引入Broker,以便擁有多個server(或worker);
Broker使用隊列保存可用的server(或worker);
當Client的請求到來時,Broker在隊列中選擇處理請求的server(或worker),該過程即負載均衡.
該模式存在的問題:
該模式方法可以避免單個server發生故障時不至於停止服務.
但在面對隊列崩潰和重啓這個問題上它不具備健壯性.隊列也不能檢測到server(或worker)的故障.
The Simple Pirate Pattern:
Robust Reliable Queuing (Paranoid Pirate Pattern)
該模式解決的問題:
解決了Basic Reliable Queuing(Simple Pirate Pattern)無法檢測server(或worker)是否掉線,無法清理掉線的server(或worker)的問題.
該模式的設計思路:
在Basic Reliable Queuing的基礎上,引入server(或worker)到隊列的心跳,使隊列能在任何狀態下檢測到一個掉線的server(或worker).
該模式存在的問題:
雖然可以檢測到server(或worker)是否掉線,並能清理掉線的server(或worker),但Broker只負責負載均衡,該模式存在只能處理單一的任務請求的缺陷.
Paranoid Pirate Pattern
Service-Oriented Reliable Queuing (Majordomo Pattern)
該模式解決的問題:
解決了Robust Reliable Queuing (Paranoid Pirate Pattern)只能處理單一任務請求的缺陷.
該模式的設計思路:
該模式是在Robust Reliable Queuing 的基礎上,引入Service(服務)概念.
一個Service擁有若干workers,這些workers處理同一種任務.
Client發送請求的時候,同時發送Server的名字.
Broker(中介/管家)在接收到請求後,根據請求中Service的名字來選擇處理請求的worker.
該模式存在的問題:
該模式經常到處複製message幀,並沒有充分利用CPU。
真正的問題是Client只能在收到回覆後才發送消息,白白浪費了等待的這段時間.
Majordomo Pattern
Asynchronous Majordomo Pattern
該模式解決的問題:
解決了Majordomo Pattern中Client只能在等到回覆後才能發送消息,浪費時間等待的問題.
該模式的設計思路:
將Majordomo Pattern中Client的套結字類型REQ換成DEALER.使的Client能夠在收到回覆前發送多個請求.
該模式存在的問題:
該模式有個致命的弱點,就是沒有更多代碼的話它沒辦法處理broker崩潰。
該模式中Client沒有重連機制.因爲一個合適的重連機制需要以下這些東西:
(a)附帶一個編號的請求和對應編號的回覆,這個可以通過更改協議來實現。
(b)記錄所有在client API出去的請求,比如說,所有還沒收到回覆的請求。
(c)故障發生的時候,client API負責重新發送所有記錄的請求。
Disconnected Reliability (Titanic Pattern)
該模式解決的問題:
解決了Client不需要實時回覆,但又必須有個持久化Request-Reply連接的問題(比如Email).
該模式的設計思路:
在管家模型的Broker引入Titanic服務.
Titanic負責將Client中需要持久化連接的請求存入硬盤中.
Titanic向server(或worker)發送Client的請求.並將的回覆存入硬盤.
當Client需要回復的時候,Titanic將存儲在硬盤的回覆發送給Client.
該模式存在的問題:
持久化Request-Reply連接會帶來很多問題,從性能慢到必須增加格外的部分去管理、維護。
Titanic Pattern
High-Availability Pair (Binary Star Pattern)
該模式解決的問題:
解決了server崩潰無法重啓,導致服務終止的問題.
該模式的設計思路:
該模型讓兩個server成爲主-從配套的高可靠性組。
在任何時間,這兩個中的一個(活躍的那個)接收client程序的連接。另一個(不活躍的那個)什麼都不做,但這兩個server相互監控着對方。
如果活躍着的那個掉線了,一段特定的時間之後不活躍的那個就會接手。
該模式存在的問題:
該模式在設計時要考慮很多細節問題,這裏只列出部分.可能出現兩個server都活躍的問題,還需要考慮備份的問題等.
Binary Star Pattern
Brokerless Reliability (Freelance Pattern)
該模式解決的問題:
解決了server崩潰或重啓,server太忙,server過載和網絡問題,導致服務終止的問題.
該模式的設計思路:
創建一個server池,每個Client去連接server池中的每個server.該模型的使用場景是名字解析服務.
該模式存在的問題:
Client會變的非常複雜.
Freelance Pattern
