23.kafka心中的事件溯源
1 楔子
早些年，我還在學校學習DB的時候，設計表結構是件非常嚴肅和講究范式的事。那時天是藍的水是綠的，存儲系統(tǒng)很昂貴，程序員還是一個體面的職業(yè)，大學生對生活充滿了期望，即使找不到工作，去科技市場賣光盤也能獲得一筆不錯的收入。那時數(shù)據(jù)存儲以企業(yè)ERP為主，程序員為了把盡可能多的數(shù)據(jù)塞入到狹小的存儲空間中，往往需要親手榨干最后一滴腦汁，盡可能把表字段設計成正交的。
后來，互聯(lián)網(wǎng)興起，大學生擴招，存儲便宜了，房價也上漲了。為了支撐越來越多的OLTP線上業(yè)務查詢，人們開始接受在DB表中冗余部分數(shù)據(jù)，同時索引也越建越多，以便縮短從用戶點擊鼠標到看到數(shù)據(jù)之間的響應延時。
后來，移動互聯(lián)火熱，研究僧擴招，京牌京戶成為傳說。為了幫老板掙到二房的錢，微服務和996興起。單一的MySQL存儲已經(jīng)不能滿足我們的服務熱情，我們會額外提供Cache加速數(shù)據(jù)讀取，提供Index方便全文檢索，提供匯總數(shù)據(jù)方便領導做PPT。并且由于PM學歷穩(wěn)步提高，他們的思維也更加開闊，不再拘泥于從國人身上抄襲。為了滿足各類思想實驗，程序員必須能以更快更敏捷的方式提供數(shù)據(jù)邏輯。時至今日，996已經(jīng)逐漸不能滿足人民日益增長的物質文化需要，997開始發(fā)出時代的吶喊，逐漸成為主流。
這中間遇到的一個千古難題是：如何保證MySQL, Redis, ElasticSearch, Hive等不同平臺的數(shù)據(jù)一致性？一代又一代的程序員用自己的發(fā)量證明這根本可能是一個NP問題：2PC既慢又脆弱，TCC對業(yè)務邏輯要求太高，Cache Aside只能勉強解決緩存一致性問題。
看著手上逐漸失去效用的維生素E乳，程序員突然覺得，是不是應該對自己好一點？
程序員滿含熱淚，跪在佛像面前，請大師解惑。大師遞給程序員一張紙條，上書三個大字：fit your life。程序員恍然大悟，抬頭問大師：『您的意思是要我健身？』。大師說：『你誤會了，我的意思是說你們平時用的Kafka，配合Event Sourcing（事件溯源），就能很好的解決現(xiàn)在的問題，但關鍵是FIT』
FIT = Future + Isolation + Transaction
2 Future：對未來的自己好一點
簡單設計的DB一般只保存數(shù)據(jù)項的當前狀態(tài)值，而Event Sourcing（事件溯源）構架，則以記錄event的方式，把數(shù)據(jù)項的完整更迭歷史保存下來。這樣，我們不僅可以查到的數(shù)據(jù)的當前狀態(tài)值，而且可以通過完整歷史，重演數(shù)據(jù)項的變化過程。
這項技術，以前多用戶于金融領域，畢竟金融需要審計的嘛。后來，被引入到微服務設計模式中，但是，由于實現(xiàn)復雜，且思考方式迥異于常人，口號響亮，應者了了。
但是，在加入Kafka之后，一切都不一樣了。上一期文章《22.神說，kafka其實是個數(shù)據(jù)庫》中，簡單提到過這一點，當時我把它稱為事件流（event stream）。這里重新引用一下：
事件流（event stream）提供了一種新的思路：以Kafka為例，應用server將操作以事件的方式追加log到消息隊列中，待修改的DB, Cache和Index分別在不同的消費組內(nèi)消費相同的event log。如果在消費過程中，其中某一個進程crash了，則等待進程重啟后，從最后一次消費的offset處繼續(xù)消費就可以了。
上圖中的Index, Cache, DB，我們有時把它們統(tǒng)稱為Materialized Views（物化視圖），它們是同一數(shù)據(jù)的不同展示形式，用于支持不同的查詢。
Event Sourcing優(yōu)點之一是：對于重要數(shù)據(jù)，我們可以在Kafka中保存完整的歷史更迭記錄。在未來任意時刻，無論PM提出什么新需求，都可以通過編寫新的代碼，并重新訂閱這一主題而生成想要的結果，同時對系統(tǒng)的其它部分毋需任何改動和影響。
而對于沒那么重要的數(shù)據(jù)，比如崩潰日志，也許我們只需要保存最近7天的數(shù)據(jù)，確保運維安全就可以了。這樣，萬一上線的代碼有bug，或者消費進程意外崩潰了，7天的數(shù)據(jù)可以給我們留出足夠的時間修復bug，并重新跑一遍近期的數(shù)據(jù)，拿到正確的結果。
3 Isolation：讀寫分離
看到這里，你也許會覺得Isolation對標讀寫分離有些怪怪的，其實我也覺得怪怪的。讀寫分離在中國一般指MySQL寫走主庫，而讀走從庫。在本篇文章中，讀寫分離的等價物實際上是CQRS（Command Query Responsibility Segregation）。
但是，我仍然愿意把它稱為Isolation，因為它能幫我湊出一個單詞FIT來。在任何時候，讓人們?nèi)菀子洃?，比表述準確要重要的多。而且，反正我的文章也幾乎沒寫過什么正經(jīng)的東西，湊合看吧。
讀寫分離的重點是：讀不關心寫，寫操作毋需為讀操作做索引優(yōu)化。
這太重要了?，F(xiàn)行的微服務架構中，一個初看很美，靜看心痛，細看白頭的問題是：讀和寫都依賴同一臺MySQL數(shù)據(jù)庫，為了支撐越來越復雜的查詢邏輯，不斷的往數(shù)據(jù)表上加索引。而索引越來越多的問題至少包括：
因為數(shù)據(jù)落庫需要同步修改索引，寫入的TPS越來越低。
索引擠占了大量本來可以存儲數(shù)據(jù)的磁盤空間，結果本來可以存1T的數(shù)據(jù)，現(xiàn)在只能存500G了。
隨著數(shù)據(jù)量變大，線上創(chuàng)建新索引越來越耗時，為了不影響線上業(yè)務，我們有時需要請出在線DDL工具，比如gh-ost。
魯迅說，專注的女孩子最美。在讀寫分離架構中，我們通過不同的Materialized Views（物化視圖）支持不同的讀業(yè)務，前置Kafka的作用只有收集事件流，因此可以獨立優(yōu)化，互不干擾。
4 Transaction：代替2PC
好吧，我承認我吹小牛了，2PC（兩階段提交）是非常重要原子提交協(xié)議，不是隨隨便便出來某一個路人Kafka就可以代替的。
但是，如果手動編碼的話，2PC的性能和穩(wěn)定性也是出了名的感時花濺淚。
延伸閱讀《19.分布式事務之2PC：兩階段結婚》
基于Kafka的Event Sourcing架構，提供了一個以最終一致性為目標的高性能 &高可用的解決方案。廢話不說，上圖為敬。關于Kafka事務實現(xiàn)的更多細節(jié)可移步上一期文章《22.神說，kafka其實是個數(shù)據(jù)庫》。
你不會以為最終一致性比線性一致性慢，對吧？
5 又挽救了一個程序員的發(fā)量
聽完大師的講述，程序員豁然開朗，感覺一條康莊大道出現(xiàn)在面前。程序員含著熱淚轉身走出大殿，后面大師默默地收起手里的剃刀，暗嘆一聲：『這個月的招人計劃又完不成了』。突然，大師仿佛想起了什么，跑到大殿門口，對著已經(jīng)走出大門的程序員高喊：『施主，看完記得點關注啊~』