還記得，上次基於快取的封裝中，我們預留了ibasecachecontainer介面的內容，並沒有寫任何**，我們希望在這個介面中擴充套件快取鎖，為什麼要用到快取鎖呢，這個，我需要詳細的闡述一下，當需要有兩個執行緒操作同乙個快取資料時，一旦乙個執行緒為更新快取，另外乙個操作為讀取快取，怎麼辦？讀取了舊值，快取的值被更改。導致出現業務錯誤。這時候我們需要執行緒同步，執行緒同步的方法據我了解有兩種，（1）：原子操作；（2）鎖；
原子操作能保證該操作在cpu核心中不會被「拆分」，
鎖，能保證只有乙個執行緒訪問該資料，當其他執行緒訪問該資料時，會被拒絕，直到當前獲得資料的執行緒將鎖釋放，其他執行緒才能獲取資料；
好了，已經很明確了，我們為保證資料的可靠性，我們需要乙個快取鎖，即拒絕其他執行緒訪問資料。
同樣的，為了保證程式的可擴充套件性，我們依然需要針對介面程式設計；針對鎖的操作，鎖；解除鎖；是否鎖成功；重新嘗試鎖；廢話不多說，直接貼**；
public inte***ce ifxbolcachelock : idisposable
/// /// 開始鎖
///
/// 資源名稱，即鎖的標識
bool lock(string resourcename);
/// /// 開始鎖，並設定重試條件
///
/// 資源名稱，即鎖的標識
/// 重試次數
/// 每次重試延時
///
bool lock(string resourcename, int retrycount, timespan retrydelay);
/// /// 釋放鎖
///
/// 需要釋放鎖的 key，即鎖的標識
void unlock(string resourcename);
}
bool lock(string resourcename); 鎖操作，resourcename：需要鎖的資源；
bool lock(string resourcename,int retrycount,timespan retrydelay);鎖操作，resourcename：需要鎖的資源，即key；retrycount重試次數；retrydelay每次重試的時間間隔；
void unlock(string resourcename);釋放鎖操作，resourcename：需要釋放鎖的資源
Redise篇 記一次Redise的封裝（基礎篇）
redise在專案中用了很多次，用一次寫一次，每次在看前次寫的 時，總是感覺差強人意，剛好專案需要，現在特將redise的封裝過程分享給大家，寫的不好，還希望大家提供寶貴意見。封裝redise資料連線物件，redisemanage 首先，redise的資料庫連線以及有關redise的操作，我均使用了...
記一次redis使用keys
使用場景 專案啟動時，索引所有redis快取刪除後重新錄入 分析 redistemplete.keys 優化原因 不能用於生產環境 官方文件描述 原因 解決方案 使用scan命令 優點 實現同樣的功能，不會造成redis阻塞 scan 實現 param pattern 表示式 param consu...
redis配置優化 記一次線上redis問題排查
在通過redis快取進行了一系列的介面效能優化後,大部分介面返回在1ms 200ms間,這都是redis的功勞,但隨著介面redis快取越來越多,新的問題產生了,從redis取資料竟然用了5s 通過觀察日誌,並不是每次取資料都是5s,大部分情況從redis取資料還是很快的不會超過5ms.1 在檢視 ...