redis為什麼這麼火該怎麼用

　　最近一些人在介紹方案時，經常會出現redis這個詞，於是很多小夥伴百度完redis也就覺得它是一個緩衝，然後項目裡面把資料丟進去完事，甚至有例如將實體屬性拆分塞進redis hash裡面的奇怪用法等等！原因是什麼呢？大家覺得redis火，使用了redis項目就是高大上的，於是不管三七二十一，項目裡用上強塞一個用上！這裡本人想說的是你知道redis為什麼這麼火麼，應該怎麼用嗎？下面帶著本人拙建，簡單分析一下：

一、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效能測試，例如：www.sohu.com/a/29865580_219700。

二、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分布緩衝搶修時的問題。

　　在發生無論是緩衝穿透還是緩衝雪崩，都建議使用隊列來排隊、拒絕大量請求湧入和分布式互斥鎖來避免後端資料服務被衝擊，防止已有的資料出現問題。

三、總結

　　redis很強大，無論是哨兵式叢集還是內建的redis cluster方式叢集，但是一定要對redis瞭解清楚才能更好的使用~