（一）redis技術(shù)的使用：

redis真的是一個很好的技術(shù)，它可以很好的在一定程度上解決網(wǎng)站一瞬間的并發(fā)量，例如商品搶購秒殺等活動。。。

redis之所以能解決高并發(fā)的原因是它可以直接訪問內(nèi)存，而以往我們用的是數(shù)據(jù)庫(硬盤),提高了訪問效率,解決了數(shù)據(jù)庫服務(wù)器壓力。

為什么redis的地位越來越高，我們?yōu)楹尾贿x擇memcache，這是因?yàn)閙emcache只能存儲字符串，而redis存儲類型很豐富（例如有字符串、LIST、SET等），memcache每個值最大只能存儲1M,存儲資源非常有限,十分消耗內(nèi)存資源,而redis可以存儲1G,最重要的是memcache它不如redis安全,當(dāng)服務(wù)器發(fā)生故障或者意外關(guān)機(jī)等情況時,redsi會把內(nèi)存中的數(shù)據(jù)備份到硬盤中,而memcache所存儲的東西全部丟失;這也說明了memcache不適合做數(shù)據(jù)庫來用,可以用來做緩存。

下面用redis解決瞬間秒殺活動來說明：

下面這個程序模擬了20w人一瞬間涌入這個頁面進(jìn)行秒殺,能夠秒殺成功的只有500人,我們把先進(jìn)來的用戶放入redis隊(duì)列中,當(dāng)隊(duì)列中的用戶達(dá)到500時，后來用戶就轉(zhuǎn)到秒殺結(jié)束頁面。這里用隨機(jī)數(shù)來表示不同的用戶。

這里我們可以看到秒殺成功的第一個用戶的id是208522,秒殺成功的最后一個用戶是176260,參與秒殺人數(shù)總共是20w。（讓大家注意這些的原因是為了驗(yàn)證下面的準(zhǔn)確性）。

接下來我們依次從隊(duì)列中把秒殺成功的500個用戶取出來并觀察第一個用戶和最后一個用戶是否跟之前的記錄值一樣

我們可以看到從秒殺成功隊(duì)列中依次取出的第一個用戶id是208522，最后一個用戶是176260，可以看出結(jié)果是很準(zhǔn)確的。

redis在解決高并發(fā)這方面的能力是真的挺不錯的。

（二）Redis高并發(fā)可能產(chǎn)生的問題，解決：

1、 如果redis宕機(jī)了，或者鏈接不上，怎么辦？

解決方法：

①配置主從復(fù)制，配置哨兵模式（相當(dāng)于古代門派的長老級別可以選擇掌門人的權(quán)利），一旦發(fā)現(xiàn)主機(jī)宕機(jī)，讓下一個從機(jī)當(dāng)做主機(jī)。

②如果最壞的情況，只能關(guān)閉Redis連接，去往數(shù)據(jù)庫連接。但由于數(shù)據(jù)量大，這樣SQL數(shù)據(jù)庫也會宕掉的。

2、 如果redis緩存在高峰期到期失效，在這個時刻請求會向雪崩一樣，直接訪問數(shù)據(jù)庫如何處理？

設(shè)置條件查詢判斷，判斷redis緩存里是否有數(shù)據(jù)，如果沒有，則去往數(shù)據(jù)庫連接。當(dāng)然要加分布式鎖，利用redis的單線程+多路IO復(fù)用技術(shù)，原子性原理，讓其它的線程請求等待，假若第一個線程進(jìn)去獲取到分布式鎖在查詢數(shù)據(jù)的途中宕掉了，不能讓其它線程一直等待，設(shè)置等待一定時間判斷是否取回?cái)?shù)據(jù)，如果沒有，遞歸調(diào)用自己的方法讓第二個線程繼續(xù)拿分布式鎖查詢數(shù)據(jù)庫。當(dāng)?shù)诙€鎖從數(shù)據(jù)庫拿到數(shù)據(jù)時，把數(shù)據(jù)值設(shè)置到redis數(shù)據(jù)庫緩存中，設(shè)置失效時間，避免占內(nèi)存，方便使用提高效率。

3. 如果用戶不停地查詢一條不存在的數(shù)據(jù)，緩存沒有，數(shù)據(jù)庫也沒有，那么會出現(xiàn)什么

如果數(shù)據(jù)不存在，緩存中沒有，數(shù)據(jù)庫也沒有，當(dāng)然如果不設(shè)置判斷，會一直調(diào)用數(shù)據(jù)庫，使數(shù)據(jù)庫效率降低，訪問量大時甚至?xí)礄C(jī)。

解決方案：從數(shù)據(jù)庫查詢，如果數(shù)據(jù)庫沒有，則返回值為Null，判斷數(shù)據(jù)庫返回的值，如果為Null，則自定義把標(biāo)識的字段存到Redis中，用key,value的方法，jedis.setex(key,"empty")，設(shè)置失效時間跟具體情況而定，然后調(diào)用String json=jedis.get(key),判斷是否獲取的值"empty".equal(json),如果相等，則拋出自定義異常，給用戶提示，或者直接return null。這樣用戶再次查詢的時候由于先從reids緩存中查詢，redis會有對應(yīng)的Key獲取之前設(shè)置的value值，這樣就不會再次調(diào)用數(shù)據(jù)庫，影響效率等問題。

具體代碼如下：

@Override

redis的缺點(diǎn)有哪些?

是數(shù)據(jù)庫容量受到物理內(nèi)存的限制,不能用作海量數(shù)據(jù)的高性能讀寫,因此Redis適合的場景主要局限在較小數(shù)據(jù)量的高性能操作和運(yùn)算上。

redis的缺點(diǎn)有哪些?

是數(shù)據(jù)庫容量受到物理內(nèi)存的限制,不能用作海量數(shù)據(jù)的高性能讀寫,因此Redis適合的場景主要局限在較小數(shù)據(jù)量的高性能操作和運(yùn)算上。 Redis較難支持在線擴(kuò)容，在集群容量達(dá)到上限時在線擴(kuò)容會變得很復(fù)雜。為避免這一問題，運(yùn)維人員在系統(tǒng)上線時必須確保有足夠的空間，這對資源造成了很大的浪費(fèi)。

總結(jié)

以上是生活随笔為你收集整理的gin redis 链接不上_Redis 高并发问题,及解决方案！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。