模擬情景：
類似京東618秒殺活動，資料庫中（mysql）只有一條資料，然後有5萬併發量，頁面要保證正常顯示。
問題一：不用redis等分布式框架，就用傳統的方法如何解決？如何保證資料庫的穩定？
頁面商品剩餘數量的準確性
剩餘數量的查詢屬於qps，而且你這裡假設只有一行資料，所以一台資料就算5w併發，查詢再快，傳輸也有極限,而且這個假設在實際情況中幾乎不存在只需要考慮資料庫裡面只有1行資料的併發，如果要提公升mysql的查併發，可以多搞幾台read從庫，提供更多的查詢效能，允許一部分實際的查詢不精確，但是在下單寫入的時候，確保tps無誤差
頁面訪問的流暢性
前提有幾個，1：公司的頻寬足夠，2:問題1解決，3，在前台加乙個nginx反向**，把流量打到足夠多的服務上去，把流量硬吃下來
商品交易資料的安全性
這個不屬於效能問題的範疇，就算沒有效能問題，也需要考慮邏輯上的安全性
防止資料庫崩潰
如果不用redis，你需要估算出你每一台伺服器大致能接受多少個併發，你的邏輯層的伺服器有多少臺(就是第2步裡說的，被反向**的伺服器有多少臺)，你需要自己評估，然後再在記憶體裡寫乙個linkedblockingqueue，設定，當這個queue接受的請求太多時，直接拒絕請求，提示稍後再試
使用者參與後反饋的及時性
一般情況下，反饋及時性一點都不重要，如果有訊息佇列，就按照能處理的上限來處理好了，但是資料庫最好分開，別用同乙個mysql
問題二：使用redis等分布式框架如何解決呢？
頁面商品剩餘數量的準確性
用簡單的方式，可以寫個job，去寫商品的庫存，輪詢的固定時間更新一下，從資料庫裡讀內容。剩餘數量沒必要那麼實時，一點必要都沒有。或者在訂單購買成功時候，再觸發一下更新redis庫存，秒殺情況下，update會非常頻繁，所以不如輪詢的每幾秒更新一下來的划算
頁面訪問的流暢性
這點和不用redis的時候做法類似，只是在查詢的時候，不是讀mysql從庫了，是讀redis
商品交易資料的安全性
略…防止資料庫崩潰
這裡和上面比，需要額外考慮的不僅僅是資料庫崩潰，還得考慮redis不可用，最好的方案是你redis做高可用，如果redis不可用時，你加上了跳過redis，查詢資料庫的邏輯，則資料庫崩的可能更快
使用者參與後反饋的及時性略…
原文出處：
如何解決併發
雖然從巨集觀上，處理器是並行處理多項任務，但本質上乙個處理器在某個時間點只能處理乙個任務，屬於序列執行。在單處理器的情況下，併發問題源於多道程式設計系統的乙個基本特性 程序的相對執行速度不可 它取決於其他程序的活動 作業系統處理中斷的方式以及作業系統的排程策略。在分布式環境下，併發產生的可能性就更大...
如何解決高併發
如何解決高併發 快取靜態頁面 伺服器分離 優化資料庫結構，多做索引 資料庫集群和庫表雜湊 不要頻繁得使用new物件，能使用單例模式就使用，對於utility型別的類通過靜態方法來訪問。使用執行緒安全的集合物件vector hashtable 使用執行緒池 盡量使用快取，包括使用者快取，資訊快取等，多...
2 7 如何解決高併發？
1 cdn加速 把靜態資源放到別人伺服器上 2 後台資料庫使用mysql redis mysql是持久化儲存，存放在磁碟裡面，檢索的話，會涉及到一定的io，為了解決這個瓶頸，於是出現了快取，比如現在常用的 redis。首先，使用者訪問快取，如果未命中，就去訪問mysql，之後將mysql中的資料複製...