事務(wù)的四大特性：原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)、持久性(Durability) 事務(wù)的屬性：傳播行為、隔離級(jí)別、只讀和事務(wù)超時(shí) 個(gè)人見解：這里小僧認(rèn)為事務(wù)的特性和屬性不是一個(gè)定西，特性側(cè)重于說明特點(diǎn)，二屬性則側(cè)重于說明本身就有的東西，這里舉個(gè)例子人有鼻子 腿 眼睛 耳朵 這是屬性只要是正常人都有這些東西，但是這個(gè)人長得帥 騷氣 這屬于特性，有特點(diǎn)。 關(guān)于事務(wù)的一些特性和屬性的一些具體解釋小僧這里就不重復(fù)復(fù)述了，不懂的自行百度即可。 Redis的事務(wù)屬性主要通過5個(gè)命令來操作的，分別是 multi、exec、watch、unwatch、discard。下面分別介紹下這屋命令的意思： watch key1 key2 ... : 監(jiān)視一或多個(gè)key,如果在事務(wù)執(zhí)行之前，被監(jiān)視的key被其他命令改動(dòng)，則事務(wù)被打斷 ( 類似樂觀鎖 )

　　multi : 標(biāo)記一個(gè)事務(wù)塊的開始( queued )

　　exec : 執(zhí)行所有事務(wù)塊的命令 ( 一旦執(zhí)行exec后，之前加的監(jiān)控鎖都會(huì)被取消掉 )　

　　discard : 取消事務(wù)，放棄事務(wù)塊中的所有命令

　　unwatch : 取消watch對(duì)所有key的監(jiān)控 下面用多種案例實(shí)際操作下： (1)正常執(zhí)行的情況下，multi開啟事務(wù) 然后輸入一個(gè)或者多個(gè)命令這是所有命名沒有執(zhí)行，當(dāng)執(zhí)行exec操作后是開始執(zhí)行

(2)放棄事務(wù)，multi開啟事務(wù) 然后輸入一個(gè)或者多個(gè)命令這是所有命名沒有執(zhí)行，當(dāng)執(zhí)行discard操作后怎放棄執(zhí)行，不作任何操作，在上一步中把name 的值設(shè)置為了ergou,所以get的時(shí)候獲得ergou

(3)若在事務(wù)隊(duì)列中存在命令性錯(cuò)誤(類似于java編譯性錯(cuò)誤)，則執(zhí)行EXEC命令時(shí)，所有命令都不會(huì)執(zhí)行

(4)若在事務(wù)隊(duì)列中存在語法性錯(cuò)誤(類似于java的1/0的運(yùn)行時(shí)異常)，則執(zhí)行EXEC命令時(shí)，其他正確命令會(huì)被執(zhí)行，錯(cuò)誤命令拋出異常。

(5)使用watch檢測(cè)余額balance，事務(wù)期間balance數(shù)據(jù)未變動(dòng)，事務(wù)執(zhí)行成功

(6)使用watch檢測(cè)balance，在開啟事務(wù)后(一窗口)，在2窗口執(zhí)行的操作，更改balance的值，模擬其他客戶端在事務(wù)執(zhí)行期間更改watch監(jiān)控的數(shù)據(jù)，然后再執(zhí)行一窗口后命令，執(zhí)行EXEC后，事務(wù)未成功執(zhí)行。

一但執(zhí)行 EXEC 開啟事務(wù)的執(zhí)行后，無論事務(wù)使用執(zhí)行成功， WARCH 對(duì)變量的監(jiān)控都將被取消。故當(dāng)事務(wù)執(zhí)行失敗后，需重新執(zhí)行WATCH命令對(duì)變量進(jìn)行監(jiān)控，并開啟新的事務(wù)進(jìn)行操作。WARCH 指令類似于樂觀鎖(你有沒有想到j(luò)ava的CAS呢？)，在事務(wù)提交時(shí)，如果watch監(jiān)控的多個(gè)KEY中任何KEY的值已經(jīng)被其他客戶端更改，則使用EXEC執(zhí)行事務(wù)時(shí)，事務(wù)隊(duì)列將不會(huì)被執(zhí)行，同時(shí)返回Nullmulti-bulk應(yīng)答以通知調(diào)用者事務(wù)執(zhí)行失敗。 這里你應(yīng)該問Redis為什么不支持回滾操作呢？ 解答：在正常編程中上面案例(3)幾乎是不可能出現(xiàn)的，不過案例(4)怎有可能出現(xiàn)，但是Redis作者認(rèn)為既然使用Redis他會(huì)默認(rèn)你的操作都是正確的，為了保證高性能就不支持回滾操作了。

• 管道Pipelining Redis是一種基于客戶端-服務(wù)端模型以及請(qǐng)求/響應(yīng)協(xié)議的TCP服務(wù)。這意味著通常情況下一個(gè)請(qǐng)求會(huì)遵循以下步驟： 客戶端向服務(wù)端發(fā)送一個(gè)查詢請(qǐng)求，并監(jiān)聽Socket返回，通常是以阻塞模式，等待服務(wù)端響應(yīng)。 服務(wù)端處理命令，并將結(jié)果返回給客戶端。 redis客戶端執(zhí)行一條命令分4個(gè)過程： 發(fā)送命令－〉命令排隊(duì)－〉命令執(zhí)行－〉返回結(jié)果 這個(gè)過程稱為Round trip time(簡稱RTT, 往返時(shí)間)，Redis提供許多批量操作的命令，如MSET/MGET/HMSET/HMGET等等，這些命令存在的意義是減少維護(hù)網(wǎng)絡(luò)連接和傳輸數(shù)據(jù)所消耗的資源和時(shí)間。但大部分命令(如hgetall，并沒有mhgetall)不支持批量操作，需要消耗N次RTT(Round trip time往返時(shí)間) ，這個(gè)時(shí)候需要pipeline來解決這個(gè)問題。

然而，如果客戶端要連續(xù)執(zhí)行的多次操作無法通過Redis命令組合在一起，例如： SET a "abc" INCR b HSET c name "hi"

此時(shí)便可以使用Redis提供的pipelining功能來實(shí)現(xiàn)在一次交互中執(zhí)行多條命令。使用pipelining時(shí)，只需要從客戶端一次向Redis發(fā)送多條命令(以)分隔，Redis就會(huì)依次執(zhí)行這些命令，并且把每個(gè)命令的返回按順序組裝在一起一次返回，比如： $ (printf "PINGPINGPING"; sleep 1) | nc localhost 6379 +PONG +PONG +PONG 大部分的Redis客戶端都對(duì)Pipelining提供支持，所以開發(fā)者通常并不需要自己手工拼裝命令列表。 Pipelining的優(yōu)勢(shì) 管道技術(shù)最顯著的優(yōu)勢(shì)是提高了 redis 服務(wù)的性能。 Pipelining的局限性 Pipelining只能用于執(zhí)行連續(xù)且無相關(guān)性的命令，當(dāng)某個(gè)命令的生成需要依賴于前一個(gè)命令的返回時(shí)，就無法使用Pipelining了。

總結(jié)

以上是生活随笔為你收集整理的一个命名管道可以被多个客户端访问吗_Redis 的事务机制和管道技术Pipelining的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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