Redis的使用場景與使用Redis的原因
Redis 不是全能工
在講 Redis 緩存時(shí),我們會(huì)聯(lián)想到 Memcache 和 Redis 的優(yōu)缺點(diǎn)有哪些，其實(shí) Redis 和 Memcache 并不能進(jìn)行比較.一個(gè)是既能做緩存又能做其他的事情,一個(gè)是僅僅只做緩存。常常我們會(huì)把兩個(gè)聯(lián)想在一起主要是因?yàn)?Redis 廣泛應(yīng)用在緩存，那 Redis 哪些能干?哪些不能干呢?
Redis 能干的事情 Redis 緩存在日常開發(fā)中廣泛應(yīng)用，在提高服務(wù)器性能方面也有顯著的效果
排行榜 ? 如果使用關(guān)系型數(shù)據(jù)庫非常麻煩，而利用redis的sortSet數(shù)據(jù)結(jié)構(gòu)能夠非常方便搞定 計(jì)算器/限速器 ?利用Redis中的原子性的自增操作 ?我們可以統(tǒng)計(jì)類似用戶點(diǎn)贊數(shù) ?用戶訪問數(shù)等 ?這類操作如果用MySQL數(shù)據(jù)庫會(huì)造成非常大的服務(wù)器壓力，限流器比較典型的應(yīng)用場景就是限制某個(gè)API的頻率 ?常用應(yīng)用場景有 ?限購 防止用戶瘋狂點(diǎn)擊造成服務(wù)器的壓力 好友關(guān)系 ?利用集合的一些命令 比如求 差集 ?交集 并集等 方便搞定一些共同好友 ?共同愛好的功能。 簡單的消息隊(duì)列 ?除了Redis自身的發(fā)布/訂閱模式 ?我們可以利用List來實(shí)現(xiàn)一個(gè)隊(duì)列機(jī)制 ?比如到貨通知 ?郵件發(fā)送之類的需求 ?不需要高可靠 ?但是會(huì)帶來非常大的DB壓力，完全可以用List來完成異步解耦。 Session共享 默認(rèn)Session是保存在服務(wù)器的文件中，如果是集群服務(wù)，同一個(gè)用戶過來可能落在不同機(jī)器上，這就會(huì)導(dǎo)致用戶頻繁登錄 采用Redis保存Session后 ?無論用戶落在那臺(tái)機(jī)器上都能夠獲取到對(duì)應(yīng)的Session信息上
Redis不能干哪些事情
Redis感覺能干的事情特別多 ?但是不是萬能的 ?合適的地方用它事半功倍 ?如果濫用可能導(dǎo)致系統(tǒng)的不穩(wěn)定，成本的增高等問題
用Redis去保存用戶的基本信息，雖然它能夠支持持久化，但是它的持久化方案并不能保證數(shù)據(jù)絕對(duì)的落地，并且還可能帶來Redis性能下降，因?yàn)槌志没^頻繁會(huì)增大Redis服務(wù)的壓力 簡單來講就是數(shù)據(jù)量過大 ?數(shù)據(jù)訪問頻率低的業(yè)務(wù)不適合使用Redis ?數(shù)據(jù)太大吧會(huì)增加成本 ?訪問頻率太低 ?保存在內(nèi)存中純屬浪費(fèi)資源
Redis的優(yōu)點(diǎn)
Redis緩存速度快 ?完全基于內(nèi)存 ?使用C語言實(shí)現(xiàn) ?網(wǎng)絡(luò)層使用EPoll解決高并發(fā)問題，單線程模型避免不必要的上下文切換機(jī)器競爭條件
注意：單線程僅僅是說在網(wǎng)絡(luò)請(qǐng)求這一模塊上用一個(gè)請(qǐng)求處理客戶端的請(qǐng)求，像持久化它就會(huì)重開一個(gè)線程/進(jìn)程去進(jìn)行處理
Redis 有 8 種數(shù)據(jù)類型，當(dāng)然常用的主要是 String、Hash、List、Set、 SortSet 這 5 種類型
除了提供的豐富的數(shù)據(jù)類型，Redis 還提供了像慢查詢分析、性能測試、Pipeline、事務(wù)、Lua自定義命令、Bitmaps、HyperLogLog、發(fā)布/訂閱、Geo 等個(gè)性化功能。