Redis --- 超级详细
NoSql概述
為什么使用NoSql？
單機MySQL年代
90年代，一個基本的網站訪問量一般不會太大，單個數據庫完全足夠!
那個時候，更多的去使用靜態網頁Html~服務器根本沒有太大的壓力!
思考一下，這種情況下:整個網站的瓶頸是什么?
1、數據量如果太大、一個機器放不下了!
2、數據的索引( B+ Tree ) ，一個機器內存也放不下
3、訪問量（讀寫混合），一個服務器承受不了~
只要你開始出現以上的三種情況之一，那么你就必須要晉級!
Memcached(緩存) + MySQL + 垂直拆分(讀寫分離)
網站80%的情況都是在讀，每次都要去查詢數據庫的話就十分的麻煩!所以說我們希望減輕數據的壓力，我們可以使用緩存來保證效率!
發展過程︰優化數據結構和索引–>文件緩存(IO)—>Memcached（當時最熱門的技術!)
分庫分表 + 水平拆分 + MySql集群
技術和業務在發展的同時，對人的要求也越來越高!
本質∶數據庫（讀，寫)
早些年MyISAM:表鎖，十分影響效率!高并發下就會出現嚴重的鎖問題
轉戰Innodb:行鎖
慢慢的就開始使用分庫分表來解決寫的壓力!MySQL在哪個年代推出了表分區!這個并沒有多少公司使用!
MySOL的集群，很好滿足哪個年代的所有需求!
當下這個年代
2010–2020十年之間，世界已經發生了翻天覆地的變化;(定位，也是一種數據，音樂，熱榜!)
MySQL等關系型數據庫就不夠用了!數據量很多，變化很快~!
MySQL有的使用它來存儲一些比較大的文件，博客，圖片!數據庫表很大，效率就低了!如果有一種數據庫來專門處理這種數據，
MySQL壓力就變得十分小(研究如何處理這些問題!）大數據的IO壓力下，表幾乎沒法更大!
目前一個基本的互聯網項目
為什么使用NoSql
這時候我們就需要使用NoSQL數據庫的，Nosql可以很好的處理以上的情況!
用戶的個人信息，社交網絡，地理位置。用戶自己產生的數據，用戶日志等等爆發式增長!
什么是NoSql
NoSQL
NoSQL = Not Only sQL（不僅僅是SQL )
關系型數據庫:表格，行，列
泛指非關系型數據庫的，隨著web2,0互聯網的誕生!傳統的關系型數據庫很難對付web2.0時代!尤其是超大規模的高并發的社區↓暴露出來很多難以克服的問題，NoSQL在當今大數據環境下發展的十分迅速，Redis是發展最快的，而且是我們當下必須要掌握的一個技術!
很多的數據類型用戶的個人信息，社交網絡，地理位置。這些數據類型的存儲不需要一個固定的格式!不需要多月的操作就可以橫向擴展的! Map<String,Object>使用鍵值對來控制!
NoSQL 的特點
解耦!
1、方便擴展（數據之間沒有關系，很好擴展!)
能會比較高!)
2、大數據量高性能（Redis一秒寫8萬次，讀取11萬，NoSQL的緩存記錄級，是一種細粒度的緩存，性
3、數據類型是多樣型的!(不需要事先設計數據庫!隨取隨用!如果是數據量十分大的表，很多人就無法設計了! )
4、傳統RDBMS和NoSQL
了解：3V+3高
大數據時代的3V:主要是描述問題的
1.海量Volume
2.多樣Variety
3.實時Velocity
大數據時代的3高:主要是對程序的要求
1.高并發
2高可擴
3.高性能
真正在公司中的實踐:NoSQL+RDBMS一起使用才是最強的，阿里巴巴的架構演進!
技術沒有高低之分，就看你如何去使用!（提升內功，思維的提高!)
NoSQL四大基本類型
KV鍵值對:
新浪:Redis
美團:Redis +Tair
阿里、白度:Redis + memecache
文檔型數據庫(bson格式和json一樣）:
MongoDB（一般必須要掌握）
- o MongoDB是一個基于分布式文件存儲的數據庫，C++編寫，主要用來處理大量的文檔!
- o MongoDB是一個介于關系型數據庫和非關系型數據中中間的產品!MongoDB是非關系型數據庫中功能最豐富，最像關系型數據庫的!
.ConthDB
列存儲數據庫
HBase
分布式文件系統
四者對比
Redis 在linux下環境搭建
安裝的前提條件：
需要安裝gcc：yum install gcc-c++
1、下載redis的源碼包。
2、把源碼包上傳到linux服務器
3、解壓源碼包
tar -zxvf redis-3.0.0.tar.gz
4、Make
5、Make install
[root@bogon redis-3.0.0]# make install PREFIX=/usr/local/redis
啟動redis
1、前端啟動模式
/usr/local/redis/bin/redis-server
默認是前端啟動模式，端口是6379
2、后端啟動
1）從redis的源碼目錄中復制redis.conf到redis(/usr/local)的安裝目錄。
2）修改配置文件
3）[root@jsu bin]# ./redis-server redis.conf
4）redis-cli -p 6379 redis與客戶端進行連接
./redis-server redis.conf 開啟redis
redis-cli -p 6379 redis與客戶端進行連接
ps -ef|grep redis 查看redis線程
redis-cli -p 6379
shutdown
exit 關閉線程
測試性能：
#測試:100個并發連接100000請求
redis-benchmark -h localhost -p 6379 -c 100 -n 100000
基礎知識：
#redis 默認有16個數據庫 0~15
#可以使用select切換數據庫
[root@localhost bin] redis-cli -p 6379
127.0.0.1:6379> select 3 # 切換3號數據庫
OK
127.0.0.1:6379[3]> DBSIZE # 查看數據庫大小
(integer) 0
127.0.0.1:6379[3]> set name su
OK
127.0.0.1:6379[3]> DBSIZE
(integer) 1
127.0.0.1:6379[3]> keys * # 獲取所有的鍵
1) "name"
127.0.0.1:6379[3]> get name # 通過鍵去取值
"su"
127.0.0.1:6379[3]> flushdb # 清空當前庫的數據
OK
127.0.0.1:6379[3]> keys *
(empty list or set)
127.0.0.1:6379[3]> flushall # 清空所有庫的數據
OK
127.0.0.1:6379[3]> exist name # 判斷key是否存在
(integer)
127.0.0.1:6379>move name 1 # 移動key 到 1 redis庫中
(integer) 1
127.0.0.1:6379>del name # 刪除key=name
(integer) 1
127.0.0.1:6379> keys *
1) "age"
127.0.0.1:6379> expire age 10 # 設置key 過期的時間
(integer) 1
127.0.0.1:6379> ttl age # 顯示還有多少秒
(integer) 4
127.0.0.1:6379> get age # 時間到了 就刪除了
(nil)
127.0.0.1:6379> type name # 查詢type類型
string
127.0.0.1:6379> type age
string為什么端口號是6379？
? Redis的作者Antirez 喜歡意大利女演員Alessia Merz ，Merz 在手機九宮格上輸入就是6379
Redis是單線程
明白Redis是很快的，官方表示，Redis是基于內存操作，CPU不是Redis性能瓶頸，Redis的瓶頸是根據機器的內存和網絡帶寬，既然可以使用單線程來實現，所以就使用單線程了!
Redis為什么單線程還這么快?
誤區
1、高性能的服務器一定是多線程的?
2、多線程（CPU上下文會切換!)一定比單線程效率高!
先去CPU>內存>硬盤的速度要有所了解!
核心
? redis是將所有的數據全部放在內存中的，所以說使用單線程去操作效率就是最高的，多線程(CPU上下文會切換︰耗時的操作!!! )，對于內存系統來說，如果沒有上下文切換效率就是最高的!多次讀寫都是在一個CPU上的，在內存情況下，這個就是最佳的方案!
五大基本類型
String(字符串)
APPEND name xx # 追加字符串
STRLEN name # 字符串長度
incr views # 自增1
decr views # 自減1
INCRBY views 10 # 自增10
DECRBY views 5 # 自減10
GETRANGE name 0 3 # 截取0-3
GETRANGE name 0 -1 # 查詢所有的字符串
SETRANGE name2 1 lin# 替換指定位置開始的字符串
# setex (set with expire) 設置過期時間
# setnx (set if not exist) 不存在該值在設置（分布式鎖常常會用）
setex name3 30 xx # key 過期時間 value
setnx name3 "redis" # key value K存在不設置 不存在再設置
mset k1 v1 k2 v2 # 批量存入
mget k1 k2 k3 # 批量獲取
msetnx k1 v1 k2 v2 # K存在不設置 不存在再設置 一起成功或一起失敗###########################################################
# 對象
# 第一種 設置一個user:1對象 值為json字符來保存一個對象
127.0.0.1:6379> set user1:1 {name:zhangsan,age:4}
OK
127.0.0.1:6379> get user1:1
"{name:zhangsan,age:4}"
# 第二種 這里的key是一個巧妙的設計：user:{id}:{filed}
127.0.0.1:6379> mset user2:1:name zhangsan user2:1:age 2
OK
127.0.0.1:6379> mget user2:1:name user2:1:age
1) "zhangsan"
2) "2"#########################################################
# getset 組合使用
127.0.0.1:6379> getset db redis # 不存在 set
(nil)
127.0.0.1:6379> get db
"redis"
127.0.0.1:6379> getset db mongoDB # 存在了 修改值 返回原始值
"redis"
127.0.0.1:6379> get db
"mongoDB"List(列表)
# 將一個值或者多個值 插入到列表頭部 （左）
# LPUSH == LEFT PUSH
127.0.0.1:6379> LPUSH list one
127.0.0.1:6379> LPUSH list two
127.0.0.1:6379> LPUSH list three
127.0.0.1:6379> LRANGE list 0 -1
1) "three"
2) "two"
3) "one"
# 將一個值或者多個值 插入到列表尾部 （右）
127.0.0.1:6379> RPUSH list four
127.0.0.1:6379> LRANGE list 0 -1
1) "three"
2) "two"
3) "one"
4) "four"############################################################
# pop 取值 LPOP移除list的第一個元素
127.0.0.1:6379> LPOP list
"three"
# RPOP移除list的最后一個元素
127.0.0.1:6379> RPOP list
"four"
# 獲取索引位置為1的值
127.0.0.1:6379> LINDEX list 1
"one"
# 獲取list長度
127.0.0.1:6379> LLEN list
(integer) 2
# 刪除指定個數的值
127.0.0.1:6379> LREM list 1 three############################################################
# trim 修剪 list 截斷
# 通過下標截取指定長度 只留下1到2的元素
127.0.0.1:6379> LTRIM list 1 2
# RPOPLPUSH 移除列表中最后一個元素，將他移動到新的列表中
127.0.0.1:6379> RPOPLPUSH list otherlist############################################################
# 判斷這個列表是否存在 返回0不存在
127.0.0.1:6379> EXISTS list
# lset將列表中指定下標的值替換為另外一個值，更新操作
# 如果不存在列表我們去更新就會報錯
127.0.0.1:6379>lset list 0 item
(error)ERR no such key
# 存取值的時候 list大多數使用的push pop 而不是setget
127.0.0.1:6379> lpush list value1
127.0.0.1:6379> lset list 0 item#如果存在，更新當前下標的值############################################################
# insert 將某元素插入列表中某元素的后面或者前面
# 將"other" 插入到"world" 前面
127.0.0.1:6379> LINSERT mylist before "world" "other"
127.0.0.1:6379> LRANGE mylist 0 -1
1) "hello"
2) "other"
3) "world"可以做消息排隊！！消息隊列(Lpush Rpop) 棧(Lpush Lpop)
Set(集合)
set中的值是不能重讀的！
# 向set集合中添加元素
127.0.0.1:6379> sadd myset "cx"
# 查看指定set中的所有值
127.0.0.1:6379> SMEMBERS myset
1) "cx"
# 判斷set中是否包含指定元素 包含返回1 不包含返回0
127.0.0.1:6379> SISMEMBER myset hello
# 查詢set中有幾個元素
127.0.0.1:6379> SCARD myset
# 移除set指定元素
127.0.0.1:6379> srem myset hello############################################################
# set 無序不重復集合
# 隨機抽出元素
127.0.0.1:6379> SRANDMEMBER myset
# 隨機抽出指定個元素
127.0.0.1:6379> SRANDMEMBER myset 2
# 隨機刪除一個key
127.0.0.1:6379> spop myset
# 將一個指定的值 移動到另一個set集合中
127.0.0.1:6379> smove myset myset2 jsu############################################################
127.0.0.1:6379> SDIFF set set2 # 差集
127.0.0.1:6379> SINTER set set2 # 交集
127.0.0.1:6379> SUNION set set2 # 并集Hash(哈希)
map集合，key-map！ 這個值是map集合
# set一個具體的key -value
127.0.0.1:6379> hset myhash field1 su
# 獲取一個字段值
127.0.0.1:6379> hget myhash field1
# set多個k-v
127.0.0.1:6379> hmset myhash field1 v1 f2 v2 f3 v3
# 獲取多個字段值
127.0.0.1:6379> hmget myhash field1 f2 f3
# 獲取所有的數據
127.0.0.1:6379> hgetall myhash
# 刪除hash指定的K字段 對應的v也就沒了
127.0.0.1:6379> hdel myhash field1############################################################
# 獲取hash的長度
127.0.0.1:6379> hlen myhash
#判斷hash中指定字段是否存在!
127.0.0.1:6379>HEXISTS myhash field1
#只獲得所有field
127.0.0.1:6379> hkeys myhash
#只獲得所有value
127.0.0.1:6379> hvals myhash
#指定增量!
127.0.0.1:6379> hset myhash field3 5
127.0.0.1:6379>HINCRBY myhash field3 1
127.0.0.1:6379>HINCRBY myhash field3 -1
#如果不存在則可以設置 如果存在則不能設置
127.0.0.1:6379> hsetnx myhash field4 hello
Zset(有序集合)
在set的集合上 增加了一個值 set k1 v1 zset k1 score1 v1
# zset 存值和set一樣 但是k前多了個序號 用來排序
127.0.0.1:6379> zadd myzset 1 one
127.0.0.1:6379> zadd myzset 3 three 4 four
# 查詢所有
127.0.0.1:6379> zrange myzset 0 -1
1) "one"2) "two"3) "three"4) "four# 排序如何實現
127.0.0.1:6379> zadd salary 2500 jsu
127.0.0.1:6379> zadd salary 5000 cx
127.0.0.1:6379> zadd salary 500 kiki
# 從小到大排序
127.0.0.1:6379> ZRANGEBYSCORE salary -inf +inf
1) "kiki"2) "jsu"3) "cx"
# 從小到大排序 加上scores
127.0.0.1:6379> ZRANGEBYSCORE salary -inf +inf withscores
1) "kiki"2) "500"
3) "jsu"4) "2500"
5) "cx"6) "5000"
# 從無窮小到2500排序 加上scores
127.0.0.1:6379> ZRANGEBYSCORE salary -inf 2500 withscores
1) "kiki"2) "500"
3) "jsu"4) "2500"
# 刪除指定元素
127.0.0.1:6379> zrem salary jsu
# 獲取長度
127.0.0.1:6379> ZCARD salary
# 按照指定元素 從大到小
127.0.0.1:6379> ZREVRANGE salary 0 -1
1) "cx"2) "kiki"
#獲取指定區間的成員數量!
127.0.0.1:6379> zcount myset 1 3三種特殊數據類型
Geospatial地理位置
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-PbSm5yZ3-1596114755910)(…/AppData/Roaming/Typora/typora-user-images/image-20200728215945359.png)]
#GEOADD 添加地理位置
#規則:兩級無法直接添加，我們一般會下載城市數據，直接通過java程序一次性導入!
#有效的經度從-180度到180度。
#有效的緯度從-85.05112878度到85.05112878度。
#當坐標位置超出上述指定范圍時，該命令將會返回一個錯誤。
127.0.0.1:6379> GEOADD china:city 116.40 39.90 beijing
127.0.0.1:6379> GEOADD china:city 121.47 31.23 shanghai
127.0.0.1:6379> GEOADD china:city 106.50 29.53 chongqi
127.0.0.1:6379> GEOADD china:city 114.05 22.52 shenzhen
127.0.0.1:6379> GEOADD china:city 120.16 30.24 hangzhou
127.0.0.1:6379> GEOADD china:city 108.96 34.26 xian############################################################
# GEOPOS 獲取指定城市的經度緯度
127.0.0.1:6379> GEOPOS china:city beijing
1) 1) "116.39999896287918091"2) "39.90000009167092543"############################################################
# GEODIST 查詢兩個坐標的直線距離
127.0.0.1:6379> GEODIST china:city beijing shanghai
"1067378.7564"############################################################
# GEORADIUS 以某經緯度為坐標中心 1000km為半徑查詢在之內的城市
127.0.0.1:6379> GEORADIUS china:city 110 30 1000 km
1) "chongqi"
2) "xian"
3) "shenzhen"
4) "hangzhou"
# 帶上經緯度
127.0.0.1:6379> GEORADIUS china:city 110 30 500 km withcoord
1) 1) "chongqi"2) 1) "106.49999767541885376"2) "29.52999957900659211"
2) 1) "xian"2) 1) "108.96000176668167114"2) "34.25999964418929977"
# 帶上直線距離
127.0.0.1:6379> GEORADIUS china:city 110 30 500 km withdist
1) 1) "chongqi"2) "341.9374"
2) 1) "xian"2) "483.8340"
# 帶上經緯度 + 個數
127.0.0.1:6379> GEORADIUS china:city 110 30 500 km withcoord count 1
1) 1) "chongqi"2) 1) "106.49999767541885376"2) "29.52999957900659211"
2) 1) "xian"2) 1) "108.96000176668167114"2) "34.25999964418929977"
Hyperloglog
什么是基數?
A {1,3,5,7,8,7}
B {1,3,5,7,8}
基數（不重復的元素)=5，可以接受誤差!
簡介
Redis 2.8.9版本就更新了Hyperloglog數據結構!
Redis Hyperloglog基數統計的算法!
優點∶占用的內存是固定，2^64不同的元素的技術，只需要廢12KB內存!如果要從內存角度來比較的話Hyperloglog首選!
網頁的PV(一個人訪問一個網站多次，但是還是算作一個人!)
傳統的方式，set保存用戶的id，然后就可以統計set中的元素數量作為標準判斷!這個方式如果保存大量的用戶id，就會比較麻煩!我們的目的是為了計數，而不是保存用戶id0.81%錯誤率!統計UV任務，可以忽略不計的!
# 創建第一組
127.0.0.1:6379> PFADD mykey a b c d e f g h i j
(integer) 1
# 統計mykey元素的基數數量
127.0.0.1:6379> PFCOUNT mykey
(integer) 10
# 創建第二組
127.0.0.1:6379> PFADD mykey2 i j z x c v b n m
(integer) 1
127.0.0.1:6379> PFCOUNT mykey2
(integer) 9
# 合并兩組
127.0.0.1:6379> PFMERGE mykey3 mykey mykey2
OK
# 看并集的數量
127.0.0.1:6379> PFCOUNT mykey3
(integer) 15Bitmap
模擬上班打卡
# 記錄數據 每天是否打卡 打卡1 未打卡0
127.0.0.1:6379> setbit sign 0 1
127.0.0.1:6379> setbit sign 1 0
127.0.0.1:6379> setbit sign 2 0
127.0.0.1:6379> setbit sign 3 1
127.0.0.1:6379> setbit sign 4 1
127.0.0.1:6379> setbit sign 5 1
127.0.0.1:6379> setbit sign 6 0# 查看某天的是否打卡
127.0.0.1:6379> getbit sign 5# 打卡天數(1)
127.0.0.1:6379> BITCOUNT sign事務
Redis事務本質: 一組命令的集合！ 一個事務中所有的命令都會被序列化，在事務執行的過程中，會按照順序執行！
一次性、順序性、排他性！執行一些列的命令
------ 隊列 set set set 執行 ------
Redis事務沒有隔離級別的概念
所有的命令在事務中，并沒有直接被執行，只有發起執行命令的時候才會執行！Exec
原子性：要么同時成功,要么同時失敗
但是redis單條命令是保證原子性的，但是事務不保證原子性
Redis的事務
- 開啟事務(multi)
- 命令入隊(…)
- 執行事務(exec)
# 開啟事務
127.0.0.1:6379> multi
OK
# 命令入隊
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> set k4 v4
QUEUED
127.0.0.1:6379> get k3
QUEUED
# 執行事務 一次性、順序性、排他性
127.0.0.1:6379> exec
1) OK
2) OK
3) OK
4) OK
5) "v3"############################################################
# 取消事務
127.0.0.1:6379> DISCARD
# 事務中所有的命令都不執行
127.0.0.1:6379> get k1
(nil)
# 編譯期異常(代碼有問題！命令有錯)，事務中所有的命令都不會被執行
# 開啟事務
127.0.0.1:6379> multi
127.0.0.1:6379> set k1 v1
127.0.0.1:6379> set k2 v2
# 錯誤的命令
127.0.0.1:6379> getset k2
(error) ERR wrong number of arguments for 'getset' command
127.0.0.1:6379> set k3 v3
# 執行事務報錯！
127.0.0.1:6379> EXEC
(error) EXECABORT Transaction discarded because of previous errors.
# 所有的命令都不會執行
127.0.0.1:6379> get k2
(nil)# 運行時異常(1/0),如果事務隊列中存在語法性，那么執行命令的時候，其他的命令是可以正常執行的，錯誤命令會拋出異常！
# 設置一個字符串
127.0.0.1:6379> set k1 "v1"
# 開啟事務
127.0.0.1:6379> MULTI
# 自增1 錯誤命令，執行時候會失敗
127.0.0.1:6379> INCR k1
127.0.0.1:6379> set k2 v2
127.0.0.1:6379> get k2
127.0.0.1:6379> EXEC
# 雖然第一條命令報錯了 但是其他的會執行正常成功了
1) (error) ERR value is not an integer or out of range
監控！！watch
悲觀鎖：
- 認為什么時候都會出現問題，無論做什么都會加鎖
樂觀鎖：
-
很樂觀，認為什么時候都不會出現問題，所以不會上鎖！更新的時候去判斷一下，在此期間是否有人修改過這個數據，version！
-
獲取version
-
更新的時候比較version
Redis監視測試
# 測試單線程
127.0.0.1:6379> set money 100
127.0.0.1:6379> set out 0
# 監視money對象
127.0.0.1:6379> watch money
# 事務正常結束，數據期間沒有發生變動，這個時候就會正常執行成功
127.0.0.1:6379> MULTI
127.0.0.1:6379> DECRBY money 20
127.0.0.1:6379> INCRBY out 20
127.0.0.1:6379> exec
1) (integer) 80
2) (integer) 20
# 測試多線程修改值，使用watch可以當作redis的樂觀鎖
# 監視money
127.0.0.1:6379> watch money
127.0.0.1:6379> multi
127.0.0.1:6379> DECRBY money 10
127.0.0.1:6379> INCRBY out 10
# 執行之前 另外一個線程修改了值，就會執行失敗
127.0.0.1:6379> EXEC
(nil)# 解鎖的操作
# UNWATCH EXEC DISCARD 都可以進行解鎖Jedis
什么是jedis？ java redis 是Redis官方推薦的java連接的開發工具！ 使用Java操作Redis中間件！ 如果使用Java操作redis，那么一定要對Jedis十分的熟悉
導入依賴
<!-- 導入jedis的包 --><dependency><groupId>redis.clients</groupId><artifactId>jedis</artifactId><version>3.2.0</version></dependency><!--fastjosn--><dependency><groupId>com.alibaba</groupId><artifactId>fastjson</artifactId><version>1.2.62</version></dependency>
編碼測試
- 連接數據庫
- 操作命令
- 斷開連接
public class TestJedis {public static void main(String[] args) {// new jedis對象Jedis jedis = new Jedis("127.0.0.1",6379);jedis.flushDB();// jedis 所有的命令都是之前學過的String ping = jedis.ping();System.out.println(ping);}
事務
public class TestJedis {public static void main(String[] args) {// new jedis對象Jedis jedis = new Jedis("127.0.0.1",6379);jedis.flushDB();JSONObject jsonObject = new JSONObject();jsonObject.put("hello","suj");jsonObject.put("name","kiki");// 事務開啟Transaction multi = jedis.multi();String s = jsonObject.toString();try {multi.set("user1",s);multi.set("user2",s);int i = 1/0; // 代碼拋出異常 事務執行失敗multi.exec(); // 執行事務}catch (Exception e){multi.discard(); // 如果失敗 放棄事務e.printStackTrace();}finally {System.out.println(jedis.get("user1"));System.out.println(jedis.get("user2"));multi.close(); // 關閉連接}}
}SpringBoot整合
? SpringBoot操作數據:spring-data jpa jdbc mongodbredis !
? SpringData 也是和SpringBoot齊名的項目!
說明:在SpringBoot2.x之后，原來使用的jedis 被替換為了lettuce?
jedis:采用的直連，多個線程操作的話，是不安全的，如果想要避免不安全的，使用jedis pool連接池!更像BIO模式
lettuce:采用netty，實例可以再多個線程中進行共享，不存在線程不安全的情況!可以減少線程數據了，更像NIO模式
源碼分析
@Configuration(proxyBeanMethods = false)
@ConditionalOnClass(RedisOperations.class)
@EnableConfigurationProperties(RedisProperties.class)
@Import({ LettuceConnectionConfiguration.class, JedisConnectionConfiguration.class })
public class RedisAutoConfiguration {@Bean // 我們可以自己定義一個RedisTemplate@ConditionalOnMissingBean(name = "redisTemplate")public RedisTemplate<Object, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory)throws UnknownHostException {// 默認的RedisTemplate沒有過多的設置，redis對象都是需要序列化！// 兩個泛型都是object的類型 我們后面使用需要強制轉化<String,Object>RedisTemplate<Object, Object> template = new RedisTemplate<>();template.setConnectionFactory(redisConnectionFactory);return template;}@Bean@ConditionalOnMissingBean // 由于String是redis中最常用的類型，所以單獨提出一個beanpublic StringRedisTemplate stringRedisTemplate(RedisConnectionFactory redisConnectionFactory)throws UnknownHostException {StringRedisTemplate template = new StringRedisTemplate();template.setConnectionFactory(redisConnectionFactory);return template;}}
整合SpringBoot Redis
導入redis
<!-- 操作redis -->
<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency><groupId>io.lettuce</groupId><artifactId>lettuce-core</artifactId><version>5.3.2.RELEASE</version><scope>compile</scope>
</dependency>
配置連接
spring:redis:host: 127.0.0.1 # 默認的就是這個port: 6379
測試
@Autowiredprivate RedisTemplate redisTemplate;@Testvoid contextLoads() {/*** 五大基本類型* opsForValue 字符串* opsForList list集合* opsForSet set集合* opsForHash hash哈希* opsForZSet 有序集合** expirAt 超時*/// 獲取redis的連接對象// RedisConnection connection = redisTemplate.getConnectionFactory().getConnection();// connection.flushDb();// connection.flushAll();redisTemplate.opsForValue().set("mykey","susu");System.out.println(redisTemplate.opsForValue().get("mykey"));}
實體類對象需要實例化 !!!
自己編寫一個RedisTemplate
@Configuration
public class RedisConfig {/*** 功能描述: 自己定義一個RedisTemplate* @Param: [redisConnectionFactory]* @Return: org.springframework.data.redis.core.RedisTemplate<java.lang.String,java.lang.Object>* @Author: Jsu*/@Bean@SuppressWarnings("all")public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory factory){// 為了方便 一般直接使用<String, Object>RedisTemplate<String, Object> template = new RedisTemplate();template.setConnectionFactory(factory);// json 序列化配置Jackson2JsonRedisSerializer jsonRedisSerializer = new Jackson2JsonRedisSerializer(Object.class);ObjectMapper om = new ObjectMapper();om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);om.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);jsonRedisSerializer.setObjectMapper(om);// string 的序列化StringRedisSerializer stringRedisSerializer = new StringRedisSerializer();// key采用string的序列化方式template.setKeySerializer(stringRedisSerializer);// hash的key也采用string的序列化方式template.setHashKeySerializer(stringRedisSerializer);// value的序列化方式采用jacksontemplate.setValueSerializer(jsonRedisSerializer);// hash的value的序列化方式采用jacksontemplate.setHashValueSerializer(jsonRedisSerializer);template.afterPropertiesSet();return template;}
}
Redis.onf 詳解
單位
配置文件unit單位對大小寫不敏感
包含 好比我們學習spring import include
網絡
bind 127.0.0.1 #綁定的ip
protected-mode yes #保護模式
port 6379 #端口設置
通用GENERAL
daemonize yes#以守護進程的方式運行，默認是no，我們需要自己開啟為yes !
pidfile /var/run/redis_6379.pid #如果以后臺的方式運行，我們就需要指定一個pid文件!
# 日志
# specify the server verbosity leve1.
# This can be one of:
# debug (a lot of information，useful for development/testing)
# verbose (many rarely useful info，but not a mess like the debug leve1)
# notice (moderately verbose，what you want in production probably)生產環境
# warning (only very important / critica7 messages are logged)
1ogleve1 notice
1ogfile "" #日志的文件位置名
databases 16 #數據庫的數量，默認是16個數據庫
always-show-logo yes#是否總是顯示LOGO
快照
持久化，在規定的時間內，執行了多少次操作，則會持久化到文件.rdb.aof
redis是內存數據庫，如果沒有持久化，那么數據斷電及失!
#如果900s內，如果至少有一個1 key進行了修改，我們及進行持久化操作
save 900 1
#如果300s內，如果至少10 key進行了修改，我們及進行持久化操作
save 300 10
#如果60s內，如果至少10000 key進行了修改，我們及進行持久化操作
save 60 1000o
#我們之后學習持久化，會自己定義這個測試!
stop-writes-on-bgsave-error yes#持久化如果出錯，是否還需要繼續工作!
rdbcompression yes#是否壓縮rdb文件，需要消耗一些cpu資源!
rdbchecksum yes #保存rdb文件的時候，進行錯誤的檢查校驗!
dir ./# rdb文件保存的目錄!
SECURITY安全
可以在這里設置redis的密碼，默認是沒有密碼!
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> config get requirepass #獲取redis的密碼
1) "requirepass"
2)""
127.0.0.1:6379> config set requirepass "123456" #設置redis的密碼
127.0.0.1:6379> config get requirepass #發現所有的命令都沒有權限了
(error)NOAUTH Authentication required .
127.0.0.1:6379> ping
(error)NOAUTH Authentication required.
127.0.0.1:6379> auth 123456 #使用密碼進行登錄!
127.0.0.1:6379> config get requirepass
1) "requirepass"
2) "123456"
限制CLIENTS
maxclients 10000 #設置能連接上redis的最大客戶端的數量
maxmemory <bytes> # redis 配置最大的內存容量
maxmemory-policy noeviction #內存到達上限之后的處理策略1、volatile-1ru:只對設置了過期時間的key進行LRU（默認值）2、allkeys-lru :刪除1ru算法的key3、volatile-random:隨機刪除即將過期key4、a11keys-random:隨機刪除5、volatile-ttl :刪除即將過期的6、noeviction :永不過期，返回錯誤
APPEND ONLY模式aof配置
appendonly no #默認是不開啟aof模式的，默認是使用rdb方式持久化的，在大部分所有的情況下，rdb完全夠用!
appendfilename "appendonly.aof" #持久化的文件的名字
#appendfsync always #每次修改都會sync。消耗性能
appendfsync everysec #每秒執行一次sync，可能會丟失這1s的數據!
#appendfsync no #不執行sync，這個時候操作系統自己同步數據，速度最快!
Redis持久化
面試問到什么是持久化？ RDB和AOF
Redis是內存數據庫，如果不講內存中的數據庫狀態保存到磁盤，那么一旦服務器進程退出以后，服務器中的數據庫也會消失，所以Redis提供了持久化的功能
RDB(Redis DateBase)
什么是RDB
簡單來講：就是滿足save的規則、執行flushall命令退出redis，會產生dump.rdb文件! 該文件存儲了數據內容，可以通過此文件進行數據的恢復！！
在指定的時間間隔內將內存中的數據集快照寫入磁盤，也就是行話講的Snapshot快照，它恢復時是將快照文件直接讀到內存里。
Redis會單獨創建( fork )一個子進程來進行持久化，會先將數據寫入到一個臨時文件中，待持久化過程都結束了，再用這個臨時文件替換上次持久化好的文件。整個過程中，主進程是不進行任何IO操作的。這就確保了極高的性能。如果需要進行大規模數據的恢復，且對于數據恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺點是最后一次持久化后的數據可能丟失。我們默認的就是RDB，一般情況下不需要修改這個配置!有時候在生產環境我們會將這個文件進行備份!
rdb保存的文件是dump.rdb都是在我們的配置文件中快照中進行配置的!
觸發機制
1、save的規則滿足的情況下，會自動觸發rdb規則
2、執行flushall命令，也會觸發我們的rdb規則!
3、退出redis，也會產生rdb文件!
備份就自動生成一個dump.rdb
如何恢復rdb文件
1、只需要將rdb文件放在我們redis啟動目錄下面就可以了，redis啟動是會自動檢查dump.rdb 恢復其中的數據！
2、查看需要存在的位置
127.0.0.1:6379> config get dir
1"dir"
2) "/usr/loca1/bin"#如果在這個目錄下存在dump.rdb文件，啟動就會自動恢復其中的數據一般使用默認的基本配置就夠了 但是我們還是要學習！！
優點:
1、適合大規模的數據恢復!
2、對數據的完整性要不高!
缺點:
2、fork進程的時候，會占用一定的內容空間!!
1、需要一定的時間間隔進程操作!如果redis意外宕機了，這個最后一次修改數據就沒有的了
AOF(Append Only File)
將我們的所有的命令都記錄下來，history，恢復的時候就把這個文件全部執行一遍
是什么？
以日志的形式來記錄每個寫操作，將Redis執行過的所有指令記錄下來（讀操作不記錄），只許追加文件但不可以改寫文件，redis啟動之初會讀取該文件重新構建數據，換言之，redis重啟的話就根據日志文件的內容將寫指令從前到后執行一次以完成數據的恢復工作
簡單講: 日志形式記錄每個操作，當被惡意修改的時候 redis就打不開了 需要使用redis-check-aof --fix 工具可以恢復，但是！！ 被惡意修改的命令會刪除！
Aof保存的是appendonly.aof文件
重寫規則說明！
aof默認就是文件的無限追加，文件會越來越大!
如果aof文件大于64m，太大了! fork一個新的進程來將我們的文件進行重寫!
具體代碼修改請往上翻找config中的內容
優點︰
1、每一次修改都同步，文件的完整會更加好!
2、每秒同步一次，可能會丟失—秒的數據
3、從不同步，效率最高的!
缺點︰
1、相對于數據文件來說，aof遠遠大于rdb，修復的速度也比rdb慢!
2、Aof運行效率也要比rdb慢，所以我們redis默認的配置就是rdb持久化
擴展∶
1、RDB持久化方式能夠在指定的時間間隔內對你的數據進行快照存儲
2、AOF持久化方式記錄每次對服務器寫的操作，當服務器重啟的時候會重新執行這些命令來恢復原始的數據，AOF命令以Redis 協議追加保存每次寫的操作到文件末尾，Redis還能對AOF文件進行后臺重寫，使得AOF文件的體積不至于過大。3、只做緩存，如果你只希望你的數據在服務器運行的時候存在，你也可以不使用}任何持久化
4、同時開啟兩種持久化方式
- 在這種情況下，當redis重啟的時候會優先載入AOF文件來恢復原始的數據，因為在通常情況下AOF
- RDB的數據不實時，同時使用兩者時服務器重啟也只會找AOF文件，那要不要只使用AOF呢?作者建議不要，因為RDB更適合用于備份數據庫(AOF在不斷變化不好備份），快速重啟，而且不會有AOF可能潛在的Bug，留著作為一個萬一的手段。
5、性能建議
-
因為RDB文件只用作后備用途，建議只在Slave上持久化RDB文件，而且只要15分鐘備份一次就夠了，只保留save 9001這條規則。
-
如果Enable AOF，好處是在最惡劣情況下也只會丟失不超過兩秒數據，啟動腳本較簡單只load自己的AOF文件就可以了，代價一是帶來了持續的IO，二是AOF rewrite的最后將rewrite 討程中產生的新數據寫到新文件造成的阻塞幾乎是不可避免的。只要硬盤許可，應該盡量減少AOF rewrite的頻率，AOF重寫的基礎大小默認值64M太小了，可以設到5G以上，默認超過原大小100%大小重寫可以改到適當的數值。
-
如果不Enable AOF，僅靠Master-Slave Repllcation實現高可用性也可以，能省掉一大筆IO，也減少了rewrite時帶來的系統波動。代價是如果Master/Slave同時倒掉，會丟失十幾分鐘的數據，啟動腳本也要比較兩個Master/Slave中的RDB文件，載入較新的那個，微博就是這種架構。
Redis主從賦值
概念
? 主從賦值，是指將一臺Redis服務器的數據，復制到其他的Redis服務器上。前者稱為主節點(master/leader)，后者稱為從節點(slave/follower)；數據的復制是單向的，只能由主節點到從節點Master以寫為主，Slave以讀為主
默認情況下，每臺Redis服務器都是主節點
且一個主節點可以有多個從節點(或沒有從節點)，但一個從節點只能有一個主節點
主從復制的作用主要包括：
1、數據冗余：主從復制實現了數據的熱備份，是持久化之外的一種數據冗余方式
2、故障恢復：當主節點出現問題時，可以由從節點提供服務，實現快速的故障恢復；實際上是一種服務的冗余。
3、負載均衡：在主從復制的基礎上，配合讀寫分離，可以由主節點提供寫服務，從結點提供讀服務(即寫Redis數據時應用連接主節點，讀Redis數據時應用連接從節點)，分擔服務器重載；尤其是在寫少讀多的場景下，通過多個從結點分擔讀負載，可以大大提高redis服務的并發量
4、高可用(集群)基石：除了上述作用以外，主從復制還是哨兵和集群能后實施的基礎，因此說主從復制是redis高可用的基礎
一般來講，要將Redis運用于工程項目中，只使用一臺Redis是萬萬不能的(宕機)，原因如下：
1、從結構上來講，單個redis服務器會發生單點故障，并且一臺服務器需要處理所有的請求負載，壓力較大。
2、從容量上，單個Redis服務器內存容量有限，就算一臺Redis服務器內存容量為256G，也不能講所有的內存用作Redis存儲內存，一般來說，單臺redis最大使用內存不應該超過20G.
電商網站上的商品，都是一次上傳，無數次的瀏覽，專業來講就是“多讀少寫”。
可以使用下面這種架構：
主從復制，讀寫分離!80%的情況下都是在進行讀操作!減緩服務器的壓力!架構中經常使用!一主二從!
只要在公司中，主從復制就是必須要使用的，因為在真實的項目中不可能單機使用Redis
環境配置
只配置從庫，不用配置主庫
127.0.0.1:6379> info replication # 查看當前庫的信息
# Replication
role:master # 角色 master
connected_slaves:0 # 沒有從機
master_replid:3a0c53fe0992786e38d4bc7fd48ac5ab50215fd1
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0復制三個配置文件，然后修改對應的信息
1、端口 （6379，6380，6381）
2、pid名字 pidfile /var/run/redis（6379，6380，6381）.pid
3、log文件名字 （logfile “（6379，6380，6381）.log”）
4、dump.rdb名字 dbfilename dump（6379，6380，6381）.rdb
修改完成以后，啟動我們的三個redis服務器，可以通過進程查看
一主二從
默認環境下，每臺Redis服務器都是主節點;我們一般情況下只配置從機就好了
認老大！ 一主（79）二從（80，81）
127.0.0.1:6380>SLAVEOF 127.0.0.1 6379#SLAVEOF host 6379找誰當自己的老大!
OK
127.0.0.1:6380> info replication
#Replication
role:slave#當前角色是從機
master_host:127.0.0.1#可以的看到主機的信息
master_port :6379
master_link_status: up
master_last_io_seconds_ago: 3
master_sync_in_progress:0
slave_repl_offset:14
slave_priority:100
slave_read_on1y:1
connected_slaves :0
master_replid:a81be8dd257636b2d3e7a9f595e69d73ff03774e
master_replid2: 000000o0000o0oooo0oo0000000oo0oo00000ooo
master_rep1_offset:14
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
rep1_backlog_first_byte_offset:1
rep1_backlog_histlen : 14
#在主機中查看!
127.0.0.1:6379> info replication
#Replication
role:master
connected_slaves:1#多了從機的配置
master_replid:a81be8dd257636b2d3e7a9f595e69d73ff03774e
master_replid2:0000000000000000000o0000000000000000000o
master_repl_offset:42
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
rep1_backlog_first_byte_offset:1
repl_backlog_histlen:42
如果兩個都配置好了，從機變成2
細節
主機可以寫，從機只能讀！！主機所有的信息和數據，都會自動被從機保存
主機寫
從機只能讀
測試∶主機斷開連接，從機依舊連接到主機的，但是沒有寫操作，這個時候，主機如果回來了，從機依舊可以直接獲取到主機寫的信息!
如果是使用命令行，來配置的主從，這個時候如果重啟了。就會變回主機!只要變為從機，立馬就會從主機中獲取值!
復制原理
Slave啟動成功連接到master后會發送一個sync同步命令
Master接到命令，啟動后臺的存盤進程，同時收集所有接收到的用于修改數據集命令，在后臺進程執行完畢之后，master將傳送整個數據文件到slave，并完成一次完全同步。
全量復制:而slave服務在接收到數據庫文件數據后，將其存盤并加載到內存中。
增量復制:Master繼續將新的所有收集到的修改命令依次傳給slave，完成同步
但是只要是重新連接master，一次完全同步(全量復制）將被自動執行!我們的數據一定可以在從機中看到!
如果沒有老大了，這個時候能不能選擇一個老大出來呢?手動!
謀朝篡位
如果主機斷開了連接，我們可以使用SLAVEOF no one讓自己變成主機!其他的節點就可以手動連接到最新的這個主節點（手動）!如果這個時候老大修復了，那就重新連接!
哨兵模式
概述
主從切換技術的方法是︰當主服務器宕機后，需要手動把一臺從服務器切換為主服務器，這就需要人工干預，費事費力，還會造成一段時間內服務不可用。這不是一種推薦的方式，更多時候，我們優先考慮哨兵模式。Redis從2.8開始正式提供了Sentinel（哨兵）架構來解決這個問題。
謀朝篡位的自動版，能夠后臺監控主機是否故障，如果故障了根據投票數自動將從庫轉換為主庫。
哨兵模式是一種特殊的模式，首先Redis提供了哨兵的命令，哨兵是一個獨立的進程，作為進程，它會獨立運行。其原理是哨兵通過發送命令，等待Redis服務器響應，從而監控運行的多個Redis實例
這里的哨兵有兩個作用
- 通過發送命令，讓Redis服務器返回監控其運行狀態，包括主服務器和從服務器。
- 當哨兵監測到master宕機，會自動將slave切換成master，然后通過發布訂閱模式通知其他的從服務器，修改配置文件，讓它們切換主機。
然而一個哨兵進程對Redis服務器進行監控，可能會出現問題，為此，我們可以使用多個哨兵進行監控。各個哨兵之間還會進行監控，這樣就形成了多哨兵模式。
? 假設主服務器宕機，哨兵1先檢測到這個結果，系統并不會馬上進行failover過程，僅僅是哨兵1主觀的認為主服務器不可用，這個現象成為主觀下線。當后面的哨兵也檢測到主服務器不可用，并且數量達到一定值時，那么哨兵之間就會進行一次投票，投票的結果由一個哨兵發起，進行failover[故障轉移]操作。切換成功后，就會通過發布訂閱模式，讓各個哨兵把自己監控的從服務器實現切換主機，這個過程稱為客觀下線。
測試！
我們目前的狀態是 一主二從！
1、配置哨兵配置文件sentinel.conf
#sentinel monitor 被監控的名稱 host port 1
sentinel monitor myredis(127.0.0.1 6379 1
后面的這個數字1，代表主機掛了，slave投票看讓誰接替成為主機，票數最多的，就會成為主機!
2、啟動哨兵，重新選定主機
如果主機此時回來了，只能歸并到新的主機下，當做從機，這就是哨兵模式的規則!
哨兵模式
優點∶
1、哨兵集群，基于主從復制模式，所有的主從配置優點，它全有
2、主從可以切換，故障可以轉移，系統的可用性就會更好
3、哨兵模式就是主從模式的升級，手動到自動，更加健壯!
缺點︰
1、Redis不好啊在線擴容的，集群容量一旦到達上限，在線擴容就十分麻煩!
2、實現哨兵模式的配置其實是很麻煩的，里面有很多選擇!
哨兵模式的全部配置
# Example sentinel.conf
# 哨兵sentinel實例運行的端口默認26379
port 26379
# 哨兵sentinel的工作目錄
dir /tmp# 哨兵sentinel監控的redis主節點的ip port
# master-name可以自己命名的主節點名字只能由字母A-z、數字O-9、這三個字符".-_"組成。
# quorum配置多少個sentine1哨兵統一認為master主節點失聯那么這時客觀上認為主節點失聯了
#sentine7 monitor <master-name> <ip><redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2# 當在Redis實例中開啟了requirepass foobared授權密碼這樣所有連接Redis實例的客戶端都要提供密碼
# 設置哨兵sentinel連接主從的密碼注意必須為主從設置一樣的驗證密碼
# sentine7 auth-pass <master-name> <password>
sentine7 auth-pass mymaster MySUPER--secret-0123passwOrd# 指定多少毫秒之后主節點沒有應答哨兵sentine1此時哨兵主觀上認為主節點下線默認30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentine1 down-after-mi17iseconds mymaster 30000# 這個配置項指定了在發生failover主備切換時最多可以有多少個slave同時對新的master進行同步
# 這個數字越小，完成failover所需的時間就越長，
# 但是如果這個數字越大，就意味著越多的slave因為replication而不可用。
# 可以通過將這個值設為1來保證每次只有一個slave處于不能處理命令請求的狀態。
# sentinel para1le1-syncs <master-name> <nums1aves>
sentine1 parallel-syncs mymaster 1# 故障轉移的超時時間failover-timeout可以用在以下這些方面:
# 1．同一個sentine1對同一個master兩次failover之間的間隔時間。
# 2，當一個slave從一個錯誤的master那里同步數據開始計算時間。直到slave被糾正為向正確的master那里同步數據時。
# 3.當想要取消一個正在進行的failover所需要的時間。
# 4.當進行failover時，配置所有slaves指向新的master所需的最大時間。不過，即使過了這個超時,slaves依然會被正確配置為指向master，但是就不按parallel-syncs所配置的規則來了
#默認三分鐘
#sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000# SCRIPTS EXECUTION
# 配置當某一事件發生時所需要執行的腳本，可以通過腳本來通知管理員，例如當系統運行不正常時發郵件通知相關人員。
# 對于腳本的運行結果有以下規則:
# 若腳本執行后返回1，那么該腳本稍后將會被再次執行，重復次數目前默認為10
# 若腳本執行后返回2，或者比2更高的一個返回值，腳本將不會重復執行。
# 如果腳本在執行過程中由于收到系統中斷信號被終止了，則同返回值為1時的行為相同。
# 一個腳本的最大執行時間為60s，如果超過這個時間，腳本將會被一個SIGKILL信號終止，之后重新執行#通知型腳本:當sentinel有任何警告級別的事件發生時（比如說redis實例的主觀失效和客觀失效等等，將會去調用這個腳本，這時這個腳本應該通過郵件，SMS等方式去通知系統管理員關于系統不正常運行的信息。調用該腳本時，將傳給腳本兩個參數，一個是事件的類型，一個是事件的描述。如果sentine1.conf配置文件中配置了這個腳本路徑，那么必須保證這個腳本存在于這個路徑，并且是可執行的，否則sentine1無法正常啟動成功。#通知腳本
#shell編程
#sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /var/redis/notify.sh# 客戶端重新配置主節點參數腳本
# 當一個master由于failover而發生改變時，這個腳本將會被調用，通知相關的客戶端關于master地址已經發生改變的信息。
# 以下參數將會在調用腳本時傳給腳本:
# <master-name> <role> <state> <from-ip><from-port> <to-ip> <to-port>
# 目前<state>總是“failover”，
# <role>是“leader”或者"“observer”中的一個。
# 參數from-ip，from-port，to-ip，to-port是用來和舊的master和新的master(即舊的s7ave)通信的#這個腳本應該是通用的，能被多次調用，不是針對性的。
# sentine7 client-reconfig-script <master-name> <script-path>
sentine7l client-reconfig-script mymaster/var/redis/reconfig.sh #一般都是由運維來配置!
Redis緩存穿透和雪崩(面試常問)
服務的高可用問題
Redis緩存的使用，極大的提升了應用程序的性能和效率，特別是數據查詢方面。但同時，它也帶來了一些問題。其中，最要害的問題，就是數據的一致性問題，從嚴格意義上講，這個問題無解。如果對數據的一致性要求很高，那么就不能使用緩存。
另外的一些典型問題就是，緩存穿透、緩存雪崩和緩存擊穿。目前，業界也都有比較流行的解決方案。
緩存穿透(查不到)
概念
緩存穿透的概念很簡單，用戶想要查詢一個數據，發現redis內存數據庫沒有，也就是緩存沒有命中，于
是向持久層數據庫查詢。發現也沒有，于是本次查詢失敗。當用戶很多的時候，緩存都沒有命中(秒
殺!），于是都去請求了持久層數據庫。這會給持久層數據庫造成很大的壓力，這時候就相當于出現了
緩存穿透。
解決方案
緩存空對象
當存儲層不命中后，即使返回的空對象也將其緩存起來，同時會設置一個過期時間，之后再訪問這個數
據將會從緩存中獲取，保護了后端數據源;
但是這種方法會存在兩個問題:
1、如果空值能夠被緩存起來，這就意味著緩存需要更多的空間存儲更多的鍵，因為這當中可能會有很多
的空值的鍵;
2、即使對空值設置了過期時間，還是會存在緩存層和存儲層的數據會有一段時間窗口的不一致，這對于
需要保持一致性的業務會有影響。
緩存擊穿(量太大，緩存過期)
概述
這里需要注意和緩存擊穿的區別，緩存擊穿，是指一個key非常熱點，在不停的扛著大并發，大并發集中對這一個點進行訪問，當這個key在失效的瞬間，持續的大并發就穿破緩存，直接請求數據庫，就像在一個屏障上鑿開了一個洞。
當某個key在過期的瞬間，有大量的請求并發訪問，這類數據一般是熱點數據，由于緩存過期，會同時訪問數據庫來查詢最新數據，并且回寫緩存，會導使數據庫瞬間壓力過大。
解決方案
設置熱點數據永不過期
從緩存層面來看，沒有設置過期時間，所以不會出現熱點key過期后產生的問題。
加互斥鎖
分布式鎖∶使用分布式鎖，保證對于每個key同時只有一個線程去查詢后端服務，其他線程沒有獲得分布式鎖的權限，因此只需要等待即可。這種方式將高并發的壓力轉移到了分布式鎖，因此對分布式鎖的考驗很大。
緩存雪崩
概念
緩存雪崩，是指在某一個時間段，緩存集中過期失效。Redis宕機!
產生雪崩的原因之一，比如在寫本文的時候，馬上就要到雙十二零點，很快就會迎來一波搶購，這波商品時間比較集中的放入了緩存，假設緩存一個小時。那么到了凌晨一點鐘的時候，這批商品的緩存就都過期了。而對這批商品的訪問查詢，都落到了數據庫上，對于數據庫而言，就會產生周期性的壓力波峰。于是所有的請求都會達到存儲層，存儲層的調用量會暴增，造成存儲層也會掛掉的情況。
其實集中過期，倒不是非常致命，比較致命的緩存雪崩，是緩存服務器某個節點宕機或斷網。因為自然
形成的緩存雪崩，一定是在某個時間段集中創建緩存，這個時候，數據庫也是可以頂住壓力的。無非就
是對數據庫產生周期性的壓力而已。而緩存服務節點的宕機，對數據庫服務器造成的壓力是不可預知
的，很有可能瞬間就把數據庫壓垮。
解決方案
redis高可用
這個思想的含義是，既然redis有可能掛掉，那我多增設幾臺redis，這樣一臺掛掉之后其他的還可以繼續工作，其實就是搭建的集群。（異地多活!)
限流降級（在SpringCloud講解過!)
這個解決方案的思想是，在緩存失效后，通過加鎖或者隊列來控制讀數據庫寫緩存的線程數量。比如對某個key只允許一個線程查詢數據和寫緩存，其他線程等待。
數據預熱
數據加熱的含義就是在正式部署之前，我先把可能的數據先預先訪問一遍，這樣部分可能大量訪問的數據就會加載到緩存中。在即將發生大并發訪問前手動觸發加載緩存不同的key，設置不同的過期時間，讓緩存失效的時間點盡量均勻。
資料來源：
公眾號：狂神說
B站地址：https://www.bilibili.com/video/BV1S54y1R7SB
總結
以上是生活随笔為你收集整理的Redis --- 超级详细的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 连通性（相关练习）
- 下一篇： 口腔炎症是怎么引起的