今天我們來學習一下Redis相關的內容，相信作爲一名優秀的程序員，我們對Redis肯定不陌生，所以就不多廢話了，我們直接來開幹，首先準備一臺虛擬機，這裏我是用的是CentOS7的環境，準備好了之後我們準備好安裝包，並上傳至虛擬機
我們都知道，redis是使用C語言編寫的，因此我們在安裝之前需要檢查一下gcc的編譯環境，如果沒有的話，就需要使用yum install -y gcc-c++ 命令進行安裝
好了，安裝完成之後我們解壓redis的包，進入解壓目錄，修改一下src目錄下的MakeFile這個文件，讓redis編譯到指定的目錄，這裏不修改也可以，只是我的強迫症在作祟、每次看到一堆亂的文件就很難受。
這裏我是指定到了 /usr/local/redis 路徑下了
好了，接下來我們就可以先來使用make命令編譯了，編譯完成之後的信息如下：
終端上會有一條提示信息，告訴我i們運行一下make test是個good idea ,emmmm.......這裏是不是一個good idea 我不清楚，但是我運行了之後很久都沒退出來，浪費了一上時間吧，這裏大家學習的話不運行也沒事，但是生產環境上部署的話可以試着運行一個測試。好了，這裏我們就忽略text。我們接下來直接使用make install 命令進行安裝。安裝完成之後如下圖所示：
好吧，這傢伙仍然提示make test，我們先不管這個，我們直接來到/usr/local/redis目錄下，我們發出現已經安裝好了
接下來我們試試能不能啓動起來
好了，說明我們的安裝 的沒問題。但是我們一般在使用的時候需要指定一個配置文件，通過該配置文件進行後臺啓動。下面我們來看看怎麼通過配置文件的形式進行後臺啓動，我先將redis解壓目錄下的redis.conf文件複製一份到安裝目錄下，
接着我們到安裝目錄下，查看一下配置文件的內容，我們現主要修改一下幾個地方
上述的配置意思分別是指定redis的工作目錄是/usr/local/redis 輸出的日誌寫入文件/usr/local/redis/redis.log。允許後臺啓動
好了，配置完成之後我們可以保存退出了 。
我們要想後臺啓動redis的時候我們就需要使用到這個配製文件，語法是 redis-server文件路徑 redis.conf文件路徑。但是有時候命令太長了，寫起來很不方便，於是我們可以在redis.conf目錄下直接使用 redis-server redis.conf命令執行，
如果發現上述錯誤信息，就需要創建一個軟連接，命令如下： ln -s /usr/local/redis/bin/redis-server /usr/bin/redis-server。路徑需根據具自己的實際路徑修改。
修改完成之後我們繼續運行上述命令即可啓動redis服務了，啓動之後我們可以使用redis-cli 命令來連接一下服務端(同樣的建議創建一個軟連接，方便操作)
連接上之後我們輸入一個ping指令，如果返回了一個PONG字符串，說明我們的客戶端和服務端的鏈接是正常的。如下圖所示：
好了，Redis的安裝我們已經完成了。
接下來我們回憶下下Redis的5中基本的數據結構。String 、List 、Hash、 Set、Zset。我們最熟悉的肯定是String了,關於String類型大家只需要知道個字符串值的最大容量是512M，該類型可以存任何數據，包括圖片文件以及序列化的對象。 好了，List是簡單的字符串有序列表，按插入的順序排序，我們需要知道的它是基於鏈表的數據結構實現的，因此他的特性是操作頭尾效率高，操作中間數據效率偏低。至於Set是一個無序集合，底層使用哈希表來實現。HashSet就是類似我們在Java中使用的HsahMap，是以鍵值對存在的。最後一種Zset的類型相對於前4中就要稍微的複雜了一些、他和Set一樣也是和用來存儲String 類型的字符串，無序且不能重複，不同的是每個元素都關聯了一個分數。zset可以根據這個分數來給元素排序，需要注意的是分數可以重複。以上就是Redis支持的5種數據類型。關於基本的操作這裏不做過多的介紹。下面我們來看一下Redis的持久化操作。
我們都知道Redis是將數據存儲在內存中，因此數據的讀寫速度非常的快，快到什麼程度大家可以使用redis-benchmark測試一下：
從上圖中我們就可以看到Redis的讀寫速度了，很快，但是數據全部都是在內存裏。這樣的話如果機器突然斷電或者因爲某種原因宕機的話數據全部丟失了，出於這種原因Redis提供了持久化的功能，相信大家也並不陌生，主要分爲 兩種模式，RDB和AOF。前者是指定時間來持久化一次內存中的數據，後者是根據指定分策略將操作的命令記錄到一個文件中。
我們接着回到配置文件中，會發現有一個地方配置的信息如下：
這裏就是RDB的默認配置，其含義是 900秒內至少有一次修改則觸發保存操作 300秒內10次修改觸發保存 60秒內10000次修改觸發保存。接着我們可以看到一下這行配置，這個就是RDB持久化之後的文件，當Redis下一次啓動的時候就會加載該配置文件。
這裏我們需要注意的是RDB的觸發時機，主要有以下幾個
1、默認配置
2、執行save 或者bgsave
3、執行了flushall命令
4、正常的使用shutdown命令退出redis
好了，我們可以想一下RDB模式是否可以真的保證數據萬無一失。
接下來，我們來看一下另外一種持久化的機制AOF，我們回到配置文件中發現有以下配置：
AOF默認是關閉的狀態，如果來開啓的話就需要將上述no修改成yes 然後制定文件的名字，這種持久化的機制主要是記住運行產生數據的命令，需要注意的是對於一些重複的命令，爲了節約時間，通常會有一種AOF重寫的機制，但是該機制會影響程序運行的效率佔用cpu資源。
需要注意的是當AOF持久化文件損壞了的時候，redis讀取了損壞的文件之後會導致啓動失敗，因此需要對文件進行修復，我們使用 redis-check-aof --fix appendonly.aof 命令進行修復。
好了，我們接下來聊一下這兩種持久化的方式各自的優缺點吧，
RDB的優缺點：
適合大規模的數據恢復，速度較快
會丟失最後一次快照後的所有修改，不能絕對保證數據的高度一致性和完整性。
AOF的優缺點：
選擇appendfsync always方式運行時理論上能夠做到數據完整一致，但此時性能又不好。文件內容具備一定可讀性，能夠用來分析Redis工作情況。
持久化相同的數據，文件體積比RDB大，恢復速度比RDB慢。效率在同步寫入時低於RDB，不同步寫入時與RDB相同。
好了，上述就是這兩種方式的一個比對，大家在使用的時候可以根據自己的實際情況做出合適的策略。
接下來我們來聊一聊事務，在Redis中有一組命令是關於事務控制的。MULTI表示開始收集命令，後面所有命令都不是馬上執行，而是加入到一個隊列中。 EXEC執行MULTI後面命令隊列中的所有命令。DISCARD放棄執行隊列中的命令WATCH“觀察“、”監控“一個KEY，在當前隊列外的其他命令操作這個KEY時，放棄執行自己隊列的命令UNWATCH放棄監控一個KEY。
我們來試試這個；
假如我們在開啓了multi的情況下，編寫了一條錯誤的命令，即使即可更正了，但是同樣的也是不能提交的，也就是說一系列的操作全部都不生效。再來看看下面這種情況：
我們發現再出錯的地方並不會回滾整個一系列的操作，而是停留在出錯的那條指令之前。
關於Redis的事務大家需要明確一點，這傢伙不可靠，因此在開發的過程中，我們一定不能使用Redis的事務的，關於這個問題，Redis官方因爲做過相應的解釋，感興趣的可以取官網瞭解。這裏不做過多的解釋。
好了今天主要就給大家介紹下這些，明天繼續給大家分享Redis的集羣部署。大家晚安！