很早就聽說了zeromq 這個項目,當時不太在意.後來同事kasicass 對這個項目做了研究和分享 ,開始重視起這個項目來.1) libevent封裝了對網絡I/O,信號,定時器等的處理,可以基於它之上做網絡層的開發.2) ACE封裝了不同平臺下的系統調用,也提供好幾種網絡編程的模型.然而,zeromq不是libevent,也不是ACE,因為它的主要特性是:面向消息進行通信.所以,它提供的是比libevent,ACE處在網絡通信中更高壹層的組件.使用它,程序員不再需要上面提到的libevent,ACE之類的庫需要關心的東西,程序員如果要使用zeromq,只需要做如下的事情:1) 告知所使用的patten,比如request-reply,pub-sub,push-pull等(下面會詳細解釋這個pattern).2) 告知是用於機器之間,還是進程之間,線程之間的通信.然後,將所需要發送的數據封裝到zeromq自帶的msg結構體中發送出去,使用者自己關心如何序列化/反序列化這些數據,然後如何處理這些數據就是使用者的事情了.這樣看上來,使用者要關註的事情”高”了壹層,大部分的精力都可以放在業務邏輯之上了.簡而言之,它讓使用者的精力放在了通信模式和業務邏輯上,而不是更下面壹層的網絡層上.下面解釋壹下zeromq常用的幾種網絡pattern:1) request-reply就是壹般的C/S架構中,client與server之間壹問壹答的通信模式,比如最經典的echo服務.需要註意的是,client發送壹個request,server必須有壹個回應.server端作為publish端,而任何連接到服務端的client都會成為subscribe端.也就是說,server端會把當前的所有需要publish出去的消息全部發送到當前連接上去的client上.3) push-pullserver端作為push端,而client端作為pull端.如果有多個client端同時連接到這個server,則服務器會在內部做壹個負載均衡,采用平均分配的算法,將所有的消息均衡發布到client端上.看上去,很稀松平常?接下來亮點真的來了.考慮如下壹種場景.壹個server端做為壹組服務器集群最上層的壹個proxy,起到負載均衡的作用,將請求按照它下面對應服務器集群依次派發到不同的 client端進行處理.某個時刻可能處理的機器只有2臺,而隨著負載越來越大,可能需要3臺機器了,這個時候如果使用zeromq的push-pull 搭建的proxy端,則可以不用對之前搭建的server,client端進行停機,只需要新啟動壹個client連接上去,proxy層就會自動根據當前的機器分配平均派發任務了.cool.實際上,這些模式並不是什麽新東西,只不過zeromq為使用者做了壹個封裝,而不是像libevent,ACE等還局限在網絡層部分的封裝,它關註的是通信層,通信模式等.個人感覺,zeromq部分解決 了erlang所要解決的問題:在多臺機器中通信,派發任務等,是分布式通信的利器,但是局限於語言的限制,它沒有辦法做的跟erlang壹樣的完善(erlang已經可以算的上壹個簡易微型的OS了),但是許多的時候,似乎只使用這壹部分功能也就足夠了.zeromq的代碼量,截至到我目前閱讀的2.0.10-stable版本,也只有不到2W行代碼.提供出去的API也極為簡單,但是內部的實現比較”繞”,zeromq是我閱讀過的項目中少數的非常需要依賴調試工具跟進代碼才能看懂代碼流程的項目,同時代碼中類的繼承層次也比較多,閱讀起來並不像它提供的API那樣簡單直白.後續會對其中的壹些難點做壹些分析.
上一篇:2022可以免費畫汽車電路圖app有哪些-最受歡迎的畫畫軟件分享下一篇:如何教孩子學習序數？