原子性

原子性是數(shù)據(jù)庫的事務中的特性。在數(shù)據(jù)庫事務的情景下，原子性指的是：一個事務（transaction）中的所有操作，要么全部完成，要么全部不完成，不會結束在中間某個環(huán)節(jié)。
對于Redis而言，命令的原子性指的是：一個操作的不可以再分，操作要么執(zhí)行，要么不執(zhí)行。

Redis操作原子性的原因

Redis的操作之所以是原子性的，是因為Redis是==單線程的==。
由于對操作系統(tǒng)相關的知識不是很熟悉，從上面這句話并不能真正理解Redis操作是原子性的原因，進一步查閱進程與線程的概念及其區(qū)別。

進程與線程

• 進程
  計算機中已執(zhí)行程序的實體。比如，一個啟動了的php-fpm，就是一個進程。
• 線程
  操作系統(tǒng)能夠進行運算調(diào)度的最小單元。它被包含在進程之中，是進程的實際運作單位。一條線程指的是進程中一個單一順序的控制流，一個進程中可以并發(fā)多個線程，每條線程并行執(zhí)行不同的任務。比如，mysql運行時，mysql啟動后，該mysql服務就是一個進程，而mysql的連接、查詢的操作，就是線程。

進程與線程的區(qū)別

• 資源（如打開文件）：進程間的資源相互獨立，同一進程的各線程間共享資源。某進程的線程在其他進程不可見。
• 通信：進程間通信：消息傳遞、同步、共享內(nèi)存、遠程過程調(diào)用、管道。線程間通信：直接讀寫進程數(shù)據(jù)段（需要進程同步和互斥手段的輔助，以保證數(shù)據(jù)的一致性）。
• 調(diào)度和切換：線程上下文切換比進程上下文切換要快得多。
  線程，是操作系統(tǒng)最小的執(zhí)行單元，在單線程程序中，任務一個一個地做，必須做完一個任務后，才會去做另一個任務。

Redis在并發(fā)中的表現(xiàn)

Redis的API是原子性的操作，那么多個命令在并發(fā)中也是原子性的嗎？
看看下面這段代碼：

$redis= newRedis(); $redis->connect('127.0.0.1',6379); for($i= 0;$iget('val'); $num++; $redis->set('val',$num); usleep(10000); }

用兩個終端執(zhí)行上面的程序，發(fā)現(xiàn)val的結果是小于2000的值，那么可以知道，在程序中執(zhí)行多個Redis命令并非是原子性的，這也和普通數(shù)據(jù)庫的表現(xiàn)是一樣的。
如果想在上面的程序中實現(xiàn)原子性，可以將get和set改成單命令操作，==比如incr，或者使用Redis的事務，或者使用Redis+Lua==的方式實現(xiàn)。

原子性總結

綜上所述，對Redis來說，執(zhí)行get、set以及eval等API，都是一個一個的任務，這些任務都會由Redis的線程去負責執(zhí)行，任務要么執(zhí)行成功，要么執(zhí)行失敗，這就是Redis的命令是原子性的原因。

Redis本身提供的所有API都是原子操作，Redis中的事務其實是要保證批量操作的原子性。

事務

MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事務相關的命令。事務可以一次執(zhí)行多個命令， 并且?guī)в幸韵聝蓚€重要的保證：

• 事務是一個單獨的隔離操作：事務中的所有命令都會序列化、按順序地執(zhí)行。事務在執(zhí)行的過程中，不會被其他客戶端發(fā)送來的命令請求所打斷。
• 事務是一個原子操作：事務中的命令要么全部被執(zhí)行，要么全部都不執(zhí)行。

事務的關鍵字

• EXEC 命令負責觸發(fā)并執(zhí)行事務中的所有命令：
  如果客戶端在使用 MULTI 開啟了一個事務之后，卻因為斷線而沒有成功執(zhí)行 EXEC ，那么事務中的所有命令都不會被執(zhí)行。
• 另一方面，如果客戶端成功在開啟事務之后執(zhí)行 EXEC ，那么事務中的所有命令都會被執(zhí)行。
  當使用 AOF 方式做持久化的時候， Redis 會使用單個 write(2) 命令將事務寫入到磁盤中。
  然而，如果 Redis 服務器因為某些原因被管理員殺死，或者遇上某種硬件故障，那么可能只有部分事務命令會被成功寫入到磁盤中。
  如果 Redis 在重新啟動時發(fā)現(xiàn) AOF 文件出了這樣的問題，那么它會退出，并匯報一個錯誤。
  使用redis-check-aof程序可以修復這一問題：它會移除 AOF 文件中不完整事務的信息，確保服務器可以順利啟動。
  從 2.2 版本開始，Redis 還可以通過樂觀鎖（optimistic lock）實現(xiàn) CAS （check-and-set）操作，具體信息請參考文檔的后半部分。

事務的語句

> MULTI OK > INCR foo QUEUED > INCR bar QUEUED > EXEC 1) (integer) 1 2) (integer) 1

為什么 Redis 不支持回滾（roll back）

如果你有使用關系式數(shù)據(jù)庫的經(jīng)驗， 那么 “Redis 在事務失敗時不進行回滾，而是繼續(xù)執(zhí)行余下的命令”這種做法可能會讓你覺得有點奇怪。
以下是這種做法的優(yōu)點：

• Redis 命令只會因為錯誤的語法而失敗（并且這些問題不能在入隊時發(fā)現(xiàn)），或是命令用在了錯誤類型的鍵上面：這也就是說，從實用性的角度來說，失敗的命令是由編程錯誤造成的，而這些錯誤應該在開發(fā)的過程中被發(fā)現(xiàn)，而不應該出現(xiàn)在生產(chǎn)環(huán)境中。
• 因為不需要對回滾進行支持，所以 Redis 的內(nèi)部可以保持簡單且快速。
  有種觀點認為 Redis 處理事務的做法會產(chǎn)生 bug ， 然而需要注意的是， 在通常情況下， 回滾并不能解決編程錯誤帶來的問題。 舉個例子， 如果你本來想通過 INCR 命令將鍵的值加上 1 ， 卻不小心加上了 2 ， 又或者對錯誤類型的鍵執(zhí)行了 INCR ， 回滾是沒有辦法處理這些情況的。

轉載于:https://www.cnblogs.com/lori/p/9300087.html

總結

以上是生活随笔為你收集整理的知其所以然~redis的原子性的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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