熱場(chǎng)準(zhǔn)備
熟悉的開場(chǎng)白,大家晚上好啊,今天給大家分享的是Redis在大數(shù)據(jù)中的使用,可能真正講的是一些redis的使用技巧,Redis基本的一些東西。
首先給大家個(gè)地址,源碼以及實(shí)例都在里面,當(dāng)然今天的分享也是按照里面的實(shí)例來(lái)進(jìn)行的,大家可以先進(jìn)行下載。
http://git.newlifex.com/NewLife/NewLife.Redis
當(dāng)然這里也附上Redis的下載地址:
windows:
https://github.com/MicrosoftArchive/redis/releases
http://x.newlifex.com/Redis-x64-3.2.100.msi
https://redis.io/download
開始
Redis封裝架構(gòu)講解
實(shí)際上NewLife.Redis是一個(gè)完整的Redis協(xié)議的功能的實(shí)現(xiàn),但是redis的核心功能并沒(méi)有在這里面,Redis的核心功能的實(shí)現(xiàn)是在NewLife.Core里面。這里可以打開看一下,NewLife.Core里面有一個(gè)NewLife.Caching的命名空間,里面有一個(gè)Redis類里面實(shí)現(xiàn)了Redis的基本功能,另一個(gè)類是RedisClient是Redis的客戶端。Redis的核心功能就是有這兩個(gè)類實(shí)現(xiàn)。RedisClient代表著Redis客戶端對(duì)服務(wù)器的一個(gè)連接。
Redis真正使用的時(shí)候有一個(gè)Redis連接池,里面存放著很多個(gè)RedisClient對(duì)象。
所以我們Redis的封裝有兩層,一層是NewLife.Core里面的Redis以及RedisClient。另一層就是NewLife.Redis。這里面的FullRedis是對(duì)Redis的實(shí)現(xiàn)了Redis的所有的高級(jí)功能。這里你也可以認(rèn)為NewLife.Redis是Redis的一個(gè)擴(kuò)展。
Test實(shí)例講解Redis的基本使用
實(shí)例
打開Program.cs看下代碼
這里XTrace.UseConsole();是向控制臺(tái)輸出日志,方便調(diào)試使用查看結(jié)果。
接下來(lái)看第一個(gè)例子Test1。具體的我都在代碼中進(jìn)行了注釋,大家可以看下
staticvoidTest1(){varic=Redis.Create("127.0.0.1:6379",3);//創(chuàng)建Redis實(shí)例,得到FullRedis對(duì)象//varic=newFullRedis();//另一種實(shí)例化的方式//ic.Server="127.0.0.1:6379";//ic.Db=3;//Redis中數(shù)據(jù)庫(kù)ic.Log=XTrace.Log;//顯示日志,進(jìn)行Redis操作把日志輸出,生產(chǎn)環(huán)境不用輸出日志//簡(jiǎn)單操作Console.WriteLine("共有緩存對(duì)象{0}個(gè)",ic.Count);//緩存對(duì)象數(shù)量ic.Set("name","大石頭");//SetK-V結(jié)構(gòu),Set第二個(gè)參數(shù)可以是任何類型Console.WriteLine(ic.Get
1、Set的時(shí)候如果是字符串或者字符數(shù)據(jù)的話Redis會(huì)直接保存起來(lái)(字符串內(nèi)部機(jī)制也是保存二進(jìn)制),如果是其他類型會(huì)默認(rèn)進(jìn)行json序列化然后再保存起來(lái)
2、Get的時(shí)候如果是字符串或者字符數(shù)據(jù)會(huì)直接獲取,如果是其他類型會(huì)進(jìn)行json反序列化
3、Set第三個(gè)參數(shù)過(guò)期時(shí)間單位是秒。
4、vs調(diào)試小技巧,按F5或者直接工具欄“啟動(dòng)”會(huì)編譯整個(gè)解決方案會(huì)很慢(VS默認(rèn)),可以選中項(xiàng)目然后右鍵菜單選擇調(diào)試->啟動(dòng)新實(shí)例。會(huì)只編譯將會(huì)用到的項(xiàng)目,這樣對(duì)調(diào)試來(lái)說(shuō)會(huì)快很多。
5、大家運(yùn)行調(diào)試后可以看到控制臺(tái)輸出的內(nèi)容:向右的箭頭=》是ic.Log=XTrace.Log輸出的日志
6、字典的使用:對(duì)象的話需要把json全部取出來(lái)然后轉(zhuǎn)換成對(duì)象,而字典的話就可以直接取某個(gè)字段。
7、隊(duì)列是List結(jié)構(gòu)實(shí)現(xiàn)的,使用場(chǎng)景可以上游數(shù)據(jù)太多,下游處理不過(guò)來(lái)的時(shí)候,那么就可以使用這個(gè)隊(duì)列。上游的數(shù)據(jù)發(fā)到隊(duì)列,然后下游慢慢的消費(fèi)。另一個(gè)應(yīng)用,跨語(yǔ)言的協(xié)同工作,比方說(shuō)其他語(yǔ)言實(shí)現(xiàn)的程序往隊(duì)列里面塞數(shù)據(jù),然后另一種語(yǔ)言來(lái)進(jìn)行消費(fèi)處理。哈,這種方式類似mq的概念,雖然有點(diǎn)low,但是也很好用。
8、集合,用的比較多的是用在一個(gè)需要精確判斷的去重功能。像我們每天有三千萬(wàn)訂單,這三千萬(wàn)訂單可以有重復(fù),這時(shí)候我想統(tǒng)計(jì)下一共有訂單,這時(shí)候直接數(shù)據(jù)庫(kù)group by是不大可能的,因?yàn)閿?shù)據(jù)庫(kù)中分了十幾張表,這里分享個(gè)實(shí)戰(zhàn)經(jīng)驗(yàn):比方說(shuō)攬收,商家發(fā)貨了,網(wǎng)點(diǎn)要把件收回來(lái),但是收回來(lái)之前網(wǎng)點(diǎn)不知道自己有多少貨啊,這時(shí)候我們做了一個(gè)功能,也就是訂單會(huì)發(fā)送到我們公司來(lái),我們會(huì)建一個(gè)time_site的key的集合,而且集合本身有去重的功能,而且我們可以很方便的通過(guò)set.Count功能來(lái)統(tǒng)計(jì)數(shù)量,當(dāng)件被攬收以后,我們后臺(tái)把這個(gè)件從集合中Remove掉.然后這個(gè)Set中存在的就是網(wǎng)點(diǎn)還沒(méi)有攬收的件,這時(shí)候通過(guò)Count就會(huì)知道這個(gè)網(wǎng)點(diǎn)今天還有多少件沒(méi)有攬收。實(shí)際使用中這個(gè)數(shù)量比較大,因?yàn)橛袔兹f(wàn)個(gè)網(wǎng)點(diǎn)。
9、Redis中布隆過(guò)濾器,去重的,面試的時(shí)候問(wèn)的比較多
10、小經(jīng)驗(yàn)分享:
數(shù)據(jù)庫(kù)中不合法的時(shí)間處理:判斷時(shí)間中的年份,是否大于2000年。如果小于2000就認(rèn)為不合法。習(xí)慣大于小于號(hào)不習(xí)慣用等于號(hào),這樣可以處理很多意外的數(shù)據(jù)
Set的時(shí)候最好指定過(guò)期時(shí)間防止有些需要?jiǎng)h除的數(shù)據(jù),我們忘記刪了
Redis異步盡量不用,因?yàn)镽edis延遲本身很小,大概在100us-200us,再一個(gè)就是Redis本身是單線程的,異步任務(wù)切換的耗時(shí)比網(wǎng)絡(luò)耗時(shí)還要大。List用法:物聯(lián)網(wǎng)中數(shù)據(jù)上傳,量比較大時(shí),我們可以把這些數(shù)據(jù)先放在Redis的List中,比如說(shuō)一秒鐘1萬(wàn)條,然后再批量取出來(lái)然后批量插入數(shù)據(jù)庫(kù)中。這時(shí)候要設(shè)置好key,可以前綴+時(shí)間,對(duì)于已經(jīng)處理的List可以進(jìn)行remove移除。
壓力測(cè)試
接下來(lái)看第四個(gè)例子,我們直接做壓力測(cè)試,代碼如下:
staticvoidMain(String[]args){XTrace.UseConsole();//激活FullRedis,否則Redis.Create會(huì)得到默認(rèn)的Redis對(duì)象FullRedis.Register();Test4();Console.ReadKey();}staticvoidTest4(){varic=Redis.Create("127.0.0.1:6379",5);//varic=newMemoryCache();ic.Bench();}
運(yùn)行的結(jié)果如下圖所示:
測(cè)試就是進(jìn)行g(shù)et,set remove,累加等的操作。大家可以看到在我本機(jī)上輕輕松松的到了六十萬(wàn),多線程的時(shí)候甚至到了一百多萬(wàn)。為什么會(huì)達(dá)到這么高的ops呢,下面給大家說(shuō)一下。
Bench 會(huì)分根據(jù)線程數(shù)分多組進(jìn)行添刪改壓力測(cè)試。
rand 參數(shù),是否隨機(jī)產(chǎn)生key/value。
batch 批大小,分批執(zhí)行讀寫操作,借助GetAll/SetAll進(jìn)行優(yōu)化。
Redis中NB的函數(shù)來(lái)提升性能
上面的操作如果大家都掌握的基本算Redis入門了,接下來(lái)進(jìn)行進(jìn)階。會(huì)了基本比別人更勝一籌了。
1、GetAll()與SetAll()
GetAll:比方說(shuō)我要取十個(gè)key,這個(gè)時(shí)候可以用getall。這時(shí)候redis就執(zhí)行了一次命令。比方說(shuō)我要取10個(gè)key那么用get的話要取10次,如果用getall的話要用1次。一次getall時(shí)間大概是get的一點(diǎn)幾倍,但是10次get的話就是10倍的時(shí)間,這個(gè)賬你應(yīng)該會(huì)算吧。強(qiáng)烈推薦大家用getall。
setall 跟getall相似。批量設(shè)置K-V.
setall與getall性能很恐怖,官方公布的ops也就10萬(wàn)左右,為什么我們的測(cè)試輕輕松松到五十萬(wàn)甚至上百萬(wàn),因?yàn)槲覀兙陀昧藄etall,getall。
如果get,set兩次以上,建議用getall,setall
2、Redis管道Pipeline
比如執(zhí)行10次命令會(huì)打包成一個(gè)包集體發(fā)過(guò)去執(zhí)行,這里實(shí)現(xiàn)的方式是StartPipeline()開始,StopPipeline()結(jié)束中間的代碼就會(huì)以管道的形式執(zhí)行。這里推薦使用我們的更強(qiáng)的武器,AutoPipeline自動(dòng)管道屬性。管道操作到一定數(shù)量時(shí),自動(dòng)提交,默認(rèn)0。使用了AutoPipeline,就不需要StartPipeline,StopPipeline指定管道的開始結(jié)束了!
3、Add與Replace
Add:Redis中沒(méi)有這個(gè)Key就添加,有了就不要添加,返回false
Replace:有則替換,還會(huì)返回原來(lái)的值,沒(méi)有則不進(jìn)行操作
Add跟Replace就是實(shí)現(xiàn)Redis分布式鎖的關(guān)鍵
Redis使用技巧,經(jīng)驗(yàn)分享
在項(xiàng)目的Readme中,這里摘錄下:
特性
在ZTO大數(shù)據(jù)實(shí)時(shí)計(jì)算廣泛應(yīng)用,200多個(gè)Redis實(shí)例穩(wěn)定工作一年多,每天處理近1億包裹數(shù)據(jù),日均調(diào)用量80億次
低延遲,Get/Set操作平均耗時(shí)200~600us(含往返網(wǎng)絡(luò)通信)
大吞吐,自帶連接池,最大支持1000并發(fā)
高性能,支持二進(jìn)制序列化(默認(rèn)用的json,json很低效,轉(zhuǎn)成二進(jìn)制性能會(huì)提升很多)
Redis經(jīng)驗(yàn)分享
在Linux上多實(shí)例部署,實(shí)例個(gè)數(shù)等于處理器個(gè)數(shù),各實(shí)例最大內(nèi)存直接為本機(jī)物理內(nèi)存,避免單個(gè)實(shí)例內(nèi)存撐爆(比方說(shuō)8核心處理器,那么就部署8個(gè)實(shí)例)
把海量數(shù)據(jù)(10億+)根據(jù)key哈希(Crc16/Crc32)存放在多個(gè)實(shí)例上,讀寫性能成倍增長(zhǎng)
采用二進(jìn)制序列化,而非常見(jiàn)的Json序列化
合理設(shè)計(jì)每一對(duì)Key的Value大小,包括但不限于使用批量獲取,原則是讓每次網(wǎng)絡(luò)包控制在1.4k字節(jié)附近,減少通信次數(shù)(實(shí)際經(jīng)驗(yàn)幾十k,幾百k也是沒(méi)問(wèn)題的)
Redis客戶端的Get/Set操作平均耗時(shí)200~600us(含往返網(wǎng)絡(luò)通信),以此為參考評(píng)估網(wǎng)絡(luò)環(huán)境和Redis客戶端組件(達(dá)不到就看一下網(wǎng)絡(luò),序列化方式等等)
使用管道Pipeline合并一批命令
Redis的主要性能瓶頸是序列化、網(wǎng)絡(luò)帶寬和內(nèi)存大小,濫用時(shí)處理器也會(huì)達(dá)到瓶頸
其它可查優(yōu)化技巧以上經(jīng)驗(yàn),源自于300多個(gè)實(shí)例4T以上空間一年多穩(wěn)定工作的經(jīng)驗(yàn),并按照重要程度排了先后順序,可根據(jù)場(chǎng)景需要酌情采用!
緩存Redis的兄弟姐妹
Redis實(shí)現(xiàn)ICache接口,它的孿生兄弟MemoryCache,內(nèi)存緩存,千萬(wàn)級(jí)吞吐率。各應(yīng)用強(qiáng)烈建議使用ICache接口編碼設(shè)計(jì),小數(shù)據(jù)時(shí)使用MemoryCache實(shí)現(xiàn);數(shù)據(jù)增大(10萬(wàn))以后,改用Redis實(shí)現(xiàn),不需要修改業(yè)務(wù)代碼。
提問(wèn)環(huán)節(jié)聊聊大數(shù)據(jù)中Redis使用的經(jīng)驗(yàn),問(wèn)題
1、一條數(shù)據(jù)多個(gè)key怎么設(shè)置比較合理?
如果對(duì)性能要求不是很高直接用json序列化實(shí)體就好,沒(méi)必要使用字典進(jìn)行存儲(chǔ)。
2、隊(duì)列跟List有什么區(qū)別?左進(jìn)右出的話用List還是用隊(duì)列比較好?
隊(duì)列其實(shí)就是用List實(shí)現(xiàn)的,也是基于List封裝的。左進(jìn)右出的話直接隊(duì)列就好。Redis的List結(jié)構(gòu)比較有意思,既可以左進(jìn)右出,也能右進(jìn)左出。所以它既可以實(shí)現(xiàn)列表結(jié)構(gòu),也能隊(duì)列,也能實(shí)現(xiàn)棧
3、存放多個(gè)字段的類性能一樣嗎?
大部分場(chǎng)景都不會(huì)有偏差,可能對(duì)于大公司數(shù)據(jù)量比較大的場(chǎng)景會(huì)有些偏差
4、可否介紹一下使用Redis進(jìn)行數(shù)據(jù)計(jì)算、統(tǒng)計(jì)的場(chǎng)景?
略。自己看視頻吧!o(∩_∩)o 哈哈!(因?yàn)槲覜](méi)聽清?。?/p>
5、大數(shù)據(jù)寫入到數(shù)據(jù)庫(kù)之后 比如數(shù)據(jù)到億以上的時(shí)候 統(tǒng)計(jì)分析這塊 查詢這塊 能不能分享些經(jīng)驗(yàn)。
分表分庫(kù),拆分到一千萬(wàn)以內(nèi)。
6、CPU為何暴漲?
程序員終極理念:CPU達(dá)到百分百,然后性能達(dá)到最優(yōu),盡量不要浪費(fèi)。最痛恨的是:如果cpu不到百分百,性能沒(méi)法提升了,說(shuō)明代碼有問(wèn)題!
視頻地址
視頻已經(jīng)上傳至百度云,大家可以自行下載觀看鏈接:https://pan.baidu.com/s/1sOW_PLjxQE8C2msbDfizeA提取碼:c7dp觀看指南(笑笑提供)
總結(jié)
雖然Redis會(huì)用,但是沒(méi)有像大石頭這樣的大數(shù)據(jù)使用場(chǎng)景。今天的視頻收獲頗豐,可能大部分人跟我一樣,沒(méi)有大石頭的使用場(chǎng)景,但是值得借鑒的經(jīng)驗(yàn)還是很豐富的!期待下一次的精彩分享。
-
封裝
+關(guān)注
關(guān)注
127文章
7968瀏覽量
143191 -
服務(wù)器
+關(guān)注
關(guān)注
12文章
9262瀏覽量
85782 -
Redis
+關(guān)注
關(guān)注
0文章
376瀏覽量
10900
原文標(biāo)題:Redis 基本使用及百億數(shù)據(jù)量中的使用技巧
文章出處:【微信號(hào):DBDevs,微信公眾號(hào):數(shù)據(jù)分析與開發(fā)】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論