Redis-01Redis概述
文章目錄
- 思維導圖
- Redis概述
- Redis的版本
- Redis的部分應用場景
- 緩存
- 高速讀／寫
- 安裝 Redis
- Windows下安裝Redis
- linux下安裝Redis
- 數據類型
- 在線網站
思維導圖
Redis概述
在傳統的 Java Web 項目中， 使用數據庫進行存儲數據，弊端主要來自于性能方面。由于數據庫持久化數據主要是面向磁盤，而磁盤的讀／寫比較慢.
如果不存在高并發，因此往往沒有瞬間需要讀／寫大量數據的要求，這 個時候使用數據庫進行讀／寫是沒有太大的問題的，
在互聯網中，往往存在大數據量的 需求 ，比如一些商品搶購的場景，或者是主頁訪問量瞬間較大的時候， 一瞬間成千上萬的 請求就會到來 ，需要系統在極短的時間內完成成千上萬次的讀／寫操作，這個時候往往不是 數據庫能夠承受的，極其容易造成數據庫系統癱瘓，最終導致服務巖機的嚴重生產問題。
為了克服這些問題， Java Web 項目往往就引入了 NoSQL 技術， NoSQL 工具也是一種簡易的數據庫，它主要是一種基于內存的數據庫，并提供一定的持久化功能。Redis 和MongoDB 是當前使用最廣泛的 NoSQL。 我們這里來探討Redis 。
Redis可以支持每秒十幾萬次的讀／寫操作，其性能遠超數據庫，并且支持集群、 分布式、 主從同步等配置，原則上可以無限擴展，讓更多的數據存儲在內存中，還能支持一定的事務能力，這在高并發訪問的場景下保證數據安全和一致性非常重要。
#Redis的優點
基于 ANSI C 語言編寫的，接近于匯編語言的機器語言，運行十分快速
基于于內存的讀／寫，速度自然比數據庫的磁盤讀／寫要快得多
數據庫結構只有 6 種數據類型，數據結構比較簡單，因此規則較少，而數據庫則是范式，完整性、規范性需要考慮的規則比較多，處理業務會比較復雜
Redis的版本
Redis借鑒了Linux操作系統對于版本號的命名規則： 版本號第二位如果是奇數， 則為非穩定版本（例如2.7、 2.9、 3.1） ， 如果是偶數， 則為穩定版本（例如2.6、 2.8、 3.0、 3.2、4.0） 。
Redis的部分應用場景
- 緩存 ： 合理地使用緩存不僅可以加快數據的訪問速度， 而且能夠有效地降低后端數據源的壓力，同時 Redis提供了鍵值過期時間設置， 并且也提供了靈活控制最大內存和內存溢出后的淘汰策略。
- 高速讀／寫的場合使用它快速讀／寫： 比如一些需要進行商品搶購和搶紅包的場合，把這些需要高速讀／寫的數據 ， 緩存到 Redis 中，而在滿足一定的條件下，觸發這些緩存的數據寫入數據庫中
- 排行榜系統： 按照熱度排名的排行榜， 按照發布時間的排行榜， 按照各種復雜維度計算出的排行榜， Redis提供了列表和有序集合數據結構， 合理地使用這些數據結構可以很方便地構建各種排行榜系統
- 計數器應用：視頻網站有播放數、 電商網站有瀏覽數， 為了保證數據的實時性， 每一次播放和瀏覽都要做加1的操作，Redis天然支持計數功能而且計數的性能也非常好
- 社交網絡：贊/踩、 粉絲、 共同好友/喜好、 推送、，Redis提供的數據結構可以相對比較容易地實現這些功能
- 消息隊列系統： Redis提供了發布訂閱功能和阻塞隊列的功能， 雖然和專業的消息隊列比還不夠足夠強大， 但是對于一般的消息隊列功能基本可以滿足
緩存
一般而言在使用Redis 存儲的時候，需要從 3 個方面進行考慮。
業務數據常用嗎？命中率如何？如果命中率很低，就沒有必要寫入緩存。
該業務數據是讀操作多，還是寫操作多 ，如果寫操作多 ，頻繁需要寫入數據庫 ，也沒有必要使用緩存。
業務數據大小如何？如果要存儲幾百兆字節的文件，會給緩存帶來很大的壓力，有沒有必要？
在考慮過這些問題后，如果覺得有必要使用緩存，那么就使用它 。使用 Redis 作為緩 存的讀取邏輯如下：
-
當第一次讀取數據的時候，讀取 Redis 的數據就會失敗，此時會觸發程序讀取數據庫，把數據讀取出來，并且寫入 Redis 。
-
當第二次及以后讀取數據時，就直接讀取 Redis ， 讀到數據后就結束了流程，速度就大大提高 。
從上面的分析可知，大部分的操作是讀操作，使用 Redis 應對讀操作，速度就會十分迅速，同時也降低了對數據庫的依賴， 大大降低了數據庫的負擔。
分析了讀操作的邏輯后，下面再來分析寫操作的流程，
從上面的流程可以看出，更新或者寫入的操作，需要多個 Redis 的操作 。 如果業務數據寫次數遠大于讀次數沒有必要使用 Redis。如果是讀次數遠大于寫次數， 則使用 Redis 就有其價值了，因為寫入 Redis 雖然要消耗一定的代價，但是其性能良好，相對數據庫而言，幾乎可以忽略不計 。
高速讀／寫
在互聯網的應用中，往往存在一些需要高速讀／寫的場合，比如商品的秒殺，搶紅包，淘寶、京東的雙十一活動或者春運搶票等。這類場合在一個瞬間成千上萬的請求就會達到服務器，如果使用的是數據庫， 一個瞬間數據庫就需要執行成千上萬的 SQL，很容易造成數據庫的瓶頸，嚴重的會導致數據庫癱瘓，造成 Java Web 系統服務崩潰。
在這樣的場合的應對辦法往往是考慮異步寫入數據庫，而在高速讀／寫的場合中單單使用 Redis 去應對， 把這些需要高速讀／寫的數據 ， 緩存到 Redis 中，而在滿足一定的條件下，觸發這些緩存的數據寫入數據庫中.
先看看一次請求操作的流程圖 如下：
當一個請求達到服務器，只是把業務數據先在 Redi s 讀／寫，而沒有進行任何對數據庫的操作，換句話說系統僅僅是操作 Redis 緩存，而沒有操作數據庫，這個速度就比操作數據庫要快得多，從而達到需要高速響應的效果。
但是一般緩存不能持久化，或者所持久化的數據不太規范，因此需要把這些數據存入數據庫 ，所以在一個請求操作完 Redis 的讀／寫后，會去判斷該高速讀／寫的業務是否結束。這個判斷的條件往往就是秒殺商 品剩余個數為 0，搶紅包金額為 0，如果不成立，則不會操作數據庫；如果成立，則觸發事件將 Redis 緩存的數據以批量的形式一次性寫入數據庫，從而完成持久化的工作。
假設面對的是一個商品秒殺的場景，從上面的流程看， 一個用戶搶購商品，絕大部分的場合都是在操作內存數據庫 Redis ， 而不是磁盤數據庫，所以其性能更為優越。只有在商品被搶購一空后才會觸發系統把 Redis 緩存的數據寫入數據庫磁盤中 ， 這樣系統大部分的操作基于內存，就能夠在秒殺的場合高速響應用戶的請求，達到快速應答。
而現實中這種需要高速響應的系統會比上面的分析更復雜 ， 因為**這里沒有討論高并發下的數據安全和一致性問題，沒有討論有效請求和無效請求 、 事務一致性等諸多問題**，這些后續獨立討論它 。
安裝 Redis
Windows下安裝Redis
請參考 實戰SSM_O2O商鋪_45【Redis緩存】配置Redis在Service層加入緩存
linux下安裝Redis
Redis-02Redis在linux下的安裝及常見問題
數據類型
Redis 是 一種基于內存的數據庫，并且提供 一定 的 持 久化功能，它 是一 種 鍵值( key-value ）數據庫，使用 key 作為索引找到 當前緩存的數據， 并且返回給程序調用 者。
當前的 Redis （redis3.0）支持 6 種數據類型，它們分別是字符串（ String ） 、列表（ List）、集合（ set ）、哈希結構（ hash ）、有序集合（ zset）和基數（ HyperLogLog ）
| STRING （字符串） | 可以是保存字符串、整數和浮點數 | 可以對字符串進行操作 ，比如增加字符或在子串，如果是整數或者浮點數 ， 可以實現計算，比如自增等 |
| LIST （ 列表） | 它是一個鏈表，它 的每一個節點都包 含一個字符串 | Redis支持從鏈表的兩端插入或者彈出節點，或在通過偏移對它進行裁剪；還可以讀取一個或者多個節點， 根據條件刪除或者查找節點等 |
| SET （集合） | 它是一個收集器，但是是無序的,在它里面每一個元素都是一個字符串，而且是獨一無二 , 各不相同的 | 可以新增、讀取、刪除單個元素 ； 檢測一個元索是否在集合中，計算它和1其他集合的交集并集和差集等；隨機從集合中讀取元素 |
| HASH ( 哈希散列表） | 它類似于 Java 語言中的 Map，是一個鍵值對應的無序列表 | 可以附、刪 、 查、改單個鍵值對， 也可以獲取所有的鍵值對 |
| ZSET （有序集合〉 | 它是一個有序的集合 ， 可以包含字符串、整數、浮點數、分值（ score ） ， 元素的排序是依據分值的大小來決定的 | 可以地、刪、查、改元素，根據分值的泡因或者成員來獲取對應的元素 |
| HyperLogLog （基數） | 它的作用是計算主復的值， 以確定存儲的數量 | 只提供基數的運算，不提供返回的功能 |
如上表格粗略描述了 Redis 的 6 種數據類型 ， 并簡要說明了它們的作用，后面還會詳細介紹它們的數據結構和常用 Redis 命令 。
此外， Red is 還支持一些事務 、 發布訂閱消息模式、 主從復制、持久化等。
在線網站
http://try.redis.io/
總結
以上是生活随笔為你收集整理的Redis-01Redis概述的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 实战SSM_O2O商铺_48【用户登录】
- 下一篇： Redis-04Redis数据结构--哈