Redis持久化之大數據服務暫停問題

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

對這兩種方式的官方文檔的翻譯請看：

http://latteye.com/2011/11/redis-persistence.html

 

RDB就是快照存儲，比如“每1個小時對redis進行快照存儲”。那么，

save這個參數就應該設置

save 3600 1000   //前一次快照3600秒后，當有超過1000個key被改動的時候就進行一次快照更新

RDB快照產生dump.rdb文件，當每到快照時間，更新文件。

AOF是存儲所有的寫操作，分兩個步驟：

fsync和rewrite

fsync是把內存中的寫操作寫入aof文件中

rewrite是將寫操作合並，比如set aa 1; set aa 2; 兩個操作應該寫成一個操作set aa 2;

如果數據量小的話，啥問題也沒有

現在假設服務器是20G內存，而且服務器上僅僅只有跑redis一個占內存的進程，就是說redis最多可以跑20G物理內存

現在壓入13G的redis數據（可以使用phpredis循環壓入，但是要注意設置php的運行內存大小，最好使用pipeline的方式，否則php出現內存不足的error）

嘗試1，我們只使用RDB的方式

當進行快照的時候（測試時候可以把快照間隔時間定成30秒或更短）

top查看進程

26376 test 16 0 13.5g 13g 7488 D 0.0 42.8 6:48.24 redis-server

32459 test 18 0 13.5g 13g 7200 D 1.3 42.8 0:23.22 redis-server

 

看到有兩個進程，同時在運行，並且占用同樣大小的內存數，和起來竟然占用26G之大~！

現在redis服務端上兩個進程都運行，看看客戶端：

測試redis-cli set操作：

redis 10.1.0.108:6379> set test2 22

耗時(40.47s)近1分鍾

 

就是說在大數據量的時候，做RDB，redis服務會暫停近1分鍾！這個就是redis持久化的時候的服務暫停現象。

 

好吧，為了保證數據容錯性，我們的快照一般是要頻繁快照的，所以暫停一分鍾是不可容忍的。

 

現在嘗試使用AOF+RDB：

1 將RDB的快照時間設置為1天（由於加上了AOF，所以這個時間是合理的）。

2 1次性壓入1000w左右的string數據到redis中（大概有5G數據量）

3 查看性能表現：

第一個步驟fsync：

redis會從內存中逐漸生成appendonly.aof  在這個過程我試了下set和get操作都是沒有暫停現象的（很好~！）

好了，現在appendonly.aof生成了，有5.7個G

-rw-r--r-- 1 root root 4186238374 Mar 6 15:50 appendonly.aof

 

第二個步驟：調用BGREWRITEAOF重寫aof文件

這個時候top查看：

看到也是兩個redis-server服務開着。說明rewrite的時候是fork一個子進程在rewrite的，主進程是進行着redis服務的。

這個時候redis-cli調用檢查

get操作：無延時

set操作：出現了延遲現象 ！！

  

這個說明AOF在重寫的時候會占用服務器的大量CPU和內存資源，導致服務出現短暫暫停現象！

但是為什么get操作沒有出現延遲現象呢？

參考官網文章，看到一個配置項：

no-appendfsync-on-rewrite

這個配置項是設置在rewrite的時候是否對新的寫操作進行fsync。no表示進行fsync，yes表示不進行

默認是設置為no

 

現在將這個配置項設置為yes（我們對於rewrite的aof文件硬盤大小沒有很大要求）

重新進行測試：

對同樣的5.7G的AOF操作進行一次BGREWRITEAOF。

get操作：無延遲

set操作：無延遲

 

很好！說明在rewrite的時候如果不進行fsync操作，主進程和子進程是互不干擾的。

 

那么如果rewrite的時候對新的寫操作不進行fsync，那么新的aof文件里面是否會丟失這個寫操作呢？

答案是不會的，redis會將新的寫操作放在內存中，等待rewrite操作完成的時候，將新操作直接掛在aof中。

 

好了，至此，這個問題應該已經可以過去了。

 

推薦幾個文章：

對數據持久化的一些想法：http://www.yiihsia.com/2011/04/%E5%AF%B9redis%E6%95%B0%E6%8D%AE%E6%8C%81%E4%B9%85%E5%8C%96%E7%9A%84%E4%B8%80%E4%BA%9B%E6%83%B3%E6%B3%95/

（這個文章提供了一個非常好的方法，當數據量大，內存足夠的情況，一台機子上盡量多開幾個redis，甚至可以考慮有幾個cpu就開幾個redis，這樣，每個redis的內存量不會太大，就不會有大數據量服務暫停問題，這個也是考慮到了redis是單線程的，能盡量利用CPU）

redis的內存陷阱：http://www.iteye.com/topic/808293

（這個文章很好解釋了問什么大數據量的時候會出現服務暫停）

Copy on write does not seem to work.： http://code.google.com/p/redis/issues/detail?id=150

 

----------------------

作者：yjf512（軒脈刃）

出處：http://www.cnblogs.com/yjf512/

本文版權歸yjf512和cnBlog共有，歡迎轉載，但未經作者同意必須保留此段聲明