Java開發大型互聯網-如何使用Redis數據庫之Rdis事務處理

引言

Redis是一個開源的、使用C語言編寫的、支持網絡交互的、可基於內存也可持久化的Key-Value數據庫。Redis是一個開源的使用ANSI C語言編寫、支持網絡、可基於內存亦可持久化的日誌型、Key-Value數據庫，並提供多種語言的API。從2010年3月15日起，Redis的開發工作由VMware主持。從2013年5月開始，Redis的開發由Pivotal贊助。

學會安裝redis

從redis.io下載最新版redis-X.Y.Z.tar.gz後解壓，然後進入redis-X.Y.Z文件夾後直接make即可，安裝非常簡單。

make成功後會在src文件夾下產生一些二進制可執行文件，包括redis-server、redis-cli等等：

$ find . -type f -executable

./redis-benchmark //用於進行redis性能測試的工具

./redis-check-dump //用於修復出問題的dump.rdb文件

./redis-cli //redis的客戶端

./redis-server //redis的服務端

./redis-check-aof //用於修復出問題的AOF文件

./redis-sentinel //用於集群管理

學會啟動redis

啟動redis非常簡單，直接./redis-server就可以啟動服務端了，還可以用下面的方法指定要加載的配置文件：

./redis-server ../redis.conf

默認情況下，redis-server會以非daemon的方式來運行，且默認服務端口為6379。

有關作者為什麼選擇6379作為默認端口，還有一段有趣的典故，英語好的同學可以看看作者這篇博文中的解釋。

使用redis客戶端

我們直接看一個例子：

//這樣來啟動redis客戶端了

$ ./redis-cli

//用set指令來設置key、value

127.0.0.1:6379> set name "roc"

OK

//來獲取name的值

127.0.0.1:6379> get name

"roc"

//通過客戶端來關閉redis服務端

127.0.0.1:6379> shutdown

127.0.0.1:6379>

redis的事務處理

眾所周知，事務是指“一個完整的動作，要麼全部執行，要麼什麼也沒有做”。

在聊redis事務處理之前，要先和大家介紹四個redis指令，即MULTI、EXEC、DISCARD、WATCH。這四個指令構成了redis事務處理的基礎。

MULTI用來組裝一個事務；

EXEC用來執行一個事務；

DISCARD用來取消一個事務；

WATCH用來監視一些key，一旦這些key在事務執行之前被改變，則取消事務的執行。

紙上得來終覺淺，我們來看一個MULTI和EXEC的例子：

redis> MULTI //標記事務開始

OK

redis> INCR user_id //多條命令按順序入隊

QUEUED

redis> INCR user_id

QUEUED

redis> INCR user_id

QUEUED

redis> PING

QUEUED

redis> EXEC //執行

1) (integer) 1

2) (integer) 2

3) (integer) 3

4) PONG

在上面的例子中，我們看到了QUEUED的字樣，這表示我們在用MULTI組裝事務時，每一個命令都會進入到內存隊列中緩存起來，如果出現QUEUED則表示我們這個命令成功插入了緩存隊列，在將來執行EXEC時，這些被QUEUED的命令都會被組裝成一個事務來執行。

對於事務的執行來說，如果redis開啟了AOF持久化的話，那麼一旦事務被成功執行，事務中的命令就會通過write命令一次性寫到磁盤中去，如果在向磁盤中寫的過程中恰好出現斷電、硬件故障等問題，那麼就可能出現只有部分命令進行了AOF持久化，這時AOF文件就會出現不完整的情況，這時，我們可以使用redis-check-aof工具來修復這一問題，這個工具會將AOF文件中不完整的信息移除，確保AOF文件完整可用。

有關事務，大家經常會遇到的是兩類錯誤：

調用EXEC之前的錯誤

調用EXEC之後的錯誤

“調用EXEC之前的錯誤”，有可能是由於語法有誤導致的，也可能時由於內存不足導致的。只要出現某個命令無法成功寫入緩衝隊列的情況，redis都會進行記錄，在客戶端調用EXEC時，redis會拒絕執行這一事務。（這時2.6.5版本之後的策略。在2.6.5之前的版本中，redis會忽略那些入隊失敗的命令，只執行那些入隊成功的命令）。我們來看一個這樣的例子：

127.0.0.1:6379> multi

OK

127.0.0.1:6379> haha //一個明顯錯誤的指令

(error) ERR unknown command 'haha'

127.0.0.1:6379> ping

QUEUED

127.0.0.1:6379> exec

//redis無情的拒絕了事務的執行，原因是“之前出現了錯誤”

(error) EXECABORT Transaction discarded because of previous errors.

而對於“調用EXEC之後的錯誤”，redis則採取了完全不同的策略，即redis不會理睬這些錯誤，而是繼續向下執行事務中的其他命令。這是因為，對於應用層面的錯誤，並不是redis自身需要考慮和處理的問題，所以一個事務中如果某一條命令執行失敗，並不會影響接下來的其他命令的執行。我們也來看一個例子：

127.0.0.1:6379> multi

OK

127.0.0.1:6379> set age 23

QUEUED

//age不是集合，所以如下是一條明顯錯誤的指令

127.0.0.1:6379> sadd age 15

QUEUED

127.0.0.1:6379> set age 29

QUEUED

127.0.0.1:6379> exec //執行事務時，redis不會理睬第2條指令執行錯誤

1) OK

2) (error) WRONGTYPE Operation against a key holding the wrong kind of value

3) OK

127.0.0.1:6379> get age

"29" //可以看出第3條指令被成功執行了

好了，我們來說說最後一個指令“WATCH”，這是一個很好用的指令，它可以幫我們實現類似於“樂觀鎖”的效果，即CAS（check and set）。

WATCH本身的作用是“監視key是否被改動過”，而且支持同時監視多個key，只要還沒真正觸發事務，WATCH都會盡職盡責的監視，一旦發現某個key被修改了，在執行EXEC時就會返回nil，表示事務無法觸發。

127.0.0.1:6379> set age 23

OK

127.0.0.1:6379> watch age //開始監視age

OK

127.0.0.1:6379> set age 24 //在EXEC之前，age的值被修改了

OK

127.0.0.1:6379> multi

OK

127.0.0.1:6379> set age 25

QUEUED

127.0.0.1:6379> get age

QUEUED

127.0.0.1:6379> exec //觸發EXEC

(nil) //事務無法被執行

總結

以 上就是我對Java開發大型互聯網-如何使用Redis數據庫之Rdis事務處理問題及其優化總結，分享給大家，希望大家知道什麼是Java開發大型互聯網-如何使用Redis數據庫之Rdis事務處理問題及其優化。覺得收穫的話可以點個關注收藏轉發一波喔，謝謝大佬們支持！

• 1、多寫多敲代碼，好的代碼與紮實的基礎知識一定是實踐出來的

• 2、可以去百度搜索騰訊課堂圖靈學院的視頻來學習一下java架構實戰案例，還挺不錯的。

• 最後，每一位讀到這裡的網友，感謝你們能耐心地看完。希望在成為一名更優秀的Java程序員的道路上，我們可以一起學習、一起進步！都能贏取白富美，走向架構師的人生巔峰!

• 3丶想了解學習以上課程內容可加群：469717771 驗證碼頭條（06 必過）歡迎大家的加入喲！