?

redis目前對事務的支持比較簡單，只能保證一個客戶端連接發(fā)起事務中的命令可以連續(xù)執(zhí)行，而中間不會插入其他客戶端的命令。

1.事務

一般情況下，redis接收到一個客戶端發(fā)送的命令，立刻執(zhí)行并返回結(jié)果。但是當連接發(fā)出multi命令時，此連接便進入事務上下文，redis把此連接發(fā)送的命令保存到一個列隊當中，當此連接發(fā)送exec命令時，redis便開始按順序執(zhí)行列隊中的所有命令，并將所有命令執(zhí)行的結(jié)果大包一起返回給客戶端連接，然后此連接便結(jié)束事務。

例如：

例子中可以看出set 命令發(fā)出后并沒有立即執(zhí)行，而是存放在消息列隊中。調(diào)用exec命令，set命令才開始連續(xù)執(zhí)行，最后返回執(zhí)行結(jié)果。

如果取消事務，可以使用discard 命令取消一個事務例如：

?

discard命令的作用是清空事務列隊中的命令，并退出事務。

另外，redis只能保證事務的每個命令能夠連續(xù)執(zhí)行，但是事務中如果有命令執(zhí)行失敗，redis并不會回滾操作。

?2.持久化

redis 是基于內(nèi)存的數(shù)據(jù)庫，內(nèi)存數(shù)據(jù)庫有個嚴重的弊端：突然宕機或者斷電時，內(nèi)容的數(shù)據(jù)不會保存。為了解決這個問題，redis提供兩種持久化方式：內(nèi)存快照(snapshotting)和日志追加（append-only file）.

內(nèi)存快照方式是將內(nèi)存中的數(shù)據(jù)以快照的方式寫入二進制文件中，默認文件名為dump.rdb

redis每隔一段時間進行一次內(nèi)存快照操作，客戶端使用save或者bgsave命令告訴redis需要做一次快照操作。save命令在主線程中保存內(nèi)存快照，redis由單線程處理所有請求，執(zhí)行save命令肯可能阻塞其他客戶端請求，從而不能快速的相應請求，所以建議不要使用save命令。另外要注意，內(nèi)存快照每次都把數(shù)據(jù)完整的寫入到硬盤，而不是只寫入增量數(shù)據(jù)。所以如果數(shù)據(jù)量大，寫入操作比較頻繁，從而嚴重影響性能。

內(nèi)存快照相關(guān)配置：

save ?<seconds> ?<changes>

上面的配置表示經(jīng)過seconds秒或數(shù)據(jù)更改changes次進行一次快照操作。例如下面的配置

save 1000 1

表示 1000秒或者數(shù)據(jù)更改1次就進行快照。也可以設置多個方案

save 1000 1

save 300 39

save 19 1111

這樣，其中一個成立，redis就會進行快照。

如果使用?bgsave 進行快照 ? 只需要直接發(fā)送 ?bgsave 命令就可以了?

如果成功會返回

?

bgsave命令執(zhí)行之后立即返回?OK?，然后 Redis fork 出一個新子進程，原來的 Redis 進程(父進程)繼續(xù)處理客戶端請求，而子進程則負責將數(shù)據(jù)保存到磁盤，然后退出。

而save是直接調(diào)用主進程所以會引起阻塞.

日志追加（aof）方式是把增加，修改數(shù)據(jù)的命令通過write函數(shù)追加到文件尾部（默認是appendoly.aof）。redis重啟時讀取appendonly.aof文件中的所有命令并且執(zhí)行，從而把數(shù)據(jù)寫入內(nèi)容中。

另外，操作系統(tǒng)內(nèi)核的I/O接口可能存在緩存，所以日志追加方式不可能立即寫入文件中，這樣就有可能丟失部分數(shù)據(jù)。幸運的是redis提供了解決的方法，通過修改配置文件告訴redis應該在什么時候使用fsync函數(shù)強制操作系統(tǒng)把緩存寫入磁盤。有一下三種方法：

appendonly yes #啟動日志追加持久化方式（yes|no）

#appendfsync always #每次收到增加或者修改命令就立即強制寫入磁盤

appendfsync everysec #每秒強制寫入磁盤一次

#appendfync no#是否寫入磁盤完全依賴操作系統(tǒng)

日志追加方式有效降低數(shù)據(jù)丟失的風險，同時也帶來了另外一些問題，即持久化文件不斷變大。例如調(diào)用 incr nums 命令100次，文件就會保存100條incr nums 命令，其中99條是多余的，因為回復數(shù)據(jù)只需要set nums 100

為了壓縮日志文件，redis 提供bgrewriteaof命令。當redis收到此命令，就是用類似內(nèi)存快照方式將內(nèi)存的數(shù)據(jù)以命令的方式保存到臨時文件中，最后替換原來的日志文件。

3.主從同步

主從同步可以防止主機壞掉導致網(wǎng)站不能正常運行，這種方法即把從機設置為主機即可。redis支持主從同步，而且配置很簡單。redis主從同步的有點如下：

master（主）可以有多個slave（從）

多個slave連接到同一個master，slave還可以連接其他slave形成圖形結(jié)構(gòu)。

不會阻塞master。當一個或者多個slave與master初次同步數(shù)據(jù)時，master可以繼續(xù)處理客戶請求。相反，slave在初次同步數(shù)據(jù)時會阻塞而不能處理客戶端的請求（2.2以后不會阻塞）。

主從同步用來提高系統(tǒng)的伸縮性，比如多個slave專門用戶客戶端的讀請求。

在master服務器上禁止數(shù)據(jù)持久化，只在slave服務器上進行數(shù)據(jù)持久化。

?redis主從同步非常簡單，設置好slave（從）服務器后，slave自動和master建立連接，發(fā)送SYNC命令。無論是第一次同步建立的連接還是斷開后重新建立的連接，master都啟動一個后臺進程，將內(nèi)存數(shù)據(jù)以快照的形式寫入文件中，同時master主進程開始收集新的寫命令并且緩存起來。master后臺進程完成內(nèi)存快照后，把數(shù)據(jù)文件發(fā)給slave，slave將文件保存到磁盤上，然后把數(shù)據(jù)加載到內(nèi)存中。接著master把緩存命令發(fā)給slave，后續(xù)master收到的寫命令都通過開始建立的連接發(fā)送給slave，當master與slave斷開連接，slave自動重新建立連接。如果master同時收到多個slave發(fā)來的請求，其只啟動一個進程寫數(shù)據(jù)庫鏡像，然后發(fā)送給所有slave。

redis主從同步過程分為兩個階段，第一階段如下：

1.slave服務器主動連接到master服務器

2.slave服務器發(fā)送sycn命令到master服務器請求同步·

3.master服務器備份數(shù)據(jù)庫到rdb文件

4.master服務器把rdb文件傳輸給slave服務器

5。slave服務器清空數(shù)據(jù)庫數(shù)據(jù)，把rdb文件數(shù)據(jù)導入數(shù)據(jù)庫

完成第一個階段，接下來master服務器把用戶所有更改數(shù)據(jù)的操作，通過命令的形似轉(zhuǎn)發(fā)給slave服務器，slave服務器只需要執(zhí)行master服務器發(fā)送過來的命令就可以達到同步的效果。

相對于mysql來說，redis主從復制的配置很簡答，只需要在slave服務器配置文件下添加

slaveof ? master服務器ip：端口

例如：

slaveof 192.168.1.123：6379

4.虛擬內(nèi)存

redis的數(shù)據(jù)保存在內(nèi)存中，可能出現(xiàn)物理內(nèi)存不足的情況。物理內(nèi)存不足時，redis會使用虛擬內(nèi)存（VM）。

VM是redis2.0新加的功能，之前redis把數(shù)據(jù)庫中的所有數(shù)據(jù)放在內(nèi)存中，隨著redis的不斷運行，使用內(nèi)存會越來越大，最終導致內(nèi)存不住。redis的VM與操作系統(tǒng)的VM相似，把很少訪問的vlaue保存到磁盤中。與此同時，redis把value對應的key放在內(nèi)存中，為了能夠讓redis快速定位到被被換出的value所在的磁盤位置，從而將其導入的內(nèi)存中。

操作系統(tǒng)也有虛擬內(nèi)存功能，為什么redis要重復‘制造輪子‘呢？主要原因有兩點：

1.操作系統(tǒng)的VM是基于頁的概念，比如linux系統(tǒng)中內(nèi)個頁是4kb，而redis大多數(shù)對象遠小于4kb，一頁行可能有多個redis對象。另外redis的集合對象類型與list，set可能存放在多個頁上面。故redis自己實現(xiàn)可能達到控制換入的粒度。

2.redis將交換到磁盤的對象壓縮，保存到磁盤的對象可以取出指針和對象元素信息。一般壓縮后的對象比內(nèi)存中對象小10倍，這樣redis的vm比操作系統(tǒng)的VM少做很多I/O操作。

配置redis的VM

#開啟VM

vm-enabled yes

#交換出來的value文件保存路徑

vm-swap-file /tmp/redis.swap

#redis使用最大內(nèi)存上線，超過后開始使用交換空間 ?單位字節(jié)

vm-max-memory ?268435456

#設置每個頁面的大小為32字節(jié)

vm-page-size 32

#最多在文件使用多少頁面，swap文件的大小等于vm-page-size * vm-page

vm-pages 134217728

#用于執(zhí)行value對象換出換入的工作線程數(shù)。0表示不使用工作線程

vm-max-threads 4

redis的vm只把value交換到磁盤中，而key依然存儲在內(nèi)存中，目的是讓開啟VM的redis和完全使用內(nèi)存的redis性能基本保持一致。如果由于太多key而造成內(nèi)存不住問題，redis的VM并不能解決。

和炒作系統(tǒng)一樣，redis也按照頁交換對象。一頁只能保存一個對象，但是一個對象可以保存在多頁中。

當redis使用的內(nèi)存沒有超過設置的vm-max-memory之前，不把任何value交換到磁盤中；當超過最大內(nèi)存限制后，redis根據(jù)一下算法尋找一個對象交換到磁盤中：

swappability=age*log(size_in_memory);

其中age代表這個對象距離上一次被訪問的時間，size_in_memry是這個對象在內(nèi)存中占用的空間大小。redis采取的策略是把那些很少訪問，而且占用內(nèi)存又比較大的對象交換的齒盤空間中，但是第二個因素所占的權(quán)重更低，所以在公式中取log值。因為交換大對象時，需要占用更多的I/O和cpu資源。

應該更具自己的應用設置vm-page-size，設置太大浪費磁盤空間，設置太小照成swap文件出現(xiàn)過多碎片。

vm-max-threads 表示用于交換任務的工作線程數(shù)量，建議不要將vm-max-threads設置為0，設置為0時交換過程在主線程進行，從而阻塞其他用戶。但也不是設置越大越好，因為太多的工作線程導致操作系統(tǒng)使用更多的時間來切換線程，從而降低效率。推薦吧vm-max-threads設置為服務器的cpu核心數(shù)。

為了理解VM子系統(tǒng)如何工作，需要了解對象在swap文件中如何存儲。

swap文件中采用rdb文件的存儲格式。swap文件被分割成固定數(shù)量的頁，每頁占用指定的數(shù)量的字節(jié)空間。在redis.conf中更具自己業(yè)務需求配置一下兩個參數(shù)：

vm-page-size 設置每頁的大小，默認值為32.

vm-pages設置能夠使用的頁數(shù)，默認值為134217728

redis在內(nèi)存中保存一個bitmap以映射這些頁是否被占用，每bit代表一個對應磁盤空間的頁是否被占用。內(nèi)存中保存這樣一份映射表極大的增強了redis性能，同時，對內(nèi)存的使用又非常少。

在持久化備份的時候，也會備份swap 中的數(shù)據(jù)只不過在備份時swap變?yōu)橹蛔x了，父進程和后臺主進程只能訪問swap。而父進程不能將value換入。

當一個value 交換到磁盤時，value對應的redis object 將被VM Pointer，VM pointer保存value在磁盤的信息。

交換過程：

從內(nèi)存交換到swap中：

第一步。計算保存這個對象需要占用swap文件中多少頁

第二步：在swap中尋找一段連續(xù)的空白頁空間保存這個對象

第三步：把對象寫入swap

從swap中交換到內(nèi)存中

從swap文件交換到內(nèi)存比較簡單，因為在VM Pointer 中已記錄對象在swap文件的頁起始地址和占用頁數(shù)，只要更具VM Pointer 把磁盤的對象換入內(nèi)存即可。

?

轉(zhuǎn)載于:https://www.cnblogs.com/phpshen/p/6292988.html

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術(shù)人生

總結(jié)

以上是生活随笔為你收集整理的redis 事务，持久化，日志，主从，VM的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。