Python的組合資料型別
轉載自：https://www.jianshu.com/p/d2ac26ca6525
一、併發控制
當程式中可能出現併發的情況時，就需要通過一定的手段來保證在併發情況下資料的準確性，通過這種手段保證了當前使用者和其他使用者一起操作時，所得到的結果和他單獨操作時的結果是一樣的。這種手段就叫做併發控制。併發控制的目的是保證一個使用者的工作不會對另一個使用者的工作產生不合理的影響。
沒有做好併發控制，就可能導致髒讀、幻讀和不可重複讀等問題。
常說的併發控制，一般都和資料庫管理系統(DBMS)有關。在 DBMS 中的併發控制的任務，是確保在多個事務同時存取資料庫中同一資料時，不破壞事務的隔離性、一致性和資料庫的統一性。
實現併發控制的主要手段大致可以分為樂觀併發控制和悲觀併發控制兩種。
首先要明確：無論是悲觀鎖還是樂觀鎖，都是人們定義出來的概念，可以認為是一種思想。其實不僅僅是關係型資料庫系統中有樂觀鎖和悲觀鎖的概念，像 hibernate、tair、memcache 等都有類似的概念。所以，不應該拿樂觀鎖、悲觀鎖和其他的資料庫鎖等進行對比。樂觀鎖比較適用於讀多寫少的情況(多讀場景)，悲觀鎖比較適用於寫多讀少的情況(多寫場景)。
二、悲觀鎖(Pessimistic Lock)
1️⃣理解
當要對資料庫中的一條資料進行修改的時候，為了避免同時被其他人修改，最好的辦法就是直接對該資料進行加鎖以防止併發。這種藉助資料庫鎖機制，在修改資料之前先鎖定，再修改的方式被稱之為悲觀併發控制【Pessimistic Concurrency Control，縮寫“PCC”，又名“悲觀鎖”】。
之所以叫做悲觀鎖，是因為這是一種對資料的修改持有悲觀態度的併發控制方式。總是假設最壞的情況，每次讀取資料的時候都預設其他執行緒會更改資料，因此需要進行加鎖操作，當其他執行緒想要訪問資料時，都需要阻塞掛起。悲觀鎖的實現：
- 傳統的關係型資料庫使用這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。
- Java 裡面的同步 synchronized 關鍵字的實現。
2️⃣悲觀鎖主要分為共享鎖和排他鎖：
- 共享鎖【shared locks】又稱為讀鎖，簡稱S鎖。顧名思義，共享鎖就是多個事務對於同一資料可以共享一把鎖，都能訪問到資料，但是隻能讀不能修改。
- 排他鎖【exclusive locks】又稱為寫鎖，簡稱X鎖。顧名思義，排他鎖就是不能與其他鎖並存，如果一個事務獲取了一個數據行的排他鎖，其他事務就不能再獲取該行的其他鎖，包括共享鎖和排他鎖，但是獲取排他鎖的事務是可以對資料行讀取和修改。
3️⃣說明
悲觀併發控制實際上是“先取鎖再訪問”的保守策略，為資料處理的安全提供了保證。但是在效率方面，處理加鎖的機制會讓資料庫產生額外的開銷，還有增加產生死鎖的機會。另外還會降低並行性，一個事務如果鎖定了某行資料，其他事務就必須等待該事務處理完才可以處理那行資料。
三、樂觀鎖(Optimistic Locking)
1️⃣理解
樂觀鎖是相對悲觀鎖而言的，樂觀鎖假設資料一般情況下不會造成衝突，所以在資料進行提交更新的時候，才會正式對資料的衝突與否進行檢測，如果發現衝突了，則返回給使用者錯誤的資訊，讓使用者決定如何去做。樂觀鎖適用於讀操作多的場景，這樣可以提高程式的吞吐量。
樂觀鎖機制採取了更加寬鬆的加鎖機制。樂觀鎖是相對悲觀鎖而言，也是為了避免資料庫幻讀、業務處理時間過長等原因引起資料處理錯誤的一種機制，但樂觀鎖不會刻意使用資料庫本身的鎖機制，而是依據資料本身來保證資料的正確性。樂觀鎖的實現：
- CAS 實現：Java 中java.util.concurrent.atomic包下面的原子變數使用了樂觀鎖的一種 CAS 實現方式。
- 版本號控制：一般是在資料表中加上一個資料版本號 version 欄位，表示資料被修改的次數。當資料被修改時，version 值會+1。當執行緒A要更新資料值時，在讀取資料的同時也會讀取 version 值，在提交更新時，若剛才讀取到的 version 值與當前資料庫中的 version 值相等時才更新，否則重試更新操作，直到更新成功。
2️⃣說明
樂觀併發控制相信事務之間的資料競爭(data race)的概率是比較小的，因此儘可能直接做下去，直到提交的時候才去鎖定，所以不會產生任何鎖和死鎖。
四、具體實現
1️⃣悲觀鎖實現方式
悲觀鎖的實現，往往依靠資料庫提供的鎖機制。在資料庫中，悲觀鎖的流程如下：
- 在對記錄進行修改前，先嚐試為該記錄加上排他鎖(exclusive locks)。
- 如果加鎖失敗，說明該記錄正在被修改，那麼當前查詢可能要等待或者丟擲異常。具體響應方式由開發者根據實際需要決定。
- 如果成功加鎖，那麼就可以對記錄做修改，事務完成後就會解鎖了。
- 期間如果有其他對該記錄做修改或加排他鎖的操作，都會等待解鎖或直接丟擲異常。
拿比較常用的 MySql Innodb 引擎舉例，來說明一下在 SQL 中如何使用悲觀鎖。
要使用悲觀鎖，必須關閉 MySQL 資料庫的自動提交屬性。因為 MySQL 預設使用 autocommit 模式，也就是說，當執行一個更新操作後，MySQL 會立刻將結果進行提交。(sql語句：set autocommit=0)
以電商下單扣減庫存的過程說明一下悲觀鎖的使用：以上，在對id = 1的記錄修改前，先通過 for update 的方式進行加鎖，然後再進行修改。這就是比較典型的悲觀鎖策略。
如果以上修改庫存的程式碼發生併發，同一時間只有一個執行緒可以開啟事務並獲得id=1的鎖，其它的事務必須等本次事務提交之後才能執行。這樣可以保證當前的資料不會被其它事務修改。
上面提到，使用 select…for update 會把資料給鎖住，不過需要注意一些鎖的級別，MySQL InnoDB 預設行級鎖。行級鎖都是基於索引的，如果一條 SQL 語句用不到索引是不會使用行級鎖的，會使用表級鎖把整張表鎖住，這點需要注意。
2️⃣樂觀鎖實現方式使用樂觀鎖就不需要藉助資料庫的鎖機制了。
主要就是兩個步驟：衝突檢測和資料更新。其實現方式有一種比較典型的就是 CAS(Compare and Swap)。
CAS 是項樂觀鎖技術，當多個執行緒嘗試使用 CAS 同時更新同一個變數時，只有其中一個執行緒能更新變數的值，而其它執行緒都失敗，失敗的執行緒並不會被掛起，而是被告知這次競爭中失敗，並可以再次嘗試。比如前面的扣減庫存問題，通過樂觀鎖可以實現如下： 樂觀鎖使用在更新之前，先查詢一下庫存表中當前庫存數(quantity)，然後在做 update 的時候，以庫存數作為一個修改條件。當提交更新的時候，判斷資料庫表對應記錄的當前庫存數與第一次取出來的庫存數進行比對，如果資料庫表當前庫存數與第一次取出來的庫存數相等，則予以更新，否則認為是過期資料。
以上更新語句存在一個比較嚴重的問題，即傳說中的ABA問題：
①比如說執行緒one從資料庫中取出庫存數3，這時候執行緒two也從資料庫中取出庫存數3，並且執行緒two進行了一些操作變成了2。
②然後執行緒two又將庫存數變成3，這時候執行緒one進行 CAS 操作發現數據庫中仍然是3，然後執行緒one操作成功。
③儘管執行緒one的 CAS 操作成功，但是不代表這個過程就是沒有問題的。
樂觀鎖每次在執行資料修改操作時，都會帶上一個版本號，一旦版本號和資料的版本號一致就可以執行修改操作並對版本號執行+1操作，否則就執行失敗。因為每次操作的版本號都會隨之增加，所以不會出現 ABA 問題，因為版本號只會增加不會減少。除了 version 以外，還可以使用時間戳，因為時間戳天然具有順序遞增性。
以上 SQL 其實還是有一定的問題的，就是一旦遇上高併發的時候，就只有一個執行緒可以修改成功，那麼就會存在大量的失敗。對於像淘寶這樣的電商網站，高併發是常有的事，總讓使用者感知到失敗顯然是不合理的。所以，還是要想辦法減少樂觀鎖的粒度。有一條比較好的建議，可以減小樂觀鎖力度，最大程度的提升吞吐率，提高併發能力！如下：
以上 SQL 語句中，如果使用者下單數為1，則通過quantity - 1 > 0的方式進行樂觀鎖控制。在執行過程中，會在一次原子操作中查詢一遍 quantity 的值，並將其扣減掉1。
高併發環境下鎖粒度把控是一門重要的學問。選擇一個好的鎖，在保證資料安全的情況下，可以大大提升吞吐率，進而提升效能。
五、如何選擇
在樂觀鎖與悲觀鎖的選擇上面，主要看下兩者的區別以及適用場景就可以了。
1️⃣響應效率：如果需要非常高的響應速度，建議採用樂觀鎖方案，成功就執行，不成功就失敗，不需要等待其他併發去釋放鎖。樂觀鎖並未真正加鎖，效率高。一旦鎖的粒度掌握不好，更新失敗的概率就會比較高，容易發生業務失敗。
2️⃣衝突頻率：如果衝突頻率非常高，建議採用悲觀鎖，保證成功率。衝突頻率大，選擇樂觀鎖會需要多次重試才能成功，代價比較大。
3️⃣重試代價：如果重試代價大，建議採用悲觀鎖。悲觀鎖依賴資料庫鎖，效率低。更新失敗的概率比較低。
4️⃣樂觀鎖如果有人在你之前更新了，你的更新應當是被拒絕的，可以讓使用者從新操作。悲觀鎖則會等待前一個更新完成。這也是區別。
隨著網際網路三高架構(高併發、高效能、高可用)的提出，悲觀鎖已經越來越少的被應用到生產環境中了，尤其是併發量比較大的業務場景。
MySQL樂觀鎖電商庫存併發問題應用
作者：mysql_______1
連結：https://www.jianshu.com/p/d2ac26ca6525
來源：簡書
著作權歸作者所有。商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。