1、Google ProtoBuf官方
2 Google Protocol Buffers
- gProtoBuf 制定了一些協議,基於序列化和反序列化原理,從傳輸算法進行處理
- gProtoBuf 解決高效的解碼,提供get/set方法,但不同版本生成的文件結構發生很大的變化,從結構和使用方面都不一樣,故:兼容性不夠好,升級版本請注意
- gProtoBuf 是基於Client以stub,Server是sketcton方式
- gProtoBuf 不支持繼承方式
3、常見的序列化和反序列化的框架有哪些
序列 | 名稱 | 建議使用 |
---|---|---|
1 | Thrift | 推薦 |
2 | Kyro | 推薦 |
3 | hessian | 推薦 |
4 | protobuf | 推薦 |
5 | fst | 不推薦 |
6 | fastjson | 不推薦 |
7 | Jackson | 推薦 |
8 | gson | 推薦 |
4、序列化與反序列化(要點)
- 序列化其實就是編碼,加碼Encoder:加碼是將字符串轉換成字符數組
- 反序列化其實就是解碼,解碼Decoder:解碼是將字符數組轉換成字符串
- 在Java實體類可以通過實現Serializable接口進行序列化,也可以通過transient關鍵字不實現某個字段不進行序列化(在grpc不建議使用)
5、gProtoBuf實現RPC步驟(重點和掌握點)
- 1、定義一個接口說明文件,描述了對象(結構體)對象成員,接口方法等一系列的信息
- 2、通過RPC框架所提供的編譯器,將接口說明文件編譯成具體的語言文件
- 3、在客戶端和服務器翻倍引入RPC編譯器所生成的
6、RPC的特點(重點)
- RPC將比較大的數據轉換成比較小的序列化數據來提高性能,減少輸送數據的時間(壓縮)
- 注意: RPC使用Java自帶的序列化來提供C++,Python調用是不允許的(不同語言的處理方式不同導致)
7、gProtoBuf的語法和特徵
- 1、required 必填, opional 可選,在開發中required的壞處比好處更明顯,建議使用opional
- 2、syntax = "proto2" 指定版本的語法
- 3、如提供package又提供java_package會以java_package爲主生成,如:提供package不提供java_package會以package生成它爲主的工程,故package是不能省的
- 4、java_outer_classsname會以這個名字生成一個大類,包含其他類.
- 5、文件.proto的1,2的數字表示是一個標識可用二進制唯一字段值
- 6、default = HOME 如果沒有初始化值就是HOME
- 7、option optimize_for = SEPEEP 這個標識加快解析速度
- 8、oneof 多個自動強制設置一個字段行爲來節省空間共享內存,設置任何一個成員都會自主清空
- 9、protobuf支持枚舉與oneof解決多協議對象傳值
8、gProtoBuf使用注意點
- Buildder VS Message是一個不可變的,通過方法連進行完成Build
- ProtobufVarint32FrameDecoder處理器,ProtobufDecder() 方法接收proto文件生成的類
- gProtoBuf建議使用下劃線命名變量,主要是適配不同語言
9、如何共享proto生成不同語言的文件(重點和掌握點)
- 1、git submodule git裏面倉庫的一個倉庫(不推薦使用)
- 2、git subtree 推薦使用
- 3、打成jar 拉版本
10、Netty在proto的風格
- Netty採用方法的風格與proto生成的類一樣的做法
11、TCP和UDP的區別(掌握點)
- 基於連接(TCP)與無連接(UDP)
- 對系統資源的要求(TCP較多,UDP較少)
- TCP能保證數據正確性,TCP保證數據是有順序的,而且TCP邏輯通信信道是全雙工(讀與寫)的可靠的信道
- TCP具有穩定性,有情人機制,三次握手(握手,確認,重發),容易被攻擊(DOS、DDOS、CC,XSS等)
- UDP程序結構較爲簡單,UDP可能丟包,UDP不保證數據的正確性,信道不可靠,
- UDP 快比TCP安全,沒有TCP握手,確認,重發,擁塞控制等機制,
簡單比例:
UDP就好像是一個負責人的快遞員,把包裹送到目的地(鋒巢櫃),並收件人進行簽收。(發短信)
TCP就好像是一個不負責人的快遞員,把包裹送到目的地,然後沒送到收件人手裏,放到哪個物業部或掃描對方