面試或者工作中經常能遇到類似於搶購或者是併發爭奪默寫限量資源的需求，有一些想法但是比較亂，這裡剛好整理一下。
乙個搶購活動主要由這幾部分組成
2.下單-爭奪購買資格
3.支付-更新訂單狀態
頁面重新整理處理辦法：
1.頁面靜態化
2.反向**快取靜態頁面
3.所需動態引數通過介面獲得，不要經過框架渲染
4.提供引數的介面不要由查詢資料庫的操作，所有搶購引數全部放在記憶體或者快取中
下單處理辦法：重點
1.過濾器過濾請求(可以視搶購是否真的很大的併發量選擇開啟)：主要是考慮以某種假隨機的方式過濾掉一部分請求，例如獲取隨機數在某個範圍內才允許繼續搶購/ip尾號為某幾個數才允許繼續搶購
2.過濾器過濾掉惡意請求：限制某一賬號頻繁請求/某一賬號第一次進入搶購後進行記錄，再次進入則在過濾器處攔截返回提示搶購中；限制某一ip頻繁請求對ip一秒內請求5-10次的拉入黑名單30秒/60秒，此情況可返回線路繁忙/搶購繁忙
3.占用庫存：重點
單點系統用記憶體，分布式可以用快取，將此次搶購商品數量放入其中。或者採用占用資格即增加的方式，維護庫存。
經過上面一系列的攔截過濾，假設有10件商品參與搶購，有1000個使用者參與到搶購活動中來，前面兩種過濾後期望剩餘使用者數為100。
單點系統呼叫同步方法(沒測試過)對記憶體中的庫存進行操作。
分布式方法可以對redis的key進行incr或decr維護快取中的庫存。
占用庫存成功的將繼續生成訂單即支付，未有機會執行占用庫存的，需要對庫存進行判斷，如果大於等於搶購數量則返回搶購失敗。
4.下單：可非同步生成訂單，直接返回搶購成功，請去訂單列表支付(體驗不太好)。或者就同步生成訂單，跳轉訂單頁面進行支付。
支付處理辦法：
1.與銀行支付通訊必須是同步的，如果有notify，則在notify結束後修改訂單狀態。
記錄一下，以後會補上乙個簡單搶購系統的詳細**實現。
使用Mysql和Redis設計搶購邏輯
搶購場景中,要保證兩點 1.庫存不會超減 少賣 2.在1基礎上的執行速度 我測試了兩種方案,方案一.mysql開啟事務,獲取庫存時使用獨佔鎖阻塞其他讀請求.我把庫存表簡單設計如下 create table la store id int 11 not null val int 255 not nul...
模組簡單設計 設計簡單的賬號系統
下面考慮 乙個簡化版使用者賬戶系統，從註冊，登入，使用，登出四個方面做個簡單的設計 account表包含下面三個字段 id 乙個表唯一的id，標識使用者 user 使用者名稱 passwd 使用者密碼 為了防止資料庫被侵入洩露密碼，需要如md5 passwd 或者crypt單向加密 1，使用者註冊 ...
系統許可權的設計之簡單設計
工作時間也不長，但是總想寫一些自己的收穫。公司利用的技術也比較單純，asp.net,js也不怎麼需要用，唯一寫的多的就是sql語句。好了，廢話不多說了，開始談談我在做專案中一些對系統許可權的收穫，不過很多都是專案中看到的，我就想自己重新做一遍。也許會有 很多的問題和考慮不全的地方，但是我還是要寫出來...