redis 概念

Redis 是一個開源（BSD許可）的，內(nèi)存中的數(shù)據(jù)結構存儲系統(tǒng)，它可以用作數(shù)據(jù)庫、緩存和消息中間件。 它支持多種類型的數(shù)據(jù)結構，如 字符串（strings）， 散列（hashes）， 列表（lists）， 集合（sets）， 有序集合（sorted sets） 與范圍查詢， bitmaps， hyperloglogs 和 地理空間（geospatial） 索引半徑查詢。 Redis 內(nèi)置了 復制（replication），LUA腳本（Lua scripting）， LRU驅動事件（LRU eviction），事務（transactions） 和不同級別的 磁盤持久化（persistence）， 并通過 Redis哨兵（Sentinel）和自動 分區(qū)（Cluster）提供高可用性（high availability）。

網(wǎng)站建設哪家好，找成都創(chuàng)新互聯(lián)公司！專注于網(wǎng)頁設計、網(wǎng)站建設、微信開發(fā)、成都微信小程序、集團企業(yè)網(wǎng)站建設等服務項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了噶爾免費建站歡迎大家使用！

Redis 優(yōu)勢

1.速度快
官方數(shù)據(jù)讀寫性能10萬/s，原因：數(shù)據(jù)庫存放在memory中，redis利用c語言編寫，單線程架構預防了多線程競爭問題，
2.基于鍵值對的數(shù)據(jù)結構服務器
幾乎所有的編程語言都提供了類似字典的功能，類似于這種組織數(shù)據(jù)的方式叫作基于鍵值的方式，與很多鍵值對數(shù)據(jù)庫不同的是，Redis中的值不僅可以是字符串，而且還可以是具體的數(shù)據(jù)結構，這樣不僅能便于在許多應用場景的開發(fā)，同時也能夠提高開發(fā)效率。Redis的全稱是REmote Dictionary Server，它主要提供了5種數(shù)據(jù)結構：字符串、哈希、列表、集合、有序集合，同時在字符串的基礎之上演變出了位圖（Bitmaps）和HyperLogLog兩種神奇的“數(shù)據(jù)結構”，并且隨著LBS（Location Based Service，基于位置服務）的不斷發(fā)展。
3.豐富的功能
除了5種數(shù)據(jù)結構，Redis還提供了許多額外的功能：
·提供了鍵過期功能，可以用來實現(xiàn)緩存。
·提供了發(fā)布訂閱功能，可以用來實現(xiàn)消息系統(tǒng)。
·支持Lua腳本功能，可以利用Lua創(chuàng)造出新的Redis命令。
·提供了簡單的事務功能，能在一定程度上保證事務特性。
·提供了流水線（Pipeline）功能，這樣客戶端能將一批命令一次性傳到
Redis，減少了網(wǎng)絡的開銷。
4.簡單穩(wěn)定
Redis的簡單主要表現(xiàn)在三個方面。首先，Redis的源碼很少，其次，Redis使用單線程模型，最后，Redis不需要依賴于操作系統(tǒng)中的類庫（例如Memcache需要依賴libevent這樣的系統(tǒng)類庫），Redis自己實現(xiàn)了事件處理的相關功能。
5.客戶端語言多
Redis提供了簡單的TCP通信協(xié)議，很多編程語言可以很方便地接入到Redis
6.持久化
通常看，將數(shù)據(jù)放在內(nèi)存中是不安全的，一旦發(fā)生斷電或者機器故障，重要的數(shù)據(jù)可能就會丟失，因此Redis提供了兩種持久化方式：RDB和AOF，即可以用兩種策略將內(nèi)存的數(shù)據(jù)保存到硬盤中（如圖1-1所示），這樣就保證了數(shù)據(jù)的可持久性。

7.主從復制
Redis提供了復制功能，實現(xiàn)了多個相同數(shù)據(jù)的Redis副本（如圖1-2所示），復制功能是分布式Redis的基礎。

8.高可用和分布式
Redis從2.8版本正式提供了高可用實現(xiàn)Redis Sentinel，它能夠保證Redis節(jié)點的故障發(fā)現(xiàn)和故障自動轉移。Redis從3.0版本正式提供了分布式實現(xiàn)Redis Cluster，它是Redis真正的分布式實現(xiàn)，提供了高可用、讀寫和容量的擴展性。

Redis集群介紹

Redis 集群是一個提供在多個Redis間節(jié)點間共享數(shù)據(jù)的程序集。Redis集群并不支持處理多個keys的命令,因為這需要在不同的節(jié)點間移動數(shù)據(jù),從而達不到像Redis那樣的性能,在高負載的情況下可能會導致不可預料的錯誤.
Redis 集群通過分區(qū)來提供一定程度的可用性,在實際環(huán)境中當某個節(jié)點宕機或者不可達的情況下繼續(xù)處理命令. Redis 集群的優(yōu)勢:自動分割數(shù)據(jù)到不同的節(jié)點上。整個集群的部分節(jié)點失敗或者不可達的情況下能夠繼續(xù)處理命令。
Redis 集群的數(shù)據(jù)分片
Redis 集群沒有使用一致性hash, 而是引入了 哈希槽的概念.Redis 集群有16384個哈希槽,每個key通過CRC16校驗后對16384取模來決定放置哪個槽.集群的每個節(jié)點負責一部分hash槽,舉個例子,比如當前集群有3個節(jié)點,那么:
節(jié)點 A 包含 0 到 5500號哈希槽.
節(jié)點 B 包含5501 到 11000 號哈希槽.
節(jié)點 C 包含11001 到 16384號哈希槽.
這種結構很容易添加或者刪除節(jié)點. 比如如果我想新添加個節(jié)點D, 我需要從節(jié)點 A, B, C中得部分槽到D上. 如果我想移除節(jié)點A,需要將A中的槽移到B和C節(jié)點上,然后將沒有任何槽的A節(jié)點從集群中移除即可. 由于從一個節(jié)點將哈希槽移動到另一個節(jié)點并不會停止服務,所以無論添加刪除或者改變某個節(jié)點的哈希槽的數(shù)量都不會造成集群不可用的狀態(tài).

Redis 集群的主從復制模型

為了使在部分節(jié)點失敗或者大部分節(jié)點無法通信的情況下集群仍然可用，所以集群使用了主從復制模型,每個節(jié)點都會有N-1個復制品.
在我們例子中具有A，B，C三個節(jié)點的集群,在沒有復制模型的情況下,如果節(jié)點B失敗了，那么整個集群就會以為缺少5501-11000這個范圍的槽而不可用.
然而如果在集群創(chuàng)建的時候（或者過一段時間）我們?yōu)槊總€節(jié)點添加一個從節(jié)點A1，B1，C1,那么整個集群便有三個master節(jié)點和三個slave節(jié)點組成，這樣在節(jié)點B失敗后，集群便會選舉B1為新的主節(jié)點繼續(xù)服務，整個集群便不會因為槽找不到而不可用了
不過當B和B1 都失敗后，集群是不可用的.

Redis 一致性保證

Redis 并不能保證數(shù)據(jù)的強一致性. 這意味這在實際中集群在特定的條件下可能會丟失寫操作.第一個原因是因為集群是用了異步復制. 寫操作過程:客戶端向主節(jié)點B寫入一條命令.主節(jié)點B向客戶端回復命令狀態(tài).主節(jié)點將寫操作復制給他得從節(jié)點 B1, B2 和 B3.主節(jié)點對命令的復制工作發(fā)生在返回命令回復之后， 因為如果每次處理命令請求都需要等待復制操作完成的話， 那么主節(jié)點處理命令請求的速度將極大地降低 —— 我們必須在性能和一致性之間做出權衡。 注意：Redis 集群可能會在將來提供同步寫的方法。 Redis 集群另外一種可能會丟失命令的情況是集群出現(xiàn)了網(wǎng)絡分區(qū)， 并且一個客戶端與至少包括一個主節(jié)點在內(nèi)的少數(shù)實例被孤立。
舉個例子 假設集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六個節(jié)點， 其中 A 、B 、C 為主節(jié)點， A1 、B1 、C1 為A，B，C的從節(jié)點， 還有一個客戶端 Z1 假設集群中發(fā)生網(wǎng)絡分區(qū)，那么集群可能會分為兩方，大部分的一方包含節(jié)點 A 、C 、A1 、B1 和 C1 ，小部分的一方則包含節(jié)點 B 和客戶端 Z1 .Z1仍然能夠向主節(jié)點B中寫入, 如果網(wǎng)絡分區(qū)發(fā)生時間較短,那么集群將會繼續(xù)正常運作,如果分區(qū)的時間足夠讓大部分的一方將B1選舉為新的master，那么Z1寫入B中得數(shù)據(jù)便丟失了.
注意， 在網(wǎng)絡分裂出現(xiàn)期間， 客戶端 Z1 可以向主節(jié)點 B 發(fā)送寫命令的最大時間是有限制的， 這一時間限制稱為節(jié)點超時時間（node timeout）， 是 Redis 集群的一個重要的配置選項。

Redis 高并發(fā)

1.redis是基于內(nèi)存的，內(nèi)存的讀寫速度非?？欤?br/>2.redis是單線程的，省去了很多上下文切換線程的時間；
3.redis使用多路復用技術，可以處理并發(fā)的連接。非阻塞IO 內(nèi)部實現(xiàn)采用epoll，采用了epoll+自己實現(xiàn)的簡單的事件框架。epoll中的讀、寫、關閉、連接都轉化成了事件，然后利用epoll的多路復用特性，絕不在io上浪費一點時間。
下面重點介紹單線程設計和IO多路復用核心設計快的原因

為什么Redis是單線程的

1.官方答案
因為Redis是基于內(nèi)存的操作，CPU不是Redis的瓶頸，Redis的瓶頸最有可能是機器內(nèi)存的大小或者網(wǎng)絡帶寬。既然單線程容易實現(xiàn)，而且CPU不會成為瓶頸，那就順理成章地采用單線程的方案了。
2.性能指標
關于redis的性能，官方數(shù)據(jù)處理每秒幾十萬的請求。
3.詳細原因
1）不需要各種鎖的性能消耗
Redis的數(shù)據(jù)結構并不全是簡單的Key-Value，還有l(wèi)ist，hash等復雜的結構，這些結構有可能會進行很細粒度的操作，比如在很長的列表后面添加一個元素，在hash當中添加或者刪除一個對象。這些操作可能就需要加非常多的鎖，導致的結果是同步開銷大大增加。
總之，在單線程的情況下，就不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因為可能出現(xiàn)死鎖而導致的性能消耗。
2）單線程多進程集群方案
單線程的威力實際上非常強大，每核心效率也非常高，多線程自然是可以比單線程有更高的性能上限，但是在今天的計算環(huán)境中，即使是單機多線程的上限也往往不能滿足需要了，需要進一步摸索的是多服務器集群化的方案，這些方案中多線程的技術照樣是用不上的。所以單線程、多進程的集群不失為一個時髦的解決方案。
3）CPU消耗
采用單線程，避免了不必要的上下文切換和競爭條件，也不存在多進程或者多線程導致的切換而消耗 CPU。
但是如果CPU成為Redis瓶頸，或者不想讓服務器其他CUP核閑置，那怎么辦？
可以考慮多起幾個Redis進程，Redis是key-value數(shù)據(jù)庫，不是關系數(shù)據(jù)庫，數(shù)據(jù)之間沒有約束。只要客戶端分清哪些key放在哪個Redis進程上就可以了。

Redis單線程的優(yōu)劣勢

1、代碼更清晰，處理邏輯更簡單不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因為可能出現(xiàn)死鎖而導致的性能消耗不存在多進程或者多線程導致的切換而消耗CPU
單進程單線程弊端無法發(fā)揮多核CPU性能，不過可以通過在單機開多個Redis實例來完善；
2、IO多路復用技術 redis 采用網(wǎng)絡IO多路復用技術來保證在多連接的時候， 系統(tǒng)的高吞吐量。
多路-指的是多個socket連接，復用-指的是復用一個線程。多路復用主要有三種技術：select，poll，epoll。epoll是最新的也是目前最好的多路復用技術。
這里“多路”指的是多個網(wǎng)絡連接，“復用”指的是復用同一個線程。采用多路 I/O 復用技術可以讓單個線程高效的處理多個連接請求（盡量減少網(wǎng)絡IO的時間消耗），且Redis在內(nèi)存中操作數(shù)據(jù)的速度非?？欤▋?nèi)存內(nèi)的操作不會成為這里的性能瓶頸），主要以上兩點造就了Redis具有很高的吞吐量。

Redis cluster遷移

redis集群遷移分為兩種方法：
1、遷移方案利用cluster 自身集群管理工具 redis-trib.rb 進行無損遷移方案。
2、遷移方案利用Redis cluster 自身管理工具，停機老集群節(jié)點，通過rdb 文件進行歸檔
第一種方式介紹：
部署新節(jié)點redis 實例。（注意部署以后是單實例，不用創(chuàng)建成集群）
將新節(jié)點redis 添加到老集群中。(添加master 節(jié)點)
將新節(jié)點redis 添加到老集群中。(添加slave 節(jié)點)
集群進行遷移
將槽位均勻分片給新的剩余master 節(jié)點
優(yōu)勢：保證數(shù)據(jù)完整性
缺陷：遷移后源redis集群不可用。
第二種方式介紹：
老集群節(jié)點生成RDB 文件（操作前提: 應用斷開Redis 連接）
獲取老集群節(jié)點槽位信息，并記錄
部署新Redis cluster 遷移環(huán)境
為新Redis 集群分配槽位(對應老集群節(jié)點的槽位)
將老集群的rdb 文件分別拷貝相同的槽位節(jié)點下。
優(yōu)勢：保證源redis的可用性，應用可隨時切換。
缺陷：在遷移過程中槽位必須一直對應。

keepalived

什么是Keepalived呢，keepalived觀其名可知，保持存活，在網(wǎng)絡里面就是保持在線了，也就是所謂的高可用或熱備，用來防止單點故障(單點故障是指一旦某一點出現(xiàn)故障就會導致整個系統(tǒng)架構的不可用)的發(fā)生。
Redis Master-Slave + Keepalive + VIP。
這是很經(jīng)典的db架構，也可以用與MySQL的主從切換?；驹硎牵篕eepalive通過腳本檢測master的存活，然后通過漂移VIP（Virtual IP）完成主從切換。
基礎架構圖

基本構建與原理

1）Keepalive + VIP : 在redis master-slave上部署keepalived、redis instance存活檢測腳本、以及告警通知腳本。
2）當redis master失效的時候，VIP從master上漂移到slave上，完成m-s角色和配置更改。
3）客戶端連接redis的參數(shù)中host設置的是VIP，整個切換過程對客戶端透明。

優(yōu)缺點與適用場景

優(yōu)點：實現(xiàn)簡單，成本低。
缺點：整個集群的最大吞吐量受限于redis單實例的處理能力，除非一個應用使用多套這種Keepalive+VIP方案。
因而擴展能力較差，而且不適合目前單機部署多個redis實例的部署場景，而我們的一個物理機上至少部署8個redis實例。
適合場景：并發(fā)請求不是很高的應用。