日志處理是一個很大范疇，其中包括實時計算、數據倉庫、離線計算等眾多點。這篇文章主要介紹在實時計算場景中，如何能做到日志處理保序、不丟失、不重復，并且在上下游業務系統不可靠（存在故障）、業務流量劇烈波動情況下，如何保持這三點。
為方便理解，本文使用《銀行的一天》作為例子將概念解釋清楚。在文檔末尾，介紹日志服務Logstore消費組功能，如何與Spark Streaming、Storm Spout等配合，完成日志數據的處理過程。
什么樣的數據可以抽象成日志？
半世紀前說起日志，想到的是船長、操作員手里厚厚的筆記。如今計算機誕生使得日志產生與消費無處不在：服務器、路由器、傳感器、GPS、訂單、及各種設備通過不同角度描述著我們生活的世界。從船長日志中我們可以發現，日志除了帶一個記錄的時間戳外，可以包含幾乎任意的內容，例如：一段記錄文字、一張圖片、天氣狀況、船行方向等。半個世紀過去了，“船長日志”的方式已經擴展到一筆訂單、一項付款記錄、一次用戶訪問、一次數據庫操作等多樣的領域。
在計算機世界中，常用的日志有：Metric、Binlog（Database、NoSQL）、Event、Auditing、Access Log等。
在該文檔的示例中，我們把用戶到銀行的一次操作作為一條日志數據。其中包括用戶、賬號名、操作時間、操作類型、操作金額等。
例如：
2016-06-28 08:00:00 張三 存款 1000元美元
2016-06-27 09:00:00 李四 取款 20000元美元Logstore數據模型
為了能抽象問題，這里以日志服務Logstore作為演示模型。其包含以下內容：
Log：由時間及一組Key-Value對組成。
LogGroup：一組日志的集合，包含相同Meta（IP、Source）等。
兩者關系如下：
Shard：分區，LogGroup讀寫基本單元，可以理解以48小時為周期的FIFO隊列。每個Shard提供5 MB/s寫數據和10 MB/s讀數據能力。Shard有邏輯區間（BeginKey，EndKey）用以歸納不同類型數據。
Logstore：日志庫，用以存放同一類日志數據。Logstore是一個載體，通過由
[0000,FFFF..)區間Shard組合構建而成，Logstore會包含1個或多個Shard。Project：存儲Logstore的容器。
這些概念相互關系如下。
銀行的一天
以19世紀銀行為例。某個城市有若干用戶（Producer），到銀行去存取錢（User Operation），銀行有若干個柜員（Consumer）。因為19世紀還沒有電腦可以實時同步，因此每個柜員都有一個小賬本能夠記錄對應信息，每天晚上把錢和賬本拿到公司去對賬。
在分布式世界里，我們可以把柜員認為是固定內存和計算能力單機。用戶是來自各個數據源的請求，Bank大廳是處理用戶存取數據的日志庫（Logstore）。
該場景中，各角色及其主要操作包括：
Log/LogGroup：用戶發出的存取款等操作。
用戶（User）：Log/LogGroup生產者。
柜員（Clerk）：銀行處理用戶請求的員工。
銀行大廳（Logstore）：用戶產生的操作請求先進入銀行大廳，再交給柜員處理。
分區（Shard）：銀行大廳用以安排用戶請求的組織方式。
問題1：保序（Ordering）
銀行有2個柜員（A，B），張三進了銀行，在柜臺A上存了1000元，A把張三1000元存在自己的賬本上。張三到了下午覺得手頭緊到B柜臺取錢，B柜員一看賬本，發現不對，張三并沒有在這里存錢。
從這個例子可以看到，存取款是一個嚴格有序的操作，需要同一個柜員（處理器）來處理同一個用戶的操作，這樣才能保持狀態一致性。
實現保序的方法很簡單：排隊，創建一個Shard，終端只有一個柜員A來處理。用戶請求先進先出，一點問題都沒有。但帶來的問題是效率低下，假設有1000個用戶來進行操作，即使有10個柜員也無濟于事。這種場景怎么辦？
假設有10個柜員，我們可以創建10個Shard。要保證10個柜員對同一個賬戶的操作是有序的，可以根據一致性Hash方式將用戶進行映射。例如我們開10個隊伍（Shard），每個柜員處理一個Shard，把不同銀行賬號或用戶姓名，映射到特定Shard中。在這種情況下張三Hash（Zhang）= Z落在一個特定Shard中（區間包含Z），處理端面對的一直是柜員A。
當然如果張姓用戶比較多，也可以換其他策略。例如根據用戶AccountID、ZipCode進行Hash，這樣就可以使得每個Shard中操作請求更均勻。
問題2：不丟失（At-Least Once）
張三拿著存款在柜臺A處理，柜員A處理到一半去接了個電話，等回來后以為業務已經辦理好了，于是開始處理下一個用戶的請求，張三的存款請求因此被丟失。
雖然機器不會犯錯，在線時間和可靠性要比柜員高。但難免也會遇到電腦故障、或因負載高導致的處理中斷，因為這樣的場景丟失用戶的存款，后果是無法容忍的。
A可以在自己日記本上（非賬本）記錄一個項目：當前已處理到Shard哪個位置，只有當張三的這個存款請求被完全確認后，柜員A才能叫下一個。
帶來問題是什么？可能會重復。例如A已經處理完張三請求（更新賬本），準備在日記本上記錄處理到哪個位置之時，突然被叫開了，當A回來后，發現張三請求沒有記錄下來，A會把張三請求再次處理一遍，這就會造成重復。
問題3：不重復（Exactly Once）
重復是否一定會帶來問題？答案是不一定。
在冪等情況下，重復雖然會有浪費，但對結果沒有影響。什么叫冪等：重復消費不對結果產生影響的操作叫做冪等。例如用戶有一個操作“查詢余額”，該操作是一個只讀操作，重復做不影響結果。對于非只讀操作，例如注銷用戶這類操作，可以連續做兩次。
但現實生活中大部分操作不是冪等的，例如存款、取款等，重復進行計算會對結果帶來致命的影響。解決的方式是什么呢？柜員（A）需要把賬本完成+日記本標記Shard中處理完成作為一個事務合并操作，并記錄下來（CheckPoint）。
如果A暫時離開或永久離開，其他柜員只要使用相同的規范：記錄中已操作則處理下一個即可，如果沒有則重復做，過程中需要保證原子性。
CheckPoint可以將Shard中的元素位置（或時間）作為Key，放入一個可以持久化的對象中。代表當前元素已經被處理完成。
業務挑戰
以上三個概念解釋完成后，原理并不復雜。但在現實世界中，用戶數、處理量規模的變化與不確定性會使得以上三個問題變得更復雜。
遇到發工資的日期，用戶數會大漲。
柜員（Clerk）畢竟不是機器人，也需要休假，需要吃午飯。
銀行經理為了整體服務體驗，需要增加柜員。那以什么作為判斷標準增加柜員呢？
柜員在交接過程中，能否非常容易地傳遞賬本與記錄？
現實中的一天
8點銀行開門。
只有一個Shard0，用戶請求全部排在Shard0下，柜員A也正好可以處理。
10點進入高峰期。
銀行經理決定把10點后Shard0分裂成2個新Shard（Shard1，Shard2），并且給了如下規定，姓名是[A-W]用戶到Shard1中排隊，姓名是
[X, Y, Z]到Shard2中排隊等待處理。這兩個Shard區間明顯是不均勻的，因為用戶的姓氏分布就是不均勻的，通過這種映射方式可以保證柜員處理的均衡。10~12點請求消費狀態。
柜員A處理2個Shard非常吃力，于是經理派出柜員B、C出場。因為只有2個Shard，B開始接管A負責一個Shard，C處于閑置狀態。
中午12點人越來越多。
銀行經理覺得Shard1下柜員A壓力太大，因此從Shard1中拆分出（Shard3，Shard4）兩個新的Shard，Shard3由柜員A處理、Shard4由柜員C處理。在12點后原來排在Shard1中的請求，分別到Shard3，Shard4中。
12點后請求消費狀態。
流量持續到下午4點后，開始逐漸減少。
因此銀行經理讓柜員A、B休息，讓C同事處理Shard2、Shard3、Shard4中的請求。并逐步將Shard2與Shard3合并成Shard5，最后將Shard5和Shard4合并成一個Shard，當處理完成Shard中所有請求后銀行關門。
現實中的日志處理
上述過程可以抽象成日志處理的經典場景，如果要解決銀行的業務需求，我們要提供彈性伸縮、并且靈活適配的日志基礎框架，包括：
對Shard進行彈性伸縮。
消費者上線與下線能夠對Shard自動適配，過程中數據不丟失。過程中支持保序。
過程中不重復（需要消費者配合）。
觀察到消費進度，以便合理調配計算資源。
支持更多渠道日志接入（對銀行而言開通網上銀行、手機銀行、支票等渠道，可以接入更多的用戶請求）。
您可以通過Logstore消費組解決日志實時處理中的這些經典問題，只需把精力放在業務邏輯上，而不用去擔心流量擴容、Failover等瑣事。更多信息，請參見通過消費組消費數據。
另外，Spark Streaming已經通過消費組實現了對應的接口，歡迎使用。更多信息，請參見Spark Streaming消費。