Redis 概念Redis 是一個開源（BSD許可）的，內存中的數據結構存儲系統，它可以用作數據庫、緩存和消息中間件。 它支持多種類型的數據結構，如 字符串（strings）， 散列（hashes）， 列表（lists）， 集合（sets）， 有序集合（sorted sets） 與範圍查詢， bitmaps， hyperloglogs 和 地理空間（geospatial） 索引半徑查詢。 Redis 內置了 複製（replication），LUA腳本（Lua scripting）， LRU驅動事件（LRU eviction），事務（transactions） 和不同級別的 磁盤持久化（persistence）， 並通過 Redis哨兵（Sentinel）和自動 分區（Cluster）提供高可用性（high availability）。
Redis 優勢1.速度快
官方數據讀寫性能10萬/s，原因：數據庫存放在memory中，redis利用c語言編寫，單線程架構預防了多線程競爭問題，
2.基於鍵值對的數據結構服務器
幾乎所有的編程語言都提供了類似字典的功能，類似於這種組織數據的方式叫作基於鍵值的方式，與很多鍵值對數據庫不同的是，Redis中的值不僅可以是字符串，而且還可以是具體的數據結構，這樣不僅能便於在許多應用場景的開發，同時也能夠提高開發效率。Redis的全稱是REmote Dictionary Server，它主要提供了5種數據結構：字符串、哈希、列表、集合、有序集合，同時在字符串的基礎之上演變出了位圖（Bitmaps）和HyperLogLog兩種神奇的“數據結構”，並且隨着LBS（Location Based Service，基於位置服務）的不斷髮展。
3.豐富的功能
除了5種數據結構，Redis還提供了許多額外的功能：
·提供了鍵過期功能，可以用來實現緩存。
·提供了發佈訂閱功能，可以用來實現消息系統。
·支持Lua腳本功能，可以利用Lua創造出新的Redis命令。
·提供了簡單的事務功能，能在一定程度上保證事務特性。
·提供了流水線（Pipeline）功能，這樣客戶端能將一批命令一次性傳到
Redis，減少了網絡的開銷。
4.簡單穩定
Redis的簡單主要表現在三個方面。首先，Redis的源碼很少，其次，Redis使用單線程模型，最後，Redis不需要依賴於操作系統中的類庫（例如Memcache需要依賴libevent這樣的系統類庫），Redis自己實現了事件處理的相關功能。
5.客戶端語言多
Redis提供了簡單的TCP通信協議，很多編程語言可以很方便地接入到Redis
6.持久化
通常看，將數據放在內存中是不安全的，一旦發生斷電或者機器故障，重要的數據可能就會丟失，因此Redis提供了兩種持久化方式：RDB和AOF，即可以用兩種策略將內存的數據保存到硬盤中（如圖1-1所示），這樣就保證了數據的可持久性。
7.主從複製
Redis提供了複製功能，實現了多個相同數據的Redis副本（如圖1-2所示），複製功能是分佈式Redis的基礎。
8.高可用和分佈式
Redis從2.8版本正式提供了高可用實現Redis Sentinel，它能夠保證Redis節點的故障發現和故障自動轉移。Redis從3.0版本正式提供了分佈式實現Redis Cluster，它是Redis真正的分佈式實現，提供了高可用、讀寫和容量的擴展性。
Redis集羣介紹Redis 集羣是一個提供在多個Redis間節點間共享數據的程序集。Redis集羣並不支持處理多個keys的命令,因爲這需要在不同的節點間移動數據,從而達不到像Redis那樣的性能,在高負載的情況下可能會導致不可預料的錯誤.
Redis 集羣通過分區來提供一定程度的可用性,在實際環境中當某個節點宕機或者不可達的情況下繼續處理命令. Redis 集羣的優勢:自動分割數據到不同的節點上。整個集羣的部分節點失敗或者不可達的情況下能夠繼續處理命令。
Redis 集羣的數據分片
Redis 集羣沒有使用一致性hash, 而是引入了 哈希槽的概念.Redis 集羣有16384個哈希槽,每個key通過CRC16校驗後對16384取模來決定放置哪個槽.集羣的每個節點負責一部分hash槽,舉個例子,比如當前集羣有3個節點,那麼:
節點 A 包含 0 到 5500號哈希槽.
節點 B 包含5501 到 11000 號哈希槽.
節點 C 包含11001 到 16384號哈希槽.
這種結構很容易添加或者刪除節點. 比如如果我想新添加個節點D, 我需要從節點 A, B, C中得部分槽到D上. 如果我想移除節點A,需要將A中的槽移到B和C節點上,然後將沒有任何槽的A節點從集羣中移除即可. 由於從一個節點將哈希槽移動到另一個節點並不會停止服務,所以無論添加刪除或者改變某個節點的哈希槽的數量都不會造成集羣不可用的狀態.
Redis 集羣的主從複製模型爲了使在部分節點失敗或者大部分節點無法通信的情況下集羣仍然可用，所以集羣使用了主從複製模型,每個節點都會有N-1個複製品.
在我們例子中具有A，B，C三個節點的集羣,在沒有複製模型的情況下,如果節點B失敗了，那麼整個集羣就會以爲缺少5501-11000這個範圍的槽而不可用.
然而如果在集羣創建的時候（或者過一段時間）我們爲每個節點添加一個從節點A1，B1，C1,那麼整個集羣便有三個master節點和三個slave節點組成，這樣在節點B失敗後，集羣便會選舉B1爲新的主節點繼續服務，整個集羣便不會因爲槽找不到而不可用了
不過當B和B1 都失敗後，集羣是不可用的.
Redis 一致性保證Redis 並不能保證數據的強一致性. 這意味這在實際中集羣在特定的條件下可能會丟失寫操作.第一個原因是因爲集羣是用了異步複製. 寫操作過程:客戶端向主節點B寫入一條命令.主節點B向客戶端回覆命令狀態.主節點將寫操作複製給他得從節點 B1, B2 和 B3.主節點對命令的複製工作發生在返回命令回覆之後， 因爲如果每次處理命令請求都需要等待複製操作完成的話， 那麼主節點處理命令請求的速度將極大地降低 —— 我們必須在性能和一致性之間做出權衡。 注意：Redis 集羣可能會在將來提供同步寫的方法。 Redis 集羣另外一種可能會丟失命令的情況是集羣出現了網絡分區， 並且一個客戶端與至少包括一個主節點在內的少數實例被孤立。
舉個例子 假設集羣包含 A 、 B 、 C 、 A1 、 B1 、 C1 六個節點， 其中 A 、B 、C 爲主節點， A1 、B1 、C1 爲A，B，C的從節點， 還有一個客戶端 Z1 假設集羣中發生網絡分區，那麼集羣可能會分爲兩方，大部分的一方包含節點 A 、C 、A1 、B1 和 C1 ，小部分的一方則包含節點 B 和客戶端 Z1 .Z1仍然能夠向主節點B中寫入, 如果網絡分區發生時間較短,那麼集羣將會繼續正常運作,如果分區的時間足夠讓大部分的一方將B1選舉爲新的master，那麼Z1寫入B中得數據便丟失了.
注意， 在網絡分裂出現期間， 客戶端 Z1 可以向主節點 B 發送寫命令的最大時間是有限制的， 這一時間限制稱爲節點超時時間（node timeout）， 是 Redis 集羣的一個重要的配置選項。
Redis 高併發1.redis是基於內存的，內存的讀寫速度非常快；
2.redis是單線程的，省去了很多上下文切換線程的時間；
3.redis使用多路複用技術，可以處理併發的連接。非阻塞IO 內部實現採用epoll，採用了epoll+自己實現的簡單的事件框架。epoll中的讀、寫、關閉、連接都轉化成了事件，然後利用epoll的多路複用特性，絕不在io上浪費一點時間。
下面重點介紹單線程設計和IO多路複用核心設計快的原因
爲什麼Redis是單線程的1.官方答案
因爲Redis是基於內存的操作，CPU不是Redis的瓶頸，Redis的瓶頸最有可能是機器內存的大小或者網絡帶寬。既然單線程容易實現，而且CPU不會成爲瓶頸，那就順理成章地採用單線程的方案了。
2.性能指標
關於redis的性能，官方數據處理每秒幾十萬的請求。
3.詳細原因
1）不需要各種鎖的性能消耗
Redis的數據結構並不全是簡單的Key-Value，還有list，hash等複雜的結構，這些結構有可能會進行很細粒度的操作，比如在很長的列表後面添加一個元素，在hash當中添加或者刪除一個對象。這些操作可能就需要加非常多的鎖，導致的結果是同步開銷大大增加。
總之，在單線程的情況下，就不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因爲可能出現死鎖而導致的性能消耗。
2）單線程多進程集羣方案
單線程的威力實際上非常強大，每核心效率也非常高，多線程自然是可以比單線程有更高的性能上限，但是在今天的計算環境中，即使是單機多線程的上限也往往不能滿足需要了，需要進一步摸索的是多服務器集羣化的方案，這些方案中多線程的技術照樣是用不上的。所以單線程、多進程的集羣不失爲一個時髦的解決方案。
3）CPU消耗
採用單線程，避免了不必要的上下文切換和競爭條件，也不存在多進程或者多線程導致的切換而消耗 CPU。
但是如果CPU成爲Redis瓶頸，或者不想讓服務器其他CUP核閒置，那怎麼辦？
可以考慮多起幾個Redis進程，Redis是key-value數據庫，不是關係數據庫，數據之間沒有約束。只要客戶端分清哪些key放在哪個Redis進程上就可以了。
Redis單線程的優劣勢1、代碼更清晰，處理邏輯更簡單不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因爲可能出現死鎖而導致的性能消耗不存在多進程或者多線程導致的切換而消耗CPU
單進程單線程弊端無法發揮多核CPU性能，不過可以通過在單機開多個Redis實例來完善；
2、IO多路複用技術 redis 採用網絡IO多路複用技術來保證在多連接的時候， 系統的高吞吐量。
多路-指的是多個socket連接，複用-指的是複用一個線程。多路複用主要有三種技術：select，poll，epoll。epoll是最新的也是目前最好的多路複用技術。
這裏“多路”指的是多個網絡連接，“複用”指的是複用同一個線程。採用多路 I/O 複用技術可以讓單個線程高效的處理多個連接請求（儘量減少網絡IO的時間消耗），且Redis在內存中操作數據的速度非常快（內存內的操作不會成爲這裏的性能瓶頸），主要以上兩點造就了Redis具有很高的吞吐量。
Redis cluster遷移redis集羣遷移分爲兩種方法：
1、遷移方案利用cluster 自身集羣管理工具 redis-trib.rb 進行無損遷移方案。
2、遷移方案利用Redis cluster 自身管理工具，停機老集羣節點，通過rdb 文件進行歸檔
第一種方式介紹：
部署新節點redis 實例。（注意部署以後是單實例，不用創建成集羣）
將新節點redis 添加到老集羣中。(添加master 節點)
將新節點redis 添加到老集羣中。(添加slave 節點)
集羣進行遷移
將槽位均勻分片給新的剩餘master 節點
優勢：保證數據完整性
缺陷：遷移後源redis集羣不可用。
第二種方式介紹：
老集羣節點生成RDB 文件（操作前提: 應用斷開Redis 連接）
獲取老集羣節點槽位信息，並記錄
部署新Redis cluster 遷移環境
爲新Redis 集羣分配槽位(對應老集羣節點的槽位)
將老集羣的rdb 文件分別拷貝相同的槽位節點下。
優勢：保證源redis的可用性，應用可隨時切換。
缺陷：在遷移過程中槽位必須一直對應。
keepalived什麼是Keepalived呢，keepalived觀其名可知，保持存活，在網絡裏面就是保持在線了，也就是所謂的高可用或熱備，用來防止單點故障(單點故障是指一旦某一點出現故障就會導致整個系統架構的不可用)的發生。
Redis Master-Slave + Keepalive + VIP。
這是很經典的db架構，也可以用與mysql的主從切換。基本原理是：Keepalive通過腳本檢測master的存活，然後通過漂移VIP（Virtual IP）完成主從切換。
基礎架構圖
基本構建與原理1）Keepalive + VIP : 在redis master-slave上部署keepalived、redis instance存活檢測腳本、以及告警通知腳本。
2）當redis master失效的時候，VIP從master上漂移到slave上，完成m-s角色和配置更改。
3）客戶端連接redis的參數中host設置的是VIP，整個切換過程對客戶端透明。
優缺點與適用場景優點：實現簡單，成本低。
缺點：整個集羣的最大吞吐量受限於redis單實例的處理能力，除非一個應用使用多套這種Keepalive+VIP方案。
因而擴展能力較差，而且不適合目前單機部署多個redis實例的部署場景，而我們的一個物理機上至少部署8個redis實例。
適合場景：併發請求不是很高的應用。