1.列舉至少3個非關係型資料庫，簡單描述他們的特性

Memcached

特性：資料都在記憶體中，一般不持久化

　　　 支援簡單的　　　　key-value模式

　　　 一般是作為快取資料庫輔助持久化的資料庫

Redis

　　 特性：幾乎覆蓋了Memcached的絕大部分功能

　　　　　　資料都在記憶體中，支援持久化，主要用作備份恢復 除了支援簡單的key-value模式，還支援多種資料結構的儲存，比如 　　　　　　list、set、hash、zset等。

　　　　　　一般是作為快取資料庫輔助持久化的資料庫

mongoDB

　　　特性：高效能、開源、模式自由(schema free)的文件型資料庫 資料都在記憶體中， 如果記憶體不足，把不常用的資料儲存到硬碟 　　　　　　雖然是key-value模式，但是對value（尤其是json）提供了豐富的查詢功能

　　　　　　支援二進位制資料及大型物件 可以根據資料的特點替代RDBMS ，成為獨立的資料庫。或者配合RDBMS，儲存特定的資料。

2.reids常用的資料型別有哪些？（介紹一下各資料型別的特點）

Redis支援儲存的多種key-value型別，包括string(字串)、list(連結串列)、set(集合)、zset(sorted set --有序集合)和hash（雜湊型別）。

1. 字串型別（string）

這是redis中最基本的型別，也是最常用的型別，跟memcached一樣，即一個key對應一個值這種。操作也很簡單，常用操作命令有get、set、del等。

2. 連結串列型別（list）

連結串列型別有點類似於程式語言中的陣列一樣，可以用一個key存一組資料進去。其實list型別就是一個雙向連結串列，通過lpush、lpop、rpush、rpop這四個命令來向連結串列的頭部插入、移除、尾部插入、移除，這使得list即可以用作棧，也可以用作佇列。

3set（集合）

redis中的set是string型別的無序集合，set元素最大可以包含2的32次方-1個元素。利用set集合型別，我們可以快速取出n個key之間的並集、交集、差集等，從而輕鬆解決mysql等資料庫不容易實現這種運算的缺陷。應用場景：取出兩個QQ號中的共同的好友數。

4. 有序集合型別（sorted set）

和set一樣，sorted set也是string型別元素的集合，是一個沒有重複元素的字串集合。因為元素是有序的，所以使用有序集合你可以以非常快的速度（O(log(N))）新增，刪除和更新元素，它也很擅長排序。應用場景：獲取所有使用者投票數最高的前10名，等等。

5. 雜湊型別（hash）

hash資料型別儲存的資料與mysql資料庫中儲存一條記錄極為相似，其儲存了欄位和欄位值的對映，但欄位值只能是字串，不支援其他型別。每一個雜湊可以儲存超過2的32次方-1個欄位-值對。應用場景：儲存使用者的基本資訊，等等。

3.redis的持久化方式是什麼？分別有什麼特點？如何選取持久化方式？（或者問Redis的資料持久化方式有哪些？如何進行的持久化？如何選取持久化方式？）

redis 持久化的兩種方式

• RDB：RDB 持久化機制，是對 redis 中的資料執行週期性的持久化。
• AOF：AOF 機制對每條寫入命令作為日誌，以append-only的模式寫入一個日誌檔案中，在 redis 重啟的時候，可以通過回放AOF 日誌中的寫入指令來重新構建整個資料集。

通過 RDB 或 AOF，都可以將 redis 記憶體中的資料給持久化到磁碟上面來，然後可以將這些資料備份到別的地方去，比如說阿里雲等雲服務。

如果 redis 掛了，伺服器上的記憶體和磁碟上的資料都丟了，可以從雲服務上拷貝回來之前的資料，放到指定的目錄中，然後重新啟動 redis，redis 就會自動根據持久化資料檔案中的資料，去恢復記憶體中的資料，繼續對外提供服務。

如果同時使用 RDB 和 AOF 兩種持久化機制，那麼在 redis 重啟的時候，會使用AOF來重新構建資料，因為 AOF 中的資料更加完整。

RDB 優缺點

• RDB會生成多個數據檔案，每個資料檔案都代表了某一個時刻中 redis 的資料，這種多個數據檔案的方式，非常適合做冷備，可以將這種完整的資料檔案傳送到一些遠端的安全儲存上去，比如說 Amazon 的 S3 雲服務上去，在國內可以是阿里雲的 ODPS 分散式儲存上，以預定好的備份策略來定期備份redis中的資料。

• RDB 對 redis 對外提供的讀寫服務，影響非常小，可以讓 redis保持高效能，因為 redis 主程序只需要 fork 一個子程序，讓子程序執行磁碟 IO 操作來進行 RDB 持久化即可。

• 相對於 AOF 持久化機制來說，直接基於 RDB 資料檔案來重啟和恢復 redis 程序，更加快速。

• 如果想要在 redis 故障時，儘可能少的丟失資料，那麼 RDB 沒有 AOF 好。一般來說，RDB 資料快照檔案，都是每隔 5 分鐘，或者更長時間生成一次，這個時候就得接受一旦 redis 程序宕機，那麼會丟失最近 5 分鐘的資料。

• RDB 每次在 fork 子程序來執行 RDB 快照資料檔案生成的時候，如果資料檔案特別大，可能會導致對客戶端提供的服務暫停數毫秒，或者甚至數秒。

AOF 優缺點

• AOF 可以更好的保護資料不丟失，一般 AOF 會每隔 1 秒，通過一個後臺執行緒執行一次fsync操作，最多丟失 1 秒鐘的資料。
• AOF 日誌檔案以append-only模式寫入，所以沒有任何磁碟定址的開銷，寫入效能非常高，而且檔案不容易破損，即使檔案尾部破損，也很容易修復。
• AOF 日誌檔案即使過大的時候，出現後臺重寫操作，也不會影響客戶端的讀寫。因為在rewritelog 的時候，會對其中的指導進行壓縮，創建出一份需要恢復資料的最小日誌出來。再建立新日誌檔案的時候，老的日誌檔案還是照常寫入。當新的 merge 後的日誌檔案 ready 的時候，再交換新老日誌檔案即可。
• AOF 日誌檔案的命令通過非常可讀的方式進行記錄，這個特性非常適合做災難性的誤刪除的緊急恢復。比如某人不小心用flushall命令清空了所有資料，只要這個時候後臺rewrite還沒有發生，那麼就可以立即拷貝 AOF 檔案，將最後一條flushall命令給刪了，然後再將該AOF檔案放回去，就可以通過恢復機制，自動恢復所有資料。
• 對於同一份資料來說，AOF 日誌檔案通常比 RDB 資料快照檔案更大。
• AOF 開啟後，支援的寫 QPS 會比 RDB 支援的寫 QPS 低，因為 AOF 一般會配置成每秒fsync一次日誌檔案，當然，每秒一次fsync，效能也還是很高的。（如果實時寫入，那麼 QPS 會大降，redis 效能會大大降低）
• 以前 AOF 發生過 bug，就是通過 AOF 記錄的日誌，進行資料恢復的時候，沒有恢復一模一樣的資料出來。所以說，類似 AOF 這種較為複雜的基於命令日誌/merge/回放的方式，比基於 RDB 每次持久化一份完整的資料快照檔案的方式，更加脆弱一些，容易有 bug。不過 AOF 就是為了避免 rewrite 過程導致的 bug，因此每次 rewrite 並不是基於舊的指令日誌進行 merge 的，而是基於當時記憶體中的資料進行指令的重新構建，這樣健壯性會好很多。

RDB和AOF到底該如何選擇

• 不要僅僅使用 RDB，因為那樣會導致你丟失很多資料
• 也不要僅僅使用 AOF，因為那樣有兩個問題，第一，你通過 AOF 做冷備，沒有 RDB 做冷備，來的恢復速度更快; 第二，RDB 每次簡單粗暴生成資料快照，更加健壯，可以避免 AOF 這種複雜的備份和恢復機制的 bug。
• redis 支援同時開啟開啟兩種持久化方式，我們可以綜合使用 AOF 和 RDB 兩種持久化機制，用 AOF 來保證資料不丟失，作為資料恢復的第一選擇; 用 RDB 來做不同程度的冷備，在 AOF 檔案都丟失或損壞不可用的時候，還可以使用 RDB 來進行快速的資料恢復。

4.redis的事務有什麼作用?CAS是什麼意思？常用的事務命令是什麼？watch的作用是什麼？

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

Redis事務的主要作用就是串聯多個命令防止別的命令插隊

樂觀鎖(Optimistic Lock), 顧名思義，就是很樂觀，每次去拿資料的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個資料，可以使用版本號等機制。樂觀鎖適用於多讀的應用型別，這樣可以提高吞吐量。Redis就是利用這種check-and-set機制實現事務的。

WATCH key [key ...] 在執行multi之前，先執行watch key1 [key2],可以監視一個(或多個) key ，如果在事務執行之前這個(或這些) key 被其他命令所改動，那麼事務將被打斷。

unwatch 取消WATCH命令對所有 key 的監視。 如果在執行WATCH命令之後，EXEC命令或DISCARD命令先被執行了的話，那麼就不需要再執行UNWATCH了。

WATCH命令可以監控一個或多個鍵，一旦其中有一個鍵被修改（或刪除），之後的事務就不會執行。監控一直持續到EXEC命令（事務中的命令是在EXEC之後才執行的，所以在MULTI命令後可以修改WATCH監控的鍵值）

5.redis的主從複製有什麼優點？能否解決redis的容量問題？能否分攤寫操作的壓力？

• 一個Master可以同步多個Slaves
• Slave同樣可以接受其它Slaves的連線和同步請求，這樣可以有效的分載Master的同步壓力。因此我們可以將Redis的Replication架構視為圖結構
• Master Server是以非阻塞的方式為Slaves提供服務。所以在Master-Slave同步期間，客戶端仍然可以提交查詢或修改請求
• Slave Server同樣是以非阻塞的方式完成資料同步。在同步期間，如果有客戶端提交查詢請求，Redis則返回同步之前的資料
• 為了分載Master的讀操作壓力，Slave伺服器可以為客戶端提供只讀操作的服務，寫服務仍然必須由Master來完成。即便如此，系統的伸縮性還是得到了很大的提高
• Master可以將資料儲存操作交給Slaves完成，從而避免了在Master中要有獨立的程序來完成此操作
• 支援主從複製，主機會自動將資料同步到從機，可以進行讀寫分離

一個機器啟動多個例項，其實並不會耗費太多資源，因為Redis夠輕量，另外多個例項一個接一個的重寫AOF檔案或者生成記憶體快照，可以降低記憶體的佔用，而不影響對外的服務

6.主從複製中主節點down機,怎麼實現主從切換（自動、手動）？自動實現從轉主的時候，選取slave轉為master的選取機制是？

上一個slave可以是下一個slave的Master，slave同樣可以接收其他slaves的連線和同步請求，那麼該slave作為了鏈條中下一個的master, 可以有效減輕master的寫壓力,去中心化降低風險。 用 slaveof <ip> <port> 中途變更轉向:會清除之前的資料，重新建立拷貝最新的 風險是一旦某個slave宕機，後面的slave都沒法備份

當一個master宕機後，後面的slave可以立刻升為master，其後面的slave不用做任何修改。。 用 slaveof no one 將從機變為主機。

7.Redis中哨兵的作用是什麼？

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

8.當Redis資料庫容量不夠,併發寫資料量較大,如何分攤壓力和擴容?簡述redis叢集的搭建流程？

1、安裝ruby環境

能上網

執行yum install ruby 執行yum install rubygems

不能上網

cd /run/media/root/CentOS 7 x86_64/Packages（路徑跟centos6不同）獲取右圖rpm包 拷貝到/opt/rpmruby/目錄下，並cd到此目錄 執行：rpm -Uvh *.rpm --nodeps --force 按照依賴安裝各個rpm包

2.拷貝redis-3.2.0.gem到/opt目錄下

3.執行在opt目錄下執行 gem install --local redis-3.2.0.gem