redis存儲引擎

1. 三分鍾讀懂redis資料庫

redis是一個key-value存儲系統。和Memcached類似，它支持存儲的value類型相對更多，包括string(字元串)、list(鏈表)、set(集合)、zset(sorted set --有序集合)和hash（哈希類型）。這些數據類型都支持push/pop、add/remove及取交集並集和差集及更豐富的操作，而且這些操作都是原子性的。在此基礎上，redis支持各種不同方式的排序。與memcached一樣，為了保證效率，數據都是緩存在內存中。區別的是redis會周期性的把更新的數據寫入磁碟或者把修改操作寫入追加的記錄文件，並且在此基礎上實現了master-slave(主從)同步。

1. 使用Redis有哪些好處？

(1) 速度快，因為數據存在內存中，類似於HashMap，HashMap的優勢就是查找和操作的時間復雜度都是O(1)

(2) 支持豐富數據類型，支持string，list，set，sorted set，hash

(3) 支持事務，操作都是原子性，所謂的原子性就是對數據的更改要麼全部執行，要麼全部不執行

(4) 豐富的特性：可用於緩存，消息，按key設置過期時間，過期後將會自動刪除

2. redis相比memcached有哪些優勢？

(1) memcached所有的值均是簡單的字元串，redis作為其替代者，支持更為豐富的數據類型

(2) redis的速度比memcached快很多

(3) redis可以持久化其數據

3. redis常見性能問題和解決方案：

(1) Master最好不要做任何持久化工作，如RDB內存快照和AOF日誌文件

(2) 如果數據比較重要，某個Slave開啟AOF備份數據，策略設置為每秒同步一次

(3) 為了主從復制的速度和連接的穩定性，Master和Slave最好在同一個區域網內

(4) 盡量避免在壓力很大的主庫上增加從庫

(5) 主從復制不要用圖狀結構，用單向鏈表結構更為穩定，即：Master <- Slave1 <- Slave2 <- Slave3...

這樣的結構方便解決單點故障問題，實現Slave對Master的替換。如果Master掛了，可以立刻啟用Slave1做Master，其他不變。

4. Mysql里有2000w數據，redis中只存20w的數據，如何保證redis中的數據都是熱點數據

相關知識：redis 內存數據集大小上升到一定大小的時候，就會施行數據淘汰策略。redis 提供 6種數據淘汰策略：

voltile-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（驅逐）：禁止驅逐數據

相關推薦：《Python視頻教程》

5. Memcache與Redis的區別都有哪些？

1)、存儲方式

Memecache把數據全部存在內存之中，斷電後會掛掉，數據不能超過內存大小。

Redis有部份存在硬碟上，這樣能保證數據的持久性。

2)、數據支持類型

Memcache對數據類型支持相對簡單。

Redis有復雜的數據類型。

3），value大小

redis最大可以達到1GB，而memcache只有1MB

6. Redis 常見的性能問題都有哪些？如何解決？

1).Master寫內存快照，save命令調度rdbSave函數，會阻塞主線程的工作，當快照比較大時對性能影響是非常大的，會間斷性暫停服務，所以Master最好不要寫內存快照。

2).Master AOF持久化，如果不重寫AOF文件，這個持久化方式對性能的影響是最小的，但是AOF文件會不斷增大，AOF文件過大會影響Master重啟的恢復速度。Master最好不要做任何持久化工作，包括內存快照和AOF日誌文件，特別是不要啟用內存快照做持久化,如果數據比較關鍵，某個Slave開啟AOF備份數據，策略為每秒同步一次。

3).Master調用BGREWRITEAOF重寫AOF文件，AOF在重寫的時候會佔大量的CPU和內存資源，導致服務load過高，出現短暫服務暫停現象。

4). Redis主從復制的性能問題，為了主從復制的速度和連接的穩定性，Slave和Master最好在同一個區域網內

7. redis 最適合的場景

Redis最適合所有數據in-momory的場景，雖然Redis也提供持久化功能，但實際更多的是一個disk-backed的功能，跟傳統意義上的持久化有比較大的差別，那麼可能大家就會有疑問，似乎Redis更像一個加強版的Memcached，那麼何時使用Memcached,何時使用Redis呢?

如果簡單地比較Redis與Memcached的區別，大多數都會得到以下觀點：

1.Redis不僅僅支持簡單的k/v類型的數據，同時還提供list，set，zset，hash等數據結構的存儲。

2.Redis支持數據的備份，即master-slave模式的數據備份。

3.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的發布/訂閱功能來建立聊天系統！（不，這是真的，你可以去核實）。

2. redis主要解決什麼問題

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，你可以從這里去查看。
排行榜/計數器
Redis在內存中對數字進行遞增或遞減的操作實現的非常好。集合（Set）和有序集合（Sorted Set）也使得我們在執行這些操作的時候變的非常簡單，Redis只是正好提供了這兩種數據結構。所以，我們要從排序集合中獲取到排名最靠前的10個用戶–我們稱之為「user_scores」，我們只需要像下面一樣執行即可：
當然，這是假定你是根據你用戶的分數做遞增的排序。如果你想返回用戶及用戶的分數，你需要這樣執行：
ZRANGE user_scores 0 10 WITHSCORES
Agora Games就是一個很好的例子，用Ruby實現的，它的排行榜就是使用Redis來存儲數據的，你可以在這里看到。
5、發布/訂閱
最後（但肯定不是最不重要的）是Redis的發布/訂閱功能。發布/訂閱的使用場景確實非常多。我已看見人們在社交網路連接中使用，還可作為基於發布/訂閱的腳本觸發器，甚至用Redis的發布/訂閱功能來建立聊天系統！（不，這是真的，你可以去核實）。
Redis提供的所有特性中，我感覺這個是喜歡的人最少的一個，雖然它為用戶提供如果此多功能。
等等？

3. 資料庫老師會問哪些問題

1.MySQL 主鍵與索引的聯系與區別

主鍵是為了標識資料庫記錄唯一性，不允許記錄重復，且鍵值不能為空，主鍵也是一個特殊索引。

數據表中只允許有一個主鍵，但是可以有多個索引。

使用主鍵會資料庫會自動創建主索引，也可以在非主鍵上創建索引，方便查詢效率。

索引可以提高查詢速度，它就相當於字典的目錄，可以通過它很快查詢到想要的結果，而不需要進行全表掃描。

主鍵索引外索引的值可以為空。

主鍵也可以由多個欄位組成，組成復合主鍵，同時主鍵肯定也是唯一索引。

唯一索引則表示該索引值唯一，可以由一個或幾個欄位組成，一個表可以有多個唯一索引。

2.資料庫索引是怎麼回事？用的啥數據結構 為什麼B+樹比B樹更合適

一個索引是存儲的表中一個特定列的值數據結構（最常見的是B-Tree）。索引是在表的列上創建。所以，要記住的關鍵點是索引包含一個表中列的值，並且這些值存儲在一個數據結構中。請記住記住這一點：索引是一種數據結構 。

什麼樣的數據結構可以作為索引？

B-Tree 是最常用的用於索引的數據結構。因為它們是時間復雜度低， 查找、刪除、插入操作都可以可以在對數時間內完成。另外一個重要原因存儲在B-Tree中的數據是有序的。資料庫管理系統（RDBMS）通常決定索引應該用哪些數據結構。但是，在某些情況下，你在創建索引時可以指定索引要使用的數據結構。

當我們利用索引查詢的時候，不可能把整個索引全部載入到內存，只能逐一載入每個磁碟頁，磁碟頁對應索引樹的節點。那麼Mysql衡量查詢效率的標准就是磁碟IO次數。如果我們利用二叉樹作為索引結構，那麼磁碟的IO次數和索引樹的高度是相關的。

那麼為了提高查詢效率，就需要減少磁碟IO數。為了減少磁碟IO的次數，就需要盡量降低樹的高度，需要把原來「瘦高」的樹結構變的「矮胖」，樹的每層的分叉越多越好，因此B樹正好符合我們的要求，這也是B-樹的特徵之一。

B樹 B樹的節點為關鍵字和相應的數據（索引等）

B+樹 B+樹是B樹的一個變形，非葉子節點只保存索引，不保存實際的數據，數據都保存在葉子節點中，B+樹的葉子節點為鏈表，鏈表放數據，非葉子節點是索引。

對比：

• B樹和B+樹同樣適用於高度越低，查詢越快。

• B樹查找節點，B+樹只需要查詢所有節點（索引），B樹查詢索引和數據。雖然可能第一個就找到，但在極端情況下，需要全查詢索引和數據，不如B+樹穩定。

• B+樹和B樹比，B+樹的硬碟空間更少，io的讀寫代價更低。因為B+樹節點只有索引，佔位更少。在查詢的情況下硬碟指針移動更低

哈希表索引是怎麼工作的？

哈希表是另外一種你可能看到用作索引的數據結構-這些索引通常被稱為哈希索引。使用哈希索引的原因是，在尋找值時哈希表效率極高。所以，如果使用哈希索引，對於比較字元串是否相等的查詢能夠極快的檢索出的值。例如之前我們討論過的這個查詢(SELECT * FROM Employee WHERE Employee_Name = 『Jesus』) 就可以受益於創建在Employee_Name 列上的哈希索引。哈系索引的工作方式是將列的值作為索引的鍵值（key），和鍵值相對應實際的值（value）是指向該表中相應行的指針。因為哈希表基本上可以看作是關聯數組，一個典型的數據項就像「Jesus => 0x28939″，而0x28939是對內存中表中包含Jesus這一行的引用。在哈系索引的中查詢一個像「Jesus」這樣的值，並得到對應行的在內存中的引用，明顯要比掃描全表獲得值為「Jesus」的行的方式快很多。

哈希索引的缺點

哈希表是無順的數據結構，對於很多類型的查詢語句哈希索引都無能為力。舉例來說，假如你想要找出所有小於40歲的員工。你怎麼使用使用哈希索引進行查詢？這不可行，因為哈希表只適合查詢鍵值對-也就是說查詢相等的查詢（例：like 「WHERE name = 『Jesus』）。哈希表的鍵值映射也暗示其鍵的存儲是無序的。這就是為什麼哈希索引通常不是資料庫索引的默認數據結構-因為在作為索引的數據結構時，其不像B-Tree那麼靈活

3.創建索引的注意事項

索引可以提高數據的訪問速度，但同時也增加了插入、更新和刪除操作的處理時間，解決此問題就是分析應用程序的業務處理、數據使用，為經常被用作查詢條件、或者被要求排序的欄位建立索引。索引是建立在資料庫表中的某些列的上面。因此，在創建索引的時候，應該仔細考慮在哪些列上可以創建索引，在哪些列上不能創建索引。

創建規則：

• 表的主鍵、外鍵必須有索引；

• 數據量超過300的表應該有索引；

• 經常與其他表進行連接的表，在連接欄位上應該建立索引；

• 經常出現在Where子句中的欄位，特別是大表的欄位，應該建立索引；

• 索引應該建在選擇性高的欄位上；

• 索引應該建在小欄位上，對於大的文本欄位甚至超長欄位，不要建索引；

• 復合索引的建立需要進行仔細分析；盡量考慮用單欄位索引代替

• 頻繁進行數據操作的表，不要建立太多的索引；

• 刪除無用的索引，避免對執行計劃造成負面影響；

創建索引需要注意的地方：

• 限製表上的索引數目。對一個存在大量更新操作的表，所建索引的數目一般不要超過3個，最多不要超過5個。索引雖說提高了訪問速度，但太多索引會影響數據的更新操作。

• 避免在取值朝一個方向增長的欄位（例如：日期類型的欄位）上，建立索引；對復合索引，避免將這種類型的欄位放置在最前面

• 對復合索引，按照欄位在查詢條件中出現的頻度建立索引

• 刪除不再使用，或者很少被使用的索引。

4.MYSQL事務特性和實現原理

ACID表示原子性（atomicity）、一致性（consistency）、隔離性（isolation）和持久性（rability）。一個很好的事務處理系統，必須具備這些標准特性：

原子性（atomicity）

一個事務必須被視為一個不可分割的最小工作單元，整個事務中的所有操作要麼全部提交成功，要麼全部失敗回滾，對於一個事務來說，不可能只執行其中的一部分操作，這就是事務的原子性

是利用Innodb的undo log。undo log名為回滾日誌，是實現原子性的關鍵，當事務回滾時能夠撤銷所有已經成功執行的sql語句，他需要記錄你要回滾的相應日誌信息。

一致性（consistency）

資料庫總是從一個一致性的狀態轉換到另一個一致性的狀態。（在前面的例子中，一致性確保了，即使在執行第三、四條語句之間時系統崩潰，支票賬戶中也不會損失200美元，因為事務最終沒有提交，所以事務中所做的修改也不會保存到資料庫中。）

資料庫通過原子性、隔離性、持久性來保證一致性

隔離性（isolation）

通常來說，一個事務所做的修改在最終提交以前，對其他事務是不可見的。（在前面的例子中，當執行完第三條語句、第四條語句還未開始時，此時有另外的一個賬戶匯總程序開始運行，則其看到支票帳戶的余額並沒有被減去200美元。）

利用的是鎖和MVCC機制。MVCC,即多版本並發控制(Multi Version Concurrency Control),一個行記錄數據有多個版本對快照數據，這些快照數據在undo log中。如果一個事務讀取的行正在做DELELE或者UPDATE操作，讀取操作不會等行上的鎖釋放，而是讀取該行的快照版本。

持久性（rability）

一旦事務提交，則其所做的修改會永久保存到資料庫。（此時即使系統崩潰，修改的數據也不會丟失。持久性是個有占模糊的概念，因為實際上持久性也分很多不同的級別。有些持久性策略能夠提供非常強的安全保障，而有些則未必，而且不可能有能做到100%的持久性保證的策略。）

是利用Innodb的redo log。當做數據修改的時候，不僅在內存中操作，還會在redo log中記錄這次操作。當事務提交的時候，會將redo log日誌進行刷盤(redo log一部分在內存中，一部分在磁碟上)。當資料庫宕機重啟的時候，會將redo log中的內容恢復到資料庫中，再根據undo log和binlog內容決定回滾數據還是提交數據。redo log體積小，刷盤快。redo log是一直往末尾進行追加，屬於順序IO。效率顯然比隨機IO來的快

5.redis的原理和優點

redis是一個key-value存儲系統.和Memcached類似，它支持存儲的value類型相對更多，包括string(字元串)、list(鏈表)、set(集合)、zset(sorted set --有序集合)和hashs（哈希類型）

這些數據類型都支持push/pop、add/remove及取交集並集和差集及更豐富的操作，而且這些操作都是原子性的.

在此基礎上，redis支持各種不同方式的排序.與memcached一樣，為了保證效率，數據都是緩存在內存中.區別的是redis會周期性的把更新的數據寫入磁碟或者把修改操作寫入追加的記錄文件，並且在此基礎上實現了master-slave(主從)同步.

Redis的優點:

• 性能極高 – Redis能支持超過 100K+ 每秒的讀寫頻率。

• 豐富的數據類型 – Redis支持二進制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 數據類型操作。

• 原子 – Redis的所有操作都是原子性的，同時Redis還支持對幾個操作全並後的原子性執行。

• 豐富的特性 – Redis還支持 publish/subscribe, 通知, key 過期等等特性。

6.Mysql中的鎖機制

Mysql用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。這些鎖統稱為悲觀鎖

MySQL的鎖機制比較簡單，其最 顯著的特點是不同的存儲引擎支持不同的鎖機制。比如，MyISAM和MEMORY存儲引擎採用的是表級鎖（table-level locking）；BDB存儲引擎採用的是頁面鎖（page-level locking），但也支持表級鎖；InnoDB存儲引擎既支持行級鎖（row-level locking），也支持表級鎖，但默認情況下是採用行級鎖。

• 表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖沖突的概率最高，並發度最低。

• 行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖沖突的概率最低，並發度也最高。

• 頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，並發度一般

從上述特點可見，很難籠統地說哪種鎖更好，只能就具體應用的特點來說哪種鎖更合適！僅從鎖的角度 來說：表級鎖更適合於以查詢為主，只有少量按索引條件更新數據的應用，如Web應用；而行級鎖則更適合於有大量按索引條件並發更新少量不同數據，同時又有 並發查詢的應用，如一些在線事務處理（OLTP）系統。

7.ABC聯合索引生效問題

對於復合索引：Mysql從左到右的使用索引中的欄位，一個查詢可以只使用索引中的一部份，但只能是最左側部分。例如索引是key index （a,b,c）。 可以支持a | a,b| a,b,c 3種組合進行查找，但不支持 b,c進行查找 .當最左側欄位是常量引用時，索引就十分有效。

對於復合索引：Mysql從左到右的使用索引中的欄位，一個查詢可以只使用索引中的一部份，但只能是最左側部分。例如索引是key index （a,b,c）。 可以支持a | a,b| a,b,c 3種組合進行查找，但不支持 b,c進行查找 .當最左側欄位是常量引用時，索引就十分有效。

4. LevelDB 可以用來替換 Redis 做緩存嗎

可能很多人都不知道RedisStorage 和redis 之間的區別。

redis的存儲是存儲在內存里的, RedisStorage可以選擇存儲在磁碟里.
當redis崩潰的時候。redis 會從rdb或者aof文件重新讀取數據到內存里。如果數據量很大的話。這個初始化是相當的慢。(這就是 redis的假數據持久)。
RedisStorage 是直接存儲在 磁碟里。所以不存在這個數據重載入問題。

還有redis 存儲是受物理內存限制的，比如你有幾千萬或者幾億的數據。如果存儲在redis里。那得需要多巨大的內存了。使用RedisStorage 就沒有物理內存限制這個問題。最大可以存儲十億數據。

最後說一下淘寶的Tair ldb項目。同樣基於leveldb 存儲引擎。 廣泛的用在 登錄淘寶、查看商品詳情頁面、在淘江湖和好友「搗漿糊」等。 說明leveldb 數據引擎的可靠性和海量數據存儲。 但是開源版的Tair ldb 並不好用。所以自己寫了個基於 leveldb的 server端。

5. redis可以多key對應一個value嗎

redis可以多key對應一個value，設置方法為：

1、打開HBuilderX工具，新建web項目並在js文件夾中，創建一個js文件map.js。

6. redis怎麼實現資料庫的緩存

大致為兩種措施：

一、腳本同步：
1、自己寫腳本將資料庫數據寫入到redis/memcached。
2、這就涉及到實時數據變更的問題（mysql row binlog的實時分析），binlog增量訂閱Alibaba 的canal ，以及緩存層數據 丟失/失效 後的數據同步恢復問題。

二、業務層實現：
1、先讀取nosql緩存層，沒有數據再讀取mysql層，並寫入數據到nosql。
2、nosql層做好多節點分布式（一致性hash），以及節點失效後替代方案（多層hash尋找相鄰替代節點），和數據震盪恢復了。

7. redis適合什麼場景

1、緩存。 緩存現在幾乎是所有中大型網站都在用的必殺技，合理的利用緩存不僅能夠提升網站訪問速度，還能大大降低資料庫的壓力。Redis提供了鍵過期功能，也提供了靈活的鍵淘汰策略，所以，現在Redis用在緩存的場合非常多。（推薦：《 Redis視頻教程 》）
2、排行榜。 很多網站都有排行榜應用的，如京東的月度銷量榜單、商品按時間的上新排行榜等。Redis提供的有序集合數據類構能實現各種復雜的排行榜應用。
3、計數器。 什麼是計數器，如電商網站商品的瀏覽量、視頻網站視頻的播放數等。為了保證數據實時效，每次瀏覽都得給+1，並發量高時如果每次都請求資料庫操作無疑是種挑戰和壓力。Redis提供的incr命令來實現計數器功能，內存操作，性能非常好，非常適用於這些計數場景。
4、分布式會話。 集群模式下，在應用不多的情況下一般使用容器自帶的session復制功能就能滿足，當應用增多相對復雜的系統中，一般都會搭建以Redis等內存資料庫為中心的session服務，session不再由容器管理，而是由session服務及內存資料庫管理。
5、分布式鎖。 在很多互聯網公司中都使用了分布式技術，分布式技術帶來的技術挑戰是對同一個資源的並發訪問，如全局ID、減庫存、秒殺等場景，並發量不大的場景可以使用資料庫的悲觀鎖、樂觀鎖來實現，但在並發量高的場合中，利用資料庫鎖來控制資源的並發訪問是不太理想的，大大影響了資料庫的性能。可以利用Redis的setnx功能來編寫分布式的鎖，如果設置返回1說明獲取鎖成功，否則獲取鎖失敗，實際應用中要考慮的細節要更多。