以前一直做單機系統，考慮到的相容性往往是儲存在硬碟的資料結構要考慮相容性的。但是目前在進行分布式儲存系統的設計時，遇到訊息體的相容性。
因為分布式系統中，公升級過程不能和單機系統一樣，停業務，公升級，開業務(reboot)。在分布式系統中的，是不能隨便將所有系統全部停掉進行公升級。採用的策略一般是逐步公升級，那麼就會出現新舊系統。這不光要考慮儲存持久化的相容性，而且也要考慮訊息體的相容性。新舊系統可以相互相容彼此的訊息體。
所以在修改系統中存在的訊息體是，就必須要考慮相容性：老系統用老**如何處理新系統的訊息體；反之，新系統如何處老系統的訊息體。
根據ceph**中的相容性發現有這幾種實現策略
訊息頭包含兩個字段：version和compact_version。version表示當前訊息版本，如果修改訊息體，該值應該加1；compact_version表示可以相容的最低版本號；如果peer收到訊息後，發現自己當前版本< compact_version，那麼就屬於不相容的系統，就無法進行解析。
新系統比較好處理老訊息體，但是老系統在不改**情況下，就很難處理新訊息體。
對於新加字段的是最經常，如果在不修改老系統**的情況下，只能將新字段加在訊息體的最後面。老系統放棄這部分資訊，作為無用資料。
這種情況，在訊息體中間進行修改，那麼老系統安裝原來的方式就會解析出錯誤的訊息。對於這種情況，往往採用對老系統傳送老訊息體結構，新系統傳送新訊息體。這樣就會帶來乙個問題，如何獲取peer的資訊。
a：簡單是用version版本，但是在同乙個version版本可能修改了很多的訊息體，很難控制
b：使用feature來表示，如果出現這種情況下，新增乙個feature根據這個feature就很容易判斷peer是否支援這個功能
隨著發展會發現老的訊息體太out了，需要重構，這樣的話使用前面兩種方法就不合適了。那麼就會設計新的訊息體和老訊息共存。但是這樣也是會判斷peer的feature來判斷傳送新舊訊息。
現在才發現設計訊息結構是多麼複雜的事情，不然以後就是無盡的麻煩。
如果在後續中發現有其他分布式系統訊息的其他相容方式也會及時更新。
分布式 分布式系統的設計
在計算機領域，當單機效能達到瓶頸時，一般有兩種方式解決效能問題 而分布式系統的設計說白了就是 如何合理將乙個系統拆分成多個子系統部署到不同機器上。講設計方法前，先介紹分布式系統的特性 1 分布性 空間中隨機分布。這些計算機可以分布在不同的機房，不同的城市，甚至不同的國家。2 對等性 分布式系統中的計...
VB與系統的相容性
以前是用的win8系統，對於vb的學習並沒有收到什麼影響，兩者相敬如賓。可是後來因為系統出問題，重灌了乙個系統，是win864位的，vb有時候根本就執行不了，總是時不時的就停止工作，找了好多辦法解決它，可是問題依舊在。1 首先是從網上找了好多資訊，問問為什麼不能安裝？按理說是可以安裝64位系統的，可...
分布式系統中的分布式事務
分布式事務中可以借助mq訊息系統來進行事務控制，這一點與可靠訊息最終一致方案一樣。看來mq中介軟體確實在乙個分布式系統架構中，扮演者重要的角色。最大努力通知方案是比較簡單的分布式事務方案，它本質上就是通過定期校對，實現資料一致性。中介軟體如何保證訊息的一致性 問題的問法多種多樣，怎麼保證兩個伺服器的...