Redis學習筆記4--持久化機制與分區

1.定時快照方式(snapshot)：

該持久化方式實際是在Redis內部一個定時器事件，每隔固定時間去檢查當前數據發生的改變次數與時間是否知足配置的持久化觸發的條件，若是知足則經過操做系統fork調用來建立出一個子進程，這個子進程默認會與父進程共享相同的地址空間，這時就能夠經過子進程來遍歷整個內存來進行存儲操做，而主進程則仍然能夠提供服務，當有寫入時由操做系統按照內存頁(page)爲單位來進行copy-on-write保證父子進程之間不會互相影響。

該持久化的主要缺點是定時快照只是表明一段時間內的內存映像，因此係統重啓會丟失上次快照與重啓之間全部的數據。

2. 基於語句追加方式(aof)：

aof方式實際相似mysql的基於語句的binlog方式，即每條會使Redis內存數據發生改變的命令都會追加到一個log文件中，也就是說這個log文件就是Redis的持久化數據。

aof的方式的主要缺點是追加log文件可能致使體積過大，當系統重啓恢復數據時若是是aof的方式則加載數據會很是慢，幾十G的數據可能須要幾小 時才能加載完，固然這個耗時並非由於磁盤文件讀取速度慢，而是因爲讀取的全部命令都要在內存中執行一遍。另外因爲每條命令都要寫log,因此使用aof 的方式，Redis的讀寫性能也會有所降低。

3.虛擬內存方式：

虛擬內存方式是Redis來進行用戶空間的數據換入換出的一個策略，此種方式在實現的效果上比較差，主要問題是代碼複雜，重啓慢，複製慢等等.

4.diskstore方式：

diskstore方式是做者放棄了虛擬內存方式後選擇的一種新的實現方式，也就是傳統的B-tree的方式，目前仍在實驗階段，後續是否可用咱們能夠拭目以待。

5.持久化機制的選擇

 當業務不須要數據持久化時，固然關閉全部的持久化方式能夠得到最佳的性能以及最大內存的使用量；若是須要使用持久化，根據是否能夠容忍重啓丟失部分數據在快照方式與語句追加方式之間選擇其一，不要使用虛擬內存以及diskstore方式。目前來講，我的以爲選擇aof的方式是最佳的選擇。

難以取捨的持久化機制主要是快照和aof方式。相比於aof快照的特色是速度快，恢復的速度也快。可是宕機的時候丟失的數據相對多一點。

當aof和快照同時開啓的時候，數據恢復時會首先使用 aof的文件來恢復，恢復失敗的時候再去考慮快照。

 

redis 分區

分區是分割數據到多個Redis實例的處理過程，所以每一個實例只保存key的一個子集。

1）分區的優點

經過利用多臺計算機內存的和值，容許咱們構造更大的數據庫。

經過多核和多臺計算機，容許咱們擴展計算能力；經過多臺計算機和網絡適配器，容許咱們擴展網絡帶寬。

2) 分區的不足

redis的一些特性在分區方面表現的不是很好：

涉及多個key的操做一般是不被支持的。舉例來講，當兩個set映射到不一樣的redis實例上時，你就不能對這兩個set執行交集操做。

涉及多個key的redis事務不能使用。

當使用分區時，數據處理較爲複雜，好比你須要處理多個rdb/aof文件，而且從多個實例和主機備份持久化文件。

增長或刪除容量也比較複雜。redis集羣大多數支持在運行時增長、刪除節點的透明數據平衡的能力，可是相似於客戶端分區、代理等其餘系統則不支持這項特性。然而，一種叫作presharding的技術對此是有幫助的。

3）分區類型

Redis 有兩種類型分區。假設有4個Redis實例 R0，R1，R2，R3，和相似user:1，user:2這樣的表示用戶的多個key，對既定的key有多種不一樣方式來選擇這個key存放在哪一個實例中。也就是說，有不一樣的系統來映射某個key到某個Redis服務。

1.範圍分區

最簡單的分區方式是按範圍分區，就是映射必定範圍的對象到特定的Redis實例。好比，ID從0到10000的用戶會保存到實例R0，ID從10001到 20000的用戶會保存到R1，以此類推。這種方式是可行的，而且在實際中使用，不足就是要有一個區間範圍到實例的映射表。這個表要被管理，同時還須要各類對象的映射表，一般對Redis來講並不是是好的方法。

2.哈希分區

另一種分區方法是hash分區。這對任何key都適用，也無需是object_name:這種形式，像這樣：用一個hash函數將key轉換爲一個數字，好比使用crc32 hash函數。對key foobar執行crc32(foobar)會輸出相似93024922的整數。 對這個整數取模，將其轉化爲0-3之間的數字，就能夠將這個整數映射到4個Redis實例中的一個了。93024922 % 4 = 2，就是說key foobar應該被存到R2實例中。注意：取模操做是取除的餘數，一般在多種編程語言中用%操做符實現。