關於序列化和反序列化

關於序列化和反序列化是一個老生常談的問題，在這裏概述一下較爲容易理解的內容。

備註：紅色爲重點

1、定義以及相關概念

1. 基於OSI七層協議模型：

　　互聯網的產生帶來了機器間通信的需求，而互聯通信的雙方須要採用約定的協議，序列化和反序列化屬於通信協議的一部分。通信協議每每採用分層模型，不一樣模型每層的功能定義以及顆粒度不一樣，例如：TCP/IP協議是一個四層協議，而OSI模型倒是七層協議模型。在OSI七層協議模型中展示層（Presentation Layer）的主要功能是把應用層的對象轉換成一段連續的二進制串，或者反過來，把二進制串轉換成應用層的對象--這兩個功能就是序列化和反序列化。通常而言，TCP/IP協議的應用層對應與OSI七層協議模型的應用層，展現層和會話層，因此序列化協議屬於TCP/IP協議應用層的一部分。

• 序列化： 將數據結構或對象轉換成二進制串的過程
• 反序列化：將在序列化過程當中所生成的二進制串轉換成數據結構或者對象的過程

2.另外一種說法：

序列化 (Serialization)將對象的狀態信息轉換爲能夠存儲或傳輸的形式的過程。在序列化期間，對象將其當前狀態寫入到臨時或持久性存儲區。之後，能夠經過從存儲區中讀取或反序列化對象的狀態，從新建立該對象。

2、序列化協議特性（部分）

可調試性/可讀性

　　序列化和反序列化的數據正確性和業務正確性的調試每每須要很長的時間，良好的調試機制會大大提升開發效率。序列化後的二進制串每每不具有人眼可讀性，爲了驗證序列化結果的正確性，寫入方不得同時撰寫反序列化程序，或提供一個查詢平臺--這比較費時；另外一方面，若是讀取方未能成功實現反序列化，這將給問題查找帶來了很大的挑戰--難以定位是因爲自身的反序列化程序的bug所致使仍是因爲寫入方序列化後的錯誤數據所致使。對於跨公司間的調試，因爲如下緣由，問題會顯得更嚴重：
　　第1、支持不到位，跨公司調試在問題出現後可能得不到及時的支持，這大大延長了調試周期。
　　第2、訪問限制，調試階段的查詢平臺未必對外公開，這增長了讀取方的驗證難度。

　　若是序列化後的數據人眼可讀，這將大大提升調試效率， XML和JSON就具備人眼可讀的優勢。

性能

　　性能包括兩個方面，時間複雜度和空間複雜度：
　　第1、空間開銷（Verbosity）， 序列化須要在原有的數據上加上描述字段，覺得反序列化解析之用。若是序列化過程引入的額外開銷太高，可能會致使過大的網絡，磁盤等各方面的壓力。對於海量分佈式存儲系統，數據量每每以TB爲單位，巨大的的額外空間開銷意味着高昂的成本。
　　第2、時間開銷（Complexity），複雜的序列化協議會致使較長的解析時間，這可能會使得序列化和反序列化階段成爲整個系統的瓶頸。

3、幾種常見的序列化和反序列化協議

當下比較流行的序列化協議，包括XML、JSON、Protobuf、Thrift和Avro。

關於上面的幾種協議的相關知識可用在文章末尾的參考文章中學習或經過其餘途徑進行學習。

4、問答

Q：爲何一下子說序列化是將將數據結構或對象轉換成二進制串的過程，一下子又說序列化是將對象的狀態信息轉換爲能夠存儲或傳輸的形式的過程？

A：其實，進行序列化的目的是爲了跨機器，跨語言進行數據傳輸，最後還可能進行存儲，並且被序列化後的數據結構或對象是否具備人眼可讀可讀性也是一個方面。在C#中，主要有BinaryFormatter、SoapFormatter、XmlSerializer以及Newtonsoft.Json中的JsonConvert這幾種類型提供序列化功能。例如BinaryFormatter是將數據結構或對象序列化爲二進制串（byte[]),不具有人眼可讀性，數據正確性和業務正確性的調試每每須要很長的時間。相反若是將數據結構或對象序列化爲Xml或Json,既知足了需求，又提高了可讀性。

Q：該怎樣選擇序列化協議？

A：根據具體需求以及解析性能、空間開銷等進行選擇。例如：

JSON在不少應用場景中能夠替代XML，更簡潔而且解析速度更快。典型應用場景包括：
　　一、公司之間傳輸數據量相對小，實時性要求相對低（例如秒級別）的服務。
　　二、基於Web browser的Ajax請求。
　　三、因爲JSON具備很是強的先後兼容性，對於接口常常發生變化，並對可調式性要求高的場景，例如Mobile app與服務端的通信。
　　四、因爲JSON的典型應用場景是JSON＋HTTP，適合跨防火牆訪問。

參考：http://kb.cnblogs.com/page/515982/