上一篇提到訊息代理 Message Broker 的基本用途，而這篇我們進一步來看看 Message Broker 兩種不同的 Pattern。

在討論系統設計時，我們時常會聊到 Message Queue，我最初分不太清楚 Message Queue 和 Message Broker 有什麼差別，也不太懂一種叫做 Pub-Sub 的行爲和 Queue 是否有關聯。

更甚者，我還聽過類似 Pub-Sub 的名詞：Producer-Consumer，當時這又讓我更困惑了，究竟他們有什麼不同？因此，今天就來釐清這些不同的概念和名詞吧！

過去人們的溝通方式主要是透過口語及書信交流，遠距離的溝通效率低下，而且很容易受到環境的影響。但現代社會中，只要有網路覆蓋的地區，我們的資訊都能透過 TCP/IP 的架構所傳遞，效率相對於過去提高了非常多。

但是在此架構下，我們需要考慮的事情也多了許多。例如要思考傳送訊息時對方是否在線上？不在時該怎麼處理；如果傳送的訊息一下太多，系統負荷不了該怎麼辦？

由於訊息傳遞的速度太快，我們不能依靠人工來決策並處理，而是需要一套完整的邏輯來處理這些瑣事，以下便來整理我學習 System Design 時，關於傳遞訊息時需要考量的重要設計：訊息代理。

當我們在做軟體的架構設計時，資料庫的 Non-Functional Requirements 絕對是必要考慮的一環。例如 Performance（如回應時間）、Data Integrity（如資料一致性）、Availability（每年的 Uptime 比例） 等等。

如果要將資料庫設計成 HA（High Availability，高可用）的話，可能至少要讓每年的 Uptime 大於 4 個 9，也就是 99.99% 的時間都能正常使用（大約每年小於 50 分鐘的 Downtime）。

而單機的資料庫一旦發生什麼故障，由於需要人工介入修復，停機的時間超過 50 分鐘基本上是不可避免的。因此增加冗餘、增加機器的數量基本上是要達成高可用的唯一途徑。

這篇文章來看看如果要達成高可用的儲存架構，如何用雙機，也就是多一台機器的冗餘要增加資料庫的可用性。