Redis是什麼？
（全稱：Remote Dictionary Server 遠程字典服務）是一個開源的使用ANSI C語言編寫、支持網絡、可基於內存亦可持久化的日誌型、Key-Value數據庫，並提供多種語言的API。
Redis的應用場景
在我們的日常開發中，基本上都是使用數據庫來進行數據存儲，一般的系統中通常不會存在高併發的情況，所以看起來沒什麼問題，但是一旦出現同一時間大量的數據請求來訪問系統，比如搶購，秒殺等等，那這種單一的用數據庫來進行數據的保存的系統會因爲面向磁盤，而又受到磁盤的讀寫速度限制，大量的數據給磁盤帶來的巨大的的壓力，這種情況就和網安界最無解的DDOS攻擊一樣，輕則讓系統卡頓，重則直接宕機。
而redis主要應用的兩個場景就是：
1、用來存儲常用緩存的數據
2、在需要快速讀寫的場景下進行快速讀寫
NoSql技術
爲了解決上述的問題，大多數項目都會引入NoSql技術，這是一種面向內存的數據庫，並且提供了一定的持久化功能，現在流行的NoSql技術有Redis和MongoDB，相比較之下，redis的性能就比較強大了，它可以支持每秒十幾萬次的讀寫操作，其性能遠高於數據庫，並且還支持分佈式，集羣，主從同步等配置，原則上支持無限拓展（實際根據服務器的內存來看，默認開啓16個庫，默認優先使用0號庫），另外redis還支持一定的事務能力，從而在一定程度上保證了在高併發情況下數據的安全性和一致性。
一張圖瞭解集羣，分佈式：
集羣：多個人在一起作同樣的事 。
分佈式 ：多個人在一起作不同的事 。
主從同步：
1、在多臺數據服務器中，只有一臺主服務器，而主服務器只負責寫入數據，不負責外部程序讀取數據。
2、存在多臺從服務器，從服務器不寫入數據，只負責同步主服務器的數據，並讓外部程序讀取數據。
3、主服務器寫入數據後，即刻將寫入數據的命令發送給從服務器，從而使得主從數據同步。
4、應用程序可以隨機讀取某一臺從服務器的數據，這樣就可以分攤讀取數據的壓力。
5、當從服務器不能工作時，整個系統將不受影響；當主服務器不能工作時，可以方便地從從服務器選舉一臺來當主服務器
緩存技術
現在比較流行的緩存技術是redis和memcached，兩者相比：
1、redis擁有“持久化”的特性，雖然兩者都可以做緩存，但是redis還可以做存儲；
2、存儲的數據類型不一樣，memcached僅僅能存儲字符串一種類型，而redis支持5種類型，即字符串，哈希結構，鏈表，集合，有序集合。
緩存應用
在我們日常開發的場景中，讀操作對數據庫的訪問次數遠遠超過寫操作，比例大概在9:1到7:3，當我們對數據庫進行讀操作時，數據庫就會去磁盤把對應的索引取回來，另外如果sql語句很繁瑣，需要多表聯查，而且數據庫的結構設計的很不合理的情況下，並且數據庫裏面沒有建立視圖，那這樣一條語句查詢的時間是很容易讓人暴走的，尤其是當你二開那些無良外包團隊寫的項目的時候，心肌梗塞都能給你憋出來！
但是如果我們把數據放在redis中，也就是直接放在內存當中的話，讓服務器直接從內存中讀取數據，那麼這樣的速度就會快上很多，並且能夠極大地減小數據庫的壓力，系統能夠迅速的反應數據請求，但是這樣直接使用內存進行數據存儲雖然快，但是成本也是比較大的，一般考慮到成本方面的原因，我們只會把常用的一些數據和主要的數據放在redis上面，比如用戶的登錄信息之類的。
如果我們考慮項目是否需要用redis，一般從以下幾個方面考慮：
一、業務數據常用嗎？使用率如何？
如果使用的頻率很低，就沒有必要寫入緩存，還佔用一定的內存
二、該業務是讀操作頻率高，還是寫操作頻率高？
如果是寫操作頻率高，那麼就是頻繁的寫入數據庫。也就沒有必要使用緩存了
三、業務數據的大小如何？
如果業務數據過大，例如要存儲幾百M字節的數據，那如果放到緩存裏面的話，那麼對內存的開銷是十分的巨大的，也不建議使用緩存（谷歌那樣的除外，據說他是把互聯網所有的數據都放在了內存條上面，纔會有如此高效，快速的搜索。。。。。）
如果考慮了上面的一些問題，還是覺得有必要使用緩存的話，那麼就開始選擇redis吧。redis作爲緩存讀取的邏輯如下圖所示：
從上圖我們可以瞭解到：
一、當第一次讀取的時候，讀取redis失敗，然後會從數據庫裏面讀取，讀出來的數據先寫入到redis，然後再去執行後面的程序
二、當從第二次以後開始讀取的時候，因爲在第一次的時候已經寫入了redis，所以讀取redis會成功，然後就直接去執行後面的程序，這樣不僅節省了從數據庫裏面再去讀取的時間，也大大提升了程序執行的效率
這樣在進行讀操作的時候，直接從redis裏面讀取，其操作效率是很高的，而且大大的減少了數據庫的壓力
接下來看一下redis作爲緩存的寫操作是如何運行的
從上面的流程圖我們可以看出來，相對比與普通的寫操作，redis作爲緩存執行寫操作的時候，會多一步更新寫入到redis，當我們的項目裏面寫操作的次數大於讀操作時，我們就沒有必要來使用Redis了，這樣不僅浪費內存，而且程序執行效率還不是很高
瞭解完Redis作爲緩存的應用，我們再來了解一下Redis在高速讀/寫場合下的應用
現在的互聯網中，高併發的情況越來越常見，比如馬上到來的雙11，活動搶購，秒殺等等等等，這些活動都是在瞬間或者某一個時刻有成千上萬甚至上百萬千萬的數據來同時到達服務器的，如果按照單一的從數據庫進行讀寫，再去寫入到磁盤，就算你的服務器再能抗，出現卡頓是在所難免的，甚至如果是小網站的話，直接宕機也不在話下，這麼些大的數據同時阻塞在服務器， 就相當於自己給自己搞了一個巨大的DDOS定時炸彈，造成的影響有多麼的嚴重都是難以想象的
而Redis能夠很輕鬆的應對這樣高併發的場合，下圖是成百上千萬里面的一次請求：
我們來分析一下上圖的操作：
當一個業務請求過來的時候，我們直接在redis進行讀取，然後判斷高速讀寫業務是否已經結束，如果沒有結束的話，就把數據寫入到redis，然後執行下一個業務請求；如果判斷高速讀寫已經結束，通常的判斷條件是搶購的商品數量已經爲0，或者時間已經到了，這樣就把redis存放的緩存數據一次性異步批量的寫入到數據庫，來完成數據的持久化
小結：redis既可以作爲緩存來暫時的存放數據，又可以作爲持久化工具來完成數據的持久化，但是並不是適用於所有的場合，像寫操作的次數大於讀操作的時候，用redis就不合適了，大多數情況下，redis還是能滿足很多需求的，今天主要就是先認識一下redis，redis的應用場景，以後會繼續學一下redis的常用命令，在項目中的使用情況。
這裏這位朋友對redis的理解和分析也是很容易讓人理解，文章寫的很好，我也是按照他的文章加上自己的一點理解寫出來的：