相對於傳統的hadoop這樣的batch分析平台，流式分析的優點就是實時性， 即可以在秒級別延遲上得到分析結果 。
當然缺點是, 很難保證強一致性，即exactly-once語義 （在海量資料的前提下，為了保障吞吐量，無法使用類似事務的強一致性的方案）。
一般流式分析平台都會promise較弱的一致性，即least-once語義，保證資料不丟但允許資料重複。
但這只是在正常的情況下，當流式分析的任一環節發生故障，整個流被堵塞時，會導致層層佇列被打滿，最終仍然是會丟資料的。
所以對於流式分析平台，如果要保證一致性，必須借助外部的replay的能力。
storm的作者nathan在how to beat the cap theorem文中提出著名的lamda架構來解決實時系統的一致性問題。
原理其實很簡單，既然流式分析沒法保證一致性，那麼我們就用hadoop存全量資料，通過batch資料分析來保證強一致性。
流式分析只用來計算實時熱資料，而冷資料由離線計算來做，使用者查詢的時候，只需要把兩份資料做下merge。
從嚴格意義上講，這個不能算beat cap，因為只是結合batch分析的強一致性和流式分析的高可用性而形成的架構。
但確實給流式分析如何保證一致性，提出了乙個非常有建設性的方案。
lamda架構的缺陷也很明顯，太複雜，太重，需要搭建實時和離線兩套系統，對運維而言成本過高。
更麻煩的是，分析邏輯需要實現兩次，雖然現在有類似summingbird這樣的方案，但還是比較理想化，面對海量資料的現實，還是很骨感的。
針對這個問題，linkedin的架構師jay kreps在questioning the lambda architecture文中，提出一種單純基於kakfa和流式分析的架構，
原理也不複雜，就是充分利用kafka的replay能力，只要磁碟足夠，用kafka可以儲存足夠久的資料 。
並且由於kafka的資料存在磁碟上，是可以被重複讀取的，這也是kafka在流式場景下更優於其他佇列中介軟體的原因。
1. 用流式job_n去實時計算熱資料，結果存入table_n，可以用於使用者實時查詢 。
2. 在需要的時候（發生故障資料部分丟失或處理邏輯發生變化）開啟流式job_n+1來處理全量資料，存入table_n+1，當資料catch up的時候，把使用者流量切到table_n+1 。
3. 刪除job_n和table_n。
這個架構比較輕，並且確實可以在很大程度上解決流式分析平台的一致性問題，也可以用做參考。
但是對於我們的場景，這個方法太理想化：
原因是資料量太大，儲存7天的日誌需要近2pb的磁碟空間（kafka需要做replica）。
如果要在可接受時間範圍內replay完這些資料，所需要的分析資源也是很難滿足。
並且線上業務做資料來源的切換也不是那麼簡單的事。
所以我們的思路是，補全丟失的資料，而非replay全量資料。
步驟1. 重置線上job至kafka latest offset，讀最新的資料。
用線上job去補舊資料，會很影響使用者的體驗，因為實時流量本身就很大，catchup的速度會比較慢，會導致使用者長時間看不到最新日誌。
步驟2. 找出需要補全資料。
這步方法有很多，我們的方法是，
用monitorbolt提供實時業務監控，我們可以知道服務什麼時候異常，什麼時候恢復（秒級別）。
步驟3. 啟動catchup job，從earliest offset開始讀。
通過配置在處理bolt裡設定時間過濾條件，只處理規定時間範圍內的資料，其餘的資料全部丟棄。
步驟4. 資料恢復後，停止catchup job。
這個方案可以解決資料不丟的需求，當然這個方案也並不完美，問題如下，
1. 無法保證exactly-once，只能保證least-once
因為發生異常的10小時中，還是有比較少量的日誌資料是被成功寫入的， replay時，這部分資料會重複。
2. 讀取了部分不需要被replay的資料
為了簡單處理，我們的catchup job是從earliest offset開始讀的，並在業務bolt裡面進行過濾。
更好的方式，是定期在kafkaspout中對已處理的offset做checkpoint（比如分鐘級別），
然後恢復的時候，可以從某個checkpoint開始讀，這樣更精確些，但方案上會複雜很多。
我們最終通過這種方案找回了丟失的使用者sql日誌，可以作為一種思路給大家借鑑。
cap理論對於流式處理仍然奏效，並沒有被beat。
對於流式處理這樣強調高資料可用性的場景，要保證資料的強一致性是需要依賴於外部系統的replay能力的，並且對於海量資料是要付出很大的資源代價的（儲存和處理）。
實戰中，我們通過一定tradeoff，可以做到在有限資源的情況下，保證流式處理中發生故障時，仍然可以保證least-once的一致性。
如何保障流式處理的資料一致性
相對於傳統的hadoop這樣的batch分析平台，流式分析的優點就是實時性，即可以在秒級別延遲上得到分析結果 當然缺點是,很難保證強一致性，即exactly once語義 在海量資料的前提下，為了保障吞吐量，無法使用類似事務的強一致性的方案 一般流式分析平台都會promise較弱的一致性，即leas...
資料一致性處理
資料一致性處理 當多個程序同時操作同乙個資料，會產生資源爭搶，資料一致性的問題。高併發情況下，涉及到寫操作時，不可能直接運算元據庫，大併發的連線會導致mysql請求會阻塞，比如大量的insert update 請求到，會直接導致無數的行鎖和表鎖，甚至最後堆積很多，從來觸發too many conne...
資料一致性
資料一致性通常指關聯資料之間的邏輯關係是否正確和完整。而資料儲存的一致性模型則可以認為是儲存系統和資料使用者之間的一種約定。如果使用者遵循這種約定，則可以得到系統所承諾的訪問結果。常用的一致性模型有 a 嚴格一致性 linearizability,strict atomic consistency ...