資料庫高併發

案例一：訂票系統案例

某航班只有一張機票，假定有1w個人開啟你的**來訂票，問你如何解決併發問題(可擴充套件到任何高併發**要考慮的併發讀寫問題)。問題：1w個人來訪問，票沒出去前要保證大家都能看到有票，不可能乙個人在看到票的時候別人就不能看了。到底誰能搶到，那得看這個人的「運氣」（網路快慢等），其次考慮的問題「併發」：1w個人同時點選購買，到底誰能成交？總共只有一張票。

前提：在現有表當中增加乙個冗餘字段，version版本號, long型別

原理：案例一：**交易系統、銀行系統

首先，**交易系統的**表，每幾秒鐘就有乙個**記錄產生，一天下來就有（假定**3秒乙個） **數量×20×60*6條記錄，一月下來這個表記錄數量多大？ oracle中一張表的記錄數超過100w後查詢效能就很差了，如何保證系統效能？再比如，中國移動有上億的使用者量，表如何設計？把所有用於存在於乙個表麼？

此外，我們還得考慮快取，這裡的快取，指的不僅僅是hibernate，hibernate本身提供了一級二級快取。這裡的快取獨立於應用，依然是記憶體的讀取，假如我們能減少資料庫頻繁的訪問，那對系統肯定大大有利的。比如乙個電子商務系統的商品搜尋，如果某個關鍵字的商品經常被搜，那就可以考慮這部分商品列表存放到快取（記憶體中去），這樣不用每次訪問資料庫，效能大大增加。簡單的快取大家可以理解為自己做乙個hashmap，把常訪問的資料做乙個key，value是第一次從資料庫搜尋出來的值，下次訪問就可以從map裡讀取，而不讀資料庫；專業些的目前有獨立的快取框架比如memcached 等，可獨立部署成乙個快取伺服器。

首先要了解高併發的的瓶頸在**？

可能是伺服器網路頻寬不夠

可能web執行緒連線數不夠

可能資料庫連線查詢上不去。

根據不同的情況，解決思路也不同。

像第一種情況可以增加網路頻寬，dns網域名稱解析分發多台伺服器。

負載均衡，前置**伺服器nginx、apache等等

資料庫查詢優化，讀寫分離，分表等等

最後複製一些在高併發下面需要常常需要處理的內容:

解決以上問題後，使用伺服器集群來解決單台的瓶頸問題。

資料庫併發衝突的解決

mysql資料庫高併發處理

總體思想 短,少,分流 短 1.頁面靜態化,2.使用快取 3.使用儲存過程,對於處理一次請求需要多次訪問資料庫的操作,將操作整合到儲存過程,這樣只需要一次資料庫訪問 4.延遲修改,將修改請求儲存到記憶體中,但可能會斷電丟失資料 5.使用索引 少 1.分表,但應盡量避免多表關聯查詢 2.分離活躍資料,...

資料庫高併發問題

多執行緒多程序 計算密集型任務 使用多程序，因為能python有gil，多程序可以利用上cpu多核優勢 io密集型任務 使用多執行緒，做io切換節省任務執行時間 併發 乙個專案剛開始的時候是為了實現基本功能，隨著版本和功能的迭代，大資料和高併發成了軟體設計必須考慮的問題 本質很簡單，乙個是慢，乙個是...

高併發mysql主鍵設計 高併發資料庫自增主鍵分析

在一般情況下，在新增領域物件後，都需要獲取對應的主鍵值。使用應用層來維護主鍵，在一定程度上有利於程式效能的優化和應用移植性的提高。在採用資料庫自增主鍵的方案裡，如果jdbc驅動不能繫結新增記錄對應的主鍵，就需要手工執行查詢語句以獲取對應的主鍵值，對於高併發的系統，這很容易返回錯誤的主鍵。通過帶快取的...