hessian 的字段序列化小記
一背景:
今天線上碰到乙個問題，在通過hessian的反序列化的時候失敗了。
簡單檢視了下原因,是因為服務端和客戶端依賴的bean包版本不一致導致的。
二 具體分析：
client --- > commons-entity
sever --- > commons-entity
做了依賴倒置處理，服務端及客戶端都持有服務介面及物件的包。
commons-entity 存在兩個版本：服務端版本(新版本)及客戶端版本(舊版本)。兩個版本之間區別在於對於某個欄位的型別做了改變。
下面就分析下不同場景下hessian的處理結果。
1.服務端 欄位a:date 客戶端 欄位a:timestamp 反序列化出錯
2.服務端 欄位a:timestamp 客戶端 欄位a:date 序列化正常
因為date是timestamp的父類，故在反序列化時，向上轉型是沒有問題的。反之向下轉型就存在問題。所以1就會出問題，因為1需要將date轉化成timestamp型別。
結論：在反序列化時，若是客戶端物件是服務端物件的父類，那麼不會失敗。
tip：對於日期型別的物件還是建議定義為long型別。
三 擴充套件
以上就是我們具體的故障情況，那麼擴充套件的來測試下一下兩種情況是否存在問題。
場景一：
服務端 存在欄位a 客戶端 無欄位a 反序列化正常
結論：反序列化時依賴於客戶端所持有的物件，對服務傳遞位元組流進行處理的。不是依賴於服務端的物件處理。這樣也很容易理解。因為是客戶端需要生成物件。
場景二：
服務端 無欄位a 客戶端 存在欄位a 反序列化正常
結論：反序列化是先解析客戶端物件，然後拿著該物件的屬性到服務端的位元組流中查詢，若是存在則生成，若是不存在則忽略該屬性的設定，設定為預設值。
總結：在客戶端反序列化時候，從服務端中取，若是取不到，則不管，設定為預設值。不管服務端屬性是否多餘客戶端，一切以客戶端為準。
四 具體實踐**
附乙個hessian的簡單使用的核心**:
}ipersonserviceservlet的實現：
public class ipersonserviceservlet extends hessianservlet implements ipersonservice
@override
public void hello()
@override
public iperson gerperson()
}
org.mortbay.jetty
jetty
6.1h.14
com.inter12.hesian
common-inte***ce
1.0.0
hessian
hessian
3.0.1
}
hessian
hessian
3.0.1
com.inter12.hesian
common-inte***ce
1.0.0
先占個坑，以後再深挖hessian的協議。
MsgPack和Hessian序列化對比
兩者的區別 hessian序列化的時候，會寫入欄位名稱，然後字段值，類似map。msgpack序列化的時候，不寫入欄位名字，會按字段順序寫入值，類似陣列。hessian產生的資料報較大，msgpack產生的資料報較小。網路傳輸資料更小。序列化中hessian的效能較差 msgpack效能更佳，相當於...
序列化（序列化）
原書上翻譯為序列化，msdn翻譯為序列化 作用 當需要儲存，或者網路傳輸 remoting時，資料 物件或值 需要序列化 類似於打包傳輸檔案。system.serializableattribute 序列化是指儲存和獲取磁碟檔案 記憶體或其他地方中的物件。在序列化時，所有的例項資料都儲存到儲存介質上...
序列化（模型序列化 序列化巢狀）
from rest framework import serializers from meituan.models import merchant,class merchantserializer serializers.modelserializer class meta model merch...