``>[info] Redis如何實現延時隊列 使用sortedset，使用時間戳做score, 消息內容作為key,調用zadd來生產消息，消費者使用zrangbyscore獲取n秒之前的數據做輪詢處理。 >[info] redis緩存擊穿是什么？如何解決？ 緩存擊穿是指緩存中沒有但數據庫中有的數據（一般是緩存時間到期），這時由于并發用戶特別多，同時讀緩存沒讀 到數據，又同時去數據庫去取數據，引起數據庫壓力瞬間增大，造成過大壓力。和緩存雪崩不同的是，緩存擊穿指并 發查同一條數據，緩存雪崩是不同數據都過期了，很多數據都查不到從而查數據庫。（本來所有請求應該訪問緩存，結果直接打到數據庫） ***** **解決方案：** 加鎖、隊列。 **解決方案：** 布隆過濾器，過濾空數據。如果數據返回為空，空結果緩存，再寫一個算法排重。采用布隆過濾器，將所有可能存在的數據哈希到一個足夠大的 bitmap 中，一個一定不存在的數據會被這個bitmap 攔截掉，從而避免了對底層存儲系統的查詢壓力。 **解決方案：** 設置熱點數據永遠不過期。 **解決方案：** 從緩存取不到的數據，在數據庫中也沒有取到，這時也可以將key-value對寫為key-null，緩存有效時間可以設置短點，如30秒（設置太長會導致正常情況也沒法使用）。這樣可以防止攻擊用戶反復用同一個id暴力攻擊。 ***** >[info] redis 的緩存預熱、緩存更新、緩存降級問題？ **緩存預熱：** 系統上線，將相關的緩存數據加載到緩存中，提前將數據放入緩存（而不是先去查數據庫，再放到緩存） **解決方案：** 手工、項目啟動時候直接加載、定時刷新緩存。 ***** **緩存更新：** 除了服務器自帶失效策略、常見策略：1. 定時清理過期的緩存（缺點：大量緩存key比較麻煩） 2. 先判斷緩存是否過期，如果過期那么就去底層重新加載得到新的數據并更新。（缺點：大量請求都要判斷 業務復雜） **緩存降級：** 訪問量劇增，服務出現問題，降級最終目的是保存核心服務可用。（加入購物車，結算不可降級） **解決方案：** 一般：網絡波動、超時，自動降級 **警告：** 有一些服務已經達到百分之90-95，自動降級 **錯誤：** 自動降級/人工降級 **嚴重錯誤：** 特殊原因，緊急的人工降級 >[info] redis 的事務管理（ACID） A 原子性（Atomicity）：事務是不可分割的 C 一致性（Consistency）：事務的前后數據完整性必須保存一致 I 隔離性（lsolation）：事務互相隔離，互不影響 D 持久性（Durability）：事務一旦被提交，它對數據庫中的數據改變是永久的，即使數據庫發生故障，也不會產生影響。 ***** >[info] Redis事務保證原子性嗎，支持回滾嗎 Redis中，單條命令是原子性執行的，但事務不保證原子性，且沒有回滾。事務中任意命令執行失敗，其余的命令可 以仍會被執行。 >[info] Redis事務支持隔離性嗎 Redis 是單進程程序，并且它保證在執行事務時，不會對事務進行中斷，事務可以運行直到執行完所有事務隊列中的 命令為止。因此，Redis 的事務是總是帶有隔離性的。 >[info] Redis的線程模型是咋樣的？ Redis基于 **Reactor模式** 開發了網絡事件處理器，這個處理器被稱為文件事件處理器（file event handler）。它的組 成結構為4部分：多個套接字、IO多路復用程序、文件事件分派器、事件處理器。因為文件事件分派器隊列的消費是 單線程的，所以Redis才叫單線程模型 * 文件事件處理器使用 I/O 多路復用（multiplexing）程序來同時監聽多個套接字， 并根據套接字目前執行的任 務來為套接字關聯不同的事件處理器。 * 當被監聽的套接字準備好執行連接應答（accept）、讀取（read）、寫入（write）、關閉（close）等操作 時， 與操作相對應的文件事件就會產生， 這時文件事件處理器就會調用套接字之前關聯好的事件處理器來處理 這些事件。 雖然文件事件處理器以單線程方式運行， 但**通過使用 I/O 多路復用程序來監聽多個套接字**， 文件事件處理器既實現 了高性能的網絡通信模型， 又可以很好地與 redis 服務器中其他同樣以單線程方式運行的模塊進行對接， 這保持了 Redis 內部單線程設計的簡單性。 >[info] Redis的內存淘汰策略有哪些 Redis的內存淘汰策略是指在Redis的用于緩存的內存不足時，怎么處理需要新寫入且需要申請額外空間的數據。 ***** 全局的鍵空間選擇性移除 * noeviction：當內存不足以容納新寫入數據時，新寫入操作會報錯。 * allkeys-lru：當內存不足以容納新寫入數據時，在鍵空間中，移除最近最少使用的key。（這個是最常用的） * allkeys-random：當內存不足以容納新寫入數據時，在鍵空間中，隨機移除某個key。 設置過期時間的鍵空間選擇性移除 * volatile-lru：當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，移除最近最少使用的key。 * volatile-random：當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，隨機移除某個key。 * volatile-ttl：當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，有更早過期時間的key優先移 除。 >[info] Redis的內存用完了會發生什么？ 如果達到設置的上限，Redis的寫命令會返回錯誤信息（但是讀命令還可以正常返回。）或者你可以配置內存淘汰機 制，當Redis達到內存上限時會沖刷掉舊的內容。 >[info] 請對比下redis持久化之RDB和AOF？ **RDB：** 快照 **AOF：** 追加 1. Redis 默認開啟RDB持久化方式，在指定的時間間隔內，執行指定次數的寫操作，則將內存中的數據寫入到磁盤中。 2. RDB 持久化適合大規模的數據恢復但它的數據一致性和完整性較差。 3. Redis 需要手動開啟AOF持久化方式，默認是每秒將寫操作日志追加到AOF文件中。 4. AOF 的數據完整性比RDB高，但記錄內容多了，會影響數據恢復的效率。 5. Redis 針對 AOF文件大的問題，提供重寫的瘦身機制。 6. 若只打算用Redis 做緩存，可以關閉持久化。 7. 若打算使用Redis 的持久化。建議RDB和AOF都開啟。其實RDB更適合做數據的備份，留一后手。AOF出問題了， 還有RDB。 >[info] 請說說對redis事務的理解？ **Redis事務的概念：** Redis 事務的本質是一組命令的集合。事務支持一次執行多個命令，一個事務中所有命令都會被序列化。在事務 執行過程，會按照順序串行化執行隊列中的命令，其他客戶端提交的命令請求不會插入到事務執行命令序列中。 ***** 總結說：redis事務就是一次性、順序性、排他性的執行一個隊列中的一系列命令。 ***** **Redis事務沒有隔離級別的概念：** ***** **Redis不保證原子性：** Redis中，單條命令是原子性執行的，但事務不保證原子性，且沒有回滾。事務中任意命令執行失敗，其余的命 令仍會被執行。 ***** **Redis事務的三個階段：** * 開始事務 * 命令入隊 * 執行事務 **Redis事務相關命令：** * watch key1 key2 ... : 監視一或多個key,如果在事務執行之前，被監視的key被其他命令改動，則事務被打斷 （ 類似樂觀鎖 ） * multi : 標記一個事務塊的開始（ queued ） * exec : 執行所有事務塊的命令 （ 一旦執行exec后，之前加的監控鎖都會被取消掉 ） * discard : 取消事務，放棄事務塊中的所有命令 * unwatch : 取消watch對所有key的監控 **總結：** watch指令類似于樂觀鎖，在事務提交時，如果watch監控的多個KEY中任何KEY的值已經被其他客戶端更改，則 使用EXEC執行事務時，事務隊列將不會被執行，同時返回Nullmulti-bulk應答以通知調用者事務執行失敗。 >[info] Redis有哪些優缺點 **優點:** 1. 讀寫性能優異。 2. 支持數據持久化，支持AOF和RDB兩種持久化方式。 3. 支持事務，Redis的所有操作都是原子性的，同時 Redis還支持對幾個操作合并后的原子性執行。 5. 數據結構豐富，除了支持string類型的value外還支持hash、set、zset、list 等數據結構 6. 支持主從復制，主機會自動將數據同步到從機，可以進行讀寫分離。 ***** **缺點:** 1. 數據庫容量受到物理內存的限制，不能用作海量數據的高性能讀寫，因此Redis適合的場景主要局限在較小數據 量的高性能操作和運算上。 2. Redis 不具備自動容錯和恢復功能，主機從機的宕機都會導致前端部分讀寫請求失敗，需要等待機器重啟或者手動切換前端的IP才能恢復。 3. 主機宕機，宕機前有部分數據未能及時同步到從機，切換IP后還會引入數據不一致的問題，降低了系統的可用性。 4. Redis 較難支持在線擴容，在集群容量達到上限時在線擴容會變得很復雜。為避免這一問題，運維人員在系統上線時必須確保有足夠的空間，這對資源造成了很大的浪費。 >[info] redis的list隊列先進先出如何解決插隊問題？ 通常使用一個list來實現隊列操作，這樣有一個小限制，所以的任務統一都是先進先出，如果想優先處理某個任務就 不太好處理了，這就需要讓隊列有優先級的概念，我們就可以優先處理高級別的任務，實現方式有以下幾種方式： 1.**單一列表實現：** 隊列正常的操作是 左進右出（lpush,rpop）為了先處理高優先級任務，在遇到高級別任務時，可以直接插隊，直接放入隊列頭部（rpush），這樣，從隊列頭部（右側）獲取任務時，取到的就是高優先級的任務 （rpop） 2. **使用兩個隊列**，一個普通隊列，一個高級隊列，針對任務的級別放入不同的隊列，獲取任務時也很簡單，redis的 BRPOP命令可以按順序從多個隊列中取值，BRPOP會按照給出的 key 順序查看，并在找到的第一個非空 list 的尾部 彈出一個元素，redis> BRPOP list1 list2 0 ***** list1 做為高優先級任務隊列 list2 做為普通任務隊列 這樣就實現了先處理高優先級任務，當沒有高優先級任務時，就去獲取普通任務 ***** 方式1最簡單，但實際應用比較局限，方式3可以實現復雜優先級，但實現比較復雜，不利于維護 方式2是推薦用法，實際應用最為合適 >[info] redis如何優化 1. 建立redis連接池 2. 建立redis集群和一主多從 3. 設置key有效期 4. 設置bit級別的存儲，如GETBIT 和 SETBIT 等 5. 想要一次添加多條數據的時候可以使用管道 6. 根據業務需要選擇合適的數據類型，并為不同的應用場景設置 相應的緊湊存儲參數。 7. 如果需要使用持久化，根據是否可以容忍重啟丟失部分數據在快照方式與語句追加方式之間選擇其一，不要使用 虛擬內存以及diskstore方式。 8. 不要讓你的Redis所在機器物理內存使用超過實際內存總量的3/5。 >[info] 使用redis你lpop一條數據后， 插入數據庫失敗怎么辦？ 一般使用list結構作為隊列，rpush生產消息，lpop消費消息。當lpop沒有消息的時候，要適當sleep一會再重試。 **缺點：** 在消費者下線的情況下，生產的消息會丟失，得使用專業的消息隊列如rabbitmq等。 >[info] redis支持哪幾種常見數據類型？ String字符串 Hash（哈希） List（列表） Set（集合） zset(sorted set：有序集合) >[info] 使用過Redis分布式鎖么，它是怎么實現的? 先拿setnx來爭搶鎖，搶到之后，再用expire給鎖加一個過期時間防止鎖忘記了釋放 ***** Redis為單進程單線程模式，采用隊列模式將并發訪問變成串行訪問，且多客戶端對Redis的連接并不存在競爭關系 Redis中可以使用SETNX命令實現分布式鎖。 ***** 當且僅當 key 不存在，將 key 的值設為 value。若給定的 key 已經存在，則 SETNX 不做任何動作 ***** SETNX 是『SET if Not eXists』(如果不存在，則 SET)的簡寫。 ***** 返回值：設置成功，返回 1 。設置失敗，返回 0 。  ***** 使用SETNX完成同步鎖的流程及事項如下： * 使用SETNX命令獲取鎖，若返回0（key已存在，鎖已存在）則獲取失敗，反之獲取成功 * 為了防止獲取鎖后程序出現異常，導致其他線程/進程調用SETNX命令總是返回0而進入死鎖狀態，需要為該key設置 一個“合理”的過期時間 * 釋放鎖，使用DEL命令將鎖數據刪除 >[info] redis 如何做內存優化？ **散列表：** 存儲的數少，使用內存非常小，盡可能將數據模型抽象到散列表里。 ``` 如用戶信息：郵箱、電話、QQ 都設置單獨的key，應該將該用戶數據存儲到散列表里。 ``` >[info] zookeeper 是什么？ 開放源碼的一個分布式協調服務器，集群管理者，監視著集群中各個節點的狀態，根據節點提交反饋合理做下一步操作，最終將我們簡單易用的接口和性能高效提供給用戶。 分布式應用：可以基于zookeeper 來實現 數據發布訂閱、負載均衡、命名服務、分布式協調和通知、集群管理、master 選舉、分布式鎖、分布式隊列。 保證了分布式一致性 >[info] redis 回收進程是如何工作的？ 他會檢查內存使用情況，如果大于設定閾值，那么根據設定號的策略進行回收，不斷的穿越設置邊界，通過不斷達到邊界，回收邊界以下的數據。 >[info] Redis與Memcached的2個主要區別 1. Redis不僅支持簡單的k/v類型的數據，同時還支持list、set、zset(sorted set)、hash等數據結構的存儲，使得 它擁有更廣闊的應用場景。 2. Redis最大的亮點是支持數據持久化，它在運行的時候可以將數據備份在磁盤中，斷電或重啟后，緩存數據可以 再次加載到內存中，只要Redis配置的合理，基本上不會丟失數據。 3. key字符串長度限制 >[info] redis 的哨兵 實現 redis 集群高可用 1. 集群監控：負責監控redis master 和 slave 進程是否正常工作 2. 消息通知：如果 redis 實例發生故障，那么哨兵就負責發送信息給管理員 3. 故障轉移：如果 master slave 發生故障就會自動轉移到 slave node上 4. 配置中心：如果故障發生了，就通知 client 客戶端產生新的 master 地址 >[info] 說說你對redis哨兵的理解 Redis服務器毫無征兆的罷工是個麻煩事，如何保證備份的機器是原始服務器的完整備份呢？這時候就需要哨兵和復制。 ***** Sentinel可以管理多個Redis服務器，它提供了監控，提醒以及自動的故障轉移的功能，Replication則是負責讓一個 Redis服務器可以配備多個備份的服務器。