# [The Engineering Wisdom Behind Redis’s Single-Threaded Design](https://community.aws/content/2tfQijlXleV5iM6hDkSGkMJlpcd/the-engineering-wisdom-behind-redis-s-single-threaded-design) 文章摘要整理

## **redis 的設計**

Redis 採用單執行緒設計主要基於效能與實現複雜度之間的權衡。其核心架構基於事件循環機制，透過系統級的I/O多路復用技術（如epoll/kqueue）實現大量連接的高效管理。

使用單執行緒模型具有幾項好處:
1. 可忽略了同步機制中的鎖競爭和上下文切換開銷，使得所有操作可以無阻塞地順序執行。
2. 提供了確定性行為。操作以可預測的序列執行，命令嚴格按照從輸入緩衝區處理的順序執行
3. 在記憶體存取層面，單執行緒模型確保了資料結構在操作處理期間保持在快取中，大幅提升了記憶體存取效率。

避免單執行緒的缺點：
無法直接利用多個核心進行命令處理，因此為避免過慢的命令處理導致阻塞，Redis 透過多種機制，如設定命令執行時間閾值、使用 Lua 腳本限制執行時長，以及將持久化等耗時操作轉移到後台執行緒處理。另外，利用水平擴展

## **多執行緒的隱藏複雜性與局限**
改 Redis 成多執行緒後效能仍有所受限。

1. 平行化的根本限制 (Amdahl’s Law)：

Amdahl 定律說明了平行化所能帶來的最大加速比受到工作負載中序列部分的限制。即使我們能將工作負載中的一部分平行處理，但總會有無法平行化的部分，這部分將限制整體效能的提升。

對於類似 Redis 的工作負載，即使慷慨估計大約 30% 的操作可以有效平行化。縱使使用 32 個執行緒，理論上最多也只能達到 1.42 倍的加速，這遠遠達不到人們可能預期的線性擴展。

Redis 的操作特別難以有效平行化，原因包括：許多操作會以相互依賴的方式修改資料結構；大多數 Redis 命令在微秒內即可完成，留下很少的時間用於平行化開銷；命令經常修改全局狀態（例如 LRU 資訊或過期時間）。

2. 記憶體牆問題 (The Memory Wall Problem)：

現代 CPU 的速度非常快，以至於記憶體存取經常成為資料庫效能的限制因素。這種「記憶體牆」問題意味著，即使增加了更多的執行緒，效能往往也無法提升，因為瓶頸不在於 CPU 處理能力，而在於記憶體頻寬和延遲，因此隨意增加更多執行緒反而可能使情況惡化。

多個執行緒會競爭有限的快取空間。雖然每個核心都有自己的 L1/L2 快取，但執行緒必須共享資料。所有核心共享 L3 快取，這也造成了對有限資源的競爭。緩存失效過程(cacheline ping-ponging)，通過 CPU 的緩存一致性協定發生，此過程可能會給作增加數百個週期的延遲。而當工作集大小超過快取容量時，會需更常從主記憶體中獲取資料，這效能會急劇下降。

在 NUMA 系統中，記憶體存取時間取決於記憶體位置與處理器的相對位置。跨 NUMA 節點的記憶體存取可能比本地存取慢 2-3 倍。未能考慮 NUMA 拓撲的多執行緒應用程式在執行緒存取與不同 CPU 插槽相關的記憶體時，可能會遭遇嚴重的效能損失。

3. 複雜性稅 (The Complexity Tax)：

多執行緒系統引入的複雜性會隨著執行緒數量和共享資源的增加而指數級增長。

當系統擁有 N 個鎖可能存在 N(N-1)/2 種潛在的死鎖情境。即使只有 5 個鎖，就有 10 種潛在的 deadlock 情境。為防止 deadlock，整個系統需小心地規劃鎖定順序，這變得越來越困難。

競爭條件發生在系統行為取決於事件相對時序的情況下，這將對開發與營運造成影響，因細微的平行錯誤可能會出現，且可能只在特定的條件下才顯現，導致問題難以重現和診斷。對於資料完整性至關重要的資料庫系統，人們難以對多執行緒程式碼的正確性有信心，

## **使用 Multi-Process 而非 Multi-Threading 的優勢**

1. 程序隔離每個 Redis 實例運行在自己的程序中，擁有獨立的記憶體空間，提供了真正的隔離。記憶體損壞被限制在單一程序內。崩潰的影響僅限於單一分片。
2. 線性擴展。透過分散資料到多個獨立的 Redis 程序，Redis Cluster 實現了近乎線性的跨核心和機器擴展。由於每個實例獨立運行，共享開銷極少。
3. 故障隔離。程序邊界提供了執行緒邊界無法提供的真正隔離。即使某些節點（程序）故障，集群也能繼續運行。這在生產環境中特別有價值。
4. NUMA 對齊：每個 Redis 程序可以被釘選 (pin) 到特定的 NUMA 節點上。這確保了記憶體分配盡可能保持本地，最大程度地減少了昂貴的跨插槽通訊和跨 NUMA 流量。
5. 簡化管理與開發：每個實例維持單執行緒模型，簡化的程式設計，這方法也與雲端原生設計完美契合