在2017年8月14號的一天接到一個即看即買的項目，大致功能如下
1.現場走秀直播同步到H5頁面
2.實時顯示直播間人數
3.點贊並實時顯示給用戶
4.在某個時間點，可以全體推送一些消息給所有用戶
5.推送的消息裏面的商品可以點擊購買，加入購物車。
6.實時聊天，獲取用戶真實的暱稱，頭像（基於微信授權）
7.保存聊天記錄，用戶在進來後顯示最後十條聊天記錄
約定29號上線，當時準備採取用workman+mysql的方式來處理這些功能，大約有12個工作日來開發，但是其中因爲中間穿插了一個另外的項目花去了四天時間，然後客戶臨時要求加個RSVP的功能花去一天，最後只剩下了7個工作日來開發這個這個項目，包括前端和後端的整合。因爲客戶希望在直播的時候推出他們的產品，所以不希望直播全屏，那樣會使用戶看不到商品，前端解決這個問題加上做完這些頁面，總共花了三天時間，我只剩了四天時間。因爲時間很緊迫，沒有考慮這些設計的合理性，包括上線的峯值和併發都沒有進行估算，結果出現了大家預想中的事情，服務器宕機。
主要表現：
1.上線10分鐘左右，因爲直播還沒有接入，很多用戶在公屏發言，而當時用戶的暱稱、頭像都是保存在數據庫的，需要從數據庫讀取，並且聊天記錄要寫入數據庫。大量的I/O操作，導致mysql內存耗盡，直接mysql gone away了。
2.在大約八點半左右的時候，一位明星的登場走秀，導致直播間人數暴增，在幾分鐘之內服務器就掛掉了，白屏了大約一分鐘。
處理方案：
1.第一次數據庫掛掉之後，及時的發現了原因，刪除掉了聊天記錄的寫入之後重啓了數據庫
2.在apache掛掉之後，查看服務器發現cpu達到96%，內存耗盡所以掛掉，趕緊重啓
在直播結束之後，我們向服務器公司要了一份當天直播時候的報告：
通過上面圖標我們可以發現問題，就是服務器過載了，主要兩個原因
1.實時聊天購物用的是workman，每進入一個人都會建立一個tcp連接，瞬間涌入的人太多導致連接池滿載
2.峯值很高，系統已經發生任務擁塞，Apache和Mysql同時連接內存開銷太大，服務器配置是4G內存，4CPU，進程太多不夠使用然後消耗系統內存導致服務掛掉
當時服務器掛掉的原因固然是因爲服務器配置不高的原因，但是工具選取不對也是很大的因素，後來想了解決方案：
1 .增加服務器的配置（內存和CPU），或者搭建一個簡單的負載均衡系統避免一臺機器宕機，整個服務停掉
2.瞬間涌入人太多的項目要在項目開始前估算峯值，選擇服務器
3.臨時修改Apache的最大連接數，滿足項目的要求
4.數據存儲改成兩層數據存儲，用nosql+mysql的方式，在半夜服務器活動少的時候同步數據
第二天的時候趕緊花了半天的時候，將所有的操作從操作數據庫改成了操作redis，redis可以支撐7-10W的併發，比數據庫的性能要好很多，將所有的數據存入redis中，在直播的時候直接操作redis。等到直播結束或者服務器閒置的時候，定時執行腳本將數據同步至mysql，查詢的時候先查緩存再查數據庫。這樣可以很大的避免數據庫掛掉，服務器崩潰的情況。
在改成redis存儲之後，整個代碼量減少了大約三分之二，並且redis的操作是原子性的，對於一些遞增遞減的操作支持很好，不像MYSQL一樣，一旦遞增遞減update之後就會鎖定表，阻塞後面的操作，導致mysql掛掉。
