第1章 Spring原理及應用
第2章 Spring Cloud原理及應用
第3章 Netty網絡程式設計原理及應用
第4章 ZooKeeper原理及應用
角色
zab協定
第5章 Kafka原理及應用
第6章 Hadoop原理及應用
第7章 HBase原理及應用
第8章 Cassandra原理及應用
特點
Cassandra的特點包括基于列式存儲、P2P去中心化設計、可擴充、多資料中心識别和異地容災、二級索引、支援分布式寫操作：
- 基于列式存儲：Cassandra和HBase一樣，都是基于列式存儲的資料庫，由于查詢中的選擇規則是通過列來定義的，是以整個資料庫是自動索引的，查詢效率很高
- P2P去中心化設計：Cassandra采用的是P2P去中心化的設計思想，在整個叢集中沒有主節點，是以不存在主節點當機則叢集不可用的問題，也不存在主節點性能瓶頸，Cassandra會自動将資料和請求均衡地配置設定到每個節點上
- 可擴充：Cassandra是完全水準擴充的。當需要給叢集添加更多容量時，動态增加節點即可，Cassandra内部會自動做資料遷移，是以不必重新開機任何程序或手動遷移任何資料
- 多資料中心識别和異地容災：Cassandra支援機架和資料中心的識别，當需要做異地容災的時候，隻需要将資料庫配置設定為不同的資料中心即可，Cassandra會保障每個資料中心都有全量資料。是以，當主資料中心當機時，備資料中心能夠完全支援業務請求。同時，當由于地震、火災等不可抗因素導緻主資料中心丢失時，可以基于備資料中心很快地在主資料中心重建叢集并完成資料的自動恢複
- 二級索引：除支援鍵值查詢和根據鍵的範圍查詢，Cassandra還支援二級索引，在二級索引上可以友善地進行Group By和Count操作
- 支援分布式寫操作：P2P架構設計，使用者可以在任何地方任何時間集中讀或寫任何資料，不用擔心單點失敗的問題
資料模型
由Key Space、Column Family、Key和Column組成：
-
Key Space
一個Key Space可包含若幹Column Family。建立Key Space需設定的核心參數包括複制因子和副本存儲政策。複制因子是叢集中同一個資料的副本數。副本存儲政策指把副本以何種政策分布在叢集的伺服器上。副本存儲政策有簡單政策（單資料中心存儲政策）、舊網絡拓撲政策（機架感覺政策）和網絡拓撲政策（資料中心共享政策）。KeySpace的建立指令：
CREATE KEYSPACE Keyspace loginlog WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 3};
-
Key
在Cassandra中，每一行資料記錄都是以Key-Value的形式存儲的，其中Key是唯一辨別。
-
Column
Column與關系型資料庫中的列類似。在Cassandra中，每個Key-Value中的Value又稱為Column，是Cassandra中最小的資料單元。它是一個三元的資料類型，包含name、value和timestamp。name和value都是byte[]類型的，長度不限。
-
Super Column
Super Column允許Key-Value中的Value是一個Map<Key，Value List>，Super Column中的Column可以有多個子列
-
Column Family
一個包含許多Row的結構，與RDBMS中的Table類似。每個Row都包含為Client提供的Key及與該Key關聯的一系列Column。Column Family的類型可以是Standard/Super Column Family類型
-
Standard Column Family
與關系型資料庫中的Table類似，每個Column Family都由一系列Row組成，每個Row都包含一個Key及其對應的若幹Columns，Columns是Column類型。
-
Super Column Family
每個Super Column Family都由一系列Row組成，每個Row都包含一個Key及其對應的若幹SuperColumn。
Gossip協定
反熵（Anti-Entropy），不要求節點知道所有其他節點的狀态，去中心化，各節點之間的角色完全對等，叢集不需要中心節點，常用于能接受最終一緻性的領域，如失敗檢測、路由同步、釋出訂閱、動态負載均衡等。
在A、B兩個節點之間存在3種通信方式：pull、push、pull & push。
收斂性：指Gossip協定中的消息以指數級的速度在網絡中快速傳播，所有狀态的不一緻都可以在很短的時間内收斂到一緻，收斂速度為logn。Pull/Push通信方式最快，其收斂速度也最快。
問題：
多資料中心，即資料分區。
解決：
Cassandra在叢集的所有節點中都使用相同的Seed List（描述叢集中有多少個節點）指定，種子節點配置叢集的Seed List，其他節點在啟動時首先和種子節點互相通信交換叢集的資訊，防止資料分區問題，保障新加入的節點快速學習到整個叢集的資訊。
NWR理論
- N（Number）：在分布式存儲系統中，有N份備份資料
- W（Write）：在一次成功的更新操作中要求至少有W份資料被成功寫入
- R（Read）：在一次成功的讀資料操作中要求至少有R份資料被成功讀取
NWR的不同組合會産生不同的一緻性效果，當W+R>N時，整個系統對于用戶端來講都能保證強一緻性；R+W<=N，則無法保證資料的強一緻性
一緻性Hash
資料副本政策
資料存儲
資料寫入
資料讀取
資料删除機制
删除資料時，隻是插入一個關于這個資料的删除墓碑（Tombstone），并不直接删除原有的資料。該墓碑被作為對該資料的一次修改記錄。在MemTable和SSTable中，墓碑的内容是執行删除請求的時間。當用戶端再次查詢被删除的資料時，Cassandra找到并發現該資料已被标記為删除，則認為該資料已經被删除，傳回用戶端的查詢結果将為空。被删除的資料并不會立刻被從磁盤中删除，短時間内會占用磁盤空間；Major Compaction，垃圾回收機制定期删除被标記墓碑的資料。
和HBase的對比
安裝，略
Spring Boot內建Cassandra，簡單，略
spring-boot-starterdata-cassandra是SpringBoot針對Spring在cassandra-driver-core的基礎上對Cassandra用戶端操作的二次封裝
第9章 ElasticSearch原理及應用
第10章 Spark原理及應用
第11章 Flink原理及應用
Flink将資料抽象為有界資料流和無界資料流。
核心概念
- Flink Cluster：叢集是用于運作Flink應用程式的分布式系統，一個Flink叢集由ZooKeeper、JobManager和Task Manager 3個角色組成。高可用模式下，一般ZooKeeper為至少3個節點的叢集；Job Manager為至少2個節點的叢集，Job Manager高可用模式為一主多備。在正常情況下，主節點提供服務，當主節點當機時，一個備節點會更新為主節點對外提供服務。Task Manager為具體的計算節點，一個叢集中有一個或多個Task Manager。
- Flink Master，指叢集的管理節點，一個Flink Master由Flink Resource Manager（資源管理）、FlinkDispatcher（分發）和Flink Job Manager 3個角色組成。
- Flink Job Manager：Flink的任務管理節點，用于任務的送出、分發和運作狀态的監控。一個叢集可以有一個或多個（高可用模式下）Job Manager。
- Flink Task Manager：Flink叢集的計算節點，Flink的任務被Job Manager排程在多個TaskManager上執行。多個Task Manager上的Task互相交換計算結果以完成資料流的計算。
- Job：指一個運作中的Flink應用程式，Job可通過Job Manager以指令行的方式送出到叢集，或Flink監控頁面送出到叢集。
- Flink Graph：圖，指Flink流式計算程式所組成的資料流程圖。分Logical Graph和Physical Graph。前者描述是應用程式（通常指基于Java或者Scala實作的Flink程式）定義的資料流之間的邏輯關系，與之對應的是邏輯上的Operator（算子）、Input、Output、DataStream和DataSet。後者是Logical Graph基于分布式運作環境轉換後實體上的計算邏輯圖，與之對應的是實體計算上的Task、Input、Output、DataStream和DataSet。
- Flink Operator和Operator Chain：Flink Operator是Flink Logical Graph中的一個節點，用于執行一個Flink Function。一個完整的資料流通常包含一個Source Operator（資料攝取）、Process Function（資料計算）和Sink Operator（資料輸出）。多個相鄰Operator互相連接配接組成一個Operator Chain，在一個Operator Chain内部，Operator的資料可以互相直接通路，不需要經過Flink叢集的序列化和網絡傳輸。
- Flink Task和SubTask：Flink Task是Physical Graph的一個節點，對應實體上的一個計算單元，一個Task由多個SubTask組成，每個SubTask都對應資料流上的一個處理函數。
- Event：指Flink運作時資料模型的狀态變化，Event在流式計算和批量計算接口中被輸入、輸出以完成狀态的記錄和傳遞。
- Function：由應用程式實作的邏輯計算單元，Function一般通過實作Flink的Function接口或繼承Function類來定義。常用的Function有MapFunction、ReduceFunction、ProcessFunction、RichFunction等。
- Flink Record：指資料流中的元素。
- Flink State Backend：定義Task Manager上運作的Job的狀态存儲方式（如JVM堆記憶體存儲、RocksDB、FileSystem），SavePoint和CheckPoint的存儲規則和存儲方式。
架構
Flink由Job Manager、Task Manager和用戶端組成。Job Manager是管理節點，負責叢集任務的送出、配置設定和資源管理；Task Manager是具體執行任務的計算節點；用戶端用于作業的送出。
-
Job Manager的職責
Job Manager負責協調分布式計算節點，也被稱為Master節點。它負責排程任務、協調CheckPoint、故障恢複等。Job Manager将一個作業分為多個Task，并通過Actor系統與TaskManager進行互相通信，用于Task的部署、停止、取消。在高可用部署下會有多個Job Manager，其中有一個Leader、多個Flower。Leader總是處于Active狀态，為叢集提供服務；Flower處于Standby狀态，在Leader當機後會從Flower中選出一個作為Leader繼續為叢集提供服務。Job Manager選舉通過ZooKeeper實作。
-
Task Manager的職責
Task Manager也被稱為Worker節點，用于執行Job Manager配置設定的Task（SubTask）。Task Manager将系統資源（CPU、網絡、記憶體）分為多個Task Slot（計算槽），Task運作在具體的Task Slot上，Task Manager通過Actor系統與Job Manager進行互相通信，定期将Task的運作狀态和Task Manager的運作狀态送出給Job Manager。多個Task Manager上的Task通過DataStream進行狀态計算和結果互動。
-
用戶端
用戶端不是運作時環境的一部分，它主要用于送出作業給Job Manager。在作業送出完成後，用戶端可以斷開連接配接，也可以保持連接配接來接收作業的運作狀态。
- 應用程式的運作流程
- 編寫應用程式資料流作業，可以基于Java或者Scala
- 建構DAG和優化流程
- 通過用戶端指令送出作業到叢集的Job Manager Leader節點
- Job Manager将任務送出的結果和運作狀态回報給用戶端
- Job Manager根據每個Task Manager上資源的使用情況，将作業拆分為多個Task，并通過Actor系統将Task部署到具體的Task Manager節點上
- Task Manager在Task Slot上運作Task，并定時将Task Manager的運作狀态和Task的運作狀态發送給Job Manager，Job Manager根據Task Manager上資源的使用情況和Task的運作狀态對叢集進行排程
- Job Manager和ZooKeeper進行互動，以完成Job Manager的選舉和故障恢複
- Task Slot資源配置設定
- 任務和算子
- 狀态存儲
- 運作模式
事件驅動模型
定義
事件驅動模型是基于事件流的有狀态的計算模型。它接收源源不斷的事件，并根據事件的不同類型更新不同狀态來觸發不同計算。事件驅動模型和一般的計算存儲分離模型的最大差别在于，計算存儲分離模型需要将資料存儲在遠端對象存儲系統（如S3、OSS、OBS）、事務型/關系型資料庫、分布式記憶體系統（LeverDB）中。即計算存儲分離模型的所有資料計算都基于本地記憶體和磁盤，而資料均被存儲在遠端存儲系統中，好處是計算和存儲分離，以便計算和存儲可以各自擴充而互相不影響。計算存儲分離模型的架構
事件驅動模型是基于狀态化流處理完成的，它并未将計算和存儲分離，而是在計算過程中通過通路本地存儲（作業系統記憶體或磁盤）擷取資料以便盡可能快地完成計算。事件驅動模型系統通過定期向遠端持久化存儲寫入CheckPoint和SavePoint來實作狀态復原、故障恢複和程式更新，架構如圖：
特點
事情驅動模型的特點是高效。事件驅動模型由于不需要頻繁通路遠端資料，大部分資料操作在本地記憶體中完成，少部分資料操作在磁盤上完成，是以具有更高的吞吐量和更低的延遲。同時，事件驅動模型會定期增量地将資料處理的狀态以CheckPoint的形式存儲在遠端持久化存儲中，以便程式狀态復原和故障恢複。