1.Redis與Memorycache的區別？

• Redis使用單執行緒，而Memcached是多執行緒，

• Redis使用現場申請記憶體的方式來儲存資料，並且可以配置虛擬記憶體；Memcached使用預分配的記憶體池的方式。

• Redis實現了持久化和主從同步，容災性會更強。而Memcached只是存放在記憶體中，伺服器故障關機後資料就會消失，

• Redis支援五種資料型別：string,list, Hash,set及zset。而Memcached只是簡單的key與value

• Redis的優點：對資料高併發讀寫、對海量資料的高效率儲存和訪問、對資料的可擴充套件性和高可用性

• Redis的應用場景：取最新N個數據的操作、排行榜應用取TOP N操作、需要精準設定過期時間的應用、計數器應用、獲取某段時間所有資料排重值的唯一性操作、實時訊息系統、構建佇列系統、作快取。

2.Redis的五種資料結構？

• redisObject包含type、encoding、refcount、lru 、*ptr

注：embstr編碼建立字串物件只需記憶體分配一次，呼叫一次記憶體釋放函式，而raw都需要兩次。可使用INCR和INCRBY生成分散式系統唯一序列號ID

• 雙向連結串列便於在表的兩端操作，但是它的記憶體地址不連續，容易產生記憶體碎片。ziplist是一整塊連續記憶體，儲存效率很高。但它每次資料變動都會引發一次記憶體的realloc。所以quicklist結合了雙向連結串列和ziplist的優點，是一個雙向無環連結串列，它的每一個節點都是一個ziplist。

3.漸進式rehash過程？

• rehash的步驟 
  

• 為字典的ht[1]雜湊表分配空間

  • 若是擴充套件操作，那麼ht[1]的大小為>=ht[0].used*2的2^n
  • 若是收縮操作，那麼ht[1]的大小為>=ht[0].used的2^n

• 將儲存在ht[0]中的所有鍵值對rehash到ht[1]中，rehash指重新計算鍵的雜湊值和索引值，新hash通過hashFunction(key)函式獲取， 新的索引值：index=hash&sizemask，然後將鍵值對放置到ht[1]雜湊表的指定位置上。

• 當ht[0]的所有鍵值對都遷移到了ht[1]之後（ht[0]變為空表），釋放ht[0]，將ht[1]設定為ht[0],新建空白的雜湊表ht[1]，以備下次rehash使用。

• 擴充套件與收縮的條件

  • 伺服器目前沒有執行bgsave或bgrewriteaof命令，並且雜湊表的負載因子>=1或正在執行負載因子>=5就會進行rehash操作
  • 當負載因子的值小於0.1時，程式就會對雜湊表進行收縮操作
  • 負載因子=ht[0].used/ht[0].size

• 漸進式rehash：若雜湊表中儲存著數量巨大的鍵值對，一次進行rehash，很有可能會導致伺服器宕機。所以要分多次、漸進式的完成。採取分為而治的方式，將rehash鍵值對的計算均攤到每個字典增刪改查操作，避免了集中式rehash的龐大計算量。

• 主要是維持索引計數器變數rehashidx，每次對字典執行增刪改查時將rehashidx值+1，當ht[0]的所有鍵值對都被rehash到ht[1]中，程式將rehashidx的值設定為-1，表示rehash操作完成

4.rehash原始碼？

• Redis為了兼顧效能的考慮，分為lazy rehashing：在每次對dict進行操作的時候執行一個slot的rehash。active rehashing：每100ms裡面使用1ms時間進行rehash。（serverCron函式），而字典有安全迭代器的情況下不能進行 rehash

• 字典hash（lazy rehashing）函式呼叫：_dictRehashStep–> dictRehash

  • 在_dictRehashStep函式中，會呼叫dictRehash方法，而_dictRehashStep每次僅會rehash一個值從ht[0]到 ht[1]，但由於_dictRehashStep是被dictGetRandomKey、dictFind、 dictGenericDelete、dictAdd呼叫的，因此在每次dict增刪查改時都會被呼叫，這無疑就加快了rehash過程。
  • 在dictRehash函式中每次增量rehash n個元素，由於在自動調整大小時已設定好了ht[1]的大小，因此rehash的主要過程就是遍歷ht[0]，取得key，然後將該key按ht[1]的 桶的大小重新rehash，並在rehash完後將ht[0]指向ht[1],然後將ht[1]清空。在這個過程中rehashidx非常重要，它表示上次rehash時在ht[0]的下標位置。

• 一般情況伺服器在對資料庫執行讀取/寫入命令時會對資料庫進行漸進式 rehash ，但如果伺服器長期沒有執行命令的話，資料庫字典的 rehash 就可能一直沒辦法完成，為了防止出現這種情況，我們需要對資料庫執行主動 rehash 。

• active rehashing函式呼叫的過程如下： 
  serverCron->databasesCron–>incrementallyRehash->dictRehashMilliseconds->dictRehash，其中incrementallyRehash的時間較長，rehash的個數也比較多。這裡每次執行 1 millisecond rehash 操作；如果未完成 rehash，會在下一個 loop 裡面繼續執行。

5.持久化機制

• RBD是預設方式，將記憶體中資料以快照的方式寫入到二進位制檔案中，預設檔名為dump.rdb

• 觸發rdbSave過程的方式

  • save命令：阻塞Redis伺服器程序，直到RDB檔案建立完畢為止。
  • bgsave命令：派生出一個子程序，然後由子程序負責建立RDB檔案，父程序繼續處理命令請求。
  • master接收到slave發來的sync命令
  • 定時save(配置檔案：900 1或300 10 或 60 10000）

• 命令bgsave與bgrewriteaof不能同時執行，若bgsave正在執行，則bgrewriteaof延遲到bgsave執行完再執行。若bgrewriteaof正在執行，則伺服器拒絕執行bgsave命令。dirty計數器：記錄距離上一次save/bgsave命令之後，伺服器對資料庫狀態修改了多少次

• RDB檔案結構：REDIS佔5個位元組，檢查檔案是否是RDB檔案；db_version長度為4個位元組，一個字串表示的整數，記錄了RDB檔案的版本號；database包含零個或任意多個數據庫；EOF：1個位元組，標誌著RDB檔案正文內容的結束；check_sum：8位元組，儲存校驗和，由前面四部分計算得出的。

• database結構：SELECTDB：1位元組，表示要讀一個數據庫號碼；db_number儲存著一個數據庫號碼；key_value_pairs 儲存了資料庫中的所有鍵值對資料，由TYPE、key、value組成

• RDB的優缺點，優點：一個緊湊的檔案，適合大規模的資料恢復，對資料完整性和一致性要求不高，恢復速度快。缺點：若Redis出現宕機，就會丟失最後一次快照後的所有修改。fork時，在資料大時較耗時，不能響應毫秒級請求。

• AOF：通過儲存redis伺服器所執行的寫命令來記錄資料庫狀態。

• AOF的優缺點，優點預設策略為每秒鐘 fsync 一次，最多丟失一秒的資料，缺點：aof檔案要遠大於rdb檔案，恢復速度慢於rdb，執行效率低。AOF提供更新的資料，而RDB提供更快的恢復速度

• AOF的修復：如果aof檔案被破壞， 程式redis-check-aof–fix會進行修復（在flushAppendOnlyFile函式中），若出現斷電等情況，就將寫出錯的情況記錄到日誌裡，之後會處理錯誤。重啟redis然後重新載入，AOF優先，它儲存的資料集要比RDB完整.

• AOF寫入的步驟：命令追加：將命令追加到AOF緩衝區，檔案寫入，檔案同步

• AOF重寫觸發機制： 預設配置是當AOF檔案大小是上次rewrite後大小的一倍且檔案大於64M時並且沒有子程序執行時觸發。

• AOF重寫的實現原理 ：fork出一條新程序來將檔案重寫(先寫入臨時檔案最後再rename)，遍歷新程序資料庫的記憶體資料，將整個記憶體中的資料庫內容用命令的方式重寫了一個新的aof檔案

• AOF後臺重寫：AOF重寫程式放到子程序中執行，當Redis執行完一個命令後，它會同時將這個寫命令傳送給AOF緩衝區和AOF重寫緩衝區，最後再寫入臨時檔案中。

• 虛擬記憶體：暫時把不經常訪問的資料從記憶體交換到磁碟中，從而提高資料庫容量，但程式碼複雜，重啟慢，複製慢等等，目前已被放棄

• 持久化的優化：拋棄AOF重寫機制 ，儲存RDB+AOF；Pika：適合資料大於50G且重要，多執行緒，持久化SSD

6.reaof原始碼？

• 對於快取塊的大小，因為程式需要不斷對這個快取執行 append 操作，而分配一個非常大的空間並不總是可能的，也可能產生大量的複製工作， 所以這裡使用多個大小為 AOF_RW_BUF_BLOCK_SIZE 的空間來儲存命令。預設每個快取塊的大小是10MB

• 如果客戶端有命令執行，然後feedAppendOnlyFile函式判斷是否開啟了AOF標識，若開啟，則將命令放入aof_buf_blocks中，繼續判斷是否有子程序在執行，若有，則說明正在進行reaof，就將命令放入aof_rewrite_buf_blocks中。

• 伺服器開啟就是迴圈檔案事件和時間事件的過程，而時間事件是通過ServerCron()函式執行的。該函式會100ms執行一次檢視是否有reaof或需要重新整理事件。

• 若有重新整理事件（預設每秒），呼叫flushAppendOnlyFile函式將aof_buf_blocks寫入磁碟中，若有reaof事件，呼叫rewriteAppendOnlyFileBackground()函式，它執行 fork() ，呼叫rewriteAppendOnlyFile函式子程序，在tmpfile中對 AOF 檔案進行重寫，完成後子程序結束，通知父程序。

• 父程序會捕捉子程序的退出訊號，如果子程序的退出狀態是 OK ，那麼父程序呼叫backgroundRewriteDoneHandler函式將aof_rewrite_buf_blocks追加到臨時檔案，然後使用 rename(2) 對臨時檔案改名，用它代替舊的 AOF 檔案，但它呼叫的 write 操作會阻塞主程序。

• 到現在，後臺 AOF 重寫已經全部完成了。

7.事務與事件

• 事務的錯誤處理：語法錯誤（入隊錯誤）不會執行，而執行錯誤（執行錯誤）其它命令仍然執行。multi會開啟事務，exec命令會取消對所有鍵的監控，還可以用unwatch命令來取消監控，而取消事務的命令為 Discard

• watch命令可以監控一個或者多個鍵，一旦有一個鍵被修改或刪除，之後的事務就不會執行。其中exec / discard / unwatch命令會清除連線中的所有監視。通過watched_keys字典，可以知道哪些資料庫鍵在被監視，若被監視的鍵被修改，則REDIS_DIRTY_CAS標識被開啟，Redis中使用watch實現CAS演算法。

• 檔案事件處理器由套接字、I/O多路複用程式、檔案事件分派器、事件處理器組成。時間事件分為定時事件和週期事件，serverCron函式，定期對自身的資源和狀態進行檢查。

• 客戶端的關閉，硬性限制：若輸出緩衝區的大小超過了硬性限制所設定的大小，就立即關閉客戶端，軟性限制：若輸出緩衝區的大小超過了軟性緩衝區的大小，但沒超過硬性限制，則會記錄客戶端到達軟性限制的起始時間，若持續時間伺服器設定的時長，則關閉客戶端。

• 偽客戶端：建立Lua指令碼的偽客戶端：在伺服器初始化時建立，一直持續到伺服器關閉。載入AOF檔案時使用的偽客戶端：在載入時建立，載入完成後關閉。

• 命令請求從傳送到完成的步驟：客戶端將命令請求傳送給伺服器、伺服器讀取命令請求，並分析命令引數、命令執行器根據引數查詢命令的實現函式setCommand，執行實現函式得到回覆

• serverCron函式預設每隔100毫秒執行一次，它的功能如下：更新伺服器時間快取、更新LRU時鐘、更新伺服器每秒執行命令次數、更新伺服器記憶體峰值記錄、處理客戶端資源、管理資料庫資源、執行被延遲的bgrewriteaof、檢查持久化操作的執行狀態、將AOF緩衝區中的內容寫入AOF檔案、關閉非同步客戶端、增加cronloops計數器的值

8.主從複製

• 通過執行slaveof命令或設定slaveof選項，讓一個伺服器去複製另一個伺服器。允許多個slave server擁有和mater server相同的資料庫副本

• 舊版複製功能（2.8之前）：同步（SYNC）和命令傳播。缺點：斷線後複製的效率低。

• 新版複製功能：完整重同步：用於初次複製，和SYNC一樣，讓主伺服器建立併發送RDB檔案，向從伺服器傳送儲存在緩衝區中的寫命令。部分重同步（PSYNC）：用於斷線後重複製，重連後，主伺服器將斷開期間執行的寫命令傳送給從伺服器。

• 部分重同步功能由主從伺服器的複製偏移量、主伺服器的積壓緩衝區和伺服器的執行ID組成

  • 複製偏移量：主從伺服器每次傳播N個位元組的資料，就把自己的複製偏移量加N
  • 複製積壓緩衝區是由主伺服器維護的一個固定長度的先進先出佇列，預設大小為1MB，當從伺服器斷開重連時，從伺服器通過PSYNC命令將自己的複製偏移量offset傳送給主伺服器，若offset之後的資料在積壓緩衝區中，就進行部分重同步的操作，否則進行完整重同步。
  • 伺服器執行ID：在啟動時由40個隨機的十六進位制字元生成，斷開重連時，從伺服器將自己的執行ID傳送給主伺服器，若主從伺服器的執行ID相同，則進行部分重同步操作，否則進行完整重同步操作。

• 複製的實現：設定主伺服器的地址和埠、建立套接字連線、傳送ping命令、身份驗證（可選）、傳送埠資訊、同步、命令傳播。

• 心跳檢測：在命令傳播階段，從伺服器會預設以每秒一次的頻率向主伺服器傳送replconf ack < replication_offset>命令，作用是檢測主從伺服器的網路連線狀態；輔助實現min-slaves-to-write和min-slaves-max-log選項；檢測命令丟失，通過對比主從伺服器的複製偏移量知道命令是否丟失。

• 主從複製的特點：一個master 可以擁有多個slave；多個slave可以連線到同一個master，還可以連線到其它slave；主從複製不會阻塞master，在同步資料時，master還可以繼續處理client請求；提高系統的伸縮性。

• 哨兵是Redis高可用性的解決方案，由一個或多個sentinel例項組成的哨兵系統可以監視任意多個主伺服器。

• 啟動哨兵後，會建立連向主伺服器的網路連線，命令連線指專門用於向主伺服器傳送命令，並接受命令回覆，而訂閱連線指專門用於訂閱主伺服器的sentinel:hello頻道

• 獲取伺服器資訊：和主資料庫建立連線後，哨兵會定時執行操作：每10秒哨兵會向主資料庫和從資料庫傳送info命令、每2秒哨兵會向主資料庫和從資料庫的sentinel:hello 頻道傳送自己的資訊、每秒哨兵會向主資料庫和從資料庫和其他哨兵節點發送ping命令

• 選舉領頭Sentinel：如果主資料庫斷開連線，則會選舉領頭的哨兵節點對主從系統發起故障恢復。選舉過程使用raft 演算法。選舉規則：刪除下線或中斷的伺服器，儘量選舉從伺服器優先順序高的、複製偏移量大的、執行ＩＤ小的。

9.啟動過程

• 初始化伺服器狀態結構，由initServerConfig函式完成，設定伺服器的執行ID、預設執行頻率、預設檔案配置路徑、執行架構、預設埠號、預設RDB持久化條件和AOF持久化條件、初始化伺服器的LRU時鐘、建立命令表

• 載入配置選項：指定配置引數或檔案

• 初始化伺服器資料結構： 在第一步時initServerConfig函式只是建立了命令表，而伺服器狀態還包含其他資料結構，如server.clients連結串列，server.db陣列，server.pubsub_channels字典，server.lua環境，server.log慢查詢日誌。該函式會為以上資料結構分配記憶體，之後，initServer函式負責初始化資料結構，為伺服器設定程序訊號處理器、建立共享物件、開啟伺服器的監聽埠、為serverCron函式建立時間事件、若存在AOF檔案，開啟AOF檔案，若沒有，就建立一個新的AOF檔案、初始化伺服器的後臺I/O模組（bio），到這就出現了“麵包”圖

• 還原資料庫狀態：若伺服器啟用了AOF持久化功能，那麼就用AOF檔案還原資料庫狀態，否則使用RDB檔案來還原資料庫狀態

• 執行伺服器的事件迴圈

10.叢集

• Redis叢集是redis提供的分散式資料庫方案，叢集通過分片來進行資料共享，並提供複製和故障轉移功能。由多個節點組成，通過握手（cluster meet命令）新增節點

• Redis叢集通過分片的方式儲存資料庫中的鍵值對，叢集中的整個資料庫被分為16384個槽（slot），每個節點可以處理0-16384個槽，當每個槽都有節點在處理時，叢集就處於上線狀態，命令cluster addslots < slot>可以將一個或多個槽指派給節點負責，slot屬性是一個二進位制陣列，若slots[i]=1，表示節點負責處理槽i，若slots[i]=0,則表示節點不負責處理槽i

• 節點儲存鍵值的步驟 ：先計算鍵屬於哪個槽、判斷槽是否由當前節點負責處理、若不是則返回moved錯誤（該錯誤被隱藏，但在單機模式下會列印錯誤），根據錯誤資訊轉向正確的節點，而節點資料庫的實現只能使用0號庫

• 重新分片：將任意數量已經指派給某個節點（源節點）的槽改為指派給另一個節點（目標節點），並且相關槽所屬的鍵值對也會從源節點被移動到目標節點。可線上操作。ASK錯誤是在節點遷移的過程中，被遷移槽的一部分鍵值對儲存在源節點，而另一部分儲存在目的節點。

• 叢集的訊息有五種，訊息由訊息頭和訊息正文組成。

  • meet訊息：表示接收到伺服器傳送的cluster meet命令
  • ping訊息：對五個節點中最長時間沒有傳送過ping訊息的節點發送ping訊息，以檢測是否線上
  • pong訊息：接收到meet或ping訊息
  • fail訊息：當A節點判斷B節點進入fail狀態，A節點就會向叢集廣播一條關於節點B的fail訊息
  • publish訊息：當節點接收到publish命令時，向叢集廣播一條publish訊息

• 叢集的優點，容錯性：解決在單服redis的單點問題。擴充套件性：叢集能夠很好的實現快取的效能升級，如多節點的熱部署。效能提升 ：在擴充套件過程中體現。

• 釋出與訂閱：所有頻道的訂閱關係儲存在伺服器狀態的pubsub_channel字典裡，該字典的鍵是某個被訂閱的頻道，值是一個連結串列，記錄了所有訂閱這個連結串列的客戶端。

• 將訊息傳送給頻道訂閱者 ：若客戶端執行publish命令，那將在字典中查詢該頻道，並通過遍歷連結串列將訊息傳送給該頻道的所有訂閱者。命令pubsub channels/numsub/numpat

11.Redis的6種資料淘汰策略

• volatile-lru：利用LRU演算法移除設定過過期時間的key。
• volatile-random：隨機移除設定過過期時間的key。
• volatile-ttl：移除即將過期的key，根據最近過期時間來刪除（輔以TTL）
• allkeys-lru：利用LRU演算法移除任何key。
• allkeys-random：隨機移除任何key。

• noeviction：不移除任何key，只是返回一個寫錯誤。

• 監視器：執行monitor命令，客戶端就可以將自己變成一個監視器，實時的接收並打印出伺服器當前處理的命令請求的相關資訊。伺服器將所有的監視器都記錄在monitors連結串列中。每次處理命令請求時，伺服器都會遍歷monitors連結串列，將相關資訊傳送給監視器。

• 慢查詢日誌功能用於記錄執行時間超過給定時長的命令請求。以先進先出的形式儲存在slowlog連結串列，引數：slowlog-log-slower-than和slowlog-max-len，

12.redis的併發競爭問題？

• 客戶端：進行連線池化、讀寫加鎖；服務端：使用setnx命令實現分散式鎖。

• 快取穿透：訪問不存在的物件，解決方法：快取空物件或布隆過濾器

• 快取雪崩：快取層不可用，導致儲存層呼叫量暴增，甚至掛掉。解決方法：保證快取層的高可用性、依賴隔離元件為後端限流並降級、

• 快取熱點key重建優化，

  • 若有一個熱點key，併發量巨大，不能再短時間重建快取，在快取失效的瞬間，大量執行緒重建快取，造成後端負載過大，甚至讓應用崩潰
  • 解決目標：減少重建快取的次數、資料儘可能一致、較少的潛在危險、
  • 解決方法：互斥鎖：只允許一個執行緒重建快取，其他執行緒等待（setnx）；永不過期：對key沒有設定過期時間，為每個value設定一個邏輯過期時間，若超時，則使用單獨的執行緒去構建快取。

• 配置檔案：daemonize yes 後臺執行；pidfile /var/redis-server.pid 程序檔案；

• Jedis的使用

  • 連線redis的IP和埠號 Jedis jedis = new Jedis(“127.0.0.1”,6379);
  • 執行事務：Transaction transaction=jedis.multi();