1、使用redis有哪些好處？

(1) 速度快，因為數(shù)據(jù)存在內(nèi)存中，類似于HashMap，HashMap的優(yōu)勢就是查找和操作的時間復雜度都是O(1)

(2) 支持豐富數(shù)據(jù)類型，支持string，list，set，sorted set，hash

(3) 支持事務，操作都是原子性，所謂的原子性就是對數(shù)據(jù)的更改要么全部執(zhí)行，要么全部不執(zhí)行

(4) 豐富的特性：可用于緩存，消息，按key設置過期時間，過期后將會自動刪除

2、redis相比memcached有哪些優(yōu)勢？

(1) memcached所有的值均是簡單的字符串，redis作為其替代者，支持更為豐富的數(shù)據(jù)類型

(2) redis的速度比memcached快很多

(3) redis可以持久化其數(shù)據(jù)

3、redis常見性能問題和解決方案：

(1) Master最好不要做任何持久化工作，如RDB內(nèi)存快照和AOF日志文件

(2) 如果數(shù)據(jù)比較重要，某個Slave開啟AOF備份數(shù)據(jù)，策略設置為每秒同步一次

(3) 為了主從復制的速度和連接的穩(wěn)定性，Master和Slave最好在同一個局域網(wǎng)內(nèi)

(4) 盡量避免在壓力很大的主庫上增加從庫

(5) 主從復制不要用圖狀結構，用單向鏈表結構更為穩(wěn)定，即：Master <- Slave1 <- Slave2 <- Slave3…

這樣的結構方便解決單點故障問題，實現(xiàn)Slave對Master的替換。如果Master掛了，可以立刻啟用Slave1做Master，其他不變。

4、MySQL里有2000w數(shù)據(jù)，redis中只存20w的數(shù)據(jù)，如何保證redis中的數(shù)據(jù)都是熱點數(shù)據(jù)

相關知識：redis 內(nèi)存數(shù)據(jù)集大小上升到一定大小的時候，就會施行數(shù)據(jù)淘汰策略。redis 提供 6種數(shù)據(jù)淘汰策略：

voltile-lru：從已設置過期時間的數(shù)據(jù)集（server.db[i].expires）中挑選最近最少使用的數(shù)據(jù)淘汰

volatile-ttl：從已設置過期時間的數(shù)據(jù)集（server.db[i].expires）中挑選將要過期的數(shù)據(jù)淘汰

volatile-random：從已設置過期時間的數(shù)據(jù)集（server.db[i].expires）中任意選擇數(shù)據(jù)淘汰

allkeys-lru：從數(shù)據(jù)集（server.db[i].dict）中挑選最近最少使用的數(shù)據(jù)淘汰

allkeys-random：從數(shù)據(jù)集（server.db[i].dict）中任意選擇數(shù)據(jù)淘汰

no-enviction（驅逐）：禁止驅逐數(shù)據(jù)

5、Memcache與Redis的區(qū)別都有哪些？

1)、存儲方式

Memecache把數(shù)據(jù)全部存在內(nèi)存之中，斷電后會掛掉，數(shù)據(jù)不能超過內(nèi)存大小。

Redis有部份存在硬盤上，這樣能保證數(shù)據(jù)的持久性。

2)、數(shù)據(jù)支持類型

Memcache對數(shù)據(jù)類型支持相對簡單。

Redis有復雜的數(shù)據(jù)類型。

3)、使用底層模型不同

它們之間底層實現(xiàn)方式 以及與客戶端之間通信的應用協(xié)議不一樣。

Redis直接自己構建了VM 機制 ，因為一般的系統(tǒng)調(diào)用系統(tǒng)函數(shù)的話，會浪費一定的時間去移動和請求。

4），value大小

redis最大可以達到1GB，而memcache只有1MB

6、Redis 常見的性能問題都有哪些？如何解決？

1).Master寫內(nèi)存快照，save命令調(diào)度rdbSave函數(shù)，會阻塞主線程的工作，當快照比較大時對性能影響是非常大的，會間斷性暫停服務，所以Master最好不要寫內(nèi)存快照。

2).Master AOF持久化，如果不重寫AOF文件，這個持久化方式對性能的影響是最小的，但是AOF文件會不斷增大，AOF文件過大會影響Master重啟的恢復速度。

Master最好不要做任何持久化工作，包括內(nèi)存快照和AOF日志文件，特別是不要啟用內(nèi)存快照做持久化,如果數(shù)據(jù)比較關鍵，某個Slave開啟AOF備份數(shù)據(jù)，策略為每秒同步一次。

3).Master調(diào)用BGREWRITEAOF重寫AOF文件，AOF在重寫的時候會占大量的CPU和內(nèi)存資源，導致服務load過高，出現(xiàn)短暫服務暫?，F(xiàn)象。

4). Redis主從復制的性能問題，為了主從復制的速度和連接的穩(wěn)定性，Slave和Master最好在同一個局域網(wǎng)內(nèi)

7、redis 最適合的場景

Redis最適合所有數(shù)據(jù)in-momory的場景，雖然Redis也提供持久化功能，但實際