第一：Redis 是什么?

Redis是基于內(nèi)存、可持久化的日志型、Key-Value數(shù)據(jù)庫(kù) 高性能存儲(chǔ)系統(tǒng),并提供多種語(yǔ)言的API.

第二：出現(xiàn)背景

• 數(shù)據(jù)結(jié)構(gòu)(Data Structure)需求越來越多, 但memcache中沒有, 影響開發(fā)效率

• 性能需求, 隨著讀操作的量的上升需要解決,經(jīng)歷的過程有:

  數(shù)據(jù)庫(kù)讀寫分離(M/S)–>數(shù)據(jù)庫(kù)使用多個(gè)Slave–>增加Cache (memcache)–>轉(zhuǎn)到Redis

• 解決寫的問題：

  水平拆分,對(duì)表的拆分,將有的用戶放在這個(gè)表,有的用戶放在另外一個(gè)表；

• 可靠性需求

  Cache的"雪崩"問題讓人糾結(jié)

  Cache面臨著快速恢復(fù)的挑戰(zhàn)

• 開發(fā)成本需求

  Cache和DB的一致性維護(hù)成本越來越高(先清理DB, 再清理緩存, 不行啊, 太慢了!)

  開發(fā)需要跟上不斷涌入的產(chǎn)品需求

  硬件成本最貴的就是數(shù)據(jù)庫(kù)層面的機(jī)器,基本上比前端的機(jī)器要貴幾倍,主要是IO密集型,很耗硬件；

• 維護(hù)性復(fù)雜

  一致性維護(hù)成本越來越高；

  BerkeleyDB使用B樹,會(huì)一直寫新的,內(nèi)部不會(huì)有文件重新組織；這樣會(huì)導(dǎo)致文件越來越大；大的時(shí)候需要進(jìn)行文件歸檔,歸檔的操作要定期做；

  這樣,就需要有一定的down time；

基于以上考慮, 選擇了Redis

第三：Redis 在新浪微博中的應(yīng)用

Redis簡(jiǎn)介

1. 支持5種數(shù)據(jù)結(jié)構(gòu)

支持strings, hashes, lists, sets, sorted sets

string是很好的存儲(chǔ)方式,用來做計(jì)數(shù)存儲(chǔ).sets用于建立索引庫(kù)非常棒；

2. K-V 存儲(chǔ) vs K-V 緩存

新浪微博目前使用的98%都是持久化的應(yīng)用,2%的是緩存,用到了600+服務(wù)器

Redis中持久化的應(yīng)用和非持久化的方式不會(huì)差別很大：

非持久化的為8-9萬(wàn)tps,那么持久化在7-8萬(wàn)tps左右；

當(dāng)使用持久化時(shí),需要考慮到持久化和寫性能的配比,也就是要考慮redis使用的內(nèi)存大小和硬盤寫的速率的比例計(jì)算；

3. 社區(qū)活躍

Redis目前有3萬(wàn)多行代碼, 代碼寫的精簡(jiǎn),有很多巧妙的實(shí)現(xiàn),作者有技術(shù)潔癖

Redis的社區(qū)活躍度很高,這是衡量開源軟件質(zhì)量的重要指標(biāo),開源軟件的初期一般都沒有商業(yè)技術(shù)服務(wù)支持,如果沒有活躍社區(qū)做支撐,一旦發(fā)生問題都無處求救；

Redis基本原理

redis持久化(aof) append online file：

寫log(aof), 到一定程度再和內(nèi)存合并. 追加再追加, 順序?qū)懘疟P, 對(duì)性能影響非常小

1. 單實(shí)例單進(jìn)程

Redis使用的是單進(jìn)程,所以在配置時(shí),一個(gè)實(shí)例只會(huì)用到一個(gè)CPU；

在配置時(shí),如果需要讓CPU使用率最大化,可以配置Redis實(shí)例數(shù)對(duì)應(yīng)CPU數(shù), Redis實(shí)例數(shù)對(duì)應(yīng)端口數(shù)(8核Cpu, 8個(gè)實(shí)例, 8個(gè)端口), 以提高并發(fā):

單機(jī)測(cè)試時(shí), 單條數(shù)據(jù)在200字節(jié), 測(cè)試的結(jié)果為8~9萬(wàn)tps；

2. Replication

過程: 數(shù)據(jù)寫到master–>master存儲(chǔ)到slave的rdb中–>slave加載rdb到內(nèi)存.

存儲(chǔ)點(diǎn)(save point): 當(dāng)網(wǎng)絡(luò)中斷了, 連上之后, 繼續(xù)傳.

Master-slave下第一次同步是全傳,后面是增量同步；、

3. 數(shù)據(jù)一致性

長(zhǎng)期運(yùn)行后多個(gè)結(jié)點(diǎn)之間存在不一致的可能性；

開發(fā)兩個(gè)工具程序：

1.對(duì)于數(shù)據(jù)量大的數(shù)據(jù),會(huì)周期性的全量檢查；

2.實(shí)時(shí)的檢查增量數(shù)據(jù),是否具有一致性；

對(duì)于主庫(kù)未及時(shí)同步從庫(kù)導(dǎo)致的不一致,稱之為延時(shí)問題；

對(duì)于一致性要求不是那么嚴(yán)格的場(chǎng)景,我們只需要要保證最終一致性即可；

對(duì)于延時(shí)問題,需要根據(jù)業(yè)務(wù)場(chǎng)景特點(diǎn)分析,從應(yīng)用層面增加策略來解決這個(gè)問題；

例如：

1.新注冊(cè)的用戶,必須先查詢主庫(kù)；

2.注冊(cè)成功之后,需要等待3s之后跳轉(zhuǎn),后臺(tái)此時(shí)就是在做數(shù)據(jù)同步.

第四：分布式緩存的架構(gòu)設(shè)計(jì)

1.架構(gòu)設(shè)計(jì)

由于redis是單點(diǎn),項(xiàng)目中需要使用,必須自己實(shí)現(xiàn)分布式.基本架構(gòu)圖如下所示

2.分布式實(shí)現(xiàn)

通過key做一致性哈希,實(shí)現(xiàn)key對(duì)應(yīng)redis結(jié)點(diǎn)的分布.

一致性哈希的實(shí)現(xiàn)：

l hash值計(jì)算：通過支持MD5與MurmurHash兩種計(jì)算方式,默認(rèn)是采用MurmurHash,高效的hash計(jì)算.

l 一致性的實(shí)現(xiàn)：通過Java的TreeMap來模擬環(huán)狀結(jié)構(gòu),實(shí)現(xiàn)均勻分布

3.client的選擇

對(duì)于jedis修改的主要是分區(qū)模塊的修改,使其支持了跟據(jù)BufferKey進(jìn)行分區(qū),跟據(jù)不同的redis結(jié)點(diǎn)信息,可以初始化不同的 ShardInfo,同時(shí)也修改了JedisPool的底層實(shí)現(xiàn),使其連接pool池支持跟據(jù)key,value的構(gòu)造方法,跟據(jù)不同 ShardInfos,創(chuàng)建不同的jedis連接客戶端,達(dá)到分區(qū)的效果,供應(yīng)用層調(diào)用

4.模塊的說明

l 臟數(shù)據(jù)處理模塊,處理失敗執(zhí)行的緩存操作.

l 屏蔽監(jiān)控模塊,對(duì)于jedis操作的異常監(jiān)控,當(dāng)某結(jié)點(diǎn)出現(xiàn)異常可控制redis結(jié)點(diǎn)的切除等操作.

整個(gè)分布式模塊通過hornetq,來切除異常redis結(jié)點(diǎn).對(duì)于新結(jié)點(diǎn)的增加,也可以通過reload方法實(shí)現(xiàn)增加.(此模塊對(duì)于新增結(jié)點(diǎn)也可以很方便實(shí)現(xiàn))

對(duì)于以上分布式架構(gòu)的實(shí)現(xiàn)滿足了項(xiàng)目的需求.另外使用中對(duì)于一些比較重要用途的緩存數(shù)據(jù)可以單獨(dú)設(shè)置一些redis結(jié)點(diǎn),設(shè)定特定的優(yōu)先級(jí).另外對(duì) 于緩存接口的設(shè)計(jì),也可以跟據(jù)需求,實(shí)現(xiàn)基本接口與一些特殊邏輯接口.對(duì)于cas相關(guān)操作,以及一些事物操作可以通過其watch機(jī)制來實(shí)現(xiàn).

另外推薦javaweb分布式架構(gòu),希望可以幫助到大家：

源碼地址：http://minglisoft.cn/technology