這是一個投票類項目（醫院類），簡要功能爲前期爲案例（包含一些基礎表單信息、ppt、視頻等文件）提交時間（持續時間原本較長），但因爲大家的共性拖沓原則，在提交截止的最後2天案例提交瘋狂爆發。
第一階段：案例截止日期，因爲各方面的發力和要求，大量的醫院人員來提交案例，但因爲案例又比較重含有各種數據、文檔、視頻等資料需要提交，導致大量的人員諮詢和帶寬、流量佔用，還有一個視頻轉換資源的佔用，由於之前沒考慮導致這裏產生了兩個瓶頸：
瓶頸一：原項目只是把視頻單獨存儲到了oss，其他文件落到了本地，因爲覺得文件較小，結果一天時間硬盤資源報警，之後分析原因，小文件的大小限制丟失（開發人員問題），同一文件重複修改上傳未刪除歷史文件（考慮不周），總結不要忽略任何一個小的資源當量大的時候會讓你漏洞百出
瓶頸二:視頻轉換服務資源跑滿，我們原架構因爲視頻資源屬於低頻操作，所以使用了消息隊列進行排隊消費轉換（單進程），因爲在大量的視頻需要轉換的時候，時間等待較長，在案例提交結束後無法立即（或者短時間內）在前臺展示，總結對於大併發情景一定要考慮各個節點進行壓力評估和預案，改造辦法，消費端改爲單進程多線程的處理方式
第二個階段：投票開始日期，因爲投票的門檻是需要認真，這樣導致用戶中心大量的認證訪問，用戶中心堵塞影響其他各個應用響應緩慢，出現的幾個瓶頸，主要原因我們只考慮到了投票相關應用的壓測，忽略了門檻相關服務的壓測。
瓶頸一：用戶中心原設定爲查詢高併發服務，突然由於大量應該造成了一個數據庫寫高頻、流量高的服務，總結用戶中心職責拆分不夠清晰，用戶單點登陸設計使用memcache未做穿透和緩存快速覆蓋的預案和設計
瓶頸二：遺漏的資源上傳未上傳到oss，被忽略了，但突然認證數據飆升導致硬盤報警，總結髮現的漏洞及時處理，不然遇到大數據量就會成爲短板
最終總結，對於高併發項目要足夠重視每一個節點，去假設每一個節點併發過高的情況和預案，不然現實會讓你手忙腳亂