部落格引用處（以下內容在原有部落格基礎上進行補充或更改，謝謝這些大牛的部落格指導）：
如何解決秒殺的效能問題和超賣的討論
解決方案：前端：無非就是三板斧，擴容，靜態化，訪問限流
1，擴容：通過增加機器，來增加前端池的整體承載量。
2，靜態化：將頁面展示端所有可以靜態化的元素全部靜態化，減少動態元素，提高訪問/展示效率。
3，限流，一班通過ip級別的限流，來針對某乙個ip，對其單位時間內的請求發起的數量進行限制。
4，消峰值，通過在入口處加入遊戲，問題等來消去峰值，減少併發訪問。
後端-資料庫
1，首先高併發會影響mysql 的處理效能，開始會隨著併發量的增加，處理能力提高，當達到乙個峰值點的時候，就會出現乙個拐點，之後處理能力一路降低，最後甚至比單執行緒處理能力都差。
2，超賣問題，歸根結底在於減庫存操作是乙個事務操作，需要先查，然後新增，然後update-1，但是在update-1的時候，如果出現多併發操作，那麼不可避免的會出現負數。
3，最後當高併發和超賣碰到一起的時候，那麼由於操作庫存數量在同一行，那麼就會出現爭搶db行鎖的問題，導致互相等待甚至死鎖的現象，從而大大降低mysql的處理能力，最終導致前端出現超時異常。
針對上述問題，如何解決呢？ 先看眼**的高大上解決方案：2：修改源**，將排隊提到進入引擎層前，降低引擎層面的併發度。
3：組提交，降低server和引擎的互動次數，降低io消耗。
總結後端處理方案：
1，快取+佇列的方式（提交操作不分段）
將庫存從mysql遷移至記憶體中去，因為記憶體中不存在鎖的機制，所以可以避免鎖的問題，另外由於記憶體的讀寫操作的速度遠高於mysql,所以可以解決高併發下的效能問題，然後引入佇列，通過單佇列，將所有的db寫操作引入到佇列中去，進行序列化處理，當達到庫存閾值的時候就不再消費佇列，並關閉購買功能，這樣就解決了超賣問題。
但是由於是非同步的寫db的操作，因此，可能存在某一時刻db和redis中的資料不一直的問題。
2，將提交操作分為兩步執行，先申請，後確認，利用redis的自增和事務特性來發號，保證拿到小於等於庫存閾值的使用者都能成功購買，然後資料非同步寫入db。1、前端三板斧【擴容】【限流】【靜態化】
2、後端兩條路【記憶體】+【排隊】
大牛文章引用處：
java問題收集
所有位元組碼都是用sun虛擬機器編譯的.以下內容都是在網上查閱,加上一些自己的分析,如果有不對之處請大家指出來.1,迴圈外內定義變數 和 迴圈內定義變數 下面是 和位元組碼,通過比較可以知道,兩種方法位元組碼基本上是相同的.兩者效能基本上相等.在實際使用時建議根據語義來決定,不需要在迴圈外部使用的就...
5折限時搶購移動開發者大會門票！
2012年，移動真正成為主流，蘊藏巨大機遇！2012年，在移動主流化下，挑戰史無前例！在此背景下，csdn 聯合創新工場，隆重推出 2012 中國移動開發者大會！5折門票限時 搶購！地點 北京 國家會議中心 全球 移動時代降臨 中國 全球最大移動網際網路市場 大會亮點 亮點一 參會人數超過6000人...
樣本收集問題JAVA實現
機械人rob 從方形區域f 的左上角a點出發，向下或向右行走 直到右下角的b 點，在走過的路上，收集方格中的樣本。rob 從a點到b 點共走2次，試找出rob 的2條行走路徑，使其取得的樣本總價值最大。input 第1 行有1 個正整數n，表示方形區域f有n n 個方格。接下來每行有3 個整數，前2...