redis的版本迭代,一直遵循著一個(gè)統(tǒng)一的原則:不斷優(yōu)化高性能讀寫的瓶頸,在保證強(qiáng)一致性的,盡量通過(guò)并發(fā)解決它

1.內(nèi)存 ko 硬盤

redis的起源,來(lái)自于作者自己的需求:網(wǎng)站訪問(wèn)量,訪問(wèn)需求提升后,磁盤數(shù)據(jù)庫(kù)規(guī)則的讀寫模式不再滿足,于是內(nèi)存數(shù)據(jù)庫(kù)以其接近內(nèi)存的讀寫速度,靈活的數(shù)據(jù)結(jié)構(gòu)登上舞臺(tái)

這個(gè)階段,redis確定了其簡(jiǎn)單高效強(qiáng)一致性的"單線程"模式,所有的版本迭代都是圍繞不斷優(yōu)化"單線程"的效率,使其不斷接近內(nèi)存讀寫速度極限的過(guò)程

2."快速推出的集群"

硬件更新迭代的速度永遠(yuǎn)沒(méi)有需求增長(zhǎng)來(lái)的快,當(dāng)"單核單線程"的redis碰到性能瓶頸時(shí),沒(méi)有分布式經(jīng)驗(yàn)的作者,貿(mào)然推出了"集群版redis",因?yàn)榉植际?一致性上的問(wèn)題,草草收?qǐng)?此版本redis被拋棄

3.一帶多的高可用主從模式

經(jīng)過(guò)系統(tǒng)學(xué)習(xí)分布式知識(shí)后,redis的作者推出了一寫多讀的主從模式,通過(guò)保證主從節(jié)點(diǎn)的高度一致性,減少了主節(jié)點(diǎn)的高并發(fā)讀壓力,并觀察驗(yàn)證了1-N的數(shù)據(jù)一致性效果

能進(jìn)行主從切換,主從節(jié)點(diǎn)的身份可以自由的切換

4."觀察者集群"的哨兵模式

在主從模式上積累了足夠的經(jīng)驗(yàn)后,redis的作者退出了分布式集群模式上更近一步的哨兵模式,其特點(diǎn)如下:

• 1.服務(wù)提供上,與主從模式保持一致(在支持從直接訪問(wèn)主從的同時(shí),也支持訪問(wèn)哨兵獲取主從信息)

• 2.添加入"觀察團(tuán)"1到多個(gè)哨兵

• 3.哨兵之間可以相互獨(dú)立,也可以相互之間通信,組成集群

• 4.哨兵的集群能進(jìn)行l(wèi)eader的選舉,并通過(guò)自增的"配置紀(jì)元序號(hào)"應(yīng)對(duì)"網(wǎng)裂"

哨兵的角色,既滿足了主從實(shí)時(shí)監(jiān)控,自動(dòng)切換的需求,又能在低并發(fā)的場(chǎng)景下驗(yàn)證集群一致性方案的可行性,是很優(yōu)秀的一步迭代方案

5.官方"集群模式"出現(xiàn)之前的"替代集群方案"

因?yàn)槊斑M(jìn)走的彎路,作者之后的分布式學(xué)習(xí)踐行,多個(gè)迭代版本的小步嘗試,導(dǎo)致redis長(zhǎng)期面臨高并發(fā)讀寫性能瓶頸,最快的方式就是分布式集群化,于是這段空檔期,出現(xiàn)了許多redis的分布式方案,比如codis,twemproxy等

這些集群方案因?yàn)楹拖到y(tǒng)聯(lián)系不夠緊密,導(dǎo)致的問(wèn)題是:key分布后,無(wú)法繞過(guò)代理直接獲取key在哪個(gè)機(jī)器,redis單個(gè)節(jié)點(diǎn)淪為單純的讀寫存儲(chǔ),另外的問(wèn)題就是擴(kuò)容縮容困難,難以進(jìn)行線上的無(wú)縫熱遷移

6.官方推出正式的集群模式

經(jīng)過(guò)主從模式,哨兵模式的技術(shù)積累,演進(jìn),以及實(shí)踐檢驗(yàn),官方推出了正式的集群模式,特點(diǎn)如下:

• 1.集群模式,通過(guò)將全部key劃分到確定,有限(16384)的salt中,再將不同salt映射到集群指定節(jié)點(diǎn),可以通過(guò)任意節(jié)點(diǎn)獲取到salt映射節(jié)點(diǎn)的完整列表,并計(jì)算出key落在了集群哪個(gè)節(jié)點(diǎn)

• 2.通過(guò)對(duì)salt映射集群節(jié)點(diǎn)的完整列表管理,實(shí)現(xiàn)了key可以無(wú)限擴(kuò)展,映射的salt是確定的,極大減少了元信息原理的復(fù)雜度和不確定性,集群各個(gè)節(jié)點(diǎn)的分治協(xié)作有條不紊,只需要確保少量的元數(shù)據(jù)同步一致即可

  • 1.redis集群節(jié)點(diǎn)之間的數(shù)據(jù)遷移的最小單位也是salt,通過(guò)以salt同步數(shù)據(jù),成功后修改元數(shù)據(jù),實(shí)現(xiàn)了極大和極小集群都能以一致的方式管理/遷移集群節(jié)點(diǎn)之間的數(shù)據(jù),極大減小了程序邏輯的復(fù)雜度,增加了系統(tǒng)運(yùn)行的穩(wěn)定性,確定性

• 3.集群模式每個(gè)可寫節(jié)點(diǎn)是主節(jié)點(diǎn),主節(jié)點(diǎn)支持掛靠多個(gè)只讀從節(jié)點(diǎn),主從切換時(shí)采用的是經(jīng)過(guò)驗(yàn)證的哨兵選舉的模式

7.redis6新特性:"多線程",新的通信協(xié)議,系統(tǒng)功能全部模塊化,ACL,官方集群代理模塊......

redis的作者在19年底,退出了redis6的預(yù)發(fā)布版本,通過(guò)幾個(gè)月時(shí)間的實(shí)際運(yùn)行和反饋,于5月退出了redis6的正式版本

兩個(gè)版本之間的和改變和取舍可以看到redis作者對(duì)redis的準(zhǔn)確定位和角色判斷

這是一個(gè)重大的版本,是redis的"企業(yè)級(jí)實(shí)現(xiàn)",各個(gè)新特性的特點(diǎn)如下:

• 1."多線程"

  • 1.在5月推出的正式版中,多線程的實(shí)現(xiàn)是"并發(fā)處理網(wǎng)絡(luò)數(shù)據(jù)的讀寫和協(xié)議的解析,核心的命令執(zhí)行和寫操作維持原有邏輯"

    • a.相較于19年底更為激進(jìn)的預(yù)發(fā)布版本,redis6的正式版本只在不影響核心邏輯的網(wǎng)絡(luò)數(shù)據(jù)的讀寫和協(xié)議的解析部分采用了"并發(fā)",確保了之前久經(jīng)考驗(yàn)的"單機(jī)單線程"核心處理邏輯保持其簡(jiǎn)單可靠性,減少了并發(fā)新特性帶來(lái)的未知風(fēng)險(xiǎn)

• 2.新的通信協(xié)議

  • 1.推出了可選的RESP3協(xié)議,新的協(xié)議,在對(duì)原有協(xié)議兼容的情況下做了許多優(yōu)化

    • a.返回?cái)?shù)據(jù)可以明確返回?cái)?shù)據(jù)的格式類型,降低了請(qǐng)求-響應(yīng)之間的耦合度(原RESP協(xié)議有些請(qǐng)求返回?cái)?shù)據(jù)無(wú)法獲知格式,需要指導(dǎo)請(qǐng)求的命令)

    • b.支持多路復(fù)用,減少網(wǎng)絡(luò)連接的資源消耗

  • 2.引入了許多的新的特性和數(shù)據(jù)類型

    • a.引入了更多的數(shù)據(jù)類型

    • b.引入了對(duì)訂閱/推送更好的支持(對(duì)新特性客戶端緩存的支持)

• 3.系統(tǒng)功能全部模塊化

  • 1.經(jīng)過(guò)多年的開發(fā)和不斷改進(jìn),redis6終于將系統(tǒng)功能(api)調(diào)用全部模塊話,可以像nginx一樣為期單獨(dú)開發(fā)獨(dú)立的模塊,并選擇是否將其加入整個(gè)系統(tǒng)

  • 2.需要特別說(shuō)明的是,隨著redis6一同發(fā)布的,還有隊(duì)列支持的模塊Disque

• 4.ACL

  • 1.與redis高速并發(fā)查詢速度保持一致的,是高危操作導(dǎo)致數(shù)據(jù)完全丟失的速度,這也是redis的RDB,AOF等備份方案一直備受關(guān)注的原因

  • 2.redis6新出了對(duì)命令權(quán)限的管控,主要特征:

    • a.可以限制指定用戶可以執(zhí)行/不能執(zhí)行的命令列表

    • b.可以限定指定用戶是否可以新建鏈接

    • c.可以創(chuàng)建命令集合,并設(shè)定指定用戶可以/不能執(zhí)行命令集合中的命令

    • d.權(quán)限控制生效遵循從頭到尾,從左到右的ACL原則

• 5.官方集群的代理模塊

  • 1.這個(gè)選配的模塊就不多做說(shuō)明了

• 6.客戶端緩存

  • 1.正式版取消了預(yù)發(fā)版中的caching slot战虏，而只使用key names

  • 2.正式版本支持兩種緩存方式

    • a.訂閱模式(默認(rèn)模式)

      • 1.服務(wù)器記錄哪些客戶端訂閱了哪些key names,當(dāng)對(duì)應(yīng)的key改變時(shí),發(fā)送失效通知

      • 2.缺點(diǎn)是占用服務(wù)器內(nèi)存記錄訂閱信息

    • b.廣播模式

      • 1.服務(wù)器不記錄客戶端的訂閱信息,服務(wù)器會(huì)廣播失效信息,客戶端根據(jù)自己緩存的key names自行匹配

      • 2.占用大量cpu發(fā)送"無(wú)效信息"

• 7.支持SSL

  • 1.使得客戶端/集群即使通過(guò)不安全的網(wǎng)絡(luò)傳遞消息也能保證安全性

• 8.提升RDB文件加載速度......

  • 1.包括提升RDB文件加載速度在內(nèi)的其他優(yōu)化

從redis各個(gè)版本迭代的演進(jìn)看,一直遵循著"確保命令執(zhí)行的正確性","單核單線程極致性能","適度引入并發(fā)提升處理能力上限"的設(shè)計(jì)原則

值得一提的是,redis6的開發(fā)過(guò)程,也引用了"并發(fā)"的模式,redis6有長(zhǎng)達(dá)幾十人的commit"貢獻(xiàn)者",尤其SSL功能模塊是在完全沒(méi)有作者幫助的情況下,有其他貢獻(xiàn)者完成的

結(jié)合redis6實(shí)現(xiàn)的"系統(tǒng)框架化,平臺(tái)化",以及modules的引入,可以預(yù)見(jiàn),未來(lái)的redis會(huì)吸引更多的貢獻(xiàn)者參與進(jìn)去,各種新的模塊功能將不斷出現(xiàn),redis未來(lái)的生命力將更加旺盛