數據庫	類型	線程模型	吞吐量 (QPS)	延遲 (μs)	內存效率	適用場景	兼容性
Memcached	純內存鍵值存儲	多線程	100K - 500K	10 - 100	高	緩存、會話存儲	無原生密碼認證
DragonflyDB	多協議內存數據庫	多線程	1M+	50 - 200	中高	高吞吐緩存、Redis 替代	兼容 Redis
KeyDB	Redis 多線程分支	多線程	500K - 1M	50 - 150	中	需要 Redis 兼容的多線程場景	完全兼容 Redis
Skytable	NoSQL 數據庫	單線程/多線程	100K - 300K	100 - 500	高	結構化數據存儲	不兼容 Redis
Valkey	Redis 分支	單線程	300K - 800K	50 - 200	中高	Redis 替代、低延遲場景	完全兼容 Redis

DragonflyDB 的核心架構
DragonflyDB 的核心架構旨在提供高并發處理能力和內存高效利用，以滿足現代應用對低延遲、高吞吐量的需求。其設計核心主要圍繞以下幾點：

多線程處理模型：DragonflyDB 采用多線程模型，可以并發處理多個請求，充分利用多核 CPU 的計算資源，解決了 Redis 單線程架構在高并發場景下的性能瓶頸問題。
鎖分離機制：通過將全局鎖劃分為更小的局部鎖，減少線程間的競爭，提升系統并發度，保證在高負載下的穩定性和吞吐量。
優化的內存管理：DragonflyDB 在內存管理上引入了新的分配策略，減少內存碎片，提升內存利用效率，使得在大規模內存使用的場景下性能更為優越。
持久化機制：提供類似于 Redis 的持久化方案，如 RDB 快照和 AOF（Append-Only File）日志，保證了數據的持久性和可靠性。

多線程模型 vs Redis 單線程模型
Redis 單線程模型：Redis 采用單線程模型來處理所有的客戶端請求。這種設計的好處在于實現簡單，避免了線程競爭帶來的復雜性問題。然而，隨著現代硬件的多核化，Redis 的單線程架構無法充分利用 CPU 的多核資源。在處理高并發請求時，單線程模型可能會成為瓶頸，尤其是在 CPU 負載高或者 I/O 操作密集時，容易導致系統的性能下降。
DragonflyDB 多線程模型：與 Redis 不同，DragonflyDB 采用了多線程模型。每個線程可以獨立處理客戶端請求，這使得 DragonflyDB 能夠在多核 CPU 上并行工作，顯著提高了處理請求的速度和吞吐量。通過將任務分發到多個線程來處理，DragonflyDB 能夠大幅提升多用戶環境下的響應效率，同時保持低延遲。

IO 多路復用與性能優化
Redis 的 IO 多路復用：Redis 通過使用 IO 多路復用（如 epoll 等系統調用），在單線程的基礎上同時處理多個客戶端請求。這種機制使得 Redis 即便在單線程的情況下，也能高效地處理網絡連接，避免了因阻塞 I/O 而導致的性能下降。
DragonflyDB 的 IO 多路復用：DragonflyDB 在多線程的架構下同樣采用了 IO 多路復用技術，不同的是，它通過多線程配合 IO 多路復用，使得每個線程都可以獨立地管理自己的 I/O 操作。這種設計結合了多線程并行處理和非阻塞 I/O 的優勢，使得 DragonflyDB 在處理大規模并發連接時，能保持極低的延遲和極高的吞吐量。
性能優化：DragonflyDB 的多路復用機制能夠最大化減少 I/O 操作的開銷，通過減少線程上下文切換和 I/O 阻塞時間，進一步提升了系統的整體性能。此外，通過減少網絡請求的等待時間和使用異步的 I/O 處理方式，DragonflyDB 實現了對海量連接的高效管理。

內存管理與分配策略
DragonflyDB 在內存管理上做了大量優化，以減少內存碎片，提升內存利用率，從而在大規模數據處理時表現更加穩定和高效。其內存管理設計包括以下幾個方面：
對象池和內存復用：DragonflyDB 采用了對象池技術，重用已經分配的內存塊，減少了頻繁的內存分配和釋放操作，降低了系統的內存開銷和垃圾回收的頻率。

分層內存管理：根據數據類型和大小，DragonflyDB 實現了分層次的內存管理策略。例如，對于小對象和大對象分別采用不同的分配策略，避免了因小對象過度分配而導致的內存碎片問題。
自適應內存分配算法：DragonflyDB 的內存分配器可以根據當前系統負載和內存使用情況動態調整內存分配策略，確保內存的高效使用。

垃圾回收優化：為了減少內存碎片和過度的垃圾回收操作，DragonflyDB 在數據存儲和處理過程中引入了更加智能化的垃圾回收機制，進一步提升了系統的內存利用率。

DragonflyDB 的架構設計通過多線程處理、優化的內存管理以及高效的 IO 操作，使其在高并發、大規模數據處理的場景下，能夠提供更高的性能和更好的內存利用率，是 Redis 和 Memcached 的有力替代者。

arm的架構鏡像：docker.dragonflydb.io/dragonflydb/linux_arm64_dragonfly

編輯dragonfly-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:name: dragonfly-deploymentnamespace: default
spec:replicas: 1selector:matchLabels:app: dragonflytemplate:metadata:labels:app: dragonflyspec:securityContext:fsGroup: 1000    # 確保/data/dragonfly目錄可寫runAsUser: 1000  # 非root用戶運行增強安全containers:- name: dragonflyimage: registry.cn-hangzhou.aliyuncs.com/qiluo-images/dragonflyargs: - "--requirepass=87vhqEneQ5u8"- "--dir=/data/dragonfly"- "--force_epoll"   # 關鍵修復參數DragonflyDB 默認使用 io_uring- "--logtostderr"   # 輸出日志到控制臺ports:- containerPort: 6379volumeMounts:- name: dragonfly-datamountPath: /data/dragonflyresources:limits:memory: "2Gi"     # 內存限制cpu: "1"          # CPU限制requests:memory: "1Gi"cpu: "0.5"securityContext:capabilities:add: ["IPC_LOCK"]volumes:- name: dragonfly-dataemptyDir: {}          # 使用臨時空目錄---
apiVersion: v1
kind: Service
metadata:name: dragonfly-service
spec:type: NodePortports:- port: 6379targetPort: 6379nodePort: 30380selector:app: dragonfly

應用配置

kubectl apply -f dragonfly-deployment.yaml

檢查日志（應該不再出現io_uring錯誤）

kubectl logs -f deployment/dragonfly-deployment

測試連接

kubectl run -it --rm redis-test --image=redis --restart=Never -- \redis-cli -h dragonfly-service -a 87vhqEneQ5u8 PING