State Backends 的作用
有狀態的流計算是Flink的一大特點，狀態本質上是數據，數據是需要維護的，例如數據庫就是維護數據的一種解決方案。State Backends 的作用就是用來維護State的。一個 State Backend 主要負責兩件事：Local State Management(本地狀態管理) 和 Remote State Checkpointing（遠程狀態備份）。
Local State Management（本地狀態管理）
State Management 的主要任務是確保狀態的更新和訪問。類似於數據庫系統對數據的管理，State Backends 的狀態管理就是提供對 State 的訪問或更新操作，從這一點上看，State Backends 與數據庫很相似。Flink 提供的 State Backends 主要有兩種形式的狀態管理：
- 直接將 State 以對象的形式存儲到JVM的堆上面
- 將 State 對象序列化后存儲到 RocksDB 中（RocksDB會寫到本地的磁盤上）
以上兩種方式，第一種存儲到JVM堆中，因為是在內存中讀寫，延遲會很低，但State的大小受限於內存的大小；第二種方式存儲到State Backends上（本地磁盤上），讀寫較內存會慢一些，但不受內存大小的限制，同時因為state存儲在磁盤上，可以減少應用程序對內存的占用。根據使用經驗，對延遲不是特別敏感的應用，選擇第二種方式較好，尤其是State比較大的情況下。
Remote State Checkpointing（遠程狀態備份）
Flink程序是分布式運行的，而State都是存儲到各個節點上的，一旦TaskManager節點出現問題，就會導致State的丟失。State Backend 提供了 State Checkpointing 的功能，將 TaskManager 本地的 State 的備份到遠程的存儲介質上，可以是分布式的存儲系統或者數據庫。不同的 State Backends 備份的方式不同，會有效率高低的區別。
如何選擇狀態后端？
根據上面的描述，狀態后端的主要作用包括在每一個TaskManager節點上存儲和管理狀態，將狀態進行遠程備份兩個部分。
FLink 目前提供了三種狀態后端，分別是：
- MemoryStateBackend
對於狀態管理，MemoryStateBackend直接將State對象存儲到TaskManager的JVM堆上，如MapState會被存儲為一個HashMap對象。can suffer from garbage collection pauses because it puts many long-lived objects on the heap.
對於遠程備份，MemoryStateBackend會將State備份到JobManager的堆內存上，這種方式是非常不安全的，且受限於JobManager的內存大小。 - FsStateBackend
對於狀態管理，FsStateBackend與MemoryStateBackend一樣，將State存儲到TaskManager的JVM堆上。
對於遠程備份，FsStateBackend會將State寫入到遠程的文件系統，如HDFS中。 - RocksDBStateBackend
對於狀態管理，RocksDBStateBackend將state存儲到TaskManager節點上的RocksDB數據庫實例上。
對於遠程備份，RocksDBstateBackend會將State備份到遠程的存儲系統中。
綜上所述，MemoryStateBackend 和 FsStateBackend 都是在內存中進行狀態管理，所以可以獲取較低的讀寫延遲，但會受限於TaskManager的內存大小；而RocksDBStateBackend直接將State存儲到RocksDB數據庫中，所以不受JobManager的內存限制，但會有讀寫延遲，同時 RocksDBStateBackend 支持增量備份，這是其他兩個都不支持的特性。一般來說，如果不是對延遲有極高的要求，RocksDBStateBackend是更好的選擇。