最近一些人在介紹方案時，經常會出現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緩存
上面分析了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了解清楚才能更好的使用~