redis爲何這麼火該怎麼用

　　最近一些人在介紹方案時，常常會出現redis這個詞，因而不少小夥伴百度完redis也就以爲它是一個緩存，而後項目裏面把數據丟進去完事，甚至有例如將實體屬性拆分塞進redis hash裏面的奇怪用法等等！緣由是什麼呢？你們以爲redis火，使用了redis項目就是高大上的，因而無論三七二十一，項目裏用上強塞一個用上！這裏本人想說的是你知道redis爲何這麼火麼，應該怎麼用麼？下面帶着本人拙建，簡單分析一下：

1、redis性能

　　redis是一個基於內存hash結構的緩存型db，同mysql等傳統數據庫對比性能時，讀操做在1k左右數據的時候相差基本上在10-100倍的差異，寫入的性能差異就更大了，下面是一些測試數據

 

　　經過對redis的set、get命令測試觀察，redis的讀寫性能在單線程下能夠達到每秒2W左右；經過對mysql的select和insert、delete語句測試，mysql的讀性能可達到5000每秒左右，寫性能可到達3000每秒，讀性能基本是寫性能的2倍。而上述測試是基於redis單實例、單鏈接的狀況，若是根據cpu核數來增長redis實例，而且使用pie和多鏈接，這個數據還能輕鬆的再上一個數量級~也可參見一下網上其餘人發佈的一些redis性能測試，例如：https://www.sohu.com/a/29865580_219700。

2、redis緩存

　　上面分析了redis的性能很是高，基本上同機器配置下徹底吊打傳統sql，甚至nosql的mongodb等。即便這樣redis也只是一個分佈式緩存，或者說是分佈式緩存數據庫，那麼redis確定不能像傳統數據同樣，動不動放個幾T的數據，通常都是用來放熱數據或者體量小的數據，其餘的數據仍是使用隊列經過後臺服務放到sql db裏面；另外根據redis的特性，建議服務器cpu核心數要留個1/4，每一個實例的內存最得多出1/2；假如24核的120G的服務器，建議部署18個reids實例，每一個實例5G的內存，實際使用不要超過3G的數據量~reids是緩存就繼承了緩存的優缺點，性能高是優勢，缺點：緩存穿透、緩存雪崩。

　　1.緩存穿透：緩存穿透是指查詢一個必定不存在的數據，因爲緩存是不命中時被動寫的，而且出於容錯考慮，若是從存儲層查不到數據則不寫入緩存，這將致使這個不存在的數據每次請求都要到存儲層去查詢，失去了緩存的意義。在流量大時，可能DB就掛了。

 

　　解決辦法就是將從db過來的返回值進行緩存，根據實際狀況從新加熱，若db返回是空則緩存幾分鐘就能夠了。

 　　2.緩存雪崩：在咱們設置緩存時採用了相同的過時時間或者緩存服務器因某些緣由沒法使用時，致使緩存在某一時刻同時失效，請求所有轉發到DB，DB瞬時壓力太重雪崩。

　　解決辦法過時時間上增長一個範圍的隨機值，使用Redis Sentinel 和 Redis Cluster 實現高可用，另增設一個壽命更短的本機緩存來解決redis分佈緩存搶修時的問題。

　　在發生不管是緩存穿透仍是緩存雪崩，都建議使用隊列來排隊、拒絕大量請求涌入和分佈式互斥鎖來避免後端數據服務被衝擊，防止已有的數據出現問題。

3、總結

　　redis很強大，不管是哨兵式集羣仍是自帶的redis cluster方式集羣，可是必定要對redis瞭解清楚才能更好的使用~