-
1 # 夕陽雨晴
-
2 # 此生唯一
redis算是用的最多的key-value型快取元件了！
因為使用了key-value型，所以存取效率極好，簡單來說就類似JAVA中的hashMap，不過是用整個伺服器記憶體來當做map，但是redis的資料可以透過配置指令儲存到硬碟(同步儲存save，非同步儲存bgsave)！
redis是單執行緒模式，這能保證redis中存取的資料庫絕對執行緒安全，同時，因為避免多執行緒之間切換的開銷，redis的存取效能跟使用多執行緒的memcache在一定程度上旗鼓相當，都非常高的效能，不過redis的value支援G級別的資料，能用來存放大文字等，這是memcache不能做到的。。
為了進一步提升redis的穩定性和存取效能，redis支援叢集，具體搭建方式，可參考我之前的一篇回答！
那麼redis在實際的開發中，主要用來做什麼呢？
1，資料存取:無需多說！
2，加鎖:因為redis是單執行緒的，提供的比如incr，setnx等方法均可以用來當做鎖使用！
3，秒殺系統:商品存佇列，請求進來進行匹配，然後異步出單即可！
4，計數器:對同一個key的value計數即可！
5，超時問題:比如頁面訪問超時啥的，頁面訪問介面的時候持續更新某個設定值，超過某個時間段再訪問，則超時！
當然，redis在使用過程中會存在持久化失敗，快取擊穿，擴容困難等問題，不過無論如何，redis都是一款最值得用的快取工具！
-
3 # 一個存在感小透明
不僅僅是Java工程師，基本上所有平臺開發工程師都需要使用redis，主要是作為代替memcached的快取。
由於涉及到底層，所以Redis是用C語言程式設計的一種能夠快速讀寫的工具。但是實際使用中，Java，PHP，Python等程式語言，都是可以使用Redis的，這種良好的語言擴充套件性，使Redis快速在原本memcached一家獨大的快取領域裡攻城略地，並迅速劃定了自己的圈地。
Redis最突出的優點就是讀寫速度極快，既可以作為Server與MySQL之間的快取，也可以作為分散式集群系統中多臺Server之間的快取。
接下來我們就由上述兩種情況來簡單介紹。
Server與MySql之間的快取眾所周知，MySQL雖然藉助索引能夠提高查詢速度，但是如果使用者所有的讀請求都到MySQL中去拿的話，還是會有很多的查詢與讀取消耗。這種場景，如果將一段時間內頻繁被讀取的資料提前放到redis中，利用其快速讀取優勢，一方面減少了MySQL的讀庫壓力，一方面也能夠加速使用者側感受到的頁面訪問速度。比如情人節快到了，大眾點評直接將花店，送花外賣等資訊放到快取裡，絕對能夠大幅減少MySQL的讀取壓力。
此外，在一些場景下，有些資料在完全入庫之前，還需要數次的修改。中間的修改過程，如果每次都要去修改MySQL，也是對MySQL增加了讀寫壓力，這時候，如果使用Redis來儲存中間態，就能進一步緩解MySQL的讀寫壓力，從而提高整體服務的穩定性。
server與server之間的快取出於擴充套件性和穩定性方面的考慮，一些叢集規模的服務，通常會有多臺相同功能的Tomcat。這樣就有一種可能，假如一個任務由2個步驟組成，第一個步驟是使用者發起任務，第二個步驟是Tomcat反饋後用戶點選確認才會繼續處理。此時，有一個使用者發來一個任務，這個任務由A Tomcat處理了第一步，然後反饋給了使用者，使用者點選了確認後這個請求卻被髮送給了B Tomcat，作為B Tomcat也是一臉矇蔽，由於並不能與A Tomcat相互通訊，它並不知道前因後果。
這時候假如沒有server之間的快取，這個任務就進行不下去了。
有了server之間的快取，A Tomcat在處理完第一個步驟後，會把自己做的事情記錄在redis中，然後等第二個步驟需要執行的時候，無論請求是給了A還是B，只需要到redis中讀取下上一步的記錄，就能繼續進行了。
這就是server間快取的意義。
-
4 # 梨有奶香味
Redis作為快取，有豐富的資料型別：String，List, Hash , Set, Sorted set, Bitmap 等。支援事務和Pipeline, 有光房的叢集解決方案：哨兵（Sentinel）和叢集 （Cluster），前者不能水平擴充套件。其主要的應用場景：
1、熱點資料的快取
由於redis訪問速度塊、支援的資料型別比較豐富，所以redis很適合用來儲存熱點資料，結合expire，設定過期時間。
2、分散式鎖主要利用redis的setnx命令，setnx："set if not exists"。如果不存在則成功設定快取同時返回1，否則返回0 ；假如有10臺機器，某一時刻你只希望僅有一臺機器執行任務，可以透過這種方式，槍鎖成功的機器執行。
3、計數器
4、訊息佇列
redis有list push和list pop這樣的命令，所以能夠很方便的執行佇列操作 ，例如 email 的傳送佇列、等待被其他應用消費的資料佇列，Redis 可以輕鬆而自然的創建出一個高效的佇列
end ～
回覆列表
在分散式和微服務等架構遍地開花的實踐中，Redis始終作為分散式快取的首選，可謂經久不衰、獨樹一幟。Redis基於記憶體執行並支援持久化的NoSQL資料庫，是當前最熱門的NoSql資料庫之一，也被人們稱為資料結構伺服器。
而為何要使用Redis呢？Redis不僅僅支援簡單的k/v型別的資料，同時還提供list，set，zset，hash等資料結構的儲存。Redis支援master-slave(主-從)模式應用。Redis支援資料持久化，可以將記憶體中的資料保持在磁碟中，重啟的時候可以再次載入進行使用。Redis單個value的最大限制是1GB，memcached只能儲存1MB的資料。基於種種原因，Redis成為我們快取架構的首選，而我在開啟碼農生涯時，就接觸到Redis，只是當時的使用比較簡單。
最開始時，因網際網路化團隊初建，各種所需要的中介軟體都需要自己搭建，包含Redis，而我們使用Docker搭建Redis叢集，採用主從的Redis架構，再使用Sentinel（哨兵）模式來監控該Redis叢集，使用也是透過Sentinel來使用。透過Spring或Spring Boot的哨兵連線方式連線Redis，註冊成Bean，然後使用序列化的Key-Value結構來快取所需要的資料。而因領導的風格原因，我們也僅僅被允許採用Key-Value的基礎功能來進行Redis操作。至於其中的原因，也沒有深究。
而隨後，跳槽到現公司，其將Redis作為基礎服務進行封裝，而業務團隊僅透過加密串即可進行直接連線，其背後的可高用、主從分片、災備等均由基礎架構團隊負責。基礎架構團隊提供的操作方式，就不僅僅限於使用Key-Value的get、set、delete等方法，而幾乎完全提供了Redis的所有命令，包含inc、sadd等計數、集合操作。當然，有了這些，對程式設計師的要求更高，要在合適的場景中選擇恰當的命令進行操作，也不是一件容易的事。
或許，使用Redis有這樣那樣的原因，但在我看來，最重要的就兩條：其一，它能提高使用者的訪問速度，大量的降低系統響應的TP99；其二，它是主流，大家都在用，而且經過了時間的檢驗，抗住了一個又一個電商大促的業務場景。