Nosql：非關係型資料庫

• 分表分庫 + 水平拆分 + mysql叢集：

  • 在Memcached的快取記憶體，Mysql主從複製、讀寫分離的基礎上，由於MyISAM使用表鎖，高併發Mysql應用開始使用InnoDB引擎代替MyISAM。現如今分表分庫 + 水平拆分 + mysql叢集 已經成為解決緩解寫壓力和資料增長的問題的熱門技術。

• NoSQL用於超大規模資料的儲存。這些型別的資料儲存不需要固定的模式，無需多餘操作就可以橫向擴充套件。

• - 代表著不僅僅是SQL
  - 沒有宣告性查詢語言
  - 沒有預定義的模式
  -鍵 - 值對儲存，列儲存，文件儲存，圖形資料庫
  - 最終一致性，而非ACID屬性
  - 非結構化和不可預知的資料

  - 高效能，高可用性和可伸縮性

  - CAP定理

• CAP定理：對於一個分散式計算系統來說，不可能同時滿足以下三點:

  • 一致性(Consistency) (所有節點在同一時間具有相同的資料)
  • 可用性(Availability) (保證每個請求不管成功或者失敗都有響應)
  • 分隔容忍(Partition tolerance) (系統中任意資訊的丟失或失敗不會影響系統的繼續運作)

  ​ CAP理論的核心是：一個分散式系統不可能同時很好的滿足一致性，可用性和分割槽容錯性這三個需求，最多隻能同時較好的滿足兩個。

  ​ 因此，根據 CAP 原理將 NoSQL 資料庫分成了滿足 CA 原則、滿足 CP 原則和滿足 AP 原則三 大類：

  • CA - 單點叢集，滿足一致性，可用性的系統，通常在可擴充套件性上不太強大。
  • CP - 滿足一致性，分割槽容忍性的系統，通常效能不是特別高。
  • AP - 滿足可用性，分割槽容忍性的系統，通常可能對一致性要求低一些。

• NoSQL資料模型：

  • 聚合模型：（主要是前兩個）
    • KV鍵值
    • Bson：類似JSON，可以在 Value中放 JSON， 可分可合
    • 列族：每個欄位放在一行
    • 圖形

• NoSQL資料庫四大分類：

  • KV鍵值：典型介紹：阿里百度（memcache+redis），美團（redis+tair），新浪（BerkeleyDB+redis）
  • 文件型資料庫：json格式比較多，如MongoDB(基於分散式檔案儲存資料庫)
  • 列儲存資料庫：分散式檔案系統、Cassandra、HBase
  • 圖關係資料庫：存放關係圖，如：朋友圈社交網路、廣告推薦系統、社交系統、推薦系統等，專注於構建關係圖譜。Neo4J，InfoGrid

Redis（Remote Dictionary Server（遠端字典伺服器））

• Redis = KV + Cache + persistence
• 3V+3高：海量Volume、多樣Variety、實時Velocity、高併發、高可擴、高效能
• CAP（與關係型資料庫中相對的是ACID）（和ACID都要滿足四個條件不同，CAP最多隻能三選二）
  • C：Consistency 強一致性。資料強一致性，強實時性
  • A：Avaliability 可用性。可以理解為網站執行的穩定性
  • P：Partition tolerance 分割槽容錯性。（分散式系統必須要實現）
    • CA - 單點叢集，滿足一致性，可用性的系統，通常在可擴充套件性上不太強大。如Oracle、Mysql
    • CP - 滿足一致性，分割槽容忍性的系統，通常效能不是特別高。如MongoDB、HBase、Redis
    • AP - 滿足可用性，分割槽容忍性的系統，通常可能對一致性要求低一些。大多數網站架構的選擇AP+弱一致性

• BASE（犧牲CAP 中的 C 換取 AP）
  • 基本可用（Basically Available）
  • 軟狀態（Soft state）
  • 最終一致（Eventually consistent）
• 分散式 + 叢集：
  • 分散式：不同的多臺伺服器上部署不同的服務模組（工程），他們之間通過RPC/Rmi之間通訊和呼叫，對外提供服務和組內工作
  • 叢集：不同的多臺伺服器上面部署相同的服務模組，通過分散式排程軟體進行統一的排程，對外提供服務和訪問
• Redis支援資料持久化，資料型別包括：KV、list、set、zset、hash等資料結構的儲存。Redis支援master-slave模式的資料備份
• Linux中Redis開啟服務：/usr/local/bin/redis-server /opt/myRedis/redis.conf
• 啟動Redis客戶端：redis-cli -p 6379 6379是Redis預設埠 退出：exit 或 ctrl+c 關閉服務：SHUTDOWN
• ps -ef|grep redis ：檢視redis服務的是否啟動
• lsof -i :6379 ：根據redis 的埠檢視redis程序
• redis預設安裝在：/usr/local/bin

Redis常用命令

• Redis預設在redis.conf中配置16個數據庫0-15， select 7 ：表示使用6號資料庫,

• set 和 get 能存放和取出資料， 其中set key val 時key已經存在，則覆蓋

• keys k* : 查詢以 k 開頭的鍵 FLUSH：刪除

• keys * ：查詢所有key，move k 2：將 k 移動到2號資料庫

• exists key：判斷這個key是否在當前資料庫中存在

• expire key 1 : 設定key過期時間為1秒

• ttl key : 檢視還有多少秒過期，-1表示永不過期，-2表示已經過期

• type key ： 檢視key的型別

• del key：刪除key

Redis五大資料型別

• String：與Memcached一樣的型別，即一個key對應一個value。String是二進位制安全的，意思是可以包含任何資料型別。value最多可以是512M
  • STRLEN key : 檢視key的長度 INCR key：該key的值+1 DECR key則-1
  • INCRBY key 3 和 DECRBY key 3：分別是每次+3和每次-3
  • GETRANGE key 0 -1 : 獲取key的value並擷取索引長度，0 -1表示擷取全部
  • SETRANGE key 0 val: 從該key的value的索引位置0開始插入值 val
  • setex key 10 val : 新增key-val 同時設定過期時間為10
  • setnx key val : 如果該key不存在，則新增key-val ，如果key存在則該命令不生效
  • mset k1 v1 k2 v2 k3 v3: 插入多個數據
  • msetnx k1 v1 k2 v2 k3 v3 ：若k1 k2 k3 中有一個已經存在，則全部新增失敗
• Hash：類似Java的Map，是一個String型別的field和value的對映表，hash特別適合用於儲存物件
  • HSET user id 11：插入鍵值對 id-11
  • HGET user id：獲取value
  • HMSET user id 11 name lisi age 18：一口氣插入 HMGET user id name age
  • HGETALL user：查詢所有對映關係
  • HDEL user name：刪除
  • HLEN user：長度
  • HEXISTS user id：查詢該表的id 這個key是否存在
  • HKEYS user：查詢所有key HVALS user：查詢所有value
  • HINCRBY user age 2：key為age的value，每次 +2
  • HINCRBYFLOAD user age 0.5：key為age的value，每次 +0.5
  • HSETNX user age 16： 不存在age這個key才插入有效
• List（列表）：底層是個連結串列，是簡單的字串列表，按照插入順序排序，可以頭插也可以尾插。類似雙向迴圈連結串列LinkedList
  • LPUSH list01 1 2 3 4 ：依次從最左邊插入到ilist01，結果為4 3 2 1 ， RPUSH同理
  • LRANGE list01 0 -1: 查詢 集合 list01所有value，0 和 -1 表示索引位置
  • lpop list01：表示list01的左邊作為棧頂出棧一個值，同理rpop表示list01的右邊作為棧頂出棧一個值
  • LINDEX list01 3 : 查詢列表list01索引3的value
  • LLEN list01 ： 列表長度
  • LREM list01 2 3 : 刪除2個索引為3的元素
  • LTRAM list01 3 5 ： 擷取索引為3到5的元素並重新覆蓋list01
  • RPOPLPUSH：list01 list02 ： 相當於 RPOP list01 的結果 LPUSH 進 list02
  • LSET list01 1 x：從左邊起索引為1的位置上插入string型別的 x
  • LINSERT list01 before/after x java：在x的左邊/右邊插入元素 java
• Set (集合)：是string型別的無序集合，不允許重複，是通過HashTable實現的
  • sadd set01 1 1 2 2 3 3：只新增 1 2 3
  • SMEMBERS set01 0 -1：查詢set01集合，也可以用SMEMBERS set01
  • SISMEMBER set01 x：判斷x是否存在
  • SCART set01：獲取集合的元素個數
  • SREM set01 3：刪除集合中值為 ‘3’ 的元素
  • SRANDMEMBER：set01 3 ：從set01中隨機得到3個元素
  • SPOP set01：隨機出棧一個元素
  • SMOVE set01 set02 5：將set01中 5 這個元素移動到set02
  • DEL set01：刪除集合
  • SDIFF set01 set02：輸出set01中set02所沒有的元素，即差集
  • SINTER set01 set02：輸出交集
  • SUNION set01 set02：輸出並集，
• Zset (sortedSet有序集合)：是string型別的有序集合且不允許重複，每個元素都會關聯一個double型別的分數，通過分數從小到大排序。zset成員是唯一的，但分數可以重複
  • ZADD zset01 60 v1 70 v2：60和70表示分數，越小排序越前
  • ZRANGE zset01 0 -1：查詢所有 ZRANGE zset01 0 -1 WITHSCOPES：查詢所有且帶分數
  • ZRANGEBYSCOPE zset01 60 90：查詢分數60-90的元素 ZRANGEBYSCOPE zset01 60 (90 ： 查詢分數60-90的元素但不包含90
  • ZRANGEBYSCOPE zset01 60 90 limit 2 3：從分數60-90的元素中從索引為2的位置擷取3個
  • ZREM zset01 v1：刪除
  • ZCARD zset01 ：查詢元素個數 ZCOUNT zset01 60 80：查詢分數在60-90元素個數
  • ZRANK zset01 v2：查詢元素下標 ZSCOP zset01 v2：查詢元素分數
  • ZREVRANK zset01 v2：逆序獲得下標值 ZREVRANGE zset01 0 -1：逆序輸出
  • ZREVRANGEBYSCOPE zset01 60-90：查詢分數60-90的元素並逆序輸出

redis.conf

• redis.conf 預設安裝在：/opt/myRedis

• Units單位：配置大小單位，定義了一些基本的度量單位，只支援bytes不支援bit，對大小寫不敏感

• INCLUDES：包含其他配置檔案，作為總閘

• GENERAL：

  • daemonize yes：啟用守護程序。設定redis關掉終端後，redis服務和程序還在執行。

  • port 6379：預設埠

  • tcp-backlog 511：配置tcp的backlog ，是一個連線佇列，backlog 佇列總和=未完成三次握手佇列+已經完成三次握手佇列，高併發環境下需要一個高backlog 值來避免客戶端連線慢問題

  • bind IP：設定連線的IP

  • timeout 0：設定空閒多少秒後關閉redis連線，0表示一直連線不關閉

  • Tcp-Keepalive：單位為秒，如果設定為0，則不會進行Keepalive檢測，建議設定為60，作用類似心跳檢測、判斷每過一段時間檢測是否還存活、使用中

  • loglevel debug/verbose/notice/warning ：設定log日誌級別，從左到右級別依次變高

  • database 16：設定資料庫數量，預設為16

  • Syslog-enabled：是否把日誌輸出到syslog中，預設不使用

  • Syslog-facility：指定syslog裝置，值可以是USER或LOCAL0-LOCAL7

• SNAPSHOTTING快照（RDB）

  • dbfilename dump.rdb : 預設快照備份的檔案為dump.rdb
  • stop-writes-on-bgsave-error yes ：預設yes表示備份出錯就立即停止寫資料。如果配置成no，表示不在乎資料不一致
  • rdbcompression yes ： 對於儲存到磁碟中的快照，可以設定是否進行壓縮儲存。預設yes表示採用LZF演算法進行壓縮 ，會消耗cpu，建議開啟
  • rdbchecksum yes: 在儲存快照後，可以使用CRC64演算法來進行資料檢驗，但會增大約10%的效能消耗，建議開啟
  • dir : 設定快照的備份檔案dump.rdb 所在目錄，config get dir 可以獲得目錄

• REPLICATION複製

• SECURITY安全：

  • config set requirepass "123456" : 設定密碼，此時若直接ping，則會失敗，需要先輸入密碼：auth 123456
  • config get requirepass : 獲取密碼

• LIMITS限制：

  • Maxclients：最大同時連線數，預設10000
  • Maxmemory：單位為位元組，最大記憶體
  • Maxmemory-policy：快取策略。預設是noeviction永不過期策略，但一般不使用該策略
    • volatile-lru：使用LRU(最近最少使用)演算法移除key，只對設定了過期時間的鍵
    • allkeys-lru：使用LRU演算法移除key
    • volatile-random：在過期集合中移除隨機的key，只對設定了過期時間的key
    • allkeys-random：移除隨機的key
    • volatile-ttl：移除那些TTL值最小的key，即那些最近要過期的key
    • noeviction：不進行移除，針對寫操作，只是返回錯誤資訊，一般不使用該策略
  • Maxmemory-samples：設定樣本數量，LRU演算法和最小TTL演算法都不是最精確的演算法，而是估算值，所以你可以設定樣本大小，redis預設會檢查這麼多個key並選擇其中LRU的那個。預設選取5個樣本

• APPEND ONLY MODE追加（AOF）

  • appendonly no : 預設關閉AOF
  • appendfilename "appendonly.aof" ：日誌記錄儲存到該檔案, 資料修改一次，追加一次日誌記錄到該檔案
  • appendfsync：3中AOF持久化策略
    • aways：同步持久化，每次發生資料變更會被立即記錄到磁碟，效能較差但資料完整性較好
    • everysec：出廠預設推薦使用，非同步操作，每秒記錄，如果一秒內宕機，會有資料丟失。
    • no：從不同步
  • No-appendfsync-on-rewrite：重寫時是否可以運用Appendfsync，預設no，保證資料安全性
  • auto-aof-rewrite-percentage 100：百分百情況下AOF檔案大小是上次rewrite後大小的一倍
  • auto-aof-rewrite-min-size 64mb：AOF檔案大於64M時觸發重寫機制。實際公司設定 3G 起步

常見redis.conf配置

引數說明
redis.conf 配置項說明如下：
1. Redis預設不是以守護程序的方式執行，可以通過該配置項修改，使用yes啟用守護程序
  daemonize no
2. 當Redis以守護程序方式執行時，Redis預設會把pid寫入/var/run/redis.pid檔案，可以通過pidfile指定
  pidfile /var/run/redis.pid
3. 指定Redis監聽埠，預設埠為6379，作者在自己的一篇博文中解釋了為什麼選用6379作為預設埠，因為6379在手機按鍵上MERZ對應的號碼，而MERZ取自義大利歌女Alessia Merz的名字
  port 6379
4. 繫結的主機地址
  bind 127.0.0.1
5.當 客戶端閒置多長時間後關閉連線，如果指定為0，表示關閉該功能
  timeout 300
6. 指定日誌記錄級別，Redis總共支援四個級別：debug、verbose、notice、warning，預設為verbose
  loglevel verbose
7. 日誌記錄方式，預設為標準輸出，如果配置Redis為守護程序方式執行，而這裡又配置為日誌記錄方式為標準輸出，則日誌將會發送給/dev/null
  logfile stdout
8. 設定資料庫的數量，預設資料庫為0，可以使用SELECT <dbid>命令在連線上指定資料庫id
  databases 16
9. 指定在多長時間內，有多少次更新操作，就將資料同步到資料檔案，可以多個條件配合
  save <seconds> <changes>
  Redis預設配置檔案中提供了三個條件：
  save 900 1
  save 300 10
  save 60 10000
  分別表示900秒（15分鐘）內有1個更改，300秒（5分鐘）內有10個更改以及60秒內有10000個更改。
 
10. 指定儲存至本地資料庫時是否壓縮資料，預設為yes，Redis採用LZF壓縮，如果為了節省CPU時間，可以關閉該選項，但會導致資料庫檔案變的巨大
  rdbcompression yes
11. 指定本地資料庫檔名，預設值為dump.rdb
  dbfilename dump.rdb
12. 指定本地資料庫存放目錄
  dir ./
13. 設定當本機為slav服務時，設定master服務的IP地址及埠，在Redis啟動時，它會自動從master進行資料同步
  slaveof <masterip> <masterport>
14. 當master服務設定了密碼保護時，slav服務連線master的密碼
  masterauth <master-password>
15. 設定Redis連線密碼，如果配置了連線密碼，客戶端在連線Redis時需要通過AUTH <password>命令提供密碼，預設關閉
  requirepass foobared
16. 設定同一時間最大客戶端連線數，預設無限制，Redis可以同時開啟的客戶端連線數為Redis程序可以開啟的最大檔案描述符數，如果設定 maxclients 0，表示不作限制。當客戶端連線數到達限制時，Redis會關閉新的連線並向客戶端返回max number of clients reached錯誤資訊
  maxclients 128
17. 指定Redis最大記憶體限制，Redis在啟動時會把資料載入到記憶體中，達到最大記憶體後，Redis會先嚐試清除已到期或即將到期的Key，當此方法處理 後，仍然到達最大記憶體設定，將無法再進行寫入操作，但仍然可以進行讀取操作。Redis新的vm機制，會把Key存放記憶體，Value會存放在swap區
  maxmemory <bytes>
18. 指定是否在每次更新操作後進行日誌記錄，Redis在預設情況下是非同步的把資料寫入磁碟，如果不開啟，可能會在斷電時導致一段時間內的資料丟失。因為 redis本身同步資料檔案是按上面save條件來同步的，所以有的資料會在一段時間內只存在於記憶體中。預設為no
  appendonly no
19. 指定更新日誌檔名，預設為appendonly.aof
   appendfilename appendonly.aof
20. 指定更新日誌條件，共有3個可選值： 
  no：表示等作業系統進行資料快取同步到磁碟（快） 
  always：表示每次更新操作後手動呼叫fsync()將資料寫到磁碟（慢，安全） 
  everysec：表示每秒同步一次（折衷，預設值）
  appendfsync everysec
 
21. 指定是否啟用虛擬記憶體機制，預設值為no，簡單的介紹一下，VM機制將資料分頁存放，由Redis將訪問量較少的頁即冷資料swap到磁碟上，訪問多的頁面由磁碟自動換出到記憶體中（在後面的文章我會仔細分析Redis的VM機制）
   vm-enabled no
22. 虛擬記憶體檔案路徑，預設值為/tmp/redis.swap，不可多個Redis例項共享
   vm-swap-file /tmp/redis.swap
23. 將所有大於vm-max-memory的資料存入虛擬記憶體,無論vm-max-memory設定多小,所有索引資料都是記憶體儲存的(Redis的索引資料 就是keys),也就是說,當vm-max-memory設定為0的時候,其實是所有value都存在於磁碟。預設值為0
   vm-max-memory 0
24. Redis swap檔案分成了很多的page，一個物件可以儲存在多個page上面，但一個page上不能被多個物件共享，vm-page-size是要根據儲存的 資料大小來設定的，作者建議如果儲存很多小物件，page大小最好設定為32或者64bytes；如果儲存很大大物件，則可以使用更大的page，如果不 確定，就使用預設值
   vm-page-size 32
25. 設定swap檔案中的page數量，由於頁表（一種表示頁面空閒或使用的bitmap）是在放在記憶體中的，，在磁碟上每8個pages將消耗1byte的記憶體。
   vm-pages 134217728
26. 設定訪問swap檔案的執行緒數,最好不要超過機器的核數,如果設定為0,那麼所有對swap檔案的操作都是序列的，可能會造成比較長時間的延遲。預設值為4
   vm-max-threads 4
27. 設定在向客戶端應答時，是否把較小的包合併為一個包傳送，預設為開啟
  glueoutputbuf yes
28. 指定在超過一定的數量或者最大的元素超過某一臨界值時，採用一種特殊的雜湊演算法
  hash-max-zipmap-entries 64
  hash-max-zipmap-value 512
29. 指定是否啟用重置雜湊，預設為開啟（後面在介紹Redis的雜湊演算法時具體介紹）
  activerehashing yes
30. 指定包含其它的配置檔案，可以在同一主機上多個Redis例項之間使用同一份配置檔案，而同時各個例項又擁有自己的特定配置檔案
  include /path/to/local.conf

持久化RDB（Redis DataBase）

• Redis持久化包含RDB（Redis DataBase快照）和AOF（Append Only File日誌）

• RDB：在指定時間間隔內將記憶體中的資料快照寫入磁碟，也就是SnapShot快照，它恢復時是將快照檔案直接讀到記憶體裡，實現持久化

• Redis會單獨建立（fork）一個子程序來進行持久化，會先將資料寫入到一個臨時檔案中，待持久化過程都結束了，再用這個臨時檔案替換上次持久化好的檔案。在整個過程中主執行緒不進行任何IO操作，確保了極高的效能。

• 如果需要進行大規模資料恢復，且對於資料恢復的完整性不是非常敏感，那RDB方式要比AOF方式更加高效。

• RDB的缺點是最後一次持久化後的資料可能丟失

• Fork的作用是複製一個與當前程序一樣的子程序。新程序的所有資料（變數、環境變數、程式計數器等）數值都和原程序一致

• RDB儲存的是dump.rdb檔案，命令是：save . 預設有以下3種儲存策略(可以自定義) ， save "" 則是禁用該功能

  • 三個策略分別為：15分鐘內改了1次，5分鐘內改了10次，1分鐘內改了一萬次，會觸發快照條件從而備份檔案，備份檔案為dump.rdb

• 可以在任何一個目錄下使用redis，所生成的db檔案也儲存在該目錄

• 一般備份dump.rdb時需要拷貝檔案到另外的備機上，以防物理損壞

• SHUTDOWN關閉redis的同時，預設會commit並備份到dump.rdb中。slushall命令也會產生dump.rdb，但空檔案無意義

• 如何恢復資料？重啟服務後，預設會將啟動redis的當前目錄下的備份檔案dump.rdb 恢復到redis資料庫中

• 手動備份命令：save 或者 bgsave。其中save只管儲存，其他不管全部阻塞。BGSAVE：表示redis會在後臺非同步進行快照操作，快照同時還可以響應客戶端請求，可以通過lastsave命令獲取最後一次成功執行快照的時間。

• config get dir 可以獲得快照的備份檔案dump.rdb所在目錄

• 優勢：適合大規模資料恢復，對資料完整性和一致性要求不高。

• 劣勢：fork時記憶體的資料被克隆了一份，大致2倍的膨脹性需要考慮記憶體空間是否足夠大。最後一次備份的資料可能丟失

• 動態停止所有RDB儲存規則命令：redis-cli config set save ""。不建議使用

• 配置檔案裡的 SNAPSHOTTING快照（RDB）

  • dbfilename dump.rdb : 預設快照備份的檔案為dump.rdb
  • stop-writes-on-bgsave-error yes ：預設yes表示備份出錯就立即停止寫資料。如果配置成no，表示不在乎資料不一致
  • rdbcompression yes ： 對於儲存到磁碟中的快照，可以設定是否進行壓縮儲存。預設yes表示採用LZF演算法進行壓縮 ，會消耗cpu，建議開啟
  • rdbchecksum yes: 在儲存快照後，可以使用CRC64演算法來進行資料檢驗，但會增大約10%的效能消耗，建議開啟
  • dir : 設定快照的備份檔案dump.rdb 所在目錄，config get dir 可以獲得目錄

持久化AOF（Append Only File）

• AOF是在RDB之後產生，是以日誌的形式記錄每個寫操作，將Redsi執行過的所有寫指令記錄，只需追加檔案但不可以改寫檔案，redis啟動之初會讀取該檔案重新構建資料。換言之，redis重啟時會根據日誌檔案的內容將寫指令從頭到尾執行一次以完成資料的恢復工作

• AOF也是啟動redis後自動執行日誌檔案appendonly.aof 從而恢復資料。

• /usr/local/bin/redis-server /myredis/redis_aof.conf ：啟動Redis服務並以aof檔案恢復資料

• dump.rdb和 appendonly.aof 可以同時存在，先載入appendonly.aof，若aof檔案中有記錄是錯的，開啟redis服務會失敗。此時在redis的bin目錄下使用命令：redis-check-aof --fix appendonly.aof 可檢視appendonly.aof 的錯誤資訊並消除其中的不規範指令，才能啟動redis服務

• appendonly.aof 因為只追加寫操作記錄，因此容易記憶體膨脹，free命令用於檢視記憶體使用情況，df -h 檢視磁碟空間

• Rewrite：

  • AOF的重寫機制，當AOF檔案大小超過所設定的閾值時，會啟動AOF檔案的內容壓縮，只保留可以不恢復資料的最小指令集，可以使用命令bgrewriteaof

  • 原理：AOF檔案持續增長而過大時，會fork出一條新程序來將檔案重寫(先寫臨時檔案最後再rename)，遍歷新程序的記憶體中資料，每條記錄有一條Set語句。重寫aof檔案的操作，並沒有讀取舊的aof檔案，而是將整個記憶體中的資料庫內容用命令的方法重寫了一個新aof檔案，類似快照。

  • 觸發機制：redis會記錄上次重寫時的AOF大小，預設配置是當AOF檔案大小是上次rewrite後大小的一倍且檔案大於64M時觸發

• （優勢）對應在redis.conf 的配置：APPEND ONLY MODE追加（AOF）

  • appendonly no : 預設關閉AOF
  • appendfilename "appendonly.aof" ：日誌記錄儲存到該檔案, 資料修改一次，追加一次日誌記錄到該檔案
  • appendfsync：3中AOF持久化策略
    • aways：同步持久化，每次發生資料變更會被立即記錄到磁碟，效能較差但資料完整性較好
    • everysec：出廠預設推薦使用，非同步操作，每秒記錄，如果一秒內宕機，會有資料丟失。
    • no：從不同步
  • No-appendfsync-on-rewrite：重寫時是否可以運用Appendfsync，預設no，保證資料安全性
  • auto-aof-rewrite-percentage 100：百分百情況下AOF檔案大小是上次rewrite後大小的一倍
  • auto-aof-rewrite-min-size 64mb：AOF檔案大於64M時觸發重寫機制。實際公司設定 3G 起步

• 劣勢：相同資料集的資料而言aof檔案遠大於rdb檔案，恢復速度慢於rdb。執行效率也慢，但每秒同步策略效率較好，不同步效率和rdb相同

• 如果Enalbe AOF，好處是在最惡劣情況下也只會丟失不超過兩秒資料，啟動指令碼較簡單隻load自己的AOF檔案就可以了。代價一是帶來了持續的IO，二是AOF rewrite的最後將rewrite過程中產生的新資料寫到新檔案造成的阻塞幾乎是不可避免的。只要硬碟許可，應該儘量減少AOF rewrite的頻率，AOF重寫的基礎大小預設值64M太小了，可以設到5G以上。預設超過原大小100%大小時重寫可以改到適當的數值。

  如果不Enable AOF ，僅靠Master-Slave Replication 實現高可用性也可以。能省掉一大筆IO也減少了rewrite時帶來的系統波動。代價是如果Master/Slave同時倒掉，會丟失十幾分鐘的資料，啟動指令碼也要比較兩個Master/Slave中的RDB檔案，載入較新的那個。新浪微博就選用了這種架構

Redis事務

• 可以一次執行多個命令，本質是一組命令的集合，一個事務中的所有命令都會序列化，按順序地序列化執行而不會被其他命令插入，不許加塞

• 能幹嘛？開啟事務後每個指令都會加入一個佇列中，一次性、順序性、排他性地執行一系列命令

• 常用命令

  • DISCARD：取消事務，放棄執行事務塊內的所有命令
  • EXEC：執行所有事務塊的命令，執行之後會一次性顯示該次事務塊中所有命令的結果
  • MULTI：標記一個事務塊的開始
  • UNWATCH：取消WATCH命令對所有key的監視
  • WATCH key [key...] ：類似樂觀鎖，監視一個或多個key，如果在事務EXEC執行之前這些key被其他命令所改動，那麼事務將被打斷，該事務提交無效

• 若事務塊中有無效命令(錯誤指令)則全部命令不生效，若事務塊中都是有效命令但有些命令無法執行成功，則只有這些命令執行失敗，其他命令無影響

• watch監控

  • 事務提交時，如果key已被其他客戶端改變，那麼整個事務佇列都不會被執行，同時返回Nullmulti-bulk應答以通知呼叫者事務執行失敗
  • 樂觀鎖(常用)：開啟WATCH後，若有命令要修改資料，則在要修改的該行資料加一個欄位：版本號version，每次修改完成後快取中該行的version+1，以後修改該行的請求所帶的版本不等於快取中version，則會報錯。此時需要重新從快取中獲取最新資料後再修改才能提交成功，保證資料一致性
  • 悲觀鎖(不常用)：認為每次修改資料都會覺得會有別的請求也要修改，因此鎖整張表
  • 一旦執行了exec，之前加的監控鎖都會被取消掉
  • CAS(Check And Set)

• 事務3階段：MULTI開啟事務=》命令入隊，此時還未被執行=》EXEC執行，觸發事務

• Redis事務3特性：

  • 單獨的隔離操作：事務中的所有命令都會被序列化、按順序執行，事務執行過程中不會被其他客戶端的命令請求打斷
  • 沒有隔離級別的概念：因為事務提交前任何指令都不會被實際執行
  • 不保證原子性；同一事務中如果有一條命令執行失敗，其後的命令仍然會被執行，沒有回滾

釋出訂閱機制

• 程序間的一種訊息通訊模式：傳送者（pub）釋出訊息，訂閱者（sub）接收訊息

• 一次性訂閱多個： SUBSCRIBE c1 c2 c3 c*

• 訊息釋出： PUBLISH c2 hello-redis

主從複製（Master/Slave）

• 配從機（庫）、主機（庫）

• 從庫配置：slaveof 主庫IP 主庫埠

• 配置從庫時需修改配置檔案，需修改：埠號、程序號pidfile、日誌logfile、RDB快照檔案dbfilename

• 通常主從複製有4招（一般都用哨兵模式）

  • 一主二從：一個主機2個從機
  • 薪火相傳：主=》從=》從。。。。若中途變更轉向，會清除之前的資料，重新建立拷貝最新的資料. 命令：Slaveof 新主庫IP 新主庫埠
  • 反客為主： SLAVEOF no one：使當前資料庫停止與其他資料庫的同步，轉為主資料庫
  • 哨兵模式：反客為主的自動版，能夠後臺監控主機是否故障，如果故障了根據投票數自動將從庫轉換為主庫

• info replication可以檢視當前redis的詳細資訊，也可檢視是主庫還是從庫

• 讀寫分離：預設只有主機可以寫，從機只能讀

• 預設當主機宕機或關閉Redis服務後，其他從機還是從機，即原地待命

• 當從機宕機或關閉Redis服務，重新啟動Redis後，需要重新連線主庫，除非redis.conf 已經有配置

• Slave啟動成功連線到master後會傳送一個sync命令

哨兵模式

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

• 使用步驟：

  • 自定義/myRedis目錄下新建 sentinel.conf

  • 配置主機監控：在sentinel.conf配置：sentinel monitor host6379 127.0.0.1 6379 1

  • 最後的數字1表示主機掛掉後slave投票，得票數的多少後成為主機

  • 啟動哨兵：redis-sentinel /opt/myRedis/sentinel.conf

  • 當舊主機修復後重新啟動，此時哨兵監控到後會將該舊主機轉換為新主庫的從庫

• 一組sentinel能同時監控多個master

• 主從複製的缺點：由於寫操作都是先在Master進行，然後同步更新到slave上，所以主庫同步到從庫有一定延遲，Slave數量增加，延遲會更加嚴重

Java使用Redis

• 連線使用

	public static void main(String[] args) {
		Jedis jedis = new Jedis("127.0.0.1", 6379);
		jedis.set("k1", "v1");
		System.out.println(jedis.ping());
		Set<String> keys = jedis.keys("*");
	}

• 事務

	public static void main(String[] args) {
		Jedis jedis = new Jedis("127.0.0.1", 6379);
		Transaction transaction = jedis.multi();
		//transaction.discard(); // 事務取消
		transaction.exec();
	}

• 事務-watch監控-加鎖

public class TestTransaction {
 
  public boolean transMethod() {
     Jedis jedis = new Jedis("127.0.0.1", 6379);
     int balance;// 可用餘額
     int debt;// 欠額
     int amtToSubtract = 10;// 實刷額度
     jedis.watch("balance");// watch監控某個欄位
     //jedis.set("balance","5");//此句不該出現。模擬其他程式已經修改了該條目
     Thread.sleep(7000); // 延時7秒，模擬高併發或網路延遲，在7秒的過程中有其它程式改變了balance
     balance = Integer.parseInt(jedis.get("balance"));
     if (balance < amtToSubtract) {
       jedis.unwatch();
       System.out.println("modify");
       return false;
     } else {
       System.out.println("***********transaction");
       Transaction transaction = jedis.multi();
       transaction.decrBy("balance", amtToSubtract);
       transaction.incrBy("debt", amtToSubtract);
       transaction.exec();
       balance = Integer.parseInt(jedis.get("balance"));
       debt = Integer.parseInt(jedis.get("debt"));
 
       System.out.println("*******" + balance);
       System.out.println("*******" + debt);
       return true;
     }
  }
 
  /**
   * 通俗點講，watch命令就是標記一個鍵，如果標記了一個鍵， 在提交事務前如果該鍵被別人修改過，那事務就會失敗，這種情況通常可以在程式中
   * 重新再嘗試一次。
   * 首先標記了鍵balance，然後檢查餘額是否足夠，不足就取消標記，並不做扣減； 足夠的話，就啟動事務進行更新操作，
   * 如果在此期間鍵balance被其它人修改， 那在提交事務（執行exec）時就會報錯， 程式中通常可以捕獲這類錯誤再重新執行一次，直到成功。
   */
  public static void main(String[] args) {
     TestTransaction test = new TestTransaction();
     boolean retValue = test.transMethod();
     System.out.println("main retValue-------: " + retValue);
  }
}

• 主從複製（配從不配主）

public static void main(String[] args) throws InterruptedException 
  {
     Jedis jedis_M = new Jedis("127.0.0.1",6379);
     Jedis jedis_S = new Jedis("127.0.0.1",6380);
     
     jedis_S.slaveof("127.0.0.1",6379);
     
     jedis_M.set("k6","v6");
     Thread.sleep(500);
     System.out.println(jedis_S.get("k6"));
  }

JedisPool（最常用）

• JedisPoolUtil

public class JedisPoolUtil {
  private static volatile JedisPool jedisPool = null;//被volatile修飾的變數不會被本地執行緒快取，對該變數的讀寫都是直接操作共享記憶體。
  private JedisPoolUtil() {}  // 單例模式，構造方法私有化，無法new該例項物件
  
  public static JedisPool getJedisPoolInstance() // 對外提供獲得單例項JedisPool的方法
 {
     if(null == jedisPool)
    {
       synchronized (JedisPoolUtil.class) // 單例模式的雙重校驗鎖
      {
          if(null == jedisPool) 
         {
           JedisPoolConfig poolConfig = new JedisPoolConfig();
// pool可分配的jedis例項，pool.getResource()獲取；如果為-1，則表示不限制；如果pool已經分配了maxActive個jedis例項，則此時pool的狀態exhausted。
           poolConfig.setMaxActive(1000); 
           // 控制一個pool最多有多少個狀態為idle(空閒)的jedis例項；
           poolConfig.setMaxIdle(32);
           // 表示當borrow一個jedis例項時，最大的等待時間，如果超過等待時間，則直接拋JedisConnectionException；
           poolConfig.setMaxWait(100*1000);  
           // 獲得一個jedis例項的時候是否檢查連線可用性（ping()）；如果為true，則得到的jedis例項均是可用的；
           poolConfig.setTestOnBorrow(true); 
		   // 帶上配置連線redis
           jedisPool = new JedisPool(poolConfig,"127.0.0.1");
         }
      }
    }
     return jedisPool;
 }
  
  public static void release(JedisPool jedisPool,Jedis jedis)
 {
     if(null != jedis)
    {
      jedisPool.returnResourceObject(jedis);
    }
 }

快取問題

快取穿透

​ 快取穿透是指快取和資料庫中都沒有的資料，而使用者不斷髮起請求，如發起為id為“-1”的資料或id為特別大不存在的資料。這時的使用者很可能是攻擊者，攻擊會導致資料庫壓力過大。

解決方案：

1. 介面層增加校驗，如使用者鑑權校驗，id做基礎校驗，id<=0的直接攔截；
2. 從快取取不到的資料，在資料庫中也沒有取到，這時也可以將key-value對寫為key-null，快取有效時間可以設定短點，如30秒（設定太長會導致正常情況也沒法使用）。這樣可以防止攻擊使用者反覆用同一個id暴力攻擊

快取擊穿

​ 快取擊穿是指快取中沒有但資料庫中有的資料（一般是快取時間到期），這時由於併發使用者特別多，同時讀快取沒讀到資料，又同時去資料庫去取資料，引起資料庫壓力瞬間增大，造成過大壓力

解決方案：

1. 設定熱點資料永遠不過期。
2. 加互斥鎖，互斥鎖參考程式碼如下：

快取雪崩

​ 快取雪崩是指快取中資料大批量到過期時間，而查詢資料量巨大，引起資料庫壓力過大甚至down機。和快取擊穿不同的是，快取擊穿指併發查同一條資料，快取雪崩是不同資料都過期了，很多資料都查不到從而查資料庫。

解決方案：

1. 快取資料的過期時間設定隨機，防止同一時間大量資料過期現象發生。
2. 如果快取資料庫是分散式部署，將熱點資料均勻分佈在不同的快取資料庫中。
3. 設定熱點資料永遠不過期。

面試問題

熱點資料需要大批量更新，怎麼解決？

可以把這些熱點資料寫在一個記憶體的臨時表裡，因為innoDB會維護一個buffer pool，如果直接把大量資料全部讀進去，可能會造成flush操作（把髒頁刷會MySQL），從而造成線上業務的阻塞。

也可以使用Redis進行快取

如果熱點資料太猛，Redis可能因為頻寬被打滿，訪問不到，如何解決？

• 如果要快取的資料過多或者快取空間不夠，可以使用快取淘汰策略

• 也可以使用本地快取，在不考慮高併發情況下可以使用HashMap

  如果是在高併發情況下，可以使用ConcurrentHashMap 作為快取集合，再配合快取淘汰策略。

• 還可以使用guava cache元件實現本地快取，

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

Redis提供兩種持久化機制 RDB 和 AOF 機制:

1、RDBRedis DataBase)持久化方式：

是指用資料集快照的方式半持久化模式)記錄 redis 資料庫的所有鍵值對,在某個時間點將資料寫入一個臨時檔案，持久化結束後，用這個臨時檔案替換上次持久化的檔案，達到資料恢復。

優點：

（1）只有一個檔案 dump.rdb，方便持久化。

（2）容災性好，一個檔案可以儲存到安全的磁碟。

（3）效能最大化，fork 子程序來完成寫操作，讓主程序繼續處理命令，所以是 IO最大化。使用單獨子程序來進行持久化，主程序不會進行任何 IO 操作，保證了 redis的高效能)

（4）相對於資料集大時，比 AOF 的啟動效率更高。

缺點：

資料安全性低。RDB 是間隔一段時間進行持久化，如果持久化之間 redis 發生故障，會發生資料丟失。所以這種方式更適合資料要求不嚴謹的時候

2、AOFAppend-only file)持久化方式：

是指所有的命令列記錄以 redis 命令請求協議的格式完全持久化儲存)儲存為 aof 檔案。

優點：

（1）資料安全，aof 持久化可以配置 appendfsync 屬性，有 always，每進行一次命令操作就記錄到 aof 檔案中一次。

（2）通過 append 模式寫檔案，即使中途伺服器宕機，可以通過 redis-check-aof工具解決資料一致性問題。

（3）AOF 機制的 rewrite 模式。AOF 檔案沒被 rewrite 之前（檔案過大時會對命令進行合併重寫），可以刪除其中的某些命令（比如誤操作的 flushall）)

缺點：

（1）AOF 檔案比 RDB 檔案大，且恢復速度慢。

（2）資料集大的時候，比 rdb 啟動效率低。

Redis為什麼這麼快?

Redis採用的是基於記憶體的採用的是單程序單執行緒模型的 KV 資料庫，用”單執行緒-多路複用IO模型”來實現高效能的記憶體資料服務的，由C語言編寫，官方提供的資料是可以達到100000+的QPS（每秒內查詢次數）。這個資料不比採用單程序多執行緒的同樣基於記憶體的 KV 資料庫 Memcached 差

橫軸是連線數，縱軸是QPS。

1、完全基於記憶體，絕大部分請求是純粹的記憶體操作，非常快速。資料存在記憶體中，類似HashMap，HashMap的優勢就是查詢和操作的時間複雜度都是O(1)；

2、資料結構簡單，對資料操作也簡單，Redis中的資料結構是專門進行設計的；

3、採用單執行緒，避免了不必要的上下文切換和競爭條件，也避免了多執行緒之間的的切換而消耗 CPU，不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因為可能出現死鎖而導致的效能消耗；

4、使用多路I/O複用模型，非阻塞IO；

多路 I/O 複用模型;

多路I/O複用模型是利用 select、poll、epoll 可以同時監察多個流的 I/O 事件的能力，在空閒的時候，會把當前執行緒阻塞掉，當有一個或多個流有 I/O 事件時，就從阻塞態中喚醒，於是程式就會輪詢一遍所有的流（epoll 是隻輪詢那些真正發出了事件的流），並且只依次順序的處理就緒的流，這種做法就避免了大量的無用操作。

這裡“多路”指的是多個網路連線，“複用”指的是複用同一個執行緒。採用多路 I/O 複用技術可以讓單個執行緒高效的處理多個連線請求（儘量減少網路 IO 的時間消耗），且 Redis 在記憶體中操作資料的速度非常快，也就是說記憶體內的操作不會成為影響Redis效能的瓶頸。

5、底層實現方式以及與客戶端之間通訊的應用協議構建了VM 機制 ，因為一般的系統呼叫系統函式的話，會浪費一定的時間去移動和請求；

VM(virtual memory)機制：

Redis使用到了VM,在redis.conf設定vm-enabled yes 即開啟VM功能。 通過VM功能可以實現冷熱資料分離。使熱資料仍在記憶體中，冷資料儲存到磁碟。這樣就可以避免因為記憶體不足而造成訪問速度下降的問題。Redis並沒有使用OS提供的Swap，而是自己實現。

相比於OS的交換方式。redis可以將被交換到磁碟的物件進行壓縮,儲存到磁碟的物件可以去除指標和物件元資料資訊。一般壓縮後物件會比記憶體中物件小10倍。這樣redis的vm會比OS vm能少做很多io操作。OS交換的時候，是會阻塞執行緒的，而Redis可以設定讓工作執行緒來完成，主執行緒仍可以繼續接收client的請求。

當前VM的壞處： slow restart 重啟太慢 slow saving 儲存資料太慢 slow replication 上面兩條導致 replication 太慢 complex code 程式碼過於複雜

為什麼Redis是單執行緒？

因為Redis是基於記憶體的操作，CPU不是Redis的瓶頸，Redis的瓶頸最有可能是機器記憶體的大小或者網路頻寬。既然單執行緒容易實現，而且CPU不會成為瓶頸，那就順理成章地採用單執行緒的方案了，不採用多執行緒可以避免很多麻煩，如：避免了不必要的上下文切換和競爭條件，也避免了多執行緒之間的的切換而消耗 CPU，不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因為可能出現死鎖而導致的效能消耗；

用”單執行緒-多路複用IO模型”來實現高效能的記憶體資料服務的，這種機制避免了使用鎖，但是同時這種機制在進行sunion之類的比較耗時的命令時會使redis的併發下降。因為是單一執行緒，所以同一時刻只有一個操作在進行，所以，耗時的命令會導致併發的下降，不只是讀併發，寫併發也會下降。而單一執行緒也只能用到一個CPU核心，所以可以在同一個多核的伺服器中，可以啟動多個例項，組成master-master或者master-slave的主從複製形式，耗時的讀命令可以完全在slave進行。可以通過修改redis.conf 啟動多個例項

pidfile /var/run/redis/redis_6377.pid  #pidfile要加上埠號
port 6377  #這個是必須改的
logfile /var/log/redis/redis_6377.log #logfile的名稱也加上埠號
dbfilename dump_6377.rdb  #rdbfile也加上埠號

同時有多個子系統去set一個key。這個時候要注意什麼呢？ 不推薦使用redis的事務機制。因為我們的生產環境，基本都是redis叢集環境，做了資料分片操作。你一個事務中有涉及到多個key操作的時候，這多個key不一定都儲存在同一個redis-server上。因此，redis的事務機制，十分雞肋。
(1)如果對這個key操作，不要求順序： 準備一個分散式鎖，大家去搶鎖，搶到鎖就做set操作即可
(2)如果對這個key操作，要求順序： 分散式鎖+時間戳。 假設這會系統B先搶到鎖，將key1設定為{valueB 3:05}。接下來系統A搶到鎖，發現自己的valueA的時間戳早於快取中的時間戳，那就不做set操作了。以此類推。
(3) 利用佇列，將set方法變成序列訪問也可以redis遇到高併發，如果保證讀寫key的一致性
對redis的操作都是具有原子性的,是執行緒安全的操作,你不用考慮併發問題,redis內部已經幫你處理好併發的問題了。

注意點：

“我們不能任由作業系統負載均衡，因為我們自己更瞭解自己的程式，所以，我們可以手動地為其分配CPU核，而不會過多地佔用CPU，或是讓我們關鍵程序和一堆別的程序擠在一起。”。
CPU 是一個重要的影響因素，由於是單執行緒模型，Redis 更喜歡大快取快速 CPU， 而不是多核

在多核 CPU 伺服器上面，Redis 的效能還依賴NUMA 配置和處理器繫結位置。最明顯的影響是 redis-benchmark 會隨機使用CPU核心。為了獲得精準的結果，需要使用固定處理器工具（在 Linux 上可以使用 taskset）。最有效的辦法是將客戶端和服務端分離到兩個不同的 CPU 來高校使用三級快取。

Memcache與Redis的區別都有哪些？

1)、儲存方式 Memecache把資料全部存在記憶體之中，斷電後會掛掉，資料不能超過記憶體大小。 Redis有部份存在硬碟上，redis可以持久化其資料
2)、資料支援型別 memcached所有的值均是簡單的字串，redis作為其替代者，支援更為豐富的資料型別 ，提供list，set，zset，hash等資料結構的儲存
3)、使用底層模型不同 它們之間底層實現方式 以及與客戶端之間通訊的應用協議不一樣。 Redis直接自己構建了VM 機制 ，因為一般的系統呼叫系統函式的話，會浪費一定的時間去移動和請求。
4). value 值大小不同：Redis 最大可以達到 512M；memcache 只有 1mb。
5）redis的速度比memcached快很多
6）Redis支援資料的備份，即master-slave模式的資料備份。

redis的資料型別，以及每種資料型別的使用場景

回答：一共五種
(一)String
這個其實沒啥好說的，最常規的set/get操作，value可以是String也可以是數字。一般做一些複雜的計數功能的快取。
(二)hash
這裡value存放的是結構化的物件，比較方便的就是操作其中的某個欄位。博主在做單點登入的時候，就是用這種資料結構儲存使用者資訊，以cookieId作為key，設定30分鐘為快取過期時間，能很好的模擬出類似session的效果。
(三)list
使用List的資料結構，可以做簡單的訊息佇列的功能。另外還有一個就是，可以利用lrange命令，做基於redis的分頁功能，效能極佳，使用者體驗好。本人還用一個場景，很合適—取行情資訊。就也是個生產者和消費者的場景。LIST可以很好的完成排隊，先進先出的原則。
(四)set
因為set堆放的是一堆不重複值的集合。所以可以做全域性去重的功能。為什麼不用JVM自帶的Set進行去重？因為我們的系統一般都是叢集部署，使用JVM自帶的Set，比較麻煩，難道為了一個做一個全域性去重，再起一個公共服務，太麻煩了。
另外，就是利用交集、並集、差集等操作，可以計算共同喜好，全部的喜好，自己獨有的喜好等功能。
(五)sorted set（zset）
sorted set多了一個權重引數score,集合中的元素能夠按score進行排列。可以做排行榜應用，取TOP N操作。

Redis 內部結構

• dict：是一個用於維護key和value對映關係的資料結構，與很多語言中的Map或dictionary類似。 本質上是為了解決演算法中的查詢問題
• sds： 等同於char * 它可以儲存任意二進位制資料，不能像C語言字串那樣以字元’\0’來標識字串的結 束，因此它必然有個長度欄位。
• skiplist： （跳躍表） 跳錶是一種實現起來很簡單，單層多指標的連結串列，它查詢效率很高，堪比優化過的二叉平衡樹
• quicklist：採用雙向連結串列sdlist和壓縮表ziplist來實現快速列表quicklist的，其中sdlist充當map中控器的作用，ziplist充當佔用連續記憶體空間陣列的作用。quicklist本身是一個雙向無環連結串列，它的每一個節點都是一個ziplist。
• ziplist： 壓縮表 ziplist是一個編碼後的列表，是由一系列特殊編碼的連續記憶體塊組成的順序型資料結構，

redis的過期策略和配置以及記憶體淘汰機制

redis採用的是定期刪除+惰性刪除策略。
為什麼不用定時刪除策略?
定時刪除,用一個定時器來負責監視key,過期則自動刪除。雖然記憶體及時釋放，但是十分消耗CPU資源。在大併發請求下，CPU要將時間應用在處理請求，而不是刪除key,因此沒有采用這一策略.
定期刪除+惰性刪除是如何工作的呢?
定期刪除，redis預設每個100ms檢查，是否有過期的key,有過期key則刪除。需要說明的是，redis不是每個100ms將所有的key檢查一次，而是隨機抽取進行檢查(如果每隔100ms,全部key進行檢查，redis豈不是卡死)。因此，如果只採用定期刪除策略，會導致很多key到時間沒有刪除。
於是，惰性刪除派上用場。也就是說在你獲取某個key的時候，redis會檢查一下，這個key如果設定了過期時間判斷是否過期了？如果過期了此時就會刪除。
採用定期刪除+惰性刪除就沒其他問題了麼?
不是的，如果定期刪除沒刪除key。然後你也沒即時去請求key，也就是說惰性刪除也沒生效。這樣，redis的記憶體會越來越高。那麼就應該採用記憶體淘汰機制。
在redis.conf中有一行配置記憶體淘汰策略

maxmemory-policy volatile-lru

該配置就是配記憶體淘汰策略的（6種）
volatile-lru：最近最少使用，從已設定過期時間的資料集（server.db[i].expires）中挑選最近最少使用的資料淘汰
volatile-ttl：淘汰即將過期，從已設定過期時間的資料集（server.db[i].expires）中挑選將要過期的資料淘汰
volatile-random：隨機淘汰，從已設定過期時間的資料集（server.db[i].expires）中任意選擇資料淘汰
allkeys-lru：從資料集（server.db[i].dict）中挑選最近最少使用的資料淘汰
allkeys-random：從資料集（server.db[i].dict）中任意選擇資料淘汰
no-enviction（不淘汰）：禁止驅逐資料，新寫入操作會報錯
ps：如果沒有設定 expire 的key, 不滿足先決條件(prerequisites); 那麼 volatile-lru, volatile-random 和 volatile-ttl 策略的行為, 和 noeviction(不刪除) 基本上一致。

使用策略規則：

（1）如果資料呈現冪律分佈，也就是一部分資料訪問頻率高，一部分資料訪問頻率低，則使用 allkeys-lru

（2）如果資料呈現平等分佈，也就是所有的資料訪問頻率都相同，則使用allkeys-random

Redis 叢集方案應該怎麼做？都有哪些方案？

1.twemproxy，大概概念是，它類似於一個代理方式， 使用時在本需要連線 redis 的地方改為連線 twemproxy， 它會以一個代理的身份接收請求並使用一致性 hash 演算法，將請求轉接到具體 redis，將結果再返回 twemproxy。
缺點： twemproxy 自身單埠例項的壓力，使用一致性 hash 後，對 redis 節點數量改變時候的計算值的改變，資料無法自動移動到新的節點。

2.codis，目前用的最多的叢集方案，基本和 twemproxy 一致的效果，但它支援在 節點數量改變情況下，舊節點資料可恢復到新 hash 節點

3.redis cluster3.0 自帶的叢集，特點在於他的分散式演算法不是一致性 hash，而是 hash 槽的概念，以及自身支援節點設定從節點

有沒有嘗試進行多機redis 的部署？如何保證資料一致的？

主從複製，讀寫分離
一類是主資料庫（master）一類是從資料庫（slave），主資料庫可以進行讀寫操作，當發生寫操作的時候自動將資料同步到從資料庫，而從資料庫一般是隻讀的，並接收主資料庫同步過來的資料，一個主資料庫可以有多個從資料庫，而一個從資料庫只能有一個主資料庫。

對於大量的請求怎麼樣處理

redis是一個單執行緒程式，也就說同一時刻它只能處理一個客戶端請求；
對於大量請求，redis是通過IO多路複用（select，epoll, kqueue，依據不同的平臺，採取不同的實現）來處理多個客戶端請求的

Redis 常見效能問題和解決方案？

(1) Master 最好不要做任何持久化工作，如 RDB 記憶體快照和 AOF 日誌檔案
(2) 如果資料比較重要，某個 Slave 開啟 AOF 備份資料，策略設定為每秒同步一次
(3) 為了主從複製的速度和連線的穩定性， Master 和 Slave 最好在同一個區域網內
(4) 儘量避免在壓力很大的主庫上增加從庫
（5）主從複製不要用圖狀結構，用單向連結串列結構更為穩定，即：Master <- Slave1<- Slave2 <- Slave3…這樣的結構方便解決單點故障問題，實現 Slave 對 Master的替換。如果 Master 掛了，可以立刻啟用 Slave1 做 Master，其他不變。

Redis實現分散式鎖

Redis為單程序單執行緒模式，採用佇列模式將併發訪問變成序列訪問，且多客戶端對Redis的連線並不存在競爭關係Redis中可以使用SETNX命令實現分散式鎖。
將 key 的值設為 value ，當且僅當 key 不存在。 若給定的 key 已經存在，則 SETNX 不做任何動作

解鎖：使用 del key 命令就能釋放鎖
解決死鎖：
1）通過Redis中expire()給鎖設定最大持有時間，如果超過，則Redis來幫我們釋放鎖。
2） 使用 setnx key “當前系統時間+鎖持有的時間”和getset key “當前系統時間+鎖持有的時間”組合的命令就可以實現。

Redis事務

Redis事務功能是通過MULTI、EXEC、DISCARD和WATCH 四個原語實現的
Redis會將一個事務中的所有命令序列化，然後按順序執行。
1.redis 不支援回滾“Redis 在事務失敗時不進行回滾，而是繼續執行餘下的命令”， 所以 Redis 的內部可以保持簡單且快速。
2.如果在一個事務中的命令出現錯誤，那麼所有的命令都不會執行；
3.如果在一個事務中出現執行錯誤，那麼正確的命令會被執行。
注：redis的discard只是結束本次事務,正確命令造成的影響仍然存在.

1）MULTI命令用於開啟一個事務，它總是返回OK。 MULTI執行之後，客戶端可以繼續向伺服器傳送任意多條命令，這些命令不會立即被執行，而是被放到一個佇列中，當EXEC命令被呼叫時，所有佇列中的命令才會被執行。
2）EXEC：執行所有事務塊內的命令。返回事務塊內所有命令的返回值，按命令執行的先後順序排列。 當操作被打斷時，返回空值 nil 。
3）通過呼叫DISCARD，客戶端可以清空事務佇列，並放棄執行事務， 並且客戶端會從事務狀態中退出。
4）WATCH 命令可以為 Redis 事務提供 check-and-set （CAS）行為。 可以監控一個或多個鍵，一旦其中有一個鍵被修改（或刪除），之後的事務就不會執行，監控一直持續到EXEC命令。

為什麼Redis的操作是原子性的，怎麼保證原子性的？

對於Redis而言，命令的原子性指的是：一個操作的不可以再分，操作要麼執行，要麼不執行。
Redis的操作之所以是原子性的，是因為Redis是單執行緒的。
Redis本身提供的所有API都是原子操作，Redis中的事務其實是要保證批量操作的原子性。
多個命令在併發中也是原子性的嗎？
不一定， 將get和set改成單命令操作，incr 。使用Redis的事務，或者使用Redis+Lua==的方式實現.

講解下Redis執行緒模型

檔案事件處理器包括分別是套接字、 I/O 多路複用程式、 檔案事件分派器（dispatcher）、 以及事件處理器。使用 I/O 多路複用程式來同時監聽多個套接字， 並根據套接字目前執行的任務來為套接字關聯不同的事件處理器。當被監聽的套接字準備好執行連線應答（accept）、讀取（read）、寫入（write）、關閉（close）等操作時， 與操作相對應的檔案事件就會產生， 這時檔案事件處理器就會呼叫套接字之前關聯好的事件處理器來處理這些事件。
I/O 多路複用程式負責監聽多個套接字， 並向檔案事件分派器傳送那些產生了事件的套接字。
工作原理：
1)I/O 多路複用程式負責監聽多個套接字， 並向檔案事件分派器傳送那些產生了事件的套接字。
儘管多個檔案事件可能會併發地出現， 但 I/O 多路複用程式總是會將所有產生事件的套接字都入隊到一個佇列裡面， 然後通過這個佇列， 以有序（sequentially）、同步（synchronously）、每次一個套接字的方式向檔案事件分派器傳送套接字： 當上一個套接字產生的事件被處理完畢之後（該套接字為事件所關聯的事件處理器執行完畢）， I/O 多路複用程式才會繼續向檔案事件分派器傳送下一個套接字。如果一個套接字又可讀又可寫的話， 那麼伺服器將先讀套接字， 後寫套接字.

使用 Redis 有哪些好處？

（1）速度快，因為資料存在記憶體中，類似於 HashMap，HashMap 的優勢就是查詢和操作的時間複雜度都是 O1)

（2）支援豐富資料型別，支援 string，list，set，Zset，hash 等

（3）支援事務，操作都是原子性，所謂的原子性就是對資料的更改要麼全部執行，要麼全部不執行

（4）豐富的特性：可用於快取，訊息，按 key 設定過期時間，過期後將會自動刪除

Redis 相比 Memcached 有哪些優勢？

（1）Memcached 所有的值均是簡單的字串，redis 作為其替代者，支援更為豐富的資料類

（2）Redis 的速度比 Memcached 快很多

（3）Redis 可以持久化其資料

redis 過期鍵的刪除策略？

（1）定時刪除:在設定鍵的過期時間的同時，建立一個定時器 timer). 讓定時器在鍵的過期時間來臨時，立即執行對鍵的刪除操作。

（2）惰性刪除:放任鍵過期不管，但是每次從鍵空間中獲取鍵時，都檢查取得的鍵是否過期，如果過期的話，就刪除該鍵;如果沒有過期，就返回該鍵。

（3）定期刪除:每隔一段時間程式就對資料庫進行一次檢查，刪除裡面的過期鍵。至於要刪除多少過期鍵，以及要檢查多少個數據庫，則由演算法決定。

為什麼 edis 需要把所有資料放到記憶體中？

答 ：Redis 為了達到最快的讀寫速度將資料都讀到記憶體中，並通過非同步的方式將資料寫入磁碟。所以 redis 具有快速和資料持久化的特徵。如果不將資料放在記憶體中，磁碟 I/O 速度會嚴重影響 redis 的效能。如果設定了最大使用的記憶體，則資料已有記錄數達到記憶體限值後不能繼續插入新值。

Redis 的同步機制瞭解麼？

答：Redis 可以使用主從同步，從從同步。第一次同步時，主節點做一次 bgsave（另開子程序執行），並同時將後續修改操作記錄到記憶體 buffer，待完成後將 rdb 檔案全量同步到複製節點，複製節點接受完成後將 rdb 映象載入到記憶體。載入完成後，再通知主節點將期間修改的操作記錄同步到複製節點進行重放就完成了同步過程。

Pipeline 有什麼好處，為什麼要用 pipeline？

答：可以將多次 IO 往返的時間縮減為一次，前提是 pipeline 執行的指令之間沒有因果相關性。使用 redis-benchmark 進行壓測的時候可以發現影響 redis 的 QPS峰值的一個重要因素是 pipeline 批次指令的數目。

是否使用過 Redis 叢集，叢集的原理是什麼？

（1）Redis Sentinal 著眼於高可用，在 master 宕機時會自動將 slave 提升為master，繼續提供服務。

（2）Redis Cluster 著眼於擴充套件性，在單個 redis 記憶體不足時，使用 Cluster 進行分片儲存。

Redis 叢集方案什麼情況下會導致整個叢集不可用？

答：有 A，B，C 三個節點的叢集,在沒有複製模型的情況下,如果節點 B 失敗了，那麼整個叢集就會以為缺少 5501-11000 這個範圍的槽而不可用。

Redis 支援的 Java 客戶端都有哪些？官方推薦用哪個？

答：Redisson、Jedis、lettuce 等等，官方推薦使用 Redisson。

Jedis 是 Redis 的 Java 實現的客戶端，其 API 提供了比較全面的 Redis 命令的支援；Redisson 實現了分散式和可擴充套件的 Java 資料結構，和 Jedis 相比，功能較為簡單，不支援字串操作，不支援排序、事務、管道、分割槽等 Redis 特性。

Redisson 的宗旨是促進使用者對 Redis 的關注分離，從而讓使用者能夠將精力更集中地放在處理業務邏輯上。

說說 Redis 雜湊槽的概念？

答：Redis 叢集沒有使用一致性 hash,而是引入了雜湊槽的概念，Redis 叢集有16384 個雜湊槽，每個 key 通過 CRC16 校驗後對 16384 取模來決定放置哪個槽，叢集的每個節點負責一部分 hash 槽。

Redis 叢集的主從複製模型是怎樣的？

答：為了使在部分節點失敗或者大部分節點無法通訊的情況下叢集仍然可用，所以叢集使用了主從複製模型,每個節點都會有 N-1 個複製品.

Redis 叢集會有寫操作丟失嗎？為什麼？

答 ：Redis 並不能保證資料的強一致性，這意味這在實際中叢集在特定的條件下可能會丟失寫操作。

Redis 叢集之間是如何複製的？

答：非同步複製

Redis 叢集最大節點個數是多少？

答：16384 個桶(雜湊槽)。

Redis叢集沒有使用一致性hash,而是引入了雜湊槽的概念，當需要在 Redis 叢集中放置一個 key-value 時，根據 CRC16(key) mod 16384的值，決定將一個key放到哪個桶中。

Redis key 的過期時間和永久有效分別怎麼設定？

答：EXPIRE 和 PERSIST 命令。

Redis 如何做記憶體優化？

答：儘可能使用散列表（hashes），散列表（是說散列表裡面儲存的數少）使用的記憶體非常小，所以你應該儘可能的將你的資料模型抽象到一個散列表裡面。比如你的 web 系統中有一個使用者物件，不要為這個使用者的名稱，姓氏，郵箱，密碼設定單獨的 key,而是應該把這個使用者的所有資訊儲存到一張散列表裡面。

Redis 回收程序如何工作的？

答：一個客戶端運行了新的命令，添加了新的資料。Redi 檢查記憶體使用情況，如果大於 maxmemory 的限制, 則根據設定好的策略進行回收。一個新的命令被執行，等等。所以我們不斷地穿越記憶體限制的邊界，通過不斷達到邊界然後不斷地回收回到邊界以下。如果一個命令的結果導致大量記憶體被使用（例如很大的集合的交集儲存到一個新的鍵），不用多久記憶體限制就會被這個記憶體使用量超越。

都有哪些辦法可以降低 Redis 的記憶體使用情況呢？

答：如果你使用的是 32 位的 Redis 例項，可以好好利用 Hash,list,sorted set,set等集合型別資料，因為通常情況下很多小的 Key-Value 可以用更緊湊的方式存放到一起。

Redis 的記憶體用完了會發生什麼？

答：如果達到設定的上限，Redis 的寫命令會返回錯誤資訊（但是讀命令還可以正常返回。）或者你可以將 Redis 當快取來使用配置淘汰機制，當 Redis 達到記憶體上限時會沖刷掉舊的內容。

一個 Redis 例項最多能存放多少keys？List、Set、Sorted Set 最多能存放多少元素？

答：理論上 Redis 可以處理多達 232 的 keys，並且在實際中進行了測試，每個例項至少存放了 2 億 5 千萬的 keys。我們正在測試一些較大的值。任何 list、set、和 sorted set 都可以放 232 個元素。換句話說，Redis 的儲存極限是系統中的可用記憶體值。

MySQL 裡有2000w資料，redis 中只存 20w 的資料，如何保證 redis 中的資料都是熱點資料？

答：Redis 記憶體資料集大小上升到一定大小的時候，就會施行資料淘汰策略。

Redis 提供 6 種資料淘汰策略：

volatile-lru：從已設定過期時間的資料集（server.db[i].expires）中挑選最近最少使用的資料淘汰

volatile-ttl：從已設定過期時間的資料集（server.db[i].expires）中挑選將要過期的資料淘汰

volatile-random：從已設定過期時間的資料集（server.db[i].expires）中任意選擇資料淘汰

allkeys-lru：從資料集（server.db[i].dict）中挑選最近最少使用的資料淘汰

allkeys-random：從資料集（server.db[i].dict）中任意選擇資料淘汰

no-enviction（驅逐）：禁止驅逐資料

Redis 最適合的場景？

1、會話快取（Session Cache）

最常用的一種使用 Redis 的情景是會話快取（session cache）。用 Redis 快取會話比其他儲存（如 Memcached）的優勢在於：Redis 提供持久化。當維護一個不是嚴格要求一致性的快取時，如果使用者的購物車資訊全部丟失，大部分人都會不高興的，現在，他們還會這樣嗎？ 幸運的是，隨著 Redis 這些年的改進，很容易找到怎麼恰當的使用 Redis 來快取會話的文件。甚至廣為人知的商業平臺Magento 也提供 Redis 的外掛。

2、全頁快取（FPC）

除基本的會話 token 之外，Redis 還提供很簡便的 FPC 平臺。回到一致性問題，即使重啟了 Redis 例項，因為有磁碟的持久化，使用者也不會看到頁面載入速度的下降，這是一個極大改進，類似 PHP 本地 FPC。 再次以 Magento 為例，Magento提供一個外掛來使用 Redis 作為全頁快取後端。 此外，對 WordPress 的使用者來說，Pantheon 有一個非常好的外掛 wp-redis，這個外掛能幫助你以最快速度載入你曾瀏覽過的頁面。

3、佇列

Reids 在記憶體儲存引擎領域的一大優點是提供 list 和 set 操作，這使得 Redis能作為一個很好的訊息佇列平臺來使用。Redis 作為佇列使用的操作，就類似於本地程式語言（如 Python）對 list 的 push/pop 操作。 如果你快速的在 Google中搜索“Redis queues”，你馬上就能找到大量的開源專案，這些專案的目的就是利用 Redis 建立非常好的後端工具，以滿足各種佇列需求。例如，Celery 有一個後臺就是使用 Redis 作為 broker，你可以從這裡去檢視。

4，排行榜/計數器

Redis 在記憶體中對數字進行遞增或遞減的操作實現的非常好。集合（Set）和有序集合（Sorted Set）也使得我們在執行這些操作的時候變的非常簡單，Redis 只是正好提供了這兩種資料結構。所以，我們要從排序集合中獲取到排名最靠前的 10個使用者–我們稱之為“user_scores”，我們只需要像下面一樣執行即可： 當然，這是假定你是根據你使用者的分數做遞增的排序。如果你想返回使用者及使用者的分數，你需要這樣執行： ZRANGE user_scores 0 10 WITHSCORES Agora Games 就是一個很好的例子，用 Ruby 實現的，它的排行榜就是使用 Redis 來儲存資料的，你可以在這裡看到。

5、釋出/訂閱

最後（但肯定不是最不重要的）是 Redis 的釋出/訂閱功能。釋出/訂閱的使用場景確實非常多。我已看見人們在社交網路連線中使用，還可作為基於釋出/訂閱的指令碼觸發器，甚至用 Redis 的釋出/訂閱功能來建立聊天系統！

假如 Redis 裡面有 1 億個 key，其中有 10w 個 key 是以某個固定的已知的字首開頭的，如果將它們全部找出來？

答：使用 keys 指令可以掃出指定模式的 key 列表。

對方接著追問：如果這個 redis 正在給線上的業務提供服務，那使用 keys 指令會有什麼問題？

這個時候你要回答 redis 關鍵的一個特性：redis 的單執行緒的。keys 指令會導致執行緒阻塞一段時間，線上服務會停頓，直到指令執行完畢，服務才能恢復。這個時候可以使用 scan 指令，scan 指令可以無阻塞的提取出指定模式的 key 列表，但是會有一定的重複概率，在客戶端做一次去重就可以了，但是整體所花費的時間會比直接用 keys 指令長。

如果有大量的 key 需要設定同一時間過期，一般需要注意什麼？

答：如果大量的 key 過期時間設定的過於集中，到過期的那個時間點，redis 可能會出現短暫的卡頓現象。一般需要在時間上加一個隨機值，使得過期時間分散一些。

使用過 Redis 做非同步佇列麼，你是怎麼用的？

答：一般使用 list 結構作為佇列，rpush 生產訊息，lpop 消費訊息。當 lpop 沒有訊息的時候，要適當 sleep 一會再重試。如果對方追問可不可以不用 sleep 呢？list 還有個指令叫 blpop，在沒有訊息的時候，它會阻塞住直到訊息到來。如果對方追問能不能生產一次消費多次呢？使用 pub/sub 主題訂閱者模式，可以實現1:N 的訊息佇列。

如果對方追問 pub/sub 有什麼缺點？

在消費者下線的情況下，生產的訊息會丟失，得使用專業的訊息佇列如 RabbitMQ等。

如果對方追問 redis 如何實現延時佇列？

我估計現在你很想把面試官一棒打死如果你手上有一根棒球棍的話，怎麼問的這麼詳細。但是你很剋制，然後神態自若的回答道：使用 sortedset，拿時間戳作為score，訊息內容作為 key 呼叫 zadd 來生產訊息，消費者用 zrangebyscore 指令獲取 N 秒之前的資料輪詢進行處理。到這裡，面試官暗地裡已經對你豎起了大拇指。但是他不知道的是此刻你卻豎起了中指，在椅子背後。

使用過 Redis 分散式鎖麼，它是什麼回事？

先拿 setnx 來爭搶鎖，搶到之後，再用 expire 給鎖加一個過期時間防止鎖忘記了釋放。

這時候對方會告訴你說你回答得不錯，然後接著問如果在 setnx 之後執行 expire之前程序意外 crash 或者要重啟維護了，那會怎麼樣？這時候你要給予驚訝的反饋：唉，是喔，這個鎖就永遠得不到釋放了。緊接著你需要抓一抓自己得腦袋，故作思考片刻，好像接下來的結果是你主動思考出來的，然後回答：我記得 set 指令有非常複雜的引數，這個應該是可以同時把 setnx 和expire 合成一條指令來用的！對方這時會顯露笑容，心裡開始默唸：摁，這小子還不錯。

Redis回收程序如何工作的？

一個客戶端運行了新的命令，添加了新的資料。
Redi檢查記憶體使用情況，如果大於maxmemory的限制, 則根據設定好的策略進行回收。回收使用的演算法：LRU演算法

Redis常見效能問題和解決方案？

(1) Master最好不要做任何持久化工作，如RDB記憶體快照和AOF日誌檔案
(2) 如果資料比較重要，某個Slave開啟AOF備份資料，策略設定為每秒同步一次
(3) 為了主從複製的速度和連線的穩定性，Master和Slave最好在同一個區域網內
(4) 儘量避免在壓力很大的主庫上增加從庫
(5) 主從複製不要用圖狀結構，用單向連結串列結構更為穩定，即：Master <- Slave1 <- Slave2 <- Slave3...
這樣的結構方便解決單點故障問題，實現Slave對Master的替換。如果Master掛了，可以立刻啟用Slave1做Master，其他不變。

Redis資料分片模型

為了解決讀寫分離模型的缺陷，可以將資料分片模型應用進來。
可以將每個節點看成都是獨立的master，然後通過業務實現資料分片。
結合上面兩種模型，可以將每個master設計成由一個master和多個slave組成的模型。

Redis讀寫分離模型

通過增加Slave DB的數量，讀的效能可以線性增長。為了避免Master DB的單點故障，叢集一般都會採用兩臺Master DB做雙機熱備，所以整個叢集的讀和寫的可用性都非常高。

讀寫分離架構的缺陷在於，不管是Master還是Slave，每個節點都必須儲存完整的資料，如果在資料量很大的情況下，叢集的擴充套件能力還是受限於單個節點的儲存能力，而且對於Write-intensive型別的應用，讀寫分離架構並不適合。

Redis叢集方案應該怎麼做？都有哪些方案？

1.twemproxy
2.codis，目前用的最多的叢集方案，基本和twemproxy一致的效果，但它支援在 節點數量改變情況下，舊節點資料可恢復到新hash節點。
3.Redis cluster3.0自帶的集，特點在於他的分散式演算法不是一致性hash，而是hash槽的概念，以及自身支援節點設定從節點。

Redis單點吞吐量

單點TPS達到8萬/秒，QPS達到10萬/秒，補充下TPS和QPS的概念

1.QPS: 應用系統每秒鐘最大能接受的使用者訪問量
每秒鐘處理完請求的次數，注意這裡是處理完，具體是指發出請求到伺服器處理完成功返回結果。可以理解在server中有個counter，每處理一個請求加1，1秒後counter=QPS。
2.TPS： 每秒鐘最大能處理的請求數
每秒鐘處理完的事務次數，一個應用系統1s能完成多少事務處理，一個事務在分散式處理中，可能會對應多個請求，對於衡量單個介面服務的處理能力，用QPS比較合理。

Redis相比memcached有哪些優勢？

1.memcached所有的值均是簡單的字串，Redis作為其替代者，支援更為豐富的資料型別
2.Redis的速度比memcached快很多
3.Redis可以持久化其資料
4.Redis支援資料的備份，即master-slave模式的資料備份。