並發資料庫

1. 如何處理資料庫並發問題

想要知道如何處理數據並發，自然需要先了解數據並發。

什麼是數據並發操作呢？
就是同一時間內，不同的線程同時對一條數據進行讀寫操作。

在互聯網時代，一個系統常常有很多人在使用，因此就可能出現高並發的現象，也就是不同的用戶同時對一條數據進行操作，如果沒有有效的處理，自然就會出現數據的異常。而最常見的一種數據並發的場景就是電商中的秒殺，成千上萬個用戶對在極端的時間內，搶購一個商品。針對這種場景，商品的庫存就是一個需要控制的數據，而多個用戶對在同一時間對庫存進行重寫，一個不小心就可能出現超賣的情況。

針對這種情況，我們如何有效的處理數據並發呢？

第一種方案、資料庫鎖
從鎖的基本屬性來說，可以分為兩種：一種是共享鎖（S），一種是排它鎖（X）。在Mysql的資料庫中，是有四種隔離級別的，會在讀寫的時候，自動的使用這兩種鎖，防止數據出現混亂。

這四種隔離級別分別是：

讀未提交（Read Uncommitted）
讀提交（Read Committed）
可重復讀（Repeated Read）
串列化（Serializable）
當然，不同的隔離級別，效率也是不同的，對於數據的一致性保證也就有不同的結果。而這些可能出現的又有哪些呢？

臟讀（dirty read）

當事務與事務之間沒有任何隔離的時候，就可能會出現臟讀。例如：商家想看看所有的訂單有哪些，這時，用戶A提交了一個訂單，但事務還沒提交，商家卻看到了這個訂單。而這時就會出現一種問題，當商家去操作這個訂單時，可能用戶A的訂單由於部分問題，導致數據回滾，事務沒有提交，這時商家的操作就會失去目標。

不可重復讀（unrepeatable read）

一個事務中，兩次讀操作出來的同一條數據值不同，就是不可重復讀。

例如：我們有一個事務A，需要去查詢一下商品庫存，然後做扣減，這時，事務B操作了這個商品，扣減了一部分庫存，當事務A再次去查詢商品庫存的時候，發現這一次的結果和上次不同了，這就是不可重復讀。

幻讀（phantom problem）

一個事務中，兩次讀操作出來的結果集不同，就是幻讀。

例如：一個事務A，去查詢現在已經支付的訂單有哪些，得到了一個結果集。這時，事務B新提交了一個訂單，當事務A再次去查詢時，就會出現，兩次得到的結果集不同的情況，也就是幻讀了。

那針對這些結果，不同的隔離級別可以干什麼呢？

「讀未提（Read Uncommitted）」能預防啥？啥都預防不了。

「讀提交（Read Committed）」能預防啥？使用「快照讀（Snapshot Read）」方式，避免「臟讀」，但是可能出現「不可重復讀」和「幻讀」。

「可重復讀（Repeated Red）」能預防啥？使用「快照讀（Snapshot Read）」方式，鎖住被讀取記錄，避免出現「臟讀」、「不可重復讀」，但是可能出現「幻讀」。

「串列化（Serializable）」能預防啥？有效避免「臟讀」、「不可重復讀」、「幻讀」，不過運行效率奇差。

好了，鎖說完了，但是，我們的資料庫鎖，並不能有效的解決並發的問題，只是盡可能保證數據的一致性，當並發量特別大時，資料庫還是容易扛不住。那解決數據並發的另一個手段就是，盡可能的提高處理的速度。

因為數據的IO要提升難度比較大，那麼通過其他的方式，對數據進行處理，減少資料庫的IO，就是提高並發能力的有效手段了。

最有效的一種方式就是：緩存
想要減少並發出現的概率，那麼讀寫的效率越高，讀寫的執行時間越短，自然數據並發的可能性就變小了，並發性能也有提高了。

還是用剛才的秒殺舉例，我們為的就是保證庫存的數據不出錯，賣出一個商品，減一個庫存，那麼，我們就可以將庫存放在內存中進行處理。這樣，就能夠保證庫存有序的及時扣減，並且不出現問題。這樣，我們的資料庫的寫操作也變少了，執行效率也就大大提高了。

當然，常用的分布式緩存方式有：Redis和Memcache，Redis可以持久化到硬碟，而Memcache不行，應該怎麼選擇，就看具體的使用場景了。

當然，緩存畢竟使用的范圍有限，很多的數據我們還是必須持久化到硬碟中，那我們就需要提高資料庫的IO能力，這樣避免一個線程執行時間太長，造成線程的阻塞。

那麼，讀寫分離就是另一種有效的方式了
當我們的寫成為了瓶頸的時候，讀寫分離就是一種可以選擇的方式了。

我們的讀庫就只需要執行讀，寫庫就只需要執行寫，把讀的壓力從主庫中分離出去，讓主庫的資源只是用來保證寫的效率，從而提高寫操作的性能。

2. 資料庫的並發操作分帶來哪些問題

根據之前的dong網友做的vs示意圖

並結合參考，個人認為，不可重復讀和幻讀，應該是層次上的不同：

⑴.幻讀：對象（實體）的數量不同

⑵.不可重復讀：對象（實體）的值（屬性）不同

1.更新丟失

幻讀

參考:

網頁鏈接

網頁鏈接

3. 資料庫高並發寫入，怎麼降低資料庫的壓力

主要通過架構設計來減少高並發對資料庫的壓力；
比如 在資料庫和應用程序之間，增加 DAL層，通過代理，連接池等，保證資料庫與業務程序由一定的緩沖和關系梳理；
在資料庫前面，加一個緩存層，讓大部分數據訪問，都直接在緩存層獲取數據，不用訪問到後端的MySQL資料庫；

4. 資料庫如何實現並發控制

唔，並發污染就是數據在並發使用的時候，出現的臟讀，臟寫，虛讀等等了。。。

並發性控制就是用來防止上述情況的。比如防止臟寫的並發控制應該做到在寫入數據時檢查一下要更新的數據，資料庫中的原始數據是否和程序中准備更新的原始數據一一符合，然後進行更新。防止你准備更新的記錄被別人更新了，而你又重復更新了別人更新過的記錄。。。

5. 資料庫的並發操作可能帶來哪些問題 丟失更新 死鎖 違反唯一性約束

資料庫中常見的並發操作所帶來的一致性問題包括：丟失的修改、不可重復讀、讀臟數據、幻影讀（幻影讀在一些資料中往往與不可重復讀歸為一類）。
丟失修改
下面先來看一個例子，說明並發操作帶來的數據的不一致性問題。
考慮飛機訂票系統中的一個活動序列:
甲售票點（甲事務）讀出某航班的機票余額A,設A=16.
乙售票點（乙事務）讀出同一航班的機票余額A,也為16.
甲售票點賣出一張機票,修改余額A←A-1.所以A為15,把A寫回資料庫.
乙售票點也賣出一張機票,修改余額A←A-1.所以A為15,把A寫回資料庫.
結果明明賣出兩張機票，資料庫中機票余額只減少1。
歸納起來就是：兩個事務T1和T2讀入同一數據並修改，T2提交的結果破壞了T1提交的結果，導致T1的修改被丟失。前文（2.1.4數據刪除與更新）中提到的問題及解決辦法往往是針對此類並發問題的。但仍然有幾類問題通過上面的方法解決不了，那就是：
不可重復讀
不可重復讀是指事務T1讀取數據後，事務T2執行更新操作，使T1無法再現前一次讀取結果。具體地講，不可重復讀包括三種情況：
事務T1讀取某一數據後，事務T2對其做了修改，當事務1再次讀該數據時，得到與前一次不同的值。例如，T1讀取B=100進行運算，T2讀取同一數據B，對其進行修改後將B=200寫回資料庫。T1為了對讀取值校對重讀B，B已為200，與第一次讀取值不一致。
事務T1按一定條件從資料庫中讀取了某些數據記錄後，事務T2刪除了其中部分記錄，當T1再次按相同條件讀取數據時，發現某些記錄神密地消失了。
事務T1按一定條件從資料庫中讀取某些數據記錄後，事務T2插入了一些記錄，當T1再次按相同條件讀取數據時，發現多了一些記錄。（這也叫做幻影讀）
讀"臟"數據
讀"臟"數據是指事務T1修改某一數據，並將其寫回磁碟，事務T2讀取同一數據後，T1由於某種原因被撤消，這時T1已修改過的數據恢復原值，T2讀到的數據就與資料庫中的數據不一致，則T2讀到的數據就為"臟"數據，即不正確的數據。
產生上述三類數據不一致性的主要原因是並發操作破壞了事務的隔離性。並發控制就是要用正確的方式調度並發操作，使一個用戶事務的執行不受其它事務的干擾，從而避免造成數據的不一致性。
並發一致性問題的解決辦法
封鎖（Locking）
封鎖是實現並發控制的一個非常重要的技術。所謂封鎖就是事務T在對某個數據對象例如表

6. 資料庫並發控制中使用什麼可以獲得更高的並發度

資料庫並發控制中使用可以獲得更高的並發度好像沒有，只有鎖這種方式。可以用樂觀鎖。當發生死鎖時，可以使用等待圖法，消除死鎖。

並發控制保證事務4個特性，acid：A:原子性(Atomicity) 事務是資料庫的邏輯工作單位，事務中包括的諸操作要麼全做，要麼全不做。C:一致性(Consistency) 事務執行的結果必須是使資料庫從一個一致性狀態變到另一個一致性狀態。

資料庫管理系統中的並發控制：

資料庫管理系統（DBMS）中的並發控制的任務是確保在多個事務同時存取資料庫中同一數據時不破壞事務的隔離性和統一性以及資料庫的統一性。

資料庫並發控制現有兩處火車票售票點，同時讀取某一趟列車車票資料庫中車票余額為X。兩處售票點同時賣出一張車票，同時修改余額為X -1寫回資料庫，這樣就造成了實際賣出兩張火車票而資料庫中的卻記錄只少了一張。

資料庫並發控制產生這種情況的原因是因為兩個事務讀入同一數據並同時修改，其中一個事務提交的結果破壞了另一個事務提交的結果，導致其數據的修改被丟失，破壞了事務的隔離性。並發控制要解決的就是這類問題。

7. 資料庫並發訪問是什麼意思是同時用資料庫的人數么

資料庫並發訪問是指：可能會發生兩個用戶同時對一張表的同一條數據進行修改等操作，這是可能發生的情況。 和資料庫連接人數是兩個概念。前者是對數據操作的一種可能，後者是和版權相關。

8. 如何查看高並發下mysql資料庫的性能

限流演算法目前程序開發過程常用的限流演算法有兩個：漏桶演算法和令牌桶演算法。

漏桶演算法

漏桶演算法的原理比較簡單，請求進入到漏桶中，漏桶以一定的速率漏水。當請求過多時，水直接溢出。可以看出，漏桶演算法可以強制限制數據的傳輸速度。如圖所示，把請求比作是水滴，水先滴到桶里，通過漏洞並以限定的速度出水，當水來得過猛而出水不夠快時就會導致水直接溢出，即拒絕服務。

圖片來自網路

漏桶演算法和令牌桶演算法的選擇

兩者的主要區別漏桶演算法能夠強行限制處理數據的速率，不論系統是否空閑。而令牌桶演算法能夠在限制數據的平均處理速率的同時還允許某種程度的突發流量。如何理解上面的含義呢？漏桶演算法，比如系統吞吐量是 120/s，業務請求 130/s，使用漏斗限流 100/s，起到限流的作用，多餘的請求將產生等待或者丟棄。對於令牌桶演算法，每秒產生 100 個令牌，系統容量 200 個令牌。正常情況下，業務請求 100/s 時，請求能被正常被處理。當有突發流量過來比如 200 個請求時，因為系統容量有 200 個令牌可以同一時刻處理掉這 200 個請求。如果是漏桶演算法，則只能處理 100 個請求，其他的請求等待或者被丟棄。

9. 多線程如何並發訪問SQLite資料庫

SQLite作為一款小型的嵌入式資料庫，本身沒有提供復雜的鎖定機制，無法內部管理多路並發下的數據操作同步問題，更談不上優化，所以涉及到多路並發的情況，需要外部進行讀寫鎖控制，否則SQLite會返回SQLITE_BUSY錯誤，以駁回相關請求。
返回SQLITE_BUSY主要有以下幾種情況：
1。當有寫操作時，其他讀操作會被駁回
2。當有寫操作時，其他寫操作會被駁回
3。當開啟事務時，在提交事務之前，其他寫操作會被駁回
4。當開啟事務時，在提交事務之前，其他事務請求會被駁回
5。當有讀操作時，其他寫操作會被駁回
6。讀操作之間能夠並發執行
基於以上討論，可以看出這是一個典型的讀者寫者問題，讀操作要能夠共享，寫操作要互斥，讀寫之間也要互斥

可以設計如下的方案解決並發操作資料庫被鎖定的問題，同時保證讀操作能夠保持最大並發
1。採用互斥鎖控制資料庫寫操作
2。只有擁有互斥鎖的線程才能夠操作資料庫
3。寫操作必須獨立擁有互斥鎖
4。讀操作必須能夠共享互斥鎖，即在第一次讀取的時候獲取互斥鎖，最後一次讀取的時候釋放互斥鎖

10. 資料庫的並發控制

就是，連接，比如10個人同時連接在資料庫上，就是10個並發數，很多軟體都用這個來收費，並發數