當你需要設計能夠支援高速和大量業務的關鍵應用系統(例如期貨交易系統)時,要銘記在心的設計的重點是:想要高速,就要盡量減少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+請求的緩衝+當機備援,這系統很夢幻,光是想著都會讓我流口水。

作者簡介


Advertisement

更多 iThome相關內容