從今年7月到現(xiàn)在轉(zhuǎn)眼間轉(zhuǎn)崗到淘寶部門已經(jīng)有小半年了萄凤，最近剛剛經(jīng)歷人生中第一次雙11實戰(zhàn)施绎，體驗了一把系統(tǒng)經(jīng)受高并發(fā)高流量的沖擊的感覺辩棒，一個字爽，作為小白羡玛，在這小半年里面收獲頗多别智，一個感悟是實戰(zhàn)是提高一個人能力的唯一真理，只有真的動手去做了稼稿，才會知道會遇到什么問題薄榛。日常做項目時候不怕遇到問題如何解決，最怕有些情景考慮不到让歼，而后者是需要經(jīng)驗累積起來的敞恋，一方面是試錯的累積，一方面是通過書本或者思考源碼得來的谋右。來淘寶這半年來為了能夠?qū)W到更多硬猫，從來不敢浪費時間，一邊欣賞這人家如何用代碼解決高并發(fā)高流量問題改执，一邊學著人家如何用工具快速高效的查詢系統(tǒng)瓶頸與查找線上問題啸蜜。
來淘寶后接受的是一個消息中間件系統(tǒng)，這個系統(tǒng)剛上線1年辈挂，而開發(fā)者也在我來之前的1個月轉(zhuǎn)崗去了其他部門衬横。還好有一些設計架構(gòu)圖可以參考，不得不說和看開源代碼類似终蒂，有了設計圖看代碼是很爽的蜂林。由于之前有看源碼的經(jīng)驗，在加上這個是中間件后豫，涉及的業(yè)務場景很少悉尾，所以研究起來并不費勁〈炷穑看了人家的代碼才知道,哦构眯，原來FutureTask是這樣使用異步解決耗時比較大的操作從而減少rt的，原來多線程中有些方法參數(shù)必須深拷貝才能避免線程安全問題早龟，原來服務端可以通過線程池來減少客戶端遠程調(diào)用的rt,原來線程池隊列要設置大小為了避免內(nèi)存爆掉惫霸，原來線程池隊列滿了后調(diào)用拋棄策略執(zhí)行時候用的是業(yè)務線程（這個影響業(yè)務線程rt）,哦，原來緩存作用那么大葱弟，guava緩存那么吊.....
對于如何用代碼解決高并發(fā)問題感悟是掌握并發(fā)編程基礎尤為重要壹店，比如并發(fā)包下的隊列了，Map了的使用與原理了解芝加，再比如并發(fā)隊列的put和offer方法有啥區(qū)別那硅卢，使用時如何選擇。還好在轉(zhuǎn)崗前苦心研究了一把并發(fā)編程，為欣賞人家的代碼奠定了基礎将塑，另外由理論到實踐中間還是會采坑的脉顿，這里說的采坑是說由于經(jīng)驗不足造成寫代碼時候由于沒有意識到所造成的并發(fā)安全問題，有些并發(fā)問題很微妙点寥，不細細品味是很難避免的艾疟。
說起雙11，歷經(jīng)2周幾乎每天搞到凌晨3敢辩，4點的雙11前壓測不得不說下蔽莱，由于這個系統(tǒng)才上線1年，經(jīng)歷過一次雙11戚长，今年流量是那次的5倍盗冷，再加上期間應該被改造過一些東西，壓測時候還是壓出來了一些問題±穑現(xiàn)在回頭看來壓測是模擬預估的流量(當然目前還是比較粗淺的認識)正塌，比如預估直播同時在線為200W，那么壓測時候就模擬出200W在線的用戶恤溶，然后看集群系統(tǒng)的性能如何乓诽，具體比如cpu使用量，內(nèi)存使用量咒程，系統(tǒng)load情況鸠天，接口調(diào)用的QPS，rt等是否正常,說實話來淘寶前基本這些指標對我就是紙上談兵帐姻。我們第一次壓測時候出現(xiàn)了一些機器cpu和load非常高稠集，通過dump線程堆棧分析發(fā)現(xiàn)是卡到了hashmap的put方法上，大家應該都知道hashmap在多線程下是線程不安全的饥瓷，查看代碼原來是4月份新增的一個功能竟然沒有使用ConcurrentHashMap剥纷，這個是一個低級的錯誤，拉分支修改為ConcurrentHashMap問題解決呢铆。還有一個是服務端線程池滿了晦鞋，線程滿一般是因為服務器執(zhí)行過慢，通過查看cpu占用量top10的線程棺克，發(fā)現(xiàn)都卡到了打日志的地方悠垛，而日志打印明明是異步的了，在一看原來是卡到了異步日志隊列的put方法了娜谊，異步日志隊列是一個阻塞有界隊列确买，默認如果隊列滿會調(diào)用put方法 ，而這貨是阻塞的纱皆，由于日志并不涉及統(tǒng)計信息使用湾趾，通過配置一個參數(shù)可以使用offer方法芭商，offer方法是非阻塞，隊列滿則丟棄....
兩周的壓測沒有白壓搀缠，從11月10號到11月11的0點蓉坎，系統(tǒng)沒有出現(xiàn)問題，順利的度過了高峰胡嘿，不過挑戰(zhàn)才剛剛開始...
最后打一個廣告，努力很重要钳踊，環(huán)境更重要衷敌。來吧，淘寶歡迎你的加入拓瞪，拿簡歷來砸暈我吧缴罗，郵箱1064454834@qq.com。
