1樓：陳潮進
用乙個計數器
我最近在做乙個專案高併發選課系統
每次insert之前先計數器+1然後判斷他的值是否大於max如果大於max計數器自減1 類似回滾
如果小於max 執行insert語句
ps：計數器自增和自減需要保證其原子性
推薦Redis來做計數器 max也可以用redis來存.
我昨天做了乙個併發1000的測試
資料錯誤率為0
2樓：
感覺拋開業務目標，抽離出來看實現方法，看得人渾身彆扭。
比如，業務本身的目標是什麼？為什麼選擇了通過乙個錶行數來控制數量的技術方案？肯定沒有別的方案了麼？不是什麼樣的奇怪問題，都非要硬著頭皮解決啊……
3樓：藥師Eric
加鎖就行，要麼鎖表，要麼鎖程式，加了鎖就相當於變成佇列執行，一次只能乙個人拿到鎖，只能乙個人通過，去插入資料。
php裡可以使用檔案鎖，或memcached鎖也行，檔案鎖會導致阻塞。
可以搜尋:php鎖，php檔案鎖
4樓：「已登出」
在不修改業務的情況下，必須上鎖。如果後期效能遇到瓶頸，在不提公升硬體效能的條件下，優化方式只有降低鎖層次，或修改業務。
有人說排隊，其實排隊也是一種鎖。
扯幾句題外話：
現在網上的誤導文章太多了，各種高併發情況下的不鎖、無鎖。有時候真想問候作者的各種親朋好友。
同時，很多連資料庫手冊都沒耐心看完的小屁孩，看到那種無鎖的文章，連原理都沒去理解，就屁顛屁顛地照搬過來。不出問題才怪。而且以後遇到高併發情況，還趾高氣揚地來一句：
必須無鎖。想到那場面老夫就想一巴掌拍過去。
大佬們，請教個高併發下的場景問題？
涼夜 簡單點寫的話你就用阻塞佇列去實現 使用兩個執行緒A執行緒和B執行緒，A執行緒可以當做你說的a方法作為生產者，B執行緒當做b方法，作為消費者，另外有個阻塞佇列，這個阻塞是是事件通知的關鍵 首先A執行緒負責處理你的a方法呼叫的結果，可以將結果存入乙個map中，然後檢查map數量，數量不足則繼續結束...
高併發的情況下（100W）,資料先存在Redis保證快速響應，然後怎麼往MySql裡面寫？
yoiio 我們公司是第三市值的公司,我們服務是公司小服務,1秒3000萬請求,一天大概1.5 2萬億,不需要保證ACID,一般通過水平擴容機器解決 我們公司在中國是遮蔽詞 鳴鳴先生 這麼設計也是很獨特。既然redis已經存了，那就用redis好了，redis本身是可以支援持久化的，為什麼最終還要寫...
如何獲得高併發的經驗？
飛援科技 章躍平 首先，需要機會參與有高併發產品機會，因為實戰經驗是前提 其次，需要對網路，系統架構，開發語言，資料庫調優有足夠的知識 再次，需要和測試同事保持密切合作，在系統上線之前，把高併發問題扼殺在搖籃 最後系統上線後，做好監控，運維工作，隨時把握系統流量壓力。最後還需要再安全，防doss攻擊...