php 高併發下數據同步的問題

1.加鎖
缺點：下降性能
優勢：減小代碼邏輯複雜度(題主如今這樣超過1w條就刪數據的邏輯，感受看起來就點糟糕啊，若是整個系統一複雜，這樣的來回寫數據，你肯定你的邏輯還維護得下去？建議題主梳理一下代碼的邏輯流)


2.隊列(redis/各種mq等)
缺點：引入其餘組件，增長系統複雜度，下降穩定性。
優勢：可以將web的並行邏輯串行，其實和加鎖差很少，不過更優雅，而且性能上面也更可控。若是題主的系統的邏輯複雜，推薦採用這種。

建議：php寫多你會發現，它的邏輯就是一波流的。在它的邏輯層實現過多的重試，等待，以及回寫，會致使php很臃腫。建議要麼在數據庫層上鎖，要麼引入隊列等待，要麼就直接報錯，讓用戶F5重試，若是用ajax重試，幾乎沒有用戶體驗上的問題。那麼來講一下直接報錯的方案。

3.建一個計數器表
舉例：
create table store_count (total int(11) NOT NULL) ENGINE=InnoDB
搶計數器：
若是我查出來如今總數是2，那麼我 update store_count set total = 3 where total = 2
若是更新成功，說明如今的總行數是3，能夠去插表，若是未更新，說明這時已經有其餘用戶插入了，直接給用戶報錯，讓他下次請求再來過。

缺點：這種方式其實比前兩個更粗暴，前2種方式仍是等待的，這種方式直接丟棄了部分用戶流量，帶來的是一個有緩存特性的計數器來實現題主提的邏輯。
這個計數器在內存中效果更佳。

建議題主根據自身的系統情況，和代碼邏輯，進行性能、開發效率、邏輯成本、維護成本上的取捨。

 

 

===================================================================================

 

用一個計數器
我最近在作一個項目 高併發選課系統
每次insert以前先計數器+1而後判斷他的值是否大於max
若是大於max計數器自減1 相似回滾
若是小於max 執行insert語句

ps：計數器自增和自減須要保證其原子性
推薦Redis來作計數器 max也能夠用redis來存.

 

====================================================================================

用隊列

====================================================================================

加鎖就行，要麼鎖表，要麼鎖程序，加了鎖就至關於變成隊列執行，一次只能一我的拿到鎖，只能一我的經過，去插入數據。

php裏可使用文件鎖，或memcached鎖也行，文件鎖會致使阻塞。

能夠搜索:php鎖，php文件鎖