主頁 > 後端開發 > 吃透Redis面試八股文

吃透Redis面試八股文

2023-06-01 07:38:56 後端開發

內容摘自我的學習網站：topjavaer.cn

Redis連環40問，絕對夠全！

Redis是什么？

Redis（Remote Dictionary Server）是一個使用 C 語言撰寫的，高性能非關系型的鍵值對資料庫，與傳統資料庫不同的是，Redis 的資料是存在記憶體中的，所以讀寫速度非常快，被廣泛應用于快取方向，Redis可以將資料寫入磁盤中，保證了資料的安全不丟失，而且Redis的操作是原子性的，

Redis優缺點？

優點：

  1. 基于記憶體操作，記憶體讀寫速度快，
  2. 支持多種資料型別，包括String、Hash、List、Set、ZSet等，
  3. 支持持久化，Redis支持RDB和AOF兩種持久化機制，持久化功能可以有效地避免資料丟失問題，
  4. 支持事務，Redis的所有操作都是原子性的，同時Redis還支持對幾個操作合并后的原子性執行，
  5. 支持主從復制，主節點會自動將資料同步到從節點，可以進行讀寫分離，
  6. Redis命令的處理是單執行緒的，Redis6.0引入了多執行緒，需要注意的是，多執行緒用于處理網路資料的讀寫和協議決議，Redis命令執行還是單執行緒的，

缺點：

  1. 對結構化查詢的支持比較差，
  2. 資料庫容量受到物理記憶體的限制，不適合用作海量資料的高性能讀寫，因此Redis適合的場景主要局限在較小資料量的操作，
  3. Redis 較難支持在線擴容，在集群容量達到上限時在線擴容會變得很復雜，

Redis為什么這么快？

  • 基于記憶體：Redis是使用記憶體存盤，沒有磁盤IO上的開銷，資料存在記憶體中，讀寫速度快，
  • IO多路復用模型：Redis 采用 IO 多路復用技術，Redis 使用單執行緒來輪詢描述符，將資料庫的操作都轉換成了事件，不在網路I/O上浪費過多的時間，
  • 高效的資料結構：Redis 每種資料型別底層都做了優化，目的就是為了追求更快的速度，

本文已經收錄到Github倉庫，該倉庫包含計算機基礎、Java基礎、多執行緒、JVM、資料庫、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服務、設計模式、架構、校招社招分享等核心知識點，歡迎star~

Github地址

如果訪問不了Github，可以訪問gitee地址，

gitee地址

既然Redis那么快，為什么不用它做主資料庫，只用它做快取？

雖然Redis非常快，但它也有一些局限性，不能完全替代主資料庫，有以下原因：

事務處理：Redis只支持簡單的事務處理，對于復雜的事務無能為力，比如跨多個鍵的事務處理，

資料持久化：Redis是記憶體資料庫，資料存盤在記憶體中，如果服務器崩潰或斷電，資料可能丟失，雖然Redis提供了資料持久化機制，但有一些限制，

資料處理：Redis只支持一些簡單的資料結構，比如字串、串列、哈希表等，如果需要處理復雜的資料結構，比如關系型資料庫中的表，那么Redis可能不是一個好的選擇，

資料安全：Redis沒有提供像主資料庫那樣的安全機制，比如用戶認證、訪問控制等等，

因此，雖然Redis非常快，但它還有一些限制，不能完全替代主資料庫，所以，使用Redis作為快取是一種很好的方式，可以提高應用程式的性能，并減少資料庫的負載，

講講Redis的執行緒模型？

Redis基于Reactor模式開發了網路事件處理器，這個處理器被稱為檔案事件處理器，它的組成結構為4部分：多個套接字、IO多路復用程式、檔案事件分派器、事件處理器，因為檔案事件分派器佇列的消費是單執行緒的，所以Redis才叫單執行緒模型，

  • 檔案事件處理器使用I/O多路復用（multiplexing）程式來同時監聽多個套接字， 并根據套接字目前執行的任務來為套接字關聯不同的事件處理器，
  • 當被監聽的套接字準備好執行連接accept、read、write、close等操作時， 與操作相對應的檔案事件就會產生， 這時檔案事件處理器就會呼叫套接字之前關聯好的事件處理器來處理這些事件，

雖然檔案事件處理器以單執行緒方式運行， 但通過使用 I/O 多路復用程式來監聽多個套接字， 檔案事件處理器既實作了高性能的網路通信模型， 又可以很好地與 redis 服務器中其他同樣以單執行緒方式運行的模塊進行對接， 這保持了 Redis 內部單執行緒設計的簡單性，

Redis應用場景有哪些？

  1. 快取熱點資料，緩解資料庫的壓力，
  2. 利用 Redis 原子性的自增操作，可以實作計數器的功能，比如統計用戶點贊數、用戶訪問數等，
  3. 分布式鎖，在分布式場景下，無法使用單機環境下的鎖來對多個節點上的行程進行同步，可以使用 Redis 自帶的 SETNX 命令實作分布式鎖，除此之外，還可以使用官方提供的 RedLock 分布式鎖實作，
  4. 簡單的訊息佇列，可以使用Redis自身的發布/訂閱模式或者List來實作簡單的訊息佇列，實作異步操作，
  5. 限速器，可用于限制某個用戶訪問某個介面的頻率，比如秒殺場景用于防止用戶快速點擊帶來不必要的壓力，
  6. 好友關系，利用集合的一些命令，比如交集、并集、差集等，實作共同好友、共同愛好之類的功能，

Memcached和Redis的區別？

  1. MemCached 資料結構單一，僅用來快取資料，而 Redis 支持多種資料型別，
  2. MemCached 不支持資料持久化，重啟后資料會消失，Redis 支持資料持久化，
  3. Redis 提供主從同步機制和 cluster 集群部署能力，能夠提供高可用服務，Memcached 沒有提供原生的集群模式，需要依靠客戶端實作往集群中分片寫入資料，
  4. Redis 的速度比 Memcached 快很多，
  5. Redis 使用單執行緒的多路 IO 復用模型，Memcached使用多執行緒的非阻塞 IO 模型，（Redis6.0引入了多執行緒IO，用來處理網路資料的讀寫和協議決議，但是命令的執行仍然是單執行緒）
  6. value 值大小不同：Redis 最大可以達到 512M；memcache 只有 1mb，

為什么要用 Redis 而不用 map/guava 做快取?

使用自帶的 map 或者 guava 實作的是本地快取，最主要的特點是輕量以及快速，生命周期隨著 jvm 的銷毀而結束，并且在多實體的情況下，每個實體都需要各自保存一份快取，快取不具有一致性，

使用 redis 或 memcached 之類的稱為分布式快取，在多實體的情況下，各實體共用一份快取資料，快取具有一致性，

給大家分享一個Github倉庫，上面有大彬整理的300多本經典的計算機書籍PDF，包括C語言、C++、Java、Python、前端、資料庫、作業系統、計算機網路、資料結構和演算法、機器學習、編程人生等，可以star一下，下次找書直接在上面搜索，倉庫持續更新中~

Github地址

Redis 資料型別有哪些？

基本資料型別：

1、String：最常用的一種資料型別，String型別的值可以是字串、數字或者二進制，但值最大不能超過512MB，

2、Hash：Hash 是一個鍵值對集合，

3、Set：無序去重的集合，Set 提供了交集、并集等方法，對于實作共同好友、共同關注等功能特別方便，

4、List：有序可重復的集合，底層是依賴雙向鏈表實作的，

5、SortedSet：有序Set，內部維護了一個score的引數來實作，適用于排行榜和帶權重的訊息佇列等場景，

特殊的資料型別：

1、Bitmap：位圖，可以認為是一個以位為單位陣列，陣列中的每個單元只能存0或者1，陣列的下標在 Bitmap 中叫做偏移量，Bitmap的長度與集合中元素個數無關，而是與基數的上限有關，

2、Hyperloglog，HyperLogLog 是用來做基數統計的演算法，其優點是，在輸入元素的數量或者體積非常非常大時，計算基數所需的空間總是固定的、并且是很小的，典型的使用場景是統計獨立訪客，

3、Geospatial ：主要用于存盤地理位置資訊，并對存盤的資訊進行操作，適用場景如定位、附近的人等，

SortedSet和List異同點？

相同點：

  1. 都是有序的；
  2. 都可以獲得某個范圍內的元素，

不同點：

  1. 串列基于鏈表實作，獲取兩端元素速度快，訪問中間元素速度慢；
  2. 有序集合基于散串列和跳躍表實作，訪問中間元素時間復雜度是OlogN；
  3. 串列不能簡單的調整某個元素的位置，有序串列可以（更改元素的分數）；
  4. 有序集合更耗記憶體，

Redis的記憶體用完了會怎樣？

如果達到設定的上限，Redis的寫命令會回傳錯誤資訊（但是讀命令還可以正常回傳），

也可以配置記憶體淘汰機制，當Redis達到記憶體上限時會沖刷掉舊的內容，

Redis如何做記憶體優化？

可以好好利用Hash,list,sorted set,set等集合型別資料，因為通常情況下很多小的Key-Value可以用更緊湊的方式存放到一起，盡可能使用散串列（hashes），散串列（是說散串列里面存盤的數少）使用的記憶體非常小，所以你應該盡可能的將你的資料模型抽象到一個散串列里面，比如你的web系統中有一個用戶物件，不要為這個用戶的名稱，姓氏，郵箱，密碼設定單獨的key，而是應該把這個用戶的所有資訊存盤到一張散串列里面，

keys命令存在的問題？

redis的單執行緒的，keys指令會導致執行緒阻塞一段時間，直到執行完畢，服務才能恢復，scan采用漸進式遍歷的方式來解決keys命令可能帶來的阻塞問題，每次scan命令的時間復雜度是O(1)，但是要真正實作keys的功能，需要執行多次scan，

scan的缺點：在scan的程序中如果有鍵的變化（增加、洗掉、修改），遍歷程序可能會有以下問題：新增的鍵可能沒有遍歷到，遍歷出了重復的鍵等情況，也就是說scan并不能保證完整的遍歷出來所有的鍵，

Redis事務

事務的原理是將一個事務范圍內的若干命令發送給Redis，然后再讓Redis依次執行這些命令，

事務的生命周期：

  1. 使用MULTI開啟一個事務

  2. 在開啟事務的時候，每次操作的命令將會被插入到一個佇列中，同時這個命令并不會被真的執行

  3. EXEC命令進行提交事務

一個事務范圍內某個命令出錯不會影響其他命令的執行，不保證原子性：

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set a 1
QUEUED
127.0.0.1:6379> set b 1 2
QUEUED
127.0.0.1:6379> set c 3
QUEUED
127.0.0.1:6379> exec
1) OK
2) (error) ERR syntax error
3) OK

WATCH命令

WATCH命令可以監控一個或多個鍵，一旦其中有一個鍵被修改，之后的事務就不會執行（類似于樂觀鎖），執行EXEC命令之后，就會自動取消監控，

127.0.0.1:6379> watch name
OK
127.0.0.1:6379> set name 1
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name 2
QUEUED
127.0.0.1:6379> set gender 1
QUEUED
127.0.0.1:6379> exec
(nil)
127.0.0.1:6379> get gender
(nil)

比如上面的代碼中：

  1. watch name開啟了對name這個key的監控
  2. 修改name的值
  3. 開啟事務a
  4. 在事務a中設定了name和gender的值
  5. 使用EXEC命令進提交事務
  6. 使用命令get gender發現不存在，即事務a沒有執行

使用UNWATCH可以取消WATCH命令對key的監控，所有監控鎖將會被取消，

Redis事務支持隔離性嗎？

Redis 是單行程程式，并且它保證在執行事務時，不會對事務進行中斷，事務可以運行直到執行完所有事務佇列中的命令為止，因此，Redis 的事務是總是帶有隔離性的，

Redis事務保證原子性嗎，支持回滾嗎？

Redis單條命令是原子性執行的，但事務不保證原子性，且沒有回滾，事務中任意命令執行失敗，其余的命令仍會被執行，

持久化機制

持久化就是把記憶體的資料寫到磁盤中，防止服務宕機導致記憶體資料丟失，

Redis支持兩種方式的持久化，一種是RDB的方式，一種是AOF的方式，前者會根據指定的規則定時將記憶體中的資料存盤在硬碟上，而后者在每次執行完命令后將命令記錄下來，一般將兩者結合使用，

RDB方式

RDB是 Redis 默認的持久化方案，RDB持久化時會將記憶體中的資料寫入到磁盤中，在指定目錄下生成一個dump.rdb檔案，Redis 重啟會加載dump.rdb檔案恢復資料，

bgsave是主流的觸發 RDB 持久化的方式，執行程序如下：

  • 執行BGSAVE命令
  • Redis 父行程判斷當前是否存在正在執行的子行程，如果存在，BGSAVE命令直接回傳，
  • 父行程執行fork操作創建子行程，fork操作程序中父行程會阻塞，
  • 父行程fork完成后，父行程繼續接收并處理客戶端的請求，而子行程開始將記憶體中的資料寫進硬碟的臨時檔案；
  • 當子行程寫完所有資料后會用該臨時檔案替換舊的 RDB 檔案，

Redis啟動時會讀取RDB快照檔案，將資料從硬碟載入記憶體，通過 RDB 方式的持久化，一旦Redis例外退出，就會丟失最近一次持久化以后更改的資料，

觸發 RDB 持久化的方式：

  1. 手動觸發：用戶執行SAVE或BGSAVE命令，SAVE命令執行快照的程序會阻塞所有客戶端的請求，應避免在生產環境使用此命令，BGSAVE命令可以在后臺異步進行快照操作，快照的同時服務器還可以繼續回應客戶端的請求，因此需要手動執行快照時推薦使用BGSAVE命令，

  2. 被動觸發：

    • 根據配置規則進行自動快照，如SAVE 100 10，100秒內至少有10個鍵被修改則進行快照，
    • 如果從節點執行全量復制操作，主節點會自動執行BGSAVE生成 RDB 檔案并發送給從節點，
    • 默認情況下執行shutdown命令時，如果沒有開啟 AOF 持久化功能則自動執行·BGSAVE·，

優點：

  1. Redis 加載 RDB 恢復資料遠遠快于 AOF 的方式，
  2. 使用單獨子行程來進行持久化，主行程不會進行任何 IO 操作，保證了 Redis 的高性能，

缺點：

  1. RDB方式資料無法做到實時持久化，因為BGSAVE每次運行都要執行fork操作創建子行程，屬于重量級操作，頻繁執行成本比較高，
  2. RDB 檔案使用特定二進制格式保存，Redis 版本升級程序中有多個格式的 RDB 版本，存在老版本 Redis 無法兼容新版 RDB 格式的問題，

AOF方式

AOF（append only file）持久化：以獨立日志的方式記錄每次寫命令，Redis重啟時會重新執行AOF檔案中的命令達到恢復資料的目的，AOF的主要作用是解決了資料持久化的實時性，AOF 是Redis持久化的主流方式，

默認情況下Redis沒有開啟AOF方式的持久化，可以通過appendonly引數啟用：appendonly yes，開啟AOF方式持久化后每執行一條寫命令，Redis就會將該命令寫進aof_buf緩沖區，AOF緩沖區根據對應的策略向硬碟做同步操作，

默認情況下系統每30秒會執行一次同步操作，為了防止緩沖區資料丟失，可以在Redis寫入AOF檔案后主動要求系統將緩沖區資料同步到硬碟上，可以通過appendfsync引數設定同步的時機，

appendfsync always //每次寫入aof檔案都會執行同步，最安全最慢，不建議配置
appendfsync everysec  //既保證性能也保證安全，建議配置
appendfsync no //由作業系統決定何時進行同步操作

接下來看一下 AOF 持久化執行流程：

  1. 所有的寫入命令會追加到 AOP 緩沖區中，
  2. AOF 緩沖區根據對應的策略向硬碟同步，
  3. 隨著 AOF 檔案越來越大，需要定期對 AOF 檔案進行重寫，達到壓縮檔案體積的目的，AOF檔案重寫是把Redis行程內的資料轉化為寫命令同步到新AOF檔案的程序，
  4. 當 Redis 服務器重啟時，可以加載 AOF 檔案進行資料恢復，

優點：

  1. AOF可以更好的保護資料不丟失，可以配置 AOF 每秒執行一次fsync操作，如果Redis行程掛掉，最多丟失1秒的資料，
  2. AOF以append-only的模式寫入，所以沒有磁盤尋址的開銷，寫入性能非常高，

缺點：

  1. 對于同一份檔案AOF檔案比RDB資料快照要大，
  2. 資料恢復比較慢，

RDB和AOF如何選擇？

通常來說，應該同時使用兩種持久化方案，以保證資料安全，

  • 如果資料不敏感，且可以從其他地方重新生成，可以關閉持久化，
  • 如果資料比較重要，且能夠承受幾分鐘的資料丟失，比如快取等，只需要使用RDB即可，
  • 如果是用做記憶體資料，要使用Redis的持久化，建議是RDB和AOF都開啟，
  • 如果只用AOF，優先使用everysec的配置選擇，因為它在可靠性和性能之間取了一個平衡，

當RDB與AOF兩種方式都開啟時，Redis會優先使用AOF恢復資料，因為AOF保存的檔案比RDB檔案更完整，

Redis有哪些部署方案？

單機版：單機部署，單機redis能夠承載的 QPS 大概就在上萬到幾萬不等，這種部署方式很少使用，存在的問題：1、記憶體容量有限 2、處理能力有限 3、無法高可用，

主從模式：一主多從，主負責寫，并且將資料復制到其它的 slave 節點，從節點負責讀，所有的讀請求全部走從節點，這樣也可以很輕松實作水平擴容，支撐讀高并發，master 節點掛掉后，需要手動指定新的 master，可用性不高，基本不用，

哨兵模式：主從復制存在不能自動故障轉移、達不到高可用的問題，哨兵模式解決了這些問題，通過哨兵機制可以自動切換主從節點，master 節點掛掉后，哨兵行程會主動選舉新的 master，可用性高，但是每個節點存盤的資料是一樣的，浪費記憶體空間，資料量不是很多，集群規模不是很大，需要自動容錯容災的時候使用，

Redis cluster：服務端分片技術，3.0版本開始正式提供，Redis Cluster并沒有使用一致性hash，而是采用slot(槽)的概念，一共分成16384個槽，將請求發送到任意節點，接收到請求的節點會將查詢請求發送到正確的節點上執行，主要是針對海量資料+高并發+高可用的場景，如果是海量資料，如果你的資料量很大，那么建議就用Redis cluster，所有主節點的容量總和就是Redis cluster可快取的資料容量，

主從架構

單機的 redis，能夠承載的 QPS 大概就在上萬到幾萬不等，對于快取來說，一般都是用來支撐讀高并發的，因此架構做成主從(master-slave)架構，一主多從，主負責寫，并且將資料復制到其它的 slave 節點，從節點負責讀，所有的讀請求全部走從節點，這樣也可以很輕松實作水平擴容，支撐讀高并發，

Redis的復制功能是支持多個資料庫之間的資料同步，主資料庫可以進行讀寫操作，當主資料庫的資料發生變化時會自動將資料同步到從資料庫，從資料庫一般是只讀的，它會接收主資料庫同步過來的資料，一個主資料庫可以有多個從資料庫，而一個從資料庫只能有一個主資料庫，

主從復制的原理？

  1. 當啟動一個從節點時，它會發送一個 PSYNC 命令給主節點；
  2. 如果是從節點初次連接到主節點，那么會觸發一次全量復制，此時主節點會啟動一個后臺執行緒，開始生成一份 RDB 快照檔案；
  3. 同時還會將從客戶端 client 新收到的所有寫命令快取在記憶體中，RDB 檔案生成完畢后， 主節點會將RDB檔案發送給從節點，從節點會先將RDB檔案寫入本地磁盤，然后再從本地磁盤加載到記憶體中；
  4. 接著主節點會將記憶體中快取的寫命令發送到從節點，從節點同步這些資料；
  5. 如果從節點跟主節點之間網路出現故障，連接斷開了，會自動重連，連接之后主節點僅會將部分缺失的資料同步給從節點，

哨兵Sentinel

主從復制存在不能自動故障轉移、達不到高可用的問題，哨兵模式解決了這些問題，通過哨兵機制可以自動切換主從節點，

客戶端連接Redis的時候，先連接哨兵，哨兵會告訴客戶端Redis主節點的地址，然后客戶端連接上Redis并進行后續的操作，當主節點宕機的時候，哨兵監測到主節點宕機，會重新推選出某個表現良好的從節點成為新的主節點，然后通過發布訂閱模式通知其他的從服務器，讓它們切換主機，

作業原理

  • 每個Sentinel以每秒鐘一次的頻率向它所知道的Master，Slave以及其他 Sentinel 實體發送一個 PING命令，
  • 如果一個實體距離最后一次有效回復 PING 命令的時間超過指定值， 則這個實體會被 Sentine 標記為主觀下線，
  • 如果一個Master被標記為主觀下線，則正在監視這個Master的所有 Sentinel 要以每秒一次的頻率確認Master是否真正進入主觀下線狀態，
  • 當有足夠數量的 Sentinel（大于等于組態檔指定值）在指定的時間范圍內確認Master的確進入了主觀下線狀態， 則Master會被標記為客觀下線 ，若沒有足夠數量的 Sentinel 同意 Master 已經下線， Master 的客觀下線狀態就會被解除， 若 Master重新向 Sentinel 的 PING 命令回傳有效回復， Master 的主觀下線狀態就會被移除，
  • 哨兵節點會選舉出哨兵 leader，負責故障轉移的作業，
  • 哨兵 leader 會推選出某個表現良好的從節點成為新的主節點，然后通知其他從節點更新主節點資訊，

Redis cluster

哨兵模式解決了主從復制不能自動故障轉移、達不到高可用的問題，但還是存在主節點的寫能力、容量受限于單機配置的問題，而cluster模式實作了Redis的分布式存盤，每個節點存盤不同的內容，解決主節點的寫能力、容量受限于單機配置的問題，

Redis cluster集群節點最小配置6個節點以上（3主3從），其中主節點提供讀寫操作，從節點作為備用節點，不提供請求，只作為故障轉移使用，

Redis cluster采用虛擬槽磁區，所有的鍵根據哈希函式映射到0～16383個整數槽內，每個節點負責維護一部分槽以及槽所映射的鍵值資料，

作業原理：

  1. 通過哈希的方式，將資料分片，每個節點均分存盤一定哈希槽(哈希值)區間的資料，默認分配了16384 個槽位
  2. 每份資料分片會存盤在多個互為主從的多節點上
  3. 資料寫入先寫主節點，再同步到從節點(支持配置為阻塞同步)
  4. 同一分片多個節點間的資料不保持一致性
  5. 讀取資料時，當客戶端操作的key沒有分配在該節點上時，redis會回傳轉向指令，指向正確的節點
  6. 擴容時時需要需要把舊節點的資料遷移一部分到新節點

在 redis cluster 架構下，每個 redis 要放開兩個埠號，比如一個是 6379，另外一個就是 加1w 的埠號，比如 16379，

16379 埠號是用來進行節點間通信的，也就是 cluster bus 的東西，cluster bus 的通信，用來進行故障檢測、配置更新、故障轉移授權，cluster bus 用了另外一種二進制的協議，gossip 協議，用于節點間進行高效的資料交換，占用更少的網路帶寬和處理時間，

優點：

  • 無中心架構，支持動態擴容；
  • 資料按照slot存盤分布在多個節點，節點間資料共享，可動態調整資料分布；
  • 高可用性，部分節點不可用時，集群仍可用，集群模式能夠實作自動故障轉移（failover），節點之間通過gossip協議交換狀態資訊，用投票機制完成Slave到Master的角色轉換，

缺點：

  • 不支持批量操作（pipeline），
  • 資料通過異步復制，不保證資料的強一致性，
  • 事務操作支持有限，只支持多key在同一節點上的事務操作，當多個key分布于不同的節點上時無法使用事務功能，
  • key作為資料磁區的最小粒度，不能將一個很大的鍵值物件如hash、list等映射到不同的節點，
  • 不支持多資料庫空間，單機下的Redis可以支持到16個資料庫，集群模式下只能使用1個資料庫空間，
  • 只能使用0號資料庫，

哈希磁區演算法有哪些？

節點取余磁區，使用特定的資料，如Redis的鍵或用戶ID，對節點數量N取余：hash（key）%N計算出哈希值，用來決定資料映射到哪一個節點上，
優點是簡單性，擴容時通常采用翻倍擴容，避免資料映射全部被打亂導致全量遷移的情況，

一致性哈希磁區，為系統中每個節點分配一個token，范圍一般在0~232，這些token構成一個哈希環，資料讀寫執行節點查找操作時，先根據key計算hash值，然后順時針找到第一個大于等于該哈希值的token節點，
這種方式相比節點取余最大的好處在于加入和洗掉節點只影響哈希環中相鄰的節點，對其他節點無影響，

虛擬槽磁區，所有的鍵根據哈希函式映射到0~16383整數槽內，計算公式：slot=CRC16（key）&16383，每一個節點負責維護一部分槽以及槽所映射的鍵值資料，Redis Cluser采用虛擬槽磁區演算法，

過期鍵的洗掉策略？

1、被動洗掉，在訪問key時，如果發現key已經過期，那么會將key洗掉，

2、主動洗掉，定時清理key，每次清理會依次遍歷所有DB，從db隨機取出20個key，如果過期就洗掉，如果其中有5個key過期，那么就繼續對這個db進行清理，否則開始清理下一個db，

3、記憶體不夠時清理，Redis有最大記憶體的限制，通過maxmemory引數可以設定最大記憶體，當使用的記憶體超過了設定的最大記憶體，就要進行記憶體釋放， 在進行記憶體釋放的時候，會按照配置的淘汰策略清理記憶體，

記憶體淘汰策略有哪些？

當Redis的記憶體超過最大允許的記憶體之后，Redis 會觸發記憶體淘汰策略，洗掉一些不常用的資料，以保證Redis服務器正常運行，

Redisv4.0前提供 6 種資料淘汰策略：

  • volatile-lru：LRU（Least Recently Used），最近使用，利用LRU演算法移除設定了過期時間的key
  • allkeys-lru：當記憶體不足以容納新寫入資料時，從資料集中移除最近最少使用的key
  • volatile-ttl：從已設定過期時間的資料集中挑選將要過期的資料淘汰
  • volatile-random：從已設定過期時間的資料集中任意選擇資料淘汰
  • allkeys-random：從資料集中任意選擇資料淘汰
  • no-eviction：禁止洗掉資料，當記憶體不足以容納新寫入資料時，新寫入操作會報錯

Redisv4.0后增加以下兩種：

  • volatile-lfu：LFU，Least Frequently Used，最少使用，從已設定過期時間的資料集中挑選最不經常使用的資料淘汰，
  • allkeys-lfu：當記憶體不足以容納新寫入資料時，從資料集中移除最不經常使用的key，

記憶體淘汰策略可以通過組態檔來修改，相應的配置項是maxmemory-policy，默認配置是noeviction，

如何保證快取與資料庫雙寫時的資料一致性？

1、先洗掉快取再更新資料庫

進行更新操作時，先洗掉快取，然后更新資料庫，后續的請求再次讀取時，會從資料庫讀取后再將新資料更新到快取，

存在的問題：洗掉快取資料之后，更新資料庫完成之前，這個時間段內如果有新的讀請求過來，就會從資料庫讀取舊資料重新寫到快取中，再次造成不一致，并且后續讀的都是舊資料，

2、先更新資料庫再洗掉快取

進行更新操作時，先更新MySQL，成功之后，洗掉快取，后續讀取請求時再將新資料回寫快取，

存在的問題：更新MySQL和洗掉快取這段時間內，請求讀取的還是快取的舊資料，不過等資料庫更新完成，就會恢復一致，影響相對比較小，

3、異步更新快取

資料庫的更新操作完成后不直接操作快取，而是把這個操作命令封裝成訊息扔到訊息佇列中，然后由Redis自己去消費更新資料，訊息佇列可以保證資料操作順序一致性，確保快取系統的資料正常，

以上幾個方案都不完美，需要根據業務需求，評估哪種方案影響較小，然后選擇相應的方案，

快取常見問題

快取穿透

快取穿透是指查詢一個不存在的資料，由于快取是不命中時被動寫的，如果從DB查不到資料則不寫入快取，這將導致這個不存在的資料每次請求都要到DB去查詢，失去了快取的意義，在流量大時，可能DB就掛掉了，

怎么解決？

  1. 快取空值，不會查資料庫，
  2. 采用布隆過濾器，將所有可能存在的資料哈希到一個足夠大的bitmap中，查詢不存在的資料會被這個bitmap攔截掉，從而避免了對DB的查詢壓力，

布隆過濾器的原理：當一個元素被加入集合時，通過K個哈希函式將這個元素映射成一個位陣列中的K個點，把它們置為1，查詢時，將元素通過哈希函式映射之后會得到k個點，如果這些點有任何一個0，則被檢元素一定不在，直接回傳；如果都是1，則查詢元素很可能存在，就會去查詢Redis和資料庫，

布隆過濾器一般用于在大資料量的集合中判定某元素是否存在，

快取雪崩

快取雪崩是指在我們設定快取時采用了相同的過期時間，導致快取在某一時刻同時失效，請求全部轉發到DB，DB瞬時壓力過重掛掉，

解決方法：

  1. 在原有的失效時間基礎上增加一個隨機值，使得過期時間分散一些，這樣每一個快取的過期時間的重復率就會降低，就很難引發集體失效的事件，
  2. 加鎖排隊可以起到緩沖的作用，防止大量的請求同時操作資料庫，但它的缺點是增加了系統的回應時間，降低了系統的吞吐量，犧牲了一部分用戶體驗，當快取未查詢到時，對要請求的 key 進行加鎖，只允許一個執行緒去資料庫中查，其他執行緒等候排隊，
  3. 設定二級快取，二級快取指的是除了 Redis 本身的快取，再設定一層快取，當 Redis 失效之后，先去查詢二級快取，例如可以設定一個本地快取，在 Redis 快取失效的時候先去查詢本地快取而非查詢資料庫，

快取擊穿

快取擊穿：大量的請求同時查詢一個 key 時，此時這個 key 正好失效了，就會導致大量的請求都落到資料庫，快取擊穿是查詢快取中失效的 key，而快取穿透是查詢不存在的 key，

解決方法：

1、加互斥鎖，在并發的多個請求中，只有第一個請求執行緒能拿到鎖并執行資料庫查詢操作，其他的執行緒拿不到鎖就阻塞等著，等到第一個執行緒將資料寫入快取后，直接走快取，可以使用Redis分布式鎖實作，代碼如下：

public String get(String key) {
    String value = https://www.cnblogs.com/tyson03/p/redis.get(key);
    if (value == null) { //快取值過期
        String unique_key = systemId +":" + key;
        //設定30s的超時
        if (redis.set(unique_key, 1, 'NX', 'PX', 30000) == 1) {  //設定成功
            value = https://www.cnblogs.com/tyson03/p/db.get(key);
            redis.set(key, value, expire_secs);
            redis.del(unique_key);
        } else {  //其他執行緒已經到資料庫取值并回寫到快取了，可以重試獲取快取值
            sleep(50);
            get(key);  //重試
        }
    } else {
        return value;
    }
}

2、熱點資料不過期，直接將快取設定為不過期，然后由定時任務去異步加載資料，更新快取，這種方式適用于比較極端的場景，例如流量特別特別大的場景，使用時需要考慮業務能接受資料不一致的時間，還有就是例外情況的處理，保證快取可以定時重繪，

快取預熱

快取預熱就是系統上線后，將相關的快取資料直接加載到快取系統，這樣就可以避免在用戶請求的時候，先查詢資料庫，然后再將資料快取的問題！用戶直接查詢事先被預熱的快取資料！

解決方案：

  1. 直接寫個快取重繪頁面，上線時手工操作一下；
  2. 資料量不大，可以在專案啟動的時候自動進行加載；
  3. 定時重繪快取；

快取降級

當訪問量劇增、服務出現問題（如回應時間慢或不回應）或非核心服務影響到核心流程的性能時，仍然需要保證服務還是可用的，即使是有損服務，系統可以根據一些關鍵資料進行自動降級，也可以配置開關實作人工降級，

快取降級的最終目的是保證核心服務可用，即使是有損的，而且有些服務是無法降級的（如加入購物車、結算），

在進行降級之前要對系統進行梳理，看看系統是不是可以丟卒保帥；從而梳理出哪些必須誓死保護，哪些可降級；比如可以參考日志級別設定預案：

  1. 一般：比如有些服務偶爾因為網路抖動或者服務正在上線而超時，可以自動降級；
  2. 警告：有些服務在一段時間內成功率有波動（如在95~100%之間），可以自動降級或人工降級，并發送告警；
  3. 錯誤：比如可用率低于90%，或者資料庫連接池被打爆了，或者訪問量突然猛增到系統能承受的最大閥值，此時可以根據情況自動降級或者人工降級；
  4. 嚴重錯誤：比如因為特殊原因資料錯誤了，此時需要緊急人工降級，

服務降級的目的，是為了防止Redis服務故障，導致資料庫跟著一起發生雪崩問題，因此，對于不重要的快取資料，可以采取服務降級策略，例如一個比較常見的做法就是，Redis出現問題，不去資料庫查詢，而是直接回傳默認值給用戶，

Redis 怎么實作訊息佇列？

使用list型別保存資料資訊，rpush生產訊息，lpop消費訊息，當lpop沒有訊息時，可以sleep一段時間，然后再檢查有沒有資訊，如果不想sleep的話，可以使用blpop, 在沒有資訊的時候，會一直阻塞，直到資訊的到來，

BLPOP queue 0  //0表示不限制等待時間

BLPOP和LPOP命令相似，唯一的區別就是當串列沒有元素時BLPOP命令會一直阻塞連接，直到有新元素加入，

redis可以通過pub/sub主題訂閱模式實作一個生產者，多個消費者，當然也存在一定的缺點，當消費者下線時，生產的訊息會丟失，

PUBLISH channel1 hi
SUBSCRIBE channel1
UNSUBSCRIBE channel1 //退訂通過SUBSCRIBE命令訂閱的頻道，

PSUBSCRIBE channel?* 按照規則訂閱，
PUNSUBSCRIBE channel?* 退訂通過PSUBSCRIBE命令按照某種規則訂閱的頻道，其中訂閱規則要進行嚴格的字串匹配，PUNSUBSCRIBE *無法退訂channel?*規則，

Redis 怎么實作延時佇列

使用sortedset，拿時間戳作為score，訊息內容作為key，呼叫zadd來生產訊息，消費者用zrangebyscore指令獲取N秒之前的資料輪詢進行處理，

pipeline的作用？

redis客戶端執行一條命令分4個程序： 發送命令、命令排隊、命令執行、回傳結果，使用pipeline可以批量請求，批量回傳結果，執行速度比逐條執行要快，

使用pipeline組裝的命令個數不能太多，不然資料量過大，增加客戶端的等待時間，還可能造成網路阻塞，可以將大量命令的拆分多個小的pipeline命令完成，

原生批命令（mset和mget）與pipeline對比：

  1. 原生批命令是原子性，pipeline是非原子性，pipeline命令中途例外退出，之前執行成功的命令不會回滾，

  2. 原生批命令只有一個命令，但pipeline支持多命令，

LUA腳本

Redis 通過 LUA 腳本創建具有原子性的命令： 當lua腳本命令正在運行的時候，不會有其他腳本或 Redis 命令被執行，實作組合命令的原子操作，

在Redis中執行Lua腳本有兩種方法：eval和evalsha，eval命令使用內置的 Lua 解釋器，對 Lua 腳本進行求值，

//第一個引數是lua腳本，第二個引數是鍵名引數個數，剩下的是鍵名引數和附加引數
> eval "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}" 2 key1 key2 first second
1) "key1"
2) "key2"
3) "first"
4) "second"

lua腳本作用

1、Lua腳本在Redis中是原子執行的，執行程序中間不會插入其他命令，

2、Lua腳本可以將多條命令一次性打包，有效地減少網路開銷，

應用場景

舉例：限制介面訪問頻率，

在Redis維護一個介面訪問次數的鍵值對，key是介面名稱，value是訪問次數，每次訪問介面時，會執行以下操作：

  • 通過aop攔截介面的請求，對介面請求進行計數，每次進來一個請求，相應的介面訪問次數count加1，存入redis，
  • 如果是第一次請求，則會設定count=1，并設定過期時間，因為這里set()和expire()組合操作不是原子操作，所以引入lua腳本，實作原子操作，避免并發訪問問題，
  • 如果給定時間范圍內超過最大訪問次數，則會拋出例外，
private String buildLuaScript() {
    return "local c" +
        "\nc = redis.call('get',KEYS[1])" +
        "\nif c and tonumber(c) > tonumber(ARGV[1]) then" +
        "\nreturn c;" +
        "\nend" +
        "\nc = redis.call('incr',KEYS[1])" +
        "\nif tonumber(c) == 1 then" +
        "\nredis.call('expire',KEYS[1],ARGV[2])" +
        "\nend" +
        "\nreturn c;";
}

String luaScript = buildLuaScript();
RedisScript<Number> redisScript = new DefaultRedisScript<>(luaScript, Number.class);
Number count = redisTemplate.execute(redisScript, keys, limit.count(), limit.period());

PS：這種介面限流的實作方式比較簡單，問題也比較多，一般不會使用，介面限流用的比較多的是令牌桶演算法和漏桶演算法，

什么是RedLock？

Redis 官方站提出了一種權威的基于 Redis 實作分布式鎖的方式名叫 Redlock，此種方式比原先的單節點的方法更安全，它可以保證以下特性：

  1. 安全特性：互斥訪問，即永遠只有一個 client 能拿到鎖
  2. 避免死鎖：最終 client 都可能拿到鎖，不會出現死鎖的情況，即使原本鎖住某資源的 client 掛掉了
  3. 容錯性：只要大部分 Redis 節點存活就可以正常提供服務

Redis大key怎么處理？

通常我們會將含有較大資料或含有大量成員、串列數的Key稱之為大Key，

以下是對各個資料型別大key的描述：

  • value是STRING型別，它的值超過5MB
  • value是ZSET、Hash、List、Set等集合型別時，它的成員數量超過1w個

上述的定義并不絕對，主要是根據value的成員數量和大小來確定，根據業務場景確定標準，

怎么處理：

  1. 當vaule是string時，可以使用序列化、壓縮演算法將key的大小控制在合理范圍內，但是序列化和反序列化都會帶來更多時間上的消耗，或者將key進行拆分，一個大key分為不同的部分，記錄每個部分的key，使用multiget等操作實作事務讀取，
  2. 當value是list/set等集合型別時，根據預估的資料規模來進行分片，不同的元素計算后分到不同的片，

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

  1. Master最好不要做任何持久化作業，包括記憶體快照和AOF日志檔案，特別是不要啟用記憶體快照做持久化，
  2. 如果資料比較關鍵，某個Slave開啟AOF備份資料，策略為每秒同步一次，
  3. 為了主從復制的速度和連接的穩定性，Slave和Master最好在同一個局域網內，
  4. 盡量避免在壓力較大的主庫上增加從庫
  5. Master呼叫BGREWRITEAOF重寫AOF檔案，AOF在重寫的時候會占大量的CPU和記憶體資源，導致服務load過高，出現短暫服務暫停現象，
  6. 為了Master的穩定性，主從復制不要用圖狀結構，用單向鏈表結構更穩定，即主從關系為：Master<–Slave1<–Slave2<–Slave3…，這樣的結構也方便解決單點故障問題，實作Slave對Master的替換，也即，如果Master掛了，可以立馬啟用Slave1做Master，其他不變，

說說為什么Redis過期了為什么記憶體沒釋放？

第一種情況，可能是覆寫之前的key，導致key過期時間發生了改變，

當一個key在Redis中已經存在了，但是由于一些誤操作使得key過期時間發生了改變，從而導致這個key在應該過期的時間內并沒有過期，從而造成記憶體的占用，

第二種情況是，Redis過期key的處理策略導致記憶體沒釋放，

一般Redis對過期key的處理策略有兩種：惰性洗掉和定時洗掉，

先說惰性洗掉的情況

當一個key已經確定設定了xx秒過期同時中間也沒有修改它，xx秒之后它確實已經過期了，但是惰性洗掉的策略它并不會馬上洗掉這個key，而是當再次讀寫這個key時它才會去檢查是否過期，如果過期了就會洗掉這個key，也就是說，惰性洗掉策略下，就算key過期了，也不會立刻釋放內容，要等到下一次讀寫這個key才會洗掉key，

而定時洗掉會在一定時間內主動淘汰一部分已經過期的資料，默認的時間是每100ms過期一次，因為定時洗掉策略每次只會淘汰一部分過期key，而不是所有的過期key，如果redis中資料比較多的話要是一次性全量洗掉對服務器的壓力比較大，每一次只挑一批進行洗掉，所以很可能出現部分已經過期的key并沒有及時的被清理掉，從而導致記憶體沒有即時被釋放，

Redis突然變慢，有哪些原因？

  1. 存在bigkey，如果Redis實體中存盤了 bigkey，那么在淘汰洗掉 bigkey 釋放記憶體時，也會耗時比較久，應該避免存盤 bigkey，降低釋放記憶體的耗時，

  2. 如果Redis 實體設定了記憶體上限 maxmemory，有可能導致 Redis 變慢，當 Redis 記憶體達到 maxmemory 后，每次寫入新的資料之前，Redis 必須先從實體中踢出一部分資料，讓整個實體的記憶體維持在 maxmemory 之下，然后才能把新資料寫進來，

  3. 開啟了記憶體大頁，當 Redis 在執行后臺 RDB 和 AOF rewrite 時，采用 fork 子行程的方式來處理，但主行程 fork 子行程后，此時的主行程依舊是可以接收寫請求的，而進來的寫請求，會采用 Copy On Write（寫時復制）的方式操作記憶體資料，

    什么是寫時復制？

    這樣做的好處是，父行程有任何寫操作，并不會影響子行程的資料持久化，

    不過，主行程在拷貝記憶體資料時，會涉及到新記憶體的申請，如果此時作業系統開啟了記憶體大頁，那么在此期間，客戶端即便只修改 10B 的資料，Redis 在申請記憶體時也會以 2MB 為單位向作業系統申請，申請記憶體的耗時變長，進而導致每個寫請求的延遲增加，影響到 Redis 性能，

    解決方案就是關閉記憶體大頁機制，

  4. 使用了Swap，作業系統為了緩解記憶體不足對應用程式的影響，允許把一部分記憶體中的資料換到磁盤上，以達到應用程式對記憶體使用的緩沖，這些記憶體資料被換到磁盤上的區域，就是 Swap，當記憶體中的資料被換到磁盤上后，Redis 再訪問這些資料時，就需要從磁盤上讀取，訪問磁盤的速度要比訪問記憶體慢幾百倍，尤其是針對 Redis 這種對性能要求極高、性能極其敏感的資料庫來說，這個操作延時是無法接受的，解決方案就是增加機器的記憶體，讓 Redis 有足夠的記憶體可以使用，或者整理記憶體空間，釋放出足夠的記憶體供 Redis 使用

  5. 網路帶寬過載，網路帶寬過載的情況下，服務器在 TCP 層和網路層就會出現資料包發送延遲、丟包等情況，Redis 的高性能，除了操作記憶體之外，就在于網路 IO 了，如果網路 IO 存在瓶頸，那么也會嚴重影響 Redis 的性能，解決方案：1、及時確認占滿網路帶寬 Redis 實體，如果屬于正常的業務訪問，那就需要及時擴容或遷移實體了，避免因為這個實體流量過大，影響這個機器的其他實體，2、運維層面，需要對 Redis 機器的各項指標增加監控，包括網路流量，在網路流量達到一定閾值時提前報警，及時確認和擴容，

  6. 頻繁短連接，頻繁的短連接會導致 Redis 大量時間耗費在連接的建立和釋放上，TCP 的三次握手和四次揮手同樣也會增加訪問延遲，應用應該使用長連接操作 Redis，避免頻繁的短連接，

為什么 Redis 集群的最大槽數是 16384 個？

Redis Cluster 采用資料分片機制，定義了 16384個 Slot槽位，集群中的每個Redis 實體負責維護一部分槽以及槽所映射的鍵值資料，

Redis每個節點之間會定期發送ping/pong訊息（心跳包包含了其他節點的資料），用于交換資料資訊，

Redis集群的節點會按照以下規則發ping訊息：

  • (1)每秒會隨機選取5個節點，找出最久沒有通信的節點發送ping訊息
  • (2)每100毫秒都會掃描本地節點串列，如果發現節點最近一次接受pong訊息的時間大于cluster-node-timeout/2 則立刻發送ping訊息

心跳包的訊息頭里面有個myslots的char陣列，是一個bitmap，每一個位代表一個槽，如果該位為1，表示這個槽是屬于這個節點的，

接下來，解答為什么 Redis 集群的最大槽數是 16384 個，而不是65536 個，

1、如果采用 16384 個插槽，那么心跳包的訊息頭占用空間 2KB （16384/8）；如果采用 65536 個插槽，那么心跳包的訊息頭占用空間 8KB (65536/8)，可見采用 65536 個插槽，發送心跳資訊的訊息頭達8k，比較浪費帶寬，

2、一般情況下一個Redis集群不會有超過1000個master節點，太多可能導致網路擁堵，

3、哈希槽是通過一張bitmap的形式來保存的，在傳輸程序中，會對bitmap進行壓縮，bitmap的填充率越低，壓縮率越高，其中bitmap 填充率 = slots / N (N表示節點數)，所以，插槽數越低， 填充率會降低，壓縮率會提高，

給大家分享一個Github倉庫，上面有大彬整理的300多本經典的計算機書籍PDF，包括C語言、C++、Java、Python、前端、資料庫、作業系統、計算機網路、資料結構和演算法、機器學習、編程人生等，可以star一下，下次找書直接在上面搜索，倉庫持續更新中~

Github地址

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/553939.html

標籤：Java

上一篇：《面試1v1》synchronized

下一篇：返回列表

標籤雲
其他(160069) Python(38189) JavaScript(25469) Java(18171) C(15235) 區塊鏈(8268) C＃(7972) AI(7469) 爪哇(7425) MySQL(7219) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5873) 数组(5741) R(5409) Linux(5344) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4580) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2434) ASP.NET(2403) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) .NET技术(1979) 功能(1967) Web開發(1951) HtmlCss(1950) C++(1928) python-3.x(1918) 弹簧靴(1913) xml(1889) PostgreSQL(1879) .NETCore(1863) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 【C++】Microsoft C++、C 和匯編程式檔案

    ......

    uj5u.com 2020-09-10 00:57:23 more
  • 例外宣告

    相比于斷言適用于排除邏輯上不可能存在的狀態，例外通常是用于邏輯上可能發生的錯誤。 例外宣告 Item 1：當函式不可能拋出例外或不能接受拋出例外時，使用noexcept 理由 如果不打算拋出例外的話，程式就會認為無法處理這種錯誤，并且應當盡早終止，如此可以有效地阻止例外的傳播與擴散。 示例 //不可 ......

    uj5u.com 2020-09-10 00:57:27 more
  • Codeforces 1400E Clear the Multiset(貪心 + 分治)

    鏈接：https://codeforces.com/problemset/problem/1400/E 來源：Codeforces 思路：給你一個陣列，現在你可以進行兩種操作，操作1：將一段沒有 0 的區間進行減一的操作，操作2：將 i 位置上的元素歸零。最終問：將這個陣列的全部元素歸零后操作的最少 ......

    uj5u.com 2020-09-10 00:57:30 more
  • UVA11610 【Reverse Prime】

    本人看到此題沒有翻譯，就附帶了一個自己的翻譯版本 思考 這一題，它的第一個要求是找出所有 $7$ 位反向質數及其質因數的個數。 我們應該需要質數篩篩選1~$10^{7}$的所有數，這里就不慢慢介紹了。但是，重讀題，我們突然發現反向質數都是 $7$ 位，而將它反過來后的數字卻是 $6$ 位數，這就說明 ......

    uj5u.com 2020-09-10 00:57:36 more
  • 統計區間素數數量

    1 #pragma GCC optimize(2) 2 #include <bits/stdc++.h> 3 using namespace std; 4 bool isprime[1000000010]; 5 vector<int> prime; 6 inline int getlist(int ......

    uj5u.com 2020-09-10 00:57:47 more
  • C/C++編程筆記：C++中的 const 變數詳解，教你正確認識const用法

    1、C中的const 1、區域const變數存放在堆疊區中，會分配記憶體（也就是說可以通過地址間接修改變數的值）。測驗代碼如下： 運行結果： 2、全域const變數存放在只讀資料段（不能通過地址修改，會發生寫入錯誤）， 默認為外部聯編，可以給其他源檔案使用（需要用extern關鍵字修飾） 運行結果： ......

    uj5u.com 2020-09-10 00:58:04 more
  • 【C++犯錯記錄】VS2019 MFC添加資源不懂如何修改資源宏ID

    1. 首先在資源視圖中，添加資源 2. 點擊新添加的資源，復制自動生成的ID 3. 在解決方案資源管理器中找到Resource.h檔案，編輯，使用整個專案搜索和替換的方式快速替換 宏宣告 4. Ctrl+Shift+F 全域搜索，點擊查找全部，然后逐個替換 5. 為什么使用搜索替換而不使用屬性視窗直 ......

    uj5u.com 2020-09-10 00:59:11 more
  • 【C++犯錯記錄】VS2019 MFC不懂的批量添加資源

    1. 打開資源頭檔案Resource.h，在其中預先定義好宏 ID（不清楚其實ID值應該設定多少，可以先新建一個相同的資源項，再在這個資源的ID值的基礎上遞增即可） 2. 在資源視圖中選中專案資源，按F7編輯資源檔案，按 ID 型別 相對路徑的形式添加 資源。（別忘了先把檔案拷貝到專案中的res檔案 ......

    uj5u.com 2020-09-10 01:00:19 more
  • C/C++編程筆記：關于C++的參考型別，專供新手入門使用

    今天要講的是C++中我最喜歡的一個用法——參考，也叫別名。 參考就是給一個變數名取一個變數名，方便我們間接地使用這個變數。我們可以給一個變數創建N個參考，這N + 1個變數共享了同一塊記憶體區域。(參考型別的變數會占用記憶體空間，占用的記憶體空間的大小和指標型別的大小是相同的。雖然參考是一個物件的別名，但 ......

    uj5u.com 2020-09-10 01:00:22 more
  • 【C/C++編程筆記】從頭開始學習C ++：初學者完整指南

    眾所周知，C ++的學習曲線陡峭，但是花時間學習這種語言將為您的職業帶來奇跡，并使您與其他開發人員區分開。您會更輕松地學習新語言，形成真正的解決問題的技能，并在編程的基礎上打下堅實的基礎。 C ++將幫助您養成良好的編程習慣（即清晰一致的編碼風格，在撰寫代碼時注釋代碼，并限制類內部的可見性），并且由 ......

    uj5u.com 2020-09-10 01:00:41 more
最新发布
  • 吃透Redis面試八股文

    > 內容摘自我的學習網站：topjavaer.cn Redis連環40問，絕對夠全！ ## Redis是什么？ Redis（`Remote Dictionary Server`）是一個使用 C 語言撰寫的，高性能非關系型的鍵值對資料庫。與傳統資料庫不同的是，Redis 的資料是存在記憶體中的，所以讀寫 ......

    uj5u.com 2023-06-01 07:38:56 more
  • 《面試1v1》synchronized

    > 原始碼都背下來了，你給我看這 **我是 javapub，一名 `Markdown` 程式員從👨?💻，八股文種子選手。** **面試官： 你好，我看到你的簡歷上寫著你熟悉 Java 中的 "synchronized" 關鍵字。你能給我講講它的作用嗎？** **候選人：** 當然，"synchro ......

    uj5u.com 2023-06-01 07:38:47 more
  • 單例模式

    ## 單例模式（反射破壞-列舉） #### 餓漢式單例 ~~~java package com.jan.single; //餓漢式單例 public class Hungry { //一上來就會加載好，可能會浪費空間 private byte[] data11=new byte[1024*1024] ......

    uj5u.com 2023-06-01 07:38:30 more
  • 【Netty實戰】1~3章學習筆記

    # 1. Netty總體結構 ## 1.1 Netty簡介 ? Netty是一款用于創建高性能網路應用程式的高級框架。它的基于 Java NIO 的異步的和事件驅動的實作，保證了高負載下應用程式性能的最大化和可伸縮性。 ? 其次，Netty 也包含了一組**設計模式**，將應用程式邏輯從網路層解耦， ......

    uj5u.com 2023-06-01 07:38:10 more
  • Spring MVC官方檔案學習筆記（二）之DispatcherServlet

    **1.DispatcherServlet入門** (1) Spring MVC是以前端控制器模式(即圍繞著一個中央的Servelt, DispatcherServlet)進行設計的,這個DispatcherServlet為請求的處理提供了一個共用的演算法,即它都會將實際的請求處理作業委托給那些可配置 ......

    uj5u.com 2023-06-01 07:37:57 more
  • 別再滿屏找日志了！推薦一款 IDEA 日志管理插件，看日志輕松多了！

    ![](https://img2023.cnblogs.com/other/1218593/202305/1218593-20230531145646615-374710580.png) ## **1.簡介** Grep Console是一款方便開發者對idea控制臺輸出日志進行個性化管理的插件。 ......

    uj5u.com 2023-06-01 07:36:36 more
  • StampedLock：高并發場景下一種比讀寫鎖更快的鎖

    摘要：在讀多寫少的環境中，有沒有一種比ReadWriteLock更快的鎖呢？有，那就是JDK1.8中新增的StampedLock！ 本文分享自華為云社區《【高并發】高并發場景下一種比讀寫鎖更快的鎖》，作者： 冰 河。 什么是StampedLock? ReadWriteLock鎖允許多個執行緒同時讀取共 ......

    uj5u.com 2023-06-01 07:31:08 more
  • BIO、NIO、AIO區別詳解

    ###BIO：同步阻塞 主執行緒發起io請求后，需要等待當前io操作完成，才能繼續執行。 ###NIO：同步非阻塞 引入selector、channel、等概念，當主執行緒發起io請求后，輪詢的查看系統是否準備好執行io操作，沒有準備好則主執行緒不會阻塞會繼續執行，準備好主執行緒會阻塞等待io操作完成。 # ......

    uj5u.com 2023-06-01 07:30:33 more
  • Java中泛型詳解，非常詳細

    # 前言 在前面的幾篇文章中，詳細地給大家介紹了Java里的集合。但在介紹集合時，我們涉及到了泛型的概念卻并沒有詳細學習，**所以今天我們要花點時間給大家專門講解什么是泛型、泛型的作用、用法、特點等內容。** 有些粉絲朋友，在之前就一直很好奇，比如List中的 部分到底是什么？有啥用？為什么要加這個 ......

    uj5u.com 2023-05-31 10:10:59 more
  • Rust Web 全堆疊開發之 Web Service 中的錯誤處理

    # Rust Web 全堆疊開發之 Web Service 中的錯誤處理 ## Web Service 中的統一錯誤處理 ### Actix Web Service 自定義錯誤型別 -> 自定義錯誤轉為 HTTP Response - 資料庫 - 資料庫錯誤 - 串行化 - serde 錯誤 - I/ ......

    uj5u.com 2023-05-31 10:10:55 more

Copyright © 2010-2020 有解無憂