先舉個例子：電商系統，用戶下單可以使用卡券支付。此時，訂單的金額會有兩部分構成：商品金額 和 卡券抵扣金額。通常，這樣的信息在訂單詳情頁也會展示出來。那麼，我們的訂單表裡，關於金額，應該有三個欄位：商品金額、卡券抵扣金額 和 訂單金額。 先舉個例子，在ToB的系統中，客戶通常會通過銷售代表來引入和維 ...
先舉個例子：電商系統，用戶下單可以使用卡券支付。此時，訂單的金額會有兩部分構成：商品金額 和 卡券抵扣金額。通常，這樣的信息在訂單詳情頁也會展示出來。那麼，我們的訂單表裡，關於金額，應該有三個欄位：商品金額、卡券抵扣金額 和 訂單金額。
先舉個例子，在ToB的系統中，客戶通常會通過銷售代表來引入和維繫。那麼，系統里會有一個保存客戶與銷售代表之間關係的 客戶關係表 。當客戶產生交易後， 交易表 除了要記錄客戶信息外，還要記錄當時的銷售代表。因為在企業實際經營過程中，客戶與銷售代表的關係會發生變更，例如某某銷售代表離職或調崗，其負責的客戶會轉交給其他銷售代表。
交易表 記錄交易發生時的銷售代表，就是我所說的“當時”。
相應地，在企業管理系統里，會有兩種查看或統計銷售業績的需求，第一種是依照當時的客戶關係來查看，另一種是依照當前的客戶關係來查看。
第一種需求很好實現，因為在 交易表 里記錄了銷售代表。
那麼，第二種需求怎麼實現呢？
第二種需求就是通過 交易表 與 客戶關係表這兩張表進行關聯來實現。這似乎也很容易理解。
那麼，在分散式系統中，當 交易表 和 客戶關係表分屬在 交易系統 和 CRM系統 時，對於上面的第二種需求，該如何實現呢？
我先列舉兩個不當的解決方案。
1.
2.
比較好的解決方案，可以將 CRM系統 的 客戶關係表 的數據同步到 交易系統 里。這樣就可以像上面那樣的兩表關聯來實現了。
你也許會擔心數據的一致性問題。對於這個擔心，可以考慮使用消息隊列的方式，保證消息的可靠傳輸。然後，由 交易系統 發起，定期與 CRM系統 比對客戶關係數據。畢竟， 客戶關係表 是個瘦表，數據量並不大。
當看到一些不好的代碼時，會發現我還算優秀；當看到優秀的代碼時，也才意識到持續學習的重要！--buguge
本文來自博客園，轉載請註明原文鏈接：https://www.cnblogs.com/buguge/p/16907571.html
