并發就是同一時間訪問某個服務所產生的效果。 　　并發可能導致以下幾個問題： 　　　　1. 寫文件錯誤，如多寫、少寫、錯寫（嚴重） 　　　　2. 數據存儲讀取錯誤，如已經產生的效果沒有立即獲取（客戶立馬就不高興了） 　　　　3. 服務器響應變慢，如有些需要系統自動等待鎖操作（稍慢可以接受） 　　　　4. 服務器直接掛掉，某些操作不當導致服務器資源耗盡只有掛掉了（你完了） 發現需要解決的問題，那就對癥下藥吧。 ### 　　1. 寫文件 　　這種場景基本上是在于記錄日志一類的操作吧，平時沒有什么實際用處，但是真的到了出事的時候，就尤其需要了，里面會記錄一些操作記錄，特殊操作結果情況等等。一般來說，這種文件都是以追加的形式進行寫入文件的，但是因為都是寫一個文件，如果同時操作，可能就會出現各種難以預料的事。當然，可能最多就是某用戶寫的日志被另一個給覆蓋了，少一兩條也話沒什么關系，我最開始也是這么認為的。但是，這也是在我們的預料之中，預料之外的事鬼知道呢，我就曾經因為寫日志把整個服務給整掛掉了你信不？還是，加鎖吧，看情況，加讀鎖、寫鎖，慢就慢一點吧，準確性安全性放第一吧！ ### 　　2. 數據錯誤 　　這絕對是致命的，如果數據出問題了，沒有給客戶作好解釋，基本上就是，能賠多少就賠多少，賠不了咱們就關門歇業吧！說句行外話，人們所有的操作，不都是基于對系統數據的相信嗎？如果數據都錯了，那誰還敢再用，畢竟，他什么也沒有干啊，所有的東西都顯得那么科幻！那么，并發下，我們可以做什么呢？ 1. 數據庫該有的唯一鍵一定要加上（即使其他都錯了也不能讓真數據寫進去）； 2. 針對特殊業務采用不同特點的數據庫，一般應對高并發都要求處理速度極快，所以nosql內存數據庫就是必須的了； 3. 在保證數據準確的同時盡量使用查詢緩存； 4. 一些耗時的不需要實時的操作，仍給隊列慢慢去做吧！ ### 3.服務器響應慢 一般是通過負載均衡，分布式服務搞定的，代碼里做到盡量最優化，如果還是承受不住的話，那就加機器吧！