Nosql概述

在介紹Redis之前，首先先要介紹Nosql的概念。

互聯網架構發展

在90年代的時候，計算機訪問量一般不大，單個數據庫足以應付，網頁更多的是靜態網頁，動態交互性。于是出現了下面的架構

上述架構在數據存儲的瓶頸有以下幾點：

1.數據量的總大小 一個機器放不下2.數據的索引（B+ Tree）一個機器的內存放不下3.訪問量(讀寫混合)一個實例不能承受

后來，隨著訪問量的上升，幾乎大部分使用MySQL架構的網站在數據庫上都開始出現了性能問題，web程序不再僅僅專注在功能上，同時也在追求性能。程序員們開始大量的使用緩存技術來緩解數據庫的壓力，優化數據庫的結構和索引。開始比較流行的是通過文件緩存來緩解數據庫壓力，但是當訪問量繼續增大的時候，多臺web機器通過文件緩存不能共享，大量的小文件緩存也帶了了比較高的IO壓力。在這個時候，Memcached就自然的成為一個非常時尚的技術產品。

Memcached作為一個獨立的分布式的緩存服務器，為多個web服務器提供了一個共享的高性能緩存服務，在Memcached服務器上，又發展了根據hash算法來進行多臺Memcached緩存服務的擴展，然后又出現了一致性hash來解決增加或減少緩存服務器導致重新hash帶來的大量緩存失效的弊端

由于數據庫的寫入壓力增加，Memcached只能緩解數據庫的讀取壓力。讀寫集中在一個數據庫上讓數據庫不堪重負，大部分網站開始使用主從復制技術來達到讀寫分離，以提高讀寫性能和讀庫的可擴展性。Mysql的master-slave模式成為這個時候的網站標配了。

在Memcached的高速緩存，MySQL的主從復制，讀寫分離的基礎之上，這時MySQL主庫的寫壓力開始出現瓶頸，而數據量的持續猛增，由于MyISAM使用表鎖，在高并發下會出現嚴重的鎖問題，大量的高并發MySQL應用開始使用InnoDB引擎代替MyISAM。

同時，開始流行使用分表分庫來緩解寫壓力和數據增長的擴展問題。這個時候，分表分庫成了一個熱門技術，是面試的熱門問題也是業界討論的熱門技術問題。也就在這個時候，MySQL推出了還不太穩定的表分區，這也給技術實力一般的公司帶來了希望。雖然MySQL推出了MySQL Cluster集群，但性能也不能很好滿足互聯網的要求，只是在高可靠性上提供了非常大的保證。

MySQL數據庫也經常存儲一些大文本字段，導致數據庫表非常的大，在做數據庫恢復的時候就導致非常的慢，不容易快速恢復數據庫。比如1000萬4KB大小的文本就接近40GB的大小，如果能把這些數據從MySQL省去，MySQL將變得非常的小。關系數據庫很強大，但是它并不能很好的應付所有的應用場景。MySQL的擴展性差（需要復雜的技術來實現），大數據下IO壓力大，表結構更改困難，正是當前使用MySQL的開發人員面臨的問題。

今天架構是下面這個樣子：

為什么使用NoSQL ?

今天我們可以通過第三方平臺（如：Google,Facebook等）可以很容易的訪問和抓取數據。用戶的個人信息，社交網絡，地理位置，用戶生成的數據和用戶操作日志已經成倍的增加。我們如果要對這些用戶數據進行挖掘，那SQL數據庫已經不適合這些應用了, NoSQL數據庫的發展也卻能很好的處理這些大的數據。

Nosql是什么

NoSQL(NoSQL = Not Only SQL )，意即“不僅僅是SQL”，泛指非關系型的數據庫。隨著互聯網web2.0網站的興起，傳統的關系數據庫在應付web2.0網站，特別是超大規模和高并發的SNS類型的web2.0純動態網站已經顯得力不從心，暴露了很多難以克服的問題，而非關系型的數據庫則由于其本身的特點得到了非常迅速的發展。NoSQL數據庫的產生就是為了解決大規模數據集合多重數據種類帶來的挑戰，尤其是大數據應用難題，包括超大規模數據的存儲。

（例如谷歌或Facebook每天為他們的用戶收集萬億比特的數據）。這些類型的數據存儲不需要固定的模式，無需多余操作就可以橫向擴展。

Nosql能做什么

1.易擴展：NoSQL數據庫種類繁多，但是一個共同的特點都是去掉關系數據庫的關系型特性。數據之間無關系，這樣就非常容易擴展。也無形之間，在架構的層面上帶來了可擴展的能力。

2.大數據量高性能：NoSQL數據庫都具有非常高的讀寫性能，尤其在大數據量下，同樣表現優秀。這得益于它的無關系性，數據庫的結構簡單。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對web2.0的交互頻繁的應用，Cache性能不高。而NoSQL的Cache是記錄級的，是一種細粒度的Cache，所以NoSQL在這個層面上來說就要性能高很多了

3.多樣靈活的數據模型：NoSQL無需事先為要存儲的數據建立字段，隨時可以存儲自定義的數據格式。而在關系數據庫里，增刪字段是一件非常麻煩的事情。如果是非常大數據量的表，增加字段簡直就是一個噩夢

4.傳統RDBMS VS NOSQL：

RDBMS

• 高度組織化結構化數據

• 結構化查詢語言（SQL）

• 數據和關系都存儲在單獨的表中。

• 數據操縱語言，數據定義語言

• 嚴格的一致性

• 基礎事務

NoSQL

• 代表著不僅僅是SQL

• 沒有聲明性查詢語言

• 沒有預定義的模式-鍵 - 值對存儲，列存儲，文檔存儲，圖形數據庫

• 最終一致性，而非ACID屬性

• 非結構化和不可預知的數據

• CAP定理

• 高性能，高可用性和可伸縮性

Nosql數據模型簡介

KV鍵值

Bson（類似Json）

列族：顧名思義，是按列存儲數據的。最大的特點是方便存儲結構化和半結構化數據，方便做數據壓縮，對針對某一列或者某幾列的查詢有非常大的IO優勢。

圖

NoSQL數據庫的四大分類

KV鍵值：新浪：BerkeleyDB+redis，美團：redis+tair，阿里、百度：memcache+redis

文檔型數據庫(bson格式比較多)：CouchDB，MongoDB。MongoDB 是一個基于分布式文件存儲的數據庫。由 C++ 語言編寫。旨在為 WEB 應用提供可擴展的高性能數據存儲解決方案。MongoDB 是一個介于關系數據庫和非關系數據庫之間的產品，是非關系數據庫當中功能最豐富，最像關系數據庫的。

列存儲數據庫：Cassandra, HBase，分布式文件系統

圖關系數據庫：社交網絡，推薦系統等。專注于構建關系圖譜，Neo4J, InfoGrid。

CAP+Base

關系型數據庫遵循ACID規則

事務在英文中是transaction，和現實世界中的交易很類似，它有如下四個特性：

1、A (Atomicity) 原子性原子性很容易理解，也就是說事務里的所有操作要么全部做完，要么都不做，事務成功的條件是事務里的所有操作都成功，只要有一個操作失敗，整個事務就失敗，需要回滾。比如銀行轉賬，從A賬戶轉100元至B賬戶，分為兩個步驟：1）從A賬戶取100元；2）存入100元至B賬戶。這兩步要么一起完成，要么一起不完成，如果只完成第一步，第二步失敗，錢會莫名其妙少了100元。

2、C (Consistency) 一致性一致性也比較容易理解，也就是說數據庫要一直處于一致的狀態，事務的運行不會改變數據庫原本的一致性約束。

3、I (Isolation) 獨立性所謂的獨立性是指并發的事務之間不會互相影響，如果一個事務要訪問的數據正在被另外一個事務修改，只要另外一個事務未提交，它所訪問的數據就不受未提交事務的影響。比如現有有個交易是從A賬戶轉100元至B賬戶，在這個交易還未完成的情況下，如果此時B查詢自己的賬戶，是看不到新增加的100元的

4、D (Durability) 持久性持久性是指一旦事務提交后，它所做的修改將會永久的保存在數據庫上，即使出現宕機也不會丟失。

CAP的含義

C:Consistency（強一致性）

A:Availability（可用性）

P:Partition tolerance（分區容錯性）

CAP的的3進2

CAP理論就是說在分布式存儲系統中，最多只能實現上面的兩點。因此，根據 CAP 原理將 NoSQL 數據庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類。而由于當前的網絡硬件肯定會出現延遲丟包等問題，所以分區容忍性是我們必須需要實現的。所以我們只能在一致性和可用性之間進行權衡，沒有NoSQL系統能同時保證這三點。

• CA - 單點集群，滿足一致性，可用性的系統，通常在可擴展性上不太強大。傳統Oracle數據庫

• CP - 滿足一致性，分區容忍必的系統，通常性能不是特別高。 Redis、Mongodb

• AP - 滿足可用性，分區容忍性的系統，通?？赡軐σ恢滦砸蟮鸵恍４蠖鄶稻W站架構的選擇

注意：分布式架構的時候必須做出取舍。一致性和可用性之間取一個平衡。多余大多數web應用，其實并不需要強一致性。因此犧牲C換取P，這是目前分布式數據庫產品的方向

一致性與可用性的決擇

對于web2.0網站來說，關系數據庫的很多主要特性卻往往無用武之地

• 數據庫事務一致性需求

很多web實時系統并不要求嚴格的數據庫事務，對讀一致性的要求很低， 有些場合對寫一致性要求并不高。允許實現最終一致性。

• 數據庫的寫實時性和讀實時性需求

對關系數據庫來說，插入一條數據之后立刻查詢，是肯定可以讀出來這條數據的，但是對于很多web應用來說，并不要求這么高的實時性，比方說發一條消息之 后，過幾秒乃至十幾秒之后，我的訂閱者才看到這條動態是完全可以接受的。

• 對復雜的SQL查詢，特別是多表關聯查詢的需求

任何大數據量的web系統，都非常忌諱多個大表的關聯查詢，以及復雜的數據分析類型的報表查詢，特別是SNS類型的網站，從需求以及產品設計角 度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。

BASE的含義

BASE就是為了解決關系數據庫強一致性引起的問題而引起的可用性降低而提出的解決方案。

BASE其實是下面三個術語的縮寫： 基本可用（Basically Available） 軟狀態（Soft state） 最終一致（Eventually consistent）

它的思想是通過讓系統放松對某一時刻數據一致性的要求來換取系統整體伸縮性和性能上改觀。為什么這么說呢，緣由就在于大型系統往往由于地域分布和極高性能的要求，不可能采用分布式事務來完成這些指標，要想獲得這些指標，我們必須采用另外一種方式來完成，這里BASE就是解決這個問題的辦法

分布式系統

分布式系統（distributed system）由多臺計算機和通信的軟件組件通過計算機網絡連接（本地網絡或廣域網）組成。分布式系統是建立在網絡之上的軟件系統。正是因為軟件的特性，所以分布式系統具有高度的內聚性和透明性。因此，網絡和分布式系統之間的區別更多的在于高層軟件（特別是操作系統），而不是硬件。分布式系統可以應用在在不同的平臺上如：Pc、工作站、局域網和廣域網上等。

簡單來講：1分布式：不同的多臺服務器上面部署不同的服務模塊（工程），他們之間通過Rpc/Rmi之間通信和調用，對外提供服務和組內協作。

2集群：不同的多臺服務器上面部署相同的服務模塊，通過分布式調度軟件進行統一的調度，對外提供服務和訪問。

Redis

是什么——概念

Redis:REmote DIctionary Server(遠程字典服務器)是完全開源免費的，用C語言編寫的，遵守BSD協議，是一個高性能的(key/value)分布式內存數據庫，基于內存運行并支持持久化的NoSQL數據庫，是當前最熱門的NoSql數據庫之一,也被人們稱為數據結構服務器

Redis 與其他 key - value 緩存產品有以下三個特點：

• Redis支持數據的持久化，可以將內存中的數據保持在磁盤中，重啟的時候可以再次加載進行使用

• Redis不僅僅支持簡單的key-value類型的數據，同時還提供list，set，zset，hash等數據結構的存儲

• Redis支持數據的備份，即master-slave模式的數據備份

能做啥

• 內存存儲和持久化：redis支持異步將內存中的數據寫到硬盤上，同時不影響繼續服務

• 取最新N個數據的操作，如：可以將最新的10條評論的ID放在Redis的List集合里面

• 模擬類似于HttpSession這種需要設定過期時間的功能

• 發布、訂閱消息系統

• 定時器、計數器

安裝——基于Linux

1. 下載獲得redis-XXX.tar.gz后將它放入我們的Linux目錄/opt

2. /opt目錄下，解壓命令:tar -zxvf redis-XXX.tar.gz

3. 進入目錄:cd redis-XXX

4. 在redis-XXX目錄下執行make命令

5. 如果make完成后繼續執行make install

6. 查看默認安裝目錄：usr/local/bin

7. 修改redis.conf文件將里面的daemonize no 改成 yes，讓服務在后臺啟動

8. 將默認的redis.conf拷貝到自己定義好的一個路徑下，比如/myconf

9. /usr/local/bin目錄下運行redis-server，運行拷貝出存放了自定義conf文件目錄下的redis.conf文件

10. 啟動redis客戶端：redis-cli -p 6379

11. 測試連通性：輸入ping 返回 PONG 測試成功

12. 單實例關閉：redis-cli shutdown；多實例關閉，指定端口關閉:redis-cli -p 6379 shutdown

雜項知識

• Redis 是單進程

• 默認16個數據庫，初始默認使用零號庫（Redis索引都是從零開始），統一密碼管理，16個庫都是同樣密碼，要么都OK要么一個也連接不上

• select命令切換數據庫 select 2切換到標號為2的庫

• dbsize查看當前數據庫的key的數量

• flushdb：清空當前庫

• Flushall：清空全部庫

Redis數據類型

Redis支持5大數據類型：

• string（字符串）

  string 是Redis的基本類型，一個key對應一個Value，String是二進制安全的，及時說Redis的String可以包含任何數據，比如jpg圖片或者序列化的對象，一個Redis中字符串value最多是512M

• hash（哈希，類似java里的Map）

  Redis hash是一個鍵值對集合，是一個string類型的field和value的映射表，特別適合用于存儲對象，類似于Java里面的Map<String,Object>

• list（列表）

  Redis List 是簡單的字符串列表，按照插入的順序排序，可以添加一個元素到列表的頭部或者尾部，底層其實是一個鏈表

• set（集合）

  是String類型的無序集合，通過HashTable實現

• zset(sorted set：有序集合)

  和set一樣也是String類型元素的集合，且不允許重復的成員。不同的是每個元素都會關聯一個double類型的分數。redis正是通過分數來為集合中的成員進行從小到大的排序。zset的成員是唯一的，但分數score卻可以重復。

每種數據類型相關命令請參考http://redisdoc.com/本文不再贅述

Redis配置文件

配置文件放在解壓目錄中redis.conf

• 開頭：配置文件開頭定義了一些基本度量單位，只支持bytes不支持bit，對大小寫不敏感

• INCLUDE：Redis可以作為總閘，包含一些其他的配置文件

• NETWORK：配置一些網絡參數，如設置有效監聽的客戶端連接地址，監聽端口等

  • tcp-backlog：backlog其實是一個鏈接隊列，backlog隊列總和=未完成三次握手隊列+已完成三次握手隊列

    在高并發的環境下你需要一個高backlog值來避免慢客戶端鏈接問題。Linux內核會將這個值減小到/proc/sys/net/core/somaxconn的值，所以需要確保提高somaxconn和tcp_max_syn_backlog兩個值來達到目標效果

  • tcp-keepalive：間隔多長時間進行keepalive檢測，從Redis3.2.1之后默認值為300此前為60

  (不同版本Redis配置文件結構不一樣，老版本沒有此分類，原來放在GENERAL里面)

• GENERAL：

  • daemonize 后臺啟動

  • loglevel 設置日志級別，級別越高日志越多越詳細

  • logfile 日志文件

  • databases 默認Redis數據庫數量——16個

• SNAPSHOTTING：RDB的持久化配置將Redis數據庫保存在磁盤上，詳見本文持久化部分

• REPLICATION：設置主從復制

• SECURITY：訪問密碼的查看、設置和取消。默認Redis是沒有密碼的，因為它相信安裝環境Linux是安全的

• LIMITS：對Redis進行一些限制，如最大連接客戶端數量，使用內存等

• APPEND ONLY MODE：Redis AOF持久化的一些配置，詳見本文持久化部分

Redis持久化

Redis 有兩種持久化技術RDB和AOF

http://redisdoc.com/topic/persistence.html 推薦參考官方文檔

RDB(Redis DataBase)

在指定的時間間隔內將內存中的數據集快照寫入磁盤，也就是Snapshot，它恢復時是將快照文件直接讀到內存里。

Redis會單獨創建（fork）一個子進程來進行持久化，會先將數據寫入到一個臨時文件中，待持久化過程都結束了，再用這個臨時文件替換上次持久化好的文件。整個過程中，主進程是不進行任何IO操作的，這就確保了極高的性能如果需要進行大規模數據的恢復，且對于數據恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺點是最后一次持久化后的數據可能丟失。

Fork：fork的作用是復制一個與當前進程一樣的進程。新進程的所有數據（變量、環境變量、程序計數器等）數值都和原進程一致，但是是一個全新的進程，并作為原進程的子進程。

RDB 保存的是dump.rdb文件

如何觸發RDB快照

• Save命令：save時只管保存，其它不管，全部阻塞

• bgsave命令：Redis會在后臺異步進行快照操作，快照同時還可以響應客戶端請求。可以通過lastsave命令獲取最后一次成功執行快照的時間

• flushall命令：也會產生dump.rdb文件，但里面是空的，無意義

RDB默認配置觸發是：

• 1分鐘改了1萬次

• 5分鐘改了10次

• 15分鐘改了1次

如何恢復

將備份文件 (dump.rdb) 移動到 redis 安裝目錄并啟動服務即可

如何停止

停止RDB保存規則的方法：redis-cli config set save ""

AOF(Append Only File)

以日志的形式來記錄每個寫操作，將Redis執行過的所有寫指令記錄下來(讀操作不記錄)，只許追加文件但不可以改寫文件，redis啟動之初會讀取該文件重新構建數據，換言之，redis重啟的話就根據日志文件的內容將寫指令從前到后執行一次以完成數據的恢復工作。

Aof保存的是appendonly.aof文件

如何啟動AOF

修改默認的appendonly no，改為yes

AOF損壞修復

redis-check-aof --fix進行修復

rewrite

AOF采用文件追加方式，文件會越來越大為避免出現此種情況，新增了重寫機制,當AOF文件的大小超過所設定的閾值時，Redis就會啟動AOF文件的內容壓縮，只保留可以恢復數據的最小指令集.可以使用命令bgrewriteaof

• 重寫原理

  AOF文件持續增長而過大時，會fork出一條新進程來將文件重寫(也是先寫臨時文件最后再rename)，遍歷新進程的內存中數據，每條記錄有一條的Set語句。重寫aof文件的操作，并沒有讀取舊的aof文件，而是將整個內存中的數據庫內容用命令的方式重寫了一個新的aof文件，這點和快照有點類似

• 觸發機制

  Redis會記錄上次重寫時的AOF大小，默認配置是當AOF文件大小是上次rewrite后大小的一倍且文件大于64M時觸發

總結

RDB持久化方式能夠在指定的時間間隔能對你的數據進行快照存儲

AOF持久化方式記錄每次對服務器寫的操作,當服務器重啟的時候會重新執行這些命令來恢復原始的數據,AOF命令以redis協議追加保存每次寫的操作到文件末尾.Redis還能對AOF文件進行后臺重寫,使得AOF文件的體積不至于過大

只做緩存：如果你只希望你的數據在服務器運行的時候存在,你也可以不使用任何持久化方式.

同時開啟兩種持久化方式：

• 在這種情況下,當redis重啟的時候會優先載入AOF文件來恢復原始的數據,因為在通常情況下AOF文件保存的數據集要比RDB文件保存的數據集要完整.

• RDB的數據不實時，同時使用兩者時服務器重啟也只會找AOF文件。那要不要只使用AOF呢？作者建議不要，因為RDB更適合用于備份數據庫(AOF在不斷變化不好備份)，快速重啟，而且不會有AOF可能潛在的bug，留著作為一個萬一的手段。

性能建議：

因為RDB文件只用做后備用途，建議只在Slave上持久化RDB文件，

如果使用AOF，好處是最惡劣的情況下只會丟失不超過2秒的數據，代價是持續的IO，AOF 的Rewrite過程中產生的新數據寫到新文件造成的阻塞幾乎是不可避免的，應盡量減少rewrite的頻率，默認重寫基礎大小是64M太小，可以根據需求設置GB級別的寫入大小。

如果不使用AOF，僅適用Master-Slave Replication實現高可用也可以，能省掉一大筆的IO，代價是如果M和S同時掛掉，會丟失十幾分鐘的數據，啟動腳本只要比較兩個RDB的文件載入較新的。新浪微博選用這種架構

Redis的事務

事務流程

• 開啟：以MULTI開始一個事務

• 入隊：將多個命令入隊到事務中，接到這些命令并不會立即執行，而是放到等待執行的事務隊列里面

• 執行：由EXEC命令觸發事務

事務執行分類

• 正常執行

• 放棄事務：DISCARD放棄事務執行

• 全體連坐：有一個錯誤全部失敗

• 冤頭債主：誰有錯誰不執行，不影響其他的語句

• watch監控

watch監控

• 樂觀鎖：

  樂觀鎖(Optimistic Lock), 顧名思義，就是很樂觀，每次去拿數據的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號等機制判斷是否修改。樂觀鎖適用于多讀的應用類型，這樣可以提高吞吐量，樂觀鎖策略:提交版本必須大于記錄當前版本才能執行更新

• 悲觀鎖：

  悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀，每次去拿數據的時候都認為別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會block直到它拿到鎖。傳統的關系型數據庫里邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖

Watch指令，類似樂觀鎖，事務提交時，如果Key的值已被別的客戶端改變，比如某個list已被別的客戶端push/pop過了，整個事務隊列都不會被執行

通過WATCH命令在事務執行之前監控了多個Keys，倘若在WATCH之后有任何Key的值發生了變化，EXEC命令執行的事務都將被放棄，同時返回Nullmulti-bulk應答以通知調用者事務執行失敗

Redis事務特性

• 單獨的隔離操作：事務中的所有命令都會序列化、按順序地執行。事務在執行的過程中，不會被其他客戶端發送來的命令請求所打斷。

• 沒有隔離級別的概念：隊列中的命令沒有提交之前都不會實際的被執行，因為事務提交前任何指令都不會被實際執行，也就不存在”事務內的查詢要看到事務里的更新，在事務外查詢不能看到”這個讓人萬分頭痛的問題

• 不保證原子性：redis同一個事務中如果有一條命令執行失敗，其后的命令仍然會被執行，沒有回滾

Redis的發布和訂閱

進程間的一種消息通信模式：發送者(pub)發送消息，訂閱者(sub)接收消息。

一次訂閱多個：SUBSCRIBE c1 c2 c3（可以使用通配符，例如SUBSCRIBE news*）

消息發布 ：PUBLISH c2 helloworld

一般企業中發布消息中間件不會使用Redis去做，了解即可

Redis的復制

也就是我們所說的主從復制，主機數據更新后根據配置和策略，自動同步到備機的master/slaver機制，Master以寫為主，Slave以讀為主

可以做什么：讀寫分離，容災備份

使用

遵循配從(庫)不配主(庫)的原則

• 從庫配置：slaveof 主庫IP 主庫端口

  每次與master斷開之后，都需要重新連接，除非你配置進redis.conf文件(使用info replication 可以查看當先信息)

  需要修改的配置：

  拷貝多個redis.conf文件開啟daemonize yespid文件名字指定端口log文件名字dump.rdb名字

• 常用配置結構

  • 一主二仆：一個Master兩個Slave，主機掛掉之后，剩下的機器還是slave狀態，主機復活之后維持原來的主機地位，從機掛掉，除非是寫過配置文件，否則不會恢復從機的身份。

  • 薪火相傳：上一個Slave可以是下一個slave的Master，Slave同樣可以接收其他slaves的連接和同步請求，那么該slave作為了鏈條中下一個的master,可以有效減輕master的寫壓力

  • 反客為主：SLAVEOF no one，使當前數據庫停止與其他數據庫的同步，轉成主數據庫

Redis復制原理

slave啟動成功連接到master后會發送一個sync命令。Master接到命令啟動后臺的存盤進程，同時收集所有接收到的用于修改數據集命令，在后臺進程執行完畢之后，master將傳送整個數據文件到slave,以完成一次完全同步

全量復制：而slave服務在接收到數據庫文件數據后，將其存盤并加載到內存中。增量復制：Master繼續將新的所有收集到的修改命令依次傳給slave,完成同步但是只要是重新連接master,一次完全同步（全量復制)將被自動執行

哨兵模式

反客為主的自動版，能夠后臺監控主機是否故障，如果故障了根據投票數自動將從庫轉換為主庫

使用

• 新建sentinel.conf文件

• 填寫內容： sentinel monitor 被監控數據庫名字(自己起名字) 127.0.0.1 6379 1（1表示主機掛掉后salve投票看讓誰接替成為主機，得票數多少后成為主機）

• 啟動 redis-sentinel sentinel.conf 哨兵開始監控主機，主機掛掉選取主機，原主機重新啟動之后將會變成Slave

一組sentinel能同時監控多個Master

復制的缺點

由于所有的寫操作都是先在Master上操作，然后同步更新到Slave上，所以從Master同步到Slave機器有一定的延遲，當系統很繁忙的時候，延遲問題會更加嚴重，Slave機器數量的增加也會使這個問題更加嚴重。

問題

• Redis和Memcache區別對比？如何選擇這兩個技術？

  區別：

  1） Redis和Memcache都是將數據存放在內存中，都是內存數據庫。不過memcache還可用于緩存其他東西，例如圖片、視頻等等。

  2）Redis不僅僅支持簡單的k/v類型的數據，同時還提供list，set，hash等數據結構的存儲。

  3）虛擬內存--Redis當物理內存用完時，可以將一些很久沒用到的value 交換到磁盤

  4）過期策略--memcache在set時就指定，例如set key1 0 0 8,即永不過期。Redis可以通過例如expire 設定，例如expire name 10

  5）分布式--設定memcache集群，利用magent做一主多從;redis可以做一主多從。都可以一主一從

  6）存儲數據安全--memcache掛掉后，數據沒了；redis可以定期保存到磁盤（持久化）

  7）災難恢復--memcache掛掉后，數據不可恢復; redis數據丟失后可以通過aof恢復

  8）Redis支持數據的備份，即master-slave模式的數據備份。

  選型：

  若是簡單的存取key-value這樣的數據用memcache好一些

  若是要支持數據持久化，多數據類型(如集合、散列之類的)，用列表類型做隊列之類的高級應用，就用redis

• Redis的持久化機制是什么？各自的優缺點？

  redis提供兩種持久化機制RDB和AOF機制。

  1）RDB持久化方式：

  是指用數據集快照的方式記錄redis數據庫的所有鍵值對。

  優點：

  1.只有一個文件dump.rdb，方便持久化。

  2.容災性好，一個文件可以保存到安全的磁盤。

  3.性能最大化，fork子進程來完成寫操作，讓主進程繼續處理命令，所以是IO最大化。

  4.相對于數據集大時，比AOF的啟動效率更高。

  缺點：

  1.數據安全性低。

  2）AOF持久化方式：

  是指所有的命令行記錄以redis命令請求協議的格式保存為aof文件。

  優點：

  1.數據安全，aof持久化可以配置appendfsync屬性，有always，每進行一次命令操作就記錄到aof文件中一次。

  2.通過append模式寫文件，即使中途服務器宕機，可以通過redis-check-aof工具解決數據一致性問題。

  3.AOF機制的rewrite模式。

  缺點：

  1.文件會比RDB形式的文件大。

  2.數據集大的時候，比rdb啟動效率低。