那個無論「萬一」的程序員後來怎麼樣了？

不怕一萬，只怕萬一呀，朋友。

「這個狀況很極端確定不會遇到，無論了」

從前，有個程序員叫小明，他在開發一個股票的投資組合功能。這個功能簡單的來講，就是一個投資組合裏有現金、股票等資產，咱們根據組合裏股票漲跌等狀況，給出一個總體組合的指數，以評判組合的水平。

聰明的小明在開發的時候就發現了，若是存在現金爲0，而且所持有的股票都退市了的話，這個股票指數的計算就會存在問題。小明想：「現金爲0的狀況不多，退市的狀況就更很少，這個狀況很極端，確定不會遇到，實現異常狀況處理的邏輯也很複雜，測試確定也發現不了，無論了」，因而代碼就歡快地跑到了線上。

隨着業務的發展，投資組合愈來愈多了，也隨着政策的轉向，退市的股票也陸陸續續地變多了。某一天，夜裏跑批報錯了！告警短信在夜裏發到了小明的手機了，小明只好半夜跑來公司排查問題，原來以前考慮的狀況真的出現了，小明內心暗罵了一句，還TM真的出現這狀況了！罵歸罵，小明運用他聰明的大腦，從新看了一遍邏輯，分析了各類狀況，而後給出了在這種狀況下指數的跑批值應該是多少，通過一次又一次戰戰兢兢的複覈計算，最後戰戰兢兢地把數據一條一條地更新到了數據庫。通過一番折騰後，已經快早上5點了...次日跟領導解釋了狀況，說這種狀況不多見，咱們後續抽時間把這塊的邏輯補上！

然而在此次事故的不久以後，小明還在想啥時候開始補這塊邏輯時，小明夜裏又收到了投資組合模塊的告警短信.....

「只要不考慮宕機這些極端狀況，基本都沒有問題」

從前，有另一個程序員叫小王，他在作一個完成交易時給用戶的積分帳號加積分的功能，訂單與積分在不一樣的數據庫，這涉及到一個分佈式事務的問題。

聰明的小王早就知道了有不少形態能夠解決這個問題，最合適的固然是MQ，可是目前系統沒有MQ要額外加入維護，很麻煩；TCC也能夠，但要寫額外的代碼，也好煩；2PC嘛，好像沒有合適的，性能也聽說不高，不選；Best Efforts 1PC,這個不錯！性能比2PC高，無需額外編碼，大多數狀況下能有強一致性保證，惟一可能出現異常的狀況就是在commit階段，若一個數據庫事務提交了，另一個數據庫事務因爲宕機提交失敗的話，纔會出現不一致，這狀況多少見呀！就Best Effors 1PC啦！出問題我手工給他補上就好啦。

因而代碼就輕鬆愉快地上線了。

隨着業務的發展，業務範圍和交易量也在逐步地變大，小王寫了一個新功能準備更新到交易服務裏，公司裏有超強的滾動發佈，上線過程很愉快的就完成了。完成驗證後，小王心滿意足地跑回家睡覺了。

這個小王比較幸運，睡到了次日上班。而後客服部傳來消息，說客戶投訴，其交易沒有產生積分！小王一會兒就猜想到多是昨晚滾動升級服務下線的時候，沒有作優雅停機相關代碼設計，致使Best Effors 1PC失敗了，因而小王翻了下日誌和數據，排查出果真是這個問題致使的，實際還有額外幾條數據也有這問題，小王一併修復了這些數據問題，雖然小王很聰明，但這個修復過程也佔用小王一上午的時間。同時，小王也決定，給加上優雅停機的相關邏輯。後來再也沒有出現過因爲更新致使的不一致了。

再隨着業務的發展，用戶交易量也跟着上去了，然而在一個交易較爲頻繁的時段，忽然飈出來不少告警，機房內網絡也不穩定，通過一排查，原來是網絡設備出現了問題，通過一小段時間折騰網絡恢復了正常。而後小王內心帶着忐忑地去翻看交易服務的日誌，發現出現了大量的報錯，還有很多報錯是顯式提示BestEffors1PC在Commit階段的錯誤！統計了一下，此次可不是手工能解決的問題了.....

小王寫了一個批量數據修復程序，開始在生產跑了起來，但小王開始想，我用BestEffor1PC是對的麼？

那個無論「萬一」的程序員後來怎麼樣了？

相信你們都聽過墨菲定律，就是說，你越擔憂的事情，越有可能發生。

固然，這不符合咱們程序員嚴謹的風格。咱們萬事都要量化。小明同窗的案例中，即便出現的機率是萬分之一，但當組合數量達到十萬個呢？達到百萬個呢？是否是就會變得常常出現了呢？小王同窗的案例裏，因commit要走網絡等IO，這個整個過程要1-2毫秒不過度吧？當TPS增多，這個1-2毫秒的危險窗口是否是就遍及整個時間範圍了呢？這個時候隨便發生下網絡抖動，會怎樣呢？

寫程序有一個特色就是，寫了一次，計算機會幫你執行無數遍，而你無需付出任何額外努力。但咱們人工重複執行一件事情，卻要咱們每次都付出精力與時間。

若是咱們在寫代碼時放過的萬一通過的評估是：一年都不會發生一次的話，我的認爲你是能夠強行閉上眼睛無論這個萬一的。

可是誰能評估準呢？當發生了的時候，你要作的補救措施就是你當時遺漏的邏輯。當發生須要人工補救的狀況時，所需付出的努力甚至要遠大於你當時完成這段邏輯付出的努力。

所以，小明和小王以後都懂得了 「出來行，早晚要還」的道理，再也不放過任何一個萬一。

做者簡介：某信用卡中心架構師，多年金融行業經驗，從聯機交易到深度學習都有所涉獵，開源分佈式事務框架EasyTransaction做者。歡迎關注我的公衆號，在這裏我會分享平常工做、生活中對於架構、編碼的思考。