redis總結（一）的持久化的取捨和選擇以及做用

1.redis持久化

   在客戶端發佈save的過程當中有可能形成阻塞，如一千萬條數據同時保存並生成二進制RDB文件的時候，此時就會延遲堵塞。

   文件策略是若是存在老的RDB文件，會用新的文件替代老的文件以下圖所示：

 

  對於bgsave而言，它會利用linux中的fork（）函數生成一個redis的子進程(fast的意思是相對來講速度比較快，可是當量大的時候依舊有可能阻塞主線程),而後再生成RDB文件，而且將成功生成的消息（bgsave successfully）返回告訴主進程，並響應客戶端以下圖所示：

 

 

 

5.save與bgsave的對比：所說的阻塞對比當量小的時候幾乎沒區別

 

6.若客戶端不發佈save的命令，redis也能夠進行保存的操做配置。不管是60秒發佈10000條，仍是300秒發佈10條，仍是900秒發佈一條信息都會進行更新保存並生成RDB文件。利用的就是bgsave來保存生成，（可是這種操做也有不合適的弊端，就是文件寫入過於頻繁，60秒就須要更新10000條）

　對於生成的RDB文件通常用dump.rdb的格式來保存。

　最佳配置：

　　：當保存出錯時是否中止寫入

       ：是否要壓縮文件，rdb文件會在主從之間進行拷貝，採用壓縮的形式能夠加快拷貝速度

　　 ：是否對rdb文件進行校驗檢驗

·　：文件名通常用端口號來區分

　　：通常狀況下不選用根目錄來保存，而是選擇大的硬盤路徑來保存

 總結RDB：

　　1耗性能，耗時（對全部數據進行dump，其次寫會消耗不少的cpu和內存（IO性能），是個on的過程（copy-on-write策略））

　　2不可控，丟失數據（定時保存或多或少會丟失一部分數據）

　　

AOF：

 　　AOF的三種策略：always，everysec，no

　　　　　　  always：寫的命令會進入到緩存區中，每條命令fsync到硬盤中生成AOF文件

　  　　　　　everysec：寫的命令會進入到緩存區中，每秒都會刷新fsync到硬盤中生成AOF文件（出現故障的時候有可能會丟失一秒的數據）

　 　　 　　　no：寫的命令會進入到緩存區中，會根據不一樣的系統來選擇寫入仍是不寫入，不須要人爲考慮，系統自動判斷

　　通常狀況下根據各方面權衡會默認選擇使用everysec的方案

　　

　　

　　7.當高併發或者時間推移日誌文件會變得冗餘，很消耗內存，此時能夠選擇使用AOF重寫，AOF重寫能夠減小硬盤的佔用量，加速恢復速度，

　　AOF重寫的兩種實現方式：

　　　　　　　　1.bgrewriteaof：和bgsave相似

 

　　　　　　　　2.AOF重寫配置

 

 

 

 　　配置：no-appendfsync-on-rewrite :是否關閉重寫

　　　　　。。。。perscentage 100：表示增加率

　　　　

 

 RDB和AOF的取捨：

         RDB：集中管理能夠一次性寫入大量，但不要太頻繁，由於對機器內存cpu等影響比較大，

 

　　AOF：建議一直開着，也體現出redis持久化的特色，等到必定時間能夠關閉，畢竟開緩存也須要必定的開銷

　　　　　　集中管理利用fork（），可是也有可能出現內存爆滿的狀況

  RDB：集中管理能夠一次性寫入大量，但不要太頻繁，由於對機器內存cpu等影響比較大，

 

 

最佳策略：小分片：利用redis進行內存分配，每一個內存分配最大4G，固然cpu的消耗也比較大