Redis的相關問題總結

一、Redis的優缺點及適用場景

Redis 是一個基于內存的高性能key-value數據庫。很像memcached，整個數據庫統統加載在內存當中進行操作，定期通過異步操作把數據庫數據flush到硬盤上進行保存。它的優點如下：

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

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

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

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

Redis的主要缺點是數據庫容量受到物理內存的限制，不能用作海量數據的高性能讀寫，因此Redis適合的場景主要局限在較小數據量的高性能操作和運算上。

Redis最適合所有數據in-momory的場景，如：

（1）、會話緩存（Session Cache）

最常用的一種使用Redis的情景是會話緩存（session cache）。用Redis緩存會話比其他存儲（如Memcached）的優勢在于：Redis提供持久化。

（2）、全頁緩存（FPC）

除基本的會話token之外，Redis還提供很簡便的FPC平臺。回到一致性問題，即使重啟了Redis實例，因為有磁盤的持久化，用戶也不會看到頁面加載速度的下降，這是一個極大改進，類似PHP本地FPC。

（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的緩存失效策略和主鍵失效機制

作為緩存系統都要定期清理無效數據，就需要一個主鍵失效和淘汰策略.

在Redis當中，有生存期的key被稱為volatile。在創建緩存時，要為給定的key設置生存期，當key過期的時候（生存期為0），它可能會被刪除。

1、影響生存時間的一些操作

生存時間可以通過使用 DEL 命令來刪除整個 key 來移除，或者被 SET 和 GETSET 命令覆蓋原來的數據，也就是說，修改key對應的value和使用另外相同的key和value來覆蓋以后，當前數據的生存時間不同。

比如說，對一個 key 執行INCR命令，對一個列表進行LPUSH命令，或者對一個哈希表執行HSET命令，這類操作都不會修改 key 本身的生存時間。另一方面，如果使用RENAME對一個 key 進行改名，那么改名后的 key的生存時間和改名前一樣。

RENAME命令的另一種可能是，嘗試將一個帶生存時間的 key 改名成另一個帶生存時間的 another_key ，這時舊的 another_key (以及它的生存時間)會被刪除，然后舊的 key 會改名為 another_key ，因此，新的 another_key 的生存時間也和原本的 key 一樣。使用PERSIST命令可以在不刪除 key 的情況下，移除 key 的生存時間，讓 key 重新成為一個persistent key 。

2、如何更新生存時間

可以對一個已經帶有生存時間的 key 執行EXPIRE命令，新指定的生存時間會取代舊的生存時間。過期時間的精度已經被控制在1ms之內，主鍵失效的時間復雜度是O（1），

EXPIRE和TTL命令搭配使用，TTL可以查看key的當前生存時間。設置成功返回 1；當 key 不存在或者不能為 key 設置生存時間時，返回 0 。

最大緩存配置

在 redis 中，允許用戶設置最大使用內存大小

server.maxmemory

默認為0，沒有指定最大緩存，如果有新的數據添加，超過最大內存，則會使redis崩潰，所以一定要設置。redis 內存數據集大小上升到一定大小的時候，就會實行數據淘汰策略。

redis 提供 6種數據淘汰策略：

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

注意這里的6種機制，volatile和allkeys規定了是對已設置過期時間的數據集淘汰數據還是從全部數據集淘汰數據，后面的lru、ttl以及random是三種不同的淘汰策略，再加上一種no-enviction永不回收的策略。

使用策略規則：

1、如果數據呈現冪律分布，也就是一部分數據訪問頻率高，一部分數據訪問頻率低，則使用allkeys-lru

2、如果數據呈現平等分布，也就是所有的數據訪問頻率都相同，則使用allkeys-random

三種數據淘汰策略：

ttl和random比較容易理解，實現也會比較簡單。主要是Lru最近最少使用淘汰策略，設計上會對key 按失效時間排序，然后取最先失效的key進行淘汰

三、Redis是單進程單線程的，并發問題如何解決

Redis為單進程單線程模式，采用隊列模式將并發訪問變為串行訪問。Redis本身沒有鎖的概念，Redis對于多個客戶端連接并不存在競爭，但是在Jedis客戶端對Redis進行并發訪問時會發生連接超時、數據轉換錯誤、阻塞、客戶端關閉連接等問題，這些問題均是由于客戶端連接混亂造成。對此有2種解決方法：

1.客戶端角度，為保證每個客戶端間正常有序與Redis進行通信，對連接進行池化，同時對客戶端讀寫Redis操作采用內部鎖synchronized。

2.服務器角度，利用setnx實現鎖。

注：對于第一種，需要應用程序自己處理資源的同步，可以使用的方法比較通俗，可以使用synchronized也可以使用lock；第二種需要用到Redis的setnx命令，但是需要注意一些問題。

四、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最好在同一個局域網內。

五、redis持久化的幾種方式

1、快照（snapshots）

缺省情況情況下，Redis把數據快照存放在磁盤上的二進制文件中，文件名為dump.rdb。你可以配置Redis的持久化策略，例如數據集中每N秒鐘有超過M次更新，就將數據寫入磁盤；或者你可以手工調用命令SAVE或BGSAVE。

工作原理

． Redis forks.

． 子進程開始將數據寫到臨時RDB文件中。

． 當子進程完成寫RDB文件，用新文件替換老文件。

． 這種方式可以使Redis使用copy-on-write技術。

2、AOF

快照模式并不十分健壯，當系統停止，或者無意中Redis被kill掉，最后寫入Redis的數據就會丟失。這對某些應用也許不是大問題，但對于要求高可靠性的應用來說，

Redis就不是一個合適的選擇。

Append-only文件模式是另一種選擇。

你可以在配置文件中打開AOF模式

3、虛擬內存方式

當你的key很小而value很大時,使用VM的效果會比較好.因為這樣節約的內存比較大.

當你的key不小時,可以考慮使用一些非常方法將很大的key變成很大的value,比如你可以考慮將key,value組合成一個新的value.

vm-max-threads這個參數,可以設置訪問swap文件的線程數,設置最好不要超過機器的核數,如果設置為0,那么所有對swap文件的操作都是串行的.可能會造成比較長時間的延遲,但是對數據完整性有很好的保證.

Redis 數據庫

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。