近期開發的系統b遇到乙個bug，經排查發現問題是乙個截斷導致的。
系統的部署情況是：a與b是通過網路進行通訊，系統b是多機部署，b之間是對等的。系統的處理流程如下，a發請求1給b，b處理後在響應2中會回帶一些資訊給系統a，系統a進行一些其他的處理工作，然後將2中b回帶的資訊通過請求3透傳給b，b發現透傳過來的資訊被截斷（1%的概率），導致處理結果非預期。
問題已經很明確，直接的方案如下：
方案一：系統a排查哪個環節存在截斷，進行修改
方案二：b系統精簡回帶給a的資訊，或者是進行某種形式的壓縮
方案三：b系統將回帶資訊儲存到某個公共儲存，在請求3到來時根據請求的關聯字段查出回帶資訊
鑑於是線上問題，解決方案必須簡單快速。a系統邏輯複雜，涉及到的業務眾多，通過版本解決的進度慢、涉及面廣，時間成本和風險較高。另外，如果a能透傳的限制加大，但是b系統仍然對回帶首席資訊官度不做限制，未來還會有截斷的風險。因此方案一不會優先考慮(跟系統的實際情況緊密相關)。
由於a系統本來就支援回帶透傳的功能，b系統自己做資訊儲存和讀取，需要額外的工作量，也會增加系統的複雜性，新的邏輯也會因為新的網路互動，帶來一定執行時間開銷和潛在風險，改動量也較多。因此方案三也不會有先考慮。
方案二，經過分析，回帶的資訊相當多，但最終只是為了請求3到來時，b能根據這些資訊選擇出要處理某資料庫表中的n（n<10，且多行關鍵字段有相同的值）行中的某行（配置資料）。因此，又有方案：是否可以在請求1的時候將表的行號帶出即可？
原則上，只要行號沒有人、系統去變更，是沒有問題的，但是行號並不是配置的內容資訊，一旦有人將行號變更，將是很危險的。
那麼是否可以壓縮？只是一定程度的解決，同a系統找到截斷的地方進行修改是一樣的，暫時解決問題也是可以的，但是不是很優。
將所對應的那行配置中用到的關鍵資訊根據一定的方式算出乙個簽名，比如md5，進行回傳，在處理請求3時，根據md5過濾出該處理的那行。（b系統對報錯易容忍，對處理錯誤難容忍，配置變更找不到會報錯）
好，問題基本解決了，修改（新版本相容老協議）、測試、上線了，上線過程中，運維人員進行了灰度上線，灰度了b中的一台，並且執行了一段時間，才發現問題：沒有公升級的b處理不了公升級的b回帶的按新協議回帶的md5值，導致未公升級的b進行請求3的處理的時候失敗了。測試的時候，測試人員並沒有將b多機部署，造成問題沒有及時發現，釀成問題。
總結一下：
（1）系統a提供了透傳資訊的機制，但是當量變不斷積累時可能引發質變，導致bug的出現。開發系統的時候要特別注意，比如開啟的檔案不斷增多，建立的連線不斷增多，某些資訊越來越長，掛載的so越來越多等，都可能造成量變到質變，發生危險。需要有一定的風險意識，在開發階段進行評估。
（2）當協議發生變更時，新版本的系統能相容老協議，但是老版本的系統無法處理新協議。因此如果確定要做協議，一定是不得已時才確定做，當真的做了協議變更時，一定要重視上線方案的討論。
開發中遇到的問題記錄
jquery相關問題 1.html 方法無法獲取到input中的value tomcat相關問題 1.web.xml中 do配置導致tomcat無法啟動 intellij idea中怪異出錯bug，tomcat中和main中md5加密不一致 在tomcat下，getbytes eclipse按utf...
遇到的幾個小問題，記錄下
1 往資料庫裡插入新的資料，判斷是否存在，呼叫的儲存過程 create proc dbo n inserttemplate temenaglishname nvarchar 50 tempurl varchar 50 staticpageurl varchar 200 asdeclare rows ...
Oracle中的幾個問題記錄
自己是乙個新手，所以在學習oracle資料庫中遇到了不少的問題，後來通過請教同學和在網上的搜尋，慢慢的也就明白了一些小的道理，在這兒記錄下來我的一些錯誤和不足，以免再犯。前車之鑑，後車之師。1，在oracle資料庫之當前的系統時間 不管是insert還是select，有事會用到系統時間，在oracl...