高併發 數據庫操做好比插入，修改等解決辦法

通常沒有辦法就是直接操做 數據庫了，因此才 須要分佈式mysq等，必須有事務。 可是如何併發太大仍是不夠的， 解決方案： 原子計數器---技術-- redis/noSQL 記錄用戶行爲消息--分佈式MQ 消費消息並落地--- mysql 這樣能夠抗很高的併發，可是成本太大了

運維成本和穩定型： NoSQL,MQ等 開發成本： 數據一致性，回滾方案等 冪等性難保證：重複秒殺問題 不適合新手的架構

爲何不用MySQL呢？ 通常認爲是mysql低效，其實不是 實際上是由於 事務的關係，特別是操做2個表的時候 一個事務 裏面 有更新又有插入數據的時候，那麼 mysql就是 行級鎖啓動了，同一條數據就鎖着了。 一直到前一個操做的客戶 commit或者 回滾該條數據。 其餘用戶想操做該條數據 是鎖着的，在等待。。 若是不少客戶那麼就會等待過久了。 其中等待時間 包括了 網絡延遲 以及GC垃圾回收時間 串行化了

優化方向： 減小行級鎖持有時間 將客戶端的邏輯放在mysql 裏面，避免網絡延遲和GC垃圾回收影響

如何放到mysql服務端： 定製SQL方案： update/+[auto_commit]/ ,須要修改mysql源碼 意思是，如何 更新成功的結果是1就自動提交，若是失敗就自動回滾，不提交給客戶端了，形成沒必要須有的時間影響。 使用存儲過程：整個事務在mysql 端完成。 存儲過程自己就是 爲了 將整個事務在mysql 服務器端完成。 避免客戶端去完成事務形成的時間的干擾。 就是 事務競爭優化：減小事務鎖時間

好比一個例子： 一個事務，有更新和 插入的操做。 通常狀況多是 ， 先執行更新，而後再執行插入 數據到其餘表裏面。 可是在高併發的狀況下， 簡單優化 ; 是 這樣的， 先 執行插入， 而後 在去更新比較好。 由於 更新的狀況下，數據庫會對那條數據 加一個 行級鎖，先插入呢，能夠減小鎖的持有時間。 深度優化： 事務SQL在MySQL端執行（存儲過程） 存儲過程： 1， 存儲過程優化： 事務行級鎖持有的時間 2， 不要過分依賴存儲過程 3， 簡單的邏輯可言應用存儲過程 4， 這樣能夠提供併發量，特別是秒殺併發