背景
最近做的乙個專案中，用到了目標驅動架構模式，但由於目標下發的不準確，導致出現了線上bug。
目標驅動
目標驅動是通過不同的輪詢目標的狀態，決策出需要達到的目標，使得狀態能到達到最終的目標；
簡單點的意思就是不斷迴圈著四種狀態：輪詢—>決策—>傳送目標—>達到目標。
目標驅動有什麼好處的？
系統a可以專注資料的收集，系統b可以進行目標驅動，使得系統c最終可以達成目標
假如沒有目標驅動，系統a即要資料的收集，資料的目標決策，資料的最終狀態下發管理，通知系統c
系統b可以一次處理多份資料，產生乙個最終目標下發給系統c
資料的目標決策過程可能是非常複雜的，資料的變更，依賴系統的變更等也可能導致需要下發的目標改變，這樣目標驅動可以統一判斷這些資料的變更和系統的依賴；如果不是目標驅動，是不是資料變更的時候需要下發目標，依賴系統變更的時候，也需要下發目標，導致鏈路分散
bug分析
專案中的**邏輯demo如下：
public
void
poolstatus()
throws exception
}private
boolean
validate
(data data)
catch
(exception e)
}private
void
syndatatosys
(list
validatadatalist)
從**可以看出輪詢、決策和下發目標的過程，那導致目標下發不正確的地方到底在**呢？
聰明的同學可以看到是在validate函式的思考那裡了
原因是這樣的
validata函式是對data進行決策的過程，但是validata是需要通過第三方系統等進行決策的
假如第三方系統丟擲異常的時候，把異常catch住了，並且返回的是false
那就是說validata函式過濾掉了這data
便導致下發的目標沒有data了
正確的處理
應該是異常catch的時候，log日誌後，應該直接丟擲異常
這樣決策的過程便會停止，不會導致錯誤的目標進行下發
後續改進
目標驅動應該是應對比較複雜的目標決策與下發的，但專案中的使用到的目標驅動用於配置的下發，配置是乙個很關鍵的設定，比如系統a設定了什麼，就進行修改配置
不能因為第三方系統的錯誤，而決策出錯誤的狀態，這是乙個很致命的操作
如果決策是乙個很複雜的過程，需要進行故障的測試，保證決策的狀態正確
記一次由於快取導致的bug
bug描述 有一張資料庫表儲存的是 值日員工資訊，有時候可能一次性錄入1個月的資料 有時候也可能隔了很多天沒有錄入資料，也就是說這個錄資料不是很規律。bug現象 測試人員發現，上三亞地區能正常顯示當天值日員工資訊，但是珠海地區卻不能正確顯示當天值日員工資訊。而資料庫上實際是有珠海地區值日員工資訊的。...
記一次前端bug排查
前言 時隔三年，終於記得要找回賬號密碼開始寫筆記了，這周剛加入了乙個後台管理系統專案，測試反饋系統重新整理時經常會直接登出，嚴詞要求解決這個 重大 bug，so尷尬。更嚴重的是發現系統在ie上直接登不進去，嬸可忍叔不可忍，於是我開啟了苦逼的尋bug之路。既然是登出了，當然會有登出請求，chrome重...
記一次sum SQL 統計BUG
create table asgard share records id bigint 20 not null comment 分享記錄id status tinyint 3 unsigned not null default 1 comment 資料狀態 1 正常 0 刪除 create time...