今天在群里被@了，讓一起分析RpcException的原因。確實一是我手頭事情確實比較多，二是我對不是自己做的東西有種天然的排斥性，不情願看。這方面我需要高強度的修煉。確實是我們部門缺人手，問題緊急，不然兩位男神哥哥也不會這麼麻煩我[偷笑][偷笑][偷笑]。我們組長人真是超級nice，自己那麼忙了， ...
今天在群里被@了，讓一起分析RpcException的原因。確實一是我手頭事情確實比較多，二是我對不是自己做的東西有種天然的排斥性，不情願看。這方面我需要高強度的修煉。確實是我們部門缺人手，問題緊急，不然兩位男神哥哥也不會這麼麻煩我[偷笑][偷笑][偷笑]。我們組長人真是超級nice，自己那麼忙了，儘量什麼都是親力親為的。而且永遠是和藹可親的微笑，大家有問題找他都沒有任何的壓力。顏值+才華+人品，要不要給別人留條活路啊。我們老大笑起來很甜，微微一笑很傾城。但是最近估計事情太多，人員流動也比較大，感覺一下子從陽光男孩變成了憂郁王子~~
我說過工作中我會懷疑別人說的每一句話，我真的覺得該加機器。德偉說的qps沒突增的問題：中午12點左右有499的突增，QPS是沒有突增，但是確實也是一天當中的峰值了。只是QPS和499的對應不是直線型。而是告訴我們說，看，QPS大了一點點，機器扛不住了，突增了。
再說重啟privider服務異常超時量大。本來問題就在併發量上，突然少了一臺機器，當然就更扛不住啦。
異常我查過了，所謂的遠程調用超時，其實內部都是執行成功了，就是timeout了，調用方自己斷開了連接，還是併發量上不去。當然，優化一下也是可以起點作用，但是一是快過節了風險大，二是不加機器，最能解決問題的解決這個問題的改動就是換web容器。一天兩天也換不了吧
所以，男神哥哥們，咱們就加台機器唄？
dubbo預設是同步的數據傳輸的，別人說的話要耳聽為虛，自己動手驗證一下是有必要的。從一開始調查這個的時候我就說，應該從併發上去找原因。所以我先看了磁碟，CPU和記憶體。沒有問題，而且不是在某一個介面上，就極有可能在框架和容器上了。而德偉說dubbo預設是非同步，自己是應該再推敲一下的。因為想想非同步的原理就應該明白：非同步是消息發出去，不等待結果返回的，對於一個需要快速返回結果的請求來說也是不適用的。如果真的不想加機器(其實加機器沒那麼麻煩，我那邊的高配物理機可以無償貢獻出來的，不會有額外的費用開銷)就得從參數上調整一下，但是作用可能不是特別明顯和有保證。其實，我從一開始就隱隱的知道這個問題，包括加了dubbo後事故增多，這段時間的最重要的性能都卡在這裡。之所以我不願意深入去調查這個問題是我一直在做別的事情，沒有專門去分析這個。直到被@讓我來調查這個問題，我才提，這就是我的個人性格問題了。我不願意堅持己見。如果大家都沒什麼主意，我願意拿出方案來。如果我和別人都有方案，各有道理，我願意聽別人的，不願意產生衝突，雖然看別人有時候爭論一下也挺有意思的。
我之所以不願和別人爭論，除了本身性格，確實還有能力的問題，我沒有信心可以說服別人，說明我還需要做很多的調研。
