MongoDB的網路協議

2021-09-24 00:25:30 字數 1498 閱讀 9092

tcp具有良好的擁塞控制,可靠傳輸等特性,比較適合資料庫產品的通訊協議。一些對資料一致性,可靠性要求不高的產品也有採用udp協議實現。如redis,memcached都支援udp訪問,但從實際的生產上來說,tcp來的更可靠,udp的「不可靠」性質,反而會帶來更多的運維負擔,增加了排查問題的複雜性。

bson作為json的一種擴充套件,支援了binary的資料型別,日期資料等。相比較於protocol buffers而言,資料是humman readable。mongodb經常提及的documents,實際上就是bson格式資料。同樣的,支援巢狀的機制,bson可以很好的對映成object,這相對於表結構,在靈活性上提高了一大截。資料不在是扁平的,可以是樹形的組織結構,比如:

,

"contribs" : [ "fortran", "algol", "backus-naur form", "fp" ],

"awards" : [,]

}

當然bson也有非常討厭的一些地方,比如編碼後的資料過大,引入了過的括號,符號等。

tcp是一種stream的通訊方式,每次請求之間沒有間隔,資料源源不斷的發來,那如何才能識別出乙個完整的請求塊?一般的解決方法是加上乙個header,header的長度固定,用來描述餘下的資訊量,包括攜帶的首席資訊官度。額外說明:mongodb的網路協議都是little-endian。

struct layout ;
messagelength表示整個協議的長度,因為是頭部,所以client每次傳送命令時都要先將資料寫到buffer裡,得到完整的長度後才能通過tcp傳送整個請求。mongodb規定,messagelength不能大於48mb(1000計算),過大的請求包一般意味著過於複雜的請求型別,或者過大的document,這與nosql的設計原則也是違背的。

requestid/responseto每個請求都有乙個id標識,同一時刻不應該出現相同的requestid,driver和server通過這個欄位來確認是否是同乙個請求的上下文

opcode操作**,支援的型別:request-opcodes

相關的解析**在messagingport::recv(message& m)函式內,首先讀取固定長度的header(layout),讀取到header後,根據messagelength數值做個預判是否是其他的協議型別,預判全部通過後等待讀取餘下的協議(messagelength-4),如果socketbuffer中資料不足,就會阻塞在這裡,等待資料報完整到達。

從網路上獲得了完整的資料後交給mymessagehandler::process來處理接下來的命令,這時opcode開始發揮作用,assembleresponse函式會根據opcode的不同,按照不同的協議去解析出相應的物件,然後執行命令。最後按照同樣的協議格式傳送給client響應。發給client的responseto設定為與請求命令的requestid相同,以便driver對應到相應的上下文。

參考引用

網路協議 網路 協議的理解與劃分

通過網路的覆蓋範圍劃分 區域網 一台路由器裝置就可以組建乙個小的區域網,配套光貓和交換機進行使用,覆蓋範圍一般是方圓幾千公尺之內,其具備的安裝便捷 成本節約 擴充套件方便等特點使其在各類辦公室內運用廣泛。區域網可以實現檔案管理 應用軟體共享 印表機共享等功能,在使用過程當中,通過維護區域網網路安全,...

網路協議分層 網路協議介紹

現在的網路都採用分層的方式進行工作 高層 包括應用層 表示層 會話層 傳輸層,負責主機之間的資料傳輸 底層 網路層 資料鏈路層 物理層,負責網路資料傳輸 從高層到底層分別是 應用層 提供程式之間的通訊,常見協議有http ftp 表示層 處理資料格式 資料加密等,常見協議有nbssl lpp 會話層...

網路協議 RPC協議

遠端呼叫協議,用於定義服務之間的介面呼叫規範標準 最早的rpc框架之一 1.2.1 外部資料表示法 xdr 規定互動協議的檔案,包括 與古老的rpc協議相比,雙方的soap協議沒必要完全一致 引數順序 引數個數等 更加靈活 也是乙個xml,描述了方法名 服務名 埠 請求引數等資訊,通過在服務位址後加...