Redis:八、主從複製和虛擬記憶體

來源:互聯網
上載者:User

redis主從複製配置和使用都非常簡單。通過主從複製可以允許多個slave server擁有和master server相同的資料庫副本。下面是關於redis主從複製的一些特點

1.master可以有多個slave

2.除了多個slave連到相同的master外,slave也可以串連其他slave形成圖狀結構

3.主從複製不會阻塞master。也就是說當一個或多個slave與master進行初次同步資料時,master可以繼續處理client發來的請求。相反slave在初次同步資料時則會阻塞不能處理client的請求。

4.主從複製可以用來提高系統的延展性,我們可以用多個slave 專門用於client的讀請求,比如sort操作可以使用slave來處理。也可以用來做簡單的資料冗餘

5.可以在master禁用資料持久化,只需要注釋掉master 設定檔中的所有save配置,然後只在slave上配置資料持久化。

下面介紹下主從複製的過程

       當設定好slave伺服器後,slave會建立和master的串連,然後發送sync命令。無論是第一次同步建立的串連還是串連斷開後的重新連 接,master都會啟動一個後台進程,將資料庫快照集儲存到檔案中,同時master主進程會開始收集新的寫命令並緩衝起來。後台進程完成寫檔案 後,master就傳送檔案給slave,slave將檔案儲存到磁碟上,然後載入到記憶體恢複資料庫快照集到slave上。接著master就會把緩衝的命 令轉寄給slave。而且後續master收到的寫命令都會通過開始建立的串連發送給slave。從master到slave的同步資料的命令和從
client發送的命令使用相同的協議格式。當master和slave的串連斷開時slave可以自動重建立立串連。如果master同時收到多個 slave發來的同步串連命令,只會使用啟動一個進程來寫資料庫鏡像,然後發送給所有slave。

配置slave伺服器很簡單,只需要在設定檔中加入如下配置

slaveof 192.168.1.1 6379  #指定master的ip和連接埠


虛擬記憶體:

首先說明下redis的虛擬記憶體與os的虛擬記憶體不是一碼事,但是思路和目的都是相同的。就是暫時把不經常訪問的資料從記憶體交換到磁碟中,從而騰出寶貴的 記憶體空間用於其他需要訪問的資料。尤其是對於redis這樣的記憶體資料庫,記憶體總是不夠用的。除了可以將資料分割到多個redis server外。另外的能夠提高資料庫容量的辦法就是使用vm把那些不經常訪問的資料交換的磁碟上。如果我們的儲存的資料總是有少部分資料被經常訪問,大 部分資料很少被訪問,對於網站來說確實總是只有少量使用者經常活躍。當少量資料被經常訪問時,使用vm不但能提高單台redis
server資料庫的容量,而且也不會對效能造成太多影響。

        redis沒有使用os提供的虛擬記憶體機制而是自己在使用者態實現了自己的虛擬記憶體機制,作者在自己的blog專門解釋了其中原因。http://antirez.com/post/redis-virtual-memory-story.html

主要的理由有兩點

1.os 的虛擬記憶體是已4k頁面為最小單位進行交換的。而redis的大多數對象都遠小於4k,所以一個os頁面上可能有多個redis對象。另外redis的集 合物件類型如list,set可能存在與多個os頁面上。最終可能造成只有10%key被經常訪問,但是所有os頁面都會被os認為是活躍的,這樣只有內 存真正耗盡時os才會交換頁面。

2.相比於os的交換方式。redis可以將被交換到磁碟的對象進行壓縮,儲存到磁碟的對象可以去除指標和對象中繼資料資訊。一般壓縮後的對象會比記憶體中的對象小10倍。這樣redis的vm會比os vm能少做很多io操作。

下面是vm相關配置

vm-enabled yes                          #開啟vm功能

vm-swap-file /tmp/redis.swap                 #交換出來的value儲存的檔案路徑/tmp/redis.swap

vm-max-memory 1000000                    #redis使用的最大記憶體上限,超過上限後redis開始交換value到磁碟檔案中。

vm-page-size 32                    #每個頁面的大小32個位元組

vm-pages 134217728                 #最多使用在檔案中使用多少頁面,分頁檔的大小 = vm-page-size * vm-pages

vm-max-threads 4                    #用於執行value對象換入換出的背景工作執行緒數量。0表示不使用背景工作執行緒(後面介紹)

       redis的vm在設計上為了保證key的尋找速度,只會將value交換到swap檔案中。所以如果是記憶體問題是由於太多value很小的key造成 的,那麼vm並不能解決。和os一樣redis也是按頁面來交換對象的。redis規定同一個頁面只能儲存一個對象。但是一個對象可以儲存在多個頁面中。 在redis使用的記憶體沒超過vm-max-memory之前是不會交換任何value的。當超過最大記憶體限制後,redis會選擇較老的對象。如果兩個 對象一樣老會優先交換比較大的對象,精確的公式swappability
= age*log(size_in_memory)。 對於vm-page-size的設定應該根據自己的應用將頁面的大小設定為可以容納大多數對象的大小。太大了會浪費磁碟空間,太小了會造成分頁檔出現碎 片。對於分頁檔中的每個頁面,redis會在記憶體中對應一個1bit值來記錄頁面的空閑狀態。所以像上面配置中頁面數量(vm-pages 134217728 )會佔用16M記憶體用來記錄頁面空閑狀態。vm-max-threads表示用做交換任務的線程數量。如果大於0推薦設為伺服器的cpu core的數量。如果是0則交換過程在主線程進行。

參數配置討論完後,在來簡單介紹下vm是如何工作的,
當vm-max-threads設為0時(Blocking VM)

換出

主線程定期檢查發現記憶體超出最大上限後,會直接已阻塞的方式,將選中的對象儲存到swap檔案中,並釋放對象佔用的記憶體,此過程會一直重複直到下麵條件滿足

1.記憶體使用量降到最大限制以下

2.swap檔案滿了

3.幾乎全部的對象都被交換到磁碟了

換入

當有client請求value被換出的key時。主線程會以阻塞的方式從檔案中載入對應的value對象,載入時此時會阻塞所以client。然後處理client的請求
當vm-max-threads大於0(Threaded VM)

換出

當主線程檢測到使用記憶體超過最大上限,會將選中的要交換的對象資訊放到一個隊列中交由背景工作執行緒幕後處理,主線程會繼續處理client請求。

換入

如果有client請求的key被換出了,主線程先阻塞發出命令的client,然後將載入對象的資訊放到一個隊列中,讓背景工作執行緒去載入。載入完畢後背景工作執行緒通知主線程。主線程再執行client的命令。這種方式只阻塞請求value被換出key的client

總 的來說blocking vm的方式總的效能會好一些,因為不需要線程同步,建立線程和恢複被阻塞的client等開銷。但是也相應的犧牲了響應性。threaded vm的方式主線程不會阻塞在磁碟io上,所以響應性更好。如果我們的應用不太經常發生換入換出,而且也不太在意有點延遲的話則推薦使用blocking vm的方式。關於redis vm的更詳細介紹可以參考下面連結
http://antirez.com/post/redis-virtual-memory-story.html
http://redis.io/topics/internals-vm

from:http://www.cnblogs.com/xhan/archive/2011/02/07/1949717.html

redcreen

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在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.