前兩天想自己研究php的併發問題，看到很多人都說用redis的佇列處理併發很好，所以自己也去研究了一下，下面用實際專案記錄一下自己的成果。
基本思路是所有操作用過redis的佇列和集合處理併發
1.使用者搶購佇列（list），user_list
2.商品佇列（list），goods_list
3.訂單資訊（hash集合）,order_info
4.購買成功使用者（set集合）,bought_list
ps：1和2用來控制併發，佇列的rpop是具有原子性的，即使處理併發，也是乙個個處理，不會出現重複和超賣的情況。
3則是用來暫時存放訂單資訊，之後再入庫。
4是為了防止使用者重複購買做的（set的特性是不能重複）。
併發模擬則是在linux的webbench做的。
經過試驗發現，併發1000條的搶購，直接運算元據庫要12秒，使用redis只要6秒，速度快了整整一倍！
下面貼原始碼
商品入貨1000個：
public function ruhuo()秒殺介面：
public function redis_qianghuo()就是這麼簡單，不僅高效，而且不會出現超賣情況，很實用的併發處理。
Hibernate 處理併發
一 事務 指運算元據庫的乙個程式執行單無,這些操作要麼全部成功，要麼全部失敗以保證資料的完成性和統一性.二 多事務併發引起的問題 a 第一類丟失更新 撤銷乙個事務時把其它事務更新的資料也覆蓋了。for example 事務a 和b 同時訪問數 據data 如果事務b 更新了資料,但事務a執行了回滾操...
核心併發處理
隨著硬體的發展，smp 對稱多處理器 已經很普遍，如果核心的排程機制是可搶占的，那麼smp和核心搶占是多執行緒執行的兩種場景。當多個執行緒同時訪問核心的資料結構時，我們就需要對其做序列化處理。自旋鎖和互斥體 訪問共享資源的 區稱為臨界區。自旋鎖 spinlock 和互斥體 mutex,mutual ...
處理高併發
這個我感覺都不是做開發來考慮的，但是估計面試需要。做查詢的時候會對查詢的表加上共享鎖。做更改的時候對錶加排它鎖。這個進行多個表更新查詢的時候x需要加鎖abc，y加鎖cba。現在x加了a需要c，y加了c需要a，就形成死鎖了。可以對錶建立乙個臨時表，臨時表不需要加鎖。還可以通過建立檔案組，來處理高併發，...