數據傾斜原理 數據傾斜就是數據的分布嚴重不均，流入部分算子的數據明顯多余其他算子，造成這部分算子壓力過(guò)大。 影響 單點(diǎn)問(wèn)題 數據集中在某些分區上（Subtask），導致數據嚴重不平衡。 GC 頻繁 過(guò)多的數據集中在某些 JVM（TaskManager），使得JVM 的內存資源短缺，導致頻繁 GC。 吞吐下降、延遲增大 數據單點(diǎn)和頻繁 GC 導致吞吐下降、延遲增大。 系統崩潰 嚴重情況下，過(guò)長(cháng)的 GC 導致 TaskManager 失聯(lián)，系統崩潰。 Flink數據傾斜問(wèn)題定位 定位反壓 定位反壓有2種方式：Flink Web UI 自帶的反壓監控（直接方式）、Flink Task Metrics（間接方式）。通過(guò)監控反壓的信息 ，可以獲取到數據處理瓶頸的 Subtask。 確定數據傾斜 Flink Web UI 自帶Subtask 接收和發(fā)送的數據量。當 Subtasks 之間處理的數據量有較大的差距，則該 Subtask 出現數據傾斜。 Flink 如何處理常見(jiàn)數據傾斜 數據源 source 消費不均勻 解決思路：通過(guò)調整并發(fā)度，解決數據源消費不均勻或者數據源反壓的情況。 例如kaf....

簡(jiǎn)介 反壓（backpressure）是實(shí)時(shí)計算應用開(kāi)發(fā)中，特別是流式計算中，十分常見(jiàn)的問(wèn)題。反壓意味著(zhù)數據管道中某個(gè)節點(diǎn)成為 瓶頸，處理速率跟不上上游發(fā)送數據的速率，而需要對上游進(jìn)行限速。由于實(shí)時(shí)計算應用通常使用消息隊列來(lái)進(jìn)行生產(chǎn)端和 消費端的解耦，消費端數據源是 pull-based 的，所以反壓通常是從某個(gè)節點(diǎn)傳導至數據源并降低數據源（比如 Kafka consumer）的攝入速率。 簡(jiǎn)單來(lái)說(shuō)，Flink 拓撲中每個(gè)節點(diǎn)（Task）間的數據都以阻塞隊列的方式傳輸，下游來(lái)不及消費導致隊列被占滿(mǎn)后，上游的 生產(chǎn)也會(huì )被阻塞，最終導致數據源的攝入被阻塞。 TCP-based 反壓的弊端 單個(gè)Task導致的反壓，會(huì )阻斷整個(gè)TM-TM之間的socket，連checkpoint barries也無(wú)法發(fā)出。 反壓傳播路徑長(cháng)，導致生效時(shí)延較大。 Credit-based 反壓 反壓過(guò)程簡(jiǎn)介 如圖所示在 Flink 層面實(shí)現反壓機制，就是每一次 ResultSubPartition 向 InputChannel 發(fā)送消息的時(shí)候都會(huì )發(fā)送一個(gè) backlog size 告訴下游準備發(fā)送多少消息，下....

RocksDB 介紹 RocksDB 是嵌入式的 Key-Value 數據庫，在 Flink 中被用作 RocksDBStateBackend 的底層存儲。如下圖所示，RocksDB 持久化的 SST文件在本地文件系統上通過(guò)多個(gè)層級進(jìn)行組織，不同層級之間會(huì )通過(guò)異步Compaction 合并重復、過(guò)期和已刪除的數據。在 RocksDB 的寫(xiě)入過(guò)程中，數據經(jīng)過(guò)序列化后寫(xiě)入到WriteBuffer，WriteBuffer 寫(xiě)滿(mǎn)后轉換為 Immutable Memtable 結構，再通過(guò) RocksDB 的flush 線(xiàn)程從內存 flush 到磁盤(pán)上；讀取過(guò)程中，會(huì )先嘗試從 WriteBuffer 和 Immutable Memtable 中讀取數據，如果沒(méi)有找到，則會(huì )查詢(xún) Block Cache，如果內存中都沒(méi)有的話(huà)，則會(huì )按層級查找底層的 SST 文件，并將返回的結果所在的 Data Block 加載到 BlockCache，返回給上層應用。 RocksDBKeyedStateBackend增量快照介紹 這里介紹一下大家在大狀態(tài)場(chǎng)景下經(jīng)常需要調優(yōu)的 RocksDBKeyedStateBac....

1. 內存設置 1.1 TaskManager 內存模型 TaskManager的內存模型如下圖所示(1.10之后版本內存模型)： Flink使用了堆上內存和堆外內存。 Flink 框架內存使用了堆外內存和堆外內存，不計入slot資源。 Task執行的內存使用了堆上內存和堆外內存。 網(wǎng)絡(luò )緩沖內存：網(wǎng)絡(luò )數據交換所使用的內存大小，如網(wǎng)絡(luò )數據交換緩沖區。 框架堆外內存、Task堆外內存、網(wǎng)絡(luò )緩沖內存都在堆外的直接內存里面。 管理內存：Flink堆外內存的管理，用于管理排序，hash表，緩沖中間結果以及RocksDb 狀態(tài)后端的本地內存。 JVM特有內存：JVM本身占用的內存，包括元數據和執行開(kāi)銷(xiāo)。 Flink 使用內存 = 框架堆內和堆外內存 + Task堆內和堆外內存 + 網(wǎng)絡(luò )緩沖內存 + 管理內存。 進(jìn)程內存 - Flink 內存 + JVM特有內存 1.1.1 JVM特有內存詳解 JVM特定內存： JVM本身使用的內存，包含JVM的metaspace和over-head JVM的metaspace：JVM 元空間。taskmanager.memory.jvm-meta-sp....

跳躍表將有序鏈表中的部分節點(diǎn)分層，每一層都是一個(gè)有序鏈表。在查找時(shí)優(yōu)先從最高層開(kāi)始向后查找，當到達某節點(diǎn)時(shí)，如果next節點(diǎn)值大于要查找的值或next指針指向NULL，則從當前節點(diǎn)下降一層繼續向后查找，這樣可以有效提升效率。如下圖所示使用跳表查找51的路徑為1->21->41->51需要查找4次。如果使用鏈表查找路徑為1->11->21->31->41->51需要查找6次，效率明顯提升了，當數據量較大是提升更為明顯。

壓縮列表ziplist本質(zhì)上就是一個(gè)字節數組，是Redis為了節約內存而設計的一種線(xiàn)性數據結構，可以包含多個(gè)元素，每個(gè)元素可以是一個(gè)字節數組或一個(gè)整數。 Redis的有序集合、散列和列表都直接或者間接使用了壓縮列表。當有序集合或散列表的元素個(gè)數比較少，且元素都是短字符串時(shí)，Redis便使用壓縮列表作為其底層數據存儲結構。列表使用快速鏈表（quicklist）數據結構存儲，而快速鏈表就是雙向鏈表與壓縮列表的組合。 ziplist 壓縮列表是一個(gè)特殊編碼的雙端鏈表（內存上連續），為了盡可能節省內存而設計的。ziplist 可以存儲字符串或者整數值，其中整數被編碼保存為實(shí)際的整數，而不是字符數組。ziplist 支持 O(1) 的時(shí)間復雜度在列表的兩端進(jìn)行 push 和 pop 操作。然而因為這些操作都需要對整個(gè) ziplist 進(jìn)行內存重分配（因為是一塊連續的內存），所以操作的實(shí)際復雜度和 ziplist 占用的內存大小有關(guān)。在 7.0 版本里，ziplist 已經(jīng)全面被 listpack 替換了（主要是因為連鎖更新較影響性能）

檢查操作系統配置 redis-server --check-system 結果如下，說(shuō)明檢查通過(guò)： [slow-clocksource]...OK [xen-clocksource]...OK [overcommit]...OK [THP]...OK 檢查server內存 redis-server --test-memory 1024 --- 長(cháng)期跟新

在編譯源碼https://github.com/RedisLabs/memtier_benchmark 的時(shí)候執行下面命令： autoreconf -ivf ./configure make sudo make install 報錯如下： error: required file './ltmain.sh' not found

redis 命令exists vs get，在判斷key是否存在的場(chǎng)景下： exists速度更快，可以忽略類(lèi)型。 get只適用于string類(lèi)型，當值越大時(shí)，速度越慢。

redis一款高并發(fā)的內存K-V數據庫，提供了好多命令，但是其中有部分對于生產(chǎn)環(huán)境來(lái)說(shuō)比較危險，需要禁用掉。高危命令有：keys、flushdb、flushall、config、debug、eval、script、evalsha、shutdown