柚子快報(bào)邀請(qǐng)碼778899分享：數(shù)據(jù)庫 Redis復(fù)習(xí)總結(jié)

http://yzkb.51969.com/

之前寫的博客太雜，最近想把Redis的知識(shí)點(diǎn)再系統(tǒng)的過一遍，帶著自己的理解使用簡(jiǎn)短的話把一些問題總結(jié)一下，尤其是開發(fā)中和面試中的高頻問題，基礎(chǔ)知識(shí)點(diǎn)參考–>Redis入門、Spring Cache,這篇不再贅述。

目錄

基礎(chǔ)

簡(jiǎn)介；與Memcached的區(qū)別；為什么作為mysql緩存？

如何保證都是熱點(diǎn)數(shù)據(jù) ；如何監(jiān)控緩存命中率

線程模型？為什么單線程還那么快？I/O多路復(fù)用（epoll）？

除了做緩存還能拿來做什么？

Redis是AP還是CP的？

Key沖突

Redis的最佳實(shí)踐

數(shù)據(jù)結(jié)構(gòu)

9種數(shù)據(jù)類型及適用場(chǎng)景

底層數(shù)據(jù)結(jié)構(gòu)

事務(wù)

如何實(shí)現(xiàn)redis原子性；除了lua還有辦法么？

為什么Lua能保證原子性？執(zhí)行失敗會(huì)怎么樣？

持久化

數(shù)據(jù)如何不丟失（RDB、AOF）

Big Key相關(guān)

過期刪除與內(nèi)存淘汰

過期刪除（過期key）

內(nèi)存淘汰（數(shù)據(jù)淘汰、內(nèi)存過大）

緩存

緩存雪崩、擊穿、穿透；布隆過濾器

常見的緩存更新策略

mysql的數(shù)據(jù)如何與redis同步（雙寫一致性）；如何強(qiáng)一致？

怎么保證Redis的高并發(fā)高可用（三種集群方案）

主從同步相關(guān)（主從復(fù)制）；斷點(diǎn)續(xù)傳

哨兵模式相關(guān)；腦裂

集群會(huì)有寫操作丟失嗎？

分片集群相關(guān)

實(shí)戰(zhàn)

分布式鎖相關(guān)

熱Key相關(guān)

實(shí)現(xiàn)延遲隊(duì)列

基礎(chǔ)

簡(jiǎn)介；與Memcached的區(qū)別；為什么作為mysql緩存？

什么是redis？

Redis 是一種基于內(nèi)存的數(shù)據(jù)庫，讀寫速度極快，常用于緩存、消息隊(duì)列、分布式鎖等場(chǎng)景。Redis 提供多種數(shù)據(jù)類型支持不同業(yè)務(wù)需求。其操作具有原子性，由單線程執(zhí)行，無并發(fā)競(jìng)爭(zhēng)問題。

此外，Redis 還支持事務(wù)、持久化、Lua 腳本、多種集群模式（主從復(fù)制、哨兵、切片集群）、發(fā)布/訂閱模式，以及內(nèi)存淘汰和過期刪除機(jī)制。

redis與與Memcached的區(qū)別

很多人選擇 Redis 作為緩存，而不是 Memcached，即使 Memcached 也是基于內(nèi)存的數(shù)據(jù)庫。要解答這個(gè)問題，需要了解兩者的區(qū)別和共同點(diǎn)。

共同點(diǎn)：1、都是基于內(nèi)存的數(shù)據(jù)庫，主要用作緩存；2、都有過期策略；3、性能非常高。

區(qū)別： 數(shù)據(jù)類型：Redis 支持豐富的數(shù)據(jù)類型（String、Hash、List、Set、ZSet），而 Memcached 只支持簡(jiǎn)單的 key-value 數(shù)據(jù)類型。 持久化：Redis 支持將內(nèi)存數(shù)據(jù)持久化到磁盤，重啟可恢復(fù)；Memcached 不支持持久化，數(shù)據(jù)存于內(nèi)存中，重啟或故障后數(shù)據(jù)丟失。 集群：Redis 原生支持集群模式；Memcached 沒有原生集群模式，依賴于客戶端實(shí)現(xiàn)分片寫入。 功能：Redis 支持發(fā)布訂閱模型、Lua腳本、事務(wù)等高級(jí)功能；Memcached 不支持這些功能。

為什么作為mysq緩存

Redis 作為 MySQL 緩存的優(yōu)勢(shì)主要在于「高性能」和「高并發(fā)」。

高性能：用戶首次訪問 MySQL 數(shù)據(jù)時(shí)會(huì)比較慢，因?yàn)樾枰獜挠脖P讀取。將數(shù)據(jù)緩存在 Redis 中，這樣后續(xù)訪問可以直接從內(nèi)存獲取，速度極快。當(dāng) MySQL 數(shù)據(jù)發(fā)生變化時(shí)，需同步更新 Redis 緩存，這涉及雙寫一致性問題。

高并發(fā)：Redis 的 QPS 是 MySQL 的 10 倍以上。Redis 單機(jī) QPS 能輕松突破 10萬，而 MySQL 單機(jī) QPS 很難達(dá)到 1萬。因此，使用 Redis 能大幅提升請(qǐng)求承受能力，把部分?jǐn)?shù)據(jù)緩存到 Redis 可以減少對(duì) MySQL 的直接訪問。

如何保證都是熱點(diǎn)數(shù)據(jù) ；如何監(jiān)控緩存命中率

如何保證Redis中的數(shù)據(jù)都是熱點(diǎn)數(shù)據(jù) ? 如何提高緩存命中率？

1.一般redis會(huì)給key設(shè)置過期時(shí)間，可以設(shè)置在過期之前如果被訪問了，就給key加上過期時(shí)間，類似看門狗(redission)機(jī)制的思想，具體加多少可以根據(jù)實(shí)際業(yè)務(wù)場(chǎng)景來決定，這樣的話訪問的次數(shù)越多，過期時(shí)間就會(huì)越長(zhǎng)，留在redis里的自然就是熱點(diǎn)數(shù)據(jù)（過期key是怎么刪除的下面有介紹）

如果定期刪除漏掉了很多過期key沒有及時(shí)查詢也沒有走惰性刪除，就會(huì)走內(nèi)存淘汰機(jī)制了。

2.可以使用 allkeys-lru （挑選最近最少使用的數(shù)據(jù)淘汰）淘汰策略（下面內(nèi)存淘汰有介紹），核心思想是“如果數(shù)據(jù)過去被訪問多次，那么將來被訪問的頻率也更高”，那留下來的都是經(jīng)常訪問的熱點(diǎn)數(shù)據(jù)。不使用 LRU 算法的原因是，其無法解決緩存污染問題，大量一次性讀取數(shù)據(jù)會(huì)長(zhǎng)時(shí)間占用內(nèi)存。

3.對(duì)于一些可以預(yù)測(cè)的熱點(diǎn)數(shù)據(jù)，比如秒殺庫存、熱門產(chǎn)品等，這些訪問量比較大的就可以預(yù)先加載到redis里。

4.定期監(jiān)控redis的使用情況，比如說命中率或者內(nèi)存使用情況，然后根據(jù)實(shí)際情況去調(diào)整和配置淘汰策略，確保數(shù)據(jù)有效管理和內(nèi)存高效利用

如何監(jiān)控緩存命中率？ 在memncached中，運(yùn)行state命令可以查看memcached服務(wù)的狀態(tài)信息，其中cmd_get表示總的get次數(shù)，get_hits表示get的總命中次數(shù)，命中率 = get_hits/cmd_get 也可以通過一些開源的第三方工具對(duì)整個(gè)memCached集群進(jìn)行監(jiān)控，典型的包括：Zabbix**、**MemAdmin等。 同理，在redis中可以運(yùn)行info命令查看redis服務(wù)的狀態(tài)信息，其中keyspace_hits為總的命中次效，keyspace_misses為總的miss次數(shù)，命中率=keyspace_hits / (keyspace_hits+keyspace_misses) 開源工具Redis-star能以圖表方式直觀reids服務(wù)相關(guān)信息，同時(shí)，zabbix也提供了相關(guān)的插件對(duì)reids服務(wù)進(jìn)行監(jiān)控。

線程模型？為什么單線程還那么快？I/O多路復(fù)用（epoll）？

Redis的網(wǎng)絡(luò)（線程）模型是怎樣的？

Redis 6.0之前，使用的是單Reactor單線程模式。核心在于所有操作都在單個(gè)進(jìn)程中完成，避免了進(jìn)程間通信和多進(jìn)程競(jìng)爭(zhēng)的復(fù)雜性，因此實(shí)現(xiàn)相對(duì)簡(jiǎn)單。

單Reactor單線程模式存在兩個(gè)主要缺點(diǎn)：

1.無法充分利用多核CPU性能：因?yàn)橹挥幸粋€(gè)線程在執(zhí)行，CPU的多核優(yōu)勢(shì)無法得到充分發(fā)揮。 2.處理延遲問題：當(dāng)一個(gè)Handler對(duì)象正在處理業(yè)務(wù)時(shí)，其他連接的事件無法得到及時(shí)處理。如果某個(gè)任務(wù)耗時(shí)較長(zhǎng)，會(huì)導(dǎo)致整體響應(yīng)時(shí)間延遲。 因此，單Reactor單線程模式不適用于CPU密集型的場(chǎng)景，只適合業(yè)務(wù)處理非?？焖俚膱?chǎng)景。Redis主要通過C語言實(shí)現(xiàn)，在6.0之前因?yàn)椴僮髦饕趦?nèi)存中完成，處理速度很快，所以性能瓶頸不在CPU上。隨著網(wǎng)絡(luò)硬件性能的提升，網(wǎng)絡(luò)I/O處理有時(shí)會(huì)成為瓶頸。

Redis 6.0之后，Redis引入了多線程模式。通過多線程處理網(wǎng)絡(luò)I/O，可以提高并行度和網(wǎng)絡(luò)處理性能。然而，Redis在命令執(zhí)行上仍然采用單線程模式，也就不會(huì)存在線程安全問題。這種設(shè)計(jì)在增強(qiáng)網(wǎng)絡(luò)I/O處理性能的同時(shí)，保持了命令執(zhí)行的一致性和簡(jiǎn)潔性，使得Redis依然能夠高效地運(yùn)行。

總結(jié)：Redis的網(wǎng)絡(luò)模型在6.0版本之前是單Reactor單線程模式，在6.0版本后改為多線程處理網(wǎng)絡(luò)I/O，但命令執(zhí)行仍用單線程。

Redis 6.0之前實(shí)際上并不是單線程的。只是主要工作（網(wǎng)絡(luò)I/O和命令執(zhí)行）一直使用單線程模型，其實(shí)啟動(dòng)時(shí)，Redis 會(huì)啟動(dòng)后臺(tái)線程（BIO）以處理耗時(shí)任務(wù)： 在Redis 2.6版本，啟動(dòng)了2個(gè)后臺(tái)線程，分別處理文件關(guān)閉和AOF刷盤任務(wù)，例如，命令 unlink key、flushdb async、flushall async 會(huì)交給后臺(tái)線程處理，避免主線程卡頓。因此，刪除大key時(shí)應(yīng)使用 unlink 而非 del 命令，以免阻塞主線程。 在Redis 4.0版本后，新增一個(gè)用于異步釋放內(nèi)存的線程，即lazyfree線程。 Redis為「關(guān)閉文件、AOF刷盤、釋放內(nèi)存」等任務(wù)創(chuàng)建單獨(dú)線程，因?yàn)檫@些操作耗時(shí)較長(zhǎng)，如果在主線程處理會(huì)導(dǎo)致阻塞，影響后續(xù)請(qǐng)求的處理。后臺(tái)線程相當(dāng)于一個(gè)消費(fèi)者，不停輪詢?nèi)蝿?wù)隊(duì)列，任務(wù)完成就執(zhí)行相應(yīng)操作。

Redis是單線程的，但是為什么還那么快？

Redis 實(shí)際上并不是單線程的。只是主要工作（網(wǎng)絡(luò)I/O和命令執(zhí)行）一直使用單線程模型，但在Redis 6.0版本后，引入了多I/O線程來處理網(wǎng)絡(luò)請(qǐng)求，是因?yàn)殡S著硬件性能提升，Redis的瓶頸有時(shí)出現(xiàn)在網(wǎng)絡(luò)I/O處理上。 其實(shí)啟動(dòng)時(shí)，Redis 會(huì)啟動(dòng)后臺(tái)線程（BIO）以處理耗時(shí)任務(wù)： 在Redis 2.6版本，啟動(dòng)了2個(gè)后臺(tái)線程，分別處理文件關(guān)閉和AOF刷盤任務(wù)，例如，命令 unlink key、flushdb async、flushall async 會(huì)交給后臺(tái)線程處理，避免主線程卡頓。因此，刪除大key時(shí)應(yīng)使用 unlink 而非 del 命令，以免阻塞主線程。 在Redis 4.0版本后，新增一個(gè)用于異步釋放內(nèi)存的線程，即lazyfree線程。 Redis為「關(guān)閉文件、AOF刷盤、釋放內(nèi)存」等任務(wù)創(chuàng)建單獨(dú)線程，因?yàn)檫@些操作耗時(shí)較長(zhǎng)，如果在主線程處理會(huì)導(dǎo)致阻塞，影響后續(xù)請(qǐng)求的處理。后臺(tái)線程相當(dāng)于一個(gè)消費(fèi)者，不停輪詢?nèi)蝿?wù)隊(duì)列，任務(wù)完成就執(zhí)行相應(yīng)操作。

Redis 之所以采用單線程模型，并且能夠保持極高的性能，主要有以下幾個(gè)原因：

內(nèi)存操作和高效數(shù)據(jù)結(jié)構(gòu)：Redis 的大部分操作都在內(nèi)存中完成，速度極快，；采用了高效的數(shù)據(jù)結(jié)構(gòu)，進(jìn)一步提升了操作效率；瓶頸通常在于機(jī)器的內(nèi)存或網(wǎng)絡(luò)帶寬，而非 CPU。因此，使用單線程并不會(huì)遇到性能瓶頸。

避免多線程開銷：?jiǎn)尉€程模型避免了多線程之間的資源競(jìng)爭(zhēng)，省去了線程切換帶來的時(shí)間開銷。任務(wù)執(zhí)行也是單線程的，也不存在線程安全問題。這樣也消除了死鎖等多線程編程中的潛在問題，提高了系統(tǒng)的穩(wěn)定性和性能。

I/O 多路復(fù)用機(jī)制：Redis 采用 I/O 多路復(fù)用機(jī)制來處理大量的客戶端 Socket 請(qǐng)求。I/O 多路復(fù)用是一種允許一個(gè)線程處理多個(gè) IO 流的技術(shù)，常見的實(shí)現(xiàn)方式包括select和epoll。例如：bgsave 和 bgrewriteaof 都是在后臺(tái)執(zhí)行操作，不影響主線程的正常使用，不會(huì)產(chǎn)生阻塞

解釋一下I/O多路復(fù)用模型？

I/O多路復(fù)用是指利用單個(gè)線程來同時(shí)監(jiān)聽多個(gè)Socket ，并在某個(gè)Socket可讀、可寫時(shí)得到通知，從而避免無效的等待，充分利用CPU資源。目前的I/O多路復(fù)用都是采用的epoll模式實(shí)現(xiàn)，它會(huì)在通知用戶進(jìn)程Socket就緒的同時(shí)，把已就緒的Socket寫入用戶空間，不需要挨個(gè)遍歷Socket來判斷是否就緒，提升了性能。 其中Redis的網(wǎng)絡(luò)模型就是使用I/O多路復(fù)用結(jié)合事件的處理器來應(yīng)對(duì)多個(gè)Socket請(qǐng)求，比如，提供了連接應(yīng)答處理器、命令回復(fù)處理器，命令請(qǐng)求處理器； 在Redis6.0之后，為了提升更好的性能，在命令回復(fù)處理器使用了多線程來處理回復(fù)事件，在命令請(qǐng)求處理器中，將命令的轉(zhuǎn)換使用了多線程，增加命令轉(zhuǎn)換速度，在命令執(zhí)行的時(shí)候，依然是單線程。

最基礎(chǔ)的 TCP Socket 編程使用阻塞 I/O 模型，只能一對(duì)一通信。為支持多客戶端，傳統(tǒng)方法是使用多進(jìn)程/線程模型，每個(gè)客戶端連接分配一個(gè)進(jìn)程/線程。當(dāng)請(qǐng)求過多時(shí)，調(diào)度和內(nèi)存開銷巨大，成為瓶頸。 I/O 多路復(fù)用解決上述問題，有三種 API：select、poll、epoll。 select 和 poll： 1.本質(zhì)沒有區(qū)別，都是使用線性結(jié)構(gòu)存儲(chǔ)進(jìn)程關(guān)注的 Socket 集合。只不過poll 不再使用 BitsMap 存儲(chǔ)關(guān)注的文件描述符，而是改用動(dòng)態(tài)數(shù)組并以鏈表形式組織。這打破了 select 的文件描述符個(gè)數(shù)限制，但仍受系統(tǒng)文件描述符限制。 2.需要將關(guān)注的 Socket 集合通過系統(tǒng)調(diào)用從用戶態(tài)拷貝到內(nèi)核態(tài)，由內(nèi)核檢測(cè)事件。 3.當(dāng)事件生成，內(nèi)核要遍歷集合集才能找到對(duì)應(yīng) Socket 并設(shè)置狀態(tài)為可讀/可寫，再拷貝回用戶態(tài)，用戶態(tài)繼續(xù)遍歷處理。 3.缺陷在于客戶端多時(shí)，遍歷和拷貝開銷大，難以應(yīng)對(duì) C10K 問題（C 是 Client 單詞首字母縮寫，C10K 就是單機(jī)同時(shí)處理 1 萬個(gè)請(qǐng)求的問題。） epoll： 使用紅黑樹管理待檢測(cè) Socket，增刪改 O(logn)，這能減少內(nèi)核和用戶空間的大量數(shù)據(jù)拷貝和內(nèi)存分配。 事件驅(qū)動(dòng)機(jī)制，內(nèi)核通過鏈表記錄就緒事件，僅傳遞有事件發(fā)生的 Socket 集合，提高效率。 支持邊緣觸發(fā)和水平觸發(fā)，邊緣觸發(fā)效率更高，而 select/poll 僅支持水平觸發(fā)。

什么是邊緣觸發(fā)、水平觸發(fā)？ Epoll 支持兩種事件觸發(fā)模式：邊緣觸發(fā)（ET，Edge-triggered）和水平觸發(fā)（LT，Level-triggered）。雖然這兩個(gè)詞聽上去有些抽象，但其實(shí)很容易理解。 邊緣觸發(fā)（ET）：當(dāng)監(jiān)控的 Socket 有可讀事件時(shí)，服務(wù)器只會(huì)從 epoll_wait 中蘇醒一次，無論你是否調(diào)用 read 函數(shù)讀取數(shù)據(jù)。因此，你需要保證每次都盡可能讀完所有數(shù)據(jù)。 水平觸發(fā)（LT）：當(dāng)監(jiān)控的 Socket 有可讀事件時(shí)，服務(wù)器會(huì)不斷從 epoll_wait 中蘇醒，直到內(nèi)核緩沖區(qū)的數(shù)據(jù)被讀完，以確保你知道還有數(shù)據(jù)需要處理。 類比： 邊緣觸發(fā)：想象你的快遞到了一個(gè)快遞箱，快遞箱只能發(fā)一次短信通知，即使你沒有去取，它也不會(huì)再提醒你。即只要數(shù)據(jù)未讀完，就會(huì)持續(xù)通知。 水平觸發(fā)：快遞箱會(huì)不停地發(fā)短信，直到你把快遞取走為止。即只在事件第一次發(fā)生時(shí)通知一次，之后不會(huì)再重復(fù)通知。 用水平觸發(fā)時(shí)，當(dāng)內(nèi)核通知文件描述符可讀寫后，你可以檢測(cè)它的狀態(tài)，并決定是否繼續(xù)操作，沒有必要一次性讀寫完數(shù)據(jù)。而用邊緣觸發(fā)時(shí)，事件只會(huì)通知一次，所以你必須盡可能多地讀寫數(shù)據(jù)，否則可能錯(cuò)過處理機(jī)會(huì)。 邊緣觸發(fā)一般和非阻塞 I/O搭配使用。因?yàn)槿绻闶褂眠吘売|發(fā)模式，當(dāng) I/O 事件發(fā)生時(shí)系統(tǒng)只會(huì)通知你一次，我們不知道具體能讀寫多少數(shù)據(jù)。因此，在收到通知后要盡可能多地讀寫數(shù)據(jù)，以免錯(cuò)失機(jī)會(huì)。這通常需要對(duì)文件描述符進(jìn)行循環(huán)讀寫操作。如果文件描述符是阻塞的，當(dāng)沒有數(shù)據(jù)可讀寫時(shí)，進(jìn)程會(huì)卡在讀寫操作上，程序就無法繼續(xù)運(yùn)行。因此，邊緣觸發(fā)模式通常與非阻塞 I/O 結(jié)合使用，這樣程序可以一直嘗試讀寫操作，直到系統(tǒng)調(diào)用（例如 read 和 write）因?yàn)闆]有數(shù)據(jù)而返回 EAGAIN 或 EWOULDBLOCK 錯(cuò)誤。 一般來說，邊緣觸發(fā)效率更高，因?yàn)樗鼫p少了 epoll_wait 的調(diào)用次數(shù)，從而減少了系統(tǒng)調(diào)用的開銷。傳統(tǒng)的 select/poll 只有水平觸發(fā)模式，而 epoll 默認(rèn)是水平觸發(fā)，但可以設(shè)置為邊緣觸發(fā)。

除了做緩存還能拿來做什么？

Redis 是非關(guān)系型的基于內(nèi)存存儲(chǔ)的鍵值對(duì)數(shù)據(jù)庫，它的主要作用就是用來緩存數(shù)據(jù)，來提高系統(tǒng)的性能；同時(shí) Redis中，還提供了多種數(shù)據(jù)類型（比如：String / Hash / List / Set / ZSet / Geo / BitMap等），正是基于這些豐富的數(shù)據(jù)類型和它的單線程等特性，也賦予了 Redis 除緩存數(shù)據(jù)外的多種能力。

1.分布式鎖。我們可以使用 Redis 自帶的 SETNX 命令來實(shí)現(xiàn)分布式鎖，當(dāng)然，生產(chǎn)場(chǎng)景中我們還是更推薦使用 Redisson 框架來幫我們實(shí)現(xiàn)分布式鎖的功能。 2.分布式ID。利用 Redis 原子性的自增命令，可以考慮作為應(yīng)用程序的分布式ID來使用。如果獲取分布式ID 比較頻繁，我們可以每次請(qǐng)求設(shè)置一個(gè)合適的步長(zhǎng)，比如 2000（一次取2000個(gè)連續(xù)的ID），然后緩存在本地。 3. 分布式Session。我們可以使用Redis 中提供的 String 數(shù)據(jù)類型或者 Hash 數(shù)據(jù)類型來保存 Session 數(shù)據(jù)，從而實(shí)現(xiàn)分布式環(huán)境下 Session 會(huì)話的同步。 4. 分布式限流。比如我們可以基于 Redis 的 SETNX命令可以實(shí)現(xiàn)計(jì)數(shù)器算法限流；基于 Redis 的 ZSet 數(shù)據(jù)結(jié)構(gòu)可以實(shí)現(xiàn)滑動(dòng)窗口算法限流；基于 Redis 的 List 數(shù)據(jù)結(jié)構(gòu)可以實(shí)現(xiàn)令牌桶算法限流；當(dāng)然，我們還可以基于Redis +Lua 腳本的方式實(shí)現(xiàn)分布式限流。限流算法簡(jiǎn)介。 5. 消息隊(duì)列。如果是中小型項(xiàng)目，業(yè)務(wù)量不是很大，對(duì)于數(shù)據(jù)丟失不敏感，且項(xiàng)目中已經(jīng)使用了中間件 Redis，同時(shí)又需要消息中間件功能的情況下，可以考慮使用 Redis 的Stream 來實(shí)現(xiàn)消息隊(duì)列的功能。但是如果并發(fā)量很高，資源又足夠支持的情況下，還是強(qiáng)烈建議使用更專業(yè)的消息中間件，比如 RocketMQ、Kafka 等。 6. 抽獎(jiǎng)。Redis 中提供的 Set 數(shù)據(jù)類型，可以很輕松的實(shí)現(xiàn)模擬抽獎(jiǎng)的功能。存儲(chǔ)某活動(dòng)中中獎(jiǎng)的用戶名 ，Set 類型因?yàn)橛腥ブ毓δ?，可以保證同一個(gè)用戶不會(huì)中獎(jiǎng)兩次。 7. 地理位置應(yīng)用。Redis 中提供的GEO 數(shù)據(jù)類型，可以很輕松的實(shí)現(xiàn)附近的人等查詢功能。 8. 海量數(shù)據(jù)統(tǒng)計(jì)。Redis 中提供的 BitMap 的數(shù)據(jù)類型，可以用來很方便的做海量數(shù)據(jù)的統(tǒng)計(jì)。還記得騰訊三面中被問到的那道經(jīng)典的面試題嗎：限制1個(gè)G的內(nèi)存，40億的QQ號(hào)如何實(shí)現(xiàn)快速去重！這道面試題就可以使用 BitMap 來解決！ 9.排行榜。Redis 中提供的 ZSet 數(shù)據(jù)類型，可以很輕松的實(shí)現(xiàn)排行榜等查詢功能，比如經(jīng)典的 TOP 10問題。 10. 關(guān)注模型。Redis 中提供的 Set 數(shù)據(jù)類型，可以很輕松的實(shí)現(xiàn)共同關(guān)注、我關(guān)注的人也關(guān)注他、我可能認(rèn)識(shí)的人等關(guān)注模型的查詢功能。（Set 類型支持交集運(yùn)算，set的查找也是O(1)，所以效率高，總的時(shí)間復(fù)雜度會(huì)更接近于O(min(M, N))， 而不是O(MN))。

Redis是AP還是CP的？

CAP 理論是針對(duì)分布式環(huán)境而言的，其中C代表一致性（Consistency），A 代表可用性（Availability），P 代表分區(qū)容錯(cuò)性（Partition tolerance）；CAP 理論簡(jiǎn)單來說就是C、A、P 三者不能同時(shí)滿足，最多只能滿足其中2個(gè)。一般來說，分布式環(huán)境下，分區(qū)容錯(cuò)性P是一定要滿足的，所以，我們通常所使用的第三方組件都是在CP 和AP之間進(jìn)行選擇。

這個(gè)問題網(wǎng)上流行的說法是，單機(jī)的Redis是CP的，集群Redis是AP的，這種說法其實(shí)不對(duì)，因?yàn)镃AP本身就是針對(duì)分布式環(huán)境的，單機(jī)環(huán)境壓根也沒有AP、CP一說

所以，我們所討論的「Redis 是AP的還是CP的」這個(gè)問題的前提是針對(duì)分布式環(huán)境而言的！在分布式環(huán)境下，Redis 是AP 的，它的一致性模型采用的是最終一致性。其實(shí)，這也不難理解，說 Redis 是AP 的原因是 Redis 提供的哨兵和 Cluster 的集群模式能夠很好的保證系統(tǒng)的可用性和容錯(cuò)性；而 Redis 無法保證強(qiáng)一致性的原因主要有以下兩點(diǎn)： 1.Redis 集群的主從節(jié)點(diǎn)之間采用的異步復(fù)制的策略。既然是異步復(fù)制，在數(shù)據(jù)傳輸過程中，就有可能存在網(wǎng)絡(luò)延遲等原因而導(dǎo)致主從節(jié)點(diǎn)之間的數(shù)據(jù)不一致。 2.數(shù)據(jù)一致性可能會(huì)受到主節(jié)點(diǎn)故障的影響。假如主節(jié)點(diǎn)突然宕機(jī)，瞬時(shí)產(chǎn)生的數(shù)據(jù)是無法同步到其他從節(jié)點(diǎn)的，即使集群故障轉(zhuǎn)移后，主節(jié)點(diǎn)網(wǎng)絡(luò)恢復(fù)，它也只是會(huì)以從節(jié)點(diǎn)的身份重新加入該集群，在與新的主節(jié)點(diǎn)做全量數(shù)據(jù)同步時(shí)，會(huì)首先清空全部數(shù)據(jù)，從而丟失掉了那瞬時(shí)產(chǎn)生的數(shù)據(jù)。

如果是單機(jī)的reids不會(huì)面臨CAP理論中的權(quán)衡問題，因?yàn)樗举|(zhì)上是一個(gè)單一的、直接可控的數(shù)據(jù)存儲(chǔ)實(shí)例。在這種情境下，Redis可以同時(shí)提供較強(qiáng)的一致性和高可用性，接近于滿足CAP的所有條件，但這主要是因?yàn)閱吸c(diǎn)系統(tǒng)不涉及分布式系統(tǒng)中必須考慮的網(wǎng)絡(luò)分區(qū)容錯(cuò)（P）問題。但是也不能完全保證數(shù)據(jù)不丟失，除非將AOF策略設(shè)置為always，而不是everysec(每秒)，但是這個(gè)時(shí)候也相當(dāng)于喪失了一部分可用性，性能會(huì)變差。

Key沖突

什么是key沖突 所謂 Redis 的并發(fā)競(jìng)爭(zhēng) Key 的問題也就是多個(gè)系統(tǒng)同時(shí)對(duì)一個(gè) key進(jìn)行操作，但是最后執(zhí)行的順序和我們期望的順序不同，這樣也就導(dǎo)致了結(jié)果的不同?。ǘ鄠€(gè)客戶端操作同一個(gè)Key） 比如，有ABC三個(gè)系統(tǒng)A系統(tǒng)要把變量a賦值為1；B系統(tǒng)要把變量a賦值為2；C系統(tǒng)要把變量a賦值為3； 本來我們期望順序執(zhí)行A>B>C后，a的值為3，但是如果并發(fā)太大，導(dǎo)致A晚了一步，讓BC先執(zhí)行了，最后a的值就成1了；

柚子快報(bào)邀請(qǐng)碼778899分享：數(shù)據(jù)庫 Redis復(fù)習(xí)總結(jié)

http://yzkb.51969.com/

推薦鏈接