Bitcoin Trading Bot Design - 專案review

今天來看作業4的後端作業，這份作業是要設計一個Bitcoin的交易所套利機器人系統，需要有系統設計圖和設計文件，以及使用Rust簡單實現。
作業在這

作業需求

系統設計圖 review

優點：

• 模組化：系統分成不同模組，每一個模組都有特定的功能，這樣有利於系統的擴展和維護。
• 事件驅動：系統採用了Redis Pub/Sub作為消息中間層，這樣可以確保即時數據流動和處理。
• 持久化存儲：系統使用了DatabaseModule來持久化重要的數據，如價格數據和交易結果。
• 通知系統：NotificationModule確保了重要的交易結果可以及時通知給相關人員，提高系統的透明度。
• 監控和日誌：MonitoringModule和LoggingModule為系統提供了監控和日誌功能，有助於問題的及時發現和修復。

建議：

• 數據一致性：當RedisPubSub發送消息給多個模組時，可能會有一致性問題。考慮使用事務或某種一致性協議來確保數據的一致性。
• 異常和錯誤處理：在真實的系統中，交易所的API可能會失效或返回錯誤。DataCollectionModule和TradingModule應該要有策略來處理這些異常情況。
• 過度依賴Redis：系統過於依賴Redis Pub/Sub來傳遞消息。可以使用其他Queue management或使用組合的方法來減少單點故障的風險。
• 價格更新策略：DataCollectionModule從多個交易所收集價格數據，但在價格發生劇烈波動時可能會產生問題。可以使用某種策略或算法來平滑這些數據，以減少假正面或假負面的套利信號。
• 消息的優先順序：在高頻交易中，某些消息可能比其他消息更加重要。可以給Redis Pub/Sub中的消息設定優先順序，以確保重要的事件能夠得到及時處理。

Readme review

優點：

• 完整性：README包括了系統的所有主要模組以及它們的交互。
• 系統圖：系統序列圖和組件圖提供了系統架構的清晰視覺表示。
• 解釋技術選擇：解釋了為什麼選擇Redis Pub/Sub而不是其他如Kafka，以及其在此特定應用中的優勢。
• 提出設計問題：指出了在設計和運行此類系統時可能需要考慮的關鍵問題，如Redis隊列長度、交易所API限制等。

建議：

• 背景資訊：README的開頭可以提供一些背景資訊，解釋什麼是套利和它在加密貨幣交易中的重要性。
• 深入描述模組：每個模組的描述都很基本。可以考慮對每個模組進行更深入的描述，解釋它是如何工作的，使用了哪些技術等。
• 實踐細節：可以提供一些更具體的實踐細節，如使用的特定技術、工具或算法。
• 交互實例：可以提供一個或多個系統交互的例子，以更好地理解系統是如何在特定情況下工作的。
• 錯誤處理和異常情況：描述系統如何處理可能的錯誤或異常情況，如Redis中斷、交易所API故障等。