高速大量業務的應用架構關鍵

當你需要設計能夠支援高速和大量業務的關鍵應用系統（例如期貨交易系統）時，要銘記在心的設計的重點是：想要高速，就要盡量減少I/O，尤其是硬碟的I/O；想要大量，就要有緩衝空間。

先看「高速」的部分。想要減少硬碟I/O，就必須盡量讓計算直接在記憶體內完成。在記憶體計算的速度雖然很快，但記憶體有一個致命的缺點：一旦斷電，資料不復存在。為了這個原因，資料還是有寫入硬碟的必要，但寫入的速度必須非常快。

關連式資料庫管理系統（RDBMS）的寫入速度是很慢的，一個表面上簡單的寫入，內部卻有許多操作要進行（搜尋、定位、讀取、計算、寫入、調整相關的索引.. .），所以無法滿足我們這裡對於極快速寫入的需求。這時候Event Sourcing的儲存會是比較好的選擇。

Event Sourcing的儲存方式是：一筆一筆地紀錄資料的所有操作過程，而不是只記錄資料的當前狀態。舉例說明，Event Sourcing的儲存方式不是記錄當前的帳戶餘額，而是紀錄你的帳戶從開戶以來的所有操作，包括每一個存入、取出、轉入、轉​​出、扣款、利息入帳等操作，要把這些操作記錄都累計起來，才會得到當前的帳戶餘額。

為什麼這種紀錄方式的寫入速度很快，因為每個成功的操作會化為一個事件，直接把該事件記錄到事件日誌的尾端，不需要搜尋、定位、調整索引等附帶的行為。

你現在一定有一個疑問：要把這些操作記錄都累計起來，才會得到當前的帳戶餘額，這會不會很耗費時間？其實Event Sourcing的儲存方式會在系統不繁忙的時候（例如深夜）把這些累計先算好，變成一個所謂的「快照」（snapshot）。下次只要讀取快照的狀態，加計快照後更新的那部分就好了。

附帶一提，除了寫入的效率高之外，Event Sourcing還有另外兩個明顯的好處：1. 可以輕易而快速地回到過去 2. 資料有時間維度，適合做深入的行為和趨勢分析。這不是本文章的重點，所以不展開說明。

不是所有的系統都適合使用Event Sourcing的儲存方式。 Event Sourcing的特點導致它無法像RDBMS那樣做很複雜的各種關聯查詢，所以Event Sourcing一般被視為Store（儲存空間），而不是資料庫管理系統（DBMS）。

設計良好的微服務由於獨立且體積小，更重要的是微服務內部的資料也彼此獨立，非常適合使用Event Sourcing的儲存方式。例如在賬戶的微服務裡面，我的賬戶和你的賬戶之間彼此獨立，我的事件日誌和你的事件日誌可以分開記錄在各自的軌跡（Track）中，這麼一來讀取的時候更方便，也有助於隱私權的保護和後續資料的遷移。

Event Sourcing是個實現起來簡單卻能產生特殊效益的資料儲存方式，我在「技術應用的艱辛探索」一文中提到我自己研發了一套技術框架，其資料儲存方式正是Event Sourcing，這就是為什麼我對於Event Sourcing這麼有經驗的原因。

這篇文章的主題是「高速大量業務的應用架構關鍵」，以上描述的是「高速」的部分，接下來描述「大量」的部分。當請求量大的時候，可能會處理不及，需要在記憶體內安排緩衝空間（Buffer）。這個緩衝空間可以採用經典的環狀結構，這部分我不再贅述。由於緩衝空間也是在記憶體內，如果擔心請求會丟失，也可以在這裡使用高速的Log。

上述描述的技巧讓你的系統可以滿足高速且大量的業務（例如秒殺平台），但對於非常關鍵的業務，還需要做到高可用性（High Availability），這時候最簡單的方式是部署兩套一樣的系統，同時接收相同的業務請求，兩套系統要把請求的次序統一起來，但只有其中一套真正會進行計算，另外一套會監聽主系統的心跳，一旦發現對方心跳異常，自己立刻啟動計算，進行任務的備援。

記憶體計算+微服務+Event Sourcing+請求的緩衝+當機備援，這系統很夢幻，光是想著都會讓我流口水。