Redis-事務 Redis 事務可以一次執行多個命令， 並且帶有以下兩個重要的保證： 事務的上個步驟： 事務相關指令： 執行事務出現的四種情況： redis事務的三個特性： watch監控 watch監控表示對需要操作的key添加一個樂觀鎖，防止另一個用戶進行修改，導致結果錯誤。 悲觀鎖 顧名思義 ...
Redis-事務
Redis 事務可以一次執行多個命令， 並且帶有以下兩個重要的保證：
- 事務是一個單獨的隔離操作，事務中的所有命令都會序列化、按順序地執行。事務在執行的過程中，不會被其他客戶端發送來的命令請求所打斷。
- 事務是一個原子操作：事務中的命令要麼全部被執行，要麼全部都不執行
事務的上個步驟：
- 開啟事務：以MULTI開啟一個事務
- 命令入隊：將多個命令添加到命令隊列中，接到這些命令不會立即執行，而是放到等待執行的事務隊列中
- 執行事務：有EXEC執行事務。（或者DISCARD取消執行）
事務相關指令：
|
執行事務出現的四種情況：
- 正常執行：隊列中所有的指令全部會被執行。
- 全部取消：隊列中的所有指令全部會被取消。
- 全體連坐：如果指令集中有一條在加入隊列時報錯，則隊列中的所有指令全部取消。
- 冤頭債主：如果指令已經加入到隊列中，但執行失敗，只有當前指令失敗，其它繼續執行。
redis事務的三個特性：
- 單獨的隔離性：事務中的所有的命令都會序列化，按順序執行，事務在執行過程中，不會被其它客戶端發送過來的命令請求所打斷
- 沒有隔離級別的概念：隊列中的命令沒有提交之前都不會實際的被執行，因為事務提交前任何指令都不會被實際執行，也就不存在”事務內的查詢要看到事務里的更新。
- 不保證原子性：redis同一個事務中如果有一條命令執行失敗，其後的命令仍然會被執行，沒有回滾
watch監控
watch監控表示對需要操作的key添加一個樂觀鎖，防止另一個用戶進行修改，導致結果錯誤。
- 悲觀鎖
- 顧名思義，就是很悲觀，每次去拿數據的時候都認為別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會被block直到它拿到鎖。傳統的關係型資料庫裡面就用到了很多這種鎖，比如行鎖，表鎖，讀鎖，寫鎖等，都是在操作之前先上鎖。
- 樂觀鎖
- 顧名思義，就是很樂觀，每次去拿數據的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號等機制。提交的版本號必須大於當前版本號才可以提交
在訪問以寫入為目的數據的時候（SOL中的SELECT FOR UPDATE),關係資料庫會對被訪同的數據行進行加鎖，直到事務被提交（Commit）
或者被回滾（ROLLBACK）為止，如果有其他客戶端試圖對被加鎖的數據行進行寫入，那麼該客戶端將被阻塞、直到第一個事務執行完畢為止。加鎖在實際使用中非常有效，基本上所有關係資料庫都實現了這種加鎖功能，它的缺點在於，持有鎖的客戶端運行越慢，等待解鎖的客戶端被阻塞的時間就越長。因為加鎖有可能會造成長時間的等待，所以Redis為了儘可能地減少客戶端的等待時間，並不會在執行WATCH命令時對數據進行加鎖，相反地，Redis只會在數據已經被其他客戶端搶先修改了的情況下，通知執行了WATCH命令的客戶端，
Redis-主從複製
什麼是主從複製？
主從複製，是用來建立一個和主資料庫（master）完全一樣的資料庫環境，稱為從資料庫(slave)。
主從複製的作用和使用場合一般有幾個：
- 容災恢復，主資料庫伺服器故障後，可迅速從從資料庫恢復
- 讀寫分離、主資料庫主要做寫的操作，從資料庫做讀的操作
主從複製應用場景
- 電子商務網站上的商品，一般都是一次上傳，無數次瀏覽的，說專業點也就是”多讀少寫”。
- 對於這種場景，我們可以使如下這種架構
我們將一臺Redis伺服器作主庫(Matser)，其他三台作為從庫(Slave)，主庫只負責寫數據，每次有數據更新都將更新的數據同步到它所有的從庫，而從庫只負責讀數據。這樣一來，就有了兩個好處：
- 數據被覆製成了了好幾份，就算有一臺機器出現故障，也可以使用其他機器的數據快速恢復。
- 讀寫分離，不僅可以提高伺服器的負載能力，並且可以根據讀請求的規模自由增加或者減少從庫的數量，棒極了；
註意事項：
在Redis主從模式中，一臺主庫可以擁有多個從庫，但是一個從庫只能隸屬於一個主庫
主從複製實現方式
- 一主二僕
- 薪火相傳
- 反客為主
一主二僕
一個Master兩個或多個Slave
在多台機器上配置好redis環境，並修改相應的配置文件
只需要在從資料庫加配置如下代碼：
slaveof 主資料庫地址 主資料庫埠
例如：slaveof 127.0.0.1 6379
如果設置了密碼：
masterauth 主庫密碼
示例在一臺機器上面實現一主二僕：
這裡是用的windows版本的redis,然後可以根據Windows Service Documentation.docx文檔建立後臺服務
當主庫意外關閉時，從庫是什麼情況？
當主庫關閉時，從庫繼續保持從庫狀態，但是和主庫的連接丟失，不能在同步更新數據。如果主庫恢復，從庫也會恢復到連接狀態。 當從庫1關閉時，主庫和從庫N都不受影響。但是當從庫重新恢復時，丟失和主庫的連接狀態，必須重新關聯。
薪火相傳
什麼是薪火相傳？
上一個Slave可以是下一個slave的Master，Slave同樣可以接收其他slaves的連接和同步請求，那麼該slave作為了鏈條中下一個的master,可以有效減輕master的寫壓力
中途變更轉向:會清除之前的數據，重新建立拷貝最新的
slaveof 新主庫IP 新主庫埠
薪火相傳－演示
1.打開三台伺服器（－主二僕）
2.從客戶端連接三台伺服器，通過指令info replication查詢狀態
3.將6381的主機修改成6380
語法：slaveof 主機IP 埠
4.再查看效果
反客為主
什麼是反客為主？
使當前資料庫停止與其他資料庫的同步，轉成主資料庫
指令：SLAVEOF no one
演示：
- 打開三個伺服器
- 打開相應的三個客戶端
- 將主伺服器客戶端shutdown
- 將第二個客戶端(6380)SLAVEOF no one，反客為主
- 將其他的客戶端指向新的master（SLAVEOF 127.0.0.1 6380）
主從複製執行過程：
- 當一個從資料庫啟動時，會向主資料庫發送sync命令。
- Master接到命令啟動後臺的存檔進程，同時收集所有接收到的用於修改數據集命令，在後臺進程執行完畢之後，master將傳送整個數據文件到slave,以完成一次完全同步。
- 全量複製：而slave服務在接收到資料庫文件數據後，將其存檔並載入到記憶體中。
- 增量複製：Master繼續將新的所有收集到的修改命令依次傳給slave,完成同步。
- 但是只要是重新連接master,一次完全同步（全量複製)將被自動執行。
