緣由
新系統重構中，收穫了乙個重要的設計教訓。
事情是這樣滴，如下圖所示：
有乙個 hbase 表 oe_item 存放訂單商品相關的交易資訊，rowkey 設計為 「訂單號_olditemid」 ，是通過 storm 同步任務處理 old_item 表的binlog訂閱寫入該錶的。oe_item 的量級很大。
在老的實現方式中，由於應用在訪問這個表之前無法取到訂單的olditemid, 因此，需要拿到訂單號去 scan 這個表。顯然這個開銷是很大的。當需要訪問大量訂單的 oe_item 資料時，併發訪問這個表會導致超時，執行緒被hang住，進而影響系統整體穩定性。若有可能，應該乾掉 scan oe_item 這個威脅系統穩定性的耗時操作。
系統重構後，通過詳情api介面，能夠獲取到新訂單及newitemid, 能夠獲取到老訂單及olditemid。顯然，對於老訂單來說，可以用_拼成 rowkey 來 batchget oe_item 表； 然而，對於新訂單，由於無法獲取到olditemid, 這使得要獲取新訂單 oe_item 表的資訊，依然要 scan 這個表，而不能替換為 batchget, —— 眾所周知, batchget 操作通常比 scan 操作的效能要更好，獲取大資料量時穩定性更優 ， —— 因此，錯過了優化系統穩定性的乙個關鍵環節。是不是很蛋疼 ？
教訓
要敏銳地主動發現舊設計的一些過時之處。即使當時不能解決，也應記錄下來，當機會來臨時進行重構優化。
在新系統重構中，及時用新設計來取代和相容老設計。在這個例子中，如果在系統重構中，將 rowkey 設計為 新訂單 -> ""，老訂單 -> ""，就可以用 batchget 取代 scan ，大幅提公升系統在獲取大資料量時的穩定性。
在沒有對整體設計足夠清晰之前，不要急於著手去解決乙個問題。 倉促地解決乙個問題，會導致解決不足，繼續受到該問題的困擾，之前的方案甚至會造成束縛。
敏捷設計並不是不做充分的思考和設計，而是強調不要「過猶不及」； 完成當前需要的，並為擴充套件預留空間。 這實際上需要更充分的設計考量。
比如做訂單匯出配置化時，我是採用小步優化逼近的方式來實現配置能力的。這固然也能解決問題，但是當面對新問題時，時而有某個地方考慮不周到，需要再修改**和發布。 這即是因為在整體設計上沒有思考的足夠清晰，沒有足夠的融會貫通， 以致於總是紕漏百出。
因此，解決問題，要從整體設計上盡量考量得足夠清晰，然後再下手去做。
這裡說的是，當建立新模型時，不要去相容老方案，否則永遠都沒法擺脫歷史包袱。
比如做新退款資訊獲取的時候，當時貪急求快（也考慮到退款金額不對導致訂單狀態不對，會誘導商家誤發貨）， 就沿用老方案的儲存，將新退款的資料也儲存在老的退款 hbase 表裡， 結果新老退款都需要去 scan 這個表，效能開銷甚大，而且對穩定性有影響。
正確的做法應該是， 針對新模型，建立新方案的儲存，然後在應用中聚合兩種方案，分流，冷卻老方案的儲存和獲取，一段時間後，就會自動切換到新方案上，擺脫老方案的歷史包袱。
約定勝於配置。 良好的約定，可以使得系統的互動和整合更加簡潔清晰， 而不需要考慮過多的情況，導致複雜度上公升。
比如匯出擴充套件欄位時，約定擴充套件欄位在下單表裡的儲存形式，然後匯出按照這種約定去獲取相應資料。 除非下單儲存有誤，否則匯出是不會有問題的，省了很多事。
在設計儲存的時候，就要想到如何去使用。
think deeper, design better.
FPGA設計經驗教訓雜談
做fpga設計的工作也有一段時間了,有過問題迎刃而解的快樂,也有過苦苦尋求結果和答案的痛苦歷程.現在就把我個人曾經在專案中經常遇到的問題和犯的錯誤總結一下.希望對大家有啟示和幫助 1 fpga和其他電路的介面部分的時序要處理好,要考慮到訊號進入fpga之前的線路延遲.要想清楚進入fpga的資料和時鐘...
MySQL經驗教訓
mysql語句如下 select buyer id from baoxian.bc insurance order where id in 100000422,100000418,100000417,100000416,100000415,100000413,100000411,100000410,...
CSS 經驗教訓 IE HACKs
1 在ie下最外層邊框無顏色。table td,table th 解決辦法 對table本身也要設定顏色 table,table td,table th 2 字型顯示不正常。h5 在ie中對中文將使用arial 找不到，所以用宋體 其他瀏覽器中文使用 微軟雅黑 英文使用arail 解決辦法 h5 3...