關於線上一次超時處理引發的思考
背景最近關於線上關於註冊問題有超時2s的情況發生，最長時間已經是9s多，上游系統最多只能等待2s就返回超時失敗。
影響造成線上上游系統出現註冊失敗，影響非常不好。告警郵件和簡訊頻發。
問題排查鏈路&解決方案
各系統檢查自己對應介面耗時情況，運維負責檢查osg&nginx問題,由於我負責的是最下游系統，我檢查我的介面超時情況，偶爾有個別的超時，就反饋超時個數，但是線上超時數量遠遠大於我反饋的數量，再加上各個系統反饋的耗時情況，排查出來不是各自應用的問題，故問題應該在網路的osg/ngnix的問題上，經過運維仔細排查，發現odg的連線數超過4000，就會出現等待連線的情況，故找到原因，加大連線數目，以及減少等待耗時時間。但是這個並不能解決根本情況，我的建議是，根據特定介面，配置資源優先順序，對於面向c端的頻次較高的資料庫insert&update操作介面進行擴容處理，對於頻次較低的介面，配置少量資源，最好可以實現監控&動態擴容處理。
ok上線完成，各自owner觀察各自系統的超時情況，還是發現我自己負責的系統的這個介面還是有偶發的超時情況，雖然影響不大，但是為了保證萬分之1的超時情況發生目標，還是需要檢查問題的所在。
我開始去splunk檢視access日誌檢視發生的時間點，介面耗時情況，介面方法呼叫耗時情況，由於監控的不是很全面，這些日誌很難查詢，這不得不說乙個好的監控系統&日誌系統的重要性了。期間緊急上線各個方法的耗時日誌，只能線上看耗時的打點日誌了，發現在乙個方法的時候耗時很久，進去看是**問題，發現這個方法是在同乙個事務，進行乙個查詢&三個insert操作，單個sql進行檢視sql操作耗時，發現並不久，基本乙個select&三個insert在幾十毫秒就處理完成。那就很奇怪了，到底**出了問題。看這幾天的線上異常分布時間，都在凌晨0-1，5-6以及下午6-7點分布，懷疑是不是本應用任務出現的問題，檢查任務執行時間，發現任務和問題時間不一致，排除掉。去dba諮詢時間段內是不是有定時任務執行，說基本線上io操作頻繁的和我的時間都比較吻合，都在執行頻繁的io操作，比如分賬任務，跑批任務，造成io資源緊張，獲取連線時間比較久，而且據我以前了解，我們公司所有的應用都是使用同乙個oracle，只是分配的schema不同，但是又不能針對不同的schema分配不同的資源，故誰先占有資源誰先執行，造成在資源緊張的時候後續操作會進行阻塞，耗時就要會久一些。故得出結論，是資料庫壓力過大造成的資源緊張導致的應用獲取連線耗時較久。
ok，解決吧，
1:進行資料庫處理，資料庫拆分，任務跑批分散，或者移除到別處執行，可以解決問題，但耗時較久，業務時不能進行等待的。
2:業務進行處理，根據spring的transactional註解有個超時時間設定，鑑於獲取到資源後執行耗時很短，基本都在幾十毫秒以內完成，故可以是指超時時間1s，如果獲取不到資源，返回操作，讓業務方進行重試幾次，如還是失敗，則提示使用者，使用者進行再次操作，只是體驗不是很好，不過可以減少很多的耗時問題次數的發生，並且重試的次數也是***的，不能造成重試風暴，最終導致資料庫掛掉。但這個不是最優解，只是折中方案。
我所知道的最優解：
1:資料庫進行拆分，每個應用使用自己的資料庫伺服器，oracle太貴，使用mysql。
2:對於發生頻次比較高的介面進行監控&動態擴容機制，使用docker應用擴容和mysql伺服器擴容。
3:注意點：冪等操作&超時操作一定要注意到位
覆盤&反思
1:對於公司的架構要喲一定的了解，這樣出現無法下手的問題，可以從整體上進行評估**會出現問題
2:針對個別頻次非常高的訪問介面一定要做好充分的監控&日誌。這個需要經驗積累&業務熟悉&經常關注線上情況
3:查詢出現問題的介面所有的可能行，首先就要看資料庫操作日誌，事務處理是否合適，乙個事務裡面最好只有乙個sql操作，避免使用多個sql放在同乙個事務。
4:所做的修改需要和自己介面的上下游進行充分的溝通，人多力量大，集思廣益出解決的方案。
5:排查問題的緊急程度，並不是你的問題很重要，沒有上公升到一定的階層，你的問題僅僅是自己要去推動，大多數人只是持觀望態度，等著你解決，自己要有owner意識和溝通能能力，主動的推動問題的解決，需要人就拉人進來聊，不能太依賴別人給你解決。如果是對方的問題，對方說不是自己的問題，請對方證明不是自己的問題，不然就是對方的問題。
一次curl超時引發的專案問題思考
最近專案中遇到了一次curl超時，導致了使用者操作寫入失敗的問題 1 curl超時怎樣去追蹤哪乙個步驟導致超時 php 超時原理 一次請求呼叫某個api出現超時的時候我們如何判定是在哪乙個步驟超時了？1 網路原因，請求超時，服務端 未執行，很容易判斷，超時後，服務端無任何操作 2 服務端執行超時，服...
一次線上故障引發的警示
這次引發的線上故障和我有直接關係，現分析一下這次故障產生的原因和經驗教訓，還請大家引以為戒。原因分析 1 在 公升級包開發過程中，編寫偽登陸介面測試用例時走讀介面 發現對介面引數控制不嚴格 判斷引數是否為null 對其重構為更嚴格引數控制 判斷null或空字串 但未考慮到 中的潛規則 呼叫方就是傳遞...
一次快遞經歷引發的思考
最近一次蛋疼的寄快遞經歷引發了我對企業發展的思考，為什麼有的企業可以發展的很好，而為什麼有的企業卻面臨倒閉？2.1 底層員工是企業門面 企業的底層員工是直接接觸客戶的，他們是公司的門面和形象，他們做事的態度和方式直接影響著使用者對企業的印象。乙個企業對底層員工沒有基本的要求，任由其胡亂作為，這對公司...