redise在專案中用了很多次,用一次寫一次,每次在看前次寫的**時,總是感覺差強人意,剛好專案需要,現在特將redise的封裝過程分享給大家,寫的不好,還希望大家提供寶貴意見。
封裝redise資料連線物件,redisemanage
首先,redise的資料庫連線以及有關redise的操作,我均使用了外部dll檔案,stackexchange.redis.dll,該dll很成熟穩定,且各大平台有關redise的操作均在使用該dll檔案。廢話不多說,開始建立類檔案redisemanage
宣告redise資料庫連線物件,先貼**
#region connectionmultiplexer 單例
internal static connectionmultiplexer _rediseinstance
}class nestedredis
//將instance設為乙個初始化的connectionmultiplexer新例項
internal static readonly connectionmultiplexer instance = getmanager();
}#endregion
針對redise資料庫連線物件,我們當然不希望重複宣告,重複建立,所以此處使用單例模式建立connectionmultiplexer物件,故在此處宣告了乙個internal【僅允許程式集內訪問】字首的靜態物件,當然有人肯定會問,如果只建立乙個internal字首的變數,如果別的專案中需要引用你封裝好的redise操作dll,豈不是無法訪問,別急,我們還需暴露乙個public的外部可訪問的變數,**如下:
/// /// connectionmultiplexer
///
public static connectionmultiplexer rediseconnectionmanager
}
ok,這樣做的意義何在呢?保護**安全,沒別的想法。
繼續,我們還需要定義乙個外部可訪問的資料庫連線字串變數
/// /// 鏈結設定字串
///
public static string rediseconnectionestring
如果使用者沒給該變數賦值怎麼辦,眾所周知,redise的預設訪問埠是6379,而且如果redise的配置檔案中未設定允許外部訪問,則資料庫連線為localhost,所以我們還需要配置預設的資料庫連線字串,**如下:
/// /// 預設連線字串
///
///
private static string getdefaultconnectionstring()
好了,下面就是getmanager方法了,**很簡單,不再做更多贅述
private static connectionmultiplexer getmanager(string connectionstring = null)
else
}configueationoptions = configurationoptions.parse(connectionstring);
configueationoptions.allowadmin = true;
return connectionmultiplexer.connect(connectionstring);
}
configurationoptions.parse方法,即將資料庫連線字串,轉換為configurationoptions物件,有乙個地方需要注意一下,那就是,如果需要用到connectionmultiplexer物件中的getserver函式,需要在宣告configurationoptions物件時,設定屬性allowadmin=true,**如下:
configueationoptions = configurationoptions.parse(connectionstring);
configueationoptions.allowadmin = true;
Redise篇 記一次Redise的封裝(二)
還記得,上次基於快取的封裝中,我們預留了ibasecachecontainer介面的內容,並沒有寫任何 我們希望在這個介面中擴充套件快取鎖,為什麼要用到快取鎖呢,這個,我需要詳細的闡述一下,當需要有兩個執行緒操作同乙個快取資料時,一旦乙個執行緒為更新快取,另外乙個操作為讀取快取,怎麼辦?讀取了舊值,...
記一次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 在檢視 ...