點(diǎn)擊上方藍(lán)色字體，選擇“標(biāo)星公眾號(hào)”
優(yōu)質(zhì)文章，第一時(shí)間送達(dá)
redis 安裝
安裝步驟：
1、下載獲得redis-3.2.5.tar.gz后將它放入我們的Linux目錄/opt
2、解壓命令:tar -zxvf redis-3.2.5.tar.gz
3、解壓完成后進(jìn)入目錄:cd redis-3.2.5
4、在redis-3.2.5目錄下執(zhí)行make命令
運(yùn)行make命令時(shí)出現(xiàn)故障意出現(xiàn)的錯(cuò)誤解析：gcc：命令未找到
能上網(wǎng)：
yum install gcc
yum install gcc-c++
不能上網(wǎng)：
將資料中的rpmgcc目錄復(fù)制到Linux的opt目錄中
進(jìn)入opt目錄中的rpmgcc目錄執(zhí)行命令：rpm -Uvh *.rpm --nodeps --force
然后使用gcc –v和g++ -v查看gcc和g++版本，會(huì)看到詳細(xì)的版本信息，然后
離線環(huán)境下安裝GCC和GCC-C++就完成了。
5、在redis-3.2.5目錄下再次執(zhí)行make命令
Jemalloc/jemalloc.h：沒有那個(gè)文件
解決方案：運(yùn)行make distclean之后再 make
6、在redis-3.2.5目錄下再次執(zhí)行make命令
查看默認(rèn)安裝目錄：usr/local/bin
Redis-benchmark:性能測試工具，可以在自己本子運(yùn)行，看看自己本子性能如何(服務(wù)啟動(dòng)起來后執(zhí)行)
Redis-check-aof：修復(fù)有問題的AOF文件，持久化
Redis-check-dump：修復(fù)有問題的dump.rdb文件
Redis-sentinel：Redis集群使用，哨兵
redis-server：Redis服務(wù)器啟動(dòng)命令
redis-cli：客戶端，操作入口
啟動(dòng)
1、備份redis.conf：拷貝一份redis.conf到其他目錄
2、修改redis.conf文件將里面的daemonize no 改成 yes，讓服務(wù)在后臺(tái)啟動(dòng)
3、啟動(dòng)命令：執(zhí)行 redis-server /myredis/redis.conf
4、用客戶端訪問: redis-cli
5、測試驗(yàn)證：ping
Redis的Java客戶端Jedis
Jedis所需要的jar包
Commons-pool-1.6.jar
Jedis-2.1.0.jar
idea連接虛擬機(jī)的Redis的注意事項(xiàng)
禁用Linux的防火墻：
臨時(shí)禁用：service iptables stop
關(guān)閉開機(jī)自啟：chkconfig iptables off
redis.conf中注釋掉bind 127.0.0.1（61行） ,然后 protect-mode（80行）設(shè)置為 no。
Jedis測試連通性
Redis事務(wù)
Redis事務(wù)是一個(gè)單獨(dú)的隔離操作：事務(wù)中的所有命令都會(huì)序列化、按順序地執(zhí)行。事務(wù)在執(zhí)行的過程中，不會(huì)被其他客戶端發(fā)送來的命令請(qǐng)求所打斷。
Redis事務(wù)的主要作用就是串聯(lián)多個(gè)命令防止別的命令插隊(duì)
Multi、Exec、discard
從輸入Multi命令開始，輸入的命令都會(huì)依次進(jìn)入命令隊(duì)列中，但不會(huì)執(zhí)行，至到輸入Exec后，Redis會(huì)將之前的命令隊(duì)列中的命令依次執(zhí)行。
組隊(duì)的過程中可以通過discard來放棄組隊(duì)。
事務(wù)的錯(cuò)誤處理
組隊(duì)中某個(gè)命令出現(xiàn)了報(bào)告錯(cuò)誤，執(zhí)行時(shí)整個(gè)的所有隊(duì)列會(huì)都會(huì)被取消。
如果執(zhí)行階段某個(gè)命令報(bào)出了錯(cuò)誤，則只有報(bào)錯(cuò)的命令不會(huì)被執(zhí)行，而其他的命令都會(huì)執(zhí)行，不會(huì)回滾。
悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀，每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人會(huì)修改，所以每次在拿數(shù)據(jù)的時(shí)候都會(huì)上鎖，這樣別人想拿這個(gè)數(shù)據(jù)就會(huì)block直到它拿到鎖。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫里邊就用到了很多這種鎖機(jī)制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。
樂觀鎖(Optimistic Lock), 顧名思義，就是很樂觀，每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人不會(huì)修改，所以不會(huì)上鎖，但是在更新的時(shí)候會(huì)判斷一下在此期間別人有沒有去更新這個(gè)數(shù)據(jù)，可以使用版本號(hào)等機(jī)制。樂觀鎖適用于多讀的應(yīng)用類型，這樣可以提高吞吐量。Redis就是利用這種check-and-set機(jī)制實(shí)現(xiàn)事務(wù)的。
Redis的持久化
Redis 提供了2個(gè)不同形式的持久化方式。
RDB （Redis DataBase）
AOF （Append Of File）
RDB
在指定的時(shí)間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤，也就是行話講的Snapshot快照，它恢復(fù)時(shí)是將快照文件直接讀到內(nèi)存里。
Redis會(huì)單獨(dú)創(chuàng)建（fork）一個(gè)子進(jìn)程來進(jìn)行持久化，會(huì)先將數(shù)據(jù)寫入到一個(gè)臨時(shí)文件中，待持久化過程都結(jié)束了，再用這個(gè)臨時(shí)文件替換上次持久化好的文件。整個(gè)過程中，主進(jìn)程是不進(jìn)行任何IO操作的，這就確保了極高的性能如果需要進(jìn)行大規(guī)模數(shù)據(jù)的恢復(fù)，且對(duì)于數(shù)據(jù)恢復(fù)的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺點(diǎn)是最后一次持久化后的數(shù)據(jù)可能丟失。
關(guān)于fork
在Linux程序中，fork()會(huì)產(chǎn)生一個(gè)和父進(jìn)程完全相同的子進(jìn)程，但子進(jìn)程在此后多會(huì)exec系統(tǒng)調(diào)用，出于效率考慮，Linux中引入了“寫時(shí)復(fù)制技術(shù)”，一般情況父進(jìn)程和子進(jìn)程會(huì)共用同一段物理內(nèi)存，只有進(jìn)程空間的各段的內(nèi)容要發(fā)生變化時(shí)，才會(huì)將父進(jìn)程的內(nèi)容復(fù)制一份給子進(jìn)程。
rdb的保存的文件
在redis.conf中配置文件名稱，默認(rèn)為dump.rdb
rdb文件的保存路徑，也可以修改。默認(rèn)為Redis啟動(dòng)時(shí)命令行所在的目錄下
rdb的保存策略
手動(dòng)保存快照
命令save: 只管保存，其它不管，全部阻塞
save vs bgsave
stop-writes-on-bgsave-error yes
當(dāng)Redis無法寫入磁盤的話，直接關(guān)掉Redis的寫操作
進(jìn)行rdb保存時(shí)，將文件壓縮
在存儲(chǔ)快照后，還可以讓Redis使用CRC64算法來進(jìn)行數(shù)據(jù)校驗(yàn)，但是這樣做會(huì)增加大約10%的性能消耗，如果希望獲取到最大的性能提升，可以關(guān)閉此功能
rdb的備份
先通過config get dir 查詢r(jià)db文件的目錄
將*.rdb的文件拷貝到別的地方
rdb的恢復(fù)
關(guān)閉Redis
先把備份的文件拷貝到工作目錄下
啟動(dòng)Redis, 備份數(shù)據(jù)會(huì)直接加載
rdb的優(yōu)點(diǎn)
節(jié)省磁盤空間
恢復(fù)速度快
rdb的缺點(diǎn)
雖然Redis在fork時(shí)使用了寫時(shí)拷貝技術(shù),但是如果數(shù)據(jù)龐大時(shí)還是比較消耗性能。
在備份周期在一定間隔時(shí)間做一次備份，所以如果Redis意外down掉的話，就會(huì)丟失最后一次快照后的所有修改。
AOF
以日志的形式來記錄每個(gè)寫操作，將Redis執(zhí)行過的所有寫指令記錄下來(讀操作不記錄)，只許追加文件但不可以改寫文件，Redis啟動(dòng)之初會(huì)讀取該文件重新構(gòu)建數(shù)據(jù)，換言之，Redis重啟的話就根據(jù)日志文件的內(nèi)容將寫指令從前到后執(zhí)行一次以完成數(shù)據(jù)的恢復(fù)工作。
AOF默認(rèn)不開啟，需要手動(dòng)在配置文件中配置
可以在redis.conf中配置文件名稱，默認(rèn)為 appendonly.aof
AOF文件的保存路徑，同RDB的路徑一致。
AOF和RDB同時(shí)開啟，redis 聽aof的
AOF文件故障備份
AOF的備份機(jī)制和性能雖然和RDB不同, 但是備份和恢復(fù)的操作同RDB一樣，都是拷貝備份文件，需要恢復(fù)時(shí)再拷貝到Redis工作目錄下，啟動(dòng)系統(tǒng)即加載。
AOF文件故障恢復(fù)
如遇到AOF文件損壞，可通過
redis-check-aof --fix appendonly.aof 進(jìn)行恢復(fù)
AOF同步頻率設(shè)置
始終同步，每次Redis的寫入都會(huì)立刻記入日志
每秒同步，每秒記入日志一次，如果宕機(jī)，本秒的數(shù)據(jù)可能丟失。
把不主動(dòng)進(jìn)行同步，把同步時(shí)機(jī)交給操作系統(tǒng)。
Rewrite
AOF采用文件追加方式，文件會(huì)越來越大為避免出現(xiàn)此種情況，新增了重寫機(jī)制,當(dāng)AOF文件的大小超過所設(shè)定的閾值時(shí)，Redis就會(huì)啟動(dòng)AOF文件的內(nèi)容壓縮，只保留可以恢復(fù)數(shù)據(jù)的最小指令集.可以使用命令bgrewriteaof。
Redis如何實(shí)現(xiàn)重寫？
AOF文件持續(xù)增長而過大時(shí)，會(huì)fork出一條新進(jìn)程來將文件重寫(也是先寫臨時(shí)文件最后再rename)，遍歷新進(jìn)程的內(nèi)存中數(shù)據(jù)，每條記錄有一條的Set語句。重寫aof文件的操作，并沒有讀取舊的aof文件，而是將整個(gè)內(nèi)存中的數(shù)據(jù)庫內(nèi)容用命令的方式重寫了一個(gè)新的aof文件，這點(diǎn)和快照有點(diǎn)類似。
何時(shí)重寫
重寫雖然可以節(jié)約大量磁盤空間，減少恢復(fù)時(shí)間。但是每次重寫還是有一定的負(fù)擔(dān)的，因此設(shè)定Redis要滿足一定條件才會(huì)進(jìn)行重寫。
系統(tǒng)載入時(shí)或者上次重寫完畢時(shí)，Redis會(huì)記錄此時(shí)AOF大小，設(shè)為base_size,如果Redis的AOF當(dāng)前大小>= base_size +base_size*100% (默認(rèn))且當(dāng)前大小>=64mb(默認(rèn))的情況下，Redis會(huì)對(duì)AOF進(jìn)行重寫。
AOF的優(yōu)點(diǎn)
備份機(jī)制更穩(wěn)健，丟失數(shù)據(jù)概率更低。
可讀的日志文本，通過操作AOF穩(wěn)健，可以處理誤操作。
AOF的缺點(diǎn)
比起RDB占用更多的磁盤空間。
恢復(fù)備份速度要慢。
每次讀寫都同步的話，有一定的性能壓力。
存在個(gè)別Bug，造成恢復(fù)不能。
用哪個(gè)好
官方推薦兩個(gè)都啟用。
如果對(duì)數(shù)據(jù)不敏感，可以選單獨(dú)用RDB。
不建議單獨(dú)用 AOF，因?yàn)榭赡軙?huì)出現(xiàn)Bug。
如果只是做純內(nèi)存緩存，可以都不用。
Redis的主從復(fù)制
主從復(fù)制，就是主機(jī)數(shù)據(jù)更新后根據(jù)配置和策略，自動(dòng)同步到備機(jī)的master/slaver機(jī)制，Master以寫為主，Slave以讀為主
用處
讀寫分離，性能擴(kuò)展
容災(zāi)快速恢復(fù)
配從(服務(wù)器)不配主(服務(wù)器)
在這里插入圖片描述
啟動(dòng)3臺(tái)redis服務(wù)
info replication
打印主從復(fù)制的相關(guān)信息
slaveof
成為某個(gè)實(shí)例的從服務(wù)器
一主二仆模式演示
復(fù)制原理
每次從機(jī)聯(lián)通后，都會(huì)給主機(jī)發(fā)送sync指令
主機(jī)立刻進(jìn)行存盤操作，發(fā)送RDB文件，給從機(jī)
從機(jī)收到RDB文件后，進(jìn)行全盤加載
之后每次主機(jī)的寫操作，都會(huì)立刻發(fā)送給從機(jī)，從機(jī)執(zhí)行相同的命令
薪火相傳
上一個(gè)slave可以是下一個(gè)slave的Master，slave同樣可以接收其他slaves的連接和同步請(qǐng)求，那么該slave作為了鏈條中下一個(gè)的master, 可以有效減輕master的寫壓力,去中心化降低風(fēng)險(xiǎn)。
用 slaveof
中途變更轉(zhuǎn)向:會(huì)清除之前的數(shù)據(jù)，重新建立拷貝最新的
風(fēng)險(xiǎn)是一旦某個(gè)slave宕機(jī)，后面的slave都沒法備份
反客為主
當(dāng)一個(gè)master宕機(jī)后，后面的slave可以立刻升為master，其后面的slave不用做任何修改。。
用 slaveof no one 將從機(jī)變?yōu)橹鳈C(jī)。
哨兵模式(sentinel)
反客為主的自動(dòng)版，能夠后臺(tái)監(jiān)控主機(jī)是否故障，如果故障了根據(jù)投票數(shù)自動(dòng)將從庫轉(zhuǎn)換為主庫.
配置哨兵
調(diào)整為一主二仆模式
自定義的/myredis目錄下新建sentinel.conf文件
在配置文件中填寫內(nèi)容：
sentinel monitor mymaster 127.0.0.1 6379 1
其中mymaster為監(jiān)控對(duì)象起的服務(wù)器名稱， 1 為 至少有多少個(gè)哨兵同意遷移的數(shù)量。
啟動(dòng)哨兵
執(zhí)行redis-sentinel /myredis/sentinel.conf
現(xiàn)在我將6379 shutdown 然后在將6379連上，發(fā)現(xiàn) 主機(jī)為6381 從機(jī)為6379、6380
哨兵模式搭建完畢，下面來搞集群
redis的集群
Redis 集群實(shí)現(xiàn)了對(duì)Redis的水平擴(kuò)容，即啟動(dòng)N個(gè)redis節(jié)點(diǎn)，將整個(gè)數(shù)據(jù)庫分布存儲(chǔ)在這N個(gè)節(jié)點(diǎn)中，每個(gè)節(jié)點(diǎn)存儲(chǔ)總數(shù)據(jù)的1/N。
Redis 集群通過分區(qū)（partition）來提供一定程度的可用性（availability）：即使集群中有一部分節(jié)點(diǎn)失效或者無法進(jìn)行通訊， 集群也可以繼續(xù)處理命令請(qǐng)求。
1、安裝ruby環(huán)境
能上網(wǎng)：
執(zhí)行yum install ruby
執(zhí)行yum install rubygems
不能上網(wǎng)：
cd /run/media/root/CentOS 7 x86_64/Packages（路徑跟centos6不同） 獲取右圖rpm包
拷貝到/opt/rpmruby/目錄下，并cd到此目錄
執(zhí)行：rpm -Uvh *.rpm --nodeps --force
按照依賴安裝各個(gè)rpm包
2、拷貝redis-3.2.0.gem到/opt目錄下
3、執(zhí)行在opt目錄下執(zhí)行 gem install --local redis-3.2.0.gem
制作6個(gè)實(shí)例，6379,6380,6381,6389,6390,6391.conf
cluster-enabled yes 打開集群模式
cluster-config-file nodes-6379.conf 設(shè)定節(jié)點(diǎn)配置文件名
cluster-node-timeout 15000 設(shè)定節(jié)點(diǎn)失聯(lián)時(shí)間，超過該時(shí)間（毫秒），集群自動(dòng)進(jìn)行主從切換。
復(fù)制6份
并且改端口（每個(gè)都要改）
將六個(gè)節(jié)點(diǎn)合成一個(gè)集群
組合之前，請(qǐng)確保所有redis實(shí)例啟動(dòng)后，nodes-xxxx.conf文件都生成正常。
合體：
cd /opt/redis-3.2.5/src
./redis-trib.rb create --replicas 1 192.168.1.101:6379 192.168.1.101:6380 192.168.1.101:6381 192.168.1.101:6389 192.168.1.101:6390 192.168.1.101:6391
合體成功
通過 cluster nodes 命令查看集群信息
redis cluster 如何分配這六個(gè)節(jié)點(diǎn)?
一個(gè)集群至少要有三個(gè)主節(jié)點(diǎn)。
選項(xiàng) --replicas 1 表示我們希望為集群中的每個(gè)主節(jié)點(diǎn)創(chuàng)建一個(gè)從節(jié)點(diǎn)。
分配原則盡量保證每個(gè)主數(shù)據(jù)庫運(yùn)行在不同的IP地址，每個(gè)從庫和主庫不在一個(gè)IP地址上。
什么是slots?
一個(gè) Redis 集群包含 16384 個(gè)插槽（hash slot）， 數(shù)據(jù)庫中的每個(gè)鍵都屬于這 16384 個(gè)插槽的其中一個(gè)， 集群使用公式 CRC16(key) % 16384 來計(jì)算鍵 key 屬于哪個(gè)槽， 其中 CRC16(key) 語句用于計(jì)算鍵 key 的 CRC16 校驗(yàn)和 。
集群中的每個(gè)節(jié)點(diǎn)負(fù)責(zé)處理一部分插槽。舉個(gè)例子， 如果一個(gè)集群可以有主節(jié)點(diǎn)， 其中：
節(jié)點(diǎn) A 負(fù)責(zé)處理 0 號(hào)至 5500 號(hào)插槽。
節(jié)點(diǎn) B 負(fù)責(zé)處理 5501 號(hào)至 11000 號(hào)插槽。
節(jié)點(diǎn) C 負(fù)責(zé)處理 11001 號(hào)至 16383 號(hào)插槽。
如果主節(jié)點(diǎn)下線？從節(jié)點(diǎn)能否自動(dòng)升為主節(jié)點(diǎn)？
主節(jié)點(diǎn)恢復(fù)后，主從關(guān)系會(huì)如何？
如果所有某一段插槽的主從節(jié)點(diǎn)都宕掉，redis服務(wù)是否還能繼續(xù)?
redis.conf中的參數(shù) cluster-require-full-coverage
集群的Jedis開發(fā)
public class JedisClusterTest {
public static void main(String[] args) {
Set<HostAndPort> set =new HashSet<HostAndPort>();
set.add(new HostAndPort("192.168.1.101",6379));
JedisCluster jedisCluster=new JedisCluster(set);
jedisCluster.set("k1", "v1");
System.out.println(jedisCluster.get("k1"));
}
}
Redis 集群提供了以下好處：
實(shí)現(xiàn)擴(kuò)容
分?jǐn)倝毫?br style="outline: 0px;">無中心配置相對(duì)簡單
Redis 集群的不足：
多鍵操作是不被支持的
多鍵的Redis事務(wù)是不被支持的。lua腳本不被支持。
由于集群方案出現(xiàn)較晚，很多公司已經(jīng)采用了其他的集群方案，而代理或者客戶端分片的方案想要遷移至redis cluster，需要整體遷移而不是逐步過渡，復(fù)雜度較大。
版權(quán)聲明：本文為博主原創(chuàng)文章，遵循 CC 4.0 BY-SA 版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接和本聲明。
本文鏈接：
https://blog.csdn.net/weixin_40245787/article/details/87858380
粉絲福利：Java從入門到入土學(xué)習(xí)路線圖
??????
感謝點(diǎn)贊支持下哈 
