目錄

Redis 緩存 (Caching)

目的

核心邏輯

? ? ? ? ?存儲形式總結

典型場景

Redis 分布式鎖 (Distributed Lock)

目的

核心作用

核心邏輯

典型場景

核心區別總結

---

Redis 緩存 (Caching)

在Redis中，數據是以鍵值對的形式存儲的，其中鍵總是字符串類型，而值可以是多種數據類型。

目的

加速數據訪問，減少對慢速數據源（如數據庫）的頻繁查詢，提升系統性能和吞吐量。

核心邏輯

1. 讀操作：

   • 應用優先從 Redis 讀取數據。

   • 若 Redis 中無數據（緩存未命中），則查詢數據庫，并將結果寫入 Redis。

2. 寫操作：

   • 更新數據庫后，同步或異步更新/失效 Redis 中的緩存（如?DEL key?或?SET key new_value）。

存儲形式總結

數據類型	底層實現	最大元素數	特點
String	SDS 動態字符串	512 MB	支持文本/二進制數據
Hash	哈希表或 ziplist	232-1 個字段	高效存儲對象屬性
List	雙向鏈表/ziplist	232-1 個元素	保持插入順序
Set	哈希表或 intset	232-1 個元素	自動去重
Sorted Set	跳表 + 哈希表	232-1 個元素	按分數排序
Geospatial	Sorted Set	同 Sorted Set	支持地理坐標計算
Stream	rax 樹	理論無上限	支持消費者組
Bitmap	String	232 位	超高效布爾存儲
HyperLogLog	專用結構	理論無上限	固定12KB內存存儲巨大基數

// 設置過期時間
db.KeyExpire("temp_data", TimeSpan.FromMinutes(30));// 滑動過期
db.StringSet("session:1001", data, TimeSpan.FromMinutes(20), when: When.Always);

典型場景

• 高頻讀取的熱點數據（如商品信息、用戶資料）

• 減輕數據庫壓力

• 加速 API 響應

Redis 分布式鎖 (Distributed Lock)

目的

協調分布式系統中多個進程/服務的并發操作，確保同一時刻只有一個客戶端能執行關鍵邏輯（如資源修改），避免數據競爭。

核心作用

Redis 分布式鎖用于解決分布式系統中的并發沖突問題，主要作用包括：

1. 資源互斥訪問
   確保多個服務實例/進程同時操作共享資源（如數據庫、文件）時，同一時刻只有一個客戶端能執行關鍵代碼。

   例：避免庫存超賣、重復支付、文件覆蓋等問題。

2. 協調分布式任務
   保證定時任務、批處理操作在集群環境中只被執行一次。

3. 防止并發副作用
   避免多個請求同時修改同一數據導致狀態不一致

核心邏輯

1. 加鎖：

   • 客戶端嘗試在 Redis 中創建一個唯一鍵（如?lock:order_123），通過原子操作（如?SET key random_value NX PX 30000）確保互斥性。

2. 執行業務邏輯：

   • 只有成功獲得鎖的客戶端才能執行后續操作（如扣減庫存）。

3. 解鎖：

   • 完成后刪除該鍵（需通過 Lua 腳本驗證值，避免誤刪其他客戶端的鎖）。

典型場景

• 分布式系統下的資源互斥訪問（如訂單支付、庫存扣減）

• 防止重復任務調度（如定時任務只在一個節點執行）

// 示例：使用 Redlock 或 StackExchange.Redis 鎖
var redisLock = _redis.AcquireLock("lock:order_123", TimeSpan.FromSeconds(30));
try
{if (redisLock.IsAcquired){// 執行業務邏輯（如扣減庫存）_stockService.ReduceStock(productId, 1);}
}
finally
{redisLock?.Release(); // 釋放鎖
}

類庫中用到的包是RedLockNet：

//鎖信息集合
var trayBarcodeLockInfos = new List<IRedLock>(); 
try{//獲取鎖var lockInfo = await _redLockLead.AcquireLockAsync(moveTrayBalance.TrayBarcode);_ = !lockInfo.IsAcquired ? throw new BusinessException(message: _localizer["_TrayBarcodeRequestExist", moveTrayBalance.TrayBarcode]) : false;trayBarcodeLockInfos.Add(lockInfo); //獲取鎖成功 將鎖加入集合中//執行業務邏輯··········}catch (BusinessException ex){} 
finally{//釋放鎖foreach (var lockInfo in trayBarcodeLockInfos){await _redLockLead.ReleaseLockAsync(lockInfo);}}

AcquireLockAsync() 獲取鎖 獲取不到返回失敗?

IsAcquired() 代表是否獲取鎖成功?

/// <summary>
/// 獲取鎖(獲取不到立即返回失敗)
/// </summary>
/// <param name="lockKey"></param>
/// <returns></returns>
public virtual async Task<IRedLock> AcquireLockAsync(string lockKey)
{var redLock = await _factoryProvider.RedLockFactoryInstance.CreateLockAsync(lockKey, _defaultKeyExpiry);return redLock;
}

/// <summary>
/// 獲取鎖(阻塞直到獲取鎖成功或者1h后仍獲取不到，返回失敗)
/// </summary>
/// <param name="lockKey"></param>
/// <returns></returns>
public virtual async Task<IRedLock> AcquireLockUntilSuccessAsync(string lockKey)
{var redLock = await _factoryProvider.RedLockFactoryInstance.CreateLockAsync(lockKey, _defaultKeyExpiry, _wait, _retry);return redLock;
}public async Task<IRedLock> CreateLockAsync(string resource, TimeSpan expiryTime, TimeSpan waitTime, TimeSpan retryTime, CancellationToken? cancellationToken = null)
{return await RedLock.CreateAsync(loggerFactory.CreateLogger<RedLock>(), redisCaches, resource, expiryTime, waitTime, retryTime, configuration.RetryConfiguration, cancellationToken ?? CancellationToken.None).ConfigureAwait(continueOnCapturedContext: false);
}

默認為每10秒嘗試一次，在嘗試了一小時后還獲取不到鎖的話，就返回失敗

/// <summary>
/// 釋放鎖
/// </summary>
/// <param name="redLock"></param>
/// <returns></returns>
public virtual async Task ReleaseLockAsync(IRedLock redLock)
{await redLock.DisposeAsync();
}

核心區別總結

特性	Redis 緩存	Redis 分布式鎖
核心目標	提升讀取性能，降低數據庫壓力	解決分布式系統并發沖突
數據性質	存儲業務數據（如用戶信息）	存儲鎖狀態（臨時性、非業務數據）
讀寫模式	高頻讀、低頻寫	短期占用、立即釋放
生命周期	可長期存在（有過期時間）	臨時存在（任務結束即釋放）
關鍵命令	GET/SET/DEL/EXPIRE	SET NX PX/EVAL（Lua 解鎖）
數據一致性	需處理緩存與數據庫一致性（如雙寫策略）	需確保鎖的互斥性和安全性（如 Redlock）

• 鎖是協調機制，不存儲業務數據；緩存是數據副本，兩者不可互換。

• 緩存僅加速數據讀取，無法控制并發寫操作（如超賣問題仍需分布式鎖或數據庫事務）。

實際系統中二者常結合使用：

• 讀場景：用?Redis 緩存加速數據訪問。

• 寫場景：用?Redis 分布式鎖保護共享資源，確保數據一致性。

適用場景	不適用場景
庫存扣減/秒殺系統	高頻短操作（鎖開銷 > 業務開銷）
分布式任務調度	強一致性要求極高的金融交易
防止重復提交	單機應用（用 Monitor 即可）
跨服務共享資源協調	讀多寫少場景（用樂觀鎖更優）