redis最佳化優秀文選

來源:互聯網
上載者:User

標籤:

Redis是一個單線程的記憶體資料庫。如下:
http://download.redis.io/releases/redis-2.8.11.tar.gz
在Redis的src目錄運行make命令,然後將可執行檔複製到建立的bin目錄。可以使用如下的組織形式。


Redis持久化有兩種方式 RDB和AOF

1.RDB方式

RDB 持久化可以在指定的時間間隔內產生資料集的時間點快照(point-in-time snapshot)。

RDB 是一個非常緊湊(compact)的檔案,它儲存了 Redis 在某個時間點上的資料集。 這種檔案非常適合用於進行備份

RDB 非常適用於災難恢複(disaster recovery):它只有一個檔案,並且內容都非常緊湊

RDB 可以最大化 Redis 的效能:父進程在儲存 RDB 檔案時唯一要做的就是 fork 出一個子進程,然後這個子進程就會處理接下來的所有儲存工作,父進程無須執行任何磁碟 I/O 操作。

RDB 在恢複大資料集時的速度比 AOF 的恢複速度要快。

但是RDB方式在故障的時候,不能保證不遺失資料。


2.AOF方式

使用 AOF 持久化會讓 Redis 變得非常耐久(much more durable):可以設定不同的 fsync 策略,比如無 fsync ,每秒鐘一次 fsync ,或者每次執行寫入命令時 fsync 。 AOF 的預設策略為每秒鐘 fsync 一次,在這種配置下,Redis 仍然可以保持良好的效能,並且就算髮生故障停機,也最多隻會丟失一秒鐘的資料。

AOF 檔案是一個只進行追加操作的記錄檔(append only log), 因此對 AOF 檔案的寫入不需要進行 seek , 即使日誌因為某些原因而包含了未寫入完整的命令(比如寫入時磁碟已滿,寫入中途停機,等等), redis-check-aof 工具也可以輕易地修複這種問題。

Redis 可以在 AOF 檔案體積變得過大時,自動地在後台對 AOF 進行重寫: 重寫後的新 AOF 檔案包含了恢複當前資料集所需的最小命令集合。 整個重寫操作是絕對安全的,因為 Redis 在建立新 AOF 檔案的過程中,會繼續將命令追加到現有的 AOF 檔案裡面,即使重寫過程中發生停機,現有的 AOF 檔案也不會丟失。 而一旦新 AOF 檔案建立完畢,Redis 就會從舊 AOF 檔案切換到新 AOF 檔案,並開始對新 AOF 檔案進行追加操作。

AOF 檔案有序地儲存了對資料庫執行的所有寫入操作, 這些寫入操作以 Redis 協議的格式儲存, 因此 AOF 檔案的內容非常容易被人讀懂, 對檔案進行分析(parse)也很輕鬆。 匯出(export) AOF 檔案也非常簡單: 舉個例子, 如果你不小心執行了 FLUSHALL 命令, 但只要 AOF 檔案未被重寫, 那麼只要停止伺服器, 移除 AOF 檔案末尾的 FLUSHALL 命令, 並重啟 Redis , 就可以將資料集恢複到 FLUSHALL 執行之前的狀態。

 

AOF的缺點是體積通常比RDB檔案大。故障恢複的時間也比RDB方式長。

如果開啟每次寫入都記錄日誌,而不是每秒記錄一次日誌,效能會有所下降。但是如果採用每秒寫入,一旦故障會丟失最後一秒的資料。

 

可以通過下面的程式進行簡單的測試。


設定Redis參數為appendfsync everysec

寫入20w資料需要大概4s



設定Redis參數為appendfsync always

寫入同樣的20W資料,則需要400s左右



如果要保障資料絕對的安全,則寫入的效能會降低100倍。

如果是寫入密集的系統,則需要謹慎的考慮。因為Redis是單線程的程式。


3.RDB遷移到AOF

RDB是Redis預設的持久化方式。

實驗假設程式運行在RDB方式,並且有一定的資料。需要切換到AOF方式。


初始化運行在RDB方式的Redis,配置參數如下:



登陸Redis,輸入config set appendonly yes.

這樣就開啟了 AOF 功能: Redis 會阻塞直到初始 AOF 檔案建立完成為止, 之後 Redis 會繼續處理命令請求, 並開始將寫入命令追加到 AOF 檔案末尾。




通過可以看到,AOF檔案大於RDB的檔案。

    

在設定檔中追加AOF的設定,否則下次啟動就失效了。


如果啟動了AOF方式,就可以關閉RDB方式了。

關閉的方法如下,將save的配置清空,並刪除設定檔中的配置


將RDB遷移到AOF千萬不能採用如下的方式,這樣會丟失所有的資料

  1. 在設定檔中配置AOF參數

  1. 正常停止Redis

  1. 啟動Redis

  1. 會震驚的發現 資料全沒了


驗證過程如下

開始的時候使用RDB方式,有20W資料。



修改設定檔,增加AOF配置

appendonly yes

appendfilename appendonly.aof

appendfsync always

然後正常關閉Redis


可以看到RDB的檔案大小為2M

啟動Redis。可以看到所有的資料庫資料都被清空了。


這個時候千萬別慌,mv dump.rdb到備份位置。

如果再次順利關機,就悲劇了。


順利關機之後,發現Redis dump.rdb已經被清空了。

造成這種情況我猜測是因為Redis啟動的時候AOF優先於RDB,但是首次使用AOF裡面還沒有任何資料.
此時如果關閉Redis,則會將沒有資料的redis 快照到dump.rdb,並且覆蓋了原來有資料的dump.rdb檔案。
所以,將Redis從RDB方式改為AOF方式,一定要線上進行修改。這樣會將記憶體的資料先寫入AOF檔案,這樣就不會造成資料清空的問題。

相關文檔:

http://www.cnblogs.com/stephen-liu74/archive/2012/04/16/2370212.html
https://redis.readthedocs.org/en/latest/

http://blog.91gaoqing.com/archives/217.html  一致性雜湊

redis最佳化優秀文選

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.