redis架構(gòu)詳解

一、redis特性
1.redis 是什么?
redis是基于內(nèi)存的可持久化的key-value數(shù)據(jù)庫
2.redis數(shù)據(jù)結(jié)構(gòu)類型?
value支持五種數(shù)據(jù)類型,字符串、字符串列表、字符串集合、有序集合、hashs
3.redis持久存儲方式
redis兩種持久化方式，RDB,和AOF
RDB: 將某一時刻的數(shù)據(jù)持久化到磁盤上，是一種快照式的持久方式, redis在進行持久化的過程中，會先將數(shù)據(jù)寫入臨時文件中，待持久化過程結(jié)束，會用這個臨時文件，替換上次持久化的文件，正是這種特性，讓我們可以隨時來進行備份，因為快照文件總是完整可用的。
原理:rdb方式持久化時，redis會fork出一個子進程進行持久化，主進程不會進行任何io操作,確保redis性能不會因持久化而降低,如果對數(shù)據(jù)不敏感且需要大規(guī)模恢復(fù)數(shù)據(jù)，可以使用這種方式

AOF: 將執(zhí)行過的寫指令記錄下來，在數(shù)據(jù)恢復(fù)時，將指令按照順序在執(zhí)行一邊.
我們通過配置redis.conf中的appendonly yes就可以打開AOF功能.如果有寫操作，就會追加到aof文件末尾,默認aof持久化策略是每秒鐘fsync一次將數(shù)據(jù)從緩存區(qū)域刷到磁盤上,因為在這種情況下，redis仍然可以保持很好的處理性能，即使redis故障，也只會丟失最近1秒鐘的數(shù)據(jù).
問題1: aof文件壞了怎么辦?
備份被寫壞的AOF文件
運行redis-check-aof –fix進行修復(fù)
用diff -u來看下兩個文件的差異，確認問題點
重啟redis，加載修復(fù)后的AOF文件
問題: aof追加方式文件會越來越大怎么處理?
redis提供了rewrite重寫機制，當aof文件大小超過設(shè)置閥值，就會啟動aof文件壓縮，保留恢復(fù)數(shù)據(jù)的最小指令集，在重寫時也是先寫入臨時文件
rewrite原理:在從寫開始時，任redis會fork出一個子進程,這個子進程會首先讀取現(xiàn)有的AOF文件，并將其包含的指令進行分析壓縮并寫入到一個臨時文件中.
與此同時，主工作進程會將新接收到的寫指令一邊累積到內(nèi)存緩沖區(qū)中，一邊繼續(xù)寫入到原有的AOF文件中，這樣做是保證原有的AOF文件的可用性，避免在重寫過程中出現(xiàn)意外,當“重寫子進程”完成重寫工作后，它會給父進程發(fā)一個信號，父進程收到信號后就會將內(nèi)存中緩存的寫指令追加到新AOF文件中,當追加結(jié)束后，redis就會用新AOF文件來代替舊AOF文件，之后再有新的寫指令，就都會追加到新的AOF文件中了

4.redis主從

主從優(yōu)點: 冗余備份，提升性能，讀寫分離，主從架構(gòu)異步進行，不會降低處理性能

主從原理:
從服務(wù)器向主服務(wù)器發(fā)送sync指令,當主服務(wù)器接到指令后,就會調(diào)用bgsave指令創(chuàng)建子進程專門用來進行持久化工作,也就是將主服務(wù)器上的數(shù)據(jù)寫入rdb。在數(shù)據(jù)持久化期間，主服務(wù)器將執(zhí)行的寫指令都緩存在內(nèi)存中。
在bgsave指令完成后，主服務(wù)器會講rdb文件發(fā)送給從服務(wù)器，從服務(wù)器將文件保存到磁盤上，然后讀到內(nèi)存中。這個動作完成后，主服務(wù)器會將這段時間緩存得到寫指令在以redis協(xié)議發(fā)送給從服務(wù)器.
注: 即使有多個從服務(wù)器發(fā)送sync指令，主服務(wù)器也只會執(zhí)行一次bgsave

5.redis事物

redis四個指令構(gòu)成redis事物處理的基礎(chǔ)
1.MULTI用來組裝一個事務(wù)；
2.EXEC用來執(zhí)行一個事務(wù)；
3.DISCARD用來取消一個事務(wù)；
4.WATCH用來監(jiān)視一些key，一旦這些key在事務(wù)執(zhí)行之前被改變，則取消事務(wù)的執(zhí)行

二、redis架構(gòu)
單機:

容量有限，處理能力有限，部署簡單，適合開發(fā)，或者不重要的數(shù)據(jù).

主從復(fù)制:

1、master/slave 角色
2、master/slave 數(shù)據(jù)相同
3、降低 master 讀壓力在轉(zhuǎn)交給從庫
問題：1、無法保證高可用；2、沒有解決 master 寫的壓力

哨兵:

Redis sentinel 是一個分布式系統(tǒng)中監(jiān)控 redis 主從服務(wù)器，并在主服務(wù)器下線時自動進行故障轉(zhuǎn)移。其中三個特性
監(jiān)控（Monitoring）： Sentinel 會不斷地檢查你的主服務(wù)器和從服務(wù)器是否運作正常
提醒（Notification）： 當被監(jiān)控的某個 Redis 服務(wù)器出現(xiàn)問題時， Sentinel 可以通過 API 向管理員或者其他應(yīng)用程序發(fā)送通知
自動故障遷移（Automatic failover）： 當一個主服務(wù)器不能正常工作時， Sentinel 會開始一次自動故障遷移操作
特點：
1、保證高可用
2、監(jiān)控各個節(jié)點
3、自動故障遷移
缺點：主從模式，切換需要時間丟數(shù)據(jù)
沒有解決 master 寫的壓力

集群(proxy)

Twemproxy 是一個 Twitter 開源的一個 redis 和 memcache 快速/輕量級代理服務(wù)器； Twemproxy 是一個快速的單線程代理程序，支持 Memcached ASCII 協(xié)議和 redis 協(xié)議。
特點：1、多種 hash 算法：MD5、CRC16、CRC32、CRC32a、hsieh、murmur、Jenkins
2、支持失敗節(jié)點自動刪除
3、后端 Sharding 分片邏輯對業(yè)務(wù)透明，業(yè)務(wù)方的讀寫方式和操作單個 Redis 一致
缺點：增加了新的 proxy，需要維護其高可用。
failover 邏輯需要自己實現(xiàn)，其本身不能支持故障的自動轉(zhuǎn)移可擴展性差，進行擴縮容都需要手動干預(yù)