許多web停用都將數(shù)據(jù)保存到RDBMS（關(guān)系型數(shù)據(jù)庫）中，應用服務器中讀取數(shù)據(jù)并在瀏覽器中顯示。但隨著數(shù)據(jù)量增大、訪問的集中，就會出現(xiàn)RDBMS的負擔加重，數(shù)據(jù)庫響應惡化，網(wǎng)站顯示延遲等重大影響。
Memcahe/redis是高性能的分布式內(nèi)存緩存服務器，通過緩存數(shù)據(jù)庫查詢結(jié)果，減少數(shù)據(jù)庫訪問次數(shù)，以提高動態(tài)web等應用速度，提高可擴展性。
簡而言之：緩存數(shù)據(jù)庫查詢結(jié)果，加快訪問速度，緩解數(shù)據(jù)庫壓力。
Nosql
非關(guān)系型數(shù)據(jù)庫（not only sql）
為彌補關(guān)系型數(shù)據(jù)庫的不足
以鍵值方式存儲數(shù)據(jù)
緩存數(shù)據(jù)庫
產(chǎn)品有redis、memcached、mongoDB
Memcache
特點
內(nèi)置內(nèi)存存儲方式（重啟操作系統(tǒng)會導致全部數(shù)據(jù)消失）
簡單的key/value存儲
不互相通信的分布式
緩存原理
檢查用戶請求的數(shù)據(jù)時緩存中是否存在，若存在直接返回，無需查詢數(shù)據(jù)庫。
若請求數(shù)據(jù)在緩存中查詢不到，去查詢數(shù)據(jù)庫，返回數(shù)據(jù)，同時把數(shù)據(jù)存儲到緩存中一份。
保持緩存的“新鮮性”，每當數(shù)據(jù)發(fā)生變化的時候，要同步更新緩存的信息，確保用戶不會在緩存取到舊的數(shù)據(jù)。
Redis
redis是一個開源的，使用C語言編寫的，支持網(wǎng)絡交互的，可基于內(nèi)存也可持久化的key-Value數(shù)據(jù)庫。
官網(wǎng)：redis.io
特點
豐富的數(shù)據(jù)結(jié)構(gòu)
支持持久化
支持事物（事物：一個完整的動作，要么全部執(zhí)行，要么什么都沒做。）
支持主從
安裝
從reids.io下載最新版redis-X.Y.Z.tar.gz后解壓。然后進入redis-X.Y.Z文件夾make即可。
# wget http://download.redis.io/releases/redis-4.0.9.tar.gz
# tar xzf redis-4.0.9.tar.gz -C /
# cd redis-4.0.9
# make若因缺包報錯，在安裝完缺失的包之后需重新解壓新包進行make安裝，若沒有編譯工具需要先安裝yum -y install gcc make
啟動redis（默認非daemon形式啟動）
# ./src/redis-server
指定配置文件啟動
# ./src/redis-server ../redis.conf設(shè)置開機啟動
1.# mkdir /etc/redis
2.# cp /redis-4.0.9/redis.conf /etc/redis/6379.conf啟動腳本
# vim /etc/init.d/redis
#!/bin/sh
# chkconfig: 2345 10 90
# description: Start and Stop redis
REDISPORT=6379
EXEC=/redis-4.0.9/src/redis-server
#（可更改）
CLIEXEC=/redis-4.0.9/src/redis-cli
#(可更改)
PIDFILE=/var/run/redis_${REDISPORT}.pid
CONF="/etc/redis/${REDISPORT}.conf"
case "$1" in
start)
if [ -f $PIDFILE ]
then
echo "$PIDFILE exists, process is already running or crashed"
else
echo "Starting Redis server..."
$EXEC $CONF & #（增加）
fi
;;
stop)
if [ ! -f $PIDFILE ]
then
echo "$PIDFILE does not exist, process is not running"
else
PID=$(cat $PIDFILE)
echo "Stopping ..."
$CLIEXEC -p $REDISPORT shutdown
while [ -x /proc/${PID} ]
do
echo "Waiting for Redis to shutdown ..."
sleep 1
done
echo "Redis stopped"
fi
;;
restart)
"$0" stop
sleep 3
"$0" start
;;
*)
echo "Please use start or stop as first argument"
;;syst
esac授權(quán)
# chmod 777 /etc/init.d/redis加入開機啟動
# chkconfig --add redis
# chkconfig redis on
# systemctl daemon-reload //重新加載自啟動系統(tǒng)啟動方式
# /etc/init.d/redis start 6
# systemctl start redis端口
默認服務端口為6379
測試
# ./src/redis-cli
127.0.0.1:6379> set name hello
OK
127.0.0.1:6379> get name
"hello"
127.0.0.1:6379> save //保存數(shù)據(jù)到磁盤
127.0.0.1:6379> shutdown //通過客戶端來關(guān)閉redis服務端 禁用數(shù)據(jù)結(jié)構(gòu)
redis 是一種高級的key:value存儲系統(tǒng)，它的value支持五種數(shù)據(jù)類型：
字符串（strings）
字符串列表（lists）
字符串集合（sets）
有序字符串集合（sorted sets）
哈希（hashes）
注意：
key不可太長，盡量不要超過1024字節(jié)，這樣不僅會小孩內(nèi)存，而且會降低查找效率。
key也不要太短，太短的話，key的可讀性會降低。
在項目中，建議key使用統(tǒng)一的命名格式。
redis持久化
開啟持久化功能后，重啟redis，數(shù)據(jù)會自動通過持久化文件恢復。
RDB（默認開啟）
在不同的時間點，將redis存儲的數(shù)據(jù)生成快照并存儲到磁盤等介質(zhì)上。RDB方式，是將redis某一時刻的數(shù)據(jù)持久化到磁盤中，是一種快照式的持久化方法。
redis在進行數(shù)據(jù)持久化的過程中，會先將數(shù)據(jù)寫入到一個臨時文件中，待持久化過程都結(jié)束，才會用這個臨時文件替換上次持久換文件。這種特性可讓我們隨時備份文件，因為快照文件總是完整可用的。
特點
周期性
不影響數(shù)據(jù)寫入
RDB會啟動子進程，備份所有數(shù)據(jù)。當前進程繼續(xù)提供數(shù)據(jù)讀寫，當備份完成替換老的備份文件。
高效，一次性還原所有數(shù)據(jù)
完美性較差
故障點到上一次備份之間的數(shù)據(jù)無法恢復。
查看RDB開啟狀態(tài)
vim /redis-4.0.9/redis.conf
dbfilename dump.rdb
#dbfilename：持久化數(shù)據(jù)存儲在本地的文件
dir ./
#dir：持久化數(shù)據(jù)存儲在本地的路徑，如果是在/redis/redis-3.0.6/src下啟動的redis-cli，則數(shù)據(jù)會存儲在當前src目錄下
save 900 1
save 300 10
save 60 10000
##snapshot觸發(fā)的時機，save <seconds> <changes>
##如下為900秒后，至少有一個變更操作，才會snapshot
##對于此值的設(shè)置，需要謹慎，評估系統(tǒng)的變更操作密集程度
##可以通過“save “””來關(guān)閉snapshot功能
#save時間，以下分別表示更改了1個key時間隔900s進行持久化存儲；更改了10個key300s進行存儲；更改10000個key60s進行存儲。
stop-writes-on-bgsave-error yes
##當snapshot時出現(xiàn)錯誤無法繼續(xù)時，是否阻塞客戶端“變更操作”，“錯誤”可能因為磁盤已滿/磁盤故障/OS級別異常等
rdbcompression yes
##是否啟用rdb文件壓縮，默認為“yes”，壓縮往往意味著“額外的cpu消耗”，同時也意味這較小的文件尺寸以及較短的網(wǎng)絡傳輸時間 AOF
AOF，英文是Append Only File ，即只允許追加不允許改寫的文件。
AOF，將redis執(zhí)行過得所有寫指令（每秒鐘），記錄在日志里，再次redis重新啟動時只要把這些寫指令從前到后再重復執(zhí)行一遍，就可實現(xiàn)數(shù)據(jù)恢復。
特點
實時性
完整性較好
體積大
記錄/刪除數(shù)據(jù)的指令，都會被記錄。恢復速度慢于RDB。
開啟AOF
vim /redis-4.0.9/redis.conf
appendonly yes
##此選項為aof功能的開關(guān)，默認為“no”，可以通過“yes”來開啟aof功能
##只有在“yes”下，aof重寫/文件同步等特性才會生效
appendfilename appendonly.aof
##指定aof文件名稱
appendfsync everysec
##指定aof操作中文件同步策略，有三個合法值：always everysec no,默認為everysec
no-appendfsync-on-rewrite no
##在aof-rewrite期間，appendfsync是否暫緩文件同步，"no"表示“不暫緩”，“yes”表示“暫緩”，默認為“no”
auto-aof-rewrite-min-size 64mb
##aof文件rewrite觸發(fā)的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才會觸發(fā)rewrite，默認“64mb”，建議“512mb”
auto-aof-rewrite-percentage 100
##相對于“上一次”rewrite，本次rewrite觸發(fā)時aof文件應該增長的百分比。
##每一次rewrite之后，redis都會記錄下此時“新aof”文件的大小(例如A)，那么當aof文件增長到A*(1 + p)之后
##觸發(fā)下一次rewrite，每一次aof記錄的添加，都會檢測當前aof文件的尺寸。默認的AOF持久化策略
每秒鐘fsync（把緩存中的寫指令記錄到磁盤中）一次，在這種情況下，redis，仍可以保持良好的處理性能，即使redis故障也只會丟失最近一秒的數(shù)據(jù)。
AOF日志修復
若在追加日志時，恰好遇到磁盤空間滿，inode滿或斷電等情況導致日志寫入不完整，redis并不會貿(mào)然加載這個有問題的AOF文件，而是報錯退出。
可使用redis的提供的redis-check-aof工具，可以用來進行日志修復。
1.備份被寫壞的AOF文件
2.運行redis-check-aof –fix進行修復
3.用diff -u來看下兩個文件的差異，確認問題點
4.重啟redis，加載修復后的AOF文件AOF重寫
AOF使用追加模式，若不做任何處理，AOF文件會越來越大，因此，redis提供了重寫機制（rewrite）機制。
文件重寫機制（rewrite）：當AOF文件大小超過所設(shè)定的閾值時，redis會啟動AOF的內(nèi)容壓縮，只保留可以恢復數(shù)據(jù)的最小指令集。
原理：
重寫即將開始之際，redis會創(chuàng)建（fork）一個“重寫子進程”，這個子進程會首先讀取現(xiàn)有的AOF文件，并將其包含的指令進行分析壓縮并寫入到一個臨時文件中。
與此同時，主工作進程會將新接收到的寫指令一邊累積到內(nèi)存緩沖區(qū)中，一邊繼續(xù)寫入到原有的AOF文件中，這樣做是保證原有的AOF文件的可用性，避免在重寫過程中出現(xiàn)意外。
當“重寫子進程”完成重寫工作后，它會給父進程發(fā)一個信號，父進程收到信號后就會將內(nèi)存中緩存的寫指令追加到新AOF文件中。
當追加結(jié)束后，redis就會用新AOF文件來代替舊AOF文件，之后再有新的寫指令，就都會追加到新的AOF文件中了。
通過AOF恢復數(shù)據(jù)
若意外執(zhí)行了FLUSHALL，導致redis內(nèi)存中數(shù)據(jù)被清空。只要redis配置了AOF持久化方式，且AOF文件還沒被重寫，可以執(zhí)行以下操作恢復。
暫停redis
編輯AOF文件將最后一行的FLUSHALL刪除
重啟redis
持久化選擇RDB和AOF的選擇方式
官方建議兩個同時使用這樣可以提供更可靠的持久化方案。
這種情況下redis重啟的話，會優(yōu)先采用AOF方式來進行數(shù)據(jù)恢復（AOF恢復數(shù)據(jù)完整度更高。）
AOF寫入數(shù)據(jù)快，RDB寫入速度慢
如果沒有數(shù)據(jù)持久化需求，可以關(guān)閉RDB和AOF方式，這樣的話redis將變成一個純內(nèi)存數(shù)據(jù)庫，就像memcache一樣。
redis主從、哨兵`
主從同步
redis同mysql一樣支持主從同步（同時也支持一主多從以及多級從結(jié)構(gòu)）
redis的主從同步是異步進行的，這種模式的優(yōu)點是主從同步不會影響主邏輯，也不會降低redis的處理性能。
使用主從結(jié)構(gòu)的原因
純碎的冗余備份
提升讀性能，比如很小號性能的SORT就可以有從服務器來承擔。
優(yōu)化
可以考慮關(guān)閉主服務器的數(shù)據(jù)持久化功能，只讓從服務器持久化，這樣可以提高主服務器的處理性能。
將從服務器設(shè)置為只讀模式，這樣可以避免從服務器數(shù)據(jù)被誤修改，但從服務器仍然可以接受CONRG指令，因此不應將從服務器直接暴露到不安全的網(wǎng)絡環(huán)境中。（如必須如此，那可以考慮給重要指令進行重命名。）
原理
1.如果設(shè)置了一個Slave，無論是第一次連接還是重連到Master，它都會發(fā)出一個SYNC命令；
2.當Master收到SYNC命令之后，會做兩件事：
a) Master執(zhí)行BGSAVE，即在后臺保存數(shù)據(jù)到磁盤（rdb快照文件）；
b) Master同時將新收到的寫入和修改數(shù)據(jù)集的命令存入緩沖區(qū)（非查詢類）；3.當Master在后臺把數(shù)據(jù)保存到快照文件完成之后，Master會把這個快照文件傳送給Slave，而Slave則把內(nèi)存清空后，加載該文件到內(nèi)存中；
4.而Master也會把此前收集到緩沖區(qū)中的命令，通過Reids命令協(xié)議形式轉(zhuǎn)發(fā)給Slave，Slave執(zhí)行這些命令，實現(xiàn)和Master的同步；
5.Master/Slave此后會不斷通過異步方式進行命令的同步，達到最終數(shù)據(jù)的同步一致；
6.需要注意的是Master和Slave之間一旦發(fā)生重連都會引發(fā)全量同步操作。但在2.8之后版本，也可能是部分同步操作。
部分復制
2.8開始，當Master和Slave之間的連接斷開之后，他們之間可以采用持續(xù)復制處理方式代替采用全量同步。
Master端為復制流維護一個內(nèi)存緩沖區(qū)（in-memory backlog），記錄最近發(fā)送的復制流命令；同時，Master和Slave之間都維護一個復制偏移量(replication offset)和當前Master服務器ID（Masterrun id）。當網(wǎng)絡斷開，Slave嘗試重連時：
a. 如果MasterID相同（即仍是斷網(wǎng)前的Master服務器），并且從斷開時到當前時刻的歷史命令依然在Master的內(nèi)存緩沖區(qū)中存在，則Master會將缺失的這段時間的所有命令發(fā)送給Slave執(zhí)行，然后復制工作就可以繼續(xù)執(zhí)行了；
b. 否則，依然需要全量復制操作；
sentinel
sentinel(哨兵)
Sentinel(哨兵)是用于監(jiān)控redis集群中Master狀態(tài)的工具，其已經(jīng)被集成在redis2.4+的版本中
setinel作用
1.Master狀態(tài)檢測
2.如果Master異常，則會進行Master-Slave切換，將其中一個Slave作為Master，將之前的Master作為Slave
3.Master-Slave切換后，master_redis.conf、slave_redis.conf和sentinel.conf的內(nèi)容都會發(fā)生改變，即master_redis.conf中會多一行slaveof的配置，sentinel.conf的監(jiān)控目標會隨之調(diào)換
sentinel工作方式
1.每個Sentinel以每秒鐘一次的頻率向它所知的Master，Slave以及其他 Sentinel 實例發(fā)送一個 PING 命令
2.如果一個實例（instance）距離最后一次有效回復 PING 命令的時間超過 down-after-milliseconds 選項所指定的值， 則這個實例會被 Sentinel 標記為主觀下線。
3.如果一個Master被標記為主觀下線，則正在監(jiān)視這個Master的所有 Sentinel 要以每秒一次的頻率確認Master的確進入了主觀下線狀態(tài)。 an>
4.當有足夠數(shù)量的 Sentinel（大于等于配置文件指定的值）在指定的時間范圍內(nèi)確認Master的確進入了主觀下線狀態(tài)， 則Master會被標記為客觀下線
5.在一般情況下， 每個 Sentinel 會以每 10 秒一次的頻率向它已知的所有Master，Slave發(fā)送 INFO 命令
6.當Master被 Sentinel 標記為客觀下線時，Sentinel 向下線的 Master 的所有 Slave 發(fā)送 INFO 命令的頻率會從 10 秒一次改為每秒一次
7.若沒有足夠數(shù)量的 Sentinel 同意 Master 已經(jīng)下線， Master 的客觀下線狀態(tài)就會被移除。 若 Master 重新向 Sentinel 的 PING 命令返回有效回復， Master 的主觀下線狀態(tài)就會被移除。
主觀下線和客觀下線
主觀下線：Subjectively Down，簡稱 SDOWN，指的是當前 Sentinel 實例對某個redis服務器做出的下線判斷。
客觀下線：Objectively Down， 簡稱 ODOWN，指的是多個 Sentinel 實例在對Master Server做出 SDOWN 判斷，并且通過 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下線判斷，然后開啟failover.
舉個栗子
環(huán)境
三臺服務器保持通訊暢通，并部署redis。
master slave1 slave2配置主從
master
# vim /etc/redis/6379.conf
master:
bind 0.0.0.0 //監(jiān)控本地所有網(wǎng)卡IP
protected-mode noslave1/2
# vim /etc/redis/6379.conf
bind 0.0.0.0
slaveof master_ip master_port //修改master_ip和port
protected-mode no 測試
# /redis-4.0.9/src/redis-cli
127.0.0.1:6379> info replicationmaster結(jié)果
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.0.113,port=6379,state=online,offset=2212,lag=1
slave1:ip=192.168.0.112,port=6379,state=online,offset=2212,lag=0
slave結(jié)果
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:192.168.0.109
master_port:6379
master_link_status:up配置sentienl
1.每臺機器上修改redis主配置文件設(shè)置：bind 0.0.0.0
2.每臺機器上修改sentinel配置文件：添加如下配置
# vim /redis-4.0.9/sentinel.conf
sentinel monitor mymaster MASTERIP 6379 2
//當集群中有2個sentinel認為master死了時，才能真正認為該master已經(jīng)不可用了。
sentinel down-after-milliseconds mymaster 3000 //單位毫秒
sentinel failover-timeout mymaster 10000
protected-mode no3.每臺機器啟動服務
# ./src/redis-sentinel sentinel.conf4.關(guān)閉主服務器，觀察從服務器狀態(tài)
# /redis-4.0.9/src/redis-cli
#info replication
