Redis基本使用及百億資料量中的使用技巧分享(附視訊地址及觀看指南)
作者:依樂祝
原文地址:https://www.cnblogs.com/yilezhu/p/9941208.html
- 作者:大石頭
- 時間:2018-11-10 晚上20:00
- 地點:釘釘群(組織程式碼BKMV7685)QQ群:1600800
- 內容:Redis基本使用及百億資料量中的使用技巧分享
- 記錄人:依樂祝
熱場準備
熟悉的開場白,大家晚上好啊,今天給大家分享的是Redis在大資料中的使用,可能真正講的是一些redis的使用技巧,Redis基本的一些東西。
首先給大家個地址,原始碼以及例項都在裡面,當然今天的分享也是按照裡面的例項來進行的,大家可以先進行下載。
當然這裡也附上Redis的下載地址:
windows:https://github.com/MicrosoftArchive/redis/releases
http://x.newlifex.com/Redis-x64-3.2.100.msi
Linux:https://redis.io/download
開始
Redis封裝架構講解
實際上NewLife.Redis是一個完整的Redis協議的功能的實現,但是redis的核心功能並沒有在這裡面,Redis的核心功能的實現是在NewLife.Core裡面。這裡可以開啟看一下,NewLife.Core裡面有一個NewLife.Caching的名稱空間,裡面有一個Redis類裡面實現了Redis的基本功能,另一個類是RedisClient是Redis的客戶端。Redis的核心功能就是有這兩個類實現。RedisClient代表著Redis客戶端對伺服器的一個連線。Redis真正使用的時候有一個Redis連線池,裡面存放著很多個RedisClient物件。
所以我們Redis的封裝有兩層,一層是NewLife.Core裡面的Redis以及RedisClient。另一層就是NewLife.Redis。這裡面的FullRedis是對Redis的實現了Redis的所有的高階功能。這裡你也可以認為NewLife.Redis是Redis的一個擴充套件。
Test例項講解Redis的基本使用
例項
開啟Program.cs看下程式碼
這裡XTrace.UseConsole();
是向控制檯輸出日誌,方便除錯使用檢視結果。
接下來看第一個例子Test1。具體的我都在程式碼中進行了註釋,大家可以看下
static void Test1() { var ic = Redis.Create("127.0.0.1:6379", 3);//建立Redis例項,得到FullRedis物件 //var ic = new FullRedis();//另一種例項化的方式 //ic.Server = "127.0.0.1:6379"; //ic.Db = 3;//Redis中資料庫 ic.Log = XTrace.Log;//顯示日誌,進行Redis操作把日誌輸出,生產環境不用輸出日誌 // 簡單操作 Console.WriteLine("共有快取物件 {0} 個", ic.Count);//快取物件數量 ic.Set("name", "大石頭");//Set K-V結構,Set第二個引數可以是任何型別 Console.WriteLine(ic.Get<String>("name"));//Get泛型,指定獲取的型別 ic.Set("time", DateTime.Now, 1);//過期時間秒 Console.WriteLine(ic.Get<DateTime>("time").ToFullString()); Thread.Sleep(1100); Console.WriteLine(ic.Get<DateTime>("time").ToFullString()); // 列表 var list = ic.GetList<DateTime>("list"); list.Add(DateTime.Now); list.Add(DateTime.Now.Date); list.RemoveAt(1); Console.WriteLine(list[list.Count - 1].ToFullString()); // 字典 var dic = ic.GetDictionary<DateTime>("dic"); dic.Add("xxx", DateTime.Now); Console.WriteLine(dic["xxx"].ToFullString()); // 佇列 var mq = ic.GetQueue<String>("queue"); mq.Add(new[] { "abc", "g", "e", "m" }); var arr = mq.Take(3); Console.WriteLine(arr.Join(",")); // 集合 var set = ic.GetSet<String>("181110_1234"); set.Add("xx1"); set.Add("xx2"); set.Add("xx3"); Console.WriteLine(set.Count); Console.WriteLine(set.Contains("xx2")); Console.WriteLine("共有快取物件 {0} 個", ic.Count); }
Set的時候如果是字串或者字元資料的話Redis會直接儲存起來(字串內部機制也是儲存二進位制),如果是其他型別會預設進行json序列化然後再儲存起來
Get的時候如果是字串或者字元資料會直接獲取,如果是其他型別會進行json反序列化
Set第三個引數過期時間單位是秒。
vs除錯小技巧,按F5或者直接工具欄“啟動”會編譯整個解決方案會很慢(VS預設),可以選中專案然後右鍵選單選擇除錯->啟動新例項。會只編譯將會用到的專案,這樣對除錯來說會快很多。
大家執行除錯後可以看到控制檯輸出的內容:向右的箭頭=》是
ic.Log=XTrace.Log
輸出的日誌字典的使用:物件的話需要把json全部取出來然後轉換成物件,而字典的話就可以直接取某個欄位。
佇列是List結構實現的,使用場景可以上游資料太多,下游處理不過來的時候,那麼就可以使用這個佇列。上游的資料發到佇列,然後下游慢慢的消費。另一個應用,跨語言的協同工作,比方說其他語言實現的程式往佇列裡面塞資料,然後另一種語言來進行消費處理。哈,這種方式類似mq的概念,雖然有點low,但是也很好用。
集合,用的比較多的是用在一個需要精確判斷的去重功能。像我們每天有三千萬訂單,這三千萬訂單可以有重複,這時候我想統計下一共有訂單,這時候直接資料庫group by是不大可能的,因為資料庫中分了十幾張表,這裡分享個實戰經驗:比方說攬收,商家發貨了,網點要把件收回來,但是收回來之前網點不知道自己有多少貨啊,這時候我們做了一個功能,也就是訂單會發送到我們公司來,我們會建一個time_site的key的集合,而且集合本身有去重的功能,而且我們可以很方便的通過set.Count功能來統計數量,當件被攬收以後,我們後臺把這個件從集合中Remove掉.然後這個Set中存在的就是網點還沒有攬收的件,這時候通過Count就會知道這個網點今天還有多少件沒有攬收。實際使用中這個數量比較大,因為有幾萬個網點。
Redis中布隆過濾器,去重的,面試的時候問的比較多
小經驗分享:
- 資料庫中不合法的時間處理:判斷時間中的年份,是否大於2000年。如果小於2000就認為不合法。習慣大於小於號不習慣用等於號,這樣可以處理很多意外的資料
- Set的時候最好指定過期時間防止有些需要刪除的資料,我們忘記刪了
- Redis非同步儘量不用,因為Redis延遲本身很小,大概在100us-200us,再一個就是Redis本身是單執行緒的,非同步任務切換的耗時比網路耗時還要大。
- List用法:物聯網中資料上傳,量比較大時,我們可以把這些資料先放在Redis的List中,比如說一秒鐘1萬條,然後再批量取出來然後批量插入資料庫中。這時候要設定好key,可以字首+時間,對於已經處理的List可以進行remove移除。
壓力測試
接下來看第四個例子,我們直接做壓力測試,程式碼如下:
static void Main(String[] args)
{
XTrace.UseConsole();
// 啟用FullRedis,否則Redis.Create會得到預設的Redis物件
FullRedis.Register();
Test4();
Console.ReadKey();
}
static void Test4()
{
var ic = Redis.Create("127.0.0.1:6379", 5);
//var ic = new MemoryCache();
ic.Bench();
}
執行的結果如下圖所示:
測試就是進行get,set remove,累加等的操作。大家可以看到在我本機上輕輕鬆鬆的到了六十萬,多執行緒的時候甚至到了一百多萬。為什麼會達到這麼高的ops呢,下面給大家說一下。
- Bench 會分根據執行緒數分多組進行添刪改壓力測試。
- rand 引數,是否隨機產生key/value。
- batch 批大小,分批執行讀寫操作,藉助GetAll/SetAll進行優化。
Redis中NB的函式來提升效能
上面的操作如果大家都掌握的基本算Redis入門了,接下來進行進階。會了基本比別人更勝一籌了。
- GetAll()與SetAll()
GetAll:比方說我要取十個key,這個時候可以用getall。這時候redis就執行了一次命令。比方說我要取10個key那麼用get的話要取10次,如果用getall的話要用1次。一次getall時間大概是get的一點幾倍,但是10次get的話就是10倍的時間,這個賬你應該會算吧。強烈推薦大家用getall。
setall 跟getall相似。批量設定K-V.
setall與getall效能很恐怖,官方公佈的ops也就10萬左右,為什麼我們的測試輕輕鬆鬆到五十萬甚至上百萬,因為我們就用了setall,getall。
如果get,set兩次以上,建議用getall,setall
- Redis管道Pipeline
比如執行10次命令會打包成一個包集體發過去執行,這裡實現的方式是StartPipeline()開始,StopPipeline()結束中間的程式碼就會以管道的形式執行。這裡推薦使用我們的更強的武器,AutoPipeline自動管道屬性。管道操作到一定數量時,自動提交,預設0。使用了AutoPipeline,就不需要StartPipeline,StopPipeline指定管道的開始結束了!
- Add與Replace
- Add:Redis中沒有這個Key就新增,有了就不要新增,返回false
- Replace:有則替換,還會返回原來的值,沒有則不進行操作
Add跟Replace就是實現Redis分散式鎖的關鍵
Redis使用技巧,經驗分享
在專案的Readme中,這裡摘錄下:
特性
- 在ZTO大資料實時計算廣泛應用,200多個Redis例項穩定工作一年多,每天處理近1億包裹資料,日均呼叫量80億次
- 低延遲,Get/Set操作平均耗時200~600us(含往返網路通訊)
- 大吞吐,自帶連線池,最大支援1000併發
- 高效能,支援二進位制序列化(預設用的json,json很低效,轉成二進位制效能會提升很多)
Redis經驗分享
- 在Linux上多例項部署,例項個數等於處理器個數,各例項最大記憶體直接為本機實體記憶體,避免單個例項記憶體撐爆(比方說8核心處理器,那麼就部署8個例項)
- 把海量資料(10億+)根據key雜湊(Crc16/Crc32)存放在多個例項上,讀寫效能成倍增長
- 採用二進位制序列化,而非常見的Json序列化
- 合理設計每一對Key的Value大小,包括但不限於使用批量獲取,原則是讓每次網路包控制在1.4k位元組附近,減少通訊次數(實際經驗幾十k,幾百k也是沒問題的)
- Redis客戶端的Get/Set操作平均耗時200~600us(含往返網路通訊),以此為參考評估網路環境和Redis客戶端元件(達不到就看一下網路,序列化方式等等)
- 使用管道Pipeline合併一批命令
- Redis的主要效能瓶頸是序列化、網路頻寬和記憶體大小,濫用時處理器也會達到瓶頸
- 其它可查優化技巧
以上經驗,源自於300多個例項4T以上空間一年多穩定工作的經驗,並按照重要程度排了先後順序,可根據場景需要酌情采用!
快取Redis的兄弟姐妹
Redis實現ICache介面,它的孿生兄弟MemoryCache,記憶體快取,千萬級吞吐率。
各應用強烈建議使用ICache介面編碼設計,小資料時使用MemoryCache實現;
資料增大(10萬)以後,改用Redis實現,不需要修改業務程式碼。
提問環節聊聊大資料中Redis使用的經驗,問題
一條資料多個key怎麼設定比較合理?
如果對效能要求不是很高直接用json序列化實體就好,沒必要使用字典進行儲存。佇列跟List有什麼區別?左進右出的話用List還是用佇列比較好?
佇列其實就是用List實現的,也是基於List封裝的。左進右出的話直接佇列就好。Redis的List結構比較有意思,既可以左進右出,也能右進左出。所以它既可以實現列表結構,也能佇列,也能實現棧存放多個欄位的類效能一樣嗎?
大部分場景都不會有偏差,可能對於大公司資料量比較大的場景會有些偏差可否介紹一下使用Redis進行資料計算、統計的場景?
略。自己看視訊吧!o(∩_∩)o 哈哈!(因為我沒聽清!)大資料寫入到資料庫之後 比如資料到億以上的時候 統計分析這塊 查詢這塊 能不能分享些經驗。
分表分庫,拆分到一千萬以內。CPU為何暴漲?
程式設計師終極理念:CPU達到百分百,然後效能達到最優,儘量不要浪費。最痛恨的是:如果cpu不到百分百,效能沒法提升了,說明程式碼有問題!
視訊地址
視訊已經上傳至百度雲,大家可以自行下載觀看
連結:https://pan.baidu.com/s/1sOW_PLjxQE8C2msbDfizeA
提取碼:c7dp
觀看指南(笑笑提供)
總結
雖然Redis會用,但是沒有像大石頭這樣的大資料使用場景。今天的視訊收穫頗豐,可能大部分人跟我一樣,沒有大石頭的使用場景,但是值得借鑑的經驗還是很豐富的!期待下一次的精彩分享。同時附上QQ群:1600800。可以共同交流使用經驗!