redis:transactions的保證
Atomic ： 事務commands隊列原子執行
不支持 roll backs： 不支持錯誤回滾
redis:事務， 不能用 關系型數據庫的 事務acid的特性來要求 redis事務
redis僅僅保證事務的Atomic：原子性。
redis是單線程的， 多個clients的請求，都存放在一個請求隊列中， 同一時間
redis 僅僅 執行其中一個 Atomic operations
因此 redis在執行 事務的時候， 保證了 隔離性。
當事務執行中 error發生：
It's important to note that even when a command fails, all the other commands in the queue are processed – Redis will not stop the processing of commands.
當發生錯誤時， 依然會繼續往下執行， 直到整個事務被執行完成。
redis事務： 場景一：在一個事務中， 當后一個或后多個 commands 依賴于 前一個或前幾個commands
因為redis事務作為原子操作是在Redis中執行的， 并不會和clients有交互，
當出現上述情況的時候， 怎么保證數據的正確性呢？
引入 watch
利用 optimistic locks來解決，
代碼示例
使用 redis: optimistic locks： watch 的不足呢？
watch 監視的整個key的數據， 對于 key的值類型是 lists, sets, zsets, hashes 的類型的值，
watch的鎖粒度太大， 會導致 collision的概率比較大， 最終導致代碼的執行效率很低：
因為如果被監視key對應的value的值被修改， 即 collision發生， 那么clients就會在一定時間內（5s）反復嘗試， 這樣浪費了性能， 降低了程序的執行效率。
如何解決降低 collision的概率，以實現提高程序的執行效率呢？
方案一： 降低鎖粒度：分布式鎖
將redis的樂觀鎖和小粒度鎖 與 關系型數據庫做類比：
從鎖粒度，而不是 共享和獨占鎖的角度考慮：
“表級鎖”
關系型數據庫的“表級鎖”(獨占鎖) ：redis的樂觀鎖（watch）
“行級鎖”
關系型數據庫中的“行級鎖” ： 利用redis實現小粒度的 分布式鎖
分布式鎖：粒度可控（可以是“表級鎖”，也可以是“行級鎖”）
具體是“表級鎖”還是“行級鎖”，并沒有代碼上的區分， 有的只有業務邏輯上的區分：
舉例：
根據鎖 key 的不同， 就可以實現 “表級鎖” 和“行級鎖”
如何借助 redis 實現 分布式鎖呢？
分布式鎖的要求有哪些呢？
分布式鎖可用出現的問題呢？
