引語：人多是好事！人多好賺錢。不過這對於技術人員來說，卻也不是一個小問題，我對這種問題一直是抱以一顆敬畏之心的。這更多的是一個架構問題，作為一個開發我也就這點見識了！看着微信、支付寶等等大公司發着幾個億的紅包的，我急紅了眼，不是因為我錯過了幾個億（實際上我基本一點都沒搶到），而是羡慕他們技術上的牛掰！面對幾億人的沖擊，他們巍然不動，穩穩地服務着大眾人民。為此，我想寫一篇關於高並發方面的文章了（大數據就不說了），希望借以拋磚引玉！
聲明：本文的主要創作方式為些許的個人經驗加上網上資料的收集，並非所以都為本人親身經歷，但絕對是干貨（至少我是這么認為的），希望對大家有一點點的幫助，也強烈歡迎指教！
並發是個最常見的但是不見得都需要處理的問題。它的解決不是一點，而是一系列基礎設施的配合操作完成的，我們可以不必去處理，或者只需巧妙的避開他就可以了。但是，你應該要了解大名鼎鼎的他。並發就是同一時間訪問某個服務所產生的效果。
並發可能導致以下幾個問題：
1. 寫文件錯誤，如多寫、少寫、錯寫（嚴重）
2. 數據存儲讀取錯誤，如已經產生的效果沒有立即獲取（客戶立馬就不高興了）
3. 服務器響應變慢，如有些需要系統自動等待鎖操作（稍慢可以接受）
4. 服務器直接掛掉，某些操作不當導致服務器資源耗盡只有掛掉了（你完了）
發現需要解決的問題，那就對症下葯吧。
1. 寫文件。這種場景基本上是在於記錄日志一類的操作吧，平時沒有什么實際用處，但是真的到了出事的時候，就尤其需要了，里面會記錄一些操作記錄，特殊操作結果情況等等。一般來說，這種文件都是以追加的形式進行寫入文件的，但是因為都是寫一個文件，如果同時操作，可能就會出現各種難以預料的事。當然，可能最多就是某用戶寫的日志被另一個給覆蓋了，少一兩條也話沒什么關系，我最開始也是這么認為的。但是，這也是在我們的預料之中，預料之外的事鬼知道呢，我就曾經因為寫日志把整個服務給整掛掉了你信不？還是，加鎖吧，看情況，加讀鎖、寫鎖，慢就慢一點吧，准確性安全性放第一吧！
2. 數據錯誤。這絕對是致命的，如果數據出問題了，沒有給客戶作好解釋，基本上就是，能賠多少就賠多少，賠不了咱們就關門歇業吧！說句行外話，人們所有的操作，不都是基於對系統數據的相信嗎？如果數據都錯了，那誰還敢再用，畢竟，他什么也沒有干啊，所有的東西都顯得那么科幻！那么，並發下，我們可以做什么呢？1. 數據庫該有的唯一鍵一定要加上（即使其他都錯了也不能讓真數據寫進去）；2. 針對特殊業務采用不同特點的數據庫，一般應對高並發都要求處理速度極快，所以nosql內存數據庫就是必須的了；3. 在保證數據准確的同時盡量使用查詢緩存；4. 一些耗時的不需要實時的操作，仍給隊列慢慢去做吧！
3. 服務器響應慢，這個嘛，一般是通過負載均衡，分布式服務搞定的，代碼里做到盡量最優化，如果還是承受不住的話，那就加機器吧！
4. 服務器實在受不了，掛掉了，在沒有影響數據准確性的情況下，重啟繼續干活（如果你敢的話）！
5. 既然已經考慮到了並發的問題，我想，如果事情看起來有可能發生，那就一定會發生。做好備用方案、備用設備、緊急恢復措施可能是最重要的吧！遲早會派上用場的！
好吧，我感覺我已經沒有其他話可說了（黔驢技窮），一個字，沒那么簡單。給幾個參考鏈接吧！
微信紅包的系統設計&優化(http://djt.qq.com/article/view/1349)
混合雲架構百科(http://baike.baidu.com/link?url=2MYoWz6cLxpl2qP4dW93UxJm8raufcKFEG8Pi6dtTN0e6FFi97ZE4l_KY-VrrBUaMTvFDZRbe5ccgKTEYxo9bT_GKhRFFiq-0Qy-r4kfx3d6Ia099Eo4qlTU67j00oT7)
12306的架構設計與淘寶天貓(http://www.zhenhua.org/article.asp?id=760&utm_source=tuicool&utm_medium=referral)
...
以上，就算是過年沒事干，瞎想吧！平時我們也不會涉及這方面的開發工作，所以也只能靠想像力了。不過，架構師不應該就是這樣練成的嗎？哈哈，不涉及具體技術，但是真心希望指教！