- 在高併發的情況下，肯定不能高頻率的去讀寫數據庫，會嚴重造成性能問題的
必須使用緩存，將需要秒殺的商品放入緩存中，並使用鎖來處理其併發情況。當接到用戶秒殺提交訂單的情況下，先將商品數量遞減（加鎖/解鎖）後再進行其他方面的處理，處理失敗在將數據遞增1（加鎖/解鎖），否則表示交易成功。
當商品數量遞減到0時，表示商品秒殺完畢，拒絕其他用戶的請求。
- 肯定不能直接操作數據庫的，會掛的。直接讀庫寫庫對數據庫壓力太大，要用緩存。
把你要賣出的商品比如10個商品放到緩存中；然後在redis裏設置一個計數器來記錄請求數，這個請求書你可以以你要秒殺賣出的商品數爲基數，比如你想賣出10個商品，只允許100個請求進來。那當計數器達到100的時候，後面進來的就顯示秒殺結束，這樣可以減輕你的服務器的壓力。然後根據這100個請求，先付款的先得後付款的提示商品以秒殺完。
-
首先，多用戶併發修改同一條記錄時，肯定是後提交的用戶將覆蓋掉前者提交的結果了。
這個直接可以使用加鎖機制去解決，樂觀鎖或者悲觀鎖。
樂觀鎖，就是在數據庫設計一個版本號的字段，每次修改都使其+1，這樣在提交時比對提交前的版本號就知道是不是併發提交了，但是有個缺點就是隻能是應用中控制，如果有跨應用修改同一條數據樂觀鎖就沒辦法了，這個時候可以考慮悲觀鎖。
悲觀鎖，就是直接在數據庫層面將數據鎖死，類似於oralce中使用select xxxxx from xxxx where xx=xx for update，這樣其他線程將無法提交數據。
除了加鎖的方式也可以使用接收鎖定的方式，思路是在數據庫中設計一個狀態標識位，用戶在對數據進行修改前，將狀態標識位標識爲正在編輯的狀態，這樣其他用戶要編輯此條記錄時系統將發現有其他用戶正在編輯，則拒絕其編輯的請求，類似於你在操作系統中某文件正在執行，然後你要修改該文件時，系統會提醒你該文件不可編輯或刪除。 -
不建議在數據庫層面加鎖，建議通過服務端的內存鎖（鎖主鍵）。當某個用戶要修改某個id的數據時，把要修改的id存入redis，若其他用戶觸發修改此id的數據時，讀到redis有這個id的值時，就阻止那個用戶修改。
-
實際應用中，並不是讓mysql去直面大併發讀寫，會藉助“外力”，比如緩存、利用主從庫實現讀寫分離、分表、使用隊列寫入等方法來降低併發讀寫。