document/ddia
2
0
Fork 0
mirror of https://github.com/Vonng/ddia.git synced 2024-12-06 15:20:12 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'translate-zh-tw' into fix-zhcn-path

Browse Source
This commit is contained in:
afunTW 2020-10-06 09:26:03 +08:00
commit 6d2dce3ec5
23 changed files with 11112 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
Pipfile Normal file
View File

@ -0,0 +1,13 @@
[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"
[packages]
opencc = "*"
click = "*"
[dev-packages]
[requires]
python_version = "3.6"

36
Pipfile.lock generated Normal file
View File

@ -0,0 +1,36 @@
{
"_meta": {
"hash": {
"sha256": "e11e067f853c70dd2660c4e3d606219472ef597161bcf00ffcd63872df1183bf"
},
"pipfile-spec": 6,
"requires": {
"python_version": "3.6"
},
"sources": [
{
"name": "pypi",
"url": "https://pypi.org/simple",
"verify_ssl": true
}
]
},
"default": {
"click": {
"hashes": [
"sha256:d2b5255c7c6349bc1bd1e59e08cd12acbbd63ce649f2588755783aa94dfb6b1a",
"sha256:dacca89f4bfadd5de3d7489b7c8a566eee0d3676333fbb50030263894c38c0dc"
],
"index": "pypi",
"version": "==7.1.2"
},
"opencc": {
"hashes": [
"sha256:1e0d40581dd5130ac3160f97e752caff202aa22aa004d468496fa8cba81035e7"
],
"index": "pypi",
"version": "==1.1.1.post1"
}
},
"develop": {}
}

63
translate.py Normal file
View File

@ -0,0 +1,63 @@
"""Convert zh-cn to zh-tw
Refer to https://github.com/BYVoid/OpenCC
"""
import click
import opencc
from pathlib import Path
from pprint import pprint
@click.group()
def cli():
pass
def convert(infile: str, outfile: str, cfg: str):
"""read >> convert >> write file
Args:
infile (str): input file
outfile (str): output file
cfg (str): config
"""
converter = opencc.OpenCC(cfg)
with open(infile, "r") as inf, open(outfile, "w+") as outf:
data = inf.readlines()
data = list(map(converter.convert, data))
outf.writelines(data)
print(f"Convert to {outfile}")
@cli.command()
@click.option("-i", "--input", "infile", required=True)
@click.option("-o", "--output", "outfile", required=True)
@click.option("-c", "--config", "cfg", required=True, default="s2twp.json")
def file(infile: str, outfile: str, cfg: str):
"""read >> convert >> write file
Args:
infile (str): input file
outfile (str): output file
cfg (str): config
"""
convert(infile, outfile, cfg)
@cli.command()
@click.option("-i", "--input", "infolder", required=True)
@click.option("-o", "--output", "outfolder", required=True)
@click.option("-c", "--config", "cfg", required=True, default="s2twp.json")
def repo(infolder, outfolder, cfg):
if not Path(outfolder).exists():
Path(outfolder).mkdir(parents=True)
print(f"Create {outfolder}")
infiles = Path(infolder).resolve().glob("*.md")
pair = [
{"infile": str(infile), "outfile": str(Path(outfolder).resolve() / infile.name)}
for idx, infile in enumerate(infiles)
]
for p in pair:
convert(p["infile"], p["outfile"], cfg)
if __name__ == "__main__":
cli()

101
zh-tw/README.md Normal file
View File

@ -0,0 +1,101 @@
# 設計資料密集型應用 - 中文翻譯
- 作者： [Martin Kleppmann](https://martin.kleppmann.com)
- 原書名稱：[《Designing Data-Intensive Application》](http://shop.oreilly.com/product/0636920032175.do)
- 譯者：[馮若航]( http://vonng.com/about) （fengruohang@outlook.com ）
- Gitbook地址：[ddia-cn](https://www.gitbook.com/book/vonng/ddia-cn)
- 使用[Typora](https://www.typora.io)或Gitbook以獲取最佳閱讀體驗。
## 譯序
> 不懂資料庫的全棧工程師不是好架構師
>
> —— Vonng
​ 現今，尤其是在網際網路領域，大多數應用都屬於資料密集型應用。本書從底層資料結構到頂層架構設計，將資料系統設計中的精髓娓娓道來。其中的寶貴經驗無論是對架構師，DBA、還是後端工程師、甚至產品經理都會有幫助。
​ 這是一本理論結合實踐的書，書中很多問題，譯者在實際場景中都曾遇到過，讀來讓人擊節扼腕。如果能早點讀到這本書，該少走多少彎路啊！
​ 這也是一本深入淺出的書，講述概念的來龍去脈而不是賣弄定義，介紹事物發展演化歷程而不是事實堆砌，將複雜的概念講述的淺顯易懂，但又直擊本質不失深度。每章最後的引用質量非常好，是深入學習各個主題的絕佳索引。
​ 本書為資料系統的設計、實現、與評價提供了很好的概念框架。讀完並理解本書內容後，讀者可以輕鬆看破大多數的技術忽悠，與技術磚家撕起來虎虎生風🤣。
​ 這是2017年譯者讀過最好的一本技術類書籍，這麼好的書沒有中文翻譯，實在是遺憾。某不才，願為先進技術文化的傳播貢獻一分力量。既可以深入學習有趣的技術主題，又可以鍛鍊中英文語言文字功底，何樂而不為？
## 前言
> 在我們的社會中，技術是一種強大的力量。資料、軟體、通訊可以用於壞的方面：不公平的階級固化，損害公民權利，保護既得利益集團。但也可以用於好的方面：讓底層人民發出自己的聲音，讓每個人都擁有機會，避免災難。本書獻給所有將技術用於善途的人們。
---------
> 計算是一種流行文化，流行文化鄙視歷史。 流行文化關乎個體身份和參與感，但與合作無關。流行文化活在當下，也與過去和未來無關。 我認為大部分（為了錢）編寫程式碼的人就是這樣的， 他們不知道自己的文化來自哪裡。
>
> ——阿蘭·凱接受Dobb博士的雜誌採訪時（2012年）
## 目錄
### [序言](preface.md)
### [第一部分：資料系統的基石](part-i.md)
* [第一章：可靠性、可擴充套件性、可維護性](ch1.md)
* [第二章：資料模型與查詢語言](ch2.md)
* [第三章：儲存與檢索](ch3.md)
* [第四章：編碼與演化](ch4.md)
### [第二部分：分散式資料](part-ii.md)
* [第五章：複製](ch5.md)
* [第六章：分割槽](ch6.md)
* [第七章：事務](ch7.md)
* [第八章：分散式系統的麻煩](ch8.md)
* [第九章：一致性與共識](ch9.md)
### [第三部分：衍生資料](part-iii.md)
* [第十章：批處理](ch10.md)
* [第十一章：流處理](ch11.md)
* [第十二章：資料系統的未來](ch12.md)
### [術語表](glossary.md)
### [後記](colophon.md)
## 法律宣告
從原作者處得知，已經有簡體中文的翻譯計劃，將於2018年末完成。
譯者純粹出於**學習目的**與**個人興趣**翻譯本書，不追求任何經濟利益。
譯者保留對此版本譯文的署名權，其他權利以原作者和出版社的主張為準。
本譯文只供學習研究參考之用，不得公開傳播發行或用於商業用途。有能力閱讀英文書籍者請購買正版支援。
## CONTRIBUTION
1. [序言初翻修正](https://github.com/Vonng/ddia/commit/afb5edab55c62ed23474149f229677e3b42dfc2c) by [@seagullbird](https://github.com/Vonng/ddia/commits?author=seagullbird)
2. [第一章語法標點校正](https://github.com/Vonng/ddia/commit/973b12cd8f8fcdf4852f1eb1649ddd9d187e3644) by [@nevertiree](https://github.com/Vonng/ddia/commits?author=nevertiree)
3. [第六章部分校正](https://github.com/Vonng/ddia/commit/d4eb0852c0ec1e93c8aacc496c80b915bb1e6d48) 與[第10章的初翻](https://github.com/Vonng/ddia/commit/9de8dbd1bfe6fbb03b3bf6c1a1aa2291aed2490e) by @[MuAlex](https://github.com/Vonng/ddia/commits?author=MuAlex)
4. 第一部分前言，ch2校正 by @jiajiadebug
5. 詞彙表、後記關於野豬的部分 by @[Chowss](https://github.com/Vonng/ddia/commits?author=Chowss)
https://github.com/Vonng/ddia/pulls)
感謝所有作出貢獻，提出意見的朋友們：[Issues](https://github.com/Vonng/ddia/issues)，[Pull Requests](https://github.com/Vonng/ddia/pulls)
## LICENSE
CC-BY 4.0

23
zh-tw/SUMMARY.md Normal file
View File

@ -0,0 +1,23 @@
# Summary
* [簡介](README.md)
* [序言](preface.md)
* [第一部分：資料系統的基石](part-i.md)
* [第一章：可靠性、可擴充套件性、可維護性](ch1.md)
* [第二章：資料模型與查詢語言](ch2.md)
* [第三章：儲存與檢索](ch3.md)
* [第四章：編碼與演化](ch4.md)
* [第二部分：分散式資料](part-ii.md)
* [第五章：複製](ch5.md)
* [第六章：分割槽](ch6.md)
* [第七章：事務](ch7.md)
* [第八章：分散式系統的麻煩](ch8.md)
* [第九章：一致性與共識](ch9.md)
* [第三部分：衍生資料](part-iii.md)
* [第十章：批處理](ch10.md)
* [第十一章：流處理](ch11.md)
* [第十二章：資料系統的未來](ch12.md)
* [術語表](glossary.md)
* [後記](colophon.md)

462
zh-tw/ch1.md Normal file
View File

@ -0,0 +1,462 @@
# 第一章：可靠性，可擴充套件性，可維護性
![](../img/ch1.png)
> 網際網路做得太棒了，以至於大多數人將它看作像太平洋這樣的自然資源，而不是什麼人工產物。上一次出現這種大規模且無差錯的技術， 你還記得是什麼時候嗎？
>
> ——阿蘭·凱在接受Dobb博士雜誌採訪時說（2012年）
-----------------------
[TOC]
現今很多應用程式都是 **資料密集型（data-intensive）** 的，而非 **計算密集型（compute-intensive）** 的。因此CPU很少成為這類應用的瓶頸，更大的問題通常來自資料量、資料複雜性、以及資料的變更速度。
資料密集型應用通常由標準組件構建而成，標準組件提供了很多通用的功能；例如，許多應用程式都需要：
- 儲存資料，以便自己或其他應用程式之後能再次找到 （***資料庫（database）***）
- 記住開銷昂貴操作的結果，加快讀取速度（***快取（cache）***）
- 允許使用者按關鍵字搜尋資料，或以各種方式對資料進行過濾（***搜尋索引（search indexes）***）
- 向其他程序傳送訊息，進行非同步處理（***流處理（stream processing）***）
- 定期處理累積的大批次資料（***批處理（batch processing）***）
如果這些功能聽上去平淡無奇，那是因為這些 **資料系統（data system）** 是非常成功的抽象：我們一直不假思索地使用它們並習以為常。絕大多數工程師不會幻想從零開始編寫儲存引擎，因為在開發應用時，資料庫已經是足夠完美的工具了。
​ 但現實沒有這麼簡單。不同的應用有著不同的需求，因而資料庫系統也是百花齊放，有著各式各樣的特性。實現快取有很多種手段，建立搜尋索引也有好幾種方法，諸如此類。因此在開發應用前，我們依然有必要先弄清楚最適合手頭工作的工具和方法。而且當單個工具解決不了你的問題時，組合使用這些工具可能還是有些難度的。
​ 本書將是一趟關於資料系統原理、實踐與應用的旅程，並講述了設計資料密集型應用的方法。我們將探索不同工具之間的共性與特性，以及各自的實現原理。
​ 本章將從我們所要實現的基礎目標開始：可靠、可擴充套件、可維護的資料系統。我們將澄清這些詞語的含義，概述考量這些目標的方法。並回顧一些後續章節所需的基礎知識。在接下來的章節中我們將抽絲剝繭，研究設計資料密集型應用時可能遇到的設計決策。
## 關於資料系統的思考
​ 我們通常認為，資料庫、訊息佇列、快取等工具分屬於幾個差異顯著的類別。雖然資料庫和訊息隊列表面上有一些相似性——它們都會儲存一段時間的資料——但它們有迥然不同的訪問模式，這意味著迥異的效能特徵和實現手段。
​ 那我們為什麼要把這些東西放在 **資料系統（data system）** 的總稱之下混為一談呢？
​ 近些年來，出現了許多新的資料儲存工具與資料處理工具。它們針對不同應用場景進行最佳化，因此不再適合生硬地歸入傳統類別【1】。類別之間的界限變得越來越模糊，例如：資料儲存可以被當成訊息佇列用（Redis），訊息佇列則帶有類似資料庫的持久保證（Apache Kafka）。
​ 其次，越來越多的應用程式有著各種嚴格而廣泛的要求，單個工具不足以滿足所有的資料處理和儲存需求。取而代之的是，總體工作被拆分成一系列能被單個工具高效完成的任務，並透過應用程式碼將它們縫合起來。
​ 例如，如果將快取（應用管理的快取層，Memcached或同類產品）和全文搜尋（全文搜尋伺服器，例如Elasticsearch或Solr）功能從主資料庫剝離出來，那麼使快取/索引與主資料庫保持同步通常是應用程式碼的責任。[圖1-1](../img/fig1-1.png) 給出了這種架構可能的樣子（細節將在後面的章節中詳細介紹）。
![](../img/fig1-1.png)
**圖1-1 一個可能的組合使用多個元件的資料系統架構**
​ 當你將多個工具組合在一起提供服務時，服務的介面或**應用程式程式設計介面（API, Application Programming Interface）**通常向客戶端隱藏這些實現細節。現在，你基本上已經使用較小的通用元件建立了一個全新的、專用的資料系統。這個新的複合資料系統可能會提供特定的保證，例如：快取在寫入時會作廢或更新，以便外部客戶端獲取一致的結果。現在你不僅是應用程式開發人員，還是資料系統設計人員了。
​ 設計資料系統或服務時可能會遇到很多棘手的問題，例如：當系統出問題時，如何確保資料的正確性和完整性？當部分系統退化降級時，如何為客戶提供始終如一的良好效能？當負載增加時，如何擴容應對？什麼樣的API才是好的API？
​ 影響資料系統設計的因素很多，包括參與人員的技能和經驗、歷史遺留問題、系統路徑依賴、交付時限、公司的風險容忍度、監管約束等，這些因素都需要具體問題具體分析。
​ 本書著重討論三個在大多數軟體系統中都很重要的問題：
***可靠性（Reliability）***
​ 系統在**困境（adversity）**（硬體故障、軟體故障、人為錯誤）中仍可正常工作（正確完成功能，並能達到期望的效能水準）。
***可擴充套件性（Scalability）***
​ 有合理的辦法應對系統的增長（資料量、流量、複雜性）（參閱“[可擴充套件性](#可擴充套件性)”）
***可維護性（Maintainability）***
​ 許多不同的人（工程師、運維）在不同的生命週期，都能高效地在系統上工作（使系統保持現有行為，並適應新的應用場景）。（參閱”[可維護性](#可維護性)“）
​ 人們經常追求這些詞彙，卻沒有清楚理解它們到底意味著什麼。為了工程的嚴謹性，本章的剩餘部分將探討可靠性、可擴充套件性、可維護性的含義。為實現這些目標而使用的各種技術，架構和演算法將在後續的章節中研究。
## 可靠性
人們對於一個東西是否可靠，都有一個直觀的想法。人們對可靠軟體的典型期望包括：
* 應用程式表現出使用者所期望的功能。
* 允許使用者犯錯，允許使用者以出乎意料的方式使用軟體。
* 在預期的負載和資料量下，效能滿足要求。
* 系統能防止未經授權的訪問和濫用。
如果所有這些在一起意味著“正確工作”，那麼可以把可靠性粗略理解為“即使出現問題，也能繼續正確工作”。
​ 造成錯誤的原因叫做**故障（fault）**，能預料並應對故障的系統特性可稱為**容錯（fault-tolerant）**或**韌性（resilient）**。“**容錯**”一詞可能會產生誤導，因為它暗示著系統可以容忍所有可能的錯誤，但在實際中這是不可能的。比方說，如果整個地球（及其上的所有伺服器）都被黑洞吞噬了，想要容忍這種錯誤，需要把網路託管到太空中——這種預算能不能批准就祝你好運了。所以在討論容錯時，只有談論特定型別的錯誤才有意義。
​ 注意**故障（fault）**不同於**失效（failure）**【2】。**故障**通常定義為系統的一部分狀態偏離其標準，而**失效**則是系統作為一個整體停止向用戶提供服務。故障的概率不可能降到零，因此最好設計容錯機制以防因**故障**而導致**失效**。本書中我們將介紹幾種用不可靠的部件構建可靠系統的技術。
​ 反直覺的是，在這類容錯系統中，透過故意觸發來**提高**故障率是有意義的，例如：在沒有警告的情況下隨機地殺死單個程序。許多高危漏洞實際上是由糟糕的錯誤處理導致的【3】，因此我們可以透過故意引發故障來確保容錯機制不斷執行並接受考驗，從而提高故障自然發生時系統能正確處理的信心。Netflix公司的*Chaos Monkey*【4】就是這種方法的一個例子。
​ 儘管比起**阻止錯誤（prevent error）**，我們通常更傾向於**容忍錯誤**。但也有**預防勝於治療**的情況（比如不存在治療方法時）。安全問題就屬於這種情況。例如，如果攻擊者破壞了系統，並獲取了敏感資料，這種事是撤銷不了的。但本書主要討論的是可以恢復的故障種類，正如下面幾節所述。
### 硬體故障
​ 當想到系統失效的原因時，**硬體故障（hardware faults）**總會第一個進入腦海。硬碟崩潰、記憶體出錯、機房斷電、有人拔錯網線……任何與大型資料中心打過交道的人都會告訴你：一旦你擁有很多機器，這些事情**總**會發生！
​ 據報道稱，硬碟的 **平均無故障時間（MTTF mean time to failure）** 約為10到50年【5】【6】。因此從數學期望上講，在擁有10000個磁碟的儲存叢集上，平均每天會有1個磁碟出故障。
​ 為了減少系統的故障率，第一反應通常都是增加單個硬體的冗餘度，例如：磁碟可以組建RAID，伺服器可能有雙路電源和熱插拔CPU，資料中心可能有電池和柴油發電機作為後備電源，某個元件掛掉時冗餘元件可以立刻接管。這種方法雖然不能完全防止由硬體問題導致的系統失效，但它簡單易懂，通常也足以讓機器不間斷執行很多年。
​ 直到最近，硬體冗餘對於大多數應用來說已經足夠了，它使單臺機器完全失效變得相當罕見。只要你能快速地把備份恢復到新機器上，故障停機時間對大多數應用而言都算不上災難性的。只有少量高可用性至關重要的應用才會要求有多套硬體冗餘。
​ 但是隨著資料量和應用計算需求的增加，越來越多的應用開始大量使用機器，這會相應地增加硬體故障率。此外在一些雲平臺（**如亞馬遜網路服務（AWS, Amazon Web Services）**）中，虛擬機器例項不可用卻沒有任何警告也是很常見的【7】，因為雲平臺的設計就是優先考慮**靈活性（flexibility）**和**彈性（elasticity）**[^i]，而不是單機可靠性。
​ 如果在硬體冗餘的基礎上進一步引入軟體容錯機制，那麼系統在容忍整個（單臺）機器故障的道路上就更進一步了。這樣的系統也有運維上的便利，例如：如果需要重啟機器（例如應用作業系統安全補丁），單伺服器系統就需要計劃停機。而允許機器失效的系統則可以一次修復一個節點，無需整個系統停機。
[^i]: 在[應對負載的方法](#應對負載的方法)一節定義
### 軟體錯誤
​ 我們通常認為硬體故障是隨機的、相互獨立的：一臺機器的磁碟失效並不意味著另一臺機器的磁碟也會失效。大量硬體元件不可能同時發生故障，除非它們存在比較弱的相關性（同樣的原因導致關聯性錯誤，例如伺服器機架的溫度）。
​ 另一類錯誤是內部的**系統性錯誤（systematic error）**【7】。這類錯誤難以預料，而且因為是跨節點相關的，所以比起不相關的硬體故障往往可能造成更多的**系統失效**【5】。例子包括：
* 接受特定的錯誤輸入，便導致所有應用伺服器例項崩潰的BUG。例如2012年6月30日的閏秒，由於Linux核心中的一個錯誤，許多應用同時掛掉了。
* 失控程序會佔用一些共享資源，包括CPU時間、記憶體、磁碟空間或網路頻寬。
* 系統依賴的服務變慢，沒有響應，或者開始返回錯誤的響應。
* 級聯故障，一個元件中的小故障觸發另一個元件中的故障，進而觸發更多的故障【10】。
導致這類軟體故障的BUG通常會潛伏很長時間，直到被異常情況觸發為止。這種情況意味著軟體對其環境做出了某種假設——雖然這種假設通常來說是正確的，但由於某種原因最後不再成立了【11】。
​ 雖然軟體中的系統性故障沒有速效藥，但我們還是有很多小辦法，例如：仔細考慮系統中的假設和互動；徹底的測試；程序隔離；允許程序崩潰並重啟；測量、監控並分析生產環境中的系統行為。如果系統能夠提供一些保證（例如在一個訊息佇列中，進入與發出的訊息數量相等），那麼系統就可以在執行時不斷自檢，並在出現**差異（discrepancy）**時報警【12】。
### 人為錯誤
​ 設計並構建了軟體系統的工程師是人類，維持系統執行的運維也是人類。即使他們懷有最大的善意，人類也是不可靠的。舉個例子，一項關於大型網際網路服務的研究發現，運維配置錯誤是導致服務中斷的首要原因，而硬體故障（伺服器或網路）僅導致了10-25％的服務中斷【13】。
​ 儘管人類不可靠，但怎麼做才能讓系統變得可靠？最好的系統會組合使用以下幾種辦法：
* 以最小化犯錯機會的方式設計系統。例如，精心設計的抽象、API和管理後臺使做對事情更容易，搞砸事情更困難。但如果介面限制太多，人們就會忽略它們的好處而想辦法繞開。很難正確把握這種微妙的平衡。
* 將人們最容易犯錯的地方與可能導致失效的地方**解耦（decouple）**。特別是提供一個功能齊全的非生產環境**沙箱（sandbox）**，使人們可以在不影響真實使用者的情況下，使用真實資料安全地探索和實驗。
* 在各個層次進行徹底的測試【3】，從單元測試、全系統整合測試到手動測試。自動化測試易於理解，已經被廣泛使用，特別適合用來覆蓋正常情況中少見的**邊緣場景（corner case）**。
* 允許從人為錯誤中簡單快速地恢復，以最大限度地減少失效情況帶來的影響。 例如，快速回滾配置變更，分批發布新程式碼（以便任何意外錯誤隻影響一小部分使用者），並提供資料重算工具（以備舊的計算出錯）。
* 配置詳細和明確的監控，比如效能指標和錯誤率。 在其他工程學科中這指的是**遙測（telemetry）**。 （一旦火箭離開了地面，遙測技術對於跟蹤發生的事情和理解失敗是至關重要的。）監控可以向我們發出預警訊號，並允許我們檢查是否有任何地方違反了假設和約束。當出現問題時，指標資料對於問題診斷是非常寶貴的。
* 良好的管理實踐與充分的培訓——一個複雜而重要的方面，但超出了本書的範圍。
### 可靠性有多重要？
​ 可靠性不僅僅是針對核電站和空中交通管制軟體而言，我們也期望更多平凡的應用能可靠地執行。商務應用中的錯誤會導致生產力損失（也許資料報告不完整還會有法律風險），而電商網站的中斷則可能會導致收入和聲譽的巨大損失。
​ 即使在“非關鍵”應用中，我們也對使用者負有責任。試想一位家長把所有的照片和孩子的影片儲存在你的照片應用裡【15】。如果資料庫突然損壞，他們會感覺如何？他們可能會知道如何從備份恢復嗎？
​ 在某些情況下，我們可能會選擇犧牲可靠性來降低開發成本（例如為未經證實的市場開發產品原型）或運營成本（例如利潤率極低的服務），但我們偷工減料時，應該清楚意識到自己在做什麼。
## 可擴充套件性
​ 系統今天能可靠執行，並不意味未來也能可靠執行。服務 **降級（degradation）** 的一個常見原因是負載增加，例如：系統負載已經從一萬個併發使用者增長到十萬個併發使用者，或者從一百萬增長到一千萬。也許現在處理的資料量級要比過去大得多。
​ **可擴充套件性（Scalability）** 是用來描述系統應對負載增長能力的術語。但是請注意，這不是貼在系統上的一維標籤：說“X可擴充套件”或“Y不可擴充套件”是沒有任何意義的。相反，討論可擴充套件性意味著考慮諸如“如果系統以特定方式增長，有什麼選項可以應對增長？”和“如何增加計算資源來處理額外的負載？”等問題。
### 描述負載
​ 在討論增長問題（如果負載加倍會發生什麼？）前，首先要能簡要描述系統的當前負載。負載可以用一些稱為 **負載引數（load parameters）** 的數字來描述。引數的最佳選擇取決於系統架構，它可能是每秒向Web伺服器發出的請求、資料庫中的讀寫比率、聊天室中同時活躍的使用者數量、快取命中率或其他東西。除此之外，也許平均情況對你很重要，也許你的瓶頸是少數極端場景。
​ 為了使這個概念更加具體，我們以推特在2012年11月釋出的資料【16】為例。推特的兩個主要業務是：
***釋出推文***
​ 使用者可以向其粉絲髮布新訊息（平均 4.6k請求/秒，峰值超過 12k請求/秒）。
***主頁時間線***
​ 使用者可以查閱他們關注的人釋出的推文（300k請求/秒）。
​ 處理每秒12,000次寫入（發推文的速率峰值）還是很簡單的。然而推特的擴充套件性挑戰並不是主要來自推特量，而是來自**扇出（fan-out）**——每個使用者關注了很多人，也被很多人關注。
[^ii]: 扇出：從電子工程學中借用的術語，它描述了輸入連線到另一個門輸出的邏輯閘數量。 輸出需要提供足夠的電流來驅動所有連線的輸入。 在事務處理系統中，我們使用它來描述為了服務一個傳入請求而需要執行其他服務的請求數量。
大體上講，這一對操作有兩種實現方式。
1. 釋出推文時，只需將新推文插入全域性推文集合即可。當一個使用者請求自己的主頁時間線時，首先查詢他關注的所有人，查詢這些被關注使用者釋出的推文並按時間順序合併。在如[圖1-2](../img/fig1-2.png)所示的關係型資料庫中，可以編寫這樣的查詢：
```sql
SELECT tweets.*, users.*
FROM tweets
JOIN users ON tweets.sender_id = users.id
JOIN follows ON follows.followee_id = users.id
WHERE follows.follower_id = current_user
```
![](../img/fig1-2.png)
**圖1-2 推特主頁時間線的關係型模式簡單實現**
2. 為每個使用者的主頁時間線維護一個快取，就像每個使用者的推文收件箱（[圖1-3](../img/fig1-3.png)）。 當一個使用者釋出推文時，查詢所有關注該使用者的人，並將新的推文插入到每個主頁時間線快取中。 因此讀取主頁時間線的請求開銷很小，因為結果已經提前計算好了。
![](../img/fig1-3.png)
**圖1-3 用於分發推特至關注者的資料流水線，2012年11月的負載引數【16】**
推特的第一個版本使用了方法1，但系統很難跟上主頁時間線查詢的負載。所以公司轉向了方法2，方法2的效果更好，因為發推頻率比查詢主頁時間線的頻率幾乎低了兩個數量級，所以在這種情況下，最好在寫入時做更多的工作，而在讀取時做更少的工作。
​ 然而方法2的缺點是，發推現在需要大量的額外工作。平均來說，一條推文會發往約75個關注者，所以每秒4.6k的發推寫入，變成了對主頁時間線快取每秒345k的寫入。但這個平均值隱藏了使用者粉絲數差異巨大這一現實，一些使用者有超過3000萬的粉絲，這意味著一條推文就可能會導致主頁時間線快取的3000萬次寫入！及時完成這種操作是一個巨大的挑戰 —— 推特嘗試在5秒內向粉絲髮送推文。
​ 在推特的例子中，每個使用者粉絲數的分佈（可能按這些使用者的發推頻率來加權）是探討可擴充套件性的一個關鍵負載引數，因為它決定了扇出負載。你的應用程式可能具有非常不同的特徵，但可以採用相似的原則來考慮它的負載。
​ 推特軼事的最終轉折：現在已經穩健地實現了方法2，推特逐步轉向了兩種方法的混合。大多數使用者發的推文會被扇出寫入其粉絲主頁時間線快取中。但是少數擁有海量粉絲的使用者（即名流）會被排除在外。當用戶讀取主頁時間線時，分別地獲取出該使用者所關注的每位名流的推文，再與使用者的主頁時間線快取合併，如方法1所示。這種混合方法能始終如一地提供良好效能。在[第12章](ch12.md)中我們將重新討論這個例子，這在覆蓋更多技術層面之後。
### 描述效能
一旦系統的負載被描述好，就可以研究當負載增加會發生什麼。我們可以從兩種角度來看：
* 增加負載引數並保持系統資源（CPU、記憶體、網路頻寬等）不變時，系統性能將受到什麼影響？
* 增加負載引數並希望保持效能不變時，需要增加多少系統資源？
這兩個問題都需要效能資料，所以讓我們簡單地看一下如何描述系統性能。
​ 對於Hadoop這樣的批處理系統，通常關心的是**吞吐量（throughput）**，即每秒可以處理的記錄數量，或者在特定規模資料集上執行作業的總時間[^iii]。對於線上系統，通常更重要的是服務的**響應時間（response time）**，即客戶端傳送請求到接收響應之間的時間。
[^iii]: 理想情況下，批次作業的執行時間是資料集的大小除以吞吐量。 在實踐中由於資料傾斜（資料不是均勻分佈在每個工作程序中），需要等待最慢的任務完成，所以執行時間往往更長。
> #### 延遲和響應時間
>
> **延遲（latency）** 和 **響應時間（response time）** 經常用作同義詞，但實際上它們並不一樣。響應時間是客戶所看到的，除了實際處理請求的時間（ **服務時間（service time）** ）之外，還包括網路延遲和排隊延遲。延遲是某個請求等待處理的**持續時長**，在此期間它處於 **休眠（latent）** 狀態，並等待服務【17】。
​ 即使不斷重複傳送同樣的請求，每次得到的響應時間也都會略有不同。現實世界的系統會處理各式各樣的請求，響應時間可能會有很大差異。因此我們需要將響應時間視為一個可以測量的數值**分佈（distribution）**，而不是單個數值。
​ 在[圖1-4](../img/fig1-4.png)中，每個灰條表代表一次對服務的請求，其高度表示請求花費了多長時間。大多數請求是相當快的，但偶爾會出現需要更長的時間的異常值。這也許是因為緩慢的請求實質上開銷更大，例如它們可能會處理更多的資料。但即使（你認為）所有請求都花費相同時間的情況下，隨機的附加延遲也會導致結果變化，例如：上下文切換到後臺程序，網路資料包丟失與TCP重傳，垃圾收集暫停，強制從磁碟讀取的頁面錯誤，伺服器機架中的震動【18】，還有很多其他原因。
![](../img/fig1-4.png)
**圖1-4 展示了一個服務100次請求響應時間的均值與百分位數**
​ 通常報表都會展示服務的平均響應時間。 （嚴格來講“平均”一詞並不指代任何特定公式，但實際上它通常被理解為**算術平均值（arithmetic mean）**：給定 n 個值，加起來除以 n ）。然而如果你想知道“**典型（typical）**”響應時間，那麼平均值並不是一個非常好的指標，因為它不能告訴你有多少使用者實際上經歷了這個延遲。
​ 通常使用**百分位點（percentiles）**會更好。如果將響應時間列表按最快到最慢排序，那麼**中位數（median）**就在正中間：舉個例子，如果你的響應時間中位數是200毫秒，這意味著一半請求的返回時間少於200毫秒，另一半比這個要長。
​ 如果想知道典型場景下使用者需要等待多長時間，那麼中位數是一個好的度量標準：一半使用者請求的響應時間少於響應時間的中位數，另一半服務時間比中位數長。中位數也被稱為第50百分位點，有時縮寫為p50。注意中位數是關於單個請求的；如果使用者同時發出幾個請求（在一個會話過程中，或者由於一個頁面中包含了多個資源），則至少一個請求比中位數慢的概率遠大於50％。
​ 為了弄清異常值有多糟糕，可以看看更高的百分位點，例如第95、99和99.9百分位點（縮寫為p95，p99和p999）。它們意味著95％，99％或99.9％的請求響應時間要比該閾值快，例如：如果第95百分位點響應時間是1.5秒，則意味著100個請求中的95個響應時間快於1.5秒，而100個請求中的5個響應時間超過1.5秒。如[圖1-4](../img/fig1-4.png)所示。
​ 響應時間的高百分位點（也稱為**尾部延遲（tail latencies）**）非常重要，因為它們直接影響使用者的服務體驗。例如亞馬遜在描述內部服務的響應時間要求時以99.9百分位點為準，即使它隻影響一千個請求中的一個。這是因為請求響應最慢的客戶往往也是資料最多的客戶，也可以說是最有價值的客戶 —— 因為他們掏錢了【19】。保證網站響應迅速對於保持客戶的滿意度非常重要，亞馬遜觀察到：響應時間增加100毫秒，銷售量就減少1％【20】；而另一些報告說：慢 1 秒鐘會讓客戶滿意度指標減少16%【21，22】。
​ 另一方面，最佳化第99.99百分位點（一萬個請求中最慢的一個）被認為太昂貴了，不能為亞馬遜的目標帶來足夠好處。減小高百分位點處的響應時間相當困難，因為它很容易受到隨機事件的影響，這超出了控制範圍，而且效益也很小。
​ 百分位點通常用於**服務級別目標（SLO, service level objectives）**和**服務級別協議（SLA, service level agreements）**，即定義服務預期效能和可用性的合同。 SLA可能會宣告，如果服務響應時間的中位數小於200毫秒，且99.9百分位點低於1秒，則認為服務工作正常（如果響應時間更長，就認為服務不達標）。這些指標為客戶設定了期望值，並允許客戶在SLA未達標的情況下要求退款。
​ **排隊延遲（queueing delay）** 通常佔了高百分位點處響應時間的很大一部分。由於伺服器只能並行處理少量的事務（如受其CPU核數的限制），所以只要有少量緩慢的請求就能阻礙後續請求的處理，這種效應有時被稱為 **頭部阻塞（head-of-line blocking）** 。即使後續請求在伺服器上處理的非常迅速，由於需要等待先前請求完成，客戶端最終看到的是緩慢的總體響應時間。因為存在這種效應，測量客戶端的響應時間非常重要。
​ 為測試系統的可擴充套件性而人為產生負載時，產生負載的客戶端要獨立於響應時間不斷髮送請求。如果客戶端在傳送下一個請求之前等待先前的請求完成，這種行為會產生人為排隊的效果，使得測試時的佇列比現實情況更短，使測量結果產生偏差【23】。
> #### 實踐中的百分位點
>
> ​ 在多重呼叫的後端服務裡，高百分位數變得特別重要。即使並行呼叫，終端使用者請求仍然需要等待最慢的並行呼叫完成。如[圖1-5](../img/fig1-5.png)所示，只需要一個緩慢的呼叫就可以使整個終端使用者請求變慢。即使只有一小部分後端呼叫速度較慢，如果終端使用者請求需要多個後端呼叫，則獲得較慢呼叫的機會也會增加，因此較高比例的終端使用者請求速度會變慢（效果稱為尾部延遲放大【24】）。
>
> ​ 如果您想將響應時間百分點新增到您的服務的監視儀表板，則需要持續有效地計算它們。例如，您可能希望在最近10分鐘內保持請求響應時間的滾動視窗。每一分鐘，您都會計算出該視窗中的中值和各種百分數，並將這些度量值繪製在圖上。
>
> ​ 簡單的實現是在時間視窗內儲存所有請求的響應時間列表，並且每分鐘對列表進行排序。如果對你來說效率太低，那麼有一些演算法能夠以最小的CPU和記憶體成本（如前向衰減【25】，t-digest【26】或HdrHistogram 【27】）來計算百分位數的近似值。請注意，平均百分比（例如，減少時間解析度或合併來自多臺機器的資料）在數學上沒有意義 - 聚合響應時間資料的正確方法是新增直方圖【28】。
![](../img/fig1-5.png)
**圖1-5 當一個請求需要多個後端請求時，單個後端慢請求就會拖慢整個終端使用者的請求**
### 應對負載的方法
​ 現在我們已經討論了用於描述負載的引數和用於衡量效能的指標。可以開始認真討論可擴充套件性了：當負載引數增加時，如何保持良好的效能？
​ 適應某個級別負載的架構不太可能應付10倍於此的負載。如果你正在開發一個快速增長的服務，那麼每次負載發生數量級的增長時，你可能都需要重新考慮架構——或者更頻繁。
​ 人們經常討論**縱向擴充套件（scaling up）**（**垂直擴充套件（vertical scaling）**，轉向更強大的機器）和**橫向擴充套件（scaling out）** （**水平擴充套件（horizontal scaling）**，將負載分佈到多臺小機器上）之間的對立。跨多臺機器分配負載也稱為“**無共享（shared-nothing）**”架構。可以在單臺機器上執行的系統通常更簡單，但高階機器可能非常貴，所以非常密集的負載通常無法避免地需要橫向擴充套件。現實世界中的優秀架構需要將這兩種方法務實地結合，因為使用幾臺足夠強大的機器可能比使用大量的小型虛擬機器更簡單也更便宜。
​ 有些系統是 **彈性（elastic）** 的，這意味著可以在檢測到負載增加時自動增加計算資源，而其他系統則是手動擴充套件（人工分析容量並決定向系統新增更多的機器）。如果負載**極難預測（highly unpredictable）**，則彈性系統可能很有用，但手動擴充套件系統更簡單，並且意外操作可能會更少（參閱“[重新平衡分割槽](ch6.md#分割槽再平衡)”）。
​ 跨多臺機器部署**無狀態服務（stateless services）**非常簡單，但將帶狀態的資料系統從單節點變為分散式配置則可能引入許多額外複雜度。出於這個原因，常識告訴我們應該將資料庫放在單個節點上（縱向擴充套件），直到擴充套件成本或可用性需求迫使其改為分散式。
​ 隨著分散式系統的工具和抽象越來越好，至少對於某些型別的應用而言，這種常識可能會改變。可以預見分散式資料系統將成為未來的預設設定，即使對不處理大量資料或流量的場景也如此。本書的其餘部分將介紹多種分散式資料系統，不僅討論它們在可擴充套件性方面的表現，還包括易用性和可維護性。
​ 大規模的系統架構通常是應用特定的—— 沒有一招鮮吃遍天的通用可擴充套件架構（不正式的叫法：**萬金油（magic scaling sauce）** ）。應用的問題可能是讀取量、寫入量、要儲存的資料量、資料的複雜度、響應時間要求、訪問模式或者所有問題的大雜燴。
​ 舉個例子，用於處理每秒十萬個請求（每個大小為1 kB）的系統與用於處理每分鐘3個請求（每個大小為2GB）的系統看上去會非常不一樣，儘管兩個系統有同樣的資料吞吐量。
​ 一個良好適配應用的可擴充套件架構，是圍繞著**假設（assumption）**建立的：哪些操作是常見的？哪些操作是罕見的？這就是所謂負載引數。如果假設最終是錯誤的，那麼為擴充套件所做的工程投入就白費了，最糟糕的是適得其反。在早期創業公司或非正式產品中，通常支援產品快速迭代的能力，要比可擴充套件至未來的假想負載要重要的多。
​ 儘管這些架構是應用程式特定的，但可擴充套件的架構通常也是從通用的積木塊搭建而成的，並以常見的模式排列。在本書中，我們將討論這些構件和模式。
## 可維護性
​ 眾所周知，軟體的大部分開銷並不在最初的開發階段，而是在持續的維護階段，包括修復漏洞、保持系統正常執行、調查失效、適配新的平臺、為新的場景進行修改、償還技術債、新增新的功能等等。
​ 不幸的是，許多從事軟體系統行業的人不喜歡維護所謂的**遺留（legacy）**系統，——也許因為涉及修復其他人的錯誤、和過時的平臺打交道，或者系統被迫使用於一些份外工作。每一個遺留系統都以自己的方式讓人不爽，所以很難給出一個通用的建議來和它們打交道。
​ 但是我們可以，也應該以這樣一種方式來設計軟體：在設計之初就儘量考慮儘可能減少維護期間的痛苦，從而避免自己的軟體系統變成遺留系統。為此，我們將特別關注軟體系統的三個設計原則：
***可操作性（Operability）***
​ 便於運維團隊保持系統平穩執行。
***簡單性（Simplicity）***
​ 從系統中消除儘可能多的**複雜度（complexity）**，使新工程師也能輕鬆理解系統。（注意這和使用者介面的簡單性不一樣。）
***可演化性（evolability）***
​ 使工程師在未來能輕鬆地對系統進行更改，當需求變化時為新應用場景做適配。也稱為**可擴充套件性（extensibility）**，**可修改性（modifiability）**或**可塑性（plasticity）**。
​ 和之前提到的可靠性、可擴充套件性一樣，實現這些目標也沒有簡單的解決方案。不過我們會試著想象具有可操作性，簡單性和可演化性的系統會是什麼樣子。
### 可操作性：人生苦短，關愛運維
​ 有人認為，“良好的運維經常可以繞開垃圾（或不完整）軟體的侷限性，而再好的軟體攤上垃圾運維也沒法可靠執行”。儘管運維的某些方面可以，而且應該是自動化的，但在最初建立正確運作的自動化機制仍然取決於人。
運維團隊對於保持軟體系統順利執行至關重要。一個優秀運維團隊的典型職責如下（或者更多）【29】：
* 監控系統的執行狀況，並在服務狀態不佳時快速恢復服務
* 跟蹤問題的原因，例如系統故障或效能下降
* 及時更新軟體和平臺，比如安全補丁
* 瞭解系統間的相互作用，以便在異常變更造成損失前進行規避。
* 預測未來的問題，並在問題出現之前加以解決（例如，容量規劃）
* 建立部署，配置、管理方面的良好實踐，編寫相應工具
* 執行復雜的維護任務，例如將應用程式從一個平臺遷移到另一個平臺
* 當配置變更時，維持系統的安全性
* 定義工作流程，使運維操作可預測，並保持生產環境穩定。
* 鐵打的營盤流水的兵，維持組織對系統的瞭解。
良好的可操作性意味著更輕鬆的日常工作，進而運維團隊能專注於高價值的事情。資料系統可以透過各種方式使日常任務更輕鬆：
* 透過良好的監控，提供對系統內部狀態和執行時行為的**可見性（visibility）**
* 為自動化提供良好支援，將系統與標準化工具相整合
* 避免依賴單臺機器（在整個系統繼續不間斷執行的情況下允許機器停機維護）
* 提供良好的文件和易於理解的操作模型（“如果做X，會發生Y”）
* 提供良好的預設行為，但需要時也允許管理員自由覆蓋預設值
* 有條件時進行自我修復，但需要時也允許管理員手動控制系統狀態
* 行為可預測，最大限度減少意外
### 簡單性：管理複雜度
​ 小型軟體專案可以使用簡單討喜的、富表現力的程式碼，但隨著專案越來越大，程式碼往往變得非常複雜，難以理解。這種複雜度拖慢了所有系統相關人員，進一步增加了維護成本。一個陷入複雜泥潭的軟體專案有時被描述為 **爛泥潭（a big ball of mud）** 【30】。
​ **複雜度（complexity）** 有各種可能的症狀，例如：狀態空間激增、模組間緊密耦合、糾結的依賴關係、不一致的命名和術語、解決效能問題的Hack、需要繞開的特例等等，現在已經有很多關於這個話題的討論【31,32,33】。
​ 因為複雜度導致維護困難時，預算和時間安排通常會超支。在複雜的軟體中進行變更，引入錯誤的風險也更大：當開發人員難以理解系統時，隱藏的假設、無意的後果和意外的互動就更容易被忽略。相反，降低複雜度能極大地提高軟體的可維護性，因此簡單性應該是構建系統的一個關鍵目標。
​ 簡化系統並不一定意味著減少功能；它也可以意味著消除**額外的（accidental）**的複雜度。 Moseley和Marks【32】把 **額外複雜度** 定義為：由具體實現中湧現，而非（從使用者視角看，系統所解決的）問題本身固有的複雜度。
​ 用於消除**額外複雜度**的最好工具之一是**抽象（abstraction）**。一個好的抽象可以將大量實現細節隱藏在一個乾淨，簡單易懂的外觀下面。一個好的抽象也可以廣泛用於各類不同應用。比起重複造很多輪子，重用抽象不僅更有效率，而且有助於開發高質量的軟體。抽象元件的質量改進將使所有使用它的應用受益。
​ 例如，高階程式語言是一種抽象，隱藏了機器碼、CPU暫存器和系統呼叫。 SQL也是一種抽象，隱藏了複雜的磁碟/記憶體資料結構、來自其他客戶端的併發請求、崩潰後的不一致性。當然在用高階語言程式設計時，我們仍然用到了機器碼；只不過沒有**直接（directly）**使用罷了，正是因為程式語言的抽象，我們才不必去考慮這些實現細節。
​ 抽象可以幫助我們將系統的複雜度控制在可管理的水平，不過，找到好的抽象是非常困難的。在分散式系統領域雖然有許多好的演算法，但我們並不清楚它們應該打包成什麼樣抽象。
​ 本書將緊盯那些允許我們將大型系統的部分提取為定義明確的、可重用的元件的優秀抽象。
### 可演化性：擁抱變化
​ 系統的需求永遠不變，基本是不可能的。更可能的情況是，它們處於常態的變化中，例如：你瞭解了新的事實、出現意想不到的應用場景、業務優先順序發生變化、使用者要求新功能、新平臺取代舊平臺、法律或監管要求發生變化、系統增長迫使架構變化等。
​ 在組織流程方面， **敏捷（agile）** 工作模式為適應變化提供了一個框架。敏捷社群還開發了對在頻繁變化的環境中開發軟體很有幫助的技術工具和模式，如 **測試驅動開發（TDD, test-driven development）** 和 **重構（refactoring）** 。
​ 這些敏捷技術的大部分討論都集中在相當小的規模（同一個應用中的幾個程式碼檔案）。本書將探索在更大資料系統層面上提高敏捷性的方法，可能由幾個不同的應用或服務組成。例如，為了將裝配主頁時間線的方法從方法1變為方法2，你會如何“重構”推特的架構 ？
​ 修改資料系統並使其適應不斷變化需求的容易程度，是與**簡單性**和**抽象性**密切相關的：簡單易懂的系統通常比複雜系統更容易修改。但由於這是一個非常重要的概念，我們將用一個不同的詞來指代資料系統層面的敏捷性： **可演化性（evolvability）** 【34】。
## 本章小結
​ 本章探討了一些關於資料密集型應用的基本思考方式。這些原則將指導我們閱讀本書的其餘部分，那裡將會深入技術細節。
​ 一個應用必須滿足各種需求才稱得上有用。有一些**功能需求（functional requirements）**（它應該做什麼，比如允許以各種方式儲存，檢索，搜尋和處理資料）以及一些**非功能性需求（nonfunctional ）**（通用屬性，例如安全性，可靠性，合規性，可擴充套件性，相容性和可維護性）。在本章詳細討論了可靠性，可擴充套件性和可維護性。
​ **可靠性（Reliability）** 意味著即使發生故障，系統也能正常工作。故障可能發生在硬體（通常是隨機的和不相關的），軟體（通常是系統性的Bug，很難處理），和人類（不可避免地時不時出錯）。 **容錯技術** 可以對終端使用者隱藏某些型別的故障。
​ **可擴充套件性（Scalability）** 意味著即使在負載增加的情況下也有保持效能的策略。為了討論可擴充套件性，我們首先需要定量描述負載和效能的方法。我們簡要了解了推特主頁時間線的例子，介紹描述負載的方法，並將響應時間百分位點作為衡量效能的一種方式。在可擴充套件的系統中可以新增 **處理容量（processing capacity）** 以在高負載下保持可靠。
​ **可維護性（Maintainability）** 有許多方面，但實質上是關於工程師和運維團隊的生活質量的。良好的抽象可以幫助降低複雜度，並使系統易於修改和適應新的應用場景。良好的可操作性意味著對系統的健康狀態具有良好的可見性，並擁有有效的管理手段。
​ 不幸的是，使應用可靠、可擴充套件或可維護並不容易。但是某些模式和技術會不斷重新出現在不同的應用中。在接下來的幾章中，我們將看到一些資料系統的例子，並分析它們如何實現這些目標。
​ 在本書後面的[第三部分](part-iii.md)中，我們將看到一種模式：幾個元件協同工作以構成一個完整的系統（如[圖1-1](../img/fig1-1.png)中的例子）
## 參考文獻
1. Michael Stonebraker and Uğur Çetintemel: “['One Size Fits All': An Idea Whose Time Has Come and Gone](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.68.9136&rep=rep1&type=pdf),” at *21st International Conference on Data Engineering* (ICDE), April 2005.
1. Walter L. Heimerdinger and Charles B. Weinstock: “[A Conceptual Framework for System Fault Tolerance](http://www.sei.cmu.edu/reports/92tr033.pdf),” Technical Report CMU/SEI-92-TR-033, Software Engineering Institute, Carnegie Mellon University, October 1992.
2. Ding Yuan, Yu Luo, Xin Zhuang, et al.: “[Simple Testing Can Prevent Most Critical Failures: An Analysis of Production Failures in Distributed Data-Intensive Systems](https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-yuan.pdf),” at *11th USENIX Symposium on Operating Systems Design and Implementation* (OSDI), October 2014.
3. Yury Izrailevsky and Ariel Tseitlin: “[The Netflix Simian Army](http://techblog.netflix.com/2011/07/netflix-simian-army.html),” *techblog.netflix.com*, July 19, 2011.
4. Daniel Ford, François Labelle, Florentina I. Popovici, et al.: “[Availability in Globally Distributed Storage Systems](http://research.google.com/pubs/archive/36737.pdf),” at *9th USENIX Symposium on Operating Systems Design and Implementation* (OSDI),
October 2010.
5. Brian Beach: “[Hard Drive Reliability Update – Sep 2014](https://www.backblaze.com/blog/hard-drive-reliability-update-september-2014/),” *backblaze.com*, September 23, 2014.
6. Laurie Voss: “[AWS: The Good, the Bad and the Ugly](https://web.archive.org/web/20160429075023/http://blog.awe.sm/2012/12/18/aws-the-good-the-bad-and-the-ugly/),” *blog.awe.sm*, December 18, 2012.
7. Haryadi S. Gunawi, Mingzhe Hao, Tanakorn Leesatapornwongsa, et al.: “[What Bugs Live in the Cloud?](http://ucare.cs.uchicago.edu/pdf/socc14-cbs.pdf),” at *5th ACM Symposium on Cloud Computing* (SoCC), November 2014. [doi:10.1145/2670979.2670986](http://dx.doi.org/10.1145/2670979.2670986)
8. Nelson Minar: “[Leap Second Crashes Half the Internet](http://www.somebits.com/weblog/tech/bad/leap-second-2012.html),” *somebits.com*, July 3, 2012.
9. Amazon Web Services: “[Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US East Region](http://aws.amazon.com/message/65648/),” *aws.amazon.com*, April 29, 2011.
10. Richard I. Cook: “[How Complex Systems Fail](http://web.mit.edu/2.75/resources/random/How%20Complex%20Systems%20Fail.pdf),” Cognitive Technologies Laboratory, April 2000.
11. Jay Kreps: “[Getting Real About Distributed System Reliability](http://blog.empathybox.com/post/19574936361/getting-real-about-distributed-system-reliability),” *blog.empathybox.com*, March 19, 2012.
12. David Oppenheimer, Archana Ganapathi, and David A. Patterson: “[Why Do Internet Services Fail, and What Can Be Done About It?](http://static.usenix.org/legacy/events/usits03/tech/full_papers/oppenheimer/oppenheimer.pdf),” at *4th USENIX Symposium on Internet Technologies and Systems* (USITS), March 2003.
13. Nathan Marz: “[Principles of Software Engineering, Part 1](http://nathanmarz.com/blog/principles-of-software-engineering-part-1.html),” *nathanmarz.com*, April 2, 2013.
14. Michael Jurewitz:“[The Human Impact of Bugs](http://jury.me/blog/2013/3/14/the-human-impact-of-bugs),” *jury.me*, March 15, 2013.
15. Raffi Krikorian: “[Timelines at Scale](http://www.infoq.com/presentations/Twitter-Timeline-Scalability),” at *QCon San Francisco*, November 2012.
16. Martin Fowler: *Patterns of Enterprise Application Architecture*. Addison Wesley, 2002. ISBN: 978-0-321-12742-6
17. Kelly Sommers: “[After all that run around, what caused 500ms disk latency even when we replaced physical server?](https://twitter.com/kellabyte/status/532930540777635840)” *twitter.com*, November 13, 2014.
18. Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, et al.: “[Dynamo: Amazon's Highly Available Key-Value Store](http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf),” at *21st ACM Symposium on Operating Systems Principles* (SOSP), October 2007.
19. Greg Linden: “[Make Data Useful](http://glinden.blogspot.co.uk/2006/12/slides-from-my-talk-at-stanford.html),” slides from presentation at Stanford University Data Mining class (CS345), December 2006.
20. Tammy Everts: “[The Real Cost of Slow Time vs Downtime](http://www.webperformancetoday.com/2014/11/12/real-cost-slow-time-vs-downtime-slides/),” *webperformancetoday.com*, November 12, 2014.
21. Jake Brutlag:“[Speed Matters for Google Web Search](http://googleresearch.blogspot.co.uk/2009/06/speed-matters.html),” *googleresearch.blogspot.co.uk*, June 22, 2009.
22. Tyler Treat: “[Everything You Know About Latency Is Wrong](http://bravenewgeek.com/everything-you-know-about-latency-is-wrong/),” *bravenewgeek.com*, December 12, 2015.
23. Jeffrey Dean and Luiz André Barroso: “[The Tail at Scale](http://cacm.acm.org/magazines/2013/2/160173-the-tail-at-scale/fulltext),” *Communications of the ACM*, volume 56, number 2, pages 74–80, February 2013. [doi:10.1145/2408776.2408794](http://dx.doi.org/10.1145/2408776.2408794)
24. Graham Cormode, Vladislav Shkapenyuk, Divesh Srivastava, and Bojian Xu: “[Forward Decay: A Practical Time Decay Model for Streaming Systems](http://dimacs.rutgers.edu/~graham/pubs/papers/fwddecay.pdf),” at *25th IEEE International Conference on Data Engineering* (ICDE), March 2009.
25. Ted Dunning and Otmar Ertl: “[Computing Extremely Accurate Quantiles Using t-Digests](https://github.com/tdunning/t-digest),” *github.com*, March 2014.
26. Gil Tene: “[HdrHistogram](http://www.hdrhistogram.org/),” *hdrhistogram.org*.
27. Baron Schwartz: “[Why Percentiles Don’t Work the Way You Think](https://www.vividcortex.com/blog/why-percentiles-dont-work-the-way-you-think),” *vividcortex.com*, December 7, 2015.
28. James Hamilton: “[On Designing and Deploying Internet-Scale Services](https://www.usenix.org/legacy/events/lisa07/tech/full_papers/hamilton/hamilton.pdf),” at *21st Large Installation
System Administration Conference* (LISA), November 2007.
29. Brian Foote and Joseph Yoder: “[Big Ball of Mud](http://www.laputan.org/pub/foote/mud.pdf),” at *4th Conference on Pattern Languages of Programs* (PLoP), September 1997.
30. Frederick P Brooks: “No Silver Bullet – Essence and Accident in Software Engineering,” in *The Mythical Man-Month*, Anniversary edition, Addison-Wesley, 1995. ISBN: 978-0-201-83595-3
31. Ben Moseley and Peter Marks: “[Out of the Tar Pit](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.93.8928),” at *BCS Software Practice Advancement* (SPA), 2006.
32. Rich Hickey: “[Simple Made Easy](http://www.infoq.com/presentations/Simple-Made-Easy),” at *Strange Loop*, September 2011.
33. Hongyu Pei Breivold, Ivica Crnkovic, and Peter J. Eriksson: “[Analyzing Software Evolvability](http://www.mrtc.mdh.se/publications/1478.pdf),” at *32nd Annual IEEE International Computer Software and Applications Conference* (COMPSAC), July 2008. [doi:10.1109/COMPSAC.2008.50](http://dx.doi.org/10.1109/COMPSAC.2008.50)
------
| 上一章 | 目錄 | 下一章 |
| ----------------------------------- | ------------------------------- | ------------------------------------ |
| [第一部分：資料系統基礎](part-i.md) | [設計資料密集型應用](README.md) | [第二章：資料模型與查詢語言](ch2.md) |

912
zh-tw/ch10.md Normal file
View File

@ -0,0 +1,912 @@
# 10. 批處理
![](../img/ch10.png)
> 帶有太強個人色彩的系統無法成功。當最初的設計完成並且相對穩定時，不同的人們以自己的方式進行測試，真正的考驗才開始。
>
> ——高德納
---------------
[TOC]
​ 在本書的前兩部分中，我們討論了很多關於**請求**和**查詢**以及相應的**響應**或**結果**。許多現有資料系統中都採用這種資料處理方式：你傳送請求指令，一段時間後(我們期望)系統會給出一個結果。資料庫，快取，搜尋索引，Web伺服器以及其他一些系統都以這種方式工作。
​ 像這樣的**線上（online）**系統，無論是瀏覽器請求頁面還是呼叫遠端API的服務，我們通常認為請求是由人類使用者觸發的，並且正在等待響應。他們不應該等太久，所以我們非常關注系統的響應時間（參閱“[描述效能](ch1.md)”）。
​ Web和越來越多的基於HTTP/REST的API使互動的請求/響應風格變得如此普遍，以至於很容易將其視為理所當然。但我們應該記住，這不是構建系統的唯一方式，其他方法也有其優點。我們來看看三種不同型別的系統：
***服務（線上系統）***
​ 服務等待客戶的請求或指令到達。每收到一個，服務會試圖儘快處理它，併發回一個響應。響應時間通常是服務效能的主要衡量指標，可用性通常非常重要（如果客戶端無法訪問服務，使用者可能會收到錯誤訊息）。
***批處理系統（離線系統）***
​ 一個批處理系統有大量的輸入資料，跑一個**作業（job）**來處理它，並生成一些輸出資料，這往往需要一段時間（從幾分鐘到幾天），所以通常不會有使用者等待作業完成。相反，批次作業通常會定期執行（例如，每天一次）。批處理作業的主要效能衡量標準通常是吞吐量（處理特定大小的輸入所需的時間）。本章中討論的就是批處理。
***流處理系統（準實時系統）***
​ 流處理介於線上和離線（批處理）之間，所以有時候被稱為**準實時（near-real-time）**或**準線上（nearline）**處理。像批處理系統一樣，流處理消費輸入併產生輸出（並不需要響應請求）。但是，流式作業在事件發生後不久就會對事件進行操作，而批處理作業則需等待固定的一組輸入資料。這種差異使流處理系統比起批處理系統具有更低的延遲。由於流處理基於批處理，我們將在[第11章](ch11.md)討論它。
​ 正如我們將在本章中看到的那樣，批處理是構建可靠，可擴充套件和可維護應用程式的重要組成部分。例如，2004年釋出的批處理演算法Map-Reduce（可能被過分熱情地）被稱為“造就Google大規模可擴充套件性的演算法”【2】。隨後在各種開源資料系統中得到應用，包括Hadoop，CouchDB和MongoDB。
​ 與多年前為資料倉庫開發的並行處理系統【3,4】相比，MapReduce是一個相當低級別的程式設計模型，但它使得在商用硬體上能進行的處理規模邁上一個新的臺階。雖然MapReduce的重要性正在下降【5】，但它仍然值得去理解，因為它描繪了一幅關於批處理為什麼有用，以及如何實用的清晰圖景。
​ 實際上，批處理是一種非常古老的計算方式。早在可程式設計數字計算機誕生之前，打孔卡製表機（例如1890年美國人口普查【6】中使用的霍爾里斯機）實現了半機械化的批處理形式，從大量輸入中彙總計算。 Map-Reduce與1940年代和1950年代廣泛用於商業資料處理的機電IBM卡片分類機器有著驚人的相似之處【7】。正如我們所說，歷史總是在不斷重複自己。
​ 在本章中，我們將瞭解MapReduce和其他一些批處理演算法和框架，並探索它們在現代資料系統中的作用。但首先我們將看看使用標準Unix工具的資料處理。即使你已經熟悉了它們，Unix的哲學也值得一讀，Unix的思想和經驗教訓可以遷移到大規模，異構的分散式資料系統中。
## 使用Unix工具的批處理
​ 我們從一個簡單的例子開始。假設您有一臺Web伺服器，每次處理請求時都會在日誌檔案中附加一行。例如，使用nginx預設訪問日誌格式，日誌的一行可能如下所示：
```bash
216.58.210.78 - - [27/Feb/2015:17:55:11 +0000] "GET /css/typography.css HTTP/1.1"
200 3377 "http://martin.kleppmann.com/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36"
```
（實際上這只是一行，分成多行只是為了便於閱讀。）這一行中有很多資訊。為了解釋它，你需要了解日誌格式的定義，如下所示：
```
$remote_addr - $remote_user [$time_local] "$request"
$status $body_bytes_sent "$http_referer" "$http_user_agent"
```
​ 日誌的這一行表明在2015年2月27日17:55:11 UTC，伺服器從客戶端IP地址`216.58.210.78`接收到對檔案`/css/typography.css`的請求。使用者沒有被認證，所以`$remote_user`被設定為連字元（`-` ）。響應狀態是200（即請求成功），響應的大小是3377位元組。網頁瀏覽器是Chrome 40，URL `http://martin.kleppmann.com/` 的頁面中的引用導致該檔案被載入。
### 分析簡單日誌
​ 很多工具可以從這些日誌檔案生成關於網站流量的漂亮的報告，但為了練手，讓我們使用基本的Unix功能建立自己的工具。 例如，假設你想在你的網站上找到五個最受歡迎的網頁。 則可以在Unix shell中這樣做：[^i]
[^i]: 有些人認為`cat`這裡並沒有必要，因為輸入檔案可以直接作為awk的引數。 但這種寫法讓線性管道更為顯眼。
```bash
cat /var/log/nginx/access.log | #1
awk '{print $7}' | #2
sort | #3
uniq -c | #4
sort -r -n | #5
head -n 5 #6
```
1. 讀取日誌檔案
2. 將每一行按空格分割成不同的欄位，每行只輸出第七個欄位，恰好是請求的URL。在我們的例子中是`/css/typography.css`。
3. 按字母順序排列請求的URL列表。如果某個URL被請求過n次，那麼排序後，檔案將包含連續重複出現n次的該URL。
4. `uniq`命令透過檢查兩個相鄰的行是否相同來過濾掉輸入中的重複行。 `-c`則表示還要輸出一個計數器：對於每個不同的URL，它會報告輸入中出現該URL的次數。
5. 第二種排序按每行起始處的數字（`-n`）排序，這是URL的請求次數。然後逆序（`-r`）返回結果，大的數字在前。
6. 最後，只輸出前五行（`-n 5`），並丟棄其餘的。該系列命令的輸出如下所示：
```
4189 /favicon.ico
3631 /2013/05/24/improving-security-of-ssh-private-keys.html
2124 /2012/12/05/schema-evolution-in-avro-protocol-buffers-thrift.html
1369 /
915 /css/typography.css
```
​ 如果你不熟悉Unix工具，上面的命令列可能看起來有點吃力，但是它非常強大。它能在幾秒鐘內處理幾GB的日誌檔案，並且您可以根據需要輕鬆修改命令。例如，如果要從報告中省略CSS檔案，可以將awk引數更改為`'$7 !~ /\.css$/ {print $7}'`,如果想統計最多的客戶端IP地址,可以把awk引數改為`'{print $1}'`等等。
​ 我們不會在這裡詳細探索Unix工具，但是它非常值得學習。令人驚訝的是，使用awk，sed，grep，sort，uniq和xargs的組合，可以在幾分鐘內完成許多資料分析，並且它們的效能相當的好【8】。
#### 命令鏈與自定義程式
除了Unix命令鏈，你還可以寫一個簡單的程式來做同樣的事情。例如在Ruby中，它可能看起來像這樣：
```ruby
counts = Hash.new(0) # 1
File.open('/var/log/nginx/access.log') do |file|
file.each do |line|
url = line.split[6] # 2
counts[url] += 1 # 3
end
end
top5 = counts.map{|url, count| [count, url] }.sort.reverse[0...5] # 4
top5.each{|count, url| puts "#{count} #{url}" } # 5
```
1. `counts`是一個儲存計數器的雜湊表，儲存了每個URL被瀏覽的次數，預設為0。
2. 逐行讀取日誌，抽取每行第七個被空格分隔的欄位為URL（這裡的陣列索引是6，因為Ruby的陣列索引從0開始計數）
3. 將日誌當前行中URL對應的計數器值加一。
4. 按計數器值（降序）對雜湊表內容進行排序，並取前五位。
5. 打印出前五個條目。
這個程式並不像Unix管道那樣簡潔，但是它的可讀性很強，喜歡哪一種屬於口味的問題。但兩者除了表面上的差異之外，執行流程也有很大差異，如果你在大檔案上執行此分析，則會變得明顯。
#### 排序 VS 記憶體中的聚合
​ Ruby指令碼在記憶體中儲存了一個URL的雜湊表，將每個URL對映到它出現的次數。 Unix管道沒有這樣的雜湊表，而是依賴於對URL列表的排序，在這個URL列表中，同一個URL的只是簡單地重複出現。
​ 哪種方法更好？這取決於你有多少個不同的URL。對於大多數中小型網站，你可能可以為所有不同網址提供一個計數器（假設我們使用1GB記憶體）。在此例中，作業的**工作集（working set）**（作業需要隨機訪問的記憶體大小）僅取決於不同URL的數量：如果日誌中只有單個URL，重複出現一百萬次，則散列表所需的空間表就只有一個URL加上一個計數器的大小。當工作集足夠小時，記憶體散列表表現良好，甚至在效能較差的膝上型電腦上也可以正常工作。
​ 另一方面，如果作業的工作集大於可用記憶體，則排序方法的優點是可以高效地使用磁碟。這與我們在“[SSTables和LSM樹](ch3.md#SSTables和LSM樹)”中討論過的原理是一樣的：資料塊可以在記憶體中排序並作為段檔案寫入磁碟，然後多個排序好的段可以合併為一個更大的排序檔案。 歸併排序具有在磁碟上執行良好的順序訪問模式。 （請記住，針對順序I/O進行最佳化是[第3章](ch3.md)中反覆出現的主題，相同的模式在此重現）
​ GNU Coreutils（Linux）中的`sort `程式透過溢位至磁碟的方式來自動應對大於記憶體的資料集，並能同時使用多個CPU核進行並行排序【9】。這意味著我們之前看到的簡單的Unix命令鏈很容易擴充套件到大資料集，且不會耗盡記憶體。瓶頸可能是從磁碟讀取輸入檔案的速度。
### Unix哲學
​ 我們可以非常容易地使用前一個例子中的一系列命令來分析日誌檔案，這並非巧合：事實上，這實際上是Unix的關鍵設計思想之一，且它今天仍然令人訝異地關聯。讓我們更深入地研究一下，以便從Unix中借鑑一些想法【10】。
​ Unix管道的發明者道格·麥克羅伊（Doug McIlroy）在1964年首先描述了這種情況【11】：“當我們需要將訊息從一個程式傳遞另一個程式時，我們需要一種類似水管法蘭的拼接程式的方式【a】 ，I/O應該也按照這種方式進行“。水管的類比仍然在生效，透過管道連線程式的想法成為了現在被稱為**Unix哲學**的一部分 —— 這一組設計原則在Unix使用者與開發者之間流行起來，該哲學在1978年表述如下【12,13】：
1. 讓每個程式都做好一件事。要做一件新的工作，寫一個新程式，而不是透過新增“功能”讓老程式複雜化。
2. 期待每個程式的輸出成為另一個程式的輸入。不要將無關資訊混入輸出。避免使用嚴格的列資料或二進位制輸入格式。不要堅持互動式輸入。
3. 設計和構建軟體，甚至是作業系統，要儘早嘗試，最好在幾周內完成。不要猶豫，扔掉笨拙的部分，重建它們。
4. 優先使用工具來減輕程式設計任務，即使必須曲線救國編寫工具，且在用完後很可能要扔掉大部分。
這種方法 —— 自動化，快速原型設計，增量式迭代，對實驗友好，將大型專案分解成可管理的塊 —— 聽起來非常像今天的敏捷開發和DevOps運動。奇怪的是，四十年來變化不大。
​ `sort`工具是一個很好的例子。可以說它比大多數程式語言標準庫中的實現（它們不會利用磁碟或使用多執行緒，即使這樣做有很大好處）要更好。然而，單獨使用`sort` 幾乎沒什麼用。它只能與其他Unix工具（如`uniq`）結合使用。
​ 像 `bash`這樣的Unix shell可以讓我們輕鬆地將這些小程式組合成令人訝異的強大資料處理任務。儘管這些程式中有很多是由不同人群編寫的，但它們可以靈活地結合在一起。 Unix如何實現這種可組合性？
#### 統一的介面
​ 如果你希望一個程式的輸出成為另一個程式的輸入，那意味著這些程式必須使用相同的資料格式 —— 換句話說，一個相容的介面。如果你希望能夠將任何程式的輸出連線到任何程式的輸入，那意味著所有程式必須使用相同的I/O介面。
​ 在Unix中，這種介面是一個**檔案（file）**（更準確地說，是一個檔案描述符）。一個檔案只是一串有序的位元組序列。因為這是一個非常簡單的介面，所以可以使用相同的介面來表示許多不同的東西：檔案系統上的真實檔案，到另一個程序（Unix套接字，stdin，stdout）的通訊通道，裝置驅動程式（比如`/dev/audio`或`/dev/lp0`），表示TCP連線的套接字等等。很容易將這些設計視為理所當然的，但實際上能讓這些差異巨大的東西共享一個統一的介面是非常厲害的，這使得它們可以很容易地連線在一起[^ii]。
[^ii]: 統一介面的另一個例子是URL和HTTP，這是Web的基石。 一個URL標識一個網站上的一個特定的東西（資源），你可以連結到任何其他網站的任何網址。 具有網路瀏覽器的使用者因此可以透過跟隨連結在網站之間無縫跳轉，即使伺服器可能由完全不相關的組織維護。 這個原則現在似乎非常明顯，但它卻是網路取能取得今天成就的關鍵。 之前的系統並不是那麼統一：例如，在公告板系統（BBS）時代，每個系統都有自己的電話號碼和波特率配置。 從一個BBS到另一個BBS的引用必須以電話號碼和調變解調器設定的形式；使用者將不得不掛斷，撥打其他BBS，然後手動找到他們正在尋找的資訊。 這是不可能的直接連結到另一個BBS內的一些內容。
​ 按照慣例，許多（但不是全部）Unix程式將這個位元組序列視為ASCII文字。我們的日誌分析示例使用了這個事實：`awk`，`sort`，`uniq`和`head`都將它們的輸入檔案視為由`\n`（換行符，ASCII `0x0A`）字元分隔的記錄列表。 `\n`的選擇是任意的 —— 可以說，ASCII記錄分隔符`0x1E`本來就是一個更好的選擇，因為它是為了這個目的而設計的【14】，但是無論如何，所有這些程式都使用相同的記錄分隔符允許它們互操作。
​ 每條記錄（即一行輸入）的解析則更加模糊。 Unix工具通常透過空白或製表符將行分割成欄位，但也使用CSV（逗號分隔），管道分隔和其他編碼。即使像`xargs`這樣一個相當簡單的工具也有六個命令列選項，用於指定如何解析輸入。
​ ASCII文字的統一介面大多數時候都能工作，但它不是很優雅：我們的日誌分析示例使用`{print $7}`來提取網址，這樣可讀性不是很好。在理想的世界中可能是`{print $request_url}`或類似的東西。我們稍後會回顧這個想法。
​ 儘管幾十年後還不夠完美，但統一的Unix介面仍然是非常出色的設計。沒有多少軟體能像Unix工具一樣互動組合的這麼好：你不能透過自定義分析工具輕鬆地將電子郵件帳戶的內容和線上購物歷史記錄以管道傳送至電子表格中，並將結果釋出到社交網路或維基。今天，像Unix工具一樣流暢地執行程式是一種例外，而不是規範。
​ 即使是具有**相同資料模型**的資料庫，將資料從一種匯出再匯入另一種也並不容易。缺乏整合導致了資料的**巴爾幹化**[^譯註i]。
[^譯註i]: **巴爾幹化（Balkanization）**是一個常帶有貶義的地緣政治學術語，其定義為：一個國家或政區分裂成多個互相敵對的國家或政區的過程。
#### 邏輯與佈線相分離
​ Unix工具的另一個特點是使用標準輸入（`stdin`）和標準輸出（`stdout`）。如果你執行一個程式，而不指定任何其他的東西，標準輸入來自鍵盤，標準輸出指向螢幕。但是，你也可以從檔案輸入和/或將輸出重定向到檔案。管道允許你將一個程序的標準輸出附加到另一個程序的標準輸入（有個小記憶體緩衝區，而不需要將整個中間資料流寫入磁碟）。
​ 程式仍然可以直接讀取和寫入檔案，但如果程式不擔心特定的檔案路徑，只使用標準輸入和標準輸出，則Unix方法效果最好。這允許shell使用者以任何他們想要的方式連線輸入和輸出；該程式不知道或不關心輸入來自哪裡以及輸出到哪裡。 （人們可以說這是一種**松耦合（loose coupling）**，**晚期繫結（late binding）**【15】或**控制反轉（inversion of control）**【16】）。將輸入/輸出佈線與程式邏輯分開，可以將小工具組合成更大的系統。
​ 你甚至可以編寫自己的程式，並將它們與作業系統提供的工具組合在一起。你的程式只需要從標準輸入讀取輸入，並將輸出寫入標準輸出，它就可以加入資料處理的管道中。在日誌分析示例中，你可以編寫一個將Usage-Agent字串轉換為更靈敏的瀏覽器識別符號，或者將IP地址轉換為國家程式碼的工具，並將其插入管道。`sort`程式並不關心它是否與作業系統的另一部分或者你寫的程式通訊。
​ 但是，使用`stdin`和`stdout`能做的事情是有限的。需要多個輸入或輸出的程式是可能的，但非常棘手。你沒法將程式的輸出管道連線至網路連線中【17,18】[^iii] 。如果程式直接開啟檔案進行讀取和寫入，或者將另一個程式作為子程序啟動，或者開啟網路連線，那麼I/O的佈線就取決於程式本身了。它仍然可以被配置（例如透過命令列選項），但在Shell中對輸入和輸出進行佈線的靈活性就少了。
[^iii]: 除了使用一個單獨的工具，如`netcat`或`curl`。 Unix開始試圖將所有東西都表示為檔案，但是BSD套接字API偏離了這個慣例【17】。研究用作業系統Plan 9和Inferno在使用檔案方面更加一致：它們將TCP連線表示為`/net/tcp`中的檔案【18】。
#### 透明度和實驗
使Unix工具如此成功的部分原因是，它們使檢視正在發生的事情變得非常容易：
- Unix命令的輸入檔案通常被視為不可變的。這意味著你可以隨意執行命令，嘗試各種命令列選項，而不會損壞輸入檔案。
- 你可以在任何時候結束管道，將管道輸出到`less`，然後檢視它是否具有預期的形式。這種檢查能力對除錯非常有用。
- 你可以將一個流水線階段的輸出寫入檔案，並將該檔案用作下一階段的輸入。這使你可以重新啟動後面的階段，而無需重新執行整個管道。
因此，與關係資料庫的查詢最佳化器相比，即使Unix工具非常簡單，但仍然非常有用，特別是對於實驗而言。
然而，Unix工具的最大侷限在於它們只能在一臺機器上執行 —— 而Hadoop這樣的工具即應運而生。
## MapReduce和分散式檔案系統
​ MapReduce有點像Unix工具，但分佈在數千臺機器上。像Unix工具一樣，它相當簡單粗暴，但令人驚異地管用。一個MapReduce作業可以和一個Unix程序相類比：它接受一個或多個輸入，併產生一個或多個輸出。
​ 和大多數Unix工具一樣，執行MapReduce作業通常不會修改輸入，除了生成輸出外沒有任何副作用。輸出檔案以連續的方式一次性寫入（一旦寫入檔案，不會修改任何現有的檔案部分）。
​ 雖然Unix工具使用`stdin`和`stdout`作為輸入和輸出，但MapReduce作業在分散式檔案系統上讀寫檔案。在Hadoop的Map-Reduce實現中，該檔案系統被稱為**HDFS（Hadoop分散式檔案系統）**，一個Google檔案系統（GFS）的開源實現【19】。
​ 除HDFS外，還有各種其他分散式檔案系統，如GlusterFS和Quantcast File System（QFS）【20】。諸如Amazon S3，Azure Blob儲存和OpenStack Swift 【21】等物件儲存服務在很多方面都是相似的[^iv]。在本章中，我們將主要使用HDFS作為示例，但是這些原則適用於任何分散式檔案系統。
[^iv]: 一個不同之處在於，對於HDFS，可以將計算任務安排在儲存特定檔案副本的計算機上執行，而物件儲存通常將儲存和計算分開。如果網路頻寬是一個瓶頸，從本地磁碟讀取有效能優勢。但是請注意，如果使用糾刪碼，則會丟失區域性性，因為來自多臺機器的資料必須進行合併以重建原始檔案【20】。
​ 與網路連線儲存（NAS）和儲存區域網路（SAN）架構的共享磁碟方法相比，HDFS基於**無共享**原則（參見[第二部分前言](part-ii.md)）。共享磁碟儲存由集中式儲存裝置實現，通常使用定製硬體和專用網路基礎設施（如光纖通道）。而另一方面，無共享方法不需要特殊的硬體，只需要透過傳統資料中心網路連線的計算機。
​ HDFS包含在每臺機器上執行的守護程序，對外暴露網路服務，允許其他節點訪問儲存在該機器上的檔案（假設資料中心中的每臺通用計算機都掛載著一些磁碟）。名為**NameNode**的中央伺服器會跟蹤哪個檔案塊儲存在哪臺機器上。因此，HDFS在概念上建立了一個大型檔案系統，可以使用所有執行有守護程序的機器的磁碟。
​ 為了容忍機器和磁碟故障，檔案塊被複制到多臺機器上。複製可能意味著多個機器上的相同資料的多個副本，如[第5章](ch5.md)中所述，或者諸如Reed-Solomon碼這樣的糾刪碼方案，它允許以比完全複製更低的儲存開銷以恢復丟失的資料【20,22】。這些技術與RAID相似，可以在連線到同一臺機器的多個磁碟上提供冗餘；區別在於在分散式檔案系統中，檔案訪問和複製是在傳統的資料中心網路上完成的，沒有特殊的硬體。
​ HDFS已經擴充套件的很不錯了：在撰寫本書時，最大的HDFS部署執行在上萬臺機器上，總儲存容量達數百PB【23】。如此大的規模已經變得可行，因為使用商品硬體和開源軟體的HDFS上的資料儲存和訪問成本遠低於專用儲存裝置上的同等容量【24】。
### MapReduce作業執行
​ MapReduce是一個程式設計框架，你可以使用它編寫程式碼來處理HDFS等分散式檔案系統中的大型資料集。理解它的最簡單方法是參考“[簡單日誌分析](#簡單日誌分析)”中的Web伺服器日誌分析示例。MapReduce中的資料處理模式與此示例非常相似：
1. 讀取一組輸入檔案，並將其分解成**記錄（records）**。在Web伺服器日誌示例中，每條記錄都是日誌中的一行（即`\n`是記錄分隔符）。
2. 呼叫Mapper函式，從每條輸入記錄中提取一對鍵值。在前面的例子中，Mapper函式是`awk '{print $7}'`：它提取URL（`$7`）作為關鍵字，並將值留空。
3. 按鍵排序所有的鍵值對。在日誌的例子中，這由第一個`sort`命令完成。
4. 呼叫Reducer函式遍歷排序後的鍵值對。如果同一個鍵出現多次，排序使它們在列表中相鄰，所以很容易組合這些值而不必在記憶體中保留很多狀態。在前面的例子中，Reducer是由`uniq -c`命令實現的，該命令使用相同的鍵來統計相鄰記錄的數量。
這四個步驟可以作為一個MapReduce作業執行。步驟2（Map）和4（Reduce）是你編寫自定義資料處理程式碼的地方。步驟1（將檔案分解成記錄）由輸入格式解析器處理。步驟3中的排序步驟隱含在MapReduce中 —— 你不必編寫它，因為Mapper的輸出始終在送往Reducer之前進行排序。
要建立MapReduce作業，你需要實現兩個回撥函式，Mapper和Reducer，其行為如下（參閱“[MapReduce查詢](ch2.md#MapReduce查詢)”）：
***Mapper***
​ Mapper會在每條輸入記錄上呼叫一次，其工作是從輸入記錄中提取鍵值。對於每個輸入，它可以生成任意數量的鍵值對（包括None）。它不會保留從一個輸入記錄到下一個記錄的任何狀態，因此每個記錄都是獨立處理的。
***Reducer***
MapReduce框架拉取由Mapper生成的鍵值對，收集屬於同一個鍵的所有值，並使用在這組值列表上迭代呼叫Reducer。 Reducer可以產生輸出記錄（例如相同URL的出現次數）。
​ 在Web伺服器日誌的例子中，我們在第5步中有第二個`sort`命令，它按請求數對URL進行排序。在MapReduce中，如果你需要第二個排序階段，則可以透過編寫第二個MapReduce作業並將第一個作業的輸出用作第二個作業的輸入來實現它。這樣看來，Mapper的作用是將資料放入一個適合排序的表單中，並且Reducer的作用是處理已排序的資料。
#### 分散式執行MapReduce
​ MapReduce與Unix命令管道的主要區別在於，MapReduce可以在多臺機器上並行執行計算，而無需編寫程式碼來顯式處理並行問題。Mapper和Reducer一次只能處理一條記錄；它們不需要知道它們的輸入來自哪裡，或者輸出去往什麼地方，所以框架可以處理在機器之間移動資料的複雜性。
​ 在分散式計算中可以使用標準的Unix工具作為Mapper和Reducer【25】，但更常見的是，它們被實現為傳統程式語言的函式。在Hadoop MapReduce中，Mapper和Reducer都是實現特定介面的Java類。在MongoDB和CouchDB中，Mapper和Reducer都是JavaScript函式（參閱“[MapReduce查詢](ch2.md#MapReduce查詢)”）。
​ [圖10-1]()顯示了Hadoop MapReduce作業中的資料流。其並行化基於分割槽（參見[第6章](ch6.md)）：作業的輸入通常是HDFS中的一個目錄，輸入目錄中的每個檔案或檔案塊都被認為是一個單獨的分割槽，可以單獨處理map任務（[圖10-1](../img/fig10-1.png)中的m1，m2和m3標記）。
​ 每個輸入檔案的大小通常是數百兆位元組。 MapReduce排程器（圖中未顯示）試圖在其中一臺儲存輸入檔案副本的機器上執行每個Mapper，只要該機器有足夠的備用RAM和CPU資源來執行Mapper任務【26】。這個原則被稱為**將計算放在資料附近**【27】：它節省了透過網路複製輸入檔案的開銷，減少網路負載並增加區域性性。
![](../img/fig10-1.png)
**圖10-1 具有三個Mapper和三個Reducer的MapReduce任務**
​ 在大多數情況下，應該在Mapper任務中執行的應用程式碼在將要執行它的機器上還不存在，所以MapReduce框架首先將程式碼（例如Java程式中的JAR檔案）複製到適當的機器。然後啟動Map任務並開始讀取輸入檔案，一次將一條記錄傳入Mapper回撥函式。Mapper的輸出由鍵值對組成。
​ 計算的Reduce端也被分割槽。雖然Map任務的數量由輸入檔案塊的數量決定，但Reducer的任務的數量是由作業作者配置的（它可以不同於Map任務的數量）。為了確保具有相同鍵的所有鍵值對最終落在相同的Reducer處，框架使用鍵的雜湊值來確定哪個Reduce任務應該接收到特定的鍵值對（參見“[按鍵雜湊分割槽](ch6.md#按鍵雜湊分割槽)”））。
​ 鍵值對必須進行排序，但資料集可能太大，無法在單臺機器上使用常規排序演算法進行排序。相反，分類是分階段進行的。首先每個Map任務都按照Reducer對輸出進行分割槽。每個分割槽都被寫入Mapper程式的本地磁碟，使用的技術與我們在“[SSTables與LSM樹](ch3.md#SSTables與LSM樹)”中討論的類似。
​ 只要當Mapper讀取完輸入檔案，並寫完排序後的輸出檔案，MapReduce排程器就會通知Reducer可以從該Mapper開始獲取輸出檔案。Reducer連線到每個Mapper，並下載自己相應分割槽的有序鍵值對檔案。按Reducer分割槽，排序，從Mapper向Reducer複製分割槽資料，這一整個過程被稱為**混洗（shuffle）**【26】（一個容易混淆的術語 —— 不像洗牌，在MapReduce中的混洗沒有隨機性）。
​ Reduce任務從Mapper獲取檔案，並將它們合併在一起，並保留有序特性。因此，如果不同的Mapper生成了鍵相同的記錄，則在Reducer的輸入中，這些記錄將會相鄰。
​ Reducer呼叫時會收到一個鍵，和一個迭代器作為引數，迭代器會順序地掃過所有具有該鍵的記錄（因為在某些情況可能無法完全放入記憶體中）。Reducer可以使用任意邏輯來處理這些記錄，並且可以生成任意數量的輸出記錄。這些輸出記錄會寫入分散式檔案系統上的檔案中（通常是在跑Reducer的機器本地磁碟上留一份，並在其他機器上留幾份副本）。
#### MapReduce工作流
​ 單個MapReduce作業可以解決的問題範圍很有限。以日誌分析為例，單個MapReduce作業可以確定每個URL的頁面瀏覽次數，但無法確定最常見的URL，因為這需要第二輪排序。
​ 因此將MapReduce作業連結成為**工作流（workflow）**中是極為常見的，例如，一個作業的輸出成為下一個作業的輸入。 Hadoop Map-Reduce框架對工作流沒有特殊支援，所以這個鏈是透過目錄名隱式實現的：第一個作業必須將其輸出配置為HDFS中的指定目錄，第二個作業必須將其輸入配置為從同一個目錄。從MapReduce框架的角度來看，這是是兩個獨立的作業。
​ 因此，被連結的MapReduce作業並沒有那麼像Unix命令管道（它直接將一個程序的輸出作為另一個程序的輸入，僅用一個很小的記憶體緩衝區）。它更像是一系列命令，其中每個命令的輸出寫入臨時檔案，下一個命令從臨時檔案中讀取。這種設計有利也有弊，我們將在“[物化中間狀態](#物化中間狀態)”中討論。
​ 只有當作業成功完成後，批處理作業的輸出才會被視為有效的（MapReduce會丟棄失敗作業的部分輸出）。因此，工作流中的一項作業只有在先前的作業 —— 即生產其輸入的作業 —— 成功完成後才能開始。為了處理這些作業之間的依賴，有很多針對Hadoop的工作流排程器被開發出來，包括Oozie，Azkaban，Luigi，Airflow和Pinball 【28】。
​ 這些排程程式還具有管理功能，在維護大量批處理作業時非常有用。在構建推薦系統時，由50到100個MapReduce作業組成的工作流是常見的【29】。而在大型組織中，許多不同的團隊可能執行不同的作業來讀取彼此的輸出。工具支援對於管理這樣複雜的資料流而言非常重要。
​ Hadoop的各種高階工具（如Pig 【30】，Hive 【31】，Cascading 【32】，Crunch 【33】和FlumeJava 【34】）也能自動佈線組裝多個MapReduce階段，生成合適的工作流。
### Reduce端連線與分組
​ 我們在[第2章](ch2.md)中討論了資料模型和查詢語言的聯接，但是我們還沒有深入探討連線是如何實現的。現在是我們再次撿起這條線索的時候了。
​ 在許多資料集中，一條記錄與另一條記錄存在關聯是很常見的：關係模型中的**外來鍵**，文件模型中的**文件引用**或圖模型中的**邊**。當你需要同時訪問這一關聯的兩側（持有引用的記錄與被引用的記錄）時，連線就是必須的。（包含引用的記錄和被引用的記錄），連線就是必需的。正如[第2章](ch2.md)所討論的，非規範化可以減少對連線的需求，但通常無法將其完全移除[^v]。
[^v]: 我們在本書中討論的連線通常是等值連線，即最常見的連線型別，其中記錄與其他記錄在特定欄位（例如ID）中具有**相同值**相關聯。有些資料庫支援更通用的連線型別，例如使用小於運算子而不是等號運算子，但是我們沒有地方來講這些東西。
​ 在資料庫中，如果執行只涉及少量記錄的查詢，資料庫通常會使用**索引**來快速定位感興趣的記錄（參閱[第3章](ch3.md)）。如果查詢涉及到連線，則可能涉及到查詢多個索引。然而MapReduce沒有索引的概念 —— 至少在通常意義上沒有。
​ 當MapReduce作業被賦予一組檔案作為輸入時，它讀取所有這些檔案的全部內容；資料庫會將這種操作稱為**全表掃描**。如果你只想讀取少量的記錄，則全表掃描與索引查詢相比，代價非常高昂。但是在分析查詢中（參閱“[事務處理或分析？](ch3.md#事務處理還是分析？)”），通常需要計算大量記錄的聚合。在這種情況下，特別是如果能在多臺機器上並行處理時，掃描整個輸入可能是相當合理的事情。
​ 當我們在批處理的語境中討論連線時，我們指的是在資料集中解析某種關聯的全量存在。 例如我們假設一個作業是同時處理所有使用者的資料，而非僅僅是為某個特定使用者查詢資料（而這能透過索引更高效地完成）。
#### 示例：分析使用者活動事件
​ [圖10-2](../img/fig10-2.png)給出了一個批處理作業中連線的典型例子。左側是事件日誌，描述登入使用者在網站上做的事情（稱為**活動事件（activity events）**或**點選流資料（clickstream data）**），右側是使用者資料庫。 你可以將此示例看作是星型模式的一部分（參閱“[星型和雪花型：分析的模式](ch3.md#星型和雪花型：分析的模式)”）：事件日誌是事實表，使用者資料庫是其中的一個維度。
![](../img/fig10-2.png)
**圖10-2 使用者行為日誌與使用者檔案的連線**
​ 分析任務可能需要將使用者活動與使用者簡檔相關聯：例如，如果檔案包含使用者的年齡或出生日期，系統就可以確定哪些頁面更受哪些年齡段的使用者歡迎。然而活動事件僅包含使用者ID，而沒有包含完整的使用者檔案資訊。在每個活動事件中嵌入這些檔案資訊很可能會非常浪費。因此，活動事件需要與使用者檔案資料庫相連線。
​ 實現這一連線的最簡單方法是，逐個遍歷活動事件，併為每個遇到的使用者ID查詢使用者資料庫（在遠端伺服器上）。這是可能的，但是它的效能可能會非常差：處理吞吐量將受限於受資料庫伺服器的往返時間，本地快取的有效性很大程度上取決於資料的分佈，並行執行大量查詢可能會輕易壓垮資料庫【35】。
​ 為了在批處理過程中實現良好的吞吐量，計算必須（儘可能）限於單臺機器上進行。為待處理的每條記錄發起隨機訪問的網路請求實在是太慢了。而且，查詢遠端資料庫意味著批處理作業變為**非確定的（nondeterministic）**，因為遠端資料庫中的資料可能會改變。
​ 因此，更好的方法是獲取使用者資料庫的副本（例如，使用ETL程序從資料庫備份中提取資料，參閱“[資料倉庫](ch3.md#資料倉庫)”），並將它和使用者行為日誌放入同一個分散式檔案系統中。然後你可以將使用者資料庫儲存在HDFS中的一組檔案中，而使用者活動記錄儲存在另一組檔案中，並能用MapReduce將所有相關記錄集中到同一個地方進行高效處理。
#### 排序合併連線
​ 回想一下，Mapper的目的是從每個輸入記錄中提取一對鍵值。在[圖10-2](../img/fig10-2.png)的情況下，這個鍵就是使用者ID：一組Mapper會掃過活動事件（提取使用者ID作為鍵，活動事件作為值），而另一組Mapper將會掃過使用者資料庫（提取使用者ID作為鍵，使用者的出生日期作為值）。這個過程如[圖10-3](../img/fig10-3.png)所示。
![](../img/fig10-3.png)
**圖10-3 在使用者ID上進行的Reduce端連線。如果輸入資料集分割槽為多個檔案，則每個分割槽都會被多個Mapper並行處理**
​ 當MapReduce框架透過鍵對Mapper輸出進行分割槽，然後對鍵值對進行排序時，效果是具有相同ID的所有活動事件和使用者記錄在Reducer輸入中彼此相鄰。 Map-Reduce作業甚至可以也讓這些記錄排序，使Reducer總能先看到來自使用者資料庫的記錄，緊接著是按時間戳順序排序的活動事件 —— 這種技術被稱為**二次排序（secondary sort）**【26】。
​ 然後Reducer可以容易地執行實際的連線邏輯：每個使用者ID都會被呼叫一次Reducer函式，且因為二次排序，第一個值應該是來自使用者資料庫的出生日期記錄。 Reducer將出生日期儲存在區域性變數中，然後使用相同的使用者ID遍歷活動事件，輸出**已觀看網址**和**觀看者年齡**的結果對。隨後的Map-Reduce作業可以計算每個URL的檢視者年齡分佈，並按年齡段進行聚集。
​ 由於Reducer一次處理一個特定使用者ID的所有記錄，因此一次只需要將一條使用者記錄儲存在記憶體中，而不需要透過網路發出任何請求。這個演算法被稱為**排序合併連線（sort-merge join）**，因為Mapper的輸出是按鍵排序的，然後Reducer將來自連線兩側的有序記錄列表合併在一起。
#### 把相關資料放在一起
​ 在排序合併連線中，Mapper和排序過程確保了所有對特定使用者ID執行連線操作的必須資料都被放在同一個地方：單次呼叫Reducer的地方。預先排好了所有需要的資料，Reducer可以是相當簡單的單執行緒程式碼，能夠以高吞吐量和與低記憶體開銷掃過這些記錄。
​ 這種架構可以看做，Mapper將“訊息”傳送給Reducer。當一個Mapper發出一個鍵值對時，這個鍵的作用就像值應該傳遞到的目標地址。即使鍵只是一個任意的字串（不是像IP地址和埠號那樣的實際的網路地址），它表現的就像一個地址：所有具有相同鍵的鍵值對將被傳遞到相同的目標（一次Reduce的呼叫）。
​ 使用MapReduce程式設計模型，能將計算的物理網路通訊層面（從正確的機器獲取資料）從應用邏輯中剝離出來（獲取資料後執行處理）。這種分離與資料庫的典型用法形成了鮮明對比，從資料庫中獲取資料的請求經常出現在應用程式碼內部【36】。由於MapReduce能夠處理所有的網路通訊，因此它也避免了應用程式碼去擔心部分故障，例如另一個節點的崩潰：MapReduce在不影響應用邏輯的情況下能透明地重試失敗的任務。
### GROUP BY
​ 除了連線之外，“把相關資料放在一起”的另一種常見模式是，按某個鍵對記錄分組（如SQL中的GROUP BY子句）。所有帶有相同鍵的記錄構成一個組，而下一步往往是在每個組內進行某種聚合操作，例如：
- 統計每個組中記錄的數量（例如在統計PV的例子中，在SQL中表示為`COUNT(*)`聚合）
- 對某個特定欄位求和（SQL中的`SUM(fieldname)`）
- 按某種分級函式取出排名前k條記錄。
使用MapReduce實現這種分組操作的最簡單方法是設定Mapper，以便它們生成的鍵值對使用所需的分組鍵。然後分割槽和排序過程將所有具有相同分割槽鍵的記錄導向同一個Reducer。因此在MapReduce之上實現分組和連線看上去非常相似。
​ 分組的另一個常見用途是整理特定使用者會話的所有活動事件，以找出使用者進行的一系列操作（稱為**會話化（sessionization）**【37】）。例如，可以使用這種分析來確定顯示新版網站的使用者是否比那些顯示舊版本（A/B測試）的使用者更有購買慾，或者計算某個營銷活動是否值得。
​ 如果你有多個Web伺服器處理使用者請求，則特定使用者的活動事件很可能分散在各個不同的伺服器的日誌檔案中。你可以透過使用會話cookie，使用者ID或類似的識別符號作為分組鍵，以將特定使用者的所有活動事件放在一起來實現會話化，與此同時，不同使用者的事件仍然散步在不同的分割槽中。
#### 處理傾斜
​ 如果存在與單個鍵關聯的大量資料，則“將具有相同鍵的所有記錄放到相同的位置”這種模式就被破壞了。例如在社交網路中，大多數使用者可能會與幾百人有連線，但少數名人可能有數百萬的追隨者。這種不成比例的活動資料庫記錄被稱為**關鍵物件（linchpin object）**【38】或**熱鍵（hot key）**。
​ 在單個Reducer中收集與某個名流相關的所有活動（例如他們釋出內容的回覆）可能導致嚴重的傾斜（也稱為**熱點（hot spot）**）—— 也就是說，一個Reducer必須比其他Reducer處理更多的記錄（參見“[負載傾斜與消除熱點](ch6.md#負載傾斜與消除熱點)“）。由於MapReduce作業只有在所有Mapper和Reducer都完成時才完成，所有後續作業必須等待最慢的Reducer才能啟動。
​ 如果連線的輸入存在熱點鍵，可以使用一些演算法進行補償。例如，Pig中的**傾斜連線（skewed join）**方法首先執行一個抽樣作業來確定哪些鍵是熱鍵【39】。連線實際執行時，Mapper會將熱鍵的關聯記錄**隨機**（相對於傳統MapReduce基於鍵雜湊的確定性方法）傳送到幾個Reducer之一。對於另外一側的連線輸入，與熱鍵相關的記錄需要被複制到所有處理該鍵的Reducer上【40】。
​ 這種技術將處理熱鍵的工作分散到多個Reducer上，這樣可以使其更好地並行化，代價是需要將連線另一側的輸入記錄複製到多個Reducer上。 Crunch中的**分片連線（sharded join）**方法與之類似，但需要顯式指定熱鍵而不是使用取樣作業。這種技術也非常類似於我們在“[負載傾斜與消除熱點](ch6.md#負載傾斜與消除熱點)”中討論的技術，使用隨機化來緩解分割槽資料庫中的熱點。
​ Hive的偏斜連線最佳化採取了另一種方法。它需要在表格元資料中顯式指定熱鍵，並將與這些鍵相關的記錄單獨存放，與其它檔案分開。當在該表上執行連線時，對於熱鍵，它會使用Map端連線（參閱[下一節](#Map端連線)）。
​ 當按照熱鍵進行分組並聚合時，可以將分組分兩個階段進行。第一個MapReduce階段將記錄傳送到隨機Reducer，以便每個Reducer只對熱鍵的子集執行分組，為每個鍵輸出一個更緊湊的中間聚合結果。然後第二個MapReduce作業將所有來自第一階段Reducer的中間聚合結果合併為每個鍵一個值。
### Map端連線
​ 上一節描述的連線演算法在Reducer中執行實際的連線邏輯，因此被稱為Reduce端連線。Mapper扮演著預處理輸入資料的角色：從每個輸入記錄中提取鍵值，將鍵值對分配給Reducer分割槽，並按鍵排序。
​ Reduce端方法的優點是不需要對輸入資料做任何假設：無論其屬性和結構如何，Mapper都可以對其預處理以備連線。然而不利的一面是，排序，複製至Reducer，以及合併Reducer輸入，所有這些操作可能開銷巨大。當資料透過MapReduce 階段時，資料可能需要落盤好幾次，取決於可用的記憶體緩衝區【37】。
​ 另一方面，如果你**能**對輸入資料作出某些假設，則透過使用所謂的Map端連線來加快連線速度是可行的。這種方法使用了一個閹掉Reduce與排序的MapReduce作業，每個Mapper只是簡單地從分散式檔案系統中讀取一個輸入檔案塊，然後將輸出檔案寫入檔案系統，僅此而已。
#### 廣播雜湊連線
​ 適用於執行Map端連線的最簡單場景是大資料集與小資料集連線的情況。要點在於小資料集需要足夠小，以便可以將其全部載入到每個Mapper的記憶體中。
​ 例如，假設在[圖10-2](../img/fig10-2.png)的情況下，使用者資料庫小到足以放進記憶體中。在這種情況下，當Mapper啟動時，它可以首先將使用者資料庫從分散式檔案系統讀取到記憶體中的雜湊中。完成此操作後，Map程式可以掃描使用者活動事件，並簡單地在散列表中查詢每個事件的使用者ID[^vi]。
[^vi]: 這個例子假定散列表中的每個鍵只有一個條目，這對使用者資料庫（使用者ID唯一標識一個使用者）可能是正確的。通常，雜湊表可能需要包含具有相同鍵的多個條目，而連線運算子將對每個鍵輸出所有的匹配。
​ 參與連線的較大輸入的每個檔案塊各有一個Mapper（在[圖10-2](../img/fig10-2.png)的例子中活動事件是較大的輸入）。每個Mapper都會將較小輸入整個載入到記憶體中。
​ 這種簡單有效的演算法被稱為**廣播雜湊連線（broadcast hash join）**：**廣播**一詞反映了這樣一個事實，每個連線較大輸入端分割槽的Mapper都會將較小輸入端資料集整個讀入記憶體中（所以較小輸入實際上“廣播”到較大資料的所有分割槽上），**雜湊**一詞反映了它使用一個散列表。 Pig（名為“**複製連結（replicated join）**”），Hive（“**MapJoin**”），Cascading和Crunch支援這種連線。它也被諸如Impala的資料倉庫查詢引擎使用【41】。
​ 除了將連線較小輸入載入到記憶體散列表中，另一種方法是將較小輸入儲存在本地磁碟上的只讀索引中【42】。索引中經常使用的部分將保留在作業系統的頁面快取中，因而這種方法可以提供與記憶體散列表幾乎一樣快的隨機查詢效能，但實際上並不需要資料集能放入記憶體中。
#### 分割槽雜湊連線
​ 如果Map端連線的輸入以相同的方式進行分割槽，則雜湊連線方法可以獨立應用於每個分割槽。在[圖10-2](../img/fig10-2.png)的情況中，你可以根據使用者ID的最後一位十進位制數字來對活動事件和使用者資料庫進行分割槽（因此連線兩側各有10個分割槽）。例如，Mapper3首先將所有具有以3結尾的ID的使用者載入到散列表中，然後掃描ID為3的每個使用者的所有活動事件。
​ 如果分割槽正確無誤，可以確定的是，所有你可能需要連線的記錄都落在同一個編號的分割槽中。因此每個Mapper只需要從輸入兩端各讀取一個分割槽就足夠了。好處是每個Mapper都可以在記憶體散列表中少放點資料。
​ 這種方法只有當連線兩端輸入有相同的分割槽數，且兩側的記錄都是使用相同的鍵與相同的雜湊函式做分割槽時才適用。如果輸入是由之前執行過這種分組的MapReduce作業生成的，那麼這可能是一個合理的假設。
​ 分割槽雜湊連線在Hive中稱為**Map端桶連線（bucketed map joins）【37】**。
#### Map端合併連線
​ 如果輸入資料集不僅以相同的方式進行分割槽，而且還基於相同的鍵進行**排序**，則可適用另一種Map端聯接的變體。在這種情況下，輸入是否小到能放入記憶體並不重要，因為這時候Mapper同樣可以執行歸併操作（通常由Reducer執行）的歸併操作：按鍵遞增的順序依次讀取兩個輸入檔案，將具有相同鍵的記錄配對。
​ 如果能進行Map端合併連線，這通常意味著前一個MapReduce作業可能一開始就已經把輸入資料做了分割槽並進行了排序。原則上這個連線就可以在前一個作業的Reduce階段進行。但使用獨立的僅Map作業有時也是合適的，例如，分好區且排好序的中間資料集可能還會用於其他目的。
#### MapReduce工作流與Map端連線
​ 當下遊作業使用MapReduce連線的輸出時，選擇Map端連線或Reduce端連線會影響輸出的結構。Reduce端連線的輸出是按照**連線鍵**進行分割槽和排序的，而Map端連線的輸出則按照與較大輸入相同的方式進行分割槽和排序（因為無論是使用分割槽連線還是廣播連線，連線較大輸入端的每個檔案塊都會啟動一個Map任務）。
​ 如前所述，Map端連線也對輸入資料集的大小，有序性和分割槽方式做出了更多假設。在最佳化連線策略時，瞭解分散式檔案系統中資料集的物理佈局變得非常重要：僅僅知道編碼格式和資料儲存目錄的名稱是不夠的；你還必須知道資料是按哪些鍵做的分割槽和排序，以及分割槽的數量。
​ 在Hadoop生態系統中，這種關於資料集分割槽的元資料通常在HCatalog和Hive Metastore中維護【37】。
### 批處理工作流的輸出
​ 我們已經說了很多用於實現MapReduce工作流的演算法，但卻忽略了一個重要的問題：這些處理完成之後的最終結果是什麼？我們最開始為什麼要跑這些作業？
​ 在資料庫查詢的場景中，我們將事務處理（OLTP）與分析兩種目的區分開來（參閱“[事務處理或分析？](ch3.md#事務處理或分析？)”）。我們看到，OLTP查詢通常根據鍵查詢少量記錄，使用索引，並將其呈現給使用者（比如在網頁上）。另一方面，分析查詢通常會掃描大量記錄，執行分組與聚合，輸出通常有著報告的形式：顯示某個指標隨時間變化的圖表，或按照某種排位取前10項，或一些數字細化為子類。這種報告的消費者通常是需要做出商業決策的分析師或經理。
​ 批處理放哪裡合適？它不屬於事務處理，也不是分析。它和分析比較接近，因為批處理通常會掃過輸入資料集的絕大部分。然而MapReduce作業工作流與用於分析目的的SQL查詢是不同的（參閱“[Hadoop與分散式資料庫的對比](#Hadoop與分散式資料庫的對比)”）。批處理過程的輸出通常不是報表，而是一些其他型別的結構。
#### 建立搜尋索引
​ Google最初使用MapReduce是為其搜尋引擎建立索引，用了由5到10個MapReduce作業組成的工作流實現【1】。雖然Google後來也不僅僅是為這個目的而使用MapReduce 【43】，但如果從構建搜尋索引的角度來看，更能幫助理解MapReduce。 （直至今日，Hadoop MapReduce仍然是為Lucene/Solr構建索引的好方法【44】）
​ 我們在“[全文搜尋和模糊索引](ch3.md#全文搜尋和模糊索引)”中簡要地瞭解了Lucene這樣的全文搜尋索引是如何工作的：它是一個檔案（關鍵詞字典），你可以在其中高效地查詢特定關鍵字，並找到包含該關鍵字的所有文件ID列表（文章列表）。這是一種非常簡化的看法 —— 實際上，搜尋索引需要各種額外資料，以便根據相關性對搜尋結果進行排名，糾正拼寫錯誤，解析同義詞等等 —— 但這個原則是成立的。
​ 如果需要對一組固定文件執行全文搜尋，則批處理是一種構建索引的高效方法：Mapper根據需要對文件集合進行分割槽，每個Reducer構建該分割槽的索引，並將索引檔案寫入分散式檔案系統。構建這樣的文件分割槽索引（參閱“[分割槽和二級索引](ch6.md#分割槽和二級索引)”）並行處理效果拔群。
​ 由於按關鍵字查詢搜尋索引是隻讀操作，因而這些索引檔案一旦建立就是不可變的。
​ 如果索引的文件集合發生更改，一種選擇是定期重跑整個索引工作流，並在完成後用新的索引檔案批次替換以前的索引檔案。如果只有少量的文件發生了變化，這種方法的計算成本可能會很高。但它的優點是索引過程很容易理解：文件進，索引出。
​ 另一個選擇是，可以增量建立索引。如[第3章](ch3.md)中討論的，如果要在索引中新增，刪除或更新文件，Lucene會寫新的段檔案，並在後臺非同步合併壓縮段檔案。我們將在[第11章](ch11.md)中看到更多這種增量處理。
#### 鍵值儲存作為批處理輸出
​ 搜尋索引只是批處理工作流可能輸出的一個例子。批處理的另一個常見用途是構建機器學習系統，例如分類器（比如垃圾郵件過濾器，異常檢測，影象識別）與推薦系統（例如，你可能認識的人，你可能感興趣的產品或相關的搜尋【29】）。
​ 這些批處理作業的輸出通常是某種資料庫：例如，可以透過給定使用者ID查詢該使用者推薦好友的資料庫，或者可以透過產品ID查詢相關產品的資料庫【45】。
​ 這些資料庫需要被處理使用者請求的Web應用所查詢，而它們通常是獨立於Hadoop基礎設施的。那麼批處理過程的輸出如何回到Web應用可以查詢的資料庫中呢？
​ 最直接的選擇可能是，直接在Mapper或Reducer中使用你最愛資料庫的客戶端庫，並從批處理作業直接寫入資料庫伺服器，一次寫入一條記錄。它能工作（假設你的防火牆規則允許從你的Hadoop環境直接訪問你的生產資料庫），但這並不是一個好主意，出於以下幾個原因：
- 正如前面在連線的上下文中討論的那樣，為每條記錄發起一個網路請求，要比批處理任務的正常吞吐量慢幾個數量級。即使客戶端庫支援批處理，效能也可能很差。
- MapReduce作業經常並行執行許多工。如果所有Mapper或Reducer都同時寫入相同的輸出資料庫，並以批處理的預期速率工作，那麼該資料庫很可能被輕易壓垮，其查詢效能可能變差。這可能會導致系統其他部分的執行問題【35】。
- 通常情況下，MapReduce為作業輸出提供了一個乾淨利落的“全有或全無”保證：如果作業成功，則結果就是每個任務恰好執行一次所產生的輸出，即使某些任務失敗且必須一路重試。如果整個作業失敗，則不會生成輸出。然而從作業內部寫入外部系統，會產生外部可見的副作用，這種副作用是不能以這種方式被隱藏的。因此，你不得不去操心部分完成的作業對其他系統可見的結果，並需要理解Hadoop任務嘗試與預測執行的複雜性。
更好的解決方案是在批處理作業**內**建立一個全新的資料庫，並將其作為檔案寫入分散式檔案系統中作業的輸出目錄，就像上節中的搜尋索引一樣。這些資料檔案一旦寫入就是不可變的，可以批次載入到處理只讀查詢的伺服器中。不少鍵值儲存都支援在MapReduce作業中構建資料庫檔案，包括Voldemort 【46】，Terrapin 【47】，ElephantDB 【48】和HBase批次載入【49】。
​ 構建這些資料庫檔案是MapReduce的一種很好用法的使用方法：使用Mapper提取出鍵並按該鍵排序，現在已經是構建索引所必需的大量工作。由於這些鍵值儲存大多都是隻讀的（檔案只能由批處理作業一次性寫入，然後就不可變），所以資料結構非常簡單。比如它們就不需要WAL（參閱“[使B樹可靠](ch3.md#使B樹可靠)”）。
​ 將資料載入到Voldemort時，伺服器將繼續用舊資料檔案服務請求，同時將新資料檔案從分散式檔案系統複製到伺服器的本地磁碟。一旦複製完成，伺服器會自動將查詢切換到新檔案。如果在這個過程中出現任何問題，它可以輕易回滾至舊檔案，因為它們仍然存在而且不可變【46】。
#### 批處理輸出的哲學
​ 本章前面討論過的Unix哲學（“[Unix哲學](#Unix哲學)”）鼓勵以顯式指明資料流的方式進行實驗：程式讀取輸入並寫入輸出。在這一過程中，輸入保持不變，任何先前的輸出都被新輸出完全替換，且沒有其他副作用。這意味著你可以隨心所欲地重新執行一個命令，略做改動或進行除錯，而不會攪亂系統的狀態。
​ MapReduce作業的輸出處理遵循同樣的原理。透過將輸入視為不可變且避免副作用（如寫入外部資料庫），批處理作業不僅實現了良好的效能，而且更容易維護：
- 如果在程式碼中引入了一個錯誤，而輸出錯誤或損壞了，則可以簡單地回滾到程式碼的先前版本，然後重新執行該作業，輸出將重新被糾正。或者，甚至更簡單，你可以將舊的輸出儲存在不同的目錄中，然後切換回原來的目錄。具有讀寫事務的資料庫沒有這個屬性：如果你部署了錯誤的程式碼，將錯誤的資料寫入資料庫，那麼回滾程式碼將無法修復資料庫中的資料。 （能夠從錯誤程式碼中恢復的概念被稱為**人類容錯（human fault tolerance）**【50】）
- 由於回滾很容易，比起在錯誤意味著不可挽回的傷害的環境，功能開發進展能快很多。這種**最小化不可逆性（minimizing irreversibility）**的原則有利於敏捷軟體開發【51】。
- 如果Map或Reduce任務失敗，MapReduce框架將自動重新排程，並在同樣的輸入上再次執行它。如果失敗是由程式碼中的錯誤造成的，那麼它會不斷崩潰，並最終導致作業在幾次嘗試之後失敗。但是如果故障是由於臨時問題導致的，那麼故障就會被容忍。因為輸入不可變，這種自動重試是安全的，而失敗任務的輸出會被MapReduce框架丟棄。
- 同一組檔案可用作各種不同作業的輸入，包括計算指標的監控作業可以評估作業的輸出是否具有預期的性質（例如，將其與前一次執行的輸出進行比較並測量差異） 。
- 與Unix工具類似，MapReduce作業將邏輯與佈線（配置輸入和輸出目錄）分離，這使得關注點分離，可以重用程式碼：一個團隊可以實現一個專注做好一件事的作業；而其他團隊可以決定何時何地執行這項作業。
在這些領域，在Unix上表現良好的設計原則似乎也適用於Hadoop，但Unix和Hadoop在某些方面也有所不同。例如，因為大多數Unix工具都假設輸入輸出是無型別文字檔案，所以它們必須做大量的輸入解析工作（本章開頭的日誌分析示例使用`{print $7}`來提取URL）。在Hadoop上可以透過使用更結構化的檔案格式消除一些低價值的語法轉換：比如Avro（參閱“[Avro](ch4.md#Avro)”）和Parquet（參閱“[列儲存](ch3.md#列儲存)”）經常使用，因為它們提供了基於模式的高效編碼，並允許模式隨時間推移而演進（見第4章）。
### Hadoop與分散式資料庫的對比
​ 正如我們所看到的，Hadoop有點像Unix的分散式版本，其中HDFS是檔案系統，而MapReduce是Unix程序的怪異實現（總是在Map階段和Reduce階段執行`sort`工具）。我們瞭解瞭如何在這些原語的基礎上實現各種連線和分組操作。
​ 當MapReduce論文發表時【1】，它從某種意義上來說 —— 並不新鮮。我們在前幾節中討論的所有處理和並行連線演算法已經在十多年前所謂的**大規模並行處理（MPP， massively parallel processing）**資料庫中實現了【3,40】。比如Gamma database machine，Teradata和Tandem NonStop SQL就是這方面的先驅【52】。
​ 最大的區別是，MPP資料庫專注於在一組機器上並行執行分析SQL查詢，而MapReduce和分散式檔案系統【19】的組合則更像是一個可以執行任意程式的通用作業系統。
#### 儲存多樣性
​ 資料庫要求你根據特定的模型（例如關係或文件）來構造資料，而分散式檔案系統中的檔案只是位元組序列，可以使用任何資料模型和編碼來編寫。它們可能是資料庫記錄的集合，但同樣可以是文字，影象，影片，感測器讀數，稀疏矩陣，特徵向量，基因組序列或任何其他型別的資料。
​ 說白了，Hadoop開放了將資料不加區分地轉儲到HDFS的可能性，允許後續再研究如何進一步處理【53】。相比之下，在將資料匯入資料庫專有儲存格式之前，MPP資料庫通常需要對資料和查詢模式進行仔細的前期建模。
​ 在純粹主義者看來，這種仔細的建模和匯入似乎是可取的，因為這意味著資料庫的使用者有更高質量的資料來處理。然而實踐經驗表明，簡單地使資料快速可用 —— 即使它很古怪，難以使用，使用原始格式 —— 也通常要比事先決定理想資料模型要更有價值【54】。
​ 這個想法與資料倉庫類似（參閱“[資料倉庫](ch3.md#資料倉庫)”）：將大型組織的各個部分的資料集中在一起是很有價值的，因為它可以跨越以前相分離的資料集進行連線。 MPP資料庫所要求的謹慎模式設計拖慢了集中式資料收集速度；以原始形式收集資料，稍後再操心模式的設計，能使資料收集速度加快（有時被稱為“**資料湖（data lake）**”或“**企業資料中心（enterprise data hub）**”【55】）。
​ 不加區分的資料轉儲轉移瞭解釋資料的負擔：資料集的生產者不再需要強制將其轉化為標準格式，資料的解釋成為消費者的問題（**讀時模式**方法【56】；參閱“[文件模型中的架構靈活性](ch2.md#文件模型中的架構靈活性)”）。如果生產者和消費者是不同優先順序的不同團隊，這可能是一種優勢。甚至可能不存在一個理想的資料模型，對於不同目的有不同的合適視角。以原始形式簡單地轉儲資料，可以允許多種這樣的轉換。這種方法被稱為**壽司原則（sushi principle）**：“原始資料更好”【57】。
​ 因此，Hadoop經常被用於實現ETL過程（參閱“[資料倉庫](ch3.md#資料倉庫)”）：事務處理系統中的資料以某種原始形式轉儲到分散式檔案系統中，然後編寫MapReduce作業來清理資料，將其轉換為關係形式，並將其匯入MPP資料倉庫以進行分析。資料建模仍然在進行，但它在一個單獨的步驟中進行，與資料收集相解耦。這種解耦是可行的，因為分散式檔案系統支援以任何格式編碼的資料。
#### 處理模型多樣性
​ MPP資料庫是單體的，緊密整合的軟體，負責磁碟上的儲存佈局，查詢計劃，排程和執行。由於這些元件都可以針對資料庫的特定需求進行調整和最佳化，因此整個系統可以在其設計針對的查詢型別上取得非常好的效能。而且，SQL查詢語言允許以優雅的語法表達查詢，而無需編寫程式碼，使業務分析師用來做商業分析的視覺化工具（例如Tableau）能夠訪問。
​ 另一方面，並非所有型別的處理都可以合理地表達為SQL查詢。例如，如果要構建機器學習和推薦系統，或者使用相關性排名模型的全文搜尋索引，或者執行影象分析，則很可能需要更一般的資料處理模型。這些型別的處理通常是特別針對特定應用的（例如機器學習的特徵工程，機器翻譯的自然語言模型，欺詐預測的風險評估函式），因此它們不可避免地需要編寫程式碼，而不僅僅是查詢。
​ MapReduce使工程師能夠輕鬆地在大型資料集上執行自己的程式碼。如果你有HDFS和MapReduce，那麼你**可以**在它之上建立一個SQL查詢執行引擎，事實上這正是Hive專案所做的【31】。但是，你也可以編寫許多其他形式的批處理，這些批處理不必非要用SQL查詢表示。
​ 隨後，人們發現MapReduce對於某些型別的處理而言侷限性很大，表現很差，因此在Hadoop之上其他各種處理模型也被開發出來（我們將在“[MapReduce之後](#後MapReduce時代)”中看到其中一些）。有兩種處理模型，SQL和MapReduce，還不夠，需要更多不同的模型！而且由於Hadoop平臺的開放性，實施一整套方法是可行的，而這在單體MPP資料庫的範疇內是不可能的【58】。
​ 至關重要的是，這些不同的處理模型都可以在共享的單個機器叢集上執行，所有這些機器都可以訪問分散式檔案系統上的相同檔案。在Hadoop方法中，不需要將資料匯入到幾個不同的專用系統中進行不同型別的處理：系統足夠靈活，可以支援同一個群集內不同的工作負載。不需要移動資料，使得從資料中挖掘價值變得容易得多，也使採用新的處理模型容易的多。
​ Hadoop生態系統包括隨機訪問的OLTP資料庫，如HBase（參閱“[SSTables和LSM樹](ch3.md#SSTables和LSM樹)”）和MPP風格的分析型資料庫，如Impala 【41】。 HBase與Impala都不使用MapReduce，但都使用HDFS進行儲存。它們是迥異的資料訪問與處理方法，但是它們可以共存，並被整合到同一個系統中。
#### 針對頻繁故障設計
​ 當比較MapReduce和MPP資料庫時，兩種不同的設計思路出現了：處理故障和使用記憶體與磁碟的方式。與線上系統相比，批處理對故障不太敏感，因為就算失敗也不會立即影響到使用者，而且它們總是能再次執行。
​ 如果一個節點在執行查詢時崩潰，大多數MPP資料庫會中止整個查詢，並讓使用者重新提交查詢或自動重新執行它【3】。由於查詢通常最多執行幾秒鐘或幾分鐘，所以這種錯誤處理的方法是可以接受的，因為重試的代價不是太大。 MPP資料庫還傾向於在記憶體中保留儘可能多的資料（例如，使用雜湊連線）以避免從磁碟讀取的開銷。
​ 另一方面，MapReduce可以容忍單個Map或Reduce任務的失敗，而不會影響作業的整體，透過以單個任務的粒度重試工作。它也會非常急切地將資料寫入磁碟，一方面是為了容錯，另一部分是因為假設資料集太大而不能適應記憶體。
​ MapReduce方式更適用於較大的作業：要處理如此之多的資料並執行很長時間的作業，以至於在此過程中很可能至少遇到一個任務故障。在這種情況下，由於單個任務失敗而重新執行整個作業將是非常浪費的。即使以單個任務的粒度進行恢復引入了使得無故障處理更慢的開銷，但如果任務失敗率足夠高，這仍然是一種合理的權衡。
​ 但是這些假設有多麼現實呢？在大多數叢集中，機器故障確實會發生，但是它們不是很頻繁 —— 可能少到絕大多數作業都不會經歷機器故障。為了容錯，真的值得帶來這麼大的額外開銷嗎？
​ 要了解MapReduce節約使用記憶體和在任務的層次進行恢復的原因，瞭解最初設計MapReduce的環境是很有幫助的。 Google有著混用的資料中心，線上生產服務和離線批處理作業在同樣機器上執行。每個任務都有一個透過容器強制執行的資源配給（CPU核心，RAM，磁碟空間等）。每個任務也具有優先順序，如果優先順序較高的任務需要更多的資源，則可以終止（搶佔）同一臺機器上較低優先順序的任務以釋放資源。優先順序還決定了計算資源的定價：團隊必須為他們使用的資源付費，而優先順序更高的程序花費更多【59】。
​ 這種架構允許非生產（低優先順序）計算資源被**過量使用（overcommitted）**，因為系統知道必要時它可以回收資源。與分離生產和非生產任務的系統相比，過量使用資源可以更好地利用機器並提高效率。但由於MapReduce作業以低優先順序執行，它們隨時都有被搶佔的風險，因為優先順序較高的程序可能需要其資源。在高優先順序程序拿走所需資源後，批次作業能有效地“撿麵包屑”，利用剩下的任何計算資源。
​ 在谷歌，執行一個小時的MapReduce任務有大約有5％的風險被終止，為了給更高優先順序的程序挪地方。這一概率比硬體問題，機器重啟或其他原因的概率高了一個數量級【59】。按照這種搶佔率，如果一個作業有100個任務，每個任務執行10分鐘，那麼至少有一個任務在完成之前被終止的風險大於50％。
​ 這就是MapReduce被設計為容忍頻繁意外任務終止的原因：不是因為硬體很不可靠，而是因為任意終止程序的自由有利於提高計算叢集中的資源利用率。
​ 在開源的叢集排程器中，搶佔的使用較少。 YARN的CapacityScheduler支援搶佔，以平衡不同佇列的資源分配【58】，但在編寫本文時，YARN，Mesos或Kubernetes不支援通用優先順序搶佔【60】。在任務不經常被終止的環境中，MapReduce的這一設計決策就沒有多少意義了。在下一節中，我們將研究一些與MapReduce設計決策相異的替代方案。
## MapReduce之後
​ 雖然MapReduce在二十世紀二十年代後期變得非常流行，並受到大量的炒作，但它只是分散式系統的許多可能的程式設計模型之一。對於不同的資料量，資料結構和處理型別，其他工具可能更適合表示計算。
​ 不管如何，我們在這一章花了大把時間來討論MapReduce，因為它是一種有用的學習工具，它是分散式檔案系統的一種相當簡單明晰的抽象。在這裡，**簡單**意味著我們能理解它在做什麼，而不是意味著使用它很簡單。恰恰相反：使用原始的MapReduce API來實現複雜的處理工作實際上是非常困難和費力的 —— 例如，任意一種連線演算法都需要你從頭開始實現【37】。
​ 針對直接使用MapReduce的困難，在MapReduce上有很多高階程式設計模型（Pig，Hive，Cascading，Crunch）被創造出來，作為建立在MapReduce之上的抽象。如果你瞭解MapReduce的原理，那麼它們學起來相當簡單。而且它們的高階結構能顯著簡化許多常見批處理任務的實現。
​ 但是，MapReduce執行模型本身也存在一些問題，這些問題並沒有透過增加另一個抽象層次而解決，而對於某些型別的處理，它表現得非常差勁。一方面，MapReduce非常穩健：你可以使用它在任務會頻繁終止的多租戶系統上處理幾乎任意大量級的資料，並且仍然可以完成工作（雖然速度很慢）。另一方面，對於某些型別的處理而言，其他工具有時會快上幾個數量級。
​ 在本章的其餘部分中，我們將介紹一些批處理方法。在[第11章](ch11.md)我們將轉向流處理，它可以看作是加速批處理的另一種方法。
### 物化中間狀態
​ 如前所述，每個MapReduce作業都獨立於其他任何作業。作業與世界其他地方的主要連線點是分散式檔案系統上的輸入和輸出目錄。如果希望一個作業的輸出成為第二個作業的輸入，則需要將第二個作業的輸入目錄配置為第一個作業輸出目錄，且外部工作流排程程式必須在第一個作業完成後再啟動第二個。
​ 如果第一個作業的輸出是要在組織內廣泛釋出的資料集，則這種配置是合理的。在這種情況下，你需要透過名稱引用它，並將其重用為多個不同作業的輸入（包括由其他團隊開發的作業）。將資料釋出到分散式檔案系統中眾所周知的位置能夠帶來**松耦合**，這樣作業就不需要知道是誰在提供輸入或誰在消費輸出（參閱“[邏輯與佈線相分離](#邏輯與佈線相分離)”）。
​ 但在很多情況下，你知道一個作業的輸出只能用作另一個作業的輸入，這些作業由同一個團隊維護。在這種情況下，分散式檔案系統上的檔案只是簡單的**中間狀態（intermediate state）**：一種將資料從一個作業傳遞到下一個作業的方式。在一個用於構建推薦系統的，由50或100個MapReduce作業組成的複雜工作流中，存在著很多這樣的中間狀態【29】。
​ 將這個中間狀態寫入檔案的過程稱為**物化（materialization）**。 （在“[聚合：資料立方體和物化檢視](ch2.md#聚合：資料立方體和物化檢視)”中已經在物化檢視的背景中遇到過這個術語。它意味著對某個操作的結果立即求值並寫出來，而不是在請求時按需計算）
​ 作為對照，本章開頭的日誌分析示例使用Unix管道將一個命令的輸出與另一個命令的輸入連線起來。管道並沒有完全物化中間狀態，而是隻使用一個小的記憶體緩衝區，將輸出增量地**流（stream）**向輸入。
​ 與Unix管道相比，MapReduce完全物化中間狀態的方法存在不足之處：
- MapReduce作業只有在前驅作業（生成其輸入）中的所有任務都完成時才能啟動，而由Unix管道連線的程序會同時啟動，輸出一旦生成就會被消費。不同機器上的資料傾斜或負載不均意味著一個作業往往會有一些掉隊的任務，比其他任務要慢得多才能完成。必須等待至前驅作業的所有任務完成，拖慢了整個工作流程的執行。
- Mapper通常是多餘的：它們僅僅是讀取剛剛由Reducer寫入的同樣檔案，為下一個階段的分割槽和排序做準備。在許多情況下，Mapper程式碼可能是前驅Reducer的一部分：如果Reducer和Mapper的輸出有著相同的分割槽與排序方式，那麼Reducer就可以直接串在一起，而不用與Mapper相互交織。
- 將中間狀態儲存在分散式檔案系統中意味著這些檔案被複制到多個節點，這些臨時資料這麼搞就比較過分了。
#### 資料流引擎
​ 瞭解決MapReduce的這些問題，幾種用於分散式批處理的新執行引擎被開發出來，其中最著名的是Spark 【61,62】，Tez 【63,64】和Flink 【65,66】。它們的設計方式有很多區別，但有一個共同點：把整個工作流作為單個作業來處理，而不是把它分解為獨立的子作業。
​ 由於它們將工作流顯式建模為 資料從幾個處理階段穿過，所以這些系統被稱為**資料流引擎（dataflow engines）**。像MapReduce一樣，它們在一條線上透過反覆呼叫使用者定義的函式來一次處理一條記錄，它們透過輸入分割槽來並行化載荷，它們透過網路將一個函式的輸出複製到另一個函式的輸入。
​ 與MapReduce不同，這些功能不需要嚴格扮演交織的Map與Reduce的角色，而是可以以更靈活的方式進行組合。我們稱這些函式為**運算元（operators）**，資料流引擎提供了幾種不同的選項來將一個運算元的輸出連線到另一個運算元的輸入：
- 一種選項是對記錄按鍵重新分割槽並排序，就像在MapReduce的混洗階段一樣（參閱“[分散式執行MapReduce](#分散式執行MapReduce)”）。這種功能可以用於實現排序合併連線和分組，就像在MapReduce中一樣。
- 另一種可能是接受多個輸入，並以相同的方式進行分割槽，但跳過排序。當記錄的分割槽重要但順序無關緊要時，這省去了分割槽雜湊連線的工作，因為構建散列表還是會把順序隨機打亂。
- 對於廣播雜湊連線，可以將一個運算元的輸出，傳送到連線運算元的所有分割槽。
這種型別的處理引擎是基於像Dryad 【67】和Nephele 【68】這樣的研究系統，與MapReduce模型相比，它有幾個優點：
- 排序等昂貴的工作只需要在實際需要的地方執行，而不是預設地在每個Map和Reduce階段之間出現。
- 沒有不必要的Map任務，因為Mapper所做的工作通常可以合併到前面的Reduce運算元中（因為Mapper不會更改資料集的分割槽）。
- 由於工作流中的所有連線和資料依賴都是顯式宣告的，因此排程程式能夠總覽全域性，知道哪裡需要哪些資料，因而能夠利用區域性性進行最佳化。例如，它可以嘗試將消費某些資料的任務放在與生成這些資料的任務相同的機器上，從而資料可以透過共享記憶體緩衝區傳輸，而不必透過網路複製。
- 通常，運算元間的中間狀態足以儲存在記憶體中或寫入本地磁碟，這比寫入HDFS需要更少的I/O（必須將其複製到多臺機器，並將每個副本寫入磁碟）。 MapReduce已經對Mapper的輸出做了這種最佳化，但資料流引擎將這種思想推廣至所有的中間狀態。
- 運算元可以在輸入就緒後立即開始執行；後續階段無需等待前驅階段整個完成後再開始。
- 與MapReduce（為每個任務啟動一個新的JVM）相比，現有Java虛擬機器（JVM）程序可以重用來執行新運算元，從而減少啟動開銷。
你可以使用資料流引擎執行與MapReduce工作流同樣的計算，而且由於此處所述的最佳化，通常執行速度要明顯快得多。既然運算元是Map和Reduce的泛化，那麼相同的處理程式碼就可以在任一執行引擎上執行：Pig，Hive或Cascading中實現的工作流可以無需修改程式碼，可以透過修改配置，簡單地從MapReduce切換到Tez或Spark【64】。
​ Tez是一個相當薄的庫，它依賴於YARN shuffle服務來實現節點間資料的實際複製【58】，而Spark和Flink則是包含了獨立網路通訊層，排程器，及使用者向API的大型框架。我們將簡要討論這些高階API。
#### 容錯
​ 完全物化中間狀態至分散式檔案系統的一個優點是，它具有永續性，這使得MapReduce中的容錯相當容易：如果一個任務失敗，它可以在另一臺機器上重新啟動，並從檔案系統重新讀取相同的輸入。
​ Spark，Flink和Tez避免將中間狀態寫入HDFS，因此它們採取了不同的方法來容錯：如果一臺機器發生故障，並且該機器上的中間狀態丟失，則它會從其他仍然可用的資料重新計算（在可行的情況下是先前的中間狀態，要麼就只能是原始輸入資料，通常在HDFS上）。
​ 為了實現這種重新計算，框架必須跟蹤一個給定的資料是如何計算的 —— 使用了哪些輸入分割槽？應用了哪些運算元？ Spark使用**彈性分散式資料集（RDD）**的抽象來跟蹤資料的譜系【61】，而Flink對運算元狀態存檔，允許恢復執行在執行過程中遇到錯誤的運算元【66】。
​ 在重新計算資料時，重要的是要知道計算是否是**確定性的**：也就是說，給定相同的輸入資料，運算元是否始終產生相同的輸出？如果一些丟失的資料已經發送給下游運算元，這個問題就很重要。如果運算元重新啟動，重新計算的資料與原有的丟失資料不一致，下游運算元很難解決新舊資料之間的矛盾。對於不確定性運算元來說，解決方案通常是殺死下游運算元，然後再重跑新資料。
​ 為了避免這種級聯故障，最好讓運算元具有確定性。但需要注意的是，非確定性行為很容易悄悄溜進來：例如，許多程式語言在迭代雜湊表的元素時不能對順序作出保證，許多概率和統計演算法顯式依賴於使用隨機數，以及用到系統時鐘或外部資料來源，這些都是都不確定性的行為。為了能可靠地從故障中恢復，需要消除這種不確定性因素，例如使用固定的種子生成偽隨機數。
​ 透過重算資料來從故障中恢復並不總是正確的答案：如果中間狀態資料要比源資料小得多，或者如果計算量非常大，那麼將中間資料物化為檔案可能要比重新計算廉價的多。
#### 關於物化的討論
​ 回到Unix的類比，我們看到，MapReduce就像是將每個命令的輸出寫入臨時檔案，而資料流引擎看起來更像是Unix管道。尤其是Flink是基於管道執行的思想而建立的：也就是說，將運算元的輸出增量地傳遞給其他運算元，不待輸入完成便開始處理。
​ 排序運算元不可避免地需要消費全部的輸入後才能生成任何輸出，因為輸入中最後一條輸入記錄可能具有最小的鍵，因此需要作為第一條記錄輸出。因此，任何需要排序的運算元都需要至少暫時地累積狀態。但是工作流的許多其他部分可以以流水線方式執行。
​ 當作業完成時，它的輸出需要持續到某個地方，以便使用者可以找到並使用它—— 很可能它會再次寫入分散式檔案系統。因此，在使用資料流引擎時，HDFS上的物化資料集通常仍是作業的輸入和最終輸出。和MapReduce一樣，輸入是不可變的，輸出被完全替換。比起MapReduce的改進是，你不用再自己去將中間狀態寫入檔案系統了。
### 圖與迭代處理
​ 在“[圖資料模型](ch2.md#圖資料模型)”中，我們討論了使用圖來建模資料，並使用圖查詢語言來遍歷圖中的邊與點。[第2章](ch2.md)的討論集中在OLTP風格的應用場景：快速執行查詢來查詢少量符合特定條件的頂點。
​ 批處理上下文中的圖也很有趣，其目標是在整個圖上執行某種離線處理或分析。這種需求經常出現在機器學習應用（如推薦引擎）或排序系統中。例如，最著名的圖形分析演算法之一是PageRank 【69】，它試圖根據連結到某個網頁的其他網頁來估計該網頁的流行度。它作為配方的一部分，用於確定網路搜尋引擎呈現結果的順序
> 像Spark，Flink和Tez這樣的資料流引擎（參見“[中間狀態的物化](#中間狀態的物化)”）通常將運算元作為**有向無環圖（DAG）**的一部分安排在作業中。這與圖處理不一樣：在資料流引擎中，**從一個運算元到另一個運算元的資料流**被構造成一個圖，而資料本身通常由關係型元組構成。在圖處理中，資料本身具有圖的形式。又一個不幸的命名混亂！
​ 許多圖演算法是透過一次遍歷一條邊來表示的，將一個頂點與近鄰的頂點連線起來，以傳播一些資訊，並不斷重複，直到滿足一些條件為止 —— 例如，直到沒有更多的邊要跟進，或直到一些指標收斂。我們在[圖2-6](../img/fig2-6.png)中看到一個例子，它透過重複跟進標明地點歸屬關係的邊，生成了資料庫中北美包含的所有地點列表（這種演算法被稱為**閉包傳遞（transitive closure）**）。
​ 可以在分散式檔案系統中儲存圖（包含頂點和邊的列表的檔案），但是這種“重複至完成”的想法不能用普通的MapReduce來表示，因為它只掃過一趟資料。這種演算法因此經常以**迭代**的風格實現：
1. 外部排程程式執行批處理來計算演算法的一個步驟。
2. 當批處理過程完成時，排程器檢查它是否完成（基於完成條件 —— 例如，沒有更多的邊要跟進，或者與上次迭代相比的變化低於某個閾值）。
3. 如果尚未完成，則排程程式返回到步驟1並執行另一輪批處理。
這種方法是有效的，但是用MapReduce實現它往往非常低效，因為MapReduce沒有考慮演算法的迭代性質：它總是讀取整個輸入資料集併產生一個全新的輸出資料集，即使與上次迭代相比，改變的僅僅是圖中的一小部分。
#### Pregel處理模型
​ 針對圖批處理的最佳化 —— **批次同步並行（BSP）**計算模型【70】已經開始流行起來。其中，Apache Giraph 【37】，Spark的GraphX API和Flink的Gelly API 【71】實現了它。它也被稱為**Pregel**模型，因為Google的Pregel論文推廣了這種處理圖的方法【72】。
​ 回想一下在MapReduce中，Mapper在概念上向Reducer的特定呼叫“傳送訊息”，因為框架將所有具有相同鍵的Mapper輸出集中在一起。 Pregel背後有一個類似的想法：一個頂點可以向另一個頂點“傳送訊息”，通常這些訊息是沿著圖的邊傳送的。
​ 在每次迭代中，為每個頂點呼叫一個函式，將所有傳送給它的訊息傳遞給它 —— 就像呼叫Reducer一樣。與MapReduce的不同之處在於，在Pregel模型中，頂點在一次迭代到下一次迭代的過程中會記住它的狀態，所以這個函式只需要處理新的傳入訊息。如果圖的某個部分沒有被髮送訊息，那裡就不需要做任何工作。
​ 這與Actor模型有些相似（參閱“[分散式的Actor框架](ch4.md#分散式的Actor框架)”），除了頂點狀態和頂點之間的訊息具有容錯性和耐久性，且通訊以固定的方式進行：在每次迭代中，框架遞送上次迭代中傳送的所有訊息。Actor通常沒有這樣的時間保證。
#### 容錯
​ 頂點只能透過訊息傳遞進行通訊（而不是直接相互查詢）的事實有助於提高Pregel作業的效能，因為訊息可以成批處理，且等待通訊的次數也減少了。唯一的等待是在迭代之間：由於Pregel模型保證所有在一輪迭代中傳送的訊息都在下輪迭代中送達，所以在下一輪迭代開始前，先前的迭代必須完全完成，而所有的訊息必須在網路上完成複製。
​ 即使底層網路可能丟失，重複或任意延遲訊息（參閱“[不可靠的網路](ch8.md#不可靠的網路)”），Pregel的實現能保證在後續迭代中訊息在其目標頂點恰好處理一次。像MapReduce一樣，框架能從故障中透明地恢復，以簡化在Pregel上實現演算法的程式設計模型。
​ 這種容錯是透過在迭代結束時，定期存檔所有頂點的狀態來實現的，即將其全部狀態寫入持久化儲存。如果某個節點發生故障並且其記憶體中的狀態丟失，則最簡單的解決方法是將整個圖計算回滾到上一個存檔點，然後重啟計算。如果演算法是確定性的，且訊息記錄在日誌中，那麼也可以選擇性地只恢復丟失的分割槽（就像之前討論過的資料流引擎）【72】。
#### 並行執行
​ 頂點不需要知道它在哪臺物理機器上執行；當它向其他頂點發送訊息時，它只是簡單地將訊息發往某個頂點ID。圖的分割槽取決於框架 —— 即，確定哪個頂點執行在哪臺機器上，以及如何透過網路路由訊息，以便它們到達正確的地方。
​ 由於程式設計模型一次僅處理一個頂點（有時稱為“像頂點一樣思考”），所以框架可以以任意方式對圖分割槽。理想情況下如果頂點需要進行大量的通訊，那麼它們最好能被分割槽到同一臺機器上。然而找到這樣一種最佳化的分割槽方法是很困難的 —— 在實踐中，圖經常按照任意分配的頂點ID分割槽，而不會嘗試將相關的頂點分組在一起。
​ 因此，圖演算法通常會有很多跨機器通訊的額外開銷，而中間狀態（節點之間傳送的訊息）往往比原始圖大。透過網路傳送訊息的開銷會顯著拖慢分散式圖演算法的速度。
​ 出於這個原因，如果你的圖可以放入一臺計算機的記憶體中，那麼單機（甚至可能是單執行緒）演算法很可能會超越分散式批處理【73,74】。圖比記憶體大也沒關係，只要能放入單臺計算機的磁碟，使用GraphChi等框架進行單機處理是就一個可行的選擇【75】。如果圖太大，不適合單機處理，那麼像Pregel這樣的分散式方法是不可避免的。高效的並行圖演算法是一個進行中的研究領域【76】。
### 高階API和語言
​ 自MapReduce開始流行的這幾年以來，分散式批處理的執行引擎已經很成熟了。到目前為止，基礎設施已經足夠強大，能夠儲存和處理超過10,000臺機器群集上的數PB的資料。由於在這種規模下物理執行批處理的問題已經被認為或多或少解決了，所以關注點已經轉向其他領域：改進程式設計模型，提高處理效率，擴大這些技術可以解決的問題集。
​ 如前所述，Hive，Pig，Cascading和Crunch等高階語言和API變得越來越流行，因為手寫MapReduce作業實在是個苦力活。隨著Tez的出現，這些高階語言還有一個額外好處，可以遷移到新的資料流執行引擎，而無需重寫作業程式碼。 Spark和Flink也有它們自己的高階資料流API，通常是從FlumeJava中獲取的靈感【34】。
​ 這些資料流API通常使用關係型構建塊來表達一個計算：按某個欄位連線資料集；按鍵對元組做分組；按某些條件過濾；並透過計數求和或其他函式來聚合元組。在內部，這些操作是使用本章前面討論過的各種連線和分組演算法來實現的。
​ 除了少寫程式碼的明顯優勢之外，這些高階介面還支援互動式用法，在這種互動式使用中，你可以在Shell中增量式編寫分析程式碼，頻繁執行來觀察它做了什麼。這種開發風格在探索資料集和試驗處理方法時非常有用。這也讓人聯想到Unix哲學，我們在“[Unix哲學](#Unix哲學)”中討論過這個問題。
​ 此外，這些高階介面不僅提高了人類的工作效率，也提高了機器層面的作業執行效率。
#### 向宣告式查詢語言的轉變
​ 與硬寫執行連線的程式碼相比，指定連線關係運算元的優點是，框架可以分析連線輸入的屬性，並自動決定哪種上述連線演算法最適合當前任務。 Hive，Spark和Flink都有基於代價的查詢最佳化器可以做到這一點，甚至可以改變連線順序，最小化中間狀態的數量【66,77,78,79】。
​ 連線演算法的選擇可以對批處理作業的效能產生巨大影響，而無需理解和記住本章中討論的各種連線演算法。如果連線是以**宣告式（declarative）**的方式指定的，那這就這是可行的：應用只是簡單地說明哪些連線是必需的，查詢最佳化器決定如何最好地執行連線。我們以前在“[資料查詢語言](ch2.md#資料查詢語言)”中見過這個想法。
​ 但MapReduce及其後繼者資料流在其他方面，與SQL的完全宣告式查詢模型有很大區別。 MapReduce是圍繞著回撥函式的概念建立的：對於每條記錄或者一組記錄，呼叫一個使用者定義的函式（Mapper或Reducer），並且該函式可以自由地呼叫任意程式碼來決定輸出什麼。這種方法的優點是可以基於大量已有庫的生態系統創作：解析，自然語言分析，影象分析以及執行數值演算法或統計演算法等。
​ 自由執行任意程式碼，長期以來都是傳統MapReduce批處理系統與MPP資料庫的區別所在（參見“[比較Hadoop和分散式資料庫](#比較Hadoop和分散式資料庫)”一節）。雖然資料庫具有編寫使用者定義函式的功能，但是它們通常使用起來很麻煩，而且與大多數程式語言中廣泛使用的程式包管理器和依賴管理系統相容不佳（例如Java的Maven， Javascript的npm，以及Ruby的gems）。
​ 然而資料流引擎已經發現，支援除連線之外的更多**宣告式特性**還有其他的優勢。例如，如果一個回撥函式只包含一個簡單的過濾條件，或者只是從一條記錄中選擇了一些欄位，那麼在為每條記錄呼叫函式時會有相當大的額外CPU開銷。如果以宣告方式表示這些簡單的過濾和對映操作，那麼查詢最佳化器可以利用面向列的儲存佈局（參閱“[列儲存](ch3.md#列儲存)”），只從磁碟讀取所需的列。 Hive，Spark DataFrames和Impala還使用了向量化執行（參閱“[記憶體頻寬和向量處理](ch3.md#記憶體頻寬和向量處理)”）：在對CPU快取友好的內部迴圈中迭代資料，避免函式呼叫。Spark生成JVM位元組碼【79】，Impala使用LLVM為這些內部迴圈生成本機程式碼【41】。
​ 透過在高階API中引入宣告式的部分，並使查詢最佳化器可以在執行期間利用這些來做最佳化，批處理框架看起來越來越像MPP資料庫了（並且能實現可與之媲美的效能）。同時，透過擁有執行任意程式碼和以任意格式讀取資料的可擴充套件性，它們保持了靈活性的優勢。
#### 專業化的不同領域
​ 儘管能夠執行任意程式碼的可擴充套件性是很有用的，但是也有很多常見的例子，不斷重複著標準的處理模式。因而這些模式值得擁有自己的可重用通用構建模組實現，傳統上，MPP資料庫滿足了商業智慧分析和業務報表的需求，但這只是許多使用批處理的領域之一。
​ 另一個越來越重要的領域是統計和數值演算法，它們是機器學習應用所需要的（例如分類器和推薦系統）。可重用的實現正在出現：例如，Mahout在MapReduce，Spark和Flink之上實現了用於機器學習的各種演算法，而MADlib在關係型MPP資料庫（Apache HAWQ）中實現了類似的功能【54】。
​ 空間演算法也是有用的，例如**最近鄰搜尋（k-nearest neghbors, kNN）**【80】，它在一些多維空間中搜索與給定項最近的專案 —— 這是一種相似性搜尋。近似搜尋對於基因組分析演算法也很重要，它們需要找到相似但不相同的字串【81】。
​ 批處理引擎正被用於分散式執行日益廣泛的各領域演算法。隨著批處理系統獲得各種內建功能以及高階宣告式運算元，且隨著MPP資料庫變得更加靈活和易於程式設計，兩者開始看起來相似了：最終，它們都只是儲存和處理資料的系統。
## 本章小結
​ 在本章中，我們探索了批處理的主題。我們首先看到了諸如awk，grep和sort之類的Unix工具，然後我們看到了這些工具的設計理念是如何應用到MapReduce和更近的資料流引擎中的。一些設計原則包括：輸入是不可變的，輸出是為了作為另一個（仍未知的）程式的輸入，而複雜的問題是透過編寫“做好一件事”的小工具來解決的。
​ 在Unix世界中，允許程式與程式組合的統一介面是檔案與管道；在MapReduce中，該介面是一個分散式檔案系統。我們看到資料流引擎添加了自己的管道式資料傳輸機制，以避免將中間狀態物化至分散式檔案系統，但作業的初始輸入和最終輸出通常仍是HDFS。
​ 分散式批處理框架需要解決的兩個主要問題是：
***分割槽***
​ 在MapReduce中，Mapper根據輸入檔案塊進行分割槽。Mapper的輸出被重新分割槽，排序，併合併到可配置數量的Reducer分割槽中。這一過程的目的是把所有的**相關**資料（例如帶有相同鍵的所有記錄）都放在同一個地方。
​ 後MapReduce時代的資料流引擎若非必要會盡量避免排序，但它們也採取了大致類似的分割槽方法。
***容錯***
​ MapReduce經常寫入磁碟，這使得從單個失敗的任務恢復很輕鬆，無需重新啟動整個作業，但在無故障的情況下減慢了執行速度。資料流引擎更多地將中間狀態儲存在記憶體中，更少地物化中間狀態，這意味著如果節點發生故障，則需要重算更多的資料。確定性運算元減少了需要重算的資料量。
​ 我們討論了幾種MapReduce的連線演算法，其中大多數也在MPP資料庫和資料流引擎內部使用。它們也很好地演示了分割槽演算法是如何工作的：
***排序合併連線***
​ 每個參與連線的輸入都透過一個提取連線鍵的Mapper。透過分割槽，排序和合並，具有相同鍵的所有記錄最終都會進入相同的Reducer呼叫。這個函式能輸出連線好的記錄。
***廣播雜湊連線***
​ 兩個連線輸入之一很小，所以它並沒有分割槽，而且能被完全載入進一個雜湊表中。因此，你可以為連線輸入大端的每個分割槽啟動一個Mapper，將輸入小端的散列表載入到每個Mapper中，然後掃描大端，一次一條記錄，併為每條記錄查詢散列表。
***分割槽雜湊連線***
​ 如果兩個連線輸入以相同的方式分割槽（使用相同的鍵，相同的雜湊函式和相同數量的分割槽），則可以獨立地對每個分割槽應用散列表方法。
​ 分散式批處理引擎有一個刻意限制的程式設計模型：回撥函式（比如Mapper和Reducer）被假定是無狀態的，而且除了指定的輸出外，必須沒有任何外部可見的副作用。這一限制允許框架在其抽象下隱藏一些困難的分散式系統問題：當遇到崩潰和網路問題時，任務可以安全地重試，任何失敗任務的輸出都被丟棄。如果某個分割槽的多個任務成功，則其中只有一個能使其輸出實際可見。
​ 得益於這個框架，你在批處理作業中的程式碼無需操心實現容錯機制：框架可以保證作業的最終輸出與沒有發生錯誤的情況相同，也許不得不重試各種任務。線上服務處理使用者請求，並將寫入資料庫作為處理請求的副作用，比起線上服務，批處理提供的這種可靠性語義要強得多。
​ 批處理作業的顯著特點是，它讀取一些輸入資料併產生一些輸出資料，但不修改輸入—— 換句話說，輸出是從輸入衍生出的。最關鍵的是，輸入資料是**有界的（bounded）**：它有一個已知的，固定的大小（例如，它包含一些時間點的日誌檔案或資料庫內容的快照）。因為它是有界的，一個作業知道自己什麼時候完成了整個輸入的讀取，所以一個工作在做完後，最終總是會完成的。
​ 在下一章中，我們將轉向流處理，其中的輸入是**無界的（unbounded）** —— 也就是說，你還有活兒要幹，然而它的輸入是永無止境的資料流。在這種情況下，作業永無完成之日。因為在任何時候都可能有更多的工作湧入。我們將看到，在某些方面上，流處理和批處理是相似的。但是關於無盡資料流的假設也對我們構建系統的方式產生了很多改變。
## 參考文獻
1. Jeffrey Dean and Sanjay Ghemawat: “[MapReduce: Simplified Data Processing on Large Clusters](http://research.google.com/archive/mapreduce.html),” at *6th USENIX Symposium on Operating System Design and Implementation* (OSDI), December 2004.
1. Joel Spolsky: “[The Perils of JavaSchools](http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html),” *joelonsoftware.com*, December 25, 2005.
1. Shivnath Babu and Herodotos Herodotou: “[Massively Parallel Databases and MapReduce Systems](http://research.microsoft.com/pubs/206464/db-mr-survey-final.pdf),” *Foundations and Trends in Databases*, volume 5, number 1, pages 1–104, November 2013. [doi:10.1561/1900000036](http://dx.doi.org/10.1561/1900000036)
1. David J. DeWitt and Michael Stonebraker: “[MapReduce: A Major Step Backwards](https://homes.cs.washington.edu/~billhowe/mapreduce_a_major_step_backwards.html),” originally published at *databasecolumn.vertica.com*, January 17, 2008.
1. Henry Robinson: “[The Elephant Was a Trojan Horse: On the Death of Map-Reduce at Google](http://the-paper-trail.org/blog/the-elephant-was-a-trojan-horse-on-the-death-of-map-reduce-at-google/),”
*the-paper-trail.org*, June 25, 2014.
1. “[The Hollerith Machine](https://www.census.gov/history/www/innovations/technology/the_hollerith_tabulator.html),” United States Census Bureau, *census.gov*.
1. “[IBM 82, 83, and 84 Sorters Reference Manual](http://www.textfiles.com/bitsavers/pdf/ibm/punchedCard/Sorter/A24-1034-1_82-83-84_sorters.pdf),” Edition A24-1034-1, International Business
Machines Corporation, July 1962.
1. Adam Drake: “[Command-Line Tools Can Be 235x Faster than Your Hadoop Cluster](http://aadrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html),” *aadrake.com*, January 25, 2014.
1. “[GNU Coreutils 8.23 Documentation](http://www.gnu.org/software/coreutils/manual/html_node/index.html),” Free Software Foundation, Inc., 2014.
1. Martin Kleppmann: “[Kafka, Samza, and the Unix Philosophy of Distributed Data](http://martin.kleppmann.com/2015/08/05/kafka-samza-unix-philosophy-distributed-data.html),” *martin.kleppmann.com*, August 5, 2015.
1. Doug McIlroy:[Internal Bell Labs memo](http://cm.bell-labs.com/cm/cs/who/dmr/mdmpipe.pdf), October 1964. Cited in: Dennis M. Richie: “[Advice from Doug McIlroy](https://www.bell-labs.com/usr/dmr/www/mdmpipe.html),” *cm.bell-labs.com*.
1. M. D. McIlroy, E. N. Pinson, and B. A. Tague: “[UNIX Time-Sharing System: Foreword](https://archive.org/details/bstj57-6-1899),” *The Bell System Technical Journal*, volume 57, number 6, pages 1899–1904, July 1978.
1. Eric S. Raymond: <a href="http://www.catb.org/~esr/writings/taoup/html/">*The Art of UNIX Programming*</a>. Addison-Wesley, 2003. ISBN: 978-0-13-142901-7
1. Ronald Duncan: “[Text File Formats – ASCII Delimited Text – Not CSV or TAB Delimited Text](https://ronaldduncan.wordpress.com/2009/10/31/text-file-formats-ascii-delimited-text-not-csv-or-tab-delimited-text/),”
*ronaldduncan.wordpress.com*, October 31, 2009.
1. Alan Kay: “[Is 'Software Engineering' an Oxymoron?](http://tinlizzie.org/~takashi/IsSoftwareEngineeringAnOxymoron.pdf),” *tinlizzie.org*.
1. Martin Fowler: “[InversionOfControl](http://martinfowler.com/bliki/InversionOfControl.html),” *martinfowler.com*, June 26, 2005.
1. Daniel J. Bernstein: “[Two File Descriptors for Sockets](http://cr.yp.to/tcpip/twofd.html),” *cr.yp.to*.
1. Rob Pike and Dennis M. Ritchie: “[The Styx Architecture for Distributed Systems](http://doc.cat-v.org/inferno/4th_edition/styx),” *Bell Labs Technical Journal*, volume 4, number 2, pages 146–152, April 1999.
1. Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung: “[The Google File System](http://research.google.com/archive/gfs-sosp2003.pdf),” at *19th ACM Symposium on Operating Systems Principles* (SOSP), October 2003. [doi:10.1145/945445.945450](http://dx.doi.org/10.1145/945445.945450)
1. Michael Ovsiannikov, Silvius Rus, Damian Reeves, et al.: “[The Quantcast File System](http://db.disi.unitn.eu/pages/VLDBProgram/pdf/industry/p808-ovsiannikov.pdf),” *Proceedings of the VLDB Endowment*, volume 6, number 11, pages 1092–1101, August 2013. [doi:10.14778/2536222.2536234](http://dx.doi.org/10.14778/2536222.2536234)
1. “[OpenStack Swift 2.6.1 Developer Documentation](http://docs.openstack.org/developer/swift/),” OpenStack Foundation, *docs.openstack.org*, March 2016.
1. Zhe Zhang, Andrew Wang, Kai Zheng, et al.: “[Introduction to HDFS Erasure Coding in Apache Hadoop](http://blog.cloudera.com/blog/2015/09/introduction-to-hdfs-erasure-coding-in-apache-hadoop/),” *blog.cloudera.com*, September 23, 2015.
1. Peter Cnudde: “[Hadoop Turns 10](http://yahoohadoop.tumblr.com/post/138739227316/hadoop-turns-10),” *yahoohadoop.tumblr.com*, February 5, 2016.
1. Eric Baldeschwieler: “[Thinking About the HDFS vs. Other Storage Technologies](http://hortonworks.com/blog/thinking-about-the-hdfs-vs-other-storage-technologies/),” *hortonworks.com*, July 25, 2012.
1. Brendan Gregg: “[Manta: Unix Meets Map Reduce](http://dtrace.org/blogs/brendan/2013/06/25/manta-unix-meets-map-reduce/),” *dtrace.org*, June 25, 2013.
1. Tom White: *Hadoop: The Definitive Guide*, 4th edition. O'Reilly Media, 2015. ISBN: 978-1-491-90163-2
1. Jim N. Gray: “[Distributed Computing Economics](http://arxiv.org/pdf/cs/0403019.pdf),” Microsoft Research Tech Report MSR-TR-2003-24, March 2003.
1. Márton Trencséni: “[Luigi vs Airflow vs Pinball](http://bytepawn.com/luigi-airflow-pinball.html),” *bytepawn.com*, February 6, 2016.
1. Roshan Sumbaly, Jay Kreps, and Sam Shah: “[The 'Big Data' Ecosystem at LinkedIn](http://www.slideshare.net/s_shah/the-big-data-ecosystem-at-linkedin-23512853),” at *ACM International Conference on Management of Data (SIGMOD)*, July 2013. [doi:10.1145/2463676.2463707](http://dx.doi.org/10.1145/2463676.2463707)
1. Alan F. Gates, Olga Natkovich, Shubham Chopra, et al.: “[Building a High-Level Dataflow System on Top of Map-Reduce: The Pig Experience](http://www.vldb.org/pvldb/2/vldb09-1074.pdf),” at *35th International Conference on Very Large Data Bases* (VLDB), August 2009.
1. Ashish Thusoo, Joydeep Sen Sarma, Namit Jain, et al.: “[Hive – A Petabyte Scale Data Warehouse Using Hadoop](http://i.stanford.edu/~ragho/hive-icde2010.pdf),” at *26th IEEE International Conference on Data Engineering* (ICDE), March 2010. [doi:10.1109/ICDE.2010.5447738](http://dx.doi.org/10.1109/ICDE.2010.5447738)
1. “[Cascading 3.0 User Guide](http://docs.cascading.org/cascading/3.0/userguide/),” Concurrent, Inc., *docs.cascading.org*, January 2016.
1. “[Apache Crunch User Guide](https://crunch.apache.org/user-guide.html),” Apache Software Foundation, *crunch.apache.org*.
1. Craig Chambers, Ashish Raniwala, Frances Perry, et al.: “[FlumeJava: Easy, Efficient Data-Parallel Pipelines](https://research.google.com/pubs/archive/35650.pdf),” at *31st ACM SIGPLAN Conference on Programming Language Design and Implementation* (PLDI), June 2010. [doi:10.1145/1806596.1806638](http://dx.doi.org/10.1145/1806596.1806638)
1. Jay Kreps: “[Why Local State is a Fundamental Primitive in Stream Processing](https://www.oreilly.com/ideas/why-local-state-is-a-fundamental-primitive-in-stream-processing),” *oreilly.com*, July 31, 2014.
1. Martin Kleppmann: “[Rethinking Caching in Web Apps](http://martin.kleppmann.com/2012/10/01/rethinking-caching-in-web-apps.html),” *martin.kleppmann.com*, October 1, 2012.
1. Mark Grover, Ted Malaska, Jonathan Seidman, and Gwen Shapira: *[Hadoop Application Architectures](http://shop.oreilly.com/product/0636920033196.do)*. O'Reilly Media, 2015. ISBN: 978-1-491-90004-8
1. Philippe Ajoux, Nathan Bronson, Sanjeev Kumar, et al.: “[Challenges to Adopting Stronger Consistency at Scale](https://www.usenix.org/system/files/conference/hotos15/hotos15-paper-ajoux.pdf),” at *15th USENIX Workshop on Hot Topics in Operating Systems* (HotOS), May 2015.
1. Sriranjan Manjunath: “[Skewed Join](https://wiki.apache.org/pig/PigSkewedJoinSpec),” *wiki.apache.org*, 2009.
1. David J. DeWitt, Jeffrey F. Naughton, Donovan A.Schneider, and S. Seshadri: “[Practical Skew Handling in Parallel Joins](http://www.vldb.org/conf/1992/P027.PDF),” at *18th International Conference on Very Large Data Bases* (VLDB), August 1992.
1. Marcel Kornacker, Alexander Behm, Victor Bittorf, et al.: “[Impala: A Modern, Open-Source SQL Engine for Hadoop](http://pandis.net/resources/cidr15impala.pdf),” at *7th Biennial Conference on Innovative Data Systems Research* (CIDR), January 2015.
1. Matthieu Monsch: “[Open-Sourcing PalDB, a Lightweight Companion for Storing Side Data](https://engineering.linkedin.com/blog/2015/10/open-sourcing-paldb--a-lightweight-companion-for-storing-side-da),” *engineering.linkedin.com*, October 26, 2015.
1. Daniel Peng and Frank Dabek: “[Large-Scale Incremental Processing Using Distributed Transactions and Notifications](https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Peng.pdf),” at *9th USENIX conference on Operating Systems Design and Implementation* (OSDI), October 2010.
1. “["Cloudera Search User Guide,"](http://www.cloudera.com/documentation/cdh/5-1-x/Search/Cloudera-Search-User-Guide/Cloudera-Search-User-Guide.html) Cloudera, Inc., September 2015.
1. Lili Wu, Sam Shah, Sean Choi, et al.:
“[The Browsemaps: Collaborative Filtering at LinkedIn](http://ls13-www.cs.uni-dortmund.de/homepage/rsweb2014/papers/rsweb2014_submission_3.pdf),” at *6th Workshop on Recommender Systems and the Social Web* (RSWeb), October 2014.
1. Roshan Sumbaly, Jay Kreps, Lei Gao, et al.: “[Serving Large-Scale Batch Computed Data with Project Voldemort](http://static.usenix.org/events/fast12/tech/full_papers/Sumbaly.pdf),” at *10th USENIX Conference on File and Storage Technologies* (FAST), February 2012.
1. Varun Sharma: “[Open-Sourcing Terrapin: A Serving System for Batch Generated Data](https://engineering.pinterest.com/blog/open-sourcing-terrapin-serving-system-batch-generated-data-0),” *engineering.pinterest.com*, September 14, 2015.
1. Nathan Marz: “[ElephantDB](http://www.slideshare.net/nathanmarz/elephantdb),” *slideshare.net*, May 30, 2011.
1. Jean-Daniel (JD) Cryans: “[How-to: Use HBase Bulk Loading, and Why](http://blog.cloudera.com/blog/2013/09/how-to-use-hbase-bulk-loading-and-why/),” *blog.cloudera.com*, September 27, 2013.
1. Nathan Marz: “[How to Beat the CAP Theorem](http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html),” *nathanmarz.com*, October 13, 2011.
1. Molly Bartlett Dishman and Martin Fowler: “[Agile Architecture](http://conferences.oreilly.com/software-architecture/sa2015/public/schedule/detail/40388),” at *O'Reilly Software Architecture Conference*, March 2015.
1. David J. DeWitt and Jim N. Gray: “[Parallel Database Systems: The Future of High Performance Database Systems](http://www.cs.cmu.edu/~pavlo/courses/fall2013/static/papers/dewittgray92.pdf),” *Communications of the ACM*, volume 35, number 6, pages 85–98, June 1992. [doi:10.1145/129888.129894](http://dx.doi.org/10.1145/129888.129894)
1. Jay Kreps: “[But the multi-tenancy thing is actually really really hard](https://twitter.com/jaykreps/status/528235702480142336),” tweetstorm, *twitter.com*, October 31, 2014.
1. Jeffrey Cohen, Brian Dolan, Mark Dunlap, et al.: “[MAD Skills: New Analysis Practices for Big Data](http://www.vldb.org/pvldb/2/vldb09-219.pdf),” *Proceedings of the VLDB Endowment*, volume 2, number 2, pages 1481–1492, August 2009. [doi:10.14778/1687553.1687576](http://dx.doi.org/10.14778/1687553.1687576)
1. Ignacio Terrizzano, Peter Schwarz, Mary Roth, and John E. Colino: “[Data Wrangling: The Challenging Journey from the Wild to the Lake](http://cidrdb.org/cidr2015/Papers/CIDR15_Paper2.pdf),” at *7th Biennial Conference on Innovative Data Systems Research* (CIDR), January 2015.
1. Paige Roberts: “[To Schema on Read or to Schema on Write, That Is the Hadoop Data Lake Question](http://adaptivesystemsinc.com/blog/to-schema-on-read-or-to-schema-on-write-that-is-the-hadoop-data-lake-question/),” *adaptivesystemsinc.com*, July 2, 2015.
1. Bobby Johnson and Joseph Adler: “[The Sushi Principle: Raw Data Is Better](https://vimeo.com/123985284),” at *Strata+Hadoop World*, February 2015.
1. Vinod Kumar Vavilapalli, Arun C. Murthy, Chris Douglas, et al.: “[Apache Hadoop YARN: Yet Another Resource Negotiator](http://www.socc2013.org/home/program/a5-vavilapalli.pdf),” at *4th ACM Symposium on Cloud Computing* (SoCC), October 2013. [doi:10.1145/2523616.2523633](http://dx.doi.org/10.1145/2523616.2523633)
1. Abhishek Verma, Luis Pedrosa, Madhukar Korupolu, et al.: “[Large-Scale Cluster Management at Google with Borg](http://research.google.com/pubs/pub43438.html),” at *10th European Conference on Computer Systems* (EuroSys), April 2015. [doi:10.1145/2741948.2741964](http://dx.doi.org/10.1145/2741948.2741964)
1. Malte Schwarzkopf: “[The Evolution of Cluster Scheduler Architectures](http://www.firmament.io/blog/scheduler-architectures.html),” *firmament.io*, March 9, 2016.
1. Matei Zaharia, Mosharaf Chowdhury, Tathagata Das, et al.: “[Resilient Distributed Datasets: A Fault-Tolerant Abstraction for In-Memory Cluster Computing](https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final138.pdf),” at *9th USENIX Symposium on Networked Systems Design and Implementation* (NSDI), April 2012.
1. Holden Karau, Andy Konwinski, Patrick Wendell, and Matei Zaharia: *Learning Spark*. O'Reilly Media, 2015. ISBN: 978-1-449-35904-1
1. Bikas Saha and Hitesh Shah: “[Apache Tez: Accelerating Hadoop Query Processing](http://www.slideshare.net/Hadoop_Summit/w-1205phall1saha),” at *Hadoop Summit*, June 2014.
1. Bikas Saha, Hitesh Shah, Siddharth Seth, et al.: “[Apache Tez: A Unifying Framework for Modeling and Building Data Processing Applications](http://home.cse.ust.hk/~weiwa/teaching/Fall15-COMP6611B/reading_list/Tez.pdf),” at *ACM International Conference on Management of Data* (SIGMOD), June 2015. [doi:10.1145/2723372.2742790](http://dx.doi.org/10.1145/2723372.2742790)
1. Kostas Tzoumas: “[Apache Flink: API, Runtime, and Project Roadmap](http://www.slideshare.net/KostasTzoumas/apache-flink-api-runtime-and-project-roadmap),” *slideshare.net*, January 14, 2015.
1. Alexander Alexandrov, Rico Bergmann, Stephan Ewen, et al.: “[The Stratosphere Platform for Big Data Analytics](https://ssc.io/pdf/2014-VLDBJ_Stratosphere_Overview.pdf),” *The VLDB Journal*, volume 23, number 6, pages 939–964, May 2014. [doi:10.1007/s00778-014-0357-y](http://dx.doi.org/10.1007/s00778-014-0357-y)
1. Michael Isard, Mihai Budiu, Yuan Yu, et al.: “[Dryad: Distributed Data-Parallel Programs from Sequential Building Blocks](http://research.microsoft.com/en-us/projects/dryad/eurosys07.pdf),” at *European Conference on Computer Systems* (EuroSys), March 2007. [doi:10.1145/1272996.1273005](http://dx.doi.org/10.1145/1272996.1273005)
1. Daniel Warneke and Odej Kao: “[Nephele: Efficient Parallel Data Processing in the Cloud](https://stratosphere2.dima.tu-berlin.de/assets/papers/Nephele_09.pdf),” at *2nd Workshop on Many-Task Computing on Grids and Supercomputers* (MTAGS), November 2009. [doi:10.1145/1646468.1646476](http://dx.doi.org/10.1145/1646468.1646476)
1. Lawrence Page, Sergey Brin, Rajeev Motwani, and Terry Winograd: ["The PageRank"](http://ilpubs.stanford.edu:8090/422/)
1. Leslie G. Valiant: “[A Bridging Model for Parallel Computation](http://dl.acm.org/citation.cfm?id=79181),” *Communications of the ACM*, volume 33, number 8, pages 103–111, August 1990. [doi:10.1145/79173.79181](http://dx.doi.org/10.1145/79173.79181)
1. Stephan Ewen, Kostas Tzoumas, Moritz Kaufmann, and Volker Markl: “[Spinning Fast Iterative Data Flows](http://vldb.org/pvldb/vol5/p1268_stephanewen_vldb2012.pdf),” *Proceedings of the VLDB Endowment*, volume 5, number 11, pages 1268-1279, July 2012. [doi:10.14778/2350229.2350245](http://dx.doi.org/10.14778/2350229.2350245)
1. Grzegorz Malewicz, Matthew H.Austern, Aart J. C. Bik, et al.: “[Pregel: A System for Large-Scale Graph Processing](https://kowshik.github.io/JPregel/pregel_paper.pdf),” at *ACM International Conference on Management of Data* (SIGMOD), June 2010. [doi:10.1145/1807167.1807184](http://dx.doi.org/10.1145/1807167.1807184)
1. Frank McSherry, Michael Isard, and Derek G. Murray: “[Scalability! But at What COST?](http://www.frankmcsherry.org/assets/COST.pdf),” at *15th USENIX Workshop on Hot Topics in Operating Systems* (HotOS), May 2015.
1. Ionel Gog, Malte Schwarzkopf, Natacha Crooks, et al.: “[Musketeer: All for One, One for All in Data Processing Systems](http://www.cl.cam.ac.uk/research/srg/netos/camsas/pubs/eurosys15-musketeer.pdf),” at *10th European Conference on Computer Systems* (EuroSys), April 2015. [doi:10.1145/2741948.2741968](http://dx.doi.org/10.1145/2741948.2741968)
1. Aapo Kyrola, Guy Blelloch, and Carlos Guestrin: “[GraphChi: Large-Scale Graph Computation on Just a PC](https://www.usenix.org/system/files/conference/osdi12/osdi12-final-126.pdf),” at *10th USENIX Symposium on Operating Systems Design and Implementation* (OSDI), October 2012.
1. Andrew Lenharth, Donald Nguyen, and Keshav Pingali: “[Parallel Graph Analytics](http://cacm.acm.org/magazines/2016/5/201591-parallel-graph-analytics/fulltext),” *Communications of the ACM*, volume 59, number 5, pages 78–87, May [doi:10.1145/2901919](http://dx.doi.org/10.1145/2901919)
1. Fabian Hüske: “[Peeking into Apache Flink's Engine Room](http://flink.apache.org/news/2015/03/13/peeking-into-Apache-Flinks-Engine-Room.html),” *flink.apache.org*, March 13, 2015.
1. Mostafa Mokhtar: “[Hive 0.14 Cost Based Optimizer (CBO) Technical Overview](http://hortonworks.com/blog/hive-0-14-cost-based-optimizer-cbo-technical-overview/),” *hortonworks.com*, March 2, 2015.
1. Michael Armbrust, Reynold S Xin, Cheng Lian, et al.: “[Spark SQL: Relational Data Processing in Spark](http://people.csail.mit.edu/matei/papers/2015/sigmod_spark_sql.pdf),” at *ACM International Conference on Management of Data* (SIGMOD), June 2015. [doi:10.1145/2723372.2742797](http://dx.doi.org/10.1145/2723372.2742797)
1. Daniel Blazevski: “[Planting Quadtrees for Apache Flink](http://insightdataengineering.com/blog/flink-knn/),” *insightdataengineering.com*, March 25, 2016.
1. Tom White: “[Genome Analysis Toolkit: Now Using Apache Spark for Data Processing](http://blog.cloudera.com/blog/2016/04/genome-analysis-toolkit-now-using-apache-spark-for-data-processing/),” *blog.cloudera.com*, April 6, 2016.
------
| 上一章 | 目錄 | 下一章 |
| --------------------------------- | ------------------------------- | ------------------------ |
| [第三部分：派生資料](part-iii.md) | [設計資料密集型應用](README.md) | [第十一章：流處理](ch11.md) |

934
zh-tw/ch11.md Normal file
View File

@ -0,0 +1,934 @@
# 11. 流處理
![](../img/ch11.png)
> 有效的複雜系統總是從簡單的系統演化而來。 反之亦然：從零設計的複雜系統沒一個能有效工作的。
>
> ——約翰·加爾，Systemantics（1975）
---------------
[TOC]
​ 在[第10章](ch10.md)中，我們討論了批處理技術，它讀取一組檔案作為輸入，並生成一組新的檔案作為輸出。輸出是**衍生資料（derived data）**的一種形式；也就是說，如果需要，可以透過再次執行批處理過程來重新建立資料集。我們看到了如何使用這個簡單而強大的想法來建立搜尋索引，推薦系統，做分析等等。
​ 然而，在[第10章](ch10.md)中仍然有一個很大的假設：即輸入是有界的，即已知和有限的大小，所以批處理知道它何時完成輸入的讀取。例如，MapReduce核心的排序操作必須讀取其全部輸入，然後才能開始生成輸出：可能發生這種情況：最後一條輸入記錄具有最小的鍵，因此需要第一個被輸出，所以提早開始輸出是不可行的。
​ 實際上，很多資料是**無界限**的，因為它隨著時間的推移而逐漸到達：你的使用者在昨天和今天產生了資料，明天他們將繼續產生更多的資料。除非你停業，否則這個過程永遠都不會結束，所以資料集從來就不會以任何有意義的方式“完成”【1】。因此，批處理程式必須將資料人為地分成固定時間段的資料塊，例如，在每天結束時處理一天的資料，或者在每小時結束時處理一小時的資料。
​ 日常批處理中的問題是，輸入的變更只會在一天之後的輸出中反映出來，這對於許多急躁的使用者來說太慢了。為了減少延遲，我們可以更頻繁地執行處理 —— 比如說，在每秒鐘的末尾 —— 或者甚至更連續一些，完全拋開固定的時間切片，當事件發生時就立即進行處理，這就是**流處理（stream processing）**背後的想法。
​ 一般來說，“流”是指隨著時間的推移逐漸可用的資料。這個概念出現在很多地方：Unix的stdin和stdout，程式語言（惰性列表）【2】，檔案系統API（如Java的`FileInputStream`），TCP連線，透過網際網路傳送音訊和影片等等。
在本章中，我們將把**事件流（event stream）**視為一種資料管理機制：無界限，增量處理，與[上一章](ch10.md)中批次資料相對應。我們將首先討論怎樣表示、儲存、透過網路傳輸流。在“[資料庫和流](#資料庫和流)”中，我們將研究流和資料庫之間的關係。最後在“[流處理](#流處理)”中，我們將研究連續處理這些流的方法和工具，以及它們用於應用構建的方式。
## 傳遞事件流
​ 在批處理領域，作業的輸入和輸出是檔案（也許在分散式檔案系統上）。流處理領域中的等價物看上去是什麼樣子的？
​ 當輸入是一個檔案（一個位元組序列），第一個處理步驟通常是將其解析為一系列記錄。在流處理的上下文中，記錄通常被叫做 **事件（event）** ，但它本質上是一樣的：一個小的，自包含的，不可變的物件，包含某個時間點發生的某件事情的細節。一個事件通常包含一個來自時鐘的時間戳，以指明事件發生的時間（參見“[單調鍾與時鐘](ch8.md#單調鍾與時鐘)”）。
​ 例如，發生的事件可能是使用者採取的行動，例如檢視頁面或進行購買。它也可能來源於機器，例如對溫度感測器或CPU利用率的週期性測量。在“[使用Unix工具進行批處理](ch10.md#使用Unix工具進行批處理)”的示例中，Web伺服器日誌的每一行都是一個事件。
​ 事件可能被編碼為文字字串或JSON，或者某種二進位制編碼，如[第4章](ch4.md)所述。這種編碼允許你儲存一個事件，例如將其附加到一個檔案，將其插入關係表，或將其寫入文件資料庫。它還允許你透過網路將事件傳送到另一個節點以進行處理。
​ 在批處理中，檔案被寫入一次，然後可能被多個作業讀取。類似地，在流處理術語中，一個事件由 **生產者（producer）** （也稱為 **釋出者（publisher）** 或 **傳送者（sender）** ）生成一次，然後可能由多個 **消費者（consumer）** （ **訂閱者（subscribers）** 或 **接收者（recipients）** ）進行處理【3】。在檔案系統中，檔名標識一組相關記錄；在流式系統中，相關的事件通常被聚合為一個 **主題（topic）** 或 **流（stream）** 。
​ 原則上講，檔案或資料庫就足以連線生產者和消費者：生產者將其生成的每個事件寫入資料儲存，且每個消費者定期輪詢資料儲存，檢查自上次執行以來新出現的事件。這實際上正是批處理在每天結束時處理當天資料時所做的事情。
​ 但當我們想要進行低延遲的連續處理時，如果資料儲存不是為這種用途專門設計的，那麼輪詢開銷就會很大。輪詢的越頻繁，能返回新事件的請求比例就越低，而額外開銷也就越高。相比之下，最好能在新事件出現時直接通知消費者。
​ 資料庫在傳統上對這種通知機制支援的並不好，關係型資料庫通常有 **觸發器（trigger）** ，它們可以對變化作出反應（如，插入表中的一行），但是它們的功能非常有限，並且在資料庫設計中有些後顧之憂【4,5】。相應的是，已經開發了專門的工具來提供事件通知。
### 訊息系統
​ 向消費者通知新事件的常用方式是使用**訊息傳遞系統（messaging system）**：生產者傳送包含事件的訊息，然後將訊息推送給消費者。我們之前在“[訊息傳遞中的資料流](ch4.md#訊息傳遞中的資料流)”中介紹了這些系統，但現在我們將詳細介紹這些系統。
​ 像生產者和消費者之間的Unix管道或TCP連線這樣的直接通道，是實現訊息傳遞系統的簡單方法。但是，大多數訊息傳遞系統都在這一基本模型上進行擴充套件。特別的是，Unix管道和TCP將恰好一個傳送者與恰好一個接收者連線，而一個訊息傳遞系統允許多個生產者節點將訊息傳送到同一個主題，並允許多個消費者節點接收主題中的訊息。
​ 在這個**釋出/訂閱**模式中，不同的系統採取各種各樣的方法，並沒有針對所有目的的通用答案。為了區分這些系統，問一下這兩個問題會特別有幫助：
1. **如果生產者傳送訊息的速度比消費者能夠處理的速度快會發生什麼？**一般來說，有三種選擇：系統可以丟掉訊息，將訊息放入緩衝佇列，或使用**背壓（backpressure）**（也稱為**流量控制（flow control）；**即阻塞生產者，以免其傳送更多的訊息）。例如Unix管道和TCP使用背壓：它們有一個固定大小的小緩衝區，如果填滿，傳送者會被阻塞，直到接收者從緩衝區中取出資料（參見“[網路擁塞和排隊](ch8.md#網路擁塞和排隊)”）。
如果訊息被快取在佇列中，那麼理解佇列增長會發生什麼是很重要的。當佇列裝不進記憶體時系統會崩潰嗎？還是將訊息寫入磁碟？如果是這樣，磁碟訪問又會如何影響訊息傳遞系統的效能【6】？
2. **如果節點崩潰或暫時離線，會發生什麼情況？ —— 是否會有訊息丟失？**與資料庫一樣，永續性可能需要寫入磁碟**和/或**複製的某種組合（參閱“[複製和永續性](ch7.md#複製和永續性)”），這是有代價的。如果你能接受有時訊息會丟失，則可能在同一硬體上獲得更高的吞吐量和更低的延遲。
是否可以接受訊息丟失取決於應用。例如，對於週期傳輸的感測器讀數和指標，偶爾丟失的資料點可能並不重要，因為更新的值會在短時間內發出。但要注意，如果大量的訊息被丟棄，可能無法立刻意識到指標已經不正確了【7】。如果你正在對事件計數，那麼更重要的是它們能夠可靠送達，因為每個丟失的訊息都意味著使計數器的錯誤擴大。
​ 我們在[第10章](ch10.md)中探討的批處理系統的一個很好的特性是，它們提供了強大的可靠性保證：失敗的任務會自動重試，失敗任務的部分輸出會自動丟棄。這意味著輸出與沒有發生故障一樣，這有助於簡化程式設計模型。在本章的後面，我們將研究如何在流處理的上下文中提供類似的保證。
#### 直接從生產者傳遞給消費者
許多訊息傳遞系統使用生產者和消費者之間的直接網路通訊，而不透過中間節點：
* UDP組播廣泛應用於金融行業，例如股票市場，其中低時延非常重要【8】。雖然UDP本身是不可靠的，但應用層的協議可以恢復丟失的資料包（生產者必須記住它傳送的資料包，以便能按需重新發送資料包）。
* 無代理的訊息庫，如ZeroMQ 【9】和nanomsg採取類似的方法，透過TCP或IP多播實現釋出/訂閱訊息傳遞。
* StatsD 【10】和Brubeck 【7】使用不可靠的UDP訊息傳遞來收集網路中所有機器的指標並對其進行監控。 （在StatsD協議中，只有接收到所有訊息，才認為計數器指標是正確的；使用UDP將使得指標處在一種最佳近似狀態【11】。另請參閱“[TCP與UDP](ch8.md#TCP與UDP)”
* 如果消費者在網路上公開了服務，生產者可以直接傳送HTTP或RPC請求（參閱“[透過服務進行資料流：REST和RPC](ch4.md#透過服務進行資料流：REST和RPC)”）將訊息推送給使用者。這就是webhooks背後的想法【12】，一種服務的回撥URL被註冊到另一個服務中，並且每當事件發生時都會向該URL發出請求。
儘管這些直接訊息傳遞系統在設計它們的環境中執行良好，但是它們通常要求應用程式碼意識到訊息丟失的可能性。它們的容錯程度極為有限：即使協議檢測到並重傳在網路中丟失的資料包，它們通常也只是假設生產者和消費者始終線上。
​ 如果消費者處於離線狀態，則可能會丟失其不可達時傳送的訊息。一些協議允許生產者重試失敗的訊息傳遞，但當生產者崩潰時，它可能會丟失訊息緩衝區及其本應傳送的訊息，這種方法可能就沒用了。
#### 訊息代理
​ 一種廣泛使用的替代方法是透過**訊息代理（message broker）**（也稱為**訊息佇列（message queue）**）傳送訊息，訊息代理實質上是一種針對處理訊息流而最佳化的資料庫。它作為伺服器執行，生產者和消費者作為客戶端連線到伺服器。生產者將訊息寫入代理，消費者透過從代理那裡讀取來接收訊息。
​ 透過將資料集中在代理上，這些系統可以更容易地容忍來來去去的客戶端（連線，斷開連線和崩潰），而永續性問題則轉移到代理的身上。一些訊息代理只將訊息儲存在記憶體中，而另一些訊息代理（取決於配置）將其寫入磁碟，以便在代理崩潰的情況下不會丟失。針對緩慢的消費者，它們通常會允許無上限的排隊（而不是丟棄訊息或背壓），儘管這種選擇也可能取決於配置。
​ 排隊的結果是，消費者通常是**非同步（asynchronous）**的：當生產者傳送訊息時，通常只會等待代理確認訊息已經被快取，而不等待訊息被消費者處理。向消費者遞送訊息將發生在未來某個未定的時間點 —— 通常在幾分之一秒之內，但有時當訊息堆積時會顯著延遲。
#### 訊息代理與資料庫對比
​ 有些訊息代理甚至可以使用XA或JTA參與兩階段提交協議（參閱“[實踐中的分散式事務](ch9.md#實踐中的分散式事務)”）。這個功能與資料庫在本質上非常相似，儘管訊息代理和資料庫之間仍存在實踐上很重要的差異：
* 資料庫通常保留資料直至顯式刪除，而大多數訊息代理在訊息成功遞送給消費者時會自動刪除訊息。這樣的訊息代理不適合長期的資料儲存。
* 由於它們很快就能刪除訊息，大多數訊息代理都認為它們的工作集相當小—— 即佇列很短。如果代理需要緩衝很多訊息，比如因為消費者速度較慢（如果記憶體裝不下訊息，可能會溢位到磁碟），每個訊息需要更長的處理時間，整體吞吐量可能會惡化【6】。
* 資料庫通常支援二級索引和各種搜尋資料的方式，而訊息代理通常支援按照某種模式匹配主題，訂閱其子集。機制並不一樣，對於客戶端選擇想要了解的資料的一部分，這是兩種基本的方式。
* 查詢資料庫時，結果通常基於某個時間點的資料快照；如果另一個客戶端隨後向資料庫寫入一些改變了查詢結果的內容，則第一個客戶端不會發現其先前結果現已過期（除非它重複查詢或輪詢變更）。相比之下，訊息代理不支援任意查詢，但是當資料發生變化時（即新訊息可用時），它們會通知客戶端。
這是關於訊息代理的傳統觀點，它被封裝在諸如JMS 【14】和AMQP 【15】的標準中，並且被諸如RabbitMQ，ActiveMQ，HornetQ，Qpid，TIBCO企業訊息服務，IBM MQ，Azure Service Bus和Google Cloud Pub/Sub實現 【16】。
#### 多個消費者
當多個消費者從同一主題中讀取訊息時，有使用兩種主要的訊息傳遞模式，如[圖11-1](../img/fig11-1.png)所示：
***負載均衡（load balance）***
​ 每條訊息都被傳遞給消費者**之一**，所以處理該主題下訊息的工作能被多個消費者共享。代理可以為消費者任意分配訊息。當處理訊息的代價高昂，希望能並行處理訊息時，此模式非常有用（在AMQP中，可以透過讓多個客戶端從同一個佇列中消費來實現負載均衡，而在JMS中則稱之為**共享訂閱（shared subscription）**）。
***扇出（fan-out）***
​ 每條訊息都被傳遞給**所有**消費者。扇出允許幾個獨立的消費者各自“收聽”相同的訊息廣播，而不會相互影響 —— 這個流處理中的概念對應批處理中多個不同批處理作業讀取同一份輸入檔案 （JMS中的主題訂閱與AMQP中的交叉繫結提供了這一功能）。
![](../img/fig11-1.png)
**圖11-1 （a）負載平衡：在消費者間共享消費主題；（b）扇出：將每條訊息傳遞給多個消費者。**
​ 兩種模式可以組合使用：例如，兩個獨立的消費者組可以每組各訂閱一個主題，每一組都共同收到所有訊息，但在每一組內部，每條訊息僅由單個節點處理。
#### 確認與重新交付
​ 消費隨時可能會崩潰，所以有一種可能的情況是：代理向消費者遞送訊息，但消費者沒有處理，或者在消費者崩潰之前只進行了部分處理。為了確保訊息不會丟失，訊息代理使用**確認（acknowledgments）**：客戶端必須顯式告知代理訊息處理完畢的時間，以便代理能將訊息從佇列中移除。
​ 如果與客戶端的連線關閉，或者代理超出一段時間未收到確認，代理則認為訊息沒有被處理，因此它將訊息再遞送給另一個消費者。 （請注意可能發生這樣的情況，訊息**實際上是**處理完畢的，但**確認**在網路中丟失了。需要一種原子提交協議才能處理這種情況，正如在“[實踐中的分散式事務](ch9.md#實踐中的分散式事務)”中所討論的那樣）
​ 當與負載均衡相結合時，這種重傳行為對訊息的順序有種有趣的影響。在[圖11-2](../img/fig11-2.png)中，消費者通常按照生產者傳送的順序處理訊息。然而消費者2在處理訊息m3時崩潰，與此同時消費者1正在處理訊息m4。未確認的訊息m3隨後被重新發送給消費者1，結果消費者1按照m4，m3，m5的順序處理訊息。因此m3和m4的交付順序與以生產者1的傳送順序不同。
![](../img/fig11-2.png)
**圖11-2 在處理m3時消費者2崩潰，因此稍後重傳至消費者1**
​ 即使訊息代理試圖保留訊息的順序（如JMS和AMQP標準所要求的），負載均衡與重傳的組合也不可避免地導致訊息被重新排序。為避免此問題，你可以讓每個消費者使用單獨的佇列（即不使用負載均衡功能）。如果訊息是完全獨立的，則訊息順序重排並不是一個問題。但正如我們將在本章後續部分所述，如果訊息之間存在因果依賴關係，這就是一個很重要的問題。
### 分割槽日誌
​ 透過網路傳送資料包或向網路服務傳送請求通常是短暫的操作，不會留下永久的痕跡。儘管可以永久記錄（透過抓包與日誌），但我們通常不這麼做。即使是將訊息持久地寫入磁碟的訊息代理，在送達給消費者之後也會很快刪除訊息，因為它們建立在短暫訊息傳遞的思維方式上。
​ 資料庫和檔案系統採用截然相反的方法論：至少在某人顯式刪除前，通常寫入資料庫或檔案的所有內容都要被永久記錄下來。
​ 這種思維方式上的差異對建立衍生資料的方式有巨大影響。如[第10章](ch10.md)所述，批處理過程的一個關鍵特性是，你可以反覆執行它們，試驗處理步驟，不用擔心損壞輸入（因為輸入是隻讀的）。而 AMQP/JMS風格的訊息傳遞並非如此：收到訊息是具有破壞性的，因為確認可能導致訊息從代理中被刪除，因此你不能期望再次運行同一個消費者能得到相同的結果。
​ 如果你將新的消費者新增到訊息系統，通常只能接收到消費者註冊之後開始傳送的訊息。先前的任何訊息都隨風而逝，一去不復返。作為對比，你可以隨時為檔案和資料庫新增新的客戶端，且能讀取任意久遠的資料（只要應用沒有顯式覆蓋或刪除這些資料）。
​ 為什麼我們不能把它倆雜交一下，既有資料庫的持久儲存方式，又有訊息傳遞的低延遲通知？這就是**基於日誌的訊息代理（log-based message brokers）** 背後的想法。
#### 使用日誌進行訊息儲存
​ 日誌只是磁碟上簡單的僅追加記錄序列。我們先前在[第3章](ch3.md)中日誌結構儲存引擎和預寫式日誌的上下文中討論了日誌，在[第5章](ch5.md)複製的上下文裡也討論了它。
​ 同樣的結構可以用於實現訊息代理：生產者透過將訊息追加到日誌末尾來發送訊息，而消費者透過依次讀取日誌來接收訊息。如果消費者讀到日誌末尾，則會等待新訊息追加的通知。 Unix工具`tail -f` 能監視檔案被追加寫入的資料，基本上就是這樣工作的。
​ 為了擴充套件到比單個磁碟所能提供的更高吞吐量，可以對日誌進行**分割槽**（在[第6章](ch6.md)的意義上）。不同的分割槽可以託管在不同的機器上，且每個分割槽都拆分出一份能獨立於其他分割槽進行讀寫的日誌。一個主題可以定義為一組攜帶相同型別訊息的分割槽。這種方法如[圖11-3](../img/fig11-3.png)所示。
​ 在每個分割槽內，代理為每個訊息分配一個單調遞增的序列號或**偏移量（offset）**（在[圖11-3](../img/fig11-3.png)中，框中的數字是訊息偏移量）。這種序列號是有意義的，因為分割槽是僅追加寫入的，所以分割槽內的訊息是完全有序的。沒有跨不同分割槽的順序保證。
![](../img/fig11-3.png)
**圖11-3 生產者透過將訊息追加寫入主題分割槽檔案來發送訊息，消費者依次讀取這些檔案**
​ Apache Kafka 【17,18】，Amazon Kinesis Streams 【19】和Twitter的DistributedLog 【20,21】都是基於日誌的訊息代理。 Google Cloud Pub/Sub在架構上類似，但對外暴露的是JMS風格的API，而不是日誌抽象【16】。儘管這些訊息代理將所有訊息寫入磁碟，但透過跨多臺機器分割槽，每秒能夠實現數百萬條訊息的吞吐量，並透過複製訊息來實現容錯性【22,23】。
#### 日誌與傳統訊息相比
​ 基於日誌的方法天然支援扇出式訊息傳遞，因為多個消費者可以獨立讀取日誌，而不會相互影響 —— 讀取訊息不會將其從日誌中刪除。為了在一組消費者之間實現負載平衡，代理可以將整個分割槽分配給消費者組中的節點，而不是將單條訊息分配給消費者客戶端。
​ 每個客戶端消費指派分割槽中的**所有**訊息。然後使用分配的分割槽中的所有訊息。通常情況下，當一個使用者被指派了一個日誌分割槽時，它會以簡單的單執行緒方式順序地讀取分割槽中的訊息。這種粗粒度的負載均衡方法有一些缺點：
* 共享消費主題工作的節點數，最多為該主題中的日誌分割槽數，因為同一個分割槽內的所有訊息被遞送到同一個節點[^i]。
* 如果某條訊息處理緩慢，則它會阻塞該分割槽中後續訊息的處理（一種行首阻塞的形式；請參閱“[描述效能](ch1.md#描述效能)”）。
因此在訊息處理代價高昂，希望逐條並行處理，以及訊息的順序並沒有那麼重要的情況下，JMS/AMQP風格的訊息代理是可取的。另一方面，在訊息吞吐量很高，處理迅速，順序很重要的情況下，基於日誌的方法表現得非常好。
[^i]: 設計一種負載均衡方案是可行的，在這種方案中，兩個消費者透過讀取全部訊息來共享處理分割槽的工作，但是其中一個只考慮具有偶數偏移量的訊息，而另一個消費者只處理奇數編號的偏移量。或者你可以將訊息攤到一個執行緒池中來處理，但這種方法會使消費者偏移量管理變得複雜。一般來說，單執行緒處理單分割槽是合適的，可以透過增加更多分割槽來提高並行度。
#### 消費者偏移量
​ 順序消費一個分割槽使得判斷訊息是否已經被處理變得相當容易：所有偏移量小於消費者的當前偏移量的訊息已經被處理，而具有更大偏移量的訊息還沒有被看到。因此，代理不需要跟蹤確認每條訊息，只需要定期記錄消費者的偏移即可。在這種方法減少了額外簿記開銷，而且在批處理和流處理中採用這種方法有助於提高基於日誌的系統的吞吐量。
​ 實際上，這種偏移量與單領導者資料庫複製中常見的日誌序列號非常相似，我們在“[設定新從庫](ch5.md#設定新從庫)”中討論了這種情況。在資料庫複製中，日誌序列號允許跟隨者斷開連線後，重新連線到領導者，並在不跳過任何寫入的情況下恢復複製。這裡原理完全相同：訊息代理的表現得像一個主庫，而消費者就像一個從庫。
​ 如果消費者節點失效，則失效消費者的分割槽將指派給其他節點，並從最後記錄的偏移量開始消費訊息。如果消費者已經處理了後續的訊息，但還沒有記錄它們的偏移量，那麼重啟後這些訊息將被處理兩次。我們將在本章後面討論這個問題的處理方法。
#### 磁碟空間使用
​ 如果只追加寫入日誌，則磁碟空間終究會耗盡。為了回收磁碟空間，日誌實際上被分割成段，並不時地將舊段刪除或移動到歸檔儲存。 （我們將在後面討論一種更為複雜的磁碟空間釋放方式）
​ 這就意味著如果一個慢消費者跟不上訊息產生的速率而落後的太多，它的消費偏移量指向了刪除的段，那麼它就會錯過一些訊息。實際上，日誌實現了一個有限大小的緩衝區，當緩衝區填滿時會丟棄舊訊息，它也被稱為**迴圈緩衝區（circular buffer）**或**環形緩衝區（ring buffer）**。不過由於緩衝區在磁碟上，因此可能相當的大。
​ 讓我們做個簡單計算。在撰寫本文時，典型的大型硬碟容量為6TB，順序寫入吞吐量為150MB/s。如果以最快的速度寫訊息，則需要大約11個小時才能填滿磁碟。因而磁碟可以緩衝11個小時的訊息，之後它將開始覆蓋舊的訊息。即使使用多個磁碟和機器，這個比率也是一樣的。實踐中的部署很少能用滿磁碟的寫入頻寬，所以通常可以儲存一個幾天甚至幾周的日誌緩衝區。
​ 不管保留多長時間的訊息，日誌的吞吐量或多或少保持不變，因為無論如何，每個訊息都會被寫入磁碟【18】。這種行為與預設將訊息儲存在記憶體中，僅當佇列太長時才寫入磁碟的訊息傳遞系統形成鮮明對比。當佇列很短時，這些系統非常快；而當這些系統開始寫入磁碟時，就要慢的多，所以吞吐量取決於保留的歷史數量。
#### 當消費者跟不上生產者時
​ 在“[訊息傳遞系統](#訊息傳遞系統)”中，如果消費者無法跟上生產者傳送資訊的速度時，我們討論了三種選擇：丟棄資訊，進行緩衝或施加背壓。在這種分類法裡，基於日誌的方法是緩衝的一種形式，具有很大，但大小固定的緩衝區（受可用磁碟空間的限制）。
​ 如果消費者遠遠落後，而所要求的資訊比保留在磁碟上的資訊還要舊，那麼它將不能讀取這些資訊，所以代理實際上丟棄了比緩衝區容量更大的舊資訊。你可以監控消費者落後日誌頭部的距離，如果落後太多就發出報警。由於緩衝區很大，因而有足夠的時間讓人類運維來修復慢消費者，並在訊息開始丟失之前讓其趕上。
​ 即使消費者真的落後太多開始丟失訊息，也只有那個消費者受到影響；它不會中斷其他消費者的服務。這是一個巨大的運維優勢：你可以實驗性地消費生產日誌，以進行開發，測試或除錯，而不必擔心會中斷生產服務。當消費者關閉或崩潰時，會停止消耗資源，唯一剩下的只有消費者偏移量。
​ 這種行為也與傳統的資訊代理形成了鮮明對比，在那種情況下，你需要小心地刪除那些消費者已經關閉的佇列—— 否則那些佇列就會累積不必要的訊息，從其他仍活躍的消費者那裡佔走記憶體。
#### 重播舊資訊
​ 我們之前提到，使用AMQP和JMS風格的訊息代理，處理和確認訊息是一個破壞性的操作，因為它會導致訊息在代理上被刪除。另一方面，在基於日誌的訊息代理中，使用訊息更像是從檔案中讀取資料：這是隻讀操作，不會更改日誌。
​ 除了消費者的任何輸出之外，處理的唯一副作用是消費者偏移量的前進。但偏移量是在消費者的控制之下的，所以如果需要的話可以很容易地操縱：例如你可以用昨天的偏移量跑一個消費者副本，並將輸出寫到不同的位置，以便重新處理最近一天的訊息。你可以使用各種不同的處理程式碼重複任意次。
​ 這一方面使得基於日誌的訊息傳遞更像上一章的批處理，其中衍生資料透過可重複的轉換過程與輸入資料顯式分離。它允許進行更多的實驗，更容易從錯誤和漏洞中恢復，使其成為在組織內整合資料流的良好工具【24】。
## 流與資料庫
​ 我們已經在訊息代理和資料庫之間進行了一些比較。儘管傳統上它們被視為單獨的工具類別，但是我們看到基於日誌的訊息代理已經成功地從資料庫中獲取靈感並將其應用於訊息傳遞。我們也可以反過來：從訊息傳遞和流中獲取靈感，並將它們應用於資料庫。
​ 我們之前曾經說過，事件是某個時刻發生的事情的記錄。發生的事情可能是使用者操作（例如鍵入搜尋查詢）或讀取感測器，但也可能是**寫入資料庫**。某些東西被寫入資料庫的事實是可以被捕獲，儲存和處理的事件。這一觀察結果表明，資料庫和資料流之間的聯絡不僅僅是磁碟日誌的物理儲存 —— 而是更深層的聯絡。
​ 事實上，複製日誌（參閱“[複製日誌的實現](ch5.md#複製日誌的實現)”）是資料庫寫入事件的流，由主庫在處理事務時生成。從庫將寫入流應用到它們自己的資料庫副本，從而最終得到相同資料的精確副本。複製日誌中的事件描述發生的資料更改。
​ 我們還在“[全序廣播](ch9.md#全序廣播)”中遇到了狀態機複製原理，其中指出：如果每個事件代表對資料庫的寫入，並且每個副本按相同的順序處理相同的事件，則副本將達到相同的最終狀態 （假設處理一個事件是一個確定性的操作）。這是事件流的又一種場景！
​ 在本節中，我們將首先看看異構資料系統中出現的一個問題，然後探討如何透過將事件流的想法帶入資料庫來解決這個問題。
### 保持系統同步
​ 正如我們在本書中所看到的，沒有一個系統能夠滿足所有的資料儲存，查詢和處理需求。在實踐中，大多數重要應用都需要組合使用幾種不同的技術來滿足所有的需求：例如，使用OLTP資料庫來為使用者請求提供服務，使用快取來加速常見請求，使用全文索引搜尋處理搜尋查詢，使用資料倉庫用於分析。每一個元件都有自己的資料副本，以自己的表示儲存，並根據自己的目的進行最佳化。
​ 由於相同或相關的資料出現在了不同的地方，因此相互間需要保持同步：如果某個專案在資料庫中被更新，它也應當在快取，搜尋索引和資料倉庫中被更新。對於資料倉庫，這種同步通常由ETL程序執行（參見“[資料倉庫](ch3.md#資料倉庫)”），通常是先取得資料庫的完整副本，然後執行轉換，並批次載入到資料倉庫中 —— 換句話說，批處理。我們在“[批次工作流的輸出](ch10.md#批次工作流的輸出)”中同樣看到了如何使用批處理建立搜尋索引，推薦系統和其他衍生資料系統。
​ 如果週期性的完整資料庫轉儲過於緩慢，有時會使用的替代方法是**雙寫（dual write）**，其中應用程式碼在資料變更時明確寫入每個系統：例如，首先寫入資料庫，然後更新搜尋索引，然後使快取項失效（甚至同時執行這些寫入）。
​ 但是，雙寫有一些嚴重的問題，其中一個是競爭條件，如[圖11-4](../img/fig11-4.png)所示。在這個例子中，兩個客戶端同時想要更新一個專案X：客戶端1想要將值設定為A，客戶端2想要將其設定為B。兩個客戶端首先將新值寫入資料庫，然後將其寫入到搜尋索引。因為運氣不好，這些請求的時序是交錯的：資料庫首先看到來自客戶端1的寫入將值設定為A，然後來自客戶端2的寫入將值設定為B，因此資料庫中的最終值為B。搜尋索引首先看到來自客戶端2的寫入，然後是客戶端1的寫入，所以搜尋索引中的最終值是A。即使沒發生錯誤，這兩個系統現在也永久地不一致了。
![](../img/fig11-4.png)
**圖11-4 在資料庫中X首先被設定為A，然後被設定為B，而在搜尋索引處，寫入以相反的順序到達**
​ 除非有一些額外的併發檢測機制，例如我們在“[檢測併發寫入](ch5.md#檢測併發寫入)”中討論的版本向量，否則你甚至不會意識到發生了併發寫入 —— 一個值將簡單地以無提示方式覆蓋另一個值。
​ 雙重寫入的另一個問題是，其中一個寫入可能會失敗，而另一個成功。這是一個容錯問題，而不是一個併發問題，但也會造成兩個系統互相不一致的結果。確保它們要麼都成功要麼都失敗，是原子提交問題的一個例子，解決這個問題的代價是昂貴的（參閱“[原子提交和兩階段提交（2PC）](ch7.md#原子提交和兩階段提交（2PC）)”）。
​ 如果你只有一個單領導者複製的資料庫，那麼這個領導者決定了寫入順序，而狀態機複製方法可以在資料庫副本上工作。然而，在[圖11-4](../img/fig11-4.png)中，沒有單個主庫：資料庫可能有一個領導者，搜尋索引也可能有一個領導者，但是兩者都不追隨對方，所以可能會發生衝突（參見“[多領導者複製](ch5.md#多領導者複製)“）。
​ 如果實際上只有一個領導者 —— 例如，資料庫 —— 而且我們能讓搜尋索引成為資料庫的追隨者，情況要好得多。但這在實踐中可能嗎？
### 變更資料捕獲
​ 大多數資料庫的複製日誌的問題在於，它們一直被當做資料庫的內部實現細節，而不是公開的API。客戶端應該透過其資料模型和查詢語言來查詢資料庫，而不是解析複製日誌並嘗試從中提取資料。
​ 數十年來，許多資料庫根本沒有記錄在檔的，獲取變更日誌的方式。由於這個原因，捕獲資料庫中所有的變更，然後將其複製到其他儲存技術（搜尋索引，快取，資料倉庫）中是相當困難的。
​ 最近，人們對**變更資料捕獲（change data capture, CDC）** 越來越感興趣，這是一種觀察寫入資料庫的所有資料變更，並將其提取並轉換為可以複製到其他系統中的形式的過程。 CDC是非常有意思的，尤其是當變更能在被寫入後立刻用於流時。
​ 例如，你可以捕獲資料庫中的變更，並不斷將相同的變更應用至搜尋索引。如果變更日誌以相同的順序應用，則可以預期搜尋索引中的資料與資料庫中的資料是匹配的。搜尋索引和任何其他衍生資料系統只是變更流的消費者，如[圖11-5](../img/fig11-5.png)所示。
![](../img/fig11-5.png)
**圖11-5 將資料按順序寫入一個數據庫，然後按照相同的順序將這些更改應用到其他系統**
#### 變更資料捕獲的實現
​ 我們可以將日誌消費者叫做**衍生資料系統**，正如在第三部分的[介紹](part-iii.md)中所討論的：儲存在搜尋索引和資料倉庫中的資料，只是**記錄系統**資料的額外檢視。變更資料捕獲是一種機制，可確保對記錄系統所做的所有更改都反映在衍生資料系統中，以便衍生系統具有資料的準確副本。
​ 從本質上說，變更資料捕獲使得一個數據庫成為領導者（被捕獲變化的資料庫），並將其他元件變為追隨者。基於日誌的訊息代理非常適合從源資料庫傳輸變更事件，因為它保留了訊息的順序（避免了[圖11-2](../img/fig11-2.png)的重新排序問題）。
​ 資料庫觸發器可用來實現變更資料捕獲（參閱“[基於觸發器的複製](ch5.md#基於觸發器的複製)”），透過註冊觀察所有變更的觸發器，並將相應的變更項寫入變更日誌表中。但是它們往往是脆弱的，而且有顯著的效能開銷。解析複製日誌可能是一種更穩健的方法，但它也很有挑戰，例如應對模式變更。
​ LinkedIn的Databus 【25】，Facebook的Wormhole 【26】和Yahoo!的Sherpa【27】大規模地應用這個思路。 Bottled Water使用解碼WAL的API實現了PostgreSQL的CDC 【28】，Maxwell和Debezium透過解析binlog對MySQL做了類似的事情【29,30,31】，Mongoriver讀取MongoDB oplog 【32,33】 ，而GoldenGate為Oracle提供類似的功能【34,35】。
​ 像訊息代理一樣，變更資料捕獲通常是非同步的：記錄資料庫系統不會等待消費者應用變更再進行提交。這種設計具有的運維優勢是，新增緩慢的消費者不會過度影響記錄系統。不過，所有複製延遲可能有的問題在這裡都可能出現（參見“[複製延遲問題](ch5.md#複製延遲問題)”）。
#### 初始快照
​ 如果你擁有**所有**對資料庫進行變更的日誌，則可以透過重放該日誌，來重建資料庫的完整狀態。但是在許多情況下，永遠保留所有更改會耗費太多磁碟空間，且重放過於費時，因此日誌需要被截斷。
​ 例如，構建新的全文索引需要整個資料庫的完整副本 —— 僅僅應用最近變更的日誌是不夠的，因為這樣會丟失最近未曾更新的專案。因此，如果你沒有完整的歷史日誌，則需要從一個一致的快照開始，如先前上的“[設定新的從庫](ch5.md#設定新的從庫)”中所述。
​ 資料庫的快照必須與變更日誌中的已知位置或偏移量相對應，以便在處理完快照後知道從哪裡開始應用變更。一些CDC工具集成了這種快照功能，而其他工具則把它留給你手動執行。
#### 日誌壓縮
​ 如果你只能保留有限的歷史日誌，則每次要新增新的衍生資料系統時，都需要做一次快照。但**日誌壓縮（log compaction）** 提供了一個很好的備選方案。
​ 我們之前在日誌結構儲存引擎的上下文中討論了“[Hash索引](ch3.md#Hash索引)”中的日誌壓縮（參見[圖3-2](../img/fig3-2.png)的示例）。原理很簡單：儲存引擎定期在日誌中查詢具有相同鍵的記錄，丟掉所有重複的內容，並只保留每個鍵的最新更新。這個壓縮與合併過程在後臺執行。
​ 在日誌結構儲存引擎中，具有特殊值NULL（**墓碑（tombstone）**）的更新表示該鍵被刪除，並會在日誌壓縮過程中被移除。但只要鍵不被覆蓋或刪除，它就會永遠留在日誌中。這種壓縮日誌所需的磁碟空間僅取決於資料庫的當前內容，而不取決於資料庫中曾經發生的寫入次數。如果相同的鍵經常被覆蓋寫入，則先前的值將最終將被垃圾回收，只有最新的值會保留下來。
​ 在基於日誌的訊息代理與變更資料捕獲的上下文中也適用相同的想法。如果CDC系統被配置為，每個變更都包含一個主鍵，且每個鍵的更新都替換了該鍵以前的值，那麼只需要保留對鍵的最新寫入就足夠了。
​ 現在，無論何時需要重建衍生資料系統（如搜尋索引），你可以從壓縮日誌主題0偏移量處啟動新的消費者，然後依次掃描日誌中的所有訊息。日誌能保證包含資料庫中每個鍵的最新值（也可能是一些較舊的值）—— 換句話說，你可以使用它來獲取資料庫內容的完整副本，而無需從CDC源資料庫取一個快照。
​ Apache Kafka支援這種日誌壓縮功能。正如我們將在本章後面看到的，它允許訊息代理被當成永續性儲存使用，而不僅僅是用於臨時訊息。
#### 變更流的API支援
​ 越來越多的資料庫開始將變更流作為第一類的介面，而不像傳統上要去做加裝改造，費工夫逆向工程一個CDC。例如，RethinkDB允許查詢訂閱通知，當查詢結果變更時獲得通知【36】，Firebase 【37】和CouchDB 【38】基於變更流進行同步，該變更流同樣可用於應用。而Meteor使用MongoDB oplog訂閱資料變更，並改變了使用者介面【39】。
​ VoltDB允許事務以流的形式連續地從資料庫中匯出資料【40】。資料庫將關係資料模型中的輸出流表示為一個表，事務可以向其中插入元組，但不能查詢。已提交事務按照提交順序寫入這個特殊表，而流則由該表中的元組日誌構成。外部消費者可以非同步消費該日誌，並使用它來更新衍生資料系統。
​ Kafka Connect 【41】致力於將廣泛的資料庫系統的變更資料捕獲工具與Kafka整合。一旦變更事件進入Kafka中，它就可以用於更新衍生資料系統，比如搜尋索引，也可以用於本章稍後討論的流處理系統。
### 事件溯源
​ 我們在這裡討論的想法和**事件溯源（ Event Sourcing）** 之間有一些相似之處，這是一個在 **領域驅動設計（domain-driven design, DDD）** 社群中折騰出來的技術。我們將簡要討論事件溯源，因為它包含了一些關於流處理系統的有用想法。
​ 與變更資料捕獲類似，事件溯源涉及到**將所有對應用狀態的變更** 儲存為變更事件日誌。最大的區別是事件溯源將這一想法應用到了幾個不同的抽象層次上：
* 在變更資料捕獲中，應用以**可變方式（mutable way）** 使用資料庫，任意更新和刪除記錄。變更日誌是從資料庫的底層提取的（例如，透過解析複製日誌），從而確保從資料庫中提取的寫入順序與實際寫入的順序相匹配，從而避免[圖11-4](../img/fig11-4.png)中的競態條件。寫入資料庫的應用不需要知道CDC的存在。
* 在事件溯源中，應用邏輯顯式構建在寫入事件日誌的不可變事件之上。在這種情況下，事件儲存是僅追加寫入的，更新與刪除是不鼓勵的或禁止的。事件被設計為旨在反映應用層面發生的事情，而不是底層的狀態變更。
事件源是一種強大的資料建模技術：從應用的角度來看，將使用者的行為記錄為不可變的事件更有意義，而不是在可變資料庫中記錄這些行為的影響。事件代理使得應用隨時間演化更為容易，透過事實更容易理解事情發生的原因，使得除錯更為容易，並有利於防止應用Bug（請參閱“[不可變事件的優點](#不可變事件的優點)”）。
​ 例如，儲存“學生取消選課”事件以中性的方式清楚地表達了單個行為的意圖，而副作用“從登錄檔中刪除了一個條目，而一條取消原因被新增到學生反饋表“則嵌入了很多有關稍後資料使用方式的假設。如果引入一個新的應用功能，例如“將位置留給等待列表中的下一個人” —— 事件溯源方法允許將新的副作用輕鬆地連結至現有事件之後。
​ 事件溯源類似於**編年史（chronicle）** 資料模型【45】，事件日誌與星型模式中的事實表之間也存在相似之處（參閱“[星型和雪花型：分析的模式](ch3.md#星型和雪花型：分析的模式)”） 。
​ 諸如Event Store【46】這樣的專業資料庫已經被開發出來，供使用事件溯源的應用使用，但總的來說，這種方法獨立於任何特定的工具。傳統的資料庫或基於日誌的訊息代理也可以用來構建這種風格的應用。
#### 從事件日誌中派生出當前狀態
​ 事件日誌本身並不是很有用，因為使用者通常期望看到的是系統的當前狀態，而不是變更歷史。例如，在購物網站上，使用者期望能看到他們購物車裡的當前內容，而不是他們購物車所有變更的一個僅追加列表。
​ 因此，使用事件溯源的應用需要拉取事件日誌（表示**寫入**系統的資料），並將其轉換為適合向用戶顯示的應用狀態（從系統**讀取**資料的方式【47】）。這種轉換可以使用任意邏輯，但它應當是確定性的，以便能再次執行，並從事件日誌中衍生出相同的應用狀態。
​ 與變更資料捕獲一樣，重放事件日誌允許讓你重新構建系統的當前狀態。不過，日誌壓縮需要採用不同的方式處理：
* 用於記錄更新的CDC事件通常包含記錄的**完整新版本**，因此主鍵的當前值完全由該主鍵的最近事件確定，而日誌壓縮可以丟棄相同主鍵的先前事件。
* 另一方面，事件溯源在更高層次進行建模：事件通常表示使用者操作的意圖，而不是因為操作而發生的狀態更新機制。在這種情況下，後面的事件通常不會覆蓋先前的事件，所以你需要完整的歷史事件來重新構建最終狀態。這裡進行同樣的日誌壓縮是不可能的。
使用事件溯源的應用通常有一些機制，用於儲存從事件日誌中匯出的當前狀態快照，因此它們不需要重複處理完整的日誌。然而這只是一種效能最佳化，用來加速讀取，提高從崩潰中恢復的速度；真正的目的是系統能夠永久儲存所有原始事件，並在需要時重新處理完整的事件日誌。我們將在“[不變性的限制](#不變性的限制)”中討論這個假設。
#### 命令和事件
​ 事件溯源的哲學是仔細區分**事件（event）**和**命令（command）**【48】。當來自使用者的請求剛到達時，它一開始是一個命令：在這個時間點上它仍然可能可能失敗，比如，因為違反了一些完整性條件。應用必須首先驗證它是否可以執行該命令。如果驗證成功並且命令被接受，則它變為一個持久化且不可變的事件。
​ 例如，如果使用者試圖註冊特定使用者名稱，或預定飛機或劇院的座位，則應用需要檢查使用者名稱或座位是否已被佔用。 （先前在“[容錯概念](ch8.md#容錯概念)”中討論過這個例子）當檢查成功時，應用可以生成一個事件，指示特定的使用者名稱是由特定的使用者ID註冊的，座位已經預留給特定的顧客。
​ 在事件生成的時刻，它就成為了**事實（fact）**。即使客戶稍後決定更改或取消預訂，他們之前曾預定了某個特定座位的事實仍然成立，而更改或取消是之後新增的單獨的事件。
​ 事件流的消費者不允許拒絕事件：當消費者看到事件時，它已經成為日誌中不可變的一部分，並且可能已經被其他消費者看到了。因此任何對命令的驗證，都需要在它成為事件之前同步完成。例如，透過使用一個可自動驗證命令的可序列化事務來發布事件。
​ 或者，預訂座位的使用者請求可以拆分為兩個事件：第一個是暫時預約，第二個是驗證預約後的獨立的確認事件（如“[使用全序廣播實現線性一致儲存](ch9.md#使用全序廣播實現線性一致儲存)”中所述） 。這種分割方式允許驗證發生在一個非同步的過程中。
#### 狀態，流和不變性
​ 我們在[第10章](ch10.md)中看到，批處理因其輸入檔案不變性而受益良多，你可以在現有輸入檔案上執行實驗性處理作業，而不用擔心損壞它們。這種不變性原則也是使得事件溯源與變更資料捕獲如此強大的原因。
​ 我們通常將資料庫視為應用程式當前狀態的儲存 —— 這種表示針對讀取進行了最佳化，而且通常對於服務查詢而言是最為方便的表示。狀態的本質是，它會變化，所以資料庫才會支援資料的增刪改。這又是如何符合不變性的呢？
​ 只要你的狀態發生了變化，那麼這個狀態就是這段時間中事件修改的結果。例如，當前可用的座位列表是已處理預訂產生的結果，當前帳戶餘額是帳戶中的借與貸的結果，而Web伺服器的響應時間圖，是所有已發生Web請求的獨立響應時間的聚合結果。
​ 無論狀態如何變化，總是有一系列事件導致了這些變化。即使事情已經執行與回滾，這些事件出現是始終成立的。關鍵的想法是：可變的狀態與不可變事件的僅追加日誌相互之間並不矛盾：它們是一體兩面，互為陰陽的。所有變化的日誌—— **變化日誌（change log）**，表示了隨時間演變的狀態。
​ 如果你傾向於數學表示，那麼你可能會說，應用狀態是事件流對時間求積分得到的結果，而變更流是狀態對時間求微分的結果，如[圖11-6](../img/fig11-6.png)所示【49,50,51】。這個比喻有一些侷限性（例如，狀態的二階導似乎沒有意義），但這是考慮資料的一個實用出發點。
$$
state(now) = \int_{t=0}^{now}{stream(t) \ dt} \\
stream(t) = \frac{d\ state(t)}{dt}
$$
![](../img/fig11-6.png)
**圖11-6 應用當前狀態與事件流之間的關係**
​ 如果你持久儲存了變更日誌，那麼重現狀態就非常簡單。如果你認為事件日誌是你的記錄系統，而所有的衍生狀態都從它派生而來，那麼系統中的資料流動就容易理解的多。正如帕特·赫蘭（Pat Helland）所說的【52】：
> 事務日誌記錄了資料庫的所有變更。高速追加是更改日誌的唯一方法。從這個角度來看，資料庫的內容其實是日誌中記錄最新值的快取。日誌才是真相，資料庫是日誌子集的快取，這一快取子集恰好來自日誌中每條記錄與索引值的最新值。
​ 日誌壓縮（如“[日誌壓縮](#日誌壓縮)”中所述）是連線日誌與資料庫狀態之間的橋樑：它只保留每條記錄的最新版本，並丟棄被覆蓋的版本。
#### 不可變事件的優點
​ 資料庫中的不變性是一個古老的概念。例如，會計在幾個世紀以來一直在財務記賬中應用不變性。一筆交易發生時，它被記錄在一個僅追加寫入的分類帳中，實質上是描述貨幣，商品或服務轉手的事件日誌。賬目，比如利潤、虧損、資產負債表，是從分類賬中的交易求和衍生而來【53】。
​ 如果發生錯誤，會計師不會刪除或更改分類帳中的錯誤交易 —— 而是新增另一筆交易以補償錯誤，例如退還一比不正確的費用。不正確的交易將永遠保留在分類帳中，對於審計而言可能非常重要。如果從不正確的分類賬衍生出的錯誤數字已經公佈，那麼下一個會計週期的數字就會包括一個更正。這個過程在會計事務中是很常見的【54】。
​ 儘管這種可審計性在金融系統中尤其重要，但對於不受這種嚴格監管的許多其他系統，也是很有幫助的。如“[批處理輸出的哲學](ch10.md#批處理輸出的哲學)”中所討論的，如果你意外地部署了將錯誤資料寫入資料庫的錯誤程式碼，當代碼會破壞性地覆寫資料時，恢復要困難得多。使用不可變事件的僅追加日誌，診斷問題與故障恢復就要容易的多。
​ 不可變的事件也包含了比當前狀態更多的資訊。例如在購物網站上，顧客可以將物品新增到他們的購物車，然後再將其移除。雖然從履行訂單的角度，第二個事件取消了第一個事件，但對分析目的而言，知道客戶考慮過某個特定項而之後又反悔，可能是很有用的。也許他們會選擇在未來購買，或者他們已經找到了替代品。這個資訊被記錄在事件日誌中，但對於移出購物車就刪除記錄的資料庫而言，這個資訊在移出購物車時可能就丟失【42】。
#### 從同一事件日誌中派生多個檢視
​ 此外，透過從不變的事件日誌中分離出可變的狀態，你可以針對不同的讀取方式，從相同的事件日誌中衍生出幾種不同的表現形式。效果就像一個流的多個消費者一樣（[圖11-5](../img/fig11-5.png)）：例如，分析型資料庫Druid使用這種方式直接從Kafka攝取資料【55】，Pistachio是一個分散式的鍵值儲存，使用Kafka作為提交日誌【56】，Kafka Connect能將來自Kafka的資料匯出到各種不同的資料庫與索引【41】。這對於許多其他儲存和索引系統（如搜尋伺服器）來說是很有意義的，當系統要從分散式日誌中獲取輸入時亦然（參閱“[保持系統同步](#保持系統同步)”）。
​ 新增從事件日誌到資料庫的顯式轉換，能夠使應用更容易地隨時間演進：如果你想要引入一個新功能，以新的方式表示現有資料，則可以使用事件日誌來構建一個單獨的，針對新功能的讀取最佳化檢視，無需修改現有系統而與之共存。並行執行新舊系統通常比在現有系統中執行復雜的模式遷移更容易。一旦不再需要舊的系統，你可以簡單地關閉它並回收其資源【47,57】。
​ 如果你不需要擔心如何查詢與訪問資料，那麼儲存資料通常是非常簡單的。模式設計，索引和儲存引擎的許多複雜性，都是希望支援某些特定查詢和訪問模式的結果（參見[第3章](ch3.md)）。出於這個原因，透過將資料寫入的形式與讀取形式相分離，並允許幾個不同的讀取檢視，你能獲得很大的靈活性。這個想法有時被稱為**命令查詢責任分離（command query responsibility segregation, CQRS）**【42,58,59】。
​ 資料庫和模式設計的傳統方法是基於這樣一種謬論，資料必須以與查詢相同的形式寫入。如果可以將資料從針對寫入最佳化的事件日誌轉換為針對讀取最佳化的應用狀態，那麼有關規範化和非規範化的爭論就變得無關緊要了（參閱“[多對一和多對多的關係](ch2.md#多對一和多對多的關係)”）：在針對讀取最佳化的檢視中對資料進行非規範化是完全合理的，因為翻譯過程提供了使其與事件日誌保持一致的機制。
​ 在“[描述負載](ch1.md#描述負載)”中，我們討論了推特主頁時間線，它是特定使用者關注人群所發推特的快取（類似郵箱）。這是**針對讀取最佳化的狀態**的又一個例子：主頁時間線是高度非規範化的，因為你的推文與所有粉絲的時間線都構成了重複。然而，扇出服務保持了這種重複狀態與新推特以及新關注關係的同步，從而保證了重複的可管理性。
#### 併發控制
​ 事件溯源和變更資料捕獲的最大缺點是，事件日誌的消費者通常是非同步的，所以可能會出現這樣的情況：使用者會寫入日誌，然後從日誌衍生檢視中讀取，結果發現他的寫入還沒有反映在讀取檢視中。我們之前在在“[讀己之寫](ch5.md#讀己之寫)”中討論了這個問題以及可能的解決方案。
​ 一種解決方案是將事件附加到日誌時同步執行讀取檢視的更新。而將這些寫入操作合併為一個原子單元需要**事務**，所以要麼將事件日誌和讀取檢視儲存在同一個儲存系統中，要麼就需要跨不同系統進行分散式事務。或者，你也可以使用在“[使用全序廣播實現線性化儲存](ch9.md#使用全序廣播實現線性化儲存)”中討論的方法。
​ 另一方面，從事件日誌匯出當前狀態也簡化了併發控制的某些部分。許多對於多物件事務的需求（參閱“[單物件和多物件操作](ch7.md#單物件和多物件操作)”）源於單個使用者操作需要在多個不同的位置更改資料。透過事件溯源，你可以設計一個自包含的事件以表示一個使用者操作。然後使用者操作就只需要在一個地方進行單次寫入操作 —— 即將事件附加到日誌中 —— 這個還是很容易使原子化的。
​ 如果事件日誌與應用狀態以相同的方式分割槽（例如，處理分割槽3中的客戶事件只需要更新分割槽3中的應用狀態），那麼直接使用單執行緒日誌消費者就不需要寫入併發控制了。它從設計上一次只處理一個事件（參閱“[真的的序列執行](ch7.md#真的的序列執行)”）。日誌透過在分割槽中定義事件的序列順序，消除了併發性的不確定性【24】。如果一個事件觸及多個狀態分割槽，那麼需要做更多的工作，我們將在[第12章](ch12.md)討論。
#### 不變性的限制
​ 許多不使用事件溯源模型的系統也還是依賴不可變性：各種資料庫在內部使用不可變的資料結構或多版本資料來支援時間點快照（參見“[索引和快照隔離](ch7.md#索引和快照隔離)” ）。 Git，Mercurial和Fossil等版本控制系統也依靠不可變的資料來儲存檔案的版本歷史記錄。
​ 永遠保持所有變更的不變歷史，在多大程度上是可行的？答案取決於資料集的流失率。一些工作負載主要是新增資料，很少更新或刪除；它們很容易保持不變。其他工作負載在相對較小的資料集上有較高的更新/刪除率；在這些情況下，不可變的歷史可能增至難以接受的巨大，碎片化可能成為一個問題，壓縮與垃圾收集的表現對於運維的穩健性變得至關重要【60,61】。
​ 除了效能方面的原因外，也可能有出於管理方面的原因需要刪除資料的情況，儘管這些資料都是不可變的。例如，隱私條例可能要求在使用者關閉帳戶後刪除他們的個人資訊，資料保護立法可能要求刪除錯誤的資訊，或者可能需要阻止敏感資訊的意外洩露。
​ 在這種情況下，僅僅在日誌中新增另一個事件來指明先前的資料應該被視為刪除是不夠的 —— 你實際上是想改寫歷史，並假裝資料從一開始就沒有寫入。例如，Datomic管這個特性叫**切除（excision）** 【62】，而Fossil版本控制系統有一個類似的概念叫**避免（shunning）** 【63】。
​ 真正刪除資料是非常非常困難的【64】，因為副本可能存在於很多地方：例如，儲存引擎，檔案系統和SSD通常會向一個新位置寫入，而不是原地覆蓋舊資料【52】，而備份通常是特意做成不可變的，防止意外刪除或損壞。刪除更多的是“使取回資料更困難”，而不是“使取回資料不可能”。無論如何，有時你必須得嘗試，正如我們在“[立法與自律](ch12.md#立法與自律)”中所看到的。
## 流處理
到目前為止，本章中我們已經討論了流的來源（使用者活動事件，感測器和寫入資料庫），我們討論了流如何傳輸（直接透過訊息傳送，透過訊息代理，透過事件日誌）。
剩下的就是討論一下你可以用流做什麼 —— 也就是說，你可以處理它。一般來說，有三種選項：
1. 你可以將事件中的資料寫入資料庫，快取，搜尋索引或類似的儲存系統，然後能被其他客戶端查詢。如[圖11-5](../img/fig11-5.png)所示，這是資料庫與系統其他部分發生變更保持同步的好方法 —— 特別是當流消費者是寫入資料庫的唯一客戶端時。如“[批處理工作流的輸出](ch10.md#批處理工作流的輸出)”中所討論的，它是寫入儲存系統的流等價物。
2. 你能以某種方式將事件推送給使用者，例如傳送報警郵件或推送通知，或將事件流式傳輸到可實時顯示的儀表板上。在這種情況下，人是流的最終消費者。
3. 你可以處理一個或多個輸入流，併產生一個或多個輸出流。流可能會經過由幾個這樣的處理階段組成的流水線，最後再輸出（選項1或2）。
在本章的剩餘部分中，我們將討論選項3：處理流以產生其他衍生流。處理這樣的流的程式碼片段，被稱為**運算元（operator）**或**作業（job）**。它與我們在[第10章](ch10.md)中討論過的Unix程序和MapReduce作業密切相關，資料流的模式是相似的：一個流處理器以只讀的方式使用輸入流，並將其輸出以僅追加的方式寫入一個不同的位置。
​ 流處理中的分割槽和並行化模式也非常類似於[第10章](ch10.md)中介紹的MapReduce和資料流引擎，因此我們不再重複這些主題。基本的Map操作（如轉換和過濾記錄）也是一樣的。
​ 與批次作業相比的一個關鍵區別是，流不會結束。這種差異會帶來很多隱含的結果。正如本章開始部分所討論的，排序對無界資料集沒有意義，因此無法使用**排序合併聯接**（請參閱“[Reduce端連線與分組](ch10.md#減少連線和分組)”）。容錯機制也必須改變：對於已經運行了幾分鐘的批處理作業，可以簡單地從頭開始重啟失敗任務，但是對於已經執行數年的流作業，重啟後從頭開始跑可能並不是一個可行的選項。
### 流處理的應用
長期以來，流處理一直用於監控目的，如果某個事件發生，單位希望能得到警報。例如：
* 欺詐檢測系統需要確定信用卡的使用模式是否有意外地變化，如果信用卡可能已被盜刷，則鎖卡。
* 交易系統需要檢查金融市場的價格變化，並根據指定的規則進行交易。
* 製造系統需要監控工廠中機器的狀態，如果出現故障，可以快速定位問題。
* 軍事和情報系統需要跟蹤潛在侵略者的活動，並在出現襲擊徵兆時發出警報。
這些型別的應用需要非常精密複雜的模式匹配與相關檢測。然而隨著時代的進步，流處理的其他用途也開始出現。在本節中，我們將簡要比較一下這些應用。
#### 複合事件處理
​ **複合事件處理（complex, event processing, CEP）** 是20世紀90年代為分析事件流而開發出的一種方法，尤其適用於需要搜尋某些事件模式的應用【65,66】。與正則表示式允許你在字串中搜索特定字元模式的方式類似，CEP允許你指定規則以在流中搜索某些事件模式。
​ CEP系統通常使用高層次的宣告式查詢語言，比如SQL，或者圖形使用者介面，來描述應該檢測到的事件模式。這些查詢被提交給處理引擎，該引擎消費輸入流，並在內部維護一個執行所需匹配的狀態機。當發現匹配時，引擎發出一個**複合事件（complex event）**（因此得名），並附有檢測到的事件模式詳情【67】。
​ 在這些系統中，查詢和資料之間的關係與普通資料庫相比是顛倒的。通常情況下，資料庫會持久儲存資料，並將查詢視為臨時的：當查詢進入時，資料庫搜尋與查詢匹配的資料，然後在查詢完成時丟掉查詢。 CEP引擎反轉了角色：查詢是長期儲存的，來自輸入流的事件不斷流過它們，搜尋匹配事件模式的查詢【68】。
​ CEP的實現包括Esper 【69】，IBM InfoSphere Streams 【70】，Apama，TIBCO StreamBase和SQLstream。像Samza這樣的分散式流處理元件，支援使用SQL在流上進行宣告式查詢【71】。
#### 流分析
​ 使用流處理的另一個領域是對流進行分析。 CEP與流分析之間的邊界是模糊的，但一般來說，分析往往對找出特定事件序列並不關心，而更關注大量事件上的聚合與統計指標 —— 例如：
* 測量某種型別事件的速率（每個時間間隔內發生的頻率）
* 滾動計算一段時間視窗內某個值的平均值
* 將當前的統計值與先前的時間區間的值對比（例如，檢測趨勢，當指標與上週同比異常偏高或偏低時報警）
這些統計值通常是在固定時間區間內進行計算的，例如，你可能想知道在過去5分鐘內服務每秒查詢次數的均值，以及此時間段內響應時間的第99百分位點。在幾分鐘內取平均，能抹平秒和秒之間的無關波動，且仍然能向你展示流量模式的時間圖景。聚合的時間間隔稱為**視窗（window）**，我們將在“[理解時間](#理解時間)”中更詳細地討論視窗。
​ 流分析系統有時會使用概率演算法，例如Bloom filter（我們在“[效能最佳化](ch3.md#效能最佳化)”中遇到過）來管理成員資格，HyperLogLog 【72】用於基數估計以及各種百分比估計演算法（請參閱“[實踐中的百分位點](ch1.md#實踐中的百分位點)“）。概率演算法產出近似的結果，但比起精確演算法的優點是記憶體使用要少得多。使用近似演算法有時讓人們覺得流處理系統總是有損的和不精確的，但這是錯誤看法：流處理並沒有任何內在的近似性，而概率演算法只是一種最佳化【73】。
​ 許多開源分散式流處理框架的設計都是針對分析設計的：例如Apache Storm，Spark Streaming，Flink，Concord，Samza和Kafka Streams 【74】。託管服務包括Google Cloud Dataflow和Azure Stream Analytics。
#### 維護物化檢視
​ 我們在“[資料庫和資料流](#資料庫和資料流)”中看到，資料庫的變更流可以用於維護衍生資料系統（如快取，搜尋索引和資料倉庫），使其與源資料庫保持最新。我們可以將這些示例視作維護**物化檢視（materialized view）** 的一種具體場景（參閱“[聚合：資料立方體和物化檢視](ch3.md#聚合：資料立方體和物化檢視)”）：在某個資料集上衍生出一個替代檢視以便高效查詢，並在底層資料變更時更新檢視【50】。
​ 同樣，在事件溯源中，應用程式的狀態是透過**應用（apply）**事件日誌來維護的；這裡的應用狀態也是一種物化檢視。與流分析場景不同的是，僅考慮某個時間視窗內的事件通常是不夠的：構建物化檢視可能需要任意時間段內的**所有**事件，除了那些可能由日誌壓縮丟棄的過時事件（請參閱“[日誌壓縮](#日誌壓縮)“）。實際上，你需要一個可以一直延伸到時間開端的視窗。
​ 原則上講，任何流處理元件都可以用於維護物化檢視，儘管“永遠執行”與一些面向分析的框架假設的“主要在有限時間段視窗上執行”背道而馳， Samza和Kafka Streams支援這種用法，建立在Kafka對日誌壓縮comp的支援上【75】。
#### 在流上搜索
​ 除了允許搜尋由多個事件構成模式的CEP外，有時也存在基於複雜標準（例如全文搜尋查詢）來搜尋單個事件的需求。
​ 例如，媒體監測服務可以訂閱新聞文章Feed與來自媒體的播客，搜尋任何關於公司，產品或感興趣的話題的新聞。這是透過預先構建一個搜尋查詢來完成的，然後不斷地將新聞項的流與該查詢進行匹配。在一些網站上也有類似的功能：例如，當市場上出現符合其搜尋條件的新房產時，房地產網站的使用者可以要求網站通知他們。 Elasticsearch的這種過濾器功能，是實現這種流搜尋的一種選擇【76】。
​ 傳統的搜尋引擎首先索引檔案，然後在索引上跑查詢。相比之下，搜尋一個數據流則反了過來：查詢被儲存下來，文件從查詢中流過，就像在CEP中一樣。在簡單的情況就是，你可以為每個文件測試每個查詢。但是如果你有大量查詢，這可能會變慢。為了最佳化這個過程，可以像對文件一樣，為查詢建立索引。因而收窄可能匹配的查詢集合【77】。
#### 訊息傳遞和RPC
​ 在“[訊息傳遞資料流](ch4.md#訊息傳遞資料流)”中我們討論過，訊息傳遞系統可以作為RPC的替代方案，即作為一種服務間通訊的機制，比如在Actor模型中所使用的那樣。儘管這些系統也是基於訊息和事件，但我們通常不會將其視作流處理元件：
* Actor框架主要是管理模組通訊的併發和分散式執行的一種機制，而流處理主要是一種資料管理技術。
* Actor之間的交流往往是短暫的，一對一的；而事件日誌則是持久的，多訂閱者的。
* Actor可以以任意方式進行通訊（允許包括迴圈的請求/響應），但流處理通常配置在無環流水線中，其中每個流都是一個特定作業的輸出，由良好定義的輸入流中派生而來。
也就是說，RPC類系統與流處理之間有一些交叉領域。例如，Apache Storm有一個稱為**分散式RPC**的功能，它允許將使用者查詢分散到一系列也處理事件流的節點上；然後這些查詢與來自輸入流的事件交織，而結果可以被彙總併發回給使用者【78】（另參閱“[多分割槽資料處理](ch12.md#多分割槽資料處理)”）。
​ 也可以使用Actor框架來處理流。但是，很多這樣的框架在崩潰時不能保證訊息的傳遞，除非你實現了額外的重試邏輯，否則這種處理不是容錯的。
### 時間推理
​ 流處理通常需要與時間打交道，尤其是用於分析目的時候，會頻繁使用時間視窗，例如“過去五分鐘的平均值”。“最後五分鐘”的含義看上去似乎是清晰而無歧義的，但不幸的是，這個概念非常棘手。
​ 在批處理中過程中，大量的歷史事件迅速收縮。如果需要按時間來分析，批處理器需要檢查每個事件中嵌入的時間戳。讀取執行批處理機器的系統時鐘沒有任何意義，因為處理執行的時間與事件實際發生的時間無關。
​ 批處理可以在幾分鐘內讀取一年的歷史事件；在大多數情況下，感興趣的時間線是歷史中的一年，而不是處理中的幾分鐘。而且使用事件中的時間戳，使得處理是**確定性**的：在相同的輸入上再次執行相同的處理過程會得到相同的結果（參閱“[故障容錯](ch10.md#故障容錯)”）。
​ 另一方面，許多流處理框架使用處理機器上的本地系統時鐘（**處理時間（processing time）**）來確定**視窗**【79】。這種方法的優點是簡單，事件建立與事件處理之間的延遲可以忽略不計。然而，如果存在任何顯著的處理延遲 —— 即，事件處理顯著地晚於事件實際發生的時間，處理就失效了。
#### 事件時間與處理時間
​ 很多原因都可能導致處理延遲：排隊，網路故障（參閱“[不可靠的網路](ch8.md#不可靠的網路)”），效能問題導致訊息代理/訊息處理器出現爭用，流消費者重啟，重新處理過去的事件（參閱“[重放舊訊息](#重放舊訊息)”），或者在修復程式碼BUG之後從故障中恢復。
​ 而且，訊息延遲還可能導致無法預測訊息順序。例如，假設使用者首先發出一個Web請求（由Web伺服器A處理），然後發出第二個請求（由伺服器B處理）。 A和B發出描述它們所處理請求的事件，但是B的事件在A的事件發生之前到達訊息代理。現在，流處理器將首先看到B事件，然後看到A事件，即使它們實際上是以相反的順序發生的。
​ 有一個類比也許能幫助理解，“星球大戰”電影：第四集於1977年發行，第五集於1980年，第六集於1983年，緊隨其後的是1999年的第一集，2002年的第二集，和2005年的三集，以及2015年的第七集【80】[^ii]。如果你按照按照它們上映的順序觀看電影，你處理電影的順序與它們敘事的順序就是不一致的。 （集數編號就像事件時間戳，而你觀看電影的日期就是處理時間）作為人類，我們能夠應對這種不連續性，但是流處理演算法需要專門編寫，以適應這種時機與順序的問題。
[^ii]: 感謝Flink社群的Kostas Kloudas提出這個比喻。
​ 將事件時間和處理時間搞混會導致錯誤的資料。例如，假設你有一個流處理器用於測量請求速率（計算每秒請求數）。如果你重新部署流處理器，它可能會停止一分鐘，並在恢復之後處理積壓的事件。如果你按處理時間來衡量速率，那麼在處理積壓日誌時，請求速率看上去就像有一個異常的突發尖峰，而實際上請求速率是穩定的（[圖11-7](../img/fig11-7.png)）。
![](../img/fig11-7.png)
**圖11-7 按處理時間分窗，會因為處理速率的變動引入人為因素**
#### 知道什麼時候準備好了
​ 用事件時間來定義視窗的一個棘手的問題是，你永遠也無法確定是不是已經收到了特定視窗的所有事件，還是說還有一些事件正在來的路上。
​ 例如，假設你將事件分組為一分鐘的視窗，以便統計每分鐘的請求數。你已經計數了一些帶有本小時內第37分鐘時間戳的事件，時間流逝，現在進入的主要都是本小時內第38和第39分鐘的事件。什麼時候才能宣佈你已經完成了第37分鐘的視窗計數，並輸出其計數器值？
​ 在一段時間沒有看到任何新的事件之後，你可以超時並宣佈一個視窗已經就緒，但仍然可能發生這種情況：某些事件被緩衝在另一臺機器上，由於網路中斷而延遲。你需要能夠處理這種在視窗宣告完成之後到達的 **滯留（straggler）** 事件。大體上，你有兩種選擇【1】：
1. 忽略這些滯留事件，因為在正常情況下它們可能只是事件中的一小部分。你可以將丟棄事件的數量作為一個監控指標，並在出現大量丟訊息的情況時報警。
2. 釋出一個**更正（correction）**，一個包括滯留事件的更新視窗值。更新的視窗與包含散兵隊員的價值。你可能還需要收回以前的輸出。
在某些情況下，可以使用特殊的訊息來指示“從現在開始，不會有比t更早時間戳的訊息了”，消費者可以使用它來觸發視窗【81】。但是，如果不同機器上的多個生產者都在生成事件，每個生產者都有自己的最小時間戳閾值，則消費者需要分別跟蹤每個生產者。在這種情況下，新增和刪除生產者都是比較棘手的。
#### 你用的是誰的時鐘？
​ 當事件可能在系統內多個地方進行緩衝時，為事件分配時間戳更加困難了。例如，考慮一個移動應用向伺服器上報關於用量的事件。該應用可能會在裝置處於離線狀態時被使用，在這種情況下，它將在裝置本地緩衝事件，並在下一次網際網路連線可用時向伺服器上報這些事件（可能是幾小時甚至幾天）。對於這個流的任意消費者而言，它們就如延遲極大的滯留事件一樣。
​ 在這種情況下，事件上的事件戳實際上應當是使用者交互發生的時間，取決於移動裝置的本地時鐘。然而使用者控制的裝置上的時鐘通常是不可信的，因為它可能會被無意或故意設定成錯誤的時間（參見“[時鐘同步與準確性](ch8.md#時鐘同步與準確性)”）。伺服器收到事件的時間（取決於伺服器的時鐘）可能是更準確的，因為伺服器在你的控制之下，但在描述使用者互動方面意義不大。
要校正不正確的裝置時鐘，一種方法是記錄三個時間戳【82】：
* 事件發生的時間，取決於裝置時鐘
* 事件傳送往伺服器的時間，取決於裝置時鐘
* 事件被伺服器接收的時間，取決於伺服器時鐘
透過從第三個時間戳中減去第二個時間戳，可以估算裝置時鐘和伺服器時鐘之間的偏移（假設網路延遲與所需的時間戳精度相比可忽略不計）。然後可以將該偏移應用於事件時間戳，從而估計事件實際發生的真實時間（假設裝置時鐘偏移在事件發生時與送往伺服器之間沒有變化）。
​ 這並不是流處理獨有的問題，批處理有著完全一樣的時間推理問題。只是在流處理的上下文中，我們更容易意識到時間的流逝。
#### 視窗的型別
​ 當你知道如何確定一個事件的時間戳後，下一步就是如何定義時間段的視窗。然後視窗就可以用於聚合，例如事件計數，或計算視窗內值的平均值。有幾種視窗很常用【79,83】：
***滾動視窗（Tumbling Window）***
​ 滾動視窗有著固定的長度，每個事件都僅能屬於一個視窗。例如，假設你有一個1分鐘的滾動視窗，則所有時間戳在`10:03:00`和`10:03:59`之間的事件會被分組到一個視窗中，`10:04:00`和`10:04:59`之間的事件被分組到下一個視窗，依此類推。透過將每個事件時間戳四捨五入至最近的分鐘來確定它所屬的視窗，可以實現1分鐘的滾動視窗。
***跳動視窗（Hopping Window）***
​ 跳動視窗也有著固定的長度，但允許視窗重疊以提供一些平滑。例如，一個帶有1分鐘跳躍步長的5分鐘視窗將包含`10:03:00`至`10:07:59`之間的事件，而下一個視窗將覆蓋`10:04:00`至`10:08:59`之間的事件，等等。透過首先計算1分鐘的滾動視窗，然後在幾個相鄰視窗上進行聚合，可以實現這種跳動視窗。
***滑動視窗（Sliding Window）***
​ 滑動視窗包含了彼此間距在特定時長內的所有事件。例如，一個5分鐘的滑動視窗應當覆蓋`10:03:39`和`10:08:12`的事件，因為它們相距不超過5分鐘（注意滾動視窗與步長5分鐘的跳動視窗可能不會把這兩個事件分組到同一個視窗中，因為它們使用固定的邊界）。透過維護一個按時間排序的事件緩衝區，並不斷從視窗中移除過期的舊事件，可以實現滑動視窗。
***會話視窗（Session window）***
​ 與其他視窗型別不同，會話視窗沒有固定的持續時間，而定義為：將同一使用者出現時間相近的所有事件分組在一起，而當用戶一段時間沒有活動時（例如，如果30分鐘內沒有事件）視窗結束。會話切分是網站分析的常見需求（參閱“[GROUP BY](ch10.md#GROUP\ BY)”）。
### 流式連線
​ 在[第10章](ch10.md)中，我們討論了批處理作業如何透過鍵來連線資料集，以及這種連線是如何成為資料管道的重要組成部分的。由於流處理將資料管道泛化為對無限資料集進行增量處理，因此對流進行連線的需求也是完全相同的。
​ 然而，新事件隨時可能出現在一個流中，這使得流連線要比批處理連線更具挑戰性。為了更好地理解情況，讓我們先來區分三種不同型別的連線：**流-流**連線，**流-表**連線，與**表-表**連線【84】。我們將在下面的章節中透過例子來說明。
#### 流流連線（視窗連線）
​ 假設你的網站上有搜尋功能，而你想要找出搜尋URL的近期趨勢。每當有人鍵入搜尋查詢時，都會記錄下一個包含查詢與其返回結果的事件。每當有人點選其中一個搜尋結果時，就會記錄另一個記錄點選事件。為了計算搜尋結果中每個URL的點選率，你需要將搜尋動作與點選動作的事件連在一起，這些事件透過相同的會話ID進行連線。廣告系統中需要類似的分析【85】。
​ 如果使用者丟棄了搜尋結果，點選可能永遠不會發生，即使它出現了，搜尋與點選之間的時間可能是高度可變的：在很多情況下，它可能是幾秒鐘，但也可能長達幾天或幾周（如果使用者執行搜尋，忘掉了這個瀏覽器頁面，過了一段時間後重新回到這個瀏覽器頁面上，並點選了一個結果）。由於可變的網路延遲，點選事件甚至可能先於搜尋事件到達。你可以選擇合適的連線視窗 —— 例如，如果點選與搜尋之間的時間間隔在一小時內，你可能會選擇連線兩者。
​ 請注意，在點選事件中嵌入搜尋詳情與事件連線並不一樣：這樣做的話，只有當用戶點選了一個搜尋結果時你才能知道，而那些沒有點選的搜尋就無能為力了。為了衡量搜尋質量，你需要準確的點選率，為此搜尋事件和點選事件兩者都是必要的。
​ 為了實現這種型別的連線，流處理器需要維護**狀態**：例如，按會話ID索引最近一小時內發生的所有事件。無論何時發生搜尋事件或點選事件，都會被新增到合適的索引中，而流處理器也會檢查另一個索引是否有具有相同會話ID的事件到達。如果有匹配事件就會發出一個表示搜尋結果被點選的事件；如果搜尋事件直到過期都沒看見有匹配的點選事件，就會發出一個表示搜尋結果未被點選的事件。
#### 流表連線（流擴充套件）
​ 在“[示例：使用者活動事件分析](ch10.md#示例：使用者活動事件分析)”（[圖10-2](../img/fig10-2.png)）中，我們看到了連線兩個資料集的批處理作業示例：一組使用者活動事件和一個使用者檔案資料庫。將使用者活動事件視為流，並在流處理器中連續執行相同的連線是很自然的想法：輸入是包含使用者ID的活動事件流，而輸出還是活動事件流，但其中使用者ID已經被擴充套件為使用者的檔案資訊。這個過程有時被稱為 使用資料庫的資訊來**擴充（enriching）** 活動事件。
​ 要執行此聯接，流處理器需要一次處理一個活動事件，在資料庫中查詢事件的使用者ID，並將檔案資訊新增到活動事件中。資料庫查詢可以透過查詢遠端資料庫來實現。但正如在“[示例：分析使用者活動事件](ch10.md#示例：分析使用者活動事件)”一節中討論的，此類遠端查詢可能會很慢，並且有可能導致資料庫過載【75】。
​ 另一種方法是將資料庫副本載入到流處理器中，以便在本地進行查詢而無需網路往返。這種技術與我們在“[Map端連線](ch10.md#Map端連線)”中討論的雜湊連線非常相似：如果資料庫的本地副本足夠小，則可以是記憶體中的散列表，比較大的話也可以是本地磁碟上的索引。
​ 與批處理作業的區別在於，批處理作業使用資料庫的時間點快照作為輸入，而流處理器是長時間執行的，且資料庫的內容可能隨時間而改變，所以流處理器資料庫的本地副本需要保持更新。這個問題可以透過變更資料捕獲來解決：流處理器可以訂閱使用者檔案資料庫的更新日誌，如同活躍事件流一樣。當增添或修改檔案時，流處理器會更新其本地副本。因此，我們有了兩個流之間的連線：活動事件和檔案更新。
​ 流表連線實際上非常類似於流流連線；最大的區別在於對於表的變更日誌流，連線使用了一個可以回溯到“時間起點”的視窗（概念上是無限的視窗），新版本的記錄會覆蓋更早的版本。對於輸入的流，連線可能壓根兒就沒有維護視窗。
#### 表表連線（維護物化檢視）
​ 我們在“[描述負載](ch1.md#描述負載)”中討論的推特時間線例子時說過，當用戶想要檢視他們的主頁時間線時，迭代使用者所關注人群的推文併合並它們是一個開銷巨大的操作。
​ 相反，我們需要一個時間線快取：一種每個使用者的“收件箱”，在傳送推文的時候寫入這些資訊，因而讀取時間線時只需要簡單地查詢即可。物化與維護這個快取需要處理以下事件：
* 當用戶u傳送新的推文時，它將被新增到每個關注使用者u的時間線上。
* 使用者刪除推文時，推文將從所有使用者的時間表中刪除。
* 當用戶$u_1$開始關注使用者$u_2$時，$u_2$最近的推文將被新增到$u_1$的時間線上。
* 當用戶$u_1$取消關注使用者$u_2$時，$u_2$的推文將從$u_1$的時間線中移除。
要在流處理器中實現這種快取維護，你需要推文事件流（傳送與刪除）和關注關係事件流（關注與取消關注）。流處理需要為維護一個數據庫，包含每個使用者的粉絲集合。以便知道當一條新推文到達時，需要更新哪些時間線【86】。
觀察這個流處理過程的另一種視角是：它維護了一個連線了兩個表（推文與關注）的物化檢視，如下所示：
```sql
SELECT follows.follower_id AS timeline_id,
array_agg(tweets.* ORDER BY tweets.timestamp DESC)
FROM tweets
JOIN follows ON follows.followee_id = tweets.sender_id
GROUP BY follows.follower_id
```
​ 流連線直接對應於這個查詢中的表連線。時間線實際上是這個查詢結果的快取，每當基礎表發生變化時都會更新[^iii]。
[^iii]: 如果你將流視作表的衍生物，如[圖11-6](../img/fig11-6.png)所示，而把一個連線看作是兩個表的乘法u·v，那麼會發生一些有趣的事情：物化連線的變化流遵循乘積法則：(u·v)'= u'v + uv'(u·v)'= u'v + uv'。 換句話說，任何推文的變化量都與當前的關注聯絡在一起，任何關注的變化量都與當前的推文相連線【49,50】。
#### 連線的時間依賴性
​ 這裡描述的三種連線（流流，流表，表表）有很多共通之處：它們都需要流處理器維護連線一側的一些狀態（搜尋與點選事件，使用者檔案，關注列表），然後當連線另一側的訊息到達時查詢該狀態。
​ 用於維護狀態的事件順序是很重要的（先關注然後取消關注，或者其他類似操作）。在分割槽日誌中，單個分割槽內的事件順序是保留下來的。但典型情況下是沒有跨流或跨分割槽的順序保證的。
​ 這就產生了一個問題：如果不同流中的事件發生在近似的時間範圍內，則應該按照什麼樣的順序進行處理？在流表連線的例子中，如果使用者更新了它們的檔案，哪些活動事件與舊檔案連線（在檔案更新前處理），哪些又與新檔案連線（在檔案更新之後處理）？換句話說：你需要對一些狀態做連線，如果狀態會隨著時間推移而變化，那應當使用什麼時間點來連線呢【45】？
​ 這種時序依賴可能出現在很多地方。例如銷售東西需要對發票應用適當的稅率，這取決於所處的國家/州，產品型別，銷售日期（因為稅率會隨時變化）。當連線銷售額與稅率表時，你可能期望的是使用銷售時的稅率參與連線。如果你正在重新處理歷史資料，銷售時的稅率可能和現在的稅率有所不同。
​ 如果跨越流的事件順序是未定的，則連線會變為不確定性的【87】，這意味著你在同樣輸入上重跑相同的作業未必會得到相同的結果：當你重跑任務時，輸入流上的事件可能會以不同的方式交織。
​ 在資料倉庫中，這個問題被稱為**緩慢變化的維度（slowly changing dimension, SCD）**，通常透過對特定版本的記錄使用唯一的識別符號來解決：例如，每當稅率改變時都會獲得一個新的識別符號，而發票在銷售時會帶有稅率的識別符號【88,89】。這種變化使連線變為確定性的，但也會導致日誌壓縮無法進行：表中所有的記錄版本都需要保留。
### 容錯
​ 在本章的最後一節中，讓我們看一看流處理是如何容錯的。我們在[第10章](ch10.md)中看到，批處理框架可以很容易地容錯：如果MapReduce作業中的任務失敗，可以簡單地在另一臺機器上再次啟動，並且丟棄失敗任務的輸出。這種透明的重試是可能的，因為輸入檔案是不可變的，每個任務都將其輸出寫入到HDFS上的獨立檔案中，而輸出僅當任務成功完成後可見。
​ 特別是，批處理容錯方法可確保批處理作業的輸出與沒有出錯的情況相同，即使實際上某些任務失敗了。看起來好像每條輸入記錄都被處理了恰好一次 —— 沒有記錄被跳過，而且沒有記錄被處理兩次。儘管重啟任務意味著實際上可能會多次處理記錄，但輸出中的可見效果看上去就像只處理過一次。這個原則被稱為**恰好一次語義（exactly-once semantics）**，儘管**有效一次（effectively-once）** 可能會是一個更寫實的術語【90】。
​ 在流處理中也出現了同樣的容錯問題，但是處理起來沒有那麼直觀：等待某個任務完成之後再使其輸出可見並不是一個可行選項，因為你永遠無法處理完一個無限的流。
#### 微批次與存檔點
​ 一個解決方案是將流分解成小塊，並像微型批處理一樣處理每個塊。這種方法被稱為**微批次（microbatching）**，它被用於Spark Streaming 【91】。批次的大小通常約為1秒，這是對效能妥協的結果：較小的批次會導致更大的排程與協調開銷，而較大的批次意味著流處理器結果可見之前的延遲要更長。
​ 微批次也隱式提供了一個與批次大小相等的滾動視窗（按處理時間而不是事件時間戳分窗）。任何需要更大視窗的作業都需要顯式地將狀態從一個微批次轉移到下一個微批次。
​ Apache Flink則使用不同的方法，它會定期生成狀態的滾動存檔點並將其寫入持久儲存【92,93】。如果流運算元崩潰，它可以從最近的存檔點重啟，並丟棄從最近檢查點到崩潰之間的所有輸出。存檔點會由訊息流中的 **壁障（barrier）** 觸發，類似於微批次之間的邊界，但不會強制一個特定的視窗大小。
​ 在流處理框架的範圍內，微批次與存檔點方法提供了與批處理一樣的**恰好一次語義**。但是，只要輸出離開流處理器（例如，寫入資料庫，向外部訊息代理髮送訊息，或傳送電子郵件），框架就無法拋棄失敗批次的輸出了。在這種情況下，重啟失敗任務會導致外部副作用發生兩次，只有微批次或存檔點不足以阻止這一問題。
#### 原子提交再現
​ 為了在出現故障時表現出恰好處理一次的樣子，我們需要確保事件處理的所有輸出和副作用**當且僅當**處理成功時才會生效。這些影響包括髮送給下游運算元或外部訊息傳遞系統（包括電子郵件或推送通知）的任何訊息，任何資料庫寫入，對運算元狀態的任何變更，以及對輸入訊息的任何確認（包括在基於日誌的訊息代理中將消費者偏移量前移）。
​ 這些事情要麼都原子地發生，要麼都不發生，但是它們不應當失去同步。如果這種方法聽起來很熟悉，那是因為我們在分散式事務和兩階段提交的上下文中討論過它（參閱“[恰好一次的訊息處理](ch9.md#恰好一次的訊息處理)”）。
​ 在[第9章](ch9.md)中，我們討論了分散式事務傳統實現中的問題（如XA）。然而在限制更為嚴苛的環境中，也是有可能高效實現這種原子提交機制的。 Google Cloud Dataflow【81,92】和VoltDB 【94】中使用了這種方法，Apache Kafka有計劃加入類似的功能【95,96】。與XA不同，這些實現不會嘗試跨異構技術提供事務，而是透過在流處理框架中同時管理狀態變更與訊息傳遞來內化事務。事務協議的開銷可以透過在單個事務中處理多個輸入訊息來分攤。
#### 冪等性
​ 我們的目標是丟棄任何失敗任務的部分輸出，以便能安全地重試，而不會生效兩次。分散式事務是實現這個目標的一種方式，而另一種方式是依賴**冪等性（idempotence）**【97】。
​ 冪等操作是多次重複執行與單次執行效果相同的操作。例如，將鍵值儲存中的某個鍵設定為某個特定值是冪等的（再次寫入該值，只是用同樣的值替代），而遞增一個計數器不是冪等的（再次執行遞增意味著該值遞增兩次）。
​ 即使一個操作不是天生冪等的，往往可以透過一些額外的元資料做成冪等的。例如，在使用來自Kafka的訊息時，每條訊息都有一個持久的，單調遞增的偏移量。將值寫入外部資料庫時可以將這個偏移量帶上，這樣你就可以判斷一條更新是不是已經執行過了，因而避免重複執行。
​ Storm的Trident基於類似的想法來處理狀態【78】。依賴冪等性意味著隱含了一些假設：重啟一個失敗的任務必須以相同的順序重放相同的訊息（基於日誌的訊息代理能做這些事），處理必須是確定性的，沒有其他節點能同時更新相同的值【98,99】。
​ 當從一個處理節點故障切換到另一個節點時，可能需要進行**防護（fencing）**（參閱“[領導和鎖](ch8.md#領導和鎖)”），以防止被假死節點干擾。儘管有這麼多注意事項，冪等操作是一種實現**恰好一次語義**的有效方式，僅需很小的額外開銷。
#### 失敗後重建狀態
​ 任何需要狀態的流處理 —— 例如，任何視窗聚合（例如計數器，平均值和直方圖）以及任何用於連線的表和索引，都必須確保在失敗之後能恢復其狀態。
​ 一種選擇是將狀態儲存在遠端資料儲存中，並進行復制，然而正如在“[流表連線](#流表連線)”中所述，每個訊息都要查詢遠端資料庫可能會很慢。另一種方法是在流處理器本地儲存狀態，並定期複製。然後當流處理器從故障中恢復時，新任務可以讀取狀態副本，恢復處理而不丟失資料。
​ 例如，Flink定期捕獲運算元狀態的快照，並將它們寫入HDFS等持久儲存中【92,93】。 Samza和Kafka Streams透過將狀態變更傳送到具有日誌壓縮功能的專用Kafka主題來複制狀態變更，這與變更資料捕獲類似【84,100】。 VoltDB透過在多個節點上對每個輸入訊息進行冗餘處理來複制狀態（參閱“[真的序列執行](ch7.md#真的序列執行)”）。
​ 在某些情況下，甚至可能都不需要複製狀態，因為它可以從輸入流重建。例如，如果狀態是從相當短的視窗中聚合而成，則簡單地重放該視窗中的輸入事件可能是足夠快的。如果狀態是透過變更資料捕獲來維護的資料庫的本地副本，那麼也可以從日誌壓縮的變更流中重建資料庫（參閱“[日誌壓縮](#日誌壓縮)”）。
​ 然而，所有這些權衡取決於底層基礎架構的效能特徵：在某些系統中，網路延遲可能低於磁碟訪問延遲，網路頻寬可能與磁碟頻寬相當。沒有針對所有情況的普世理想權衡，隨著儲存和網路技術的發展，本地狀態與遠端狀態的優點也可能會互換。
## 本章小結
​ 在本章中，我們討論了事件流，它們所服務的目的，以及如何處理它們。在某些方面，流處理非常類似於在[第10章](ch10.md) 中討論的批處理，不過是在無限的（永無止境的）流而不是固定大小的輸入上持續進行。從這個角度來看，訊息代理和事件日誌可以視作檔案系統的流式等價物。
我們花了一些時間比較兩種訊息代理：
***AMQP/JMS風格的訊息代理***
​ 代理將單條訊息分配給消費者，消費者在成功處理單條訊息後確認訊息。訊息被確認後從代理中刪除。這種方法適合作為一種非同步形式的RPC（另請參閱“[訊息傳遞資料流](ch4.md#訊息傳遞資料流)”），例如在任務佇列中，訊息處理的確切順序並不重要，而且訊息在處理完之後，不需要回頭重新讀取舊訊息。
***基於日誌的訊息代理***
​ 代理將一個分割槽中的所有訊息分配給同一個消費者節點，並始終以相同的順序傳遞訊息。並行是透過分割槽實現的，消費者透過存檔最近處理訊息的偏移量來跟蹤工作進度。訊息代理將訊息保留在磁碟上，因此如有必要的話，可以回跳並重新讀取舊訊息。
​ 基於日誌的方法與資料庫中的複製日誌（參見[第5章](ch5.md)）和日誌結構儲存引擎（請參閱[第3章](ch3.md)）有相似之處。我們看到，這種方法對於消費輸入流，產生衍生狀態與衍生輸出資料流的系統而言特別適用。
​ 就流的來源而言，我們討論了幾種可能性：使用者活動事件，定期讀數的感測器，和Feed資料（例如，金融中的市場資料）能夠自然地表示為流。我們發現將資料庫寫入視作流也是很有用的：我們可以捕獲變更日誌 —— 即對資料庫所做的所有變更的歷史記錄 —— 隱式地透過變更資料捕獲，或顯式地透過事件溯源。日誌壓縮允許流也能保有資料庫內容的完整副本。
​ 將資料庫表示為流為系統整合帶來了很多強大機遇。透過消費變更日誌並將其應用至衍生系統，你能使諸如搜尋索引，快取，以及分析系統這類衍生資料系統不斷保持更新。你甚至能從頭開始，透過讀取從創世至今的所有變更日誌，為現有資料建立全新的檢視。
​ 像流一樣維護狀態，以及訊息重放的基礎設施，是在各種流處理框架中實現流連線和容錯的基礎。我們討論了流處理的幾種目的，包括搜尋事件模式（複雜事件處理），計算分窗聚合（流分析），以及保證衍生資料系統處於最新狀態（物化檢視）。
​ 然後我們討論了在流處理中對時間進行推理的困難，包括處理時間與事件時間戳之間的區別，以及當你認為視窗已經完事之後，如何處理到達的掉隊事件的問題。
​ 我們區分了流處理中可能出現的三種連線型別：
***流流連線***
​ 兩個輸入流都由活動事件組成，而連線運算元在某個時間視窗內搜尋相關的事件。例如，它可能會將同一個使用者30分鐘內進行的兩個活動聯絡在一起。如果你想要找出一個流內的相關事件，連線的兩側輸入可能實際上都是同一個流（**自連線（self-join）**）。
***流表連線***
​ 一個輸入流由活動事件組成，另一個輸入流是資料庫變更日誌。變更日誌保證了資料庫的本地副本是最新的。對於每個活動事件，連線運算元將查詢資料庫，並輸出一個擴充套件的活動事件。
***表表連線***
​ 兩個輸入流都是資料庫變更日誌。在這種情況下，一側的每一個變化都與另一側的最新狀態相連線。結果是兩表連線所得物化檢視的變更流。
最後，我們討論了在流處理中實現容錯和恰好一次語義的技術。與批處理一樣，我們需要放棄任何部分失敗任務的輸出。然而由於流處理長時間執行並持續產生輸出，所以不能簡單地丟棄所有的輸出。相反，可以使用更細粒度的恢復機制，基於微批次，存檔點，事務，或冪等寫入。
## 參考文獻
1. Tyler Akidau, Robert Bradshaw, Craig Chambers, et al.: “[The Dataflow Model: A Practical Approach to Balancing Correctness, Latency, and Cost in Massive-Scale, Unbounded, Out-of-Order Data Processing](http://www.vldb.org/pvldb/vol8/p1792-Akidau.pdf),”
*Proceedings of the VLDB Endowment*, volume 8, number 12, pages 1792–1803, August 2015. [doi:10.14778/2824032.2824076](http://dx.doi.org/10.14778/2824032.2824076)
1. Harold Abelson, Gerald Jay Sussman, and Julie Sussman: <a href="https://mitpress.mit.edu/sicp/">*Structure and Interpretation of Computer Programs*</a>, 2nd edition. MIT Press, 1996. ISBN: 978-0-262-51087-5, available online at *mitpress.mit.edu*
1. Patrick Th. Eugster, Pascal A. Felber, Rachid Guerraoui, and Anne-Marie Kermarrec: “[The Many Faces of Publish/Subscribe](http://www.cs.ru.nl/~pieter/oss/manyfaces.pdf),” *ACM Computing Surveys*, volume 35, number 2, pages 114–131, June 2003.
[doi:10.1145/857076.857078](http://dx.doi.org/10.1145/857076.857078)
1. Joseph M. Hellerstein and Michael Stonebraker: <a href="http://redbook.cs.berkeley.edu/">*Readings in Database Systems*</a>, 4th edition. MIT Press, 2005. ISBN: 978-0-262-69314-1, available online at *redbook.cs.berkeley.edu*
1. Don Carney, Uğur Çetintemel, Mitch Cherniack, et al.: “[Monitoring Streams – A New Class of Data Management Applications](http://www.vldb.org/conf/2002/S07P02.pdf),” at *28th International Conference on Very Large Data Bases* (VLDB), August 2002.
1. Matthew Sackman: “[Pushing Back](http://www.lshift.net/blog/2016/05/05/pushing-back/),” *lshift.net*, May 5, 2016. Vicent Martí: “[Brubeck, a statsd-Compatible Metrics Aggregator](http://githubengineering.com/brubeck/),” *githubengineering.com*, June 15, 2015. Seth Lowenberger: “[MoldUDP64 Protocol Specification V 1.00](http://www.nasdaqtrader.com/content/technicalsupport/specifications/dataproducts/moldudp64.pdf),” *nasdaqtrader.com*, July 2009.
1. Pieter Hintjens: <a href="http://zguide.zeromq.org/page:all">*ZeroMQ – The Guide*</a>. O'Reilly Media, 2013. ISBN: 978-1-449-33404-8
1. Ian Malpass: “[Measure Anything, Measure Everything](https://codeascraft.com/2011/02/15/measure-anything-measure-everything/),” *codeascraft.com*, February 15, 2011.
1. Dieter Plaetinck: “[25 Graphite, Grafana and statsd Gotchas](https://blog.raintank.io/25-graphite-grafana-and-statsd-gotchas/),” *blog.raintank.io*, March 3, 2016.
1. Jeff Lindsay: “[Web Hooks to Revolutionize the Web](http://progrium.com/blog/2007/05/03/web-hooks-to-revolutionize-the-web/),” *progrium.com*, May 3, 2007.
1. Jim N. Gray: “[Queues Are Databases](http://research.microsoft.com/pubs/69641/tr-95-56.pdf),” Microsoft Research Technical Report MSR-TR-95-56, December 1995.
1. Mark Hapner, Rich Burridge, Rahul Sharma, et al.: “[JSR-343 Java Message Service (JMS) 2.0 Specification](https://jcp.org/en/jsr/detail?id=343),” *jms-spec.java.net*, March 2013.
1. Sanjay Aiyagari, Matthew Arrott, Mark Atwell, et al.: “[AMQP: Advanced Message Queuing Protocol Specification](http://www.rabbitmq.com/resources/specs/amqp0-9-1.pdf),” Version 0-9-1, November 2008.
1. “[Google Cloud Pub/Sub: A Google-Scale Messaging Service](https://cloud.google.com/pubsub/architecture),” *cloud.google.com*, 2016.
1. “[Apache Kafka 0.9 Documentation](http://kafka.apache.org/documentation.html),” *kafka.apache.org*, November 2015.
1. Jay Kreps, Neha Narkhede, and Jun Rao: “[Kafka: A Distributed Messaging System for Log Processing](http://www.longyu23.com/doc/Kafka.pdf),” at *6th International Workshop on Networking Meets Databases* (NetDB), June 2011.
1. “[Amazon Kinesis Streams Developer Guide](http://docs.aws.amazon.com/streams/latest/dev/introduction.html),” *docs.aws.amazon.com*, April 2016.
1. Leigh Stewart and Sijie Guo: “[Building DistributedLog: Twitter’s High-Performance Replicated Log Service](https://blog.twitter.com/2015/building-distributedlog-twitter-s-high-performance-replicated-log-service),” *blog.twitter.com*, September 16, 2015.
1. “[DistributedLog Documentation](http://distributedlog.incubator.apache.org/docs/latest/),” Twitter, Inc., *distributedlog.io*, May 2016. Jay Kreps:
“[Benchmarking Apache Kafka: 2 Million Writes Per Second (On Three Cheap Machines)](https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines),” *engineering.linkedin.com*, April 27, 2014.
1. Kartik Paramasivam: “[How We’re Improving and Advancing Kafka at LinkedIn](https://engineering.linkedin.com/apache-kafka/how-we_re-improving-and-advancing-kafka-linkedin),” *engineering.linkedin.com*, September 2, 2015.
1. Jay Kreps: “[The Log: What Every Software Engineer Should Know About Real-Time Data's Unifying Abstraction](http://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying),” *engineering.linkedin.com*, December 16, 2013.
1. Shirshanka Das, Chavdar Botev, Kapil Surlaker, et al.: “[All Aboard the Databus!](http://www.socc2012.org/s18-das.pdf),” at *3rd ACM Symposium on Cloud Computing* (SoCC), October 2012.
1. Yogeshwer Sharma, Philippe Ajoux, Petchean Ang, et al.: “[Wormhole: Reliable Pub-Sub to Support Geo-Replicated Internet Services](https://www.usenix.org/system/files/conference/nsdi15/nsdi15-paper-sharma.pdf),” at *12th USENIX Symposium on Networked Systems Design and Implementation* (NSDI), May 2015.
1. P. P. S. Narayan: “[Sherpa Update](http://web.archive.org/web/20160801221400/https://developer.yahoo.com/blogs/ydn/sherpa-7992.html),” *developer.yahoo.com*, June 8, .
1. Martin Kleppmann: “[Bottled Water: Real-Time Integration of PostgreSQL and Kafka](http://martin.kleppmann.com/2015/04/23/bottled-water-real-time-postgresql-kafka.html),” *martin.kleppmann.com*, April 23, 2015.
1. Ben Osheroff: “[Introducing Maxwell, a mysql-to-kafka Binlog Processor](https://developer.zendesk.com/blog/introducing-maxwell-a-mysql-to-kafka-binlog-processor),” *developer.zendesk.com*, August 20, 2015.
1. Randall Hauch: “[Debezium 0.2.1 Released](http://debezium.io/blog/2016/06/10/Debezium-0/),” *debezium.io*, June 10, 2016.
1. Prem Santosh Udaya Shankar: “[Streaming MySQL Tables in Real-Time to Kafka](https://engineeringblog.yelp.com/2016/08/streaming-mysql-tables-in-real-time-to-kafka.html),” *engineeringblog.yelp.com*, August 1, 2016.
1. “[Mongoriver](https://github.com/stripe/mongoriver),” Stripe, Inc., *github.com*, September 2014.
1. Dan Harvey: “[Change Data Capture with Mongo + Kafka](http://www.slideshare.net/danharvey/change-data-capture-with-mongodb-and-kafka),” at *Hadoop Users Group UK*, August 2015.
1. “[Oracle GoldenGate 12c: Real-Time Access to Real-Time Information](http://www.oracle.com/us/products/middleware/data-integration/oracle-goldengate-realtime-access-2031152.pdf),” Oracle White Paper, March 2015.
1. “[Oracle GoldenGate Fundamentals: How Oracle GoldenGate Works](https://www.youtube.com/watch?v=6H9NibIiPQE),” Oracle Corporation, *youtube.com*, November 2012.
1. Slava Akhmechet: “[Advancing the Realtime Web](http://rethinkdb.com/blog/realtime-web/),” *rethinkdb.com*, January 27, 2015.
1. “[Firebase Realtime Database Documentation](https://firebase.google.com/docs/database/),” Google, Inc., *firebase.google.com*, May 2016.
1. “[Apache CouchDB 1.6 Documentation](http://docs.couchdb.org/en/latest/),” *docs.couchdb.org*, 2014.
1. Matt DeBergalis: “[Meteor 0.7.0: Scalable Database Queries Using MongoDB Oplog Instead of Poll-and-Diff](http://info.meteor.com/blog/meteor-070-scalable-database-queries-using-mongodb-oplog-instead-of-poll-and-diff),” *info.meteor.com*, December 17, 2013.
1. “[Chapter 15. Importing and Exporting Live Data](https://docs.voltdb.com/UsingVoltDB/ChapExport.php),” VoltDB 6.4 User Manual, *docs.voltdb.com*, June 2016.
1. Neha Narkhede: “[Announcing Kafka Connect: Building Large-Scale Low-Latency Data Pipelines](http://www.confluent.io/blog/announcing-kafka-connect-building-large-scale-low-latency-data-pipelines),” *confluent.io*, February 18, 2016.
1. Greg Young: “[CQRS and Event Sourcing](https://www.youtube.com/watch?v=JHGkaShoyNs),” at *Code on the Beach*, August 2014.
1. Martin Fowler: “[Event Sourcing](http://martinfowler.com/eaaDev/EventSourcing.html),” *martinfowler.com*, December 12, 2005.
1. Vaughn Vernon: <a href="https://vaughnvernon.co/?page_id=168">*Implementing Domain-Driven Design*</a>. Addison-Wesley Professional, 2013. ISBN: 978-0-321-83457-7
1. H. V. Jagadish, Inderpal Singh Mumick, and Abraham Silberschatz: “[View Maintenance Issues for the Chronicle Data Model](http://www.mathcs.emory.edu/~cheung/papers/StreamDB/Histogram/1995-Jagadish-Histo.pdf),” at *14th ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems* (PODS), May 1995. [doi:10.1145/212433.220201](http://dx.doi.org/10.1145/212433.220201)
1. “[Event Store 3.5.0 Documentation](http://docs.geteventstore.com/),” Event Store LLP, *docs.geteventstore.com*, February 2016.
1. Martin Kleppmann: <a href="http://www.oreilly.com/data/free/stream-processing.csp">*Making Sense of Stream Processing*</a>. Report, O'Reilly Media, May 2016.
1. Sander Mak: “[Event-Sourced Architectures with Akka](http://www.slideshare.net/SanderMak/eventsourced-architectures-with-akka),” at *JavaOne*, September 2014.
1. Julian Hyde: [personal communication](https://twitter.com/julianhyde/status/743374145006641153), June 2016.
1. Ashish Gupta and Inderpal Singh Mumick: *Materialized Views: Techniques, Implementations, and Applications*. MIT Press, 1999. ISBN: 978-0-262-57122-7
1. Timothy Griffin and Leonid Libkin: “[Incremental Maintenance of Views with Duplicates](http://homepages.inf.ed.ac.uk/libkin/papers/sigmod95.pdf),” at *ACM International Conference on Management of Data* (SIGMOD), May 1995. [doi:10.1145/223784.223849](http://dx.doi.org/10.1145/223784.223849)
1. Pat Helland: “[Immutability Changes Everything](http://www.cidrdb.org/cidr2015/Papers/CIDR15_Paper16.pdf),” at *7th Biennial Conference on Innovative Data Systems Research* (CIDR), January 2015.
1. Martin Kleppmann: “[Accounting for Computer Scientists](http://martin.kleppmann.com/2011/03/07/accounting-for-computer-scientists.html),” *martin.kleppmann.com*, March 7, 2011.
1. Pat Helland: “[Accountants Don't Use Erasers](https://blogs.msdn.microsoft.com/pathelland/2007/06/14/accountants-dont-use-erasers/),” *blogs.msdn.com*, June 14, 2007.
1. Fangjin Yang: “[Dogfooding with Druid, Samza, and Kafka: Metametrics at Metamarkets](https://metamarkets.com/2015/dogfooding-with-druid-samza-and-kafka-metametrics-at-metamarkets/),” *metamarkets.com*, June 3, 2015.
1. Gavin Li, Jianqiu Lv, and Hang Qi: “[Pistachio: Co-Locate the Data and Compute for Fastest Cloud Compute](http://yahoohadoop.tumblr.com/post/116365275781/pistachio-co-locate-the-data-and-compute-for),” *yahoohadoop.tumblr.com*, April 13, 2015.
1. Kartik Paramasivam: “[Stream Processing Hard Problems – Part 1: Killing Lambda](https://engineering.linkedin.com/blog/2016/06/stream-processing-hard-problems-part-1-killing-lambda),” *engineering.linkedin.com*, June 27, 2016.
1. Martin Fowler: “[CQRS](http://martinfowler.com/bliki/CQRS.html),” *martinfowler.com*, July 14, 2011.
1. Greg Young: “[CQRS Documents](https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf),” *cqrs.files.wordpress.com*, November 2010.
1. Baron Schwartz: “[Immutability, MVCC, and Garbage Collection](http://www.xaprb.com/blog/2013/12/28/immutability-mvcc-and-garbage-collection/),” *xaprb.com*, December 28, 2013.
1. Daniel Eloff, Slava Akhmechet, Jay Kreps, et al.: ["Re: Turning the Database Inside-out with Apache Samza](https://news.ycombinator.com/item?id=9145197)," *Hacker News discussion, news.ycombinator.com*, March 4, 2015.
1. “[Datomic Development Resources: Excision](http://docs.datomic.com/excision.html),” Cognitect, Inc., *docs.datomic.com*.
1. “[Fossil Documentation: Deleting Content from Fossil](http://fossil-scm.org/index.html/doc/trunk/www/shunning.wiki),” *fossil-scm.org*, 2016.
1. Jay Kreps: “[The irony of distributed systems is that data loss is really easy but deleting data is surprisingly hard,](https://twitter.com/jaykreps/status/582580836425330688)” *twitter.com*, March 30, 2015.
1. David C. Luckham: “[What’s the Difference Between ESP and CEP?](http://www.complexevents.com/2006/08/01/what%E2%80%99s-the-difference-between-esp-and-cep/),” *complexevents.com*, August 1, 2006.
1. Srinath Perera: “[How Is Stream Processing and Complex Event Processing (CEP) Different?](https://www.quora.com/How-is-stream-processing-and-complex-event-processing-CEP-different),” *quora.com*, December 3, 2015.
1. Arvind Arasu, Shivnath Babu, and Jennifer Widom: “[The CQL Continuous Query Language: Semantic Foundations and Query Execution](http://research.microsoft.com/pubs/77607/cql.pdf),” *The VLDB Journal*, volume 15, number 2, pages 121–142, June 2006. [doi:10.1007/s00778-004-0147-z](http://dx.doi.org/10.1007/s00778-004-0147-z)
1. Julian Hyde: “[Data in Flight: How Streaming SQL Technology Can Help Solve the Web 2.0 Data Crunch](http://queue.acm.org/detail.cfm?id=1667562),” *ACM Queue*, volume 7, number 11, December 2009. [doi:10.1145/1661785.1667562](http://dx.doi.org/10.1145/1661785.1667562)
1. “[Esper Reference, Version 5.4.0](http://www.espertech.com/esper/release-5.4.0/esper-reference/html_single/index.html),” EsperTech, Inc., *espertech.com*, April 2016.
1. Zubair Nabi, Eric Bouillet, Andrew Bainbridge, and Chris Thomas:
“[Of Streams and Storms](https://developer.ibm.com/streamsdev/wp-content/uploads/sites/15/2014/04/Streams-and-Storm-April-2014-Final.pdf),” IBM technical report, *developer.ibm.com*, April 2014.
1. Milinda Pathirage, Julian Hyde, Yi Pan, and Beth Plale: “[SamzaSQL: Scalable Fast Data Management with Streaming SQL](https://github.com/milinda/samzasql-hpbdc2016/blob/master/samzasql-hpbdc2016.pdf),” at *IEEE International Workshop on High-Performance Big Data Computing* (HPBDC), May 2016. [doi:10.1109/IPDPSW.2016.141](http://dx.doi.org/10.1109/IPDPSW.2016.141)
1. Philippe Flajolet, Éric Fusy, Olivier Gandouet, and Frédéric Meunier: “[HyperLo&#x2060;g&#x200b;Log: The Analysis of a Near-Optimal Cardinality Estimation Algorithm](http://algo.inria.fr/flajolet/Publications/FlFuGaMe07.pdf),” at *Conference on Analysis of Algorithms* (AofA), June 2007.
1. Jay Kreps: “[Questioning the Lambda Architecture](https://www.oreilly.com/ideas/questioning-the-lambda-architecture),” *oreilly.com*, July 2, 2014.
1. Ian Hellström: “[An Overview of Apache Streaming Technologies](https://databaseline.wordpress.com/2016/03/12/an-overview-of-apache-streaming-technologies/),” *databaseline.wordpress.com*, March 12, 2016.
1. Jay Kreps: “[Why Local State Is a Fundamental Primitive in Stream Processing](https://www.oreilly.com/ideas/why-local-state-is-a-fundamental-primitive-in-stream-processing),” *oreilly.com*, July 31, 2014.
1. Shay Banon: “[Percolator](https://www.elastic.co/blog/percolator),” *elastic.co*, February 8, 2011.
1. Alan Woodward and Martin Kleppmann: “[Real-Time Full-Text Search with Luwak and Samza](http://martin.kleppmann.com/2015/04/13/real-time-full-text-search-luwak-samza.html),” *martin.kleppmann.com*, April 13, 2015.
1. “[Apache Storm 1.0.1 Documentation](https://storm.apache.org/releases/1.0.1/index.html),” *storm.apache.org*, May 2016.
1. Tyler Akidau: “[The World Beyond Batch: Streaming 102](https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-102),” *oreilly.com*, January 20, 2016.
1. Stephan Ewen: “[Streaming Analytics with Apache Flink](http://www.confluent.io/kafka-summit-2016-systems-advanced-streaming-analytics-with-apache-flink-and-apache-kafka),” at *Kafka Summit*, April 2016.
1. Tyler Akidau, Alex Balikov, Kaya Bekiroğlu, et al.: “[MillWheel: Fault-Tolerant Stream Processing at Internet Scale](http://research.google.com/pubs/pub41378.html),” at *39th International Conference on Very Large Data Bases* (VLDB), August 2013.
1. Alex Dean: “[Improving Snowplow's Understanding of Time](http://snowplowanalytics.com/blog/2015/09/15/improving-snowplows-understanding-of-time/),” *snowplowanalytics.com*, September 15, 2015.
1. “[Windowing (Azure Stream Analytics)](https://msdn.microsoft.com/en-us/library/azure/dn835019.aspx),” Microsoft Azure Reference, *msdn.microsoft.com*, April 2016.
1. “[State Management](http://samza.apache.org/learn/documentation/0.10/container/state-management.html),” Apache Samza 0.10 Documentation, *samza.apache.org*, December 2015.
1. Rajagopal Ananthanarayanan, Venkatesh Basker, Sumit Das, et al.: “[Photon: Fault-Tolerant and Scalable Joining of Continuous Data Streams](http://research.google.com/pubs/pub41318.html),” at *ACM International Conference on Management of Data* (SIGMOD), June 2013. [doi:10.1145/2463676.2465272](http://dx.doi.org/10.1145/2463676.2465272)
1. Martin Kleppmann: “[Samza Newsfeed Demo](https://github.com/ept/newsfeed),” *github.com*, September 2014.
1. Ben Kirwin: “[Doing the Impossible: Exactly-Once Messaging Patterns in Kafka](http://ben.kirw.in/2014/11/28/kafka-patterns/),” *ben.kirw.in*, November 28, 2014.
1. Pat Helland: “[Data on the Outside Versus Data on the Inside](http://cidrdb.org/cidr2005/papers/P12.pdf),” at *2nd Biennial Conference on Innovative Data Systems Research* (CIDR), January 2005.
1. Ralph Kimball and Margy Ross: *The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling*, 3rd edition. John Wiley & Sons, 2013. ISBN: 978-1-118-53080-1
1. Viktor Klang: “[I'm coining the phrase 'effectively-once' for message processing with at-least-once + idempotent operations](https://twitter.com/viktorklang/status/789036133434978304),” *twitter.com*, October 20, 2016.
1. Matei Zaharia, Tathagata Das, Haoyuan Li, et al.: “[Discretized Streams: An Efficient and Fault-Tolerant Model for Stream Processing on Large Clusters](https://www.usenix.org/system/files/conference/hotcloud12/hotcloud12-final28.pdf),” at *4th USENIX Conference in Hot Topics in Cloud Computing* (HotCloud), June 2012.
1. Kostas Tzoumas, Stephan Ewen, and Robert Metzger: “[High-Throughput, Low-Latency, and Exactly-Once Stream Processing with Apache Flink](http://data-artisans.com/high-throughput-low-latency-and-exactly-once-stream-processing-with-apache-flink/),” *data-artisans.com*, August 5, 2015.
1. Paris Carbone, Gyula Fóra, Stephan Ewen, et al.: “[Lightweight Asynchronous Snapshots for Distributed Dataflows](http://arxiv.org/abs/1506.08603),” arXiv:1506.08603 &#91;cs.DC&#93;, June 29, 2015.
1. Ryan Betts and John Hugg: <a href="http://www.oreilly.com/data/free/fast-data-smart-and-at-scale.csp">*Fast Data: Smart and at Scale*</a>. Report, O'Reilly Media, October 2015.
1. Flavio Junqueira: “[Making Sense of Exactly-Once Semantics](http://conferences.oreilly.com/strata/hadoop-big-data-eu/public/schedule/detail/49690),” at *Strata+Hadoop World London*, June 2016.
1. Jason Gustafson, Flavio Junqueira, Apurva Mehta, Sriram Subramanian, and Guozhang Wang: “[KIP-98 – Exactly Once Delivery and Transactional Messaging](https://cwiki.apache.org/confluence/display/KAFKA/KIP-98+-+Exactly+Once+Delivery+and+Transactional+Messaging),” *cwiki.apache.org*, November 2016.
1. Pat Helland: “[Idempotence Is Not a Medical Condition](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.401.1539&rep=rep1&type=pdf),” *Communications of the ACM*, volume 55, number 5, page 56, May 2012. [doi:10.1145/2160718.2160734](http://dx.doi.org/10.1145/2160718.2160734)
1. Jay Kreps: “[Re: Trying to Achieve Deterministic Behavior on Recovery/Rewind](http://mail-archives.apache.org/mod_mbox/samza-dev/201409.mbox/%3CCAOeJiJg%2Bc7Ei%3DgzCuOz30DD3G5Hm9yFY%3DUJ6SafdNUFbvRgorg%40mail.gmail.com%3E),” email to *samza-dev* mailing list, September 9, 2014.
1. E. N. (Mootaz) Elnozahy, Lorenzo Alvisi, Yi-Min Wang, and David B. Johnson: “[A Survey of Rollback-Recovery Protocols in Message-Passing Systems](http://www.cs.utexas.edu/~lorenzo/papers/SurveyFinal.pdf),” *ACM Computing Surveys*, volume 34, number 3, pages 375–408, September 2002. [doi:10.1145/568522.568525](http://dx.doi.org/10.1145/568522.568525)
1. Adam Warski: “[Kafka Streams – How Does It Fit the Stream Processing Landscape?](https://softwaremill.com/kafka-streams-how-does-it-fit-stream-landscape/),” *softwaremill.com*, June 1, 2016.
------
| 上一章 | 目錄 | 下一章 |
| ------------------------- | ------------------------------- | ---------------------------------- |
| [第十章：批處理](ch10.md) | [設計資料密集型應用](README.md) | [第十二章：資料系統的未來](ch12.md) |

1152
zh-tw/ch12.md Normal file
View File

File diff suppressed because it is too large Load Diff

1045
zh-tw/ch2.md Normal file
View File

File diff suppressed because it is too large Load Diff

765
zh-tw/ch3.md Normal file
View File

@ -0,0 +1,765 @@
# 3. 儲存與檢索
![](../img/ch3.png)
> 建立秩序，省卻搜尋
>
> ——德國諺語
>
-------------------
[TOC]
一個數據庫在最基礎的層次上需要完成兩件事情：當你把資料交給資料庫時，它應當把資料儲存起來；而後當你向資料庫要資料時，它應當把資料返回給你。
在[第2章](ch2.md)中，我們討論了資料模型和查詢語言，即程式設計師將資料錄入資料庫的格式，以及再次要回資料的機制。在本章中我們會從資料庫的視角來討論同樣的問題：資料庫如何儲存我們提供的資料，以及如何在我們需要時重新找到資料。
作為程式設計師，為什麼要關心資料庫內部儲存與檢索的機理？你可能不會去從頭開始實現自己的儲存引擎，但是你**確實**需要從許多可用的儲存引擎中選擇一個合適的。而且為了協調儲存引擎以適配應用工作負載，你也需要大致瞭解儲存引擎在底層究竟做什麼。
特別需要注意，針對**事務**性負載和**分析性**負載最佳化的儲存引擎之間存在巨大差異。稍後我們將在 “[事務處理還是分析？](#事務處理還是分析？)” 一節中探討這一區別，並在 “[列儲存](#列儲存)”中討論一系列針對分析最佳化儲存引擎。
但是，我們將從您最可能熟悉的兩大類資料庫：傳統關係型資料庫與很多所謂的“NoSQL”資料庫開始，透過介紹它們的**儲存引擎**來開始本章的內容。我們會研究兩大類儲存引擎：**日誌結構（log-structured）** 的儲存引擎，以及**面向頁面（page-oriented）** 的儲存引擎（例如B樹）。
## 驅動資料庫的資料結構
世界上最簡單的資料庫可以用兩個Bash函式實現：
```bash
#!/bin/bash
db_set () {
echo "$1,$2" >> database
}
db_get () {
grep "^$1," database | sed -e "s/^$1,//" | tail -n 1
}
```
這兩個函式實現了鍵值儲存的功能。執行 `db_set key value` ，會將 **鍵（key）**和**值（value）** 儲存在資料庫中。鍵和值（幾乎）可以是你喜歡的任何東西，例如，值可以是JSON文件。然後呼叫 `db_get key` ，查詢與該鍵關聯的最新值並將其返回。
麻雀雖小，五臟俱全：
```bash
$ db_set 123456 '{"name":"London","attractions":["Big Ben","London Eye"]}' $
$ db_set 42 '{"name":"San Francisco","attractions":["Golden Gate Bridge"]}'
$ db_get 42
{"name":"San Francisco","attractions":["Golden Gate Bridge"]}
```
底層的儲存格式非常簡單：一個文字檔案，每行包含一條逗號分隔的鍵值對（忽略轉義問題的話，大致與CSV檔案類似）。每次對 `db_set` 的呼叫都會向檔案末尾追加記錄，所以更新鍵的時候舊版本的值不會被覆蓋 —— 因而查詢最新值的時候，需要找到檔案中鍵最後一次出現的位置（因此 `db_get` 中使用了 `tail -n 1 ` 。)
```bash
$ db_set 42 '{"name":"San Francisco","attractions":["Exploratorium"]}'
$ db_get 42
{"name":"San Francisco","attractions":["Exploratorium"]}
$ cat database
123456,{"name":"London","attractions":["Big Ben","London Eye"]}
42,{"name":"San Francisco","attractions":["Golden Gate Bridge"]}
42,{"name":"San Francisco","attractions":["Exploratorium"]}
```
`db_set` 函式對於極其簡單的場景其實有非常好的效能，因為在檔案尾部追加寫入通常是非常高效的。與`db_set`做的事情類似，許多資料庫在內部使用了**日誌（log）**，也就是一個 **僅追加（append-only）** 的資料檔案。真正的資料庫有更多的問題需要處理（如併發控制，回收磁碟空間以避免日誌無限增長，處理錯誤與部分寫入的記錄），但基本原理是一樣的。日誌極其有用，我們還將在本書的其它部分重複見到它好幾次。
> **日誌（log）** 這個詞通常指應用日誌：即應用程式輸出的描述發生事情的文字。本書在更普遍的意義下使用**日誌**這一詞：一個僅追加的記錄序列。它可能壓根就不是給人類看的，使用二進位制格式，並僅能由其他程式讀取。
另一方面，如果這個資料庫中有著大量記錄，則這個`db_get` 函式的效能會非常糟糕。每次你想查詢一個鍵時，`db_get` 必須從頭到尾掃描整個資料庫檔案來查詢鍵的出現。用演算法的語言來說，查詢的開銷是 `O(n)` ：如果資料庫記錄數量 n 翻了一倍，查詢時間也要翻一倍。這就不好了。
為了高效查詢資料庫中特定鍵的值，我們需要一個數據結構：**索引（index）**。本章將介紹一系列的索引結構，並它們進行對比。索引背後的大致思想是，儲存一些額外的元資料作為路標，幫助你找到想要的資料。如果您想在同一份資料中以幾種不同的方式進行搜尋，那麼你也許需要不同的索引，建在資料的不同部分上。
索引是從主資料衍生的**附加（additional）**結構。許多資料庫允許新增與刪除索引，這不會影響資料的內容，它隻影響查詢的效能。維護額外的結構會產生開銷，特別是在寫入時。寫入效能很難超過簡單地追加寫入檔案，因為追加寫入是最簡單的寫入操作。任何型別的索引通常都會減慢寫入速度，因為每次寫入資料時都需要更新索引。
這是儲存系統中一個重要的權衡：精心選擇的索引加快了讀查詢的速度，但是每個索引都會拖慢寫入速度。因為這個原因，資料庫預設並不會索引所有的內容，而需要你（程式設計師或DBA）透過對應用查詢模式的瞭解來手動選擇索引。你可以選擇能為應用帶來最大收益，同時又不會引入超出必要開銷的索引。
### 雜湊索引
讓我們從 **鍵值資料（key-value Data）** 的索引開始。這不是您可以索引的唯一資料型別，但鍵值資料是很常見的。對於更復雜的索引來說，這是一個有用的構建模組。
鍵值儲存與在大多數程式語言中可以找到的**字典（dictionary）**型別非常相似，通常字典都是用**雜湊對映（hash map）**（或**雜湊表（hash table）**）實現的。雜湊對映在許多演算法教科書中都有描述【1,2】，所以這裡我們不會討論它的工作細節。既然我們已經有**記憶體中**資料結構 —— 雜湊對映，為什麼不使用它來索引在**磁碟上**的資料呢？
假設我們的資料儲存只是一個追加寫入的檔案，就像前面的例子一樣。那麼最簡單的索引策略就是：保留一個記憶體中的雜湊對映，其中每個鍵都對映到一個數據檔案中的位元組偏移量，指明瞭可以找到對應值的位置，如[圖3-1](../img/fig3-1.png)所示。當你將新的鍵值對追加寫入檔案中時，還要更新雜湊對映，以反映剛剛寫入的資料的偏移量（這同時適用於插入新鍵與更新現有鍵）。當你想查詢一個值時，使用雜湊對映來查詢資料檔案中的偏移量，**尋找（seek）** 該位置並讀取該值。
![](../img/fig3-1.png)
**圖3-1 以類CSV格式儲存鍵值對的日誌，並使用記憶體雜湊對映進行索引。**
聽上去簡單，但這是一個可行的方法。現實中，Bitcask實際上就是這麼做的（Riak中預設的儲存引擎）【3】。 Bitcask提供高效能的讀取和寫入操作，但所有鍵必須能放入可用記憶體中，因為雜湊對映完全保留在記憶體中。這些值可以使用比可用記憶體更多的空間，因為可以從磁碟上透過一次`seek`載入所需部分，如果資料檔案的那部分已經在檔案系統快取中，則讀取根本不需要任何磁碟I/O。
像Bitcask這樣的儲存引擎非常適合每個鍵的值經常更新的情況。例如，鍵可能是影片的URL，值可能是它播放的次數（每次有人點選播放按鈕時遞增）。在這種型別的工作負載中，有很多寫操作，但是沒有太多不同的鍵——每個鍵有很多的寫操作，但是將所有鍵儲存在記憶體中是可行的。
直到現在，我們只是追加寫入一個檔案 —— 所以如何避免最終用完磁碟空間？一種好的解決方案是，將日誌分為特定大小的段，當日志增長到特定尺寸時關閉當前段檔案，並開始寫入一個新的段檔案。然後，我們就可以對這些段進行**壓縮（compaction）**，如[圖3-2](../img/fig3-2.png)所示。壓縮意味著在日誌中丟棄重複的鍵，只保留每個鍵的最近更新。
![](../img/fig3-2.png)
**圖3-2 壓縮鍵值更新日誌（統計貓影片的播放次數），只保留每個鍵的最近值**
而且，由於壓縮經常會使得段變得很小（假設在一個段內鍵被平均重寫了好幾次），我們也可以在執行壓縮的同時將多個段合併在一起，如[圖3-3](../img/fig3-3.png)所示。段被寫入後永遠不會被修改，所以合併的段被寫入一個新的檔案。凍結段的合併和壓縮可以在後臺執行緒中完成，在進行時，我們仍然可以繼續使用舊的段檔案來正常提供讀寫請求。合併過程完成後，我們將讀取請求轉換為使用新的合併段而不是舊段 —— 然後可以簡單地刪除舊的段檔案。
![](../img/fig3-3.png)
**圖3-3 同時執行壓縮和分段合併**
每個段現在都有自己的記憶體散列表，將鍵對映到檔案偏移量。為了找到一個鍵的值，我們首先檢查最近段的雜湊對映;如果鍵不存在，我們檢查第二個最近的段，依此類推。合併過程保持細分的數量，所以查詢不需要檢查許多雜湊對映。
大量的細節進入實踐這個簡單的想法工作。簡而言之，一些真正實施中重要的問題是：
***檔案格式***
​ CSV不是日誌的最佳格式。使用二進位制格式更快，更簡單，首先以位元組為單位對字串的長度進行編碼，然後使用原始字串（不需要轉義）。
***刪除記錄***
如果要刪除一個鍵及其關聯的值，則必須在資料檔案（有時稱為邏輯刪除）中附加一個特殊的刪除記錄。當日志段被合併時，邏輯刪除告訴合併過程放棄刪除鍵的任何以前的值。
***崩潰恢復***
如果資料庫重新啟動，則記憶體雜湊對映將丟失。原則上，您可以透過從頭到尾讀取整個段檔案並在每次按鍵時注意每個鍵的最近值的偏移量來恢復每個段的雜湊對映。但是，如果段檔案很大，這可能需要很長時間，這將使伺服器重新啟動痛苦。 Bitcask透過儲存加速恢復磁碟上每個段的雜湊對映的快照，可以更快地載入到記憶體中。
***部分寫入記錄***
資料庫可能隨時崩潰，包括將記錄附加到日誌中途。 Bitcask檔案包含校驗和，允許檢測和忽略日誌的這些損壞部分。
***併發控制***
由於寫操作是以嚴格順序的順序附加到日誌中的，所以常見的實現選擇是隻有一個寫入器執行緒。資料檔案段是附加的，或者是不可變的，所以它們可以被多個執行緒同時讀取。
乍一看，只有追加日誌看起來很浪費：為什麼不更新檔案，用新值覆蓋舊值？但是隻能追加設計的原因有幾個：
* 追加和分段合併是順序寫入操作，通常比隨機寫入快得多，尤其是在磁碟旋轉硬碟上。在某種程度上，順序寫入在基於快閃記憶體的 **固態硬碟（SSD）** 上也是優選的【4】。我們將在第83頁的“[比較B-樹和LSM-樹](#比較B-樹和LSM-樹)”中進一步討論這個問題。
* 如果段檔案是附加的或不可變的，併發和崩潰恢復就簡單多了。例如，您不必擔心在覆蓋值時發生崩潰的情況，而將包含舊值和新值的一部分的檔案保留在一起。
* 合併舊段可以避免資料檔案隨著時間的推移而分散的問題。
但是，雜湊表索引也有侷限性：
* 散列表必須能放進記憶體
如果你有非常多的鍵，那真是倒黴。原則上可以在磁碟上保留一個雜湊對映，不幸的是磁碟雜湊對映很難表現優秀。它需要大量的隨機訪問I/O，當它變滿時增長是很昂貴的，並且雜湊衝突需要很多的邏輯【5】。
* 範圍查詢效率不高。例如，您無法輕鬆掃描kitty00000和kitty99999之間的所有鍵——您必須在雜湊對映中單獨查詢每個鍵。
在下一節中，我們將看看一個沒有這些限制的索引結構。
### SSTables和LSM樹
在[圖3-3](../img/fig3-3.png)中，每個日誌結構儲存段都是一系列鍵值對。這些對按照它們寫入的順序出現，日誌中稍後的值優先於日誌中較早的相同鍵的值。除此之外，檔案中鍵值對的順序並不重要。
現在我們可以對段檔案的格式做一個簡單的改變：我們要求鍵值對的序列按鍵排序。乍一看，這個要求似乎打破了我們使用順序寫入的能力，但是我們馬上就會明白這一點。
我們把這個格式稱為**排序字串表（Sorted String Table）**，簡稱SSTable。我們還要求每個鍵只在每個合併的段檔案中出現一次（壓縮過程已經保證）。與使用雜湊索引的日誌段相比，SSTable有幾個很大的優勢：
1. 合併段是簡單而高效的，即使檔案大於可用記憶體。這種方法就像歸併排序演算法中使用的方法一樣，如[圖3-4](../img/fig3-4.png)所示：您開始並排讀取輸入檔案，檢視每個檔案中的第一個鍵，複製最低鍵（根據排序順序）到輸出檔案，並重復。這產生一個新的合併段檔案，也按鍵排序。
![](../img/fig3-4.png)
##### 圖3-4 合併幾個SSTable段，只保留每個鍵的最新值
如果在幾個輸入段中出現相同的鍵，該怎麼辦？請記住，每個段都包含在一段時間內寫入資料庫的所有值。這意味著一個輸入段中的所有值必須比另一個段中的所有值更新（假設我們總是合併相鄰的段）。當多個段包含相同的鍵時，我們可以保留最近段的值，並丟棄舊段中的值。
2. 為了在檔案中找到一個特定的鍵，你不再需要儲存記憶體中所有鍵的索引。以[圖3-5](../img/fig3-5.png)為例：假設你正在記憶體中尋找鍵 `handiwork`，但是你不知道段檔案中該關鍵字的確切偏移量。然而，你知道 `handbag` 和 `handsome` 的偏移，而且由於排序特性，你知道 `handiwork` 必須出現在這兩者之間。這意味著您可以跳到 `handbag` 的偏移位置並從那裡掃描，直到您找到 `handiwork`（或沒找到，如果該檔案中沒有該鍵）。
![](../img/fig3-5.png)
**圖3-5 具有記憶體索引的SSTable**
您仍然需要一個記憶體中索引來告訴您一些鍵的偏移量，但它可能很稀疏：每幾千位元組的段檔案就有一個鍵就足夠了，因為幾千位元組可以很快被掃描[^i]。
3. 由於讀取請求無論如何都需要掃描所請求範圍內的多個鍵值對，因此可以將這些記錄分組到塊中，並在將其寫入磁碟之前對其進行壓縮（如[圖3-5](../img/fig3-5.png)中的陰影區域所示） 。稀疏記憶體中索引的每個條目都指向壓縮塊的開始處。除了節省磁碟空間之外，壓縮還可以減少IO頻寬的使用。
[^i]: 如果所有的鍵與值都是定長的，你可以使用段檔案上的二分查詢並完全避免使用記憶體索引。然而實踐中鍵值通常都是變長的，因此如果沒有索引，就很難知道記錄的分界點（前一條記錄結束，後一條記錄開始的地方）
#### 構建和維護SSTables
到目前為止，但是如何讓你的資料首先被按鍵排序呢？我們的傳入寫入可以以任何順序發生。
在磁碟上維護有序結構是可能的（參閱“[B樹](#B樹)”），但在記憶體儲存則要容易得多。有許多可以使用的眾所周知的樹形資料結構，例如紅黑樹或AVL樹【2】。使用這些資料結構，您可以按任何順序插入鍵，並按排序順序讀取它們。
現在我們可以使我們的儲存引擎工作如下：
* 寫入時，將其新增到記憶體中的平衡樹資料結構（例如，紅黑樹）。這個記憶體樹有時被稱為**記憶體表（memtable）**。
* 當**記憶體表**大於某個閾值（通常為幾兆位元組）時，將其作為SSTable檔案寫入磁碟。這可以高效地完成，因為樹已經維護了按鍵排序的鍵值對。新的SSTable檔案成為資料庫的最新部分。當SSTable被寫入磁碟時，寫入可以繼續到一個新的記憶體表例項。
* 為了提供讀取請求，首先嚐試在記憶體表中找到關鍵字，然後在最近的磁碟段中，然後在下一個較舊的段中找到該關鍵字。
* 有時會在後臺執行合併和壓縮過程以組合段檔案並丟棄覆蓋或刪除的值。
這個方案效果很好。它只會遇到一個問題：如果資料庫崩潰，則最近的寫入（在記憶體表中，但尚未寫入磁碟）將丟失。為了避免這個問題，我們可以在磁碟上儲存一個單獨的日誌，每個寫入都會立即被附加到磁碟上，就像在前一節中一樣。該日誌不是按排序順序，但這並不重要，因為它的唯一目的是在崩潰後恢復記憶體表。每當記憶體表寫出到SSTable時，相應的日誌都可以被丟棄。
#### 用SSTables製作LSM樹
這裡描述的演算法本質上是LevelDB 【6】和RocksDB 【7】中使用的關鍵值儲存引擎庫，被設計嵌入到其他應用程式中。除此之外，LevelDB可以在Riak中用作Bitcask的替代品。在Cassandra和HBase中使用了類似的儲存引擎【8】，這兩種引擎都受到了Google的Bigtable文件【9】（引入了SSTable和memtable）的啟發。
最初這種索引結構是由Patrick O'Neil等人描述的。在日誌結構合併樹（或LSM樹）【10】的基礎上，建立在以前的工作上日誌結構的檔案系統【11】。基於這種合併和壓縮排序檔案原理的儲存引擎通常被稱為LSM儲存引擎。
Lucene是Elasticsearch和Solr使用的一種全文搜尋的索引引擎，它使用類似的方法來儲存它的詞典【12,13】。全文索引比鍵值索引複雜得多，但是基於類似的想法：在搜尋查詢中給出一個單詞，找到提及單詞的所有文件（網頁，產品描述等）。這是透過鍵值結構實現的，其中鍵是單詞（**關鍵詞（term）**），值是包含單詞（文章列表）的所有文件的ID的列表。在Lucene中，從術語到釋出列表的這種對映儲存在SSTable類的有序檔案中，根據需要在後臺合併【14】。
#### 效能最佳化
與往常一樣，大量的細節使得儲存引擎在實踐中表現良好。例如，當查詢資料庫中不存在的鍵時，LSM樹演算法可能會很慢：您必須檢查記憶體表，然後將這些段一直回到最老的（可能必須從磁碟讀取每一個），然後才能確定鍵不存在。為了最佳化這種訪問，儲存引擎通常使用額外的Bloom過濾器【15】。 （布隆過濾器是用於近似集合內容的記憶體高效資料結構，它可以告訴您資料庫中是否出現鍵，從而為不存在的鍵節省許多不必要的磁碟讀取操作。
還有不同的策略來確定SSTables如何被壓縮和合並的順序和時間。最常見的選擇是大小分層壓實。 LevelDB和RocksDB使用平坦壓縮（LevelDB因此得名），HBase使用大小分層，Cassandra同時支援【16】。在規模級別的調整中，更新和更小的SSTables先後被合併到更老的和更大的SSTable中。在水平壓實中，關鍵範圍被拆分成更小的SSTables，而較舊的資料被移動到單獨的“水平”，這使得壓縮能夠更加遞增地進行，並且使用更少的磁碟空間。
即使有許多微妙的東西，LSM樹的基本思想 —— 儲存一系列在後臺合併的SSTables —— 簡單而有效。即使資料集比可用記憶體大得多，它仍能繼續正常工作。由於資料按排序順序儲存，因此可以高效地執行範圍查詢（掃描所有高於某些最小值和最高值的所有鍵），並且因為磁碟寫入是連續的，所以LSM樹可以支援非常高的寫入吞吐量。
### B樹
剛才討論的日誌結構索引正處在逐漸被接受的階段，但它們並不是最常見的索引型別。使用最廣泛的索引結構在1970年被引入【17】，不到10年後變得“無處不在”【18】，B樹經受了時間的考驗。在幾乎所有的關係資料庫中，它們仍然是標準的索引實現，許多非關係資料庫也使用它們。
像SSTables一樣，B樹保持按鍵排序的鍵值對，這允許高效的鍵值查詢和範圍查詢。但這就是相似之處的結尾：B樹有著非常不同的設計理念。
我們前面看到的日誌結構索引將資料庫分解為可變大小的段，通常是幾兆位元組或更大的大小，並且總是按順序編寫段。相比之下，B樹將資料庫分解成固定大小的塊或頁面，傳統上大小為4KB（有時會更大），並且一次只能讀取或寫入一個頁面。這種設計更接近於底層硬體，因為磁碟也被安排在固定大小的塊中。
每個頁面都可以使用地址或位置來標識，這允許一個頁面引用另一個頁面 —— 類似於指標，但在磁碟而不是在記憶體中。我們可以使用這些頁面引用來構建一個頁面樹，如[圖3-6](../img/fig3-6.png)所示。
![](../img/fig3-6.png)
**圖3-6 使用B樹索引查詢一個鍵**
一個頁面會被指定為B樹的根；在索引中查詢一個鍵時，就從這裡開始。該頁面包含幾個鍵和對子頁面的引用。每個子頁面負責一段連續範圍的鍵，引用之間的鍵，指明瞭引用子頁面的鍵範圍。
在[圖3-6](../img/fig3-6.png)的例子中，我們正在尋找關鍵字 251 ，所以我們知道我們需要遵循邊界 200 和 300 之間的頁面引用。這將我們帶到一個類似的頁面，進一步打破了200 - 300到子範圍。
最後，我們可以看到包含單個鍵（葉頁）的頁面，該頁面包含每個鍵的內聯值，或者包含對可以找到值的頁面的引用。
在B樹的一個頁面中對子頁面的引用的數量稱為分支因子。例如，在[圖3-6](../img/fig3-6.png)中，分支因子是 6 。在實踐中，分支因子取決於儲存頁面參考和範圍邊界所需的空間量，但通常是幾百個。
如果要更新B樹中現有鍵的值，則搜尋包含該鍵的葉頁，更改該頁中的值，並將該頁寫回到磁碟（對該頁的任何引用保持有效） 。如果你想新增一個新的鍵，你需要找到其範圍包含新鍵的頁面，並將其新增到該頁面。如果頁面中沒有足夠的可用空間容納新鍵，則將其分成兩個半滿頁面，並更新父頁面以解釋鍵範圍的新分割槽，如[圖3-7](../img/fig3-7.png)所示[^ii]。
[^ii]: 向B樹中插入一個新的鍵是相當符合直覺的，但刪除一個鍵（同時保持樹平衡）就會牽扯很多其他東西了。
![](../img/fig3-7.png)
**圖3-7 透過分割頁面來生長B樹**
該演算法確保樹保持平衡：具有 n 個鍵的B樹總是具有 $O(log n)$ 的深度。大多數資料庫可以放入一個三到四層的B樹，所以你不需要遵追蹤多頁面引用來找到你正在查詢的頁面。 （分支因子為 500 的 4KB 頁面的四級樹可以儲存多達 256TB 。）
#### 讓B樹更可靠
B樹的基本底層寫操作是用新資料覆蓋磁碟上的頁面。假定覆蓋不改變頁面的位置;即，當頁面被覆蓋時，對該頁面的所有引用保持完整。這與日誌結構索引（如LSM樹）形成鮮明對比，後者只附加到檔案（並最終刪除過時的檔案），但從不修改檔案。
您可以考慮將硬碟上的頁面覆蓋為實際的硬體操作。在磁性硬碟驅動器上，這意味著將磁頭移動到正確的位置，等待旋轉盤上的正確位置出現，然後用新的資料覆蓋適當的扇區。在固態硬碟上，由於SSD必須一次擦除和重寫相當大的儲存晶片塊，所以會發生更復雜的事情【19】。
而且，一些操作需要覆蓋幾個不同的頁面。例如，如果因為插入導致頁面過度而拆分頁面，則需要編寫已拆分的兩個頁面，並覆蓋其父頁面以更新對兩個子頁面的引用。這是一個危險的操作，因為如果資料庫在僅有一些頁面被寫入後崩潰，那麼最終將導致一個損壞的索引（例如，可能有一個孤兒頁面不是任何父項的子項） 。
為了使資料庫對崩潰具有韌性，B樹實現通常會帶有一個額外的磁碟資料結構：**預寫式日誌（WAL, write-ahead-log）**（也稱為**重做日誌（redo log）**）。這是一個僅追加的檔案，每個B樹修改都可以應用到樹本身的頁面上。當資料庫在崩潰後恢復時，這個日誌被用來使B樹恢復到一致的狀態【5,20】。
更新頁面的一個額外的複雜情況是，如果多個執行緒要同時訪問B樹，則需要仔細的併發控制 —— 否則執行緒可能會看到樹處於不一致的狀態。這通常透過使用**鎖存器（latches）**（輕量級鎖）保護樹的資料結構來完成。日誌結構化的方法在這方面更簡單，因為它們在後臺進行所有的合併，而不會干擾傳入的查詢，並且不時地將舊的分段原子交換為新的分段。
#### B樹最佳化
由於B樹已經存在了這麼久，許多最佳化已經發展了多年，這並不奇怪。僅舉幾例：
* 一些資料庫（如LMDB）使用寫時複製方案【21】，而不是覆蓋頁面並維護WAL進行崩潰恢復。修改的頁面被寫入到不同的位置，並且樹中的父頁面的新版本被建立，指向新的位置。這種方法對於併發控制也很有用，我們將在“[快照隔離和可重複讀](ch7.md#快照隔離和可重複讀)”中看到。
* 我們可以透過不儲存整個鍵來節省頁面空間，但可以縮小它的大小。特別是在樹內部的頁面上，鍵只需要提供足夠的資訊來充當鍵範圍之間的邊界。在頁面中包含更多的鍵允許樹具有更高的分支因子，因此更少的層次
* 通常，頁面可以放置在磁碟上的任何位置；沒有什麼要求附近的鍵範圍頁面附近的磁碟上。如果查詢需要按照排序順序掃描大部分關鍵字範圍，那麼每個頁面的佈局可能會非常不方便，因為每個讀取的頁面都可能需要磁碟查詢。因此，許多B樹實現嘗試佈局樹，使得葉子頁面按順序出現在磁碟上。但是，隨著樹的增長，維持這個順序是很困難的。相比之下，由於LSM樹在合併過程中一次又一次地重寫儲存的大部分，所以它們更容易使順序鍵在磁碟上彼此靠近。
* 額外的指標已新增到樹中。例如，每個葉子頁面可以在左邊和右邊具有對其兄弟頁面的引用，這允許不跳回父頁面就能順序掃描。
* B樹的變體如分形樹【22】借用一些日誌結構的思想來減少磁碟尋道（而且它們與分形無關）。
### 比較B樹和LSM樹
儘管B樹實現通常比LSM樹實現更成熟，但LSM樹由於其效能特點也非常有趣。根據經驗，通常LSM樹的寫入速度更快，而B樹的讀取速度更快【23】。 LSM樹上的讀取通常比較慢，因為它們必須在壓縮的不同階段檢查幾個不同的資料結構和SSTables。
然而，基準通常對工作量的細節不確定和敏感。 您需要測試具有特定工作負載的系統，以便進行有效的比較。 在本節中，我們將簡要討論一些在衡量儲存引擎效能時值得考慮的事情。
#### LSM樹的優點
B樹索引必須至少兩次寫入每一段資料：一次寫入預先寫入日誌，一次寫入樹頁面本身（也許再次分頁）。即使在該頁面中只有幾個位元組發生了變化，也需要一次編寫整個頁面的開銷。有些儲存引擎甚至會覆蓋同一個頁面兩次，以免在電源故障的情況下導致頁面部分更新【24,25】。
由於反覆壓縮和合並SSTables，日誌結構索引也會重寫資料。這種影響 —— 在資料庫的生命週期中寫入資料庫導致對磁碟的多次寫入 —— 被稱為**寫放大（write amplification）**。需要特別注意的是固態硬碟，固態硬碟的快閃記憶體壽命在覆寫有限次數後就會耗盡。
在寫入繁重的應用程式中，效能瓶頸可能是資料庫可以寫入磁碟的速度。在這種情況下，寫放大會導致直接的效能代價：儲存引擎寫入磁碟的次數越多，可用磁碟頻寬內的每秒寫入次數越少。
而且，LSM樹通常能夠比B樹支援更高的寫入吞吐量，部分原因是它們有時具有較低的寫放大（儘管這取決於儲存引擎配置和工作負載），部分是因為它們順序地寫入緊湊的SSTable檔案而不是必須覆蓋樹中的幾個頁面【26】。這種差異在磁性硬碟驅動器上尤其重要，順序寫入比隨機寫入快得多。
LSM樹可以被壓縮得更好，因此經常比B樹在磁碟上產生更小的檔案。 B樹儲存引擎會由於分割而留下一些未使用的磁碟空間：當頁面被拆分或某行不能放入現有頁面時，頁面中的某些空間仍未被使用。由於LSM樹不是面向頁面的，並且定期重寫SSTables以去除碎片，所以它們具有較低的儲存開銷，特別是當使用平坦壓縮時【27】。
在許多固態硬碟上，韌體內部使用日誌結構化演算法，將隨機寫入轉變為順序寫入底層儲存晶片，因此儲存引擎寫入模式的影響不太明顯【19】。但是，較低的寫入放大率和減少的碎片對SSD仍然有利：更緊湊地表示資料可在可用的I/O頻寬內提供更多的讀取和寫入請求。
#### LSM樹的缺點
日誌結構儲存的缺點是壓縮過程有時會干擾正在進行的讀寫操作。儘管儲存引擎嘗試逐步執行壓縮而不影響併發訪問，但是磁碟資源有限，所以很容易發生請求需要等待而磁碟完成昂貴的壓縮操作。對吞吐量和平均響應時間的影響通常很小，但是在更高百分比的情況下（參閱“[描述效能](ch1.md#描述效能)”），對日誌結構化儲存引擎的查詢響應時間有時會相當長，而B樹的行為則相對更具可預測性【28】。
壓縮的另一個問題出現在高寫入吞吐量：磁碟的有限寫入頻寬需要在初始寫入（記錄和重新整理記憶體表到磁碟）和在後臺執行的壓縮執行緒之間共享。寫入空資料庫時，可以使用全磁碟頻寬進行初始寫入，但資料庫越大，壓縮所需的磁碟頻寬就越多。
如果寫入吞吐量很高，並且壓縮沒有仔細配置，壓縮跟不上寫入速率。在這種情況下，磁碟上未合併段的數量不斷增加，直到磁碟空間用完，讀取速度也會減慢，因為它們需要檢查更多段檔案。通常情況下，即使壓縮無法跟上，基於SSTable的儲存引擎也不會限制傳入寫入的速率，所以您需要進行明確的監控來檢測這種情況【29,30】。
B樹的一個優點是每個鍵只存在於索引中的一個位置，而日誌結構化的儲存引擎可能在不同的段中有相同鍵的多個副本。這個方面使得B樹在想要提供強大的事務語義的資料庫中很有吸引力：在許多關係資料庫中，事務隔離是透過在鍵範圍上使用鎖來實現的，在B樹索引中，這些鎖可以直接連線到樹【5】。在[第7章](ch7.md)中，我們將更詳細地討論這一點。
B樹在資料庫體系結構中是非常根深蒂固的，為許多工作負載提供始終如一的良好效能，所以它們不可能很快就會消失。在新的資料儲存中，日誌結構化索引變得越來越流行。沒有快速和容易的規則來確定哪種型別的儲存引擎對你的場景更好，所以值得進行一些經驗上的測試。
### 其他索引結構
到目前為止，我們只討論了關鍵值索引，它們就像關係模型中的**主鍵（primary key）** 索引。主鍵唯一標識關係表中的一行，或文件資料庫中的一個文件或圖形資料庫中的一個頂點。資料庫中的其他記錄可以透過其主鍵（或ID）引用該行/文件/頂點，並且索引用於解析這樣的引用。
有二級索引也很常見。在關係資料庫中，您可以使用 `CREATE INDEX` 命令在同一個表上建立多個二級索引，而且這些索引通常對於有效地執行聯接而言至關重要。例如，在[第2章](ch2.md)中的[圖2-1](../img/fig2-1.png)中，很可能在 `user_id` 列上有一個二級索引，以便您可以在每個表中找到屬於同一使用者的所有行。
一個二級索引可以很容易地從一個鍵值索引構建。主要的不同是鍵不是唯一的。即可能有許多行（文件，頂點）具有相同的鍵。這可以透過兩種方式來解決：或者透過使索引中的每個值，成為匹配行識別符號的列表（如全文索引中的釋出列表），或者透過向每個索引新增行識別符號來使每個關鍵字唯一。無論哪種方式，B樹和日誌結構索引都可以用作輔助索引。
#### 將值儲存在索引中
索引中的關鍵字是查詢搜尋的內容，但是該值可以是以下兩種情況之一：它可以是所討論的實際行（文件，頂點），也可以是對儲存在別處的行的引用。在後一種情況下，行被儲存的地方被稱為**堆檔案（heap file）**，並且儲存的資料沒有特定的順序（它可以是僅附加的，或者可以跟蹤被刪除的行以便用新資料覆蓋它們後來）。堆檔案方法很常見，因為它避免了在存在多個二級索引時複製資料：每個索引只引用堆檔案中的一個位置，實際的資料儲存在一個地方。
在不更改鍵的情況下更新值時，堆檔案方法可以非常高效：只要新值不大於舊值，就可以覆蓋該記錄。如果新值更大，情況會更復雜，因為它可能需要移到堆中有足夠空間的新位置。在這種情況下，要麼所有的索引都需要更新，以指向記錄的新堆位置，或者在舊堆位置留下一個轉發指標【5】。
在某些情況下，從索引到堆檔案的額外跳躍對讀取來說效能損失太大，因此可能希望將索引行直接儲存在索引中。這被稱為聚集索引。例如，在MySQL的InnoDB儲存引擎中，表的主鍵總是一個聚簇索引，二級索引用主鍵（而不是堆檔案中的位置）【31】。在SQL Server中，可以為每個表指定一個聚簇索引【32】。
在 **聚集索引（clustered index）** （在索引中儲存所有行資料）和 **非聚集索引（nonclustered index）** （僅在索引中儲存對資料的引用）之間的折衷被稱為 **包含列的索引（index with included columns）**或**覆蓋索引（covering index）**，其儲存表的一部分在索引內【33】。這允許透過單獨使用索引來回答一些查詢（這種情況叫做：索引 **覆蓋（cover）** 了查詢）【32】。
與任何型別的資料重複一樣，聚簇和覆蓋索引可以加快讀取速度，但是它們需要額外的儲存空間，並且會增加寫入開銷。資料庫還需要額外的努力來執行事務保證，因為應用程式不應該因為重複而導致不一致。
#### 多列索引
至今討論的索引只是將一個鍵對映到一個值。如果我們需要同時查詢一個表中的多個列（或文件中的多個欄位），這顯然是不夠的。
最常見的多列索引被稱為 **連線索引（concatenated index）** ，它透過將一列的值追加到另一列後面，簡單地將多個欄位組合成一個鍵（索引定義中指定了欄位的連線順序）。這就像一個老式的紙質電話簿，它提供了一個從（姓，名）到電話號碼的索引。由於排序順序，索引可以用來查詢所有具有特定姓氏的人，或所有具有特定姓-名組合的人。**然而，如果你想找到所有具有特定名字的人，這個索引是沒有用的**。
**多維索引（multi-dimensional index）** 是一種查詢多個列的更一般的方法，這對於地理空間資料尤為重要。例如，餐廳搜尋網站可能有一個數據庫，其中包含每個餐廳的經度和緯度。當用戶在地圖上檢視餐館時，網站需要搜尋使用者正在檢視的矩形地圖區域內的所有餐館。這需要一個二維範圍查詢，如下所示：
```sql
SELECT * FROM restaurants WHERE latitude > 51.4946 AND latitude < 51.5079
AND longitude > -0.1162 AND longitude < -0.1004;
```
一個標準的B樹或者LSM樹索引不能夠高效地響應這種查詢：它可以返回一個緯度範圍內的所有餐館（但經度可能是任意值），或者返回在同一個經度範圍內的所有餐館（但緯度可能是北極和南極之間的任意地方），但不能同時滿足。
一種選擇是使用空間填充曲線將二維位置轉換為單個數字，然後使用常規B樹索引【34】。更普遍的是，使用特殊化的空間索引，例如R樹。例如，PostGIS使用PostgreSQL的通用Gist工具【35】將地理空間索引實現為R樹。這裡我們沒有足夠的地方來描述R樹，但是有大量的文獻可供參考。
一個有趣的主意是，多維索引不僅可以用於地理位置。例如，在電子商務網站上可以使用維度（紅色，綠色，藍色）上的三維索引來搜尋特定顏色範圍內的產品，也可以在天氣觀測資料庫中搜索二維（日期，溫度）的指數，以便有效地搜尋2013年的溫度在25至30°C之間的所有觀測資料。使用一維索引，你將不得不掃描2013年的所有記錄（不管溫度如何），然後透過溫度進行過濾，反之亦然。 二維索引可以同時透過時間戳和溫度來收窄資料集。這個技術被HyperDex使用【36】。
#### 全文搜尋和模糊索引
到目前為止所討論的所有索引都假定您有確切的資料，並允許您查詢鍵的確切值或具有排序順序的鍵的值範圍。他們不允許你做的是搜尋類似的鍵，如拼寫錯誤的單詞。這種模糊的查詢需要不同的技術。
例如，全文搜尋引擎通常允許搜尋一個單詞以擴充套件為包括該單詞的同義詞，忽略單詞的語法變體，並且搜尋在相同文件中彼此靠近的單詞的出現，並且支援各種其他功能取決於文字的語言分析。為了處理文件或查詢中的拼寫錯誤，Lucene能夠在一定的編輯距離內搜尋文字（編輯距離1意味著新增，刪除或替換了一個字母）【37】。
正如“[在SSTables中建立LSM樹](#在SSTables中建立LSM樹)”中所提到的，Lucene為其詞典使用了一個類似於SSTable的結構。這個結構需要一個小的記憶體索引，告訴查詢在排序檔案中哪個偏移量需要查詢關鍵字。在LevelDB中，這個記憶體中的索引是一些鍵的稀疏集合，但在Lucene中，記憶體中的索引是鍵中字元的有限狀態自動機，類似於trie 【38】。這個自動機可以轉換成Levenshtein自動機，它支援在給定的編輯距離內有效地搜尋單詞【39】。
其他的模糊搜尋技術正朝著文件分類和機器學習的方向發展。有關更多詳細資訊，請參閱資訊檢索教科書，例如【40】。
#### 在記憶體中儲存一切
本章到目前為止討論的資料結構都是對磁碟限制的回答。與主記憶體相比，磁碟處理起來很尷尬。對於磁碟和SSD，如果要在讀取和寫入時獲得良好效能，則需要仔細地佈置磁碟上的資料。但是，我們容忍這種尷尬，因為磁碟有兩個顯著的優點：它們是耐用的（它們的內容在電源關閉時不會丟失），並且每GB的成本比RAM低。
隨著RAM變得更便宜，每GB的成本價格被侵蝕了。許多資料集不是那麼大，所以將它們全部儲存在記憶體中是非常可行的，可能分佈在多個機器上。這導致了記憶體資料庫的發展。
某些記憶體中的鍵值儲存（如Memcached）僅用於快取，在重新啟動計算機時丟失的資料是可以接受的。但其他記憶體資料庫的目標是永續性，可以透過特殊的硬體（例如電池供電的RAM），將更改日誌寫入磁碟，將定時快照寫入磁碟或透過複製記憶體來實現，記憶狀態到其他機器。
記憶體資料庫重新啟動時，需要從磁碟或透過網路從副本重新載入其狀態（除非使用特殊的硬體）。儘管寫入磁碟，它仍然是一個記憶體資料庫，因為磁碟僅用作耐久性附加日誌，讀取完全由記憶體提供。寫入磁碟也具有操作優勢：磁碟上的檔案可以很容易地由外部實用程式進行備份，檢查和分析。
諸如VoltDB，MemSQL和Oracle TimesTen等產品是具有關係模型的記憶體資料庫，供應商聲稱，透過消除與管理磁碟上的資料結構相關的所有開銷，他們可以提供巨大的效能改進【41,42】。 RAM Cloud是一個開源的記憶體鍵值儲存器，具有永續性（對儲存器中的資料以及磁碟上的資料使用日誌結構化方法）【43】。 Redis和Couchbase透過非同步寫入磁碟提供了較弱的永續性。
反直覺的是，記憶體資料庫的效能優勢並不是因為它們不需要從磁碟讀取的事實。即使是基於磁碟的儲存引擎也可能永遠不需要從磁碟讀取，因為作業系統快取最近在記憶體中使用了磁碟塊。相反，它們更快的原因在於省去了將記憶體資料結構編碼為磁碟資料結構的開銷。【44】。
除了效能，記憶體資料庫的另一個有趣的領域是提供難以用基於磁碟的索引實現的資料模型。例如，Redis為各種資料結構（如優先順序佇列和集合）提供了類似資料庫的介面。因為它將所有資料儲存在記憶體中，所以它的實現相對簡單。
最近的研究表明，記憶體資料庫體系結構可以擴充套件到支援比可用記憶體更大的資料集，而不必重新採用以磁碟為中心的體系結構【45】。所謂的 **反快取（anti-caching）** 方法透過在記憶體不足的情況下將最近最少使用的資料從記憶體轉移到磁碟，並在將來再次訪問時將其重新載入到記憶體中。這與作業系統對虛擬記憶體和交換檔案的操作類似，但資料庫可以比作業系統更有效地管理記憶體，因為它可以按單個記錄的粒度工作，而不是整個記憶體頁面。儘管如此，這種方法仍然需要索引能完全放入記憶體中（就像本章開頭的Bitcask例子）。
如果 **非易失性儲存器（NVM）** 技術得到更廣泛的應用，可能還需要進一步改變儲存引擎設計【46】。目前這是一個新的研究領域，值得關注。
## 事務處理還是分析？
在業務資料處理的早期，對資料庫的寫入通常對應於正在進行的商業交易：進行銷售，向供應商下訂單，支付員工工資等等。隨著資料庫擴充套件到那些沒有不涉及錢易手，術語交易仍然卡住，指的是形成一個邏輯單元的一組讀寫。
事務不一定具有ACID（原子性，一致性，隔離性和永續性）屬性。事務處理只是意味著允許客戶端進行低延遲讀取和寫入 —— 而不是批次處理作業，而這些作業只能定期執行（例如每天一次）。我們在[第7章](ch7.md)中討論ACID屬性，在[第10章](ch10.md)中討論批處理。
即使資料庫開始被用於許多不同型別的部落格文章，遊戲中的動作，地址簿中的聯絡人等等，基本訪問模式仍然類似於處理業務事務。應用程式通常使用索引透過某個鍵查詢少量記錄。根據使用者的輸入插入或更新記錄。由於這些應用程式是互動式的，因此訪問模式被稱為 **線上事務處理（OLTP, OnLine Transaction Processing）** 。
但是，資料庫也開始越來越多地用於資料分析，這些資料分析具有非常不同的訪問模式。通常，分析查詢需要掃描大量記錄，每個記錄只讀取幾列，並計算彙總統計資訊（如計數，總和或平均值），而不是將原始資料返回給使用者。例如，如果您的資料是一個銷售交易表，那麼分析查詢可能是：
* 一月份每個商店的總收入是多少？
* 在最近的推廣活動中賣了多少香蕉？
* 哪個牌子的嬰兒食品最常與X品牌的尿布同時購買？
這些查詢通常由業務分析師編寫，並提供給幫助公司管理層做出更好決策（商業智慧）的報告。為了區分這種使用資料庫的事務處理模式，它被稱為**線上分析處理（OLAP, OnLine Analytice Processing）**。【47】。OLTP和OLAP之間的區別並不總是清晰的，但是一些典型的特徵在[表3-1]()中列出。
**表3-1 比較交易處理和分析系統的特點**
| 屬性 | 事務處理 OLTP | 分析系統 OLAP |
| :----------: | :--------------------------: | :----------------------: |
| 主要讀取模式 | 查詢少量記錄，按鍵讀取 | 在大批次記錄上聚合 |
| 主要寫入模式 | 隨機訪問，寫入要求低延時 | 批次匯入（ETL），事件流 |
| 主要使用者 | 終端使用者，透過Web應用 | 內部資料分析師，決策支援 |
| 處理的資料 | 資料的最新狀態（當前時間點） | 隨時間推移的歷史事件 |
| 資料集尺寸 | GB ~ TB | TB ~ PB |
起初，相同的資料庫用於事務處理和分析查詢。 SQL在這方面證明是非常靈活的：對於OLTP型別的查詢以及OLAP型別的查詢來說效果很好。儘管如此，在二十世紀八十年代末和九十年代初期，公司有停止使用OLTP系統進行分析的趨勢，而是在單獨的資料庫上執行分析。這個單獨的資料庫被稱為**資料倉庫（data warehouse）**。
### 資料倉庫
一個企業可能有幾十個不同的交易處理系統：面向終端客戶的網站，控制實體商店的收銀系統，跟蹤倉庫庫存，規劃車輛路線，供應鏈管理，員工管理等。這些系統中每一個都很複雜，需要專人維護，所以系統最終都是自動執行的。
這些OLTP系統往往對業務運作至關重要，因而通常會要求 **高可用** 與 **低延遲**。所以DBA會密切關注他們的OLTP資料庫，他們通常不願意讓業務分析人員在OLTP資料庫上執行臨時分析查詢，因為這些查詢通常開銷巨大，會掃描大部分資料集，這會損害同時執行的事務的效能。
相比之下，資料倉庫是一個獨立的資料庫，分析人員可以查詢他們想要的內容而不影響OLTP操作【48】。資料倉庫包含公司各種OLTP系統中所有的只讀資料副本。從OLTP資料庫中提取資料（使用定期的資料轉儲或連續的更新流），轉換成適合分析的模式，清理並載入到資料倉庫中。將資料存入倉庫的過程稱為“**抽取-轉換-載入（ETL）**”，如[圖3-8](../img/fig3-8)所示。
![](../img/fig3-8.png)
**圖3-8 ETL至資料倉庫的簡化提綱**
幾乎所有的大型企業都有資料倉庫，但在小型企業中幾乎聞所未聞。這可能是因為大多數小公司沒有這麼多不同的OLTP系統，大多數小公司只有少量的資料 —— 可以在傳統的SQL資料庫中查詢，甚至可以在電子表格中分析。在一家大公司裡，要做一些在一家小公司很簡單的事情，需要很多繁重的工作。
使用單獨的資料倉庫，而不是直接查詢OLTP系統進行分析的一大優勢是資料倉庫可針對分析訪問模式進行最佳化。事實證明，本章前半部分討論的索引演算法對於OLTP來說工作得很好，但對於回答分析查詢並不是很好。在本章的其餘部分中，我們將研究為分析而最佳化的儲存引擎。
#### OLTP資料庫和資料倉庫之間的分歧
資料倉庫的資料模型通常是關係型的，因為SQL通常很適合分析查詢。有許多圖形資料分析工具可以生成SQL查詢，視覺化結果，並允許分析人員探索資料（透過下鑽，切片和切塊等操作）。
表面上，一個數據倉庫和一個關係OLTP資料庫看起來很相似，因為它們都有一個SQL查詢介面。然而，系統的內部看起來可能完全不同，因為它們針對非常不同的查詢模式進行了最佳化。現在許多資料庫供應商都將重點放在支援事務處理或分析工作負載上，而不是兩者都支援。
一些資料庫（例如Microsoft SQL Server和SAP HANA）支援在同一產品中進行事務處理和資料倉庫。但是，它們正在日益成為兩個獨立的儲存和查詢引擎，這些引擎正好可以透過一個通用的SQL介面訪問【49,50,51】。
Teradata，Vertica，SAP HANA和ParAccel等資料倉庫供應商通常使用昂貴的商業許可證銷售他們的系統。 Amazon RedShift是ParAccel的託管版本。最近，大量的開源SQL-on-Hadoop專案已經出現，它們還很年輕，但是正在與商業資料倉庫系統競爭。這些包括Apache Hive，Spark SQL，Cloudera Impala，Facebook Presto，Apache Tajo和Apache Drill 【52,53】。其中一些是基於谷歌的Dremel [54]的想法。
### 星型和雪花型：分析的模式
正如[第2章](ch2.md)所探討的，根據應用程式的需要，在事務處理領域中使用了大量不同的資料模型。另一方面，在分析中，資料模型的多樣性則少得多。許多資料倉庫都以相當公式化的方式使用，被稱為星型模式（也稱為維度建模【55】）。
圖3-9中的示例模式顯示了可能在食品零售商處找到的資料倉庫。在模式的中心是一個所謂的事實表（在這個例子中，它被稱為 `fact_sales`）。事實表的每一行代表在特定時間發生的事件（這裡，每一行代表客戶購買的產品）。如果我們分析的是網站流量而不是零售量，則每行可能代表一個使用者的頁面瀏覽量或點選量。
![](../img/fig3-9.png)
**圖3-9 用於資料倉庫的星型模式的示例**
通常情況下，事實被視為單獨的事件，因為這樣可以在以後分析中獲得最大的靈活性。但是，這意味著事實表可以變得非常大。像蘋果，沃爾瑪或eBay這樣的大企業在其資料倉庫中可能有幾十PB的交易歷史，其中大部分實際上是表【56】。
事實表中的一些列是屬性，例如產品銷售的價格和從供應商那裡購買的成本（允許計算利潤餘額）。事實表中的其他列是對其他表（稱為維表）的外來鍵引用。由於事實表中的每一行都表示一個事件，因此這些維度代表事件的發生地點，時間，方式和原因。
例如，在[圖3-9](../img/fig3-9.md)中，其中一個維度是已售出的產品。 `dim_product` 表中的每一行代表一種待售產品，包括**庫存單位（SKU）**，說明，品牌名稱，類別，脂肪含量，包裝尺寸等。`fact_sales` 表中的每一行都使用外部表明在特定交易中銷售了哪些產品。 （為了簡單起見，如果客戶一次購買幾種不同的產品，則它們在事實表中被表示為單獨的行）。
即使日期和時間通常使用維度表來表示，因為這允許對日期（諸如公共假期）的附加資訊進行編碼，從而允許查詢區分假期和非假期的銷售。
“星型模式”這個名字來源於這樣一個事實，即當表關係視覺化時，事實表在中間，由維表包圍；與這些表的連線就像星星的光芒。
這個模板的變體被稱為雪花模式，其中尺寸被進一步分解為子尺寸。例如，品牌和產品類別可能有單獨的表格，並且 `dim_product` 表格中的每一行都可以將品牌和類別作為外來鍵引用，而不是將它們作為字串儲存在 `dim_product` 表格中。雪花模式比星形模式更規範化，但是星形模式通常是首選，因為分析師使用它更簡單【55】。
在典型的資料倉庫中，表格通常非常寬泛：事實表格通常有100列以上，有時甚至有數百列【51】。維度表也可以是非常寬的，因為它們包括可能與分析相關的所有元資料——例如，`dim_store` 表可以包括在每個商店提供哪些服務的細節，它是否具有店內麵包房，方形鏡頭，商店第一次開幕的日期，最後一次改造的時間，離最近的高速公路的距離等等。
## 列儲存
如果事實表中有萬億行和數PB的資料，那麼高效地儲存和查詢它們就成為一個具有挑戰性的問題。維度表通常要小得多（數百萬行），所以在本節中我們將主要關注事實的儲存。
儘管事實表通常超過100列，但典型的資料倉庫查詢一次只能訪問4個或5個查詢（ “ `SELECT *` ” 查詢很少用於分析）【51】。以[例3-1]()中的查詢為例：它訪問了大量的行（在2013日曆年中每次都有人購買水果或糖果），但只需訪問`fact_sales`表的三列：`date_key, product_sk, quantity`。查詢忽略所有其他列。
**例3-1 分析人們是否更傾向於購買新鮮水果或糖果，這取決於一週中的哪一天**
```sql
SELECT
dim_date.weekday,
dim_product.category,
SUM(fact_sales.quantity) AS quantity_sold
FROM fact_sales
JOIN dim_date ON fact_sales.date_key = dim_date.date_key
JOIN dim_product ON fact_sales.product_sk = dim_product.product_sk
WHERE
dim_date.year = 2013 AND
dim_product.category IN ('Fresh fruit', 'Candy')
GROUP BY
dim_date.weekday, dim_product.category;
```
我們如何有效地執行這個查詢？
在大多數OLTP資料庫中，儲存都是以面向行的方式進行佈局的：表格的一行中的所有值都相鄰儲存。文件資料庫是相似的：整個文件通常儲存為一個連續的位元組序列。你可以在[圖3-1](../img/fig3-1.png)的CSV例子中看到這個。
為了處理像[例3-1]()這樣的查詢，您可能在 `fact_sales.date_key`， `fact_sales.product_sk`上有索引，它們告訴儲存引擎在哪裡查詢特定日期或特定產品的所有銷售情況。但是，面向行的儲存引擎仍然需要將所有這些行（每個包含超過100個屬性）從磁碟載入到記憶體中，解析它們，並過濾掉那些不符合要求的條件。這可能需要很長時間。
面向列的儲存背後的想法很簡單：不要將所有來自一行的值儲存在一起，而是將來自每一列的所有值儲存在一起。如果每個列儲存在一個單獨的檔案中，查詢只需要讀取和解析查詢中使用的那些列，這可以節省大量的工作。這個原理如[圖3-10](../img/fig3-10.png)所示。
![](../img/fig3-10.png)
**圖3-10 使用列儲存關係型資料，而不是行**
列儲存在關係資料模型中是最容易理解的，但它同樣適用於非關係資料。例如，Parquet 【57】是一種列式儲存格式，支援基於Google的Dremel 【54】的文件資料模型。
面向列的儲存佈局依賴於包含相同順序行的每個列檔案。 因此，如果您需要重新組裝整行，您可以從每個單獨的列檔案中獲取第23項，並將它們放在一起形成表的第23行。
### 列壓縮
除了僅從磁碟載入查詢所需的列以外，我們還可以透過壓縮資料來進一步降低對磁碟吞吐量的需求。幸運的是，面向列的儲存通常很適合壓縮。
看看[圖3-10](../img/fig3-10.png)中每一列的值序列：它們通常看起來是相當重複的，這是壓縮的好兆頭。根據列中的資料，可以使用不同的壓縮技術。在資料倉庫中特別有效的一種技術是點陣圖編碼，如[圖3-11](../img/fig3-11.png)所示。
![](../img/fig3-11.png)
**圖3-11 壓縮點陣圖索引儲存佈局**
通常情況下，一列中不同值的數量與行數相比較小（例如，零售商可能有數十億的銷售交易，但只有100,000個不同的產品）。現在我們可以得到一個有 n 個不同值的列，並把它轉換成 n 個獨立的點陣圖：每個不同值的一個位圖，每行一位。如果該行具有該值，則該位為 1 ，否則為 0 。
如果 n 非常小（例如，國家/地區列可能有大約200個不同的值），則這些點陣圖可以每行儲存一位。但是，如果n更大，大部分點陣圖中將會有很多的零（我們說它們是稀疏的）。在這種情況下，點陣圖可以另外進行遊程編碼，如[圖3-11](fig3-11.png)底部所示。這可以使列的編碼非常緊湊。
這些點陣圖索引非常適合資料倉庫中常見的各種查詢。例如：
```sql
WHERE product_sk IN（30，68，69）
```
載入 `product_sk = 30` , `product_sk = 68` , `product_sk = 69` 的三個點陣圖，並計算三個點陣圖的按位或，這可以非常有效地完成。
```sql
WHERE product_sk = 31 AND store_sk = 3
```
載入 `product_sk = 31` 和 `store_sk = 3` 的點陣圖，並逐位計算AND。 這是因為列按照相同的順序包含行，因此一列的點陣圖中的第 k 位對應於與另一列的點陣圖中的第 k 位相同的行。
對於不同種類的資料，也有各種不同的壓縮方案，但我們不會詳細討論它們，參見【58】的概述。
> #### 面向列的儲存和列族
>
> Cassandra和HBase有一個列族的概念，他們從Bigtable繼承【9】。然而，把它們稱為面向列是非常具有誤導性的：在每個列族中，它們將一行中的所有列與行鍵一起儲存，並且不使用列壓縮。因此，Bigtable模型仍然主要是面向行的。
>
#### 記憶體頻寬和向量處理
對於需要掃描數百萬行的資料倉庫查詢來說，一個巨大的瓶頸是從磁盤獲取資料到記憶體的頻寬。但是，這不是唯一的瓶頸。分析資料庫的開發人員也擔心有效利用主儲存器頻寬到CPU快取中的頻寬，避免CPU指令處理流水線中的分支錯誤預測和泡沫，以及在現代中使用單指令多資料（SIMD）指令CPU 【59,60】。
除了減少需要從磁碟載入的資料量以外，面向列的儲存佈局也可以有效利用CPU週期。例如，查詢引擎可以將大量壓縮的列資料放在CPU的L1快取中，然後在緊密的迴圈中迴圈（即沒有函式呼叫）。一個CPU可以執行這樣一個迴圈比程式碼要快得多，這個程式碼需要處理每個記錄的大量函式呼叫和條件。列壓縮允許列中的更多行適合相同數量的L1快取。前面描述的按位“與”和“或”運算子可以被設計為直接在這樣的壓縮列資料塊上操作。這種技術被稱為向量化處理【58,49】。
### 列儲存中的排序順序
在列儲存中，儲存行的順序並不一定很重要。按插入順序儲存它們是最簡單的，因為插入一個新行就意味著附加到每個列檔案。但是，我們可以選擇強制執行一個命令，就像我們之前對SSTables所做的那樣，並將其用作索引機制。
注意，每列獨自排序是沒有意義的，因為那樣我們就不會知道列中的哪些項屬於同一行。我們只能重建一行，因為我們知道一列中的第k項與另一列中的第k項屬於同一行。
相反，即使按列儲存資料，也需要一次對整行進行排序。資料庫的管理員可以使用他們對常見查詢的知識來選擇表格應該被排序的列。例如，如果查詢通常以日期範圍為目標，例如上個月，則可以將 `date_key` 作為第一個排序鍵。然後，查詢最佳化器只能掃描上個月的行，這比掃描所有行要快得多。
第二列可以確定第一列中具有相同值的任何行的排序順序。例如，如果 `date_key` 是[圖3-10](../img/fig3-10.png)中的第一個排序關鍵字，那麼 `product_sk` 可能是第二個排序關鍵字，因此同一天的同一產品的所有銷售都將在儲存中組合在一起。這將有助於需要在特定日期範圍內按產品對銷售進行分組或過濾的查詢。
排序順序的另一個好處是它可以幫助壓縮列。如果主要排序列沒有多個不同的值，那麼在排序之後，它將具有很長的序列，其中相同的值連續重複多次。一個簡單的執行長度編碼（就像我們用於[圖3-11](../img/fig3-11.png)中的點陣圖一樣）可以將該列壓縮到幾千位元組 —— 即使表中有數十億行。
第一個排序鍵的壓縮效果最強。第二和第三個排序鍵會更混亂，因此不會有這麼長時間的重複值。排序優先順序下面的列以基本上隨機的順序出現，所以它們可能不會被壓縮。但前幾列排序仍然是一個整體。
#### 幾個不同的排序順序
這個想法的巧妙擴充套件在C-Store中引入，並在商業資料倉庫Vertica【61,62】中被採用。不同的查詢受益於不同的排序順序，為什麼不以相同的方式儲存相同的資料呢？無論如何，資料需要複製到多臺機器，這樣，如果一臺機器發生故障，您不會丟失資料。您可能還需要儲存以不同方式排序的冗餘資料，以便在處理查詢時，可以使用最適合查詢模式的版本。
在一個面向列的儲存中有多個排序順序有點類似於在一個面向行的儲存中有多個二級索引。但最大的區別在於面向行的儲存將每一行儲存在一個地方（在堆檔案或聚簇索引中），二級索引只包含指向匹配行的指標。在列儲存中，通常在其他地方沒有任何指向資料的指標，只有包含值的列。
### 寫入列儲存
這些最佳化在資料倉庫中是有意義的，因為大多數負載由分析人員執行的大型只讀查詢組成。面向列的儲存，壓縮和排序都有助於更快地讀取這些查詢。然而，他們有寫更加困難的缺點。
使用B樹的更新就地方法對於壓縮的列是不可能的。如果你想在排序表的中間插入一行，你很可能不得不重寫所有的列檔案。由於行由列中的位置標識，因此插入必須始終更新所有列。
幸運的是，本章前面已經看到了一個很好的解決方案：LSM樹。所有的寫操作首先進入一個記憶體中的儲存，在這裡它們被新增到一個已排序的結構中，並準備寫入磁碟。記憶體中的儲存是面向行還是列的，這並不重要。當已經積累了足夠的寫入資料時，它們將與磁碟上的列檔案合併，並批次寫入新檔案。這基本上是Vertica所做的【62】。
查詢需要檢查磁碟上的列資料和最近在記憶體中的寫入，並將兩者結合起來。但是，查詢最佳化器隱藏了使用者的這個區別。從分析師的角度來看，透過插入，更新或刪除操作進行修改的資料會立即反映在後續查詢中。
### 聚合：資料立方體和物化檢視
並不是每個資料倉庫都必定是一個列儲存：傳統的面向行的資料庫和其他一些架構也被使用。然而，對於專門的分析查詢，列式儲存可以顯著加快，所以它正在迅速普及【51,63】。
資料倉庫的另一個值得一提的是物化彙總。如前所述，資料倉庫查詢通常涉及一個聚合函式，如SQL中的COUNT，SUM，AVG，MIN或MAX。如果相同的聚合被許多不同的查詢使用，那麼每次都可以透過原始資料來處理。為什麼不快取一些查詢使用最頻繁的計數或總和？
建立這種快取的一種方式是物化檢視。在關係資料模型中，它通常被定義為一個標準（虛擬）檢視：一個類似於表的物件，其內容是一些查詢的結果。不同的是，物化檢視是查詢結果的實際副本，寫入磁碟，而虛擬檢視只是寫入查詢的捷徑。從虛擬檢視讀取時，SQL引擎會將其展開到檢視的底層查詢中，然後處理展開的查詢。
當底層資料發生變化時，物化檢視需要更新，因為它是資料的非規範化副本。資料庫可以自動完成，但是這樣的更新使得寫入成本更高，這就是在OLTP資料庫中不經常使用物化檢視的原因。在讀取繁重的資料倉庫中，它們可能更有意義（不管它們是否實際上改善了讀取效能取決於個別情況）。
物化檢視的常見特例稱為資料立方體或OLAP立方【64】。它是按不同維度分組的聚合網格。[圖3-12](../img/fig3-12.png)顯示了一個例子。
![](../img/fig3-12.png)
**圖3-12 資料立方的兩個維度，透過求和聚合**
想象一下，現在每個事實都只有兩個維度表的外來鍵——在[圖3-12](../img/fig-3-12.png)中，這些是日期和產品。您現在可以繪製一個二維表格，一個軸線上的日期和另一個軸上的產品。每個單元包含具有該日期 - 產品組合的所有事實的屬性（例如，`net_price`）的聚集（例如，`SUM`）。然後，您可以沿著每行或每列應用相同的彙總，並獲得一個維度減少的彙總（按產品的銷售額，無論日期，還是按日期銷售，無論產品如何）。
一般來說，事實往往有兩個以上的維度。在圖3-9中有五個維度：日期，產品，商店，促銷和客戶。要想象一個五維超立方體是什麼樣子是很困難的，但是原理是一樣的：每個單元格都包含特定日期（產品-商店-促銷-客戶）組合的銷售。這些值可以在每個維度上重複概括。
物化資料立方體的優點是某些查詢變得非常快，因為它們已經被有效地預先計算了。例如，如果您想知道每個商店的總銷售額，則只需檢視合適維度的總計，無需掃描數百萬行。
缺點是資料立方體不具有查詢原始資料的靈活性。例如，沒有辦法計算哪個銷售比例來自成本超過100美元的專案，因為價格不是其中的一個維度。因此，大多數資料倉庫試圖保留儘可能多的原始資料，並將聚合資料（如資料立方體）僅用作某些查詢的效能提升。
## 本章小結
在本章中，我們試圖深入瞭解資料庫如何處理儲存和檢索。將資料儲存在資料庫中會發生什麼，以及稍後再次查詢資料時資料庫會做什麼？
在高層次上，我們看到儲存引擎分為兩大類：最佳化 **事務處理（OLTP）** 或 **線上分析（OLAP）** 。這些用例的訪問模式之間有很大的區別：
* OLTP系統通常面向使用者，這意味著系統可能會收到大量的請求。為了處理負載，應用程式通常只訪問每個查詢中的少部分記錄。應用程式使用某種鍵來請求記錄，儲存引擎使用索引來查詢所請求的鍵的資料。磁碟尋道時間往往是這裡的瓶頸。
* 資料倉庫和類似的分析系統會低調一些，因為它們主要由業務分析人員使用，而不是由終端使用者使用。它們的查詢量要比OLTP系統少得多，但通常每個查詢開銷高昂，需要在短時間內掃描數百萬條記錄。磁碟頻寬（而不是查詢時間）往往是瓶頸，列式儲存是這種工作負載越來越流行的解決方案。
在OLTP方面，我們能看到兩派主流的儲存引擎：
***日誌結構學派***
只允許附加到檔案和刪除過時的檔案，但不會更新已經寫入的檔案。 Bitcask，SSTables，LSM樹，LevelDB，Cassandra，HBase，Lucene等都屬於這個類別。
***就地更新學派***
將磁碟視為一組可以覆寫的固定大小的頁面。 B樹是這種哲學的典範，用在所有主要的關係資料庫中和許多非關係型資料庫。
日誌結構的儲存引擎是相對較新的發展。他們的主要想法是，他們系統地將隨機訪問寫入順序寫入磁碟，由於硬碟驅動器和固態硬碟的效能特點，可以實現更高的寫入吞吐量。在完成OLTP方面，我們透過一些更復雜的索引結構和為保留所有資料而最佳化的資料庫做了一個簡短的介紹。
然後，我們從儲存引擎的內部繞開，看看典型資料倉庫的高階架構。這一背景說明了為什麼分析工作負載與OLTP差別很大：當您的查詢需要在大量行中順序掃描時，索引的相關性就會降低很多。相反，非常緊湊地編碼資料變得非常重要，以最大限度地減少查詢需要從磁碟讀取的資料量。我們討論了列式儲存如何幫助實現這一目標。
作為一名應用程式開發人員，如果您掌握了有關儲存引擎內部的知識，那麼您就能更好地瞭解哪種工具最適合您的特定應用程式。如果您需要調整資料庫的調整引數，這種理解可以讓您設想一個更高或更低的值可能會產生什麼效果。
儘管本章不能讓你成為一個特定儲存引擎的調參專家，但它至少有大概率使你有了足夠的概念與詞彙儲備去讀懂資料庫的文件，從而選擇合適的資料庫。
## 參考文獻
1. Alfred V. Aho, John E. Hopcroft, and Jeffrey D. Ullman: *Data Structures and Algorithms*. Addison-Wesley, 1983. ISBN: 978-0-201-00023-8
1. Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein: *Introduction to Algorithms*, 3rd edition. MIT Press, 2009. ISBN: 978-0-262-53305-8
1. Justin Sheehy and David Smith: “[Bitcask: A Log-Structured Hash Table for Fast Key/Value Data](http://basho.com/wp-content/uploads/2015/05/bitcask-intro.pdf),” Basho Technologies, April 2010.
1. Yinan Li, Bingsheng He, Robin Jun Yang, et al.: “[Tree Indexing on Solid State Drives](http://www.vldb.org/pvldb/vldb2010/papers/R106.pdf),” *Proceedings of the VLDB Endowment*, volume 3, number 1, pages 1195–1206, September 2010.
1. Goetz Graefe: “[Modern B-Tree Techniques](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.219.7269&rep=rep1&type=pdf),” *Foundations and Trends in Databases*, volume 3, number 4, pages 203–402, August 2011. [doi:10.1561/1900000028](http://dx.doi.org/10.1561/1900000028)
1. Jeffrey Dean and Sanjay Ghemawat: “[LevelDB Implementation Notes](https://github.com/google/leveldb/blob/master/doc/impl.html),” *leveldb.googlecode.com*.
1. Dhruba Borthakur: “[The History of RocksDB](http://rocksdb.blogspot.com/),” *rocksdb.blogspot.com*, November 24, 2013.
1. Matteo Bertozzi: “[Apache HBase I/O – HFile](http://blog.cloudera.com/blog/2012/06/hbase-io-hfile-input-output/),” *blog.cloudera.com*, June, 29 2012.
1. Fay Chang, Jeffrey Dean, Sanjay Ghemawat, et al.: “[Bigtable: A Distributed Storage System for Structured Data](http://research.google.com/archive/bigtable.html),” at *7th USENIX Symposium on Operating System Design and Implementation* (OSDI), November 2006.
1. Patrick O'Neil, Edward Cheng, Dieter Gawlick, and Elizabeth O'Neil: “[The Log-Structured Merge-Tree (LSM-Tree)](http://www.cs.umb.edu/~poneil/lsmtree.pdf),” *Acta Informatica*, volume 33, number 4, pages 351–385, June 1996. [doi:10.1007/s002360050048](http://dx.doi.org/10.1007/s002360050048)
1. Mendel Rosenblum and John K. Ousterhout: “[The Design and Implementation of a Log-Structured File System](http://research.cs.wisc.edu/areas/os/Qual/papers/lfs.pdf),” *ACM Transactions on Computer Systems*, volume 10, number 1, pages 26–52, February 1992.
[doi:10.1145/146941.146943](http://dx.doi.org/10.1145/146941.146943)
1. Adrien Grand: “[What Is in a Lucene Index?](http://www.slideshare.net/lucenerevolution/what-is-inaluceneagrandfinal),” at *Lucene/Solr Revolution*, November 14, 2013.
1. Deepak Kandepet: “[Hacking Lucene—The Index Format]( http://hackerlabs.github.io/blog/2011/10/01/hacking-lucene-the-index-format/index.html),” *hackerlabs.org*, October 1, 2011.
1. Michael McCandless: “[Visualizing Lucene's Segment Merges](http://blog.mikemccandless.com/2011/02/visualizing-lucenes-segment-merges.html),” *blog.mikemccandless.com*, February 11, 2011.
1. Burton H. Bloom: “[Space/Time Trade-offs in Hash Coding with Allowable Errors](http://www.cs.upc.edu/~diaz/p422-bloom.pdf),” *Communications of the ACM*, volume 13, number 7, pages 422–426, July 1970. [doi:10.1145/362686.362692](http://dx.doi.org/10.1145/362686.362692)
1. “[Operating Cassandra: Compaction](https://cassandra.apache.org/doc/latest/operating/compaction.html),” Apache Cassandra Documentation v4.0, 2016.
1. Rudolf Bayer and Edward M. McCreight: “[Organization and Maintenance of Large Ordered Indices](http://www.dtic.mil/cgi-bin/GetTRDoc?AD=AD0712079),” Boeing Scientific Research Laboratories, Mathematical and Information Sciences Laboratory, report no. 20, July 1970.
1. Douglas Comer: “[The Ubiquitous B-Tree](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.96.6637&rep=rep1&type=pdf),” *ACM Computing Surveys*, volume 11, number 2, pages 121–137, June 1979. [doi:10.1145/356770.356776](http://dx.doi.org/10.1145/356770.356776)
1. Emmanuel Goossaert: “[Coding for SSDs](http://codecapsule.com/2014/02/12/coding-for-ssds-part-1-introduction-and-table-of-contents/),” *codecapsule.com*, February 12, 2014.
1. C. Mohan and Frank Levine: “[ARIES/IM: An Efficient and High Concurrency Index Management Method Using Write-Ahead Logging](http://www.ics.uci.edu/~cs223/papers/p371-mohan.pdf),” at *ACM International Conference on Management of Data* (SIGMOD), June 1992. [doi:10.1145/130283.130338](http://dx.doi.org/10.1145/130283.130338)
1. Howard Chu: “[LDAP at Lightning Speed]( https://buildstuff14.sched.com/event/08a1a368e272eb599a52e08b4c3c779d),” at *Build Stuff '14*, November 2014.
1. Bradley C. Kuszmaul: “[A Comparison of Fractal Trees to Log-Structured Merge (LSM) Trees](http://insideanalysis.com/wp-content/uploads/2014/08/Tokutek_lsm-vs-fractal.pdf),” *tokutek.com*, April 22, 2014.
1. Manos Athanassoulis, Michael S. Kester, Lukas M. Maas, et al.: “[Designing Access Methods: The RUM Conjecture](http://openproceedings.org/2016/conf/edbt/paper-12.pdf),” at *19th International Conference on Extending Database Technology* (EDBT), March 2016.
[doi:10.5441/002/edbt.2016.42](http://dx.doi.org/10.5441/002/edbt.2016.42)
1. Peter Zaitsev: “[Innodb Double Write](https://www.percona.com/blog/2006/08/04/innodb-double-write/),” *percona.com*, August 4, 2006.
1. Tomas Vondra: “[On the Impact of Full-Page Writes](http://blog.2ndquadrant.com/on-the-impact-of-full-page-writes/),” *blog.2ndquadrant.com*, November 23, 2016.
1. Mark Callaghan: “[The Advantages of an LSM vs a B-Tree](http://smalldatum.blogspot.co.uk/2016/01/summary-of-advantages-of-lsm-vs-b-tree.html),” *smalldatum.blogspot.co.uk*, January 19, 2016.
1. Mark Callaghan: “[Choosing Between Efficiency and Performance with RocksDB](http://www.codemesh.io/codemesh/mark-callaghan),” at *Code Mesh*, November 4, 2016.
1. Michi Mutsuzaki: “[MySQL vs. LevelDB](https://github.com/m1ch1/mapkeeper/wiki/MySQL-vs.-LevelDB),” *github.com*, August 2011.
1. Benjamin Coverston, Jonathan Ellis, et al.: “[CASSANDRA-1608: Redesigned Compaction](https://issues.apache.org/jira/browse/CASSANDRA-1608), *issues.apache.org*, July 2011.
1. Igor Canadi, Siying Dong, and Mark Callaghan: “[RocksDB Tuning Guide](https://github.com/facebook/rocksdb/wiki/RocksDB-Tuning-Guide),”
*github.com*, 2016.
1. [*MySQL 5.7 Reference Manual*](http://dev.mysql.com/doc/refman/5.7/en/index.html). Oracle, 2014.
1. [*Books Online for SQL Server 2012*](http://msdn.microsoft.com/en-us/library/ms130214.aspx). Microsoft, 2012.
1. Joe Webb: “[Using Covering Indexes to Improve Query Performance](https://www.simple-talk.com/sql/learn-sql-server/using-covering-indexes-to-improve-query-performance/),” *simple-talk.com*, 29 September 2008.
1. Frank Ramsak, Volker Markl, Robert Fenk, et al.: “[Integrating the UB-Tree into a Database System Kernel](http://www.vldb.org/conf/2000/P263.pdf),” at *26th International Conference on Very Large Data Bases* (VLDB), September 2000.
1. The PostGIS Development Group: “[PostGIS 2.1.2dev Manual](http://postgis.net/docs/manual-2.1/),” *postgis.net*, 2014.
1. Robert Escriva, Bernard Wong, and Emin Gün Sirer: “[HyperDex: A Distributed, Searchable Key-Value Store](http://www.cs.princeton.edu/courses/archive/fall13/cos518/papers/hyperdex.pdf),” at *ACM SIGCOMM Conference*, August 2012. [doi:10.1145/2377677.2377681](http://dx.doi.org/10.1145/2377677.2377681)
1. Michael McCandless: “[Lucene's FuzzyQuery Is 100 Times Faster in 4.0](http://blog.mikemccandless.com/2011/03/lucenes-fuzzyquery-is-100-times-faster.html),” *blog.mikemccandless.com*, March 24, 2011.
1. Steffen Heinz, Justin Zobel, and Hugh E. Williams: “[Burst Tries: A Fast, Efficient Data Structure for String Keys](http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.18.3499),” *ACM Transactions on Information Systems*, volume 20, number 2, pages 192–223, April 2002. [doi:10.1145/506309.506312](http://dx.doi.org/10.1145/506309.506312)
1. Klaus U. Schulz and Stoyan Mihov: “[Fast String Correction with Levenshtein Automata](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.16.652),” *International Journal on Document Analysis and Recognition*, volume 5, number 1, pages 67–85, November 2002. [doi:10.1007/s10032-002-0082-8](http://dx.doi.org/10.1007/s10032-002-0082-8)
1. Christopher D. Manning, Prabhakar Raghavan, and Hinrich Schütze: [*Introduction to Information Retrieval*](http://nlp.stanford.edu/IR-book/). Cambridge University Press, 2008. ISBN: 978-0-521-86571-5, available online at *nlp.stanford.edu/IR-book*
1. Michael Stonebraker, Samuel Madden, Daniel J. Abadi, et al.: “[The End of an Architectural Era (It’s Time for a Complete Rewrite)](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.137.3697&rep=rep1&type=pdf),” at *33rd International Conference on Very Large Data Bases* (VLDB), September 2007.
1. “[VoltDB Technical Overview White Paper](https://www.voltdb.com/wptechnicaloverview),” VoltDB, 2014.
1. Stephen M. Rumble, Ankita Kejriwal, and John K. Ousterhout: “[Log-Structured Memory for DRAM-Based Storage](https://www.usenix.org/system/files/conference/fast14/fast14-paper_rumble.pdf),” at *12th USENIX Conference on File and Storage Technologies* (FAST), February 2014.
1. Stavros Harizopoulos, Daniel J. Abadi, Samuel Madden, and Michael Stonebraker: “[OLTP Through the Looking Glass, and What We Found There](http://hstore.cs.brown.edu/papers/hstore-lookingglass.pdf),” at *ACM International Conference on Management of Data*
(SIGMOD), June 2008. [doi:10.1145/1376616.1376713](http://dx.doi.org/10.1145/1376616.1376713)
1. Justin DeBrabant, Andrew Pavlo, Stephen Tu, et al.: “[Anti-Caching: A New Approach to Database Management System Architecture](http://www.vldb.org/pvldb/vol6/p1942-debrabant.pdf),” *Proceedings of the VLDB Endowment*, volume 6, number 14, pages 1942–1953, September 2013.
1. Joy Arulraj, Andrew Pavlo, and Subramanya R. Dulloor: “[Let's Talk About Storage & Recovery Methods for Non-Volatile Memory Database Systems](http://www.pdl.cmu.edu/PDL-FTP/NVM/storage.pdf),” at *ACM International Conference on Management of Data* (SIGMOD), June 2015. [doi:10.1145/2723372.2749441](http://dx.doi.org/10.1145/2723372.2749441)
1. Edgar F. Codd, S. B. Codd, and C. T. Salley: “[Providing OLAP to User-Analysts: An IT Mandate](http://www.minet.uni-jena.de/dbis/lehre/ss2005/sem_dwh/lit/Cod93.pdf),” E. F. Codd Associates, 1993.
1. Surajit Chaudhuri and Umeshwar Dayal: “[An Overview of Data Warehousing and OLAP Technology](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/sigrecord.pdf),” *ACM SIGMOD Record*, volume 26, number 1, pages 65–74, March 1997. [doi:10.1145/248603.248616](http://dx.doi.org/10.1145/248603.248616)
1. Per-Åke Larson, Cipri Clinciu, Campbell Fraser, et al.: “[Enhancements to SQL Server Column Stores](http://research.microsoft.com/pubs/193599/Apollo3%20-%20Sigmod%202013%20-%20final.pdf),” at *ACM International Conference on Management of Data* (SIGMOD), June 2013.
1. Franz Färber, Norman May, Wolfgang Lehner, et al.: “[The SAP HANA Database – An Architecture Overview](http://sites.computer.org/debull/A12mar/hana.pdf),” *IEEE Data Engineering Bulletin*, volume 35, number 1, pages 28–33, March 2012.
1. Michael Stonebraker: “[The Traditional RDBMS Wisdom Is (Almost Certainly) All Wrong](http://slideshot.epfl.ch/talks/166),” presentation at *EPFL*, May 2013.
1. Daniel J. Abadi: “[Classifying the SQL-on-Hadoop Solutions](https://web.archive.org/web/20150622074951/http://hadapt.com/blog/2013/10/02/classifying-the-sql-on-hadoop-solutions/),” *hadapt.com*, October 2, 2013.
1. Marcel Kornacker, Alexander Behm, Victor Bittorf, et al.: “[Impala: A Modern, Open-Source SQL Engine for Hadoop](http://pandis.net/resources/cidr15impala.pdf),” at *7th Biennial Conference on Innovative Data Systems Research* (CIDR), January 2015.
1. Sergey Melnik, Andrey Gubarev, Jing Jing Long, et al.: “[Dremel: Interactive Analysis of Web-Scale Datasets](http://research.google.com/pubs/pub36632.html),” at *36th International Conference on Very Large Data Bases* (VLDB), pages
330–339, September 2010.
1. Ralph Kimball and Margy Ross: *The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling*, 3rd edition. John Wiley & Sons, July 2013. ISBN: 978-1-118-53080-1
1. Derrick Harris: “[Why Apple, eBay, and Walmart Have Some of the Biggest Data Warehouses You’ve Ever Seen](http://gigaom.com/2013/03/27/why-apple-ebay-and-walmart-have-some-of-the-biggest-data-warehouses-youve-ever-seen/),” *gigaom.com*, March 27, 2013.
1. Julien Le Dem: “[Dremel Made Simple with Parquet](https://blog.twitter.com/2013/dremel-made-simple-with-parquet),” *blog.twitter.com*, September 11, 2013.
1. Daniel J. Abadi, Peter Boncz, Stavros Harizopoulos, et al.: “[The Design and Implementation of Modern Column-Oriented Database Systems](http://cs-www.cs.yale.edu/homes/dna/papers/abadi-column-stores.pdf),” *Foundations and Trends in Databases*, volume 5, number 3, pages 197–280, December 2013. [doi:10.1561/1900000024](http://dx.doi.org/10.1561/1900000024)
1. Peter Boncz, Marcin Zukowski, and Niels Nes: “[MonetDB/X100: Hyper-Pipelining Query Execution](http://www.cidrdb.org/cidr2005/papers/P19.pdf),”
at *2nd Biennial Conference on Innovative Data Systems Research* (CIDR), January 2005.
1. Jingren Zhou and Kenneth A. Ross: “[Implementing Database Operations Using SIMD Instructions](http://www1.cs.columbia.edu/~kar/pubsk/simd.pdf),”
at *ACM International Conference on Management of Data* (SIGMOD), pages 145–156, June 2002.
[doi:10.1145/564691.564709](http://dx.doi.org/10.1145/564691.564709)
1. Michael Stonebraker, Daniel J. Abadi, Adam Batkin, et al.: “[C-Store: A Column-oriented DBMS](http://www.vldb2005.org/program/paper/thu/p553-stonebraker.pdf),”
at *31st International Conference on Very Large Data Bases* (VLDB), pages 553–564, September 2005.
1. Andrew Lamb, Matt Fuller, Ramakrishna Varadarajan, et al.: “[The Vertica Analytic Database: C-Store 7 Years Later](http://vldb.org/pvldb/vol5/p1790_andrewlamb_vldb2012.pdf),” *Proceedings of the VLDB Endowment*, volume 5, number 12, pages 1790–1801, August 2012.
1. Julien Le Dem and Nong Li: “[Efficient Data Storage for Analytics with Apache Parquet 2.0](http://www.slideshare.net/julienledem/th-210pledem),” at *Hadoop Summit*, San Jose, June 2014.
1. Jim Gray, Surajit Chaudhuri, Adam Bosworth, et al.: “[Data Cube: A Relational Aggregation Operator Generalizing Group-By, Cross-Tab, and Sub-Totals](http://arxiv.org/pdf/cs/0701155.pdf),” *Data Mining and Knowledge Discovery*, volume 1, number 1, pages 29–53, March 2007. [doi:10.1023/A:1009726021843](http://dx.doi.org/10.1023/A:1009726021843)
------
| 上一章 | 目錄 | 下一章 |
| ------------------------------------ | ------------------------------- | ---------------------------- |
| [第二章：資料模型與查詢語言](ch2.md) | [設計資料密集型應用](README.md) | [第四章：編碼與演化](ch4.md) |

640
zh-tw/ch4.md Normal file
View File

@ -0,0 +1,640 @@
# 4. 編碼與演化
![](../img/ch4.png)
> 唯變所適
>
> ——以弗所的赫拉克利特，為柏拉圖所引（公元前360年）
>
-------------------
[TOC]
應用程式不可避免地隨時間而變化。新產品的推出，對需求的深入理解，或者商業環境的變化，總會伴隨著**功能（feature）**的增增改改。[第一章](ch1.md)介紹了[**可演化性(evolvability)**](ch1.md#可演化性：擁抱變化)的概念：應該盡力構建能靈活適應變化的系統（參閱“[可演化性：擁抱變化]()”）。
在大多數情況下，修改應用程式的功能也意味著需要更改其儲存的資料：可能需要使用新的欄位或記錄型別，或者以新方式展示現有資料。
我們在[第二章](ch2.md)討論的資料模型有不同的方法來應對這種變化。關係資料庫通常假定資料庫中的所有資料都遵循一個模式：儘管可以更改該模式（透過模式遷移，即`ALTER`語句），但是在任何時間點都有且僅有一個正確的模式。相比之下，**讀時模式（schema-on-read）**（或 **無模式（schemaless）**）資料庫不會強制一個模式，因此資料庫可以包含在不同時間寫入的新老資料格式的混合（參閱 “文件模型中的模式靈活性” ）。
當資料**格式（format）**或**模式（schema）**發生變化時，通常需要對應用程式程式碼進行相應的更改（例如，為記錄新增新欄位，然後修改程式開始讀寫該欄位）。但在大型應用程式中，程式碼變更通常不會立即完成：
* 對於 **服務端（server-side）** 應用程式，可能需要執行 **滾動升級 （rolling upgrade）** （也稱為 **階段釋出（staged rollout）** ），一次將新版本部署到少數幾個節點，檢查新版本是否執行正常，然後逐漸部完所有的節點。這樣無需中斷服務即可部署新版本，為頻繁釋出提供了可行性，從而帶來更好的可演化性。
* 對於 **客戶端（client-side）** 應用程式，升不升級就要看使用者的心情了。使用者可能相當長一段時間裡都不會去升級軟體。
這意味著，新舊版本的程式碼，以及新舊資料格式可能會在系統中同時共處。系統想要繼續順利執行，就需要保持**雙向相容性**：
***向後相容 (backward compatibility)***
​ 新程式碼可以讀舊資料。
***向前相容 (forward compatibility)***
​ 舊程式碼可以讀新資料。
向後相容性通常並不難實現：新程式碼的作者當然知道由舊程式碼使用的資料格式，因此可以顯示地處理它（最簡單的辦法是，保留舊程式碼即可讀取舊資料）。
向前相容性可能會更棘手，因為舊版的程式需要忽略新版資料格式中新增的部分。
本章中將介紹幾種編碼資料的格式，包括 JSON，XML，Protocol Buffers，Thrift和Avro。尤其將關注這些格式如何應對模式變化，以及它們如何對新舊程式碼資料需要共存的系統提供支援。然後將討論如何使用這些格式進行資料儲存和通訊：在Web服務中，**具象狀態傳輸（REST）**和**遠端過程呼叫（RPC）**，以及**訊息傳遞系統**（如Actor和訊息佇列）。
## 編碼資料的格式
程式通常（至少）使用兩種形式的資料：
1. 在記憶體中，資料儲存在物件，結構體，列表，陣列，雜湊表，樹等中。 這些資料結構針對CPU的高效訪問和操作進行了最佳化（通常使用指標）。
2. 如果要將資料寫入檔案，或透過網路傳送，則必須將其 **編碼（encode）** 為某種自包含的位元組序列（例如，JSON文件）。 由於每個程序都有自己獨立的地址空間，一個程序中的指標對任何其他程序都沒有意義，所以這個位元組序列表示會與通常在記憶體中使用的資料結構完全不同[^i]。
[^i]: 除一些特殊情況外，例如某些記憶體對映檔案或直接在壓縮資料上操作（如“[列壓縮](ch4.md#列壓縮)”中所述）。
所以，需要在兩種表示之間進行某種型別的翻譯。 從記憶體中表示到位元組序列的轉換稱為 **編碼（Encoding）** （也稱為**序列化（serialization）**或**編組（marshalling）**），反過來稱為**解碼（Decoding）**[^ii]（**解析（Parsing）**，**反序列化（deserialization）**，**反編組( unmarshalling）**）[^譯i]。
[^ii]: 請注意，**編碼（encode）** 與 **加密（encryption）** 無關。 本書不討論加密。
[^譯i]: Marshal與Serialization的區別：Marshal不僅傳輸物件的狀態，而且會一起傳輸物件的方法（相關程式碼）。
> #### 術語衝突
> 不幸的是，在[第七章](ch7.md)： **事務（Transaction）** 的上下文裡，**序列化（Serialization）** 這個術語也出現了，而且具有完全不同的含義。儘管序列化可能是更常見的術語，為了避免術語過載，本書中堅持使用 **編碼（Encoding）** 表達此含義。
這是一個常見的問題，因而有許多庫和編碼格式可供選擇。 首先讓我們概覽一下。
### 語言特定的格式
許多程式語言都內建了將記憶體物件編碼為位元組序列的支援。例如，Java有`java.io.Serializable` 【1】，Ruby有`Marshal`【2】，Python有`pickle`【3】等等。許多第三方庫也存在，例如`Kryo for Java` 【4】。
這些編碼庫非常方便，可以用很少的額外程式碼實現記憶體物件的儲存與恢復。但是它們也有一些深層次的問題：
* 這類編碼通常與特定的程式語言深度繫結，其他語言很難讀取這種資料。如果以這類編碼儲存或傳輸資料，那你就和這門語言綁死在一起了。並且很難將系統與其他組織的系統（可能用的是不同的語言）進行整合。
* 為了恢復相同物件型別的資料，解碼過程需要**例項化任意類**的能力，這通常是安全問題的一個來源【5】：如果攻擊者可以讓應用程式解碼任意的位元組序列，他們就能例項化任意的類，這會允許他們做可怕的事情，如遠端執行任意程式碼【6,7】。
* 在這些庫中，資料版本控制通常是事後才考慮的。因為它們旨在快速簡便地對資料進行編碼，所以往往忽略了前向後向相容性帶來的麻煩問題。
* 效率（編碼或解碼所花費的CPU時間，以及編碼結構的大小）往往也是事後才考慮的。 例如，Java的內建序列化由於其糟糕的效能和臃腫的編碼而臭名昭著【8】。
因此，除非臨時使用，採用語言內建編碼通常是一個壞主意。
### JSON，XML和二進位制變體
談到可以被許多程式語言編寫和讀取的標準化編碼，JSON和XML是顯眼的競爭者。它們廣為人知，廣受支援，也“廣受憎惡”。 XML經常被批評為過於冗長和不必要的複雜【9】。 JSON倍受歡迎，主要由於它在Web瀏覽器中的內建支援（透過成為JavaScript的一個子集）以及相對於XML的簡單性。 CSV是另一種流行的與語言無關的格式，儘管功能較弱。
JSON，XML和CSV是文字格式，因此具有人類可讀性（儘管語法是一個熱門辯題）。除了表面的語法問題之外，它們也有一些微妙的問題：
* 數字的編碼多有歧義之處。XML和CSV不能區分數字和字串（除非引用外部模式）。 JSON雖然區分字串和數字，但不區分整數和浮點數，而且不能指定精度。
* 當處理大量資料時，這個問題更嚴重了。例如，大於$2^{53}$的整數不能在IEEE 754雙精度浮點數中精確表示，因此在使用浮點數（例如JavaScript）的語言進行分析時，這些數字會變得不準確。 Twitter上有一個大於$2^{53}$的數字的例子，它使用一個64位的數字來標識每條推文。 Twitter API返回的JSON包含了兩種推特ID，一個JSON數字，另一個是十進位制字串，以此避免JavaScript程式無法正確解析數字的問題【10】。
* JSON和XML對Unicode字串（即人類可讀的文字）有很好的支援，但是它們不支援二進位制資料（不帶字元編碼(character encoding)的位元組序列）。二進位制串是很實用的功能，所以人們透過使用Base64將二進位制資料編碼為文字來繞開這個限制。模式然後用於表示該值應該被解釋為Base64編碼。這個工作，但它有點hacky，並增加了33％的資料大小。 XML 【11】和JSON 【12】都有可選的模式支援。這些模式語言相當強大，所以學習和實現起來相當複雜。 XML模式的使用相當普遍，但許多基於JSON的工具嫌麻煩才不會使用模式。由於資料的正確解釋（例如數字和二進位制字串）取決於模式中的資訊，因此不使用XML/JSON模式的應用程式可能需要對相應的編碼/解碼邏輯進行硬編碼。
* CSV沒有任何模式，因此應用程式需要定義每行和每列的含義。如果應用程式更改新增新的行或列，則必須手動處理該變更。 CSV也是一個相當模糊的格式（如果一個值包含逗號或換行符，會發生什麼？）。儘管其轉義規則已經被正式指定【13】，但並不是所有的解析器都正確的實現了標準。
儘管存在這些缺陷，但JSON，XML和CSV已經足夠用於很多目的。特別是作為資料交換格式（即將資料從一個組織傳送到另一個組織），它們很可能仍然很受歡迎。這種情況下，只要人們對格式是什麼意見一致，格式多麼美觀或者高效就沒有關係。**讓不同的組織達成一致的難度超過了其他大多數問題。**
#### 二進位制編碼
對於僅在組織內部使用的資料，使用最小公分母編碼格式的壓力較小。例如，可以選擇更緊湊或更快的解析格式。雖然對小資料集來說，收益可以忽略不計，但一旦達到TB級別，資料格式的選擇就會產生巨大的影響。
JSON比XML簡潔，但與二進位制格式一比，還是太佔地方。這一事實導致大量二進位制編碼版本JSON & XML的出現，JSON（MessagePack，BSON，BJSON，UBJSON，BISON和Smile等）（例如WBXML和Fast Infoset）。這些格式已經被各種各樣的領域所採用，但是沒有一個像JSON和XML的文字版本那樣被廣泛採用。
這些格式中的一些擴充套件了一組資料型別（例如，區分整數和浮點數，或者增加對二進位制字串的支援），另一方面，它們沒有蓋面JSON / XML的資料模型。特別是由於它們沒有規定模式，所以它們需要在編碼資料中包含所有的物件欄位名稱。也就是說，在[例4-1]()中的JSON文件的二進位制編碼中，需要在某處包含字串`userName`，`favoriteNumber`和`interest`。
**例4-1 本章中用於展示二進位制編碼的示例記錄**
```json
{
"userName": "Martin",
"favoriteNumber": 1337,
"interests": ["daydreaming", "hacking"]
}
```
我們來看一個MessagePack的例子，它是一個JSON的二進位制編碼。圖4-1顯示瞭如果使用MessagePack 【14】對[例4-1]()中的JSON文件進行編碼，則得到的位元組序列。前幾個位元組如下：
1. 第一個位元組`0x83`表示接下來是**3**個欄位（低四位= `0x03`）的**物件 object**（高四位= `0x80`）。 （如果想知道如果一個物件有15個以上的欄位會發生什麼情況，欄位的數量塞不進4個bit裡，那麼它會用另一個不同的型別識別符號，欄位的數量被編碼兩個或四個位元組）。
2. 第二個位元組`0xa8`表示接下來是**8**位元組長的字串（最高四位= 0x08）。
3. 接下來八個位元組是ASCII字串形式的欄位名稱`userName`。由於之前已經指明長度，不需要任何標記來標識字串的結束位置（或者任何轉義）。
4. 接下來的七個位元組對字首為`0xa6`的六個字母的字串值`Martin`進行編碼，依此類推。
二進位制編碼長度為66個位元組，僅略小於文字JSON編碼所取的81個位元組（刪除了空白）。所有的JSON的二進位制編碼在這方面是相似的。空間節省了一丁點（以及解析加速）是否能彌補可讀性的損失，誰也說不準。
在下面的章節中，能達到比這好得多的結果，只用32個位元組對相同的記錄進行編碼。
![](../img/fig4-1.png)
**圖4-1 使用MessagePack編碼的記錄（例4-1）**
### Thrift與Protocol Buffers
Apache Thrift 【15】和Protocol Buffers（protobuf）【16】是基於相同原理的二進位制編碼庫。 Protocol Buffers最初是在Google開發的，Thrift最初是在Facebook開發的，並且在2007~2008年都是開源的【17】。
Thrift和Protocol Buffers都需要一個模式來編碼任何資料。要在Thrift的[例4-1]()中對資料進行編碼，可以使用Thrift **介面定義語言（IDL）** 來描述模式，如下所示：
```c
struct Person {
1: required string userName,
2: optional i64 favoriteNumber,
3: optional list<string> interests
}
```
Protocol Buffers的等效模式定義看起來非常相似：
```protobuf
message Person {
required string user_name = 1;
optional int64 favorite_number = 2;
repeated string interests = 3;
}
```
Thrift和Protocol Buffers每一個都帶有一個程式碼生成工具，它採用了類似於這裡所示的模式定義，並且生成了以各種程式語言實現模式的類【18】。您的應用程式程式碼可以呼叫此生成的程式碼來對模式的記錄進行編碼或解碼。
用這個模式編碼的資料是什麼樣的？令人困惑的是，Thrift有兩種不同的二進位制編碼格式[^iii]，分別稱為BinaryProtocol和CompactProtocol。先來看看BinaryProtocol。使用這種格式的編碼來編碼[例4-1]()中的訊息只需要59個位元組，如[圖4-2](../img/fig4-2.png)所示【19】。
![](../img/fig4-2.png)
**圖4-2 使用Thrift二進位制協議編碼的記錄**
[^iii]: 實際上，Thrift有三種二進位制協議：CompactProtocol和DenseProtocol，儘管DenseProtocol只支援C ++實現，所以不算作跨語言[18]。 除此之外，它還有兩種不同的基於JSON的編碼格式【19】。 真逗！
與[圖4-1](Img/fig4-1.png)類似，每個欄位都有一個型別註釋（用於指示它是一個字串，整數，列表等），還可以根據需要指定長度（字串的長度，列表中的專案數） 。出現在資料中的字串`(“Martin”, “daydreaming”, “hacking”)`也被編碼為ASCII（或者說，UTF-8），與之前類似。
與[圖4-1](../img/fig4-1.png)相比，最大的區別是沒有欄位名`(userName, favoriteNumber, interest)`。相反，編碼資料包含欄位標籤，它們是數字`(1, 2和3)`。這些是模式定義中出現的數字。欄位標記就像欄位的別名 - 它們是說我們正在談論的欄位的一種緊湊的方式，而不必拼出欄位名稱。
Thrift CompactProtocol編碼在語義上等同於BinaryProtocol，但是如[圖4-3](../img/fig4-3.png)所示，它只將相同的資訊打包成只有34個位元組。它透過將欄位型別和標籤號打包到單個位元組中，並使用可變長度整數來實現。數字1337不是使用全部八個位元組，而是用兩個位元組編碼，每個位元組的最高位用來指示是否還有更多的位元組來。這意味著-64到63之間的數字被編碼為一個位元組，-8192和8191之間的數字以兩個位元組編碼，等等。較大的數字使用更多的位元組。
![](../img/fig4-3.png)
**圖4-3 使用Thrift壓縮協議編碼的記錄**
最後，Protocol Buffers（只有一種二進位制編碼格式）對相同的資料進行編碼，如[圖4-4](../img/fig4-4.png)所示。 它的打包方式稍有不同，但與Thrift的CompactProtocol非常相似。 Protobuf將同樣的記錄塞進了33個位元組中。
![](../img/fig4-4.png)
**圖4-4 使用Protobuf編碼的記錄**
需要注意的一個細節：在前面所示的模式中，每個欄位被標記為必需或可選，但是這對欄位如何編碼沒有任何影響（二進位制資料中沒有任何欄位指示是否需要欄位）。所不同的是，如果未設定該欄位，則所需的執行時檢查將失敗，這對於捕獲錯誤非常有用。
#### 欄位標籤和模式演變
我們之前說過，模式不可避免地需要隨著時間而改變。我們稱之為模式演變。 Thrift和Protocol Buffers如何處理模式更改，同時保持向後相容性？
從示例中可以看出，編碼的記錄就是其編碼欄位的拼接。每個欄位由其標籤號碼（樣本模式中的數字1,2,3）標識，並用資料型別（例如字串或整數）註釋。如果沒有設定欄位值，則簡單地從編碼記錄中省略。從中可以看到，欄位標記對編碼資料的含義至關重要。您可以更改架構中欄位的名稱，因為編碼的資料永遠不會引用欄位名稱，但不能更改欄位的標記，因為這會使所有現有的編碼資料無效。
您可以新增新的欄位到架構，只要您給每個欄位一個新的標籤號碼。如果舊的程式碼（不知道你新增的新的標籤號碼）試圖讀取新程式碼寫入的資料，包括一個新的欄位，其標籤號碼不能識別，它可以簡單地忽略該欄位。資料型別註釋允許解析器確定需要跳過的位元組數。這保持了前向相容性：舊程式碼可以讀取由新程式碼編寫的記錄。
向後相容性呢？只要每個欄位都有一個唯一的標籤號碼，新的程式碼總是可以讀取舊的資料，因為標籤號碼仍然具有相同的含義。唯一的細節是，如果你新增一個新的領域，你不能要求。如果您要新增一個欄位並將其設定為必需，那麼如果新程式碼讀取舊程式碼寫入的資料，則該檢查將失敗，因為舊程式碼不會寫入您新增的新欄位。因此，為了保持向後相容性，在模式的初始部署之後 **新增的每個欄位必須是可選的或具有預設值**。
刪除一個欄位就像新增一個欄位，倒退和向前相容性問題相反。這意味著您只能刪除一個可選的欄位（必填欄位永遠不能刪除），而且您不能再次使用相同的標籤號碼（因為您可能仍然有資料寫在包含舊標籤號碼的地方，而該欄位必須被新程式碼忽略）。
#### 資料型別和模式演變
如何改變欄位的資料型別？這可能是可能的——檢查檔案的細節——但是有一個風險，值將失去精度或被扼殺。例如，假設你將一個32位的整數變成一個64位的整數。新程式碼可以輕鬆讀取舊程式碼寫入的資料，因為解析器可以用零填充任何缺失的位。但是，如果舊程式碼讀取由新程式碼寫入的資料，則舊程式碼仍使用32位變數來儲存該值。如果解碼的64位值不適合32位，則它將被截斷。
Protobuf的一個奇怪的細節是，它沒有列表或陣列資料型別，而是有一個欄位的重複標記（這是第三個選項旁邊必要和可選）。如[圖4-4](../img/fig4-4.png)所示，重複欄位的編碼正如它所說的那樣：同一個欄位標記只是簡單地出現在記錄中。這具有很好的效果，可以將可選（單值）欄位更改為重複（多值）欄位。讀取舊資料的新程式碼會看到一個包含零個或一個元素的列表（取決於該欄位是否存在）。讀取新資料的舊程式碼只能看到列表的最後一個元素。
Thrift有一個專用的列表資料型別，它使用列表元素的資料型別進行引數化。這不允許Protocol Buffers所做的從單值到多值的相同演變，但是它具有支援巢狀列表的優點。
### Avro
Apache Avro 【20】是另一種二進位制編碼格式，與Protocol Buffers和Thrift有趣的不同。 它是作為Hadoop的一個子專案在2009年開始的，因為Thrift不適合Hadoop的用例【21】。
Avro也使用模式來指定正在編碼的資料的結構。 它有兩種模式語言：一種（Avro IDL）用於人工編輯，一種（基於JSON），更易於機器讀取。
我們用Avro IDL編寫的示例模式可能如下所示：
```c
record Person {
string userName;
union { null, long } favoriteNumber = null;
array<string> interests;
}
```
等價的JSON表示：
```json
{
"type": "record",
"name": "Person",
"fields": [
{"name": "userName", "type": "string"},
{"name": "favoriteNumber", "type": ["null", "long"], "default": null},
{"name": "interests", "type": {"type": "array", "items": "string"}
]
}
```
首先，請注意架構中沒有標籤號碼。 如果我們使用這個模式編碼我們的例子記錄（[例4-1]()），Avro二進位制編碼只有32個位元組長，這是我們所見過的所有編碼中最緊湊的。 編碼位元組序列的分解如[圖4-5](../img/fig4-5.png)所示。
如果您檢查位元組序列，您可以看到沒有什麼可以識別字段或其資料型別。 編碼只是由連在一起的值組成。 一個字串只是一個長度字首，後跟UTF-8位元組，但是在被包含的資料中沒有任何內容告訴你它是一個字串。 它可以是一個整數，也可以是其他的整數。 整數使用可變長度編碼（與Thrift的CompactProtocol相同）進行編碼。
![](../img/fig4-5.png)
**圖4-5 使用Avro編碼的記錄**
為了解析二進位制資料，您按照它們出現在架構中的順序遍歷這些欄位，並使用架構來告訴您每個欄位的資料型別。這意味著如果讀取資料的程式碼使用與寫入資料的程式碼完全相同的模式，則只能正確解碼二進位制資料。閱讀器和作者之間的模式不匹配意味著錯誤地解碼資料。
那麼，Avro如何支援模式演變呢？
#### 作者模式與讀者模式
有了Avro，當應用程式想要編碼一些資料（將其寫入檔案或資料庫，透過網路傳送等）時，它使用它知道的任何版本的模式編碼資料，例如，架構可能被編譯到應用程式中。這被稱為作者的模式。
當一個應用程式想要解碼一些資料（從一個檔案或資料庫讀取資料，從網路接收資料等）時，它希望資料在某個模式中，這就是讀者的模式。這是應用程式程式碼所依賴的模式，在應用程式的構建過程中，程式碼可能是從該模式生成的。
Avro的關鍵思想是作者的模式和讀者的模式不必是相同的 - 他們只需要相容。當資料解碼（讀取）時，Avro庫透過並排檢視作者的模式和讀者的模式並將資料從作者的模式轉換到讀者的模式來解決差異。 Avro規範【20】確切地定義了這種解析的工作原理，如[圖4-6](../img/fig4-6.png)所示。
例如，如果作者的模式和讀者的模式的欄位順序不同，這是沒有問題的，因為模式解析透過欄位名匹配欄位。如果讀取資料的程式碼遇到出現在作者模式中但不在讀者模式中的欄位，則忽略它。如果讀取資料的程式碼需要某個欄位，但是作者的模式不包含該名稱的欄位，則使用在讀者模式中宣告的預設值填充。
![](../img/fig4-6.png)
**圖4-6 一個Avro Reader解決讀寫模式的差異**
#### 模式演變規則
使用Avro，向前相容性意味著您可以將新版本的架構作為編寫器，並將舊版本的架構作為讀者。相反，向後相容意味著你可以有一個作為讀者的新版本的模式和作為作者的舊版本。
為了保持相容性，您只能新增或刪除具有預設值的欄位。 （我們的Avro模式中的欄位`favourNumber`的預設值為`null`）。例如，假設您新增一個預設值的欄位，所以這個新的欄位存在於新的模式中，而不是舊的。當使用新模式的閱讀器讀取使用舊模式寫入的記錄時，將為缺少的欄位填充預設值。
如果你要新增一個沒有預設值的欄位，新的閱讀器將無法讀取舊作者寫的資料，所以你會破壞向後相容性。如果您要刪除沒有預設值的欄位，舊的閱讀器將無法讀取新作者寫入的資料，因此您會打破相容性。在一些程式語言中，null是任何變數可以接受的預設值，但在Avro中並不是這樣：如果要允許一個欄位為`null`，則必須使用聯合型別。例如，`union {null，long，string}`欄位;表示該欄位可以是數字或字串，也可以是`null`。如果它是union的分支之一，那麼只能使用null作為預設值[^iv]。這比預設情況下可以為`null`是更加冗長的，但是透過明確什麼可以和不可以是什麼，有助於防止錯誤的`null` 【22】。
[^iv]: 確切地說，預設值必須是聯合的第一個分支的型別，儘管這是Avro的特定限制，而不是聯合型別的一般特徵。
因此，Avro沒有像Protocol Buffers和Thrift那樣的`optional`和`required`標記（它有聯合型別和預設值）。
只要Avro可以轉換型別，就可以改變欄位的資料型別。更改欄位的名稱是可能的，但有點棘手：讀者的模式可以包含欄位名稱的別名，所以它可以匹配舊作家的模式欄位名稱與別名。這意味著更改欄位名稱是向後相容的，但不能向前相容。同樣，向聯合型別新增分支也是向後相容的，但不能向前相容。
##### 但作者模式到底是什麼？
到目前為止，我們已經討論了一個重要的問題：讀者如何知道作者的模式是哪一部分資料被編碼的？我們不能只將整個模式包括在每個記錄中，因為模式可能比編碼的資料大得多，從而使二進位制編碼節省的所有空間都是徒勞的。
答案取決於Avro使用的上下文。舉幾個例子：
* 有很多記錄的大檔案
Avro的一個常見用途 - 尤其是在Hadoop環境中 - 用於儲存包含數百萬條記錄的大檔案，所有記錄都使用相同的模式進行編碼。 （我們將在[第10章](ch10.md)討論這種情況。）在這種情況下，該檔案的作者可以在檔案的開頭只包含一次作者的模式。 Avro指定一個檔案格式（物件容器檔案）來做到這一點。
* 支援獨立寫入的記錄的資料庫
在一個數據庫中，不同的記錄可能會在不同的時間點使用不同的作者的模式編寫 - 你不能假定所有的記錄都有相同的模式。最簡單的解決方案是在每個編碼記錄的開始處包含一個版本號，並在資料庫中保留一個模式版本列表。讀者可以獲取記錄，提取版本號，然後從資料庫中獲取該版本號的作者模式。使用該作者的模式，它可以解碼記錄的其餘部分。 （例如Espresso 【23】就是這樣工作的。）
* 透過網路連線傳送記錄
當兩個程序透過雙向網路連線進行通訊時，他們可以在連線設定上協商模式版本，然後在連線的生命週期中使用該模式。 Avro RPC協議（參閱“[透過服務的資料流：REST和RPC](#透過服務的資料流：REST和RPC)”）如此工作。
具有模式版本的資料庫在任何情況下都是非常有用的，因為它充當文件併為您提供了檢查模式相容性的機會【24】。作為版本號，你可以使用一個簡單的遞增整數，或者你可以使用模式的雜湊。
#### 動態生成的模式
與Protocol Buffers和Thrift相比，Avro方法的一個優點是架構不包含任何標籤號碼。但為什麼這很重要？在模式中保留一些數字有什麼問題？
不同之處在於Avro對動態生成的模式更友善。例如，假如你有一個關係資料庫，你想要把它的內容轉儲到一個檔案中，並且你想使用二進位制格式來避免前面提到的文字格式（JSON，CSV，SQL）的問題。如果你使用Avro，你可以很容易地從關係模式生成一個Avro模式（在我們之前看到的JSON表示中），並使用該模式對資料庫內容進行編碼，並將其全部轉儲到Avro物件容器檔案【25】中。您為每個資料庫表生成一個記錄模式，每個列成為該記錄中的一個欄位。資料庫中的列名稱對映到Avro中的欄位名稱。
現在，如果資料庫模式發生變化（例如，一個表中添加了一列，刪除了一列），則可以從更新的資料庫模式生成新的Avro模式，並在新的Avro模式中匯出資料。資料匯出過程不需要注意模式的改變 - 每次執行時都可以簡單地進行模式轉換。任何讀取新資料檔案的人都會看到記錄的欄位已經改變，但是由於欄位是透過名字來標識的，所以更新的作者的模式仍然可以與舊的讀者模式匹配。
相比之下，如果您為此使用Thrift或Protocol Buffers，則欄位標記可能必須手動分配：每次資料庫模式更改時，管理員都必須手動更新從資料庫列名到欄位標籤。 （這可能會自動化，但模式生成器必須非常小心，不要分配以前使用的欄位標記。）這種動態生成的模式根本不是Thrift或Protocol Buffers的設計目標，而是為Avro。
#### 程式碼生成和動態型別的語言
Thrift和Protobuf依賴於程式碼生成：在定義了模式之後，可以使用您選擇的程式語言生成實現此模式的程式碼。這在Java，C ++或C＃等靜態型別語言中很有用，因為它允許將高效的記憶體中結構用於解碼的資料，並且在編寫訪問資料結構的程式時允許在IDE中進行型別檢查和自動完成。
在動態型別程式語言（如JavaScript，Ruby或Python）中，生成程式碼沒有太多意義，因為沒有編譯時型別檢查器來滿足。程式碼生成在這些語言中經常被忽視，因為它們避免了明確的編譯步驟。而且，對於動態生成的模式（例如從資料庫表生成的Avro模式），程式碼生成對獲取資料是一個不必要的障礙。
Avro為靜態型別程式語言提供了可選的程式碼生成功能，但是它也可以在不生成任何程式碼的情況下使用。如果你有一個物件容器檔案（它嵌入了作者的模式），你可以簡單地使用Avro庫開啟它，並以與檢視JSON檔案相同的方式檢視資料。該檔案是自描述的，因為它包含所有必要的元資料。
這個屬性特別適用於動態型別的資料處理語言如Apache Pig 【26】。在Pig中，您可以開啟一些Avro檔案，開始分析它們，並編寫派生資料集以Avro格式輸出檔案，而無需考慮模式。
### 模式的優點
正如我們所看到的，Protocol Buffers，Thrift和Avro都使用模式來描述二進位制編碼格式。他們的模式語言比XML模式或者JSON模式簡單得多，它支援更詳細的驗證規則（例如，“該欄位的字串值必須與該正則表示式匹配”或“該欄位的整數值必須在0和100之間“）。由於Protocol Buffers，Thrift和Avro實現起來更簡單，使用起來也更簡單，所以它們已經發展到支援相當廣泛的程式語言。
這些編碼所基於的想法絕不是新的。例如，它們與ASN.1有很多相似之處，它是1984年首次被標準化的模式定義語言【27】。它被用來定義各種網路協議，其二進位制編碼（DER）仍然被用於編碼SSL證書（X.509），例如【28】。 ASN.1支援使用標籤號碼的模式演進，類似於Protocol Buf-fers和Thrift 【29】。然而，這也是非常複雜和嚴重的檔案記錄，所以ASN.1可能不是新應用程式的好選擇。
許多資料系統也為其資料實現某種專有的二進位制編碼。例如，大多數關係資料庫都有一個網路協議，您可以透過該協議向資料庫傳送查詢並獲取響應。這些協議通常特定於特定的資料庫，並且資料庫供應商提供將來自資料庫的網路協議的響應解碼為記憶體資料結構的驅動程式（例如使用ODBC或JDBC API）。
所以，我們可以看到，儘管JSON，XML和CSV等文字資料格式非常普遍，但基於模式的二進位制編碼也是一個可行的選擇。他們有一些很好的屬性：
* 它們可以比各種“二進位制JSON”變體更緊湊，因為它們可以省略編碼資料中的欄位名稱。
* 模式是一種有價值的文件形式，因為模式是解碼所必需的，所以可以確定它是最新的（而手動維護的文件可能很容易偏離現實）。
* 保留模式資料庫允許您在部署任何內容之前檢查模式更改的向前和向後相容性。
* 對於靜態型別程式語言的使用者來說，從模式生成程式碼的能力是有用的，因為它可以在編譯時進行型別檢查。
總而言之，模式進化允許與JSON資料庫提供的無模式/模式讀取相同的靈活性（請參閱第39頁的“文件模型中的模式靈活性”），同時還可以更好地保證資料和更好的工具。
## 資料流的型別
在本章的開始部分，我們曾經說過，無論何時您想要將某些資料傳送到不共享記憶體的另一個程序，例如，只要您想透過網路傳送資料或將其寫入檔案，就需要將它編碼為一個位元組序列。然後我們討論了做這個的各種不同的編碼。
我們討論了向前和向後的相容性，這對於可演化性來說非常重要（透過允許您獨立升級系統的不同部分，而不必一次改變所有內容，可以輕鬆地進行更改）。相容性是編碼資料的一個程序和解碼它的另一個程序之間的一種關係。
這是一個相當抽象的概念 - 資料可以透過多種方式從一個流程流向另一個流程。誰編碼資料，誰解碼？在本章的其餘部分中，我們將探討資料如何在流程之間流動的一些最常見的方式：
* 透過資料庫（參閱“[透過資料庫的資料流](#透過資料庫的資料流)”）
* 透過服務呼叫（參閱“[透過服務傳輸資料流：REST和RPC](#透過服務傳輸資料流：REST和RPC)”）
* 透過非同步訊息傳遞（參閱“[訊息傳遞資料流](#訊息傳遞資料流)”）
### 資料庫中的資料流
在資料庫中，寫入資料庫的過程對資料進行編碼，從資料庫讀取的過程對資料進行解碼。可能只有一個程序訪問資料庫，在這種情況下，讀者只是相同程序的後續版本 - 在這種情況下，您可以考慮將資料庫中的內容儲存為向未來的自我傳送訊息。
向後相容性顯然是必要的。否則你未來的自己將無法解碼你以前寫的東西。
一般來說，幾個不同的程序同時訪問資料庫是很常見的。這些程序可能是幾個不同的應用程式或服務，或者它們可能只是幾個相同服務的例項（為了可擴充套件性或容錯性而並行執行）。無論哪種方式，在應用程式發生變化的環境中，訪問資料庫的某些程序可能會執行較新的程式碼，有些程序可能會執行較舊的程式碼，例如，因為新版本當前正在部署在滾動升級，所以有些例項已經更新，而其他例項尚未更新。
這意味著資料庫中的一個值可能會被更新版本的程式碼寫入，然後被仍舊執行的舊版本的程式碼讀取。因此，資料庫也經常需要向前相容。
但是，還有一個額外的障礙。假設您將一個欄位新增到記錄模式，並且較新的程式碼將該新欄位的值寫入資料庫。隨後，舊版本的程式碼（尚不知道新欄位）將讀取記錄，更新記錄並將其寫回。在這種情況下，理想的行為通常是舊程式碼保持新的領域完整，即使它不能被解釋。
前面討論的編碼格式支援未知域的儲存，但是有時候需要在應用程式層面保持謹慎，如圖4-7所示。例如，如果將資料庫值解碼為應用程式中的模型物件，稍後重新編碼這些模型物件，那麼未知欄位可能會在該翻譯過程中丟失。
解決這個問題不是一個難題，你只需要意識到它。
![](../img/fig4-7.png)
**圖4-7 當較舊版本的應用程式更新以前由較新版本的應用程式編寫的資料時，如果不小心，資料可能會丟失。**
#### 在不同的時間寫入不同的值
資料庫通常允許任何時候更新任何值。這意味著在一個單一的資料庫中，可能有一些值是五毫秒前寫的，而一些值是五年前寫的。
在部署應用程式的新版本（至少是伺服器端應用程式）時，您可能會在幾分鐘內完全用新版本替換舊版本。資料庫內容也是如此：五年前的資料仍然存在於原始編碼中，除非您已經明確地重寫了它。這種觀察有時被總結為資料超出程式碼。
將資料重寫（遷移）到一個新的模式當然是可能的，但是在一個大資料集上執行是一個昂貴的事情，所以大多數資料庫如果可能的話就避免它。大多數關係資料庫都允許簡單的模式更改，例如新增一個預設值為空的新列，而不重寫現有資料[^v]讀取舊行時，資料庫將填充編碼資料中缺少的任何列的空值在磁碟上。 LinkedIn的文件資料庫Espresso使用Avro儲存，允許它使用Avro的模式演變規則【23】。
因此，架構演變允許整個資料庫看起來好像是用單個模式編碼的，即使底層儲存可能包含用模式的各種歷史版本編碼的記錄。
[^v]: 除了MySQL，即使並非真的必要，它也經常會重寫整個表，正如“[文件模型中的架構靈活性](ch3.md#文件模型中的靈活性)”中所提到的。
#### 歸檔儲存
也許您不時為資料庫建立一個快照，例如備份或載入到資料倉庫（參閱“[資料倉庫](ch3.md#資料倉庫)”）。在這種情況下，即使源資料庫中的原始編碼包含來自不同時代的模式版本的混合，資料轉儲通常也將使用最新模式進行編碼。既然你正在複製資料，那麼你可能會一直對資料的副本進行編碼。
由於資料轉儲是一次寫入的，而且以後是不可變的，所以Avro物件容器檔案等格式非常適合。這也是一個很好的機會，可以將資料編碼為面向分析的列式格式，例如Parquet（請參閱第97頁的“[列壓縮](ch3.md#列壓縮)”）。
在[第10章](ch10.md)中，我們將詳細討論在檔案儲存中使用資料。
### 服務中的資料流：REST與RPC
當您需要透過網路進行通訊的程序時，安排該通訊的方式有幾種。最常見的安排是有兩個角色：客戶端和伺服器。伺服器透過網路公開API，並且客戶端可以連線到伺服器以向該API發出請求。伺服器公開的API被稱為服務。
Web以這種方式工作：客戶（Web瀏覽器）向Web伺服器發出請求，使GET請求下載HTML，CSS，JavaScript，影象等，並向POST請求提交資料到伺服器。 API包含一組標準的協議和資料格式（HTTP，URL，SSL/TLS，HTML等）。由於網路瀏覽器，網路伺服器和網站作者大多同意這些標準，您可以使用任何網路瀏覽器訪問任何網站（至少在理論上！）。
Web瀏覽器不是唯一的客戶端型別。例如，在移動裝置或桌面計算機上執行的本地應用程式也可以向伺服器發出網路請求，並且在Web瀏覽器內執行的客戶端JavaScript應用程式可以使用XMLHttpRequest成為HTTP客戶端（該技術被稱為Ajax 【30】）。在這種情況下，伺服器的響應通常不是用於顯示給人的HTML，而是用於便於客戶端應用程式程式碼（如JSON）進一步處理的編碼資料。儘管HTTP可能被用作傳輸協議，但頂層實現的API是特定於應用程式的，客戶端和伺服器需要就該API的細節達成一致。
此外，伺服器本身可以是另一個服務的客戶端（例如，典型的Web應用伺服器充當資料庫的客戶端）。這種方法通常用於將大型應用程式按照功能區域分解為較小的服務，這樣當一個服務需要來自另一個服務的某些功能或資料時，就會向另一個服務發出請求。這種構建應用程式的方式傳統上被稱為**面向服務的體系結構（service-oriented architecture，SOA）**，最近被改進和更名為**微服務架構**【31,32】。
在某些方面，服務類似於資料庫：它們通常允許客戶端提交和查詢資料。但是，雖然資料庫允許使用我們在第2章 中討論的查詢語言進行任意查詢，但是服務公開了一個特定於應用程式的API，它只允許由服務的業務邏輯（應用程式程式碼）預定的輸入和輸出【33】。這種限制提供了一定程度的封裝：服務可以對客戶可以做什麼和不可以做什麼施加細粒度的限制。
面向服務/微服務架構的一個關鍵設計目標是透過使服務獨立部署和演化來使應用程式更易於更改和維護。例如，每個服務應該由一個團隊擁有，並且該團隊應該能夠經常釋出新版本的服務，而不必與其他團隊協調。換句話說，我們應該期望伺服器和客戶端的舊版本和新版本同時執行，因此伺服器和客戶端使用的資料編碼必須在不同版本的服務API之間相容——正是我們所做的本章一直在談論。
#### Web服務
**當服務使用HTTP作為底層通訊協議時，可稱之為Web服務**。這可能是一個小錯誤，因為Web服務不僅在Web上使用，而且在幾個不同的環境中使用。例如：
1. 執行在使用者裝置上的客戶端應用程式（例如，移動裝置上的本地應用程式，或使用Ajax的JavaScript web應用程式）透過HTTP向服務發出請求。這些請求通常透過公共網際網路進行。
2. 一種服務向同一組織擁有的另一項服務提出請求，這些服務通常位於同一資料中心內，作為面向服務/微型架構的一部分。 （支援這種用例的軟體有時被稱為 **中介軟體（middleware）** ）
3. 一種服務透過網際網路向不同組織所擁有的服務提出請求。這用於不同組織後端系統之間的資料交換。此類別包括由線上服務（如信用卡處理系統）提供的公共API，或用於共享訪問使用者資料的OAuth。
有兩種流行的Web服務方法：REST和SOAP。他們在哲學方面幾乎是截然相反的，往往是各自支持者之間的激烈辯論（即使在每個陣營內也有很多爭論。 例如，**HATEOAS（超媒體作為應用程式狀態的引擎）**經常引發討論【35】。）
REST不是一個協議，而是一個基於HTTP原則的設計哲學【34,35】。它強調簡單的資料格式，使用URL來標識資源，並使用HTTP功能進行快取控制，身份驗證和內容型別協商。與SOAP相比，REST已經越來越受歡迎，至少在跨組織服務整合的背景下【36】，並經常與微服務相關[31]。根據REST原則設計的API稱為RESTful。
相比之下，SOAP是用於製作網路API請求的基於XML的協議（ 儘管首字母縮寫詞相似，SOAP並不是SOA的要求。 SOAP是一種特殊的技術，而SOA是構建系統的一般方法。）。雖然它最常用於HTTP，但其目的是獨立於HTTP，並避免使用大多數HTTP功能。相反，它帶有龐大而複雜的多種相關標準（Web服務框架，稱為`WS-*`），它們增加了各種功能【37】。
SOAP Web服務的API使用稱為Web服務描述語言（WSDL）的基於XML的語言來描述。 WSDL支援程式碼生成，客戶端可以使用本地類和方法呼叫（編碼為XML訊息並由框架再次解碼）訪問遠端服務。這在靜態型別程式語言中非常有用，但在動態型別程式語言中很少（參閱“[程式碼生成和動態型別化語言](#程式碼生成和動態型別化語言)”）。
由於WSDL的設計不是人類可讀的，而且由於SOAP訊息通常是手動構建的過於複雜，所以SOAP的使用者在很大程度上依賴於工具支援，程式碼生成和IDE【38】。對於SOAP供應商不支援的程式語言的使用者來說，與SOAP服務的整合是困難的。
儘管SOAP及其各種擴充套件表面上是標準化的，但是不同廠商的實現之間的互操作性往往會造成問題【39】。由於所有這些原因，儘管許多大型企業仍然使用SOAP，但在大多數小公司中已經不再受到青睞。
REST風格的API傾向於更簡單的方法，通常涉及較少的程式碼生成和自動化工具。定義格式（如OpenAPI，也稱為Swagger 【40】）可用於描述RESTful API並生成文件。
#### 遠端過程呼叫（RPC）的問題
Web服務僅僅是透過網路進行API請求的一系列技術的最新版本，其中許多技術受到了大量的炒作，但是存在嚴重的問題。 Enterprise JavaBeans（EJB）和Java的**遠端方法呼叫（RMI）**僅限於Java。**分散式元件物件模型（DCOM）**僅限於Microsoft平臺。**公共物件請求代理體系結構（CORBA）**過於複雜，不提供前向或後向相容性【41】。
所有這些都是基於 **遠端過程呼叫（RPC）** 的思想，該過程呼叫自20世紀70年代以來一直存在【42】。 RPC模型試圖向遠端網路服務發出請求，看起來與在同一程序中呼叫程式語言中的函式或方法相同（這種抽象稱為位置透明）。儘管RPC起初看起來很方便，但這種方法根本上是有缺陷的【43,44】。網路請求與本地函式呼叫非常不同：
* 本地函式呼叫是可預測的，並且成功或失敗，這僅取決於受您控制的引數。網路請求是不可預知的：由於網路問題，請求或響應可能會丟失，或者遠端計算機可能很慢或不可用，這些問題完全不在您的控制範圍之內。網路問題是常見的，所以你必須預測他們，例如透過重試失敗的請求。
* 本地函式呼叫要麼返回結果，要麼丟擲異常，或者永遠不返回（因為進入無限迴圈或程序崩潰）。網路請求有另一個可能的結果：由於超時，它可能會返回沒有結果。在這種情況下，你根本不知道發生了什麼：如果你沒有得到來自遠端服務的響應，你無法知道請求是否透過。 （我們將在[第8章](ch8.md)更詳細地討論這個問題。）
* 如果您重試失敗的網路請求，可能會發生請求實際上正在透過，只有響應丟失。在這種情況下，重試將導致該操作被執行多次，除非您在協議中引入除重（ **冪等（idempotence）**）機制。本地函式呼叫沒有這個問題。 （在[第十一章](ch11.md)更詳細地討論冪等性）
* 每次呼叫本地功能時，通常需要大致相同的時間來執行。網路請求比函式呼叫要慢得多，而且其延遲也是非常可變的：在不到一毫秒的時間內它可能會完成，但是當網路擁塞或者遠端服務超載時，可能需要幾秒鐘的時間完全一樣的東西。
* 呼叫本地函式時，可以高效地將引用（指標）傳遞給本地記憶體中的物件。當你發出一個網路請求時，所有這些引數都需要被編碼成可以透過網路傳送的一系列位元組。沒關係，如果引數是像數字或字串這樣的基本型別，但是對於較大的物件很快就會變成問題。
客戶端和服務可以用不同的程式語言實現，所以RPC框架必須將資料型別從一種語言翻譯成另一種語言。這可能會捅出大簍子，因為不是所有的語言都具有相同的型別 —— 例如回想一下JavaScript的數字大於$2^{53}$的問題（參閱“[JSON，XML和二進位制變體](#JSON，XML和二進位制變體)”）。用單一語言編寫的單個程序中不存在此問題。
所有這些因素意味著嘗試使遠端服務看起來像程式語言中的本地物件一樣毫無意義，因為這是一個根本不同的事情。 REST的部分吸引力在於，它並不試圖隱藏它是一個網路協議的事實（儘管這似乎並沒有阻止人們在REST之上構建RPC庫）。
#### RPC的當前方向
儘管有這樣那樣的問題，RPC不會消失。在本章提到的所有編碼的基礎上構建了各種RPC框架：例如，Thrift和Avro帶有RPC支援，gRPC是使用Protocol Buffers的RPC實現，Finagle也使用Thrift，Rest.li使用JSON over HTTP。
這種新一代的RPC框架更加明確的是，遠端請求與本地函式呼叫不同。例如，Finagle和Rest.li 使用futures（promises）來封裝可能失敗的非同步操作。`Futures`還可以簡化需要並行發出多項服務的情況，並將其結果合併【45】。 gRPC支援流，其中一個呼叫不僅包括一個請求和一個響應，還包括一系列的請求和響應【46】。
其中一些框架還提供服務發現，即允許客戶端找出在哪個IP地址和埠號上可以找到特定的服務。我們將在“[請求路由](ch6.md#請求路由)”中回到這個主題。
使用二進位制編碼格式的自定義RPC協議可以實現比通用的JSON over REST更好的效能。但是，RESTful API還有其他一些顯著的優點：對於實驗和除錯（只需使用Web瀏覽器或命令列工具curl，無需任何程式碼生成或軟體安裝即可向其請求），它是受支援的所有的主流程式語言和平臺，還有大量可用的工具（伺服器，快取，負載平衡器，代理，防火牆，監控，除錯工具，測試工具等）的生態系統。由於這些原因，REST似乎是公共API的主要風格。 RPC框架的主要重點在於同一組織擁有的服務之間的請求，通常在同一資料中心內。
#### 資料編碼與RPC的演化
對於可演化性，重要的是可以獨立更改和部署RPC客戶端和伺服器。與透過資料庫流動的資料相比（如上一節所述），我們可以在透過服務進行資料流的情況下做一個簡化的假設：假定所有的伺服器都會先更新，其次是所有的客戶端。因此，您只需要在請求上具有向後相容性，並且對響應具有前向相容性。
RPC方案的前後向相容性屬性從它使用的編碼方式中繼承
* Thrift，gRPC（Protobuf）和Avro RPC可以根據相應編碼格式的相容性規則進行演變。
* 在SOAP中，請求和響應是使用XML模式指定的。這些可以演變，但有一些微妙的陷阱【47】。
* RESTful API通常使用JSON（沒有正式指定的模式）用於響應，以及用於請求的JSON或URI編碼/表單編碼的請求引數。新增可選的請求引數並向響應物件新增新的欄位通常被認為是保持相容性的改變。
由於RPC經常被用於跨越組織邊界的通訊，所以服務的相容性變得更加困難，因此服務的提供者經常無法控制其客戶，也不能強迫他們升級。因此，需要長期保持相容性，也許是無限期的。如果需要進行相容性更改，則服務提供商通常會並排維護多個版本的服務API。
關於API版本化應該如何工作（即，客戶端如何指示它想要使用哪個版本的API）沒有一致意見【48】）。對於RESTful API，常用的方法是在URL或HTTP Accept頭中使用版本號。對於使用API金鑰來標識特定客戶端的服務，另一種選擇是將客戶端請求的API版本儲存在伺服器上，並允許透過單獨的管理介面更新該版本選項【49】。
### 訊息傳遞中的資料流
我們一直在研究從一個過程到另一個過程的編碼資料流的不同方式。到目前為止，我們已經討論了REST和RPC（其中一個程序透過網路向另一個程序傳送請求並期望儘可能快的響應）以及資料庫（一個程序寫入編碼資料，另一個程序在將來再次讀取）。
在最後一節中，我們將簡要介紹一下RPC和資料庫之間的非同步訊息傳遞系統。它們與RPC類似，因為客戶端的請求（通常稱為訊息）以低延遲傳送到另一個程序。它們與資料庫類似，不是透過直接的網路連線傳送訊息，而是透過稱為訊息代理（也稱為訊息佇列或面向訊息的中介軟體）的中介來臨時儲存訊息。
與直接RPC相比，使用訊息代理有幾個優點：
* 如果收件人不可用或過載，可以充當緩衝區，從而提高系統的可靠性。
* 它可以自動將訊息重新發送到已經崩潰的程序，從而防止訊息丟失。
* 避免發件人需要知道收件人的IP地址和埠號（這在虛擬機器經常出入的雲部署中特別有用）。
* 它允許將一條訊息傳送給多個收件人。
* 將發件人與收件人邏輯分離（發件人只是釋出郵件，不關心使用者）。
然而，與RPC相比，差異在於訊息傳遞通訊通常是單向的：傳送者通常不期望收到其訊息的回覆。一個程序可能傳送一個響應，但這通常是在一個單獨的通道上完成的。這種通訊模式是非同步的：傳送者不會等待訊息被傳遞，而只是傳送它，然後忘記它。
#### 訊息掮客
過去，資訊掮客主要是TIBCO，IBM WebSphere和webMethods等公司的商業軟體的秀場。最近像RabbitMQ，ActiveMQ，HornetQ，NATS和Apache Kafka這樣的開源實現已經流行起來。我們將在[第11章](ch11.md)中對它們進行更詳細的比較。
詳細的交付語義因實現和配置而異，但通常情況下，訊息代理的使用方式如下：一個程序將訊息傳送到指定的佇列或主題，代理確保將訊息傳遞給一個或多個消費者或訂閱者到那個佇列或主題。在同一主題上可以有許多生產者和許多消費者。
一個主題只提供單向資料流。但是，消費者本身可能會將訊息釋出到另一個主題上（因此，可以將它們連結在一起，就像我們將在[第11章](ch11.md)中看到的那樣），或者傳送給原始訊息的傳送者使用的回覆佇列（允許請求/響應資料流，類似於RPC）。
訊息代理通常不會執行任何特定的資料模型 - 訊息只是包含一些元資料的位元組序列，因此您可以使用任何編碼格式。如果編碼是向後相容的，則您可以靈活地更改發行商和消費者的獨立編碼，並以任意順序進行部署。
如果消費者重新發布訊息到另一個主題，則可能需要小心保留未知欄位，以防止前面在資料庫環境中描述的問題（[圖4-7](../img/fig4-7.png)）。
#### 分散式的Actor框架
Actor模型是單個程序中併發的程式設計模型。邏輯被封裝在角色中，而不是直接處理執行緒（以及競爭條件，鎖定和死鎖的相關問題）。每個角色通常代表一個客戶或實體，它可能有一些本地狀態（不與其他任何角色共享），它透過傳送和接收非同步訊息與其他角色通訊。訊息傳送不保證：在某些錯誤情況下，訊息將丟失。由於每個角色一次只能處理一條訊息，因此不需要擔心執行緒，每個角色可以由框架獨立排程。
在分散式的行為者框架中，這個程式設計模型被用來跨越多個節點來擴充套件應用程式。不管傳送方和接收方是在同一個節點上還是在不同的節點上，都使用相同的訊息傳遞機制。如果它們在不同的節點上，則該訊息被透明地編碼成位元組序列，透過網路傳送，並在另一側解碼。
位置透明在actor模型中比在RPC中效果更好，因為actor模型已經假定訊息可能會丟失，即使在單個程序中也是如此。儘管網路上的延遲可能比同一個程序中的延遲更高，但是在使用參與者模型時，本地和遠端通訊之間的基本不匹配是較少的。
分散式的Actor框架實質上是將訊息代理和角色程式設計模型整合到一個框架中。但是，如果要執行基於角色的應用程式的滾動升級，則仍然需要擔心向前和向後相容性問題，因為訊息可能會從執行新版本的節點發送到執行舊版本的節點，反之亦然。
三個流行的分散式actor框架處理訊息編碼如下：
* 預設情況下，Akka使用Java的內建序列化，不提供前向或後向相容性。 但是，你可以用類似緩衝區的東西替代它，從而獲得滾動升級的能力【50】。
* Orleans 預設使用不支援滾動升級部署的自定義資料編碼格式; 要部署新版本的應用程式，您需要設定一個新的群集，將流量從舊群集遷移到新群集，然後關閉舊群集【51,52】。 像Akka一樣，可以使用自定義序列化外掛。
* 在Erlang OTP中，對記錄模式進行更改是非常困難的（儘管系統具有許多為高可用性設計的功能）。 滾動升級是可能的，但需要仔細計劃【53】。 一個新的實驗性的`maps`資料型別（2014年在Erlang R17中引入的類似於JSON的結構）可能使得這個資料型別在未來更容易【54】。
## 本章小結
在本章中，我們研究了將資料結構轉換為網路中的位元組或磁碟上的位元組的幾種方法。我們看到了這些編碼的細節不僅影響其效率，更重要的是應用程式的體系結構和部署它們的選項。
特別是，許多服務需要支援滾動升級，其中新版本的服務逐步部署到少數節點，而不是同時部署到所有節點。滾動升級允許在不停機的情況下發布新版本的服務（從而鼓勵在罕見的大型版本上頻繁釋出小型版本），並使部署風險降低（允許在影響大量使用者之前檢測並回滾有故障的版本）。這些屬性對於可演化性，以及對應用程式進行更改的容易性都是非常有利的。
在滾動升級期間，或出於各種其他原因，我們必須假設不同的節點正在執行我們的應用程式程式碼的不同版本。因此，在系統周圍流動的所有資料都是以提供向後相容性（新程式碼可以讀取舊資料）和向前相容性（舊程式碼可以讀取新資料）的方式進行編碼是重要的。
我們討論了幾種資料編碼格式及其相容性屬性：
* 程式語言特定的編碼僅限於單一程式語言，並且往往無法提供前向和後向相容性。
* JSON，XML和CSV等文字格式非常普遍，其相容性取決於您如何使用它們。他們有可選的模式語言，這有時是有用的，有時是一個障礙。這些格式對於資料型別有些模糊，所以你必須小心數字和二進位制字串。
* 像Thrift，Protocol Buffers和Avro這樣的二進位制模式驅動格式允許使用清晰定義的前向和後向相容性語義進行緊湊，高效的編碼。這些模式可以用於靜態型別語言的文件和程式碼生成。但是，他們有一個缺點，就是在資料可讀之前需要對資料進行解碼。
我們還討論了資料流的幾種模式，說明了資料編碼是重要的不同場景：
* 資料庫，寫入資料庫的程序對資料進行編碼，並從資料庫讀取程序對其進行解碼
* RPC和REST API，客戶端對請求進行編碼，伺服器對請求進行解碼並對響應進行編碼，客戶端最終對響應進行解碼
* 非同步訊息傳遞（使用訊息代理或參與者），其中節點之間透過傳送訊息進行通訊，訊息由傳送者編碼並由接收者解碼
我們可以小心地得出這樣的結論：前向相容性和滾動升級在某種程度上是可以實現的。願您的應用程式的演變迅速、敏捷部署。
## 參考文獻
1. “[Java Object Serialization Specification](http://docs.oracle.com/javase/7/docs/platform/serialization/spec/serialTOC.html),” *docs.oracle.com*, 2010.
1. “[Ruby 2.2.0 API Documentation](http://ruby-doc.org/core-2.2.0/),” *ruby-doc.org*, Dec 2014.
1. “[The Python 3.4.3 Standard Library Reference Manual](https://docs.python.org/3/library/pickle.html),” *docs.python.org*, February 2015.
1. “[EsotericSoftware/kryo](https://github.com/EsotericSoftware/kryo),” *github.com*, October 2014.
1. “[CWE-502: Deserialization of Untrusted Data](http://cwe.mitre.org/data/definitions/502.html),” Common Weakness Enumeration, *cwe.mitre.org*,
July 30, 2014.
1. Steve Breen: “[What Do WebLogic, WebSphere, JBoss, Jenkins, OpenNMS, and Your Application Have in Common? This Vulnerability](http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/),” *foxglovesecurity.com*, November 6, 2015.
1. Patrick McKenzie: “[What the Rails Security Issue Means for Your Startup](http://www.kalzumeus.com/2013/01/31/what-the-rails-security-issue-means-for-your-startup/),” *kalzumeus.com*, January 31, 2013.
1. Eishay Smith: “[jvm-serializers wiki](https://github.com/eishay/jvm-serializers/wiki),” *github.com*, November 2014.
1. “[XML Is a Poor Copy of S-Expressions](http://c2.com/cgi/wiki?XmlIsaPoorCopyOfEssExpressions),” *c2.com* wiki.
1. Matt Harris: “[Snowflake: An Update and Some Very Important Information](https://groups.google.com/forum/#!topic/twitter-development-talk/ahbvo3VTIYI),” email to *Twitter Development Talk* mailing list, October 19, 2010.
1. Shudi (Sandy) Gao, C. M. Sperberg-McQueen, and Henry S. Thompson: “[XML Schema 1.1](http://www.w3.org/XML/Schema),” W3C Recommendation, May 2001.
1. Francis Galiegue, Kris Zyp, and Gary Court: “[JSON Schema](http://json-schema.org/),” IETF Internet-Draft, February 2013.
1. Yakov Shafranovich: “[RFC 4180: Common Format and MIME Type for Comma-Separated Values (CSV) Files](https://tools.ietf.org/html/rfc4180),” October 2005.
1. “[MessagePack Specification](http://msgpack.org/),” *msgpack.org*. Mark Slee, Aditya Agarwal, and Marc Kwiatkowski: “[Thrift: Scalable Cross-Language Services Implementation](http://thrift.apache.org/static/files/thrift-20070401.pdf),” Facebook technical report, April 2007.
1. “[Protocol Buffers Developer Guide](https://developers.google.com/protocol-buffers/docs/overview),” Google, Inc., *developers.google.com*.
1. Igor Anishchenko: “[Thrift vs Protocol Buffers vs Avro - Biased Comparison](http://www.slideshare.net/IgorAnishchenko/pb-vs-thrift-vs-avro),” *slideshare.net*, September 17, 2012.
1. “[A Matrix of the Features Each Individual Language Library Supports](http://wiki.apache.org/thrift/LibraryFeatures),” *wiki.apache.org*.
1. Martin Kleppmann: “[Schema Evolution in Avro, Protocol Buffers and Thrift](http://martin.kleppmann.com/2012/12/05/schema-evolution-in-avro-protocol-buffers-thrift.html),” *martin.kleppmann.com*, December 5, 2012.
1. “[Apache Avro 1.7.7 Documentation](http://avro.apache.org/docs/1.7.7/),” *avro.apache.org*, July 2014.
1. Doug Cutting, Chad Walters, Jim Kellerman, et al.:
“[&#91;PROPOSAL&#93; New Subproject: Avro](http://mail-archives.apache.org/mod_mbox/hadoop-general/200904.mbox/%3C49D53694.1050906@apache.org%3E),” email thread on *hadoop-general* mailing list,
*mail-archives.apache.org*, April 2009.
1. Tony Hoare: “[Null References: The Billion Dollar Mistake](http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare),” at *QCon London*, March 2009.
1. Aditya Auradkar and Tom Quiggle: “[Introducing Espresso—LinkedIn's Hot New Distributed Document Store](https://engineering.linkedin.com/espresso/introducing-espresso-linkedins-hot-new-distributed-document-store),” *engineering.linkedin.com*, January 21, 2015.
1. Jay Kreps: “[Putting Apache Kafka to Use: A Practical Guide to Building a Stream Data Platform (Part 2)](http://blog.confluent.io/2015/02/25/stream-data-platform-2/),” *blog.confluent.io*, February 25, 2015.
1. Gwen Shapira: “[The Problem of Managing Schemas](http://radar.oreilly.com/2014/11/the-problem-of-managing-schemas.html),” *radar.oreilly.com*, November 4, 2014.
1. “[Apache Pig 0.14.0 Documentation](http://pig.apache.org/docs/r0.14.0/),” *pig.apache.org*, November 2014.
1. John Larmouth: [*ASN.1Complete*](http://www.oss.com/asn1/resources/books-whitepapers-pubs/larmouth-asn1-book.pdf). Morgan Kaufmann, 1999. ISBN: 978-0-122-33435-1
1. Russell Housley, Warwick Ford, Tim Polk, and David Solo: “[RFC 2459: Internet X.509 Public Key Infrastructure: Certificate and CRL Profile](https://www.ietf.org/rfc/rfc2459.txt),” IETF Network Working Group, Standards Track,
January 1999.
1. Lev Walkin: “[Question: Extensibility and Dropping Fields](http://lionet.info/asn1c/blog/2010/09/21/question-extensibility-removing-fields/),” *lionet.info*, September 21, 2010.
1. Jesse James Garrett: “[Ajax: A New Approach to Web Applications](http://www.adaptivepath.com/ideas/ajax-new-approach-web-applications/),” *adaptivepath.com*, February 18, 2005.
1. Sam Newman: *Building Microservices*. O'Reilly Media, 2015. ISBN: 978-1-491-95035-7
1. Chris Richardson: “[Microservices: Decomposing Applications for Deployability and Scalability](http://www.infoq.com/articles/microservices-intro),” *infoq.com*, May 25, 2014.
1. Pat Helland: “[Data on the Outside Versus Data on the Inside](http://cidrdb.org/cidr2005/papers/P12.pdf),” at *2nd Biennial Conference on Innovative Data Systems Research* (CIDR), January 2005.
1. Roy Thomas Fielding: “[Architectural Styles and the Design of Network-Based Software Architectures](https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf),” PhD Thesis, University of California, Irvine, 2000.
1. Roy Thomas Fielding: “[REST APIs Must Be Hypertext-Driven](http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven),” *roy.gbiv.com*, October 20 2008.
1. “[REST in Peace, SOAP](http://royal.pingdom.com/2010/10/15/rest-in-peace-soap/),” *royal.pingdom.com*, October 15, 2010.
1. “[Web Services Standards as of Q1 2007](https://www.innoq.com/resources/ws-standards-poster/),” *innoq.com*, February 2007.
1. Pete Lacey: “[The S Stands for Simple](http://harmful.cat-v.org/software/xml/soap/simple),” *harmful.cat-v.org*, November 15, 2006.
1. Stefan Tilkov: “[Interview: Pete Lacey Criticizes Web Services](http://www.infoq.com/articles/pete-lacey-ws-criticism),” *infoq.com*, December 12, 2006.
1. “[OpenAPI Specification (fka Swagger RESTful API Documentation Specification) Version 2.0](http://swagger.io/specification/),” *swagger.io*, September 8, 2014.
1. Michi Henning: “[The Rise and Fall of CORBA](http://queue.acm.org/detail.cfm?id=1142044),” *ACM Queue*, volume 4, number 5, pages 28–34, June 2006.
[doi:10.1145/1142031.1142044](http://dx.doi.org/10.1145/1142031.1142044)
1. Andrew D. Birrell and Bruce Jay Nelson: “[Implementing Remote Procedure Calls](http://www.cs.princeton.edu/courses/archive/fall03/cs518/papers/rpc.pdf),” *ACM Transactions on Computer Systems* (TOCS), volume 2, number 1, pages 39–59, February 1984. [doi:10.1145/2080.357392](http://dx.doi.org/10.1145/2080.357392)
1. Jim Waldo, Geoff Wyant, Ann Wollrath, and Sam Kendall: “[A Note on Distributed Computing](http://m.mirror.facebook.net/kde/devel/smli_tr-94-29.pdf),” Sun Microsystems Laboratories, Inc., Technical Report TR-94-29, November 1994.
1. Steve Vinoski: “[Convenience over Correctness](http://steve.vinoski.net/pdf/IEEE-Convenience_Over_Correctness.pdf),” *IEEE Internet Computing*, volume 12, number 4, pages 89–92, July 2008. [doi:10.1109/MIC.2008.75](http://dx.doi.org/10.1109/MIC.2008.75)
1. Marius Eriksen: “[Your Server as a Function](http://monkey.org/~marius/funsrv.pdf),” at *7th Workshop on Programming Languages and Operating Systems* (PLOS), November 2013. [doi:10.1145/2525528.2525538](http://dx.doi.org/10.1145/2525528.2525538)
1. “[grpc-common Documentation](https://github.com/grpc/grpc-common),” Google, Inc., *github.com*, February 2015.
1. Aditya Narayan and Irina Singh: “[Designing and Versioning Compatible Web Services](http://www.ibm.com/developerworks/websphere/library/techarticles/0705_narayan/0705_narayan.html),” *ibm.com*, March 28, 2007.
1. Troy Hunt: “[Your API Versioning Is Wrong, Which Is Why I Decided to Do It 3 Different Wrong Ways](http://www.troyhunt.com/2014/02/your-api-versioning-is-wrong-which-is.html),” *troyhunt.com*, February 10, 2014.
1. “[API Upgrades](https://stripe.com/docs/upgrades),” Stripe, Inc., April 2015.
1. Jonas Bonér: “[Upgrade in an Akka Cluster](http://grokbase.com/t/gg/akka-user/138wd8j9e3/upgrade-in-an-akka-cluster),” email to *akka-user* mailing list, *grokbase.com*, August 28, 2013.
1. Philip A. Bernstein, Sergey Bykov, Alan Geller, et al.: “[Orleans: Distributed Virtual Actors for Programmability and Scalability](http://research.microsoft.com/pubs/210931/Orleans-MSR-TR-2014-41.pdf),” Microsoft Research Technical Report MSR-TR-2014-41, March 2014.
1. “[Microsoft Project Orleans Documentation](http://dotnet.github.io/orleans/),” Microsoft Research, *dotnet.github.io*, 2015.
1. David Mercer, Sean Hinde, Yinso Chen, and Richard A O'Keefe: “[beginner: Updating Data Structures](http://erlang.org/pipermail/erlang-questions/2007-October/030318.html),” email thread on *erlang-questions* mailing list, *erlang.com*, October 29, 2007.
1. Fred Hebert: “[Postscript: Maps](http://learnyousomeerlang.com/maps),” *learnyousomeerlang.com*, April 9, 2014.
------
| 上一章 | 目錄 | 下一章 |
| ---------------------------- | ------------------------------- | --------------------------------- |
| [第三章：儲存與檢索](ch3.md) | [設計資料密集型應用](README.md) | [第二部分：分散式資料](part-ii.md) |

925
zh-tw/ch5.md Normal file
View File

@ -0,0 +1,925 @@
# 5. 複製
![](../img/ch5.png)
> 與可能出錯的東西比，'不可能'出錯的東西最顯著的特點就是：一旦真的出錯，通常就徹底玩完了。
>
> ——道格拉斯·亞當斯（1992）
------
[TOC]
​ 複製意味著在透過網路連線的多臺機器上保留相同資料的副本。正如在[第二部分簡介](part-ii.md)中所討論的那樣，我們希望能複製資料，可能出於各種各樣的原因：
* 使得資料與使用者在地理上接近（從而減少延遲）
* 即使系統的一部分出現故障，系統也能繼續工作（從而提高可用性）
* 擴充套件可以接受讀請求的機器數量（從而提高讀取吞吐量）
本章將假設你的資料集非常小，每臺機器都可以儲存整個資料集的副本。在[第6章](ch6.md)中將放寬這個假設，討論對單個機器來說太大的資料集的分割（分片）。在後面的章節中，我們將討論複製資料系統中可能發生的各種故障，以及如何處理這些故障。
​ 如果複製中的資料不會隨時間而改變，那複製就很簡單：將資料複製到每個節點一次就萬事大吉。複製的困難之處在於處理複製資料的**變更（change）**，這就是本章所要講的。我們將討論三種流行的變更復制演算法：**單領導者（single leader）**，**多領導者（multi leader）**和**無領導者（leaderless）**。幾乎所有分散式資料庫都使用這三種方法之一。
​ 在複製時需要進行許多權衡：例如，使用同步複製還是非同步複製？如何處理失敗的副本？這些通常是資料庫中的配置選項，細節因資料庫而異，但原理在許多不同的實現中都類似。本章會討論這些決策的後果。
​ 資料庫的複製算得上是老生常談了 ——70年代研究得出的基本原則至今沒有太大變化【1】，因為網路的基本約束仍保持不變。然而在研究之外，許多開發人員仍然假設一個數據庫只有一個節點。分散式資料庫變為主流只是最近發生的事。許多程式設計師都是這一領域的新手，因此對於諸如**最終一致性（eventual consistency）**等問題存在許多誤解。在“[複製延遲問題](#複製延遲問題)”一節，我們將更加精確地瞭解最終的一致性，並討論諸如**讀己之寫（read-your-writes）**和**單調讀（monotonic read）**保證等內容。
## 領導者與追隨者
​ 儲存資料庫副本的每個節點稱為 **副本（replica）** 。當存在多個副本時，會不可避免的出現一個問題：如何確保所有資料都落在了所有的副本上？
​ 每一次向資料庫的寫入操作都需要傳播到所有副本上，否則副本就會包含不一樣的資料。最常見的解決方案被稱為 **基於領導者的複製（leader-based replication）** （也稱**主動/被動（active/passive）** 或 **主/從（master/slave）**複製），如[圖5-1](#fig5-1.png)所示。它的工作原理如下：
1. 副本之一被指定為 **領導者（leader）**，也稱為 **主庫（master|primary）** 。當客戶端要向資料庫寫入時，它必須將請求傳送給**領導者**，領導者會將新資料寫入其本地儲存。
2. 其他副本被稱為**追隨者（followers）**，亦稱為**只讀副本（read replicas）**，**從庫（slaves）**，**備庫（ sencondaries）**，**熱備（hot-standby）**[^i]。每當領導者將新資料寫入本地儲存時，它也會將資料變更傳送給所有的追隨者，稱之為**複製日誌（replication log）**記錄或**變更流（change stream）**。每個跟隨者從領導者拉取日誌，並相應更新其本地資料庫副本，方法是按照領導者處理的相同順序應用所有寫入。
3. 當客戶想要從資料庫中讀取資料時，它可以向領導者或追隨者查詢。 但只有領導者才能接受寫操作（從客戶端的角度來看從庫都是隻讀的）。
[^i]: 不同的人對**熱（hot）**，**溫（warm）**，**冷（cold）** 備份伺服器有不同的定義。 例如在PostgreSQL中，**熱備（hot standby）**指的是能接受客戶端讀請求的副本。而**溫備（warm standby）**只是追隨領導者，但不處理客戶端的任何查詢。 就本書而言，這些差異並不重要。
![](../img/fig5-1.png)
**圖5-1 基於領導者(主-從)的複製**
​ 這種複製模式是許多關係資料庫的內建功能，如PostgreSQL（從9.0版本開始），MySQL，Oracle Data Guard 【2】和SQL Server的AlwaysOn可用性組【3】。 它也被用於一些非關係資料庫，包括MongoDB，RethinkDB和Espresso 【4】。 最後，基於領導者的複製並不僅限於資料庫：像Kafka 【5】和RabbitMQ高可用佇列【6】這樣的分散式訊息代理也使用它。 某些網路檔案系統，例如DRBD這樣的塊複製裝置也與之類似。
### 同步複製與非同步複製
​ 複製系統的一個重要細節是：複製是**同步（synchronously）**發生還是**非同步（asynchronously）**發生。 （在關係型資料庫中這通常是一個配置項，其他系統通常硬編碼為其中一個）。
​ 想象[圖5-1](fig5-1.png)中發生的情況，網站的使用者更新他們的個人頭像。在某個時間點，客戶向主庫傳送更新請求；不久之後主庫就收到了請求。在某個時刻，主庫又會將資料變更轉發給自己的從庫。最後，主庫通知客戶更新成功。
[圖5-2](../img/fig5-2.png)顯示了系統各個元件之間的通訊：使用者客戶端，主庫和兩個從庫。時間從左到右流動。請求或響應訊息用粗箭頭表示。
![](../img/fig5-2.png)
**圖5-2 基於領導者的複製：一個同步從庫和一個非同步從庫**
​ 在[圖5-2]()的示例中，從庫1的複製是同步的：在向用戶報告寫入成功，並使結果對其他使用者可見之前，主庫需要等待從庫1的確認，確保從庫1已經收到寫入操作。以及在使寫入對其他客戶端可見之前接收到寫入。跟隨者2的複製是非同步的：主庫傳送訊息，但不等待從庫的響應。
​ 在這幅圖中，從庫2處理訊息前存在一個顯著的延遲。通常情況下，複製的速度相當快：大多數資料庫系統能在一秒向從庫應用變更，但它們不能提供複製用時的保證。有些情況下，從庫可能落後主庫幾分鐘或更久；例如：從庫正在從故障中恢復，系統在最大容量附近執行，或者如果節點間存在網路問題。
​ 同步複製的優點是，從庫保證有與主庫一致的最新資料副本。如果主庫突然失效，我們可以確信這些資料仍然能在從庫上上找到。缺點是，如果同步從庫沒有響應（比如它已經崩潰，或者出現網路故障，或其它任何原因），主庫就無法處理寫入操作。主庫必須阻止所有寫入，並等待同步副本再次可用。
​ 因此，將所有從庫都設定為同步的是不切實際的：任何一個節點的中斷都會導致整個系統停滯不前。實際上，如果在資料庫上啟用同步複製，通常意味著其中**一個**跟隨者是同步的，而其他的則是非同步的。如果同步從庫變得不可用或緩慢，則使一個非同步從庫同步。這保證你至少在兩個節點上擁有最新的資料副本：主庫和同步從庫。 這種配置有時也被稱為 **半同步（semi-synchronous）**【7】。
​ 通常情況下，基於領導者的複製都配置為完全非同步。 在這種情況下，如果主庫失效且不可恢復，則任何尚未複製給從庫的寫入都會丟失。 這意味著即使已經向客戶端確認成功，寫入也不能保證 **持久（Durable）** 。 然而，一個完全非同步的配置也有優點：即使所有的從庫都落後了，主庫也可以繼續處理寫入。
​ 弱化的永續性可能聽起來像是一個壞的折衷，然而非同步複製已經被廣泛使用了，特別當有很多追隨者，或追隨者異地分佈時。 稍後將在“[複製延遲問題](#複製延遲問題)”中回到這個問題。
> ### 關於複製的研究
>
> 對於非同步複製系統而言，主庫故障時有可能丟失資料。這可能是一個嚴重的問題，因此研究人員仍在研究不丟資料但仍能提供良好效能和可用性的複製方法。 例如，**鏈式複製**【8,9】]是同步複製的一種變體，已經在一些系統（如Microsoft Azure儲存【10,11】）中成功實現。
>
> 複製的一致性與**共識（consensus）**（使幾個節點就某個值達成一致）之間有著密切的聯絡，[第9章](ch9.md)將詳細地探討這一領域的理論。本章主要討論實踐中資料庫常用的簡單複製形式。
>
### 設定新從庫
​ 有時候需要設定一個新的從庫：也許是為了增加副本的數量，或替換失敗的節點。如何確保新的從庫擁有主庫資料的精確副本？
​ 簡單地將資料檔案從一個節點複製到另一個節點通常是不夠的：客戶端不斷向資料庫寫入資料，資料總是在不斷變化，標準的資料副本會在不同的時間點總是不一樣。複製的結果可能沒有任何意義。
​ 可以透過鎖定資料庫（使其不可用於寫入）來使磁碟上的檔案保持一致，但是這會違背高可用的目標。幸運的是，拉起新的從庫通常並不需要停機。從概念上講，過程如下所示：
1. 在某個時刻獲取主庫的一致性快照（如果可能），而不必鎖定整個資料庫。大多數資料庫都具有這個功能，因為它是備份必需的。對於某些場景，可能需要第三方工具，例如MySQL的innobackupex 【12】。
2. 將快照複製到新的從庫節點。
3. 從庫連線到主庫，並拉取快照之後發生的所有資料變更。這要求快照與主庫複製日誌中的位置精確關聯。該位置有不同的名稱：例如，PostgreSQL將其稱為 **日誌序列號（log sequence number, LSN）**，MySQL將其稱為 **二進位制日誌座標（binlog coordinates）**。
4. 當從庫處理完快照之後積壓的資料變更，我們說它**趕上（caught up）**了主庫。現在它可以繼續處理主庫產生的資料變化了。
建立從庫的實際步驟因資料庫而異。在某些系統中，這個過程是完全自動化的，而在另外一些系統中，它可能是一個需要由管理員手動執行的，有點神祕的多步驟工作流。
### 處理節點宕機
​ 系統中的任何節點都可能宕機，可能因為意外的故障，也可能由於計劃內的維護（例如，重啟機器以安裝核心安全補丁）。對運維而言，能在系統不中斷服務的情況下重啟單個節點好處多多。我們的目標是，即使個別節點失效，也能保持整個系統執行，並儘可能控制節點停機帶來的影響。
​ 如何透過基於主庫的複製實現高可用？
#### 從庫失效：追趕恢復
​ 在其本地磁碟上，每個從庫記錄從主庫收到的資料變更。如果從庫崩潰並重新啟動，或者，如果主庫和從庫之間的網路暫時中斷，則比較容易恢復：從庫可以從日誌中知道，在發生故障之前處理的最後一個事務。因此，從庫可以連線到主庫，並請求在從庫斷開連線時發生的所有資料變更。當應用完所有這些變化後，它就趕上了主庫，並可以像以前一樣繼續接收資料變更流。
#### 主庫失效：故障切換
​ 主庫失效處理起來相當棘手：其中一個從庫需要被提升為新的主庫，需要重新配置客戶端，以將它們的寫操作傳送給新的主庫，其他從庫需要開始拉取來自新主庫的資料變更。這個過程被稱為**故障切換（failover）**。
​ 故障切換可以手動進行（通知管理員主庫掛了，並採取必要的步驟來建立新的主庫）或自動進行。自動故障切換過程通常由以下步驟組成：
1. 確認主庫失效。有很多事情可能會出錯：崩潰，停電，網路問題等等。沒有萬無一失的方法來檢測出現了什麼問題，所以大多數系統只是簡單使用 **超時（Timeout）** ：節點頻繁地相互來回傳遞訊息，並且如果一個節點在一段時間內（例如30秒）沒有響應，就認為它掛了（因為計劃內維護而故意關閉主庫不算）。
2. 選擇一個新的主庫。這可以透過選舉過程（主庫由剩餘副本以多數選舉產生）來完成，或者可以由之前選定的**控制器節點（controller node）**來指定新的主庫。主庫的最佳人選通常是擁有舊主庫最新資料副本的從庫（最小化資料損失）。讓所有的節點同意一個新的領導者，是一個**共識**問題，將在[第9章](ch9.md)詳細討論。
3. 重新配置系統以啟用新的主庫。客戶端現在需要將它們的寫請求傳送給新主庫（將在“[請求路由](ch6.md#請求路由)”中討論這個問題）。如果老領導回來，可能仍然認為自己是主庫，沒有意識到其他副本已經讓它下臺了。系統需要確保老領導認可新領導，成為一個從庫。
故障切換會出現很多大麻煩：
* 如果使用非同步複製，則新主庫可能沒有收到老主庫宕機前最後的寫入操作。在選出新主庫後，如果老主庫重新加入叢集，新主庫在此期間可能會收到衝突的寫入，那這些寫入該如何處理？最常見的解決方案是簡單丟棄老主庫未複製的寫入，這很可能打破客戶對於資料永續性的期望。
* 如果資料庫需要和其他外部儲存相協調，那麼丟棄寫入內容是極其危險的操作。例如在GitHub 【13】的一場事故中，一個過時的MySQL從庫被提升為主庫。資料庫使用自增ID作為主鍵，因為新主庫的計數器落後於老主庫的計數器，所以新主庫重新分配了一些已經被老主庫分配掉的ID作為主鍵。這些主鍵也在Redis中使用，主鍵重用使得MySQL和Redis中資料產生不一致，最後導致一些私有資料洩漏到錯誤的使用者手中。
* 發生某些故障時（見[第8章](ch8.md)）可能會出現兩個節點都以為自己是主庫的情況。這種情況稱為 **腦裂(split brain)**，非常危險：如果兩個主庫都可以接受寫操作，卻沒有衝突解決機制（參見“[多領導者複製](#多領導者複製)”），那麼資料就可能丟失或損壞。一些系統採取了安全防範措施：當檢測到兩個主庫節點同時存在時會關閉其中一個節點[^ii]，但設計粗糙的機制可能最後會導致兩個節點都被關閉【14】。
[^ii]: 這種機制稱為 **遮蔽（fencing）**，充滿感情的術語是：**爆彼之頭（Shoot The Other Node In The Head, STONITH）**。
* 主庫被宣告死亡之前的正確超時應該怎麼配置？在主庫失效的情況下，超時時間越長，意味著恢復時間也越長。但是如果超時設定太短，又可能會出現不必要的故障切換。例如，臨時負載峰值可能導致節點的響應時間超時，或網路故障可能導致資料包延遲。如果系統已經處於高負載或網路問題的困擾之中，那麼不必要的故障切換可能會讓情況變得更糟糕。
這些問題沒有簡單的解決方案。因此，即使軟體支援自動故障切換，不少運維團隊還是更願意手動執行故障切換。
節點故障、不可靠的網路、對副本一致性，永續性，可用性和延遲的權衡 ，這些問題實際上是分散式系統中的基本問題。[第8章](ch8.md)和[第9章](ch9.md)將更深入地討論它們。
### 複製日誌的實現
基於主庫的複製底層是如何工作的？實踐中有好幾種不同的複製方式，所以先簡要地看一下。
#### 基於語句的複製
​ 在最簡單的情況下，主庫記錄下它執行的每個寫入請求（**語句（statement）**）並將該語句日誌傳送給其從庫。對於關係資料庫來說，這意味著每個`INSERT`，`UPDATE`或`DELETE`語句都被轉發給每個從庫，每個從庫解析並執行該SQL語句，就像從客戶端收到一樣。
雖然聽上去很合理，但有很多問題會搞砸這種複製方式：
* 任何呼叫**非確定性函式（nondeterministic）**的語句，可能會在每個副本上生成不同的值。例如，使用`NOW()`獲取當前日期時間，或使用`RAND()`獲取一個隨機數。
* 如果語句使用了**自增列（auto increment）**，或者依賴於資料庫中的現有資料（例如，`UPDATE ... WHERE <某些條件>`），則必須在每個副本上按照完全相同的順序執行它們，否則可能會產生不同的效果。當有多個併發執行的事務時，這可能成為一個限制。
* 有副作用的語句（例如，觸發器，儲存過程，使用者定義的函式）可能會在每個副本上產生不同的副作用，除非副作用是絕對確定的。
的確有辦法繞開這些問題 ——例如，當語句被記錄時，主庫可以用固定的返回值替換任何不確定的函式呼叫，以便從庫獲得相同的值。但是由於邊緣情況實在太多了，現在通常會選擇其他的複製方法。
​ 基於語句的複製在5.1版本前的MySQL中使用。因為它相當緊湊，現在有時候也還在用。但現在在預設情況下，如果語句中存在任何不確定性，MySQL會切換到基於行的複製（稍後討論）。 VoltDB使用了基於語句的複製，但要求事務必須是確定性的，以此來保證安全【15】。
#### 傳輸預寫式日誌（WAL）
在[第3章](ch3.md)中，我們討論了儲存引擎如何在磁碟上表示資料，並且我們發現，通常寫操作都是追加到日誌中：
* 對於日誌結構儲存引擎（請參閱“[SSTables和LSM樹](ch3.md#SSTables和LSM樹)”），日誌是主要的儲存位置。日誌段在後臺壓縮，並進行垃圾回收。
* 對於覆寫單個磁碟塊的[B樹](ch3.md#B樹)，每次修改都會先寫入 **預寫式日誌（Write Ahead Log, WAL）**，以便崩潰後索引可以恢復到一個一致的狀態。
在任何一種情況下，日誌都是包含所有資料庫寫入的僅追加位元組序列。可以使用完全相同的日誌在另一個節點上構建副本：除了將日誌寫入磁碟之外，主庫還可以透過網路將其傳送給其從庫。
​ 當從庫應用這個日誌時，它會建立和主庫一模一樣資料結構的副本。
​ PostgreSQL和Oracle等使用這種複製方法【16】。主要缺點是日誌記錄的資料非常底層：WAL包含哪些磁碟塊中的哪些位元組發生了更改。這使複製與儲存引擎緊密耦合。如果資料庫將其儲存格式從一個版本更改為另一個版本，通常不可能在主庫和從庫上執行不同版本的資料庫軟體。
​ 看上去這可能只是一個微小的實現細節，但卻可能對運維產生巨大的影響。如果複製協議允許從庫使用比主庫更新的軟體版本，則可以先升級從庫，然後執行故障切換，使升級後的節點之一成為新的主庫，從而執行資料庫軟體的零停機升級。如果複製協議不允許版本不匹配（傳輸WAL經常出現這種情況），則此類升級需要停機。
#### 邏輯日誌複製（基於行）
​ 另一種方法是，複製和儲存引擎使用不同的日誌格式，這樣可以使複製日誌從儲存引擎內部分離出來。這種複製日誌被稱為邏輯日誌，以將其與儲存引擎的（物理）資料表示區分開來。
關係資料庫的邏輯日誌通常是以行的粒度描述對資料庫表的寫入的記錄序列：
* 對於插入的行，日誌包含所有列的新值。
* 對於刪除的行，日誌包含足夠的資訊來唯一標識已刪除的行。通常是主鍵，但是如果表上沒有主鍵，則需要記錄所有列的舊值。
* 對於更新的行，日誌包含足夠的資訊來唯一標識更新的行，以及所有列的新值（或至少所有已更改的列的新值）。
修改多行的事務會生成多個這樣的日誌記錄，後面跟著一條記錄，指出事務已經提交。 MySQL的二進位制日誌（當配置為使用基於行的複製時）使用這種方法【17】。
​ 由於邏輯日誌與儲存引擎內部分離，因此可以更容易地保持向後相容，從而使領導者和跟隨者能夠執行不同版本的資料庫軟體甚至不同的儲存引擎。
​ 對於外部應用程式來說，邏輯日誌格式也更容易解析。如果要將資料庫的內容傳送到外部系統（如資料），這一點很有用，例如複製到資料倉庫進行離線分析，或建立自定義索引和快取【18】。 這種技術被稱為 **資料變更捕獲（change data capture）**，第11章將重新講到它。
#### 基於觸發器的複製
​ 到目前為止描述的複製方法是由資料庫系統實現的，不涉及任何應用程式程式碼。在很多情況下，這就是你想要的。但在某些情況下需要更多的靈活性。例如，如果您只想複製資料的一個子集，或者想從一種資料庫複製到另一種資料庫，或者如果您需要衝突解決邏輯（參閱“[處理寫入衝突](#處理寫入衝突)”），則可能需要將複製移動到應用程式層。
​ 一些工具，如Oracle Golden Gate 【19】，可以透過讀取資料庫日誌，使得其他應用程式可以使用資料。另一種方法是使用許多關係資料庫自帶的功能：觸發器和儲存過程。
​ 觸發器允許您註冊在資料庫系統中發生資料更改（寫入事務）時自動執行的自定義應用程式程式碼。觸發器有機會將更改記錄到一個單獨的表中，使用外部程式讀取這個表，再加上任何業務邏輯處理，會後將資料變更復制到另一個系統去。例如，Databus for Oracle 【20】和Bucardo for Postgres 【21】就是這樣工作的。
​ 基於觸發器的複製通常比其他複製方法具有更高的開銷，並且比資料庫的內建複製更容易出錯，也有很多限制。然而由於其靈活性，仍然是很有用的。
## 複製延遲問題
​ 容忍節點故障只是需要複製的一個原因。正如在[第二部分](part-ii.md)的介紹中提到的，另一個原因是可擴充套件性（處理比單個機器更多的請求）和延遲（讓副本在地理位置上更接近使用者）。
​ 基於主庫的複製要求所有寫入都由單個節點處理，但只讀查詢可以由任何副本處理。所以對於讀多寫少的場景（Web上的常見模式），一個有吸引力的選擇是建立很多從庫，並將讀請求分散到所有的從庫上去。這樣能減小主庫的負載，並允許向最近的副本傳送讀請求。
​ 在這種擴充套件體系結構中，只需新增更多的追隨者，就可以提高只讀請求的服務容量。但是，這種方法實際上只適用於非同步複製——如果嘗試同步複製到所有追隨者，則單個節點故障或網路中斷將使整個系統無法寫入。而且越多的節點越有可能會被關閉，所以完全同步的配置是非常不可靠的。
​ 不幸的是，當應用程式從非同步從庫讀取時，如果從庫落後，它可能會看到過時的資訊。這會導致資料庫中出現明顯的不一致：同時對主庫和從庫執行相同的查詢，可能得到不同的結果，因為並非所有的寫入都反映在從庫中。這種不一致只是一個暫時的狀態——如果停止寫入資料庫並等待一段時間，從庫最終會趕上並與主庫保持一致。出於這個原因，這種效應被稱為 **最終一致性（eventually consistency）**[^iii]【22,23】
[^iii]: 道格拉斯·特里（Douglas Terry）等人創造了術語最終一致性。 【24】 並經由Werner Vogels 【22】推廣，成為許多NoSQL專案的戰吼。 然而，不只有NoSQL資料庫是最終一致的：關係型資料庫中的非同步複製追隨者也有相同的特性。
​ “最終”一詞故意含糊不清：總的來說，副本落後的程度是沒有限制的。在正常的操作中，**複製延遲（replication lag）**，即寫入主庫到反映至從庫之間的延遲，可能僅僅是幾分之一秒，在實踐中並不顯眼。但如果系統在接近極限的情況下執行，或網路中存在問題，延遲可以輕而易舉地超過幾秒，甚至幾分鐘。
​ 因為滯後時間太長引入的不一致性，可不僅是一個理論問題，更是應用設計中會遇到的真實問題。本節將重點介紹三個由複製延遲問題的例子，並簡述解決這些問題的一些方法。
### 讀己之寫
​ 許多應用讓使用者提交一些資料，然後檢視他們提交的內容。可能是使用者資料庫中的記錄，也可能是對討論主題的評論，或其他類似的內容。提交新資料時，必須將其傳送給領導者，但是當用戶檢視資料時，可以從追隨者讀取。如果資料經常被檢視，但只是偶爾寫入，這是非常合適的。
​ 但對於非同步複製，問題就來了。如[圖5-3](fig5-3.png)所示：如果使用者在寫入後馬上就檢視資料，則新資料可能尚未到達副本。對使用者而言，看起來好像是剛提交的資料丟失了，使用者會不高興，可以理解。
![](../img/fig5-3.png)
**圖5-3 使用者寫入後從舊副本中讀取資料。需要寫後讀(read-after-write)的一致性來防止這種異常**
​ 在這種情況下，我們需要 **讀寫一致性（read-after-write consistency）**，也稱為 **讀己之寫一致性（read-your-writes consistency）**【24】。這是一個保證，如果使用者重新載入頁面，他們總會看到他們自己提交的任何更新。它不會對其他使用者的寫入做出承諾：其他使用者的更新可能稍等才會看到。它保證使用者自己的輸入已被正確儲存。
如何在基於領導者的複製系統中實現讀後一致性？有各種可能的技術，這裡說一些：
* 讀使用者**可能已經修改過**的內容時，都從主庫讀；這就要求有一些方法，不用實際查詢就可以知道使用者是否修改了某些東西。舉個例子，社交網路上的使用者個人資料資訊通常只能由使用者本人編輯，而不能由其他人編輯。因此一個簡單的規則是：從主庫讀取使用者自己的檔案，在從庫讀取其他使用者的檔案。
* 如果應用中的大部分內容都可能被使用者編輯，那這種方法就沒用了，因為大部分內容都必須從主庫讀取（擴容讀就沒效果了）。在這種情況下可以使用其他標準來決定是否從主庫讀取。例如可以跟蹤上次更新的時間，在上次更新後的一分鐘內，從主庫讀。還可以監控從庫的複製延遲，防止對任意比主庫滯後超過一分鐘的從庫發出查詢。
* 客戶端可以記住最近一次寫入的時間戳，系統需要確保從庫為該使用者提供任何查詢時，該時間戳前的變更都已經傳播到了本從庫中。如果當前從庫不夠新，則可以從另一個從庫讀，或者等待從庫追趕上來。
時間戳可以是邏輯時間戳（指示寫入順序的東西，例如日誌序列號）或實際系統時鐘（在這種情況下，時鐘同步變得至關重要；參閱“[不可靠的時鐘](ch8.md#不可靠的時鐘)”）。
* 如果您的副本分佈在多個數據中心（出於可用性目的與使用者儘量在地理上接近），則會增加複雜性。任何需要由領導者提供服務的請求都必須路由到包含主庫的資料中心。
另一種複雜的情況是：如果同一個使用者從多個裝置請求服務，例如桌面瀏覽器和移動APP。這種情況下可能就需要提供跨裝置的寫後讀一致性：如果使用者在某個裝置上輸入了一些資訊，然後在另一個裝置上檢視，則應該看到他們剛輸入的資訊。
在這種情況下，還有一些需要考慮的問題：
* 記住使用者上次更新時間戳的方法變得更加困難，因為一臺裝置上執行的程式不知道另一臺裝置上發生了什麼。元資料需要一箇中心儲存。
* 如果副本分佈在不同的資料中心，很難保證來自不同裝置的連線會路由到同一資料中心。 （例如，使用者的臺式計算機使用家庭寬頻連線，而移動裝置使用蜂窩資料網路，則裝置的網路路線可能完全不同）。如果你的方法需要讀主庫，可能首先需要把來自同一使用者的請求路由到同一個資料中心。
### 單調讀
​ 從非同步從庫讀取第二個異常例子是，使用者可能會遇到 **時光倒流（moving backward in time）**。
​ 如果使用者從不同從庫進行多次讀取，就可能發生這種情況。例如，[圖5-4](../img/fig5-4.png)顯示了使用者2345兩次進行相同的查詢，首先查詢了一個延遲很小的從庫，然後是一個延遲較大的從庫。 （如果使用者重新整理網頁，而每個請求被路由到一個隨機的伺服器，這種情況是很有可能的。）第一個查詢返回最近由使用者1234新增的評論，但是第二個查詢不返回任何東西，因為滯後的從庫還沒有拉取寫入內容。在效果上相比第一個查詢，第二個查詢是在更早的時間點來觀察系統。如果第一個查詢沒有返回任何內容，那問題並不大，因為使用者2345可能不知道使用者1234最近添加了評論。但如果使用者2345先看見使用者1234的評論，然後又看到它消失，那麼對於使用者2345，就很讓人頭大了。
![](../img/fig5-4.png)
**圖5-4 使用者首先從新副本讀取，然後從舊副本讀取。時光倒流。為了防止這種異常，我們需要單調的讀取。**
​ **單調讀（Monotonic reads）**【23】是這種異常不會發生的保證。這是一個比**強一致性（strong consistency）**更弱，但比**最終一致性（eventually consistency）**更強的保證。當讀取資料時，您可能會看到一箇舊值；單調讀取僅意味著如果一個使用者順序地進行多次讀取，則他們不會看到時間後退，即，如果先前讀取到較新的資料，後續讀取不會得到更舊的資料。
​ 實現單調讀取的一種方式是確保每個使用者總是從同一個副本進行讀取（不同的使用者可以從不同的副本讀取）。例如，可以基於使用者ID的雜湊來選擇副本，而不是隨機選擇副本。但是，如果該副本失敗，使用者的查詢將需要重新路由到另一個副本。
### 一致字首讀
第三個複製延遲例子違反了因果律。 想象一下Poons先生和Cake夫人之間的以下簡短對話：
> *Mr. Poons*
> ​ Mrs. Cake，你能看到多遠的未來？
>
> *Mrs. Cake*
> ​ 通常約十秒鐘，Mr. Poons.
這兩句話之間有因果關係：Cake夫人聽到了Poons先生的問題並回答了這個問題。
​ 現在，想象第三個人正在透過從庫來聽這個對話。 Cake夫人說的內容是從一個延遲很低的從庫讀取的，但Poons先生所說的內容，從庫的延遲要大的多（見[圖5-5](../img/fig5-5.png)）。 於是，這個觀察者會聽到以下內容：
> *Mrs. Cake*
> ​ 通常約十秒鐘，Mr. Poons.
>
> *Mr. Poons*
> ​ Mrs. Cake，你能看到多遠的未來？
對於觀察者來說，看起來好像Cake夫人在Poons先生髮問前就回答了這個問題。
這種超能力讓人印象深刻，但也會把人搞糊塗。【25】。
![](../img/fig5-5.png)
**圖5-5 如果某些分割槽的複製速度慢於其他分割槽，那麼觀察者在看到問題之前可能會看到答案。**
​ 防止這種異常，需要另一種型別的保證：**一致字首讀（consistent prefix reads）**【23】。 這個保證說：如果一系列寫入按某個順序發生，那麼任何人讀取這些寫入時，也會看見它們以同樣的順序出現。
​ 這是**分割槽（partitioned）**（**分片（sharded）**）資料庫中的一個特殊問題，將在第6章中討論。如果資料庫總是以相同的順序應用寫入，則讀取總是會看到一致的字首，所以這種異常不會發生。但是在許多分散式資料庫中，不同的分割槽獨立執行，因此不存在**全域性寫入順序**：當用戶從資料庫中讀取資料時，可能會看到資料庫的某些部分處於較舊的狀態，而某些處於較新的狀態。
​ 一種解決方案是，確保任何因果相關的寫入都寫入相同的分割槽。對於某些無法高效完成這種操作的應用，還有一些顯式跟蹤因果依賴關係的演算法，本書將在“關係與併發”一節中返回這個主題。
### 複製延遲的解決方案
​ 在使用最終一致的系統時，如果複製延遲增加到幾分鐘甚至幾小時，則應該考慮應用程式的行為。如果答案是“沒問題”，那很好。但如果結果對於使用者來說是不好體驗，那麼設計系統來提供更強的保證是很重要的，例如**寫後讀**。明明是非同步複製卻假設複製是同步的，這是很多麻煩的根源。
​ 如前所述，應用程式可以提供比底層資料庫更強有力的保證，例如透過主庫進行某種讀取。但在應用程式程式碼中處理這些問題是複雜的，容易出錯。
​ 如果應用程式開發人員不必擔心微妙的複製問題，並可以信賴他們的資料庫“做了正確的事情”，那該多好呀。這就是**事務（transaction）**存在的原因：**資料庫透過事務提供強大的保證**，所以應用程式可以更加簡單。
​ 單節點事務已經存在了很長時間。然而在走向分散式（複製和分割槽）資料庫時，許多系統放棄了事務。聲稱事務在效能和可用性上的代價太高，並斷言在可擴充套件系統中最終一致性是不可避免的。這個敘述有一些道理，但過於簡單了，本書其餘部分將提出更為細緻的觀點。第七章和第九章將回到事務的話題，並討論一些替代機制。
## 多主複製
​ 本章到目前為止，我們只考慮使用單個領導者的複製架構。 雖然這是一種常見的方法，但也有一些有趣的選擇。
​ 基於領導者的複製有一個主要的缺點：只有一個主庫，而所有的寫入都必須透過它。如果出於任何原因（例如和主庫之間的網路連線中斷）無法連線到主庫， 就無法向資料庫寫入。
[^iv]: 如果資料庫被分割槽（見第6章），每個分割槽都有一個領導。 不同的分割槽可能在不同的節點上有其領導者，但是每個分割槽必須有一個領導者節點。
​ 基於領導者的複製模型的自然延伸是允許多個節點接受寫入。 複製仍然以同樣的方式發生：處理寫入的每個節點都必須將該資料更改轉發給所有其他節點。 稱之為**多領導者配置**（也稱多主、多活複製）。 在這種情況下，每個領導者同時扮演其他領導者的追隨者。
### 多主複製的應用場景
​ 在單個數據中心內部使用多個主庫很少是有意義的，因為好處很少超過複雜性的代價。 但在一些情況下，多活配置是也合理的。
#### 運維多個數據中心
​ 假如你有一個數據庫，副本分散在好幾個不同的資料中心（也許這樣可以容忍單個數據中心的故障，或地理上更接近使用者）。 使用常規的基於領導者的複製設定，主庫必須位於其中一個數據中心，且所有寫入都必須經過該資料中心。
​ 多領導者配置中可以在每個資料中心都有主庫。 [圖5-6](../img/fig5-6.png)展示了這個架構的樣子。 在每個資料中心內使用常規的主從複製；在資料中心之間，每個資料中心的主庫都會將其更改複製到其他資料中心的主庫中。
![](../img/fig5-6.png)
**圖5-6 跨多個數據中心的多主複製**
我們來比較一下在運維多個數據中心時，單主和多主的適應情況。
***效能***
​ 在單活配置中，每個寫入都必須穿過網際網路，進入主庫所在的資料中心。這可能會增加寫入時間，並可能違背了設定多個數據中心的初心。在多活配置中，每個寫操作都可以在本地資料中心進行處理，並與其他資料中心非同步複製。因此，資料中心之間的網路延遲對使用者來說是透明的，這意味著感覺到的效能可能會更好。
***容忍資料中心停機***
​ 在單主配置中，如果主庫所在的資料中心發生故障，故障切換可以使另一個數據中心裡的追隨者成為領導者。在多活配置中，每個資料中心可以獨立於其他資料中心繼續執行，並且當發生故障的資料中心歸隊時，複製會自動趕上。
***容忍網路問題***
​ 資料中心之間的通訊通常穿過公共網際網路，這可能不如資料中心內的本地網路可靠。單主配置對這資料中心間的連線問題非常敏感，因為透過這個連線進行的寫操作是同步的。採用非同步複製功能的多活配置通常能更好地承受網路問題：臨時的網路中斷並不會妨礙正在處理的寫入。
​ 有些資料庫預設情況下支援多主配置，但使用外部工具實現也很常見，例如用於MySQL的Tungsten Replicator 【26】，用於PostgreSQL的BDR【27】以及用於Oracle的GoldenGate 【19】。
​ 儘管多主複製有這些優勢，但也有一個很大的缺點：兩個不同的資料中心可能會同時修改相同的資料，寫衝突是必須解決的（如[圖5-6](../img/fig5-6.png)中“[衝突解決](#衝突解決)”）。本書將在“[處理寫入衝突](#處理寫入衝突)”中詳細討論這個問題。
​ 由於多主複製在許多資料庫中都屬於改裝的功能，所以常常存在微妙的配置缺陷，且經常與其他資料庫功能之間出現意外的反應。例如自增主鍵、觸發器、完整性約束等，都可能會有麻煩。因此，多主複製往往被認為是危險的領域，應儘可能避免【28】。
#### 需要離線操作的客戶端
​ 多主複製的另一種適用場景是：應用程式在斷網之後仍然需要繼續工作。
​ 例如，考慮手機，膝上型電腦和其他裝置上的日曆應用。無論裝置目前是否有網際網路連線，你需要能隨時檢視你的會議（發出讀取請求），輸入新的會議（發出寫入請求）。如果在離線狀態下進行任何更改，則裝置下次上線時，需要與伺服器和其他裝置同步。
​ 在這種情況下，每個裝置都有一個充當領導者的本地資料庫（它接受寫請求），並且在所有裝置上的日曆副本之間同步時，存在非同步的多主複製過程。複製延遲可能是幾小時甚至幾天，具體取決於何時可以訪問網際網路。
​ 從架構的角度來看，這種設定實際上與資料中心之間的多領導者複製類似，每個裝置都是一個“資料中心”，而它們之間的網路連線是極度不可靠的。從歷史上各類日曆同步功能的破爛實現可以看出，想把多活配好是多麼困難的一件事。
​ 有一些工具旨在使這種多領導者配置更容易。例如，CouchDB就是為這種操作模式而設計的【29】。
#### 協同編輯
​ 實時協作編輯應用程式允許多個人同時編輯文件。例如，Etherpad 【30】和Google Docs 【31】允許多人同時編輯文字文件或電子表格（該演算法在“[自動衝突解決](#自動衝突解決)”中簡要討論）。我們通常不會將協作式編輯視為資料庫複製問題，但與前面提到的離線編輯用例有許多相似之處。當一個使用者編輯文件時，所做的更改將立即應用到其本地副本（Web瀏覽器或客戶端應用程式中的文件狀態），並非同步複製到伺服器和編輯同一文件的任何其他使用者。
​ 如果要保證不會發生編輯衝突，則應用程式必須先取得文件的鎖定，然後使用者才能對其進行編輯。如果另一個使用者想要編輯同一個文件，他們首先必須等到第一個使用者提交修改並釋放鎖定。這種協作模式相當於在領導者上進行交易的單領導者複製。
​ 但是，為了加速協作，您可能希望將更改的單位設定得非常小（例如，一個按鍵），並避免鎖定。這種方法允許多個使用者同時進行編輯，但同時也帶來了多領導者複製的所有挑戰，包括需要解決衝突【32】。
### 處理寫入衝突
​ 多領導者複製的最大問題是可能發生寫衝突，這意味著需要解決衝突。
​ 例如，考慮一個由兩個使用者同時編輯的維基頁面，如[圖5-7](../img/fig5-7.png)所示。使用者1將頁面的標題從A更改為B，並且使用者2同時將標題從A更改為C。每個使用者的更改已成功應用到其本地主庫。但當非同步複製時，會發現衝突【33】。單主資料庫中不會出現此問題。
![](../img/fig5-7.png)
**圖5-7 兩個主庫同時更新同一記錄引起的寫入衝突**
#### 同步與非同步衝突檢測
​ 在單主資料庫中，第二個寫入將被阻塞，並等待第一個寫入完成，或中止第二個寫入事務，強制使用者重試。另一方面，在多活配置中，兩個寫入都是成功的，並且在稍後的時間點僅僅非同步地檢測到衝突。那時要求使用者解決衝突可能為時已晚。
​ 原則上，可以使衝突檢測同步 - 即等待寫入被複制到所有副本，然後再告訴使用者寫入成功。但是，透過這樣做，您將失去多主複製的主要優點：允許每個副本獨立接受寫入。如果您想要同步衝突檢測，那麼您可以使用單主程式複製。
#### 避免衝突
​ 處理衝突的最簡單的策略就是避免它們：如果應用程式可以確保特定記錄的所有寫入都透過同一個領導者，那麼衝突就不會發生。由於多領導者複製處理的許多實現衝突相當不好，避免衝突是一個經常推薦的方法【34】。
​ 例如，在使用者可以編輯自己的資料的應用程式中，可以確保來自特定使用者的請求始終路由到同一資料中心，並使用該資料中心的領導者進行讀寫。不同的使用者可能有不同的“家庭”資料中心（可能根據使用者的地理位置選擇），但從任何使用者的角度來看，配置基本上都是單一的領導者。
​ 但是，有時您可能需要更改指定的記錄的主庫——可能是因為一個數據中心出現故障，您需要將流量重新路由到另一個數據中心，或者可能是因為使用者已經遷移到另一個位置，現在更接近不同的資料中心。在這種情況下，衝突避免會中斷，你必須處理不同主庫同時寫入的可能性。
#### 收斂至一致的狀態
​ 單主資料庫按順序進行寫操作：如果同一個欄位有多個更新，則最後一個寫操作將決定該欄位的最終值。
​ 在多主配置中，沒有明確的寫入順序，所以最終值應該是什麼並不清楚。在[圖5-7](../img/fig5-7.png)中，在主庫1中標題首先更新為B而後更新為C；在主庫2中，首先更新為C，然後更新為B。兩個順序都不是“更正確”的。
​ 如果每個副本只是按照它看到寫入的順序寫入，那麼資料庫最終將處於不一致的狀態：最終值將是在主庫1的C和主庫2的B。這是不可接受的，每個複製方案都必須確保資料在所有副本中最終都是相同的。因此，資料庫必須以一種**收斂（convergent）**的方式解決衝突，這意味著所有副本必須在所有變更復制完成時收斂至一個相同的最終值。
實現衝突合併解決有多種途徑：
* 給每個寫入一個唯一的ID（例如，一個時間戳，一個長的隨機數，一個UUID或者一個鍵和值的雜湊），挑選最高ID的寫入作為勝利者，並丟棄其他寫入。如果使用時間戳，這種技術被稱為**最後寫入勝利（LWW, last write wins）**。雖然這種方法很流行，但是很容易造成資料丟失【35】。我們將在[本章末尾](#檢測併發寫入)更詳細地討論LWW。
* 為每個副本分配一個唯一的ID，ID編號更高的寫入具有更高的優先順序。這種方法也意味著資料丟失。
* 以某種方式將這些值合併在一起 - 例如，按字母順序排序，然後連線它們（在[圖5-7](../img/fig5-7.png)中，合併的標題可能類似於“B/C”）。
* 用一種可保留所有資訊的顯式資料結構來記錄衝突，並編寫解決衝突的應用程式程式碼（也許透過提示使用者的方式）。
#### 自定義衝突解決邏輯
​ 作為解決衝突最合適的方法可能取決於應用程式，大多數多主複製工具允許使用應用程式程式碼編寫衝突解決邏輯。該程式碼可以在寫入或讀取時執行：
***寫時執行***
​ 只要資料庫系統檢測到複製更改日誌中存在衝突，就會呼叫衝突處理程式。例如，Bucardo允許您為此編寫一段Perl程式碼。這個處理程式通常不能提示使用者——它在後臺程序中執行，並且必須快速執行。
***讀時執行***
​ 當檢測到衝突時，所有衝突寫入被儲存。下一次讀取資料時，會將這些多個版本的資料返回給應用程式。應用程式可能會提示使用者或自動解決衝突，並將結果寫回資料庫。例如，CouchDB以這種方式工作。
​ 請注意，衝突解決通常適用於單個行或文件層面，而不是整個事務【36】。因此，如果您有一個事務會原子性地進行幾次不同的寫入（請參閱第7章），則對於衝突解決而言，每個寫入仍需分開單獨考慮。
> #### 題外話：自動衝突解決
>
> ​ 衝突解決規則可能很快變得複雜，並且自定義程式碼可能容易出錯。亞馬遜是一個經常被引用的例子，由於衝突解決處理程式令人意外的效果：一段時間以來，購物車上的衝突解決邏輯將保留新增到購物車的物品，但不包括從購物車中移除的物品。因此，顧客有時會看到物品重新出現在他們的購物車中，即使他們之前已經被移走【37】。
>
> 已經有一些有趣的研究來自動解決由於資料修改引起的衝突。有幾行研究值得一提：
>
> * **無衝突複製資料型別（Conflict-free replicated datatypes）**（CRDT）【32,38】是可以由多個使用者同時編輯的集合，對映，有序列表，計數器等的一系列資料結構，它們以合理的方式自動解決衝突。一些CRDT已經在Riak 2.0中實現【39,40】。
> * **可合併的持久資料結構（Mergeable persistent data structures）**【41】顯式跟蹤歷史記錄，類似於Git版本控制系統，並使用三向合併功能（而CRDT使用雙向合併）。
> * **可執行的轉換（operational transformation）**[42]是Etherpad 【30】和Google Docs 【31】等合作編輯應用背後的衝突解決演算法。它是專為同時編輯專案的有序列表而設計的，例如構成文字文件的字元列表。
>
> 這些演算法在資料庫中的實現還很年輕，但很可能將來它們將被整合到更多的複製資料系統中。自動衝突解決方案可以使應用程式處理多領導者資料同步更為簡單。
>
#### 什麼是衝突？
​ 有些衝突是顯而易見的。在[圖5-7](../img/fig5-7.png)的例子中，兩個寫操作併發地修改了同一條記錄中的同一個欄位，並將其設定為兩個不同的值。毫無疑問這是一個衝突。
​ 其他型別的衝突可能更為微妙，難以發現。例如，考慮一個會議室預訂系統：它記錄誰訂了哪個時間段的哪個房間。應用需要確保每個房間只有一組人同時預定（即不得有相同房間的重疊預訂）。在這種情況下，如果同時為同一個房間建立兩個不同的預訂，則可能會發生衝突。即使應用程式在允許使用者進行預訂之前檢查可用性，如果兩次預訂是由兩個不同的領導者進行的，則可能會有衝突。
​ 現在還沒有一個現成的答案，但在接下來的章節中，我們將更好地瞭解這個問題。我們將在第7章中看到更多的衝突示例，在[第12章](ch12.md)中我們將討論用於檢測和解決複製系統中衝突的可擴充套件方法。
### 多主複製拓撲
​ **複製拓撲**（replication topology）描述寫入從一個節點傳播到另一個節點的通訊路徑。如果你有兩個領導者，如[圖5-7]()所示，只有一個合理的拓撲結構：領導者1必須把他所有的寫到領導者2，反之亦然。當有兩個以上的領導，各種不同的拓撲是可能的。[圖5-8]()舉例說明了一些例子。
![](../img/fig5-8.png)
**圖5-8 三個可以設定多領導者複製的示例拓撲。**
​ 最普遍的拓撲是全部到全部（[圖5-8 [c]]()），其中每個領導者將其寫入每個其他領導。但是，也會使用更多受限制的拓撲：例如，預設情況下，MySQL僅支援**環形拓撲（circular topology）**【34】，其中每個節點接收來自一個節點的寫入，並將這些寫入（加上自己的任何寫入）轉發給另一個節點。另一種流行的拓撲結構具有星形的形狀[^v]。個指定的根節點將寫入轉發給所有其他節點。星型拓撲可以推廣到樹。
[^v]: 不要與星型模式混淆（請參閱“[分析模式：星型還是雪花](ch2.md#分析模式：星型還是雪花)”），其中描述了資料模型的結構，而不是節點之間的通訊拓撲。
​ 在圓形和星形拓撲中，寫入可能需要在到達所有副本之前透過多個節點。因此，節點需要轉發從其他節點收到的資料更改。為了防止無限複製迴圈，每個節點被賦予一個唯一的識別符號，並且在複製日誌中，每個寫入都被標記了所有已經過的節點的識別符號【43】。當一個節點收到用自己的識別符號標記的資料更改時，該資料更改將被忽略，因為節點知道它已經被處理過。
​ 迴圈和星型拓撲的問題是，如果只有一個節點發生故障，則可能會中斷其他節點之間的複製訊息流，導致它們無法通訊，直到節點修復。拓撲結構可以重新配置為在發生故障的節點上工作，但在大多數部署中，這種重新配置必須手動完成。更密集連線的拓撲結構（例如全部到全部）的容錯性更好，因為它允許訊息沿著不同的路徑傳播，避免單點故障。
​ 另一方面，全部到全部的拓撲也可能有問題。特別是，一些網路連結可能比其他網路連結更快（例如，由於網路擁塞），結果是一些複製訊息可能“超過”其他複製訊息，如[圖5-9](../img/fig5-9.png)所示。
![](../img/fig5-9.png)
**圖5-9 使用多主程式複製時，可能會在某些副本中寫入錯誤的順序。**
​ 在[圖5-9](../img/fig5-9.png)中，客戶端A向主庫1的表中插入一行，客戶端B在主庫3上更新該行。然而，主庫2可以以不同的順序接收寫入：它可以首先接收更新（其中，從它的角度來看，是對資料庫中不存在的行的更新），並且僅在稍後接收到相應的插入（其應該在更新之前）。
​ 這是一個因果關係的問題，類似於我們在“[一致字首讀](ch8.md#一致字首讀)”中看到的：更新取決於先前的插入，所以我們需要確保所有節點先處理插入，然後再處理更新。僅僅在每一次寫入時新增一個時間戳是不夠的，因為時鐘不可能被充分地同步，以便在主庫2處正確地排序這些事件（見[第8章](ch8.md)）。
​ 要正確排序這些事件，可以使用一種稱為**版本向量（version vectors）**的技術，本章稍後將討論這種技術（參閱“[檢測併發寫入](#檢測併發寫入)”）。然而，衝突檢測技術在許多多領導者複製系統中執行得不好。例如，在撰寫本文時，PostgreSQL BDR不提供寫入的因果排序【27】，而Tungsten Replicator for MySQL甚至不嘗試檢測衝突【34】。
​ 如果您正在使用具有多領導者複製功能的系統，那麼應該瞭解這些問題，仔細閱讀文件，並徹底測試您的資料庫，以確保它確實提供了您認為具有的保證。
## 無主複製
​ 我們在本章到目前為止所討論的複製方法 ——單主複製、多主複製——都是這樣的想法：客戶端向一個主庫傳送寫請求，而資料庫系統負責將寫入複製到其他副本。主庫決定寫入的順序，而從庫按相同順序應用主庫的寫入。
​ 一些資料儲存系統採用不同的方法，放棄主庫的概念，並允許任何副本直接接受來自客戶端的寫入。最早的一些的複製資料系統是**無領導的（leaderless）**【1,44】，但是在關係資料庫主導的時代，這個想法幾乎已被忘卻。在亞馬遜將其用於其內部的Dynamo系統[^vi]之後，它再一次成為資料庫的一種時尚架構【37】。 Riak，Cassandra和Voldemort是由Dynamo啟發的無領導複製模型的開源資料儲存，所以這類資料庫也被稱為*Dynamo風格*。
[^vi]: Dynamo不適用於Amazon以外的使用者。 令人困惑的是，AWS提供了一個名為DynamoDB的託管資料庫產品，它使用了完全不同的體系結構：它基於單載入程式複製。
​ 在一些無領導者的實現中，客戶端直接將寫入傳送到到幾個副本中，而另一些情況下，一個**協調者（coordinator）**節點代表客戶端進行寫入。但與主庫資料庫不同，協調者不執行特定的寫入順序。我們將會看到，這種設計上的差異對資料庫的使用方式有著深遠的影響。
### 當節點故障時寫入資料庫
​ 假設你有一個帶有三個副本的資料庫，而其中一個副本目前不可用，或許正在重新啟動以安裝系統更新。在基於主機的配置中，如果要繼續處理寫入，則可能需要執行故障切換（參閱「[處理節點宕機](#處理節點宕機)」）。
​ 另一方面，在無領導配置中，故障切換不存在。[圖5-10](../img/fig5-10.png)顯示了發生了什麼事情：客戶端（使用者1234）並行傳送寫入到所有三個副本，並且兩個可用副本接受寫入，但是不可用副本錯過了它。假設三個副本中的兩個承認寫入是足夠的：在使用者1234已經收到兩個確定的響應之後，我們認為寫入成功。客戶簡單地忽略了其中一個副本錯過了寫入的事實。
![](../img/fig5-10.png)
**圖5-10 法定寫入，法定讀取，並在節點中斷後讀修復。**
​ 現在想象一下，不可用的節點重新聯機，客戶端開始讀取它。節點關閉時發生的任何寫入都從該節點丟失。因此，如果您從該節點讀取資料，則可能會將陳舊（過時）值視為響應。
​ 為了解決這個問題，當一個客戶端從資料庫中讀取資料時，它不僅僅傳送它的請求到一個副本：讀請求也被並行地傳送到多個節點。客戶可能會從不同的節點獲得不同的響應。即來自一個節點的最新值和來自另一個節點的陳舊值。版本號用於確定哪個值更新（參閱“[檢測併發寫入](#檢測併發寫入)”）。
#### 讀修復和反熵
​ 複製方案應確保最終將所有資料複製到每個副本。在一個不可用的節點重新聯機之後，它如何趕上它錯過的寫入？
​ 在Dynamo風格的資料儲存中經常使用兩種機制：
***讀修復（Read repair）***
​ 當客戶端並行讀取多個節點時，它可以檢測到任何陳舊的響應。例如，在[圖5-10](../img/fig5-10.png)中，使用者2345獲得了來自副本3的版本6值和來自副本1和2的版本7值。客戶端發現副本3具有陳舊值，並將新值寫回到該副本。這種方法適用於讀頻繁的值。
***反熵過程（Anti-entropy process）***
​ 此外，一些資料儲存具有後臺程序，該程序不斷查詢副本之間的資料差異，並將任何缺少的資料從一個副本複製到另一個副本。與基於領導者的複製中的複製日誌不同，此反熵過程不會以任何特定的順序複製寫入，並且在複製資料之前可能會有顯著的延遲。
​ 並不是所有的系統都實現了這兩個，例如，Voldemort目前沒有反熵過程。請注意，如果沒有反熵過程，某些副本中很少讀取的值可能會丟失，從而降低了永續性，因為只有在應用程式讀取值時才執行讀修復。
#### 讀寫的法定人數
​ 在[圖5-10](../img/fig5-10.png)的示例中，我們認為即使僅在三個副本中的兩個上進行處理，寫入仍然是成功的。如果三個副本中只有一個接受了寫入，會怎樣？我們能推多遠呢？
​ 如果我們知道，每個成功的寫操作意味著在三個副本中至少有兩個出現，這意味著至多有一個副本可能是陳舊的。因此，如果我們從至少兩個副本讀取，我們可以確定至少有一個是最新的。如果第三個副本停機或響應速度緩慢，則讀取仍可以繼續返回最新值。
​ 更一般地說，如果有n個副本，每個寫入必須由w節點確認才能被認為是成功的，並且我們必須至少為每個讀取查詢r個節點。 （在我們的例子中，$n = 3，w = 2，r = 2$）。只要$w + r> n$，我們期望在讀取時獲得最新的值，因為r個讀取中至少有一個節點是最新的。遵循這些r值，w值的讀寫稱為**法定人數（quorum）**[^vii]的讀和寫【44】。你可以認為，r和w是有效讀寫所需的最低票數。
[^vii]: 有時候這種法定人數被稱為嚴格的法定人數，相對“寬鬆的法定人數”而言（見“[寬鬆的法定人數與提示移交](#寬鬆的法定人數與提示移交)”）
​ 在Dynamo風格的資料庫中，引數n，w和r通常是可配置的。一個常見的選擇是使n為奇數（通常為3或5）並設定 $w = r =（n + 1）/ 2$（向上取整）。但是可以根據需要更改數字。例如，設定$w = n$和$r = 1$的寫入很少且讀取次數較多的工作負載可能會受益。這使得讀取速度更快，但具有隻有一個失敗節點導致所有資料庫寫入失敗的缺點。
> 叢集中可能有多於n的節點。（叢集的機器數可能多於副本數目），但是任何給定的值只能儲存在n個節點上。 這允許對資料集進行分割槽，從而支援可以放在一個節點上的資料集更大的資料集。 將在第6章回到分割槽。
>
法定人數條件$w + r> n$允許系統容忍不可用的節點，如下所示：
* 如果$w <n$，如果節點不可用，我們仍然可以處理寫入。
* 如果$r <n$，如果節點不可用，我們仍然可以處理讀取。
* 對於$n = 3，w = 2，r = 2$，我們可以容忍一個不可用的節點。
* 對於$n = 5，w = 3，r = 3$，我們可以容忍兩個不可用的節點。 這個案例如[圖5-11](../img/fig5-11.png)所示。
* 通常，讀取和寫入操作始終並行傳送到所有n個副本。 引數w和r決定我們等待多少個節點，即在我們認為讀或寫成功之前，有多少個節點需要報告成功。
![](../img/fig5-11.png)
**圖5-11 如果$w + r > n$，讀取r個副本，至少有一個r副本必然包含了最近的成功寫入**
​ 如果少於所需的w或r節點可用，則寫入或讀取將返回錯誤。 由於許多原因，節點可能不可用：因為由於執行操作的錯誤（由於磁碟已滿而無法寫入）導致節點關閉（崩潰，關閉電源），由於客戶端和伺服器之間的網路中斷 節點，或任何其他原因。 我們只關心節點是否返回了成功的響應，而不需要區分不同型別的錯誤。
### 法定人數一致性的侷限性
​ 如果你有n個副本，並且你選擇w和r，使得$w + r> n$，你通常可以期望每個讀取返回為一個鍵寫的最近的值。情況就是這樣，因為你寫的節點集合和你讀過的節點集合必須重疊。也就是說，您讀取的節點中必須至少有一個具有最新值的節點（如[圖5-11](../img/fig5-11.png)所示）。
​ 通常，r和w被選為多數（超過 $n/2$ ）節點，因為這確保了$w + r> n$，同時仍然容忍多達$n/2$個節點故障。但是，法定人數不一定必須是大多數，只是讀寫使用的節點交集至少需要包括一個節點。其他法定人數的配置是可能的，這使得分散式演算法的設計有一定的靈活性【45】。
​ 您也可以將w和r設定為較小的數字，以使$w + r≤n$（即法定條件不滿足）。在這種情況下，讀取和寫入操作仍將被髮送到n個節點，但操作成功只需要少量的成功響應。
​ 較小的w和r更有可能會讀取過時的資料，因為您的讀取更有可能不包含具有最新值的節點。另一方面，這種配置允許更低的延遲和更高的可用性：如果存在網路中斷，並且許多副本變得無法訪問，則可以繼續處理讀取和寫入的機會更大。只有當可達副本的數量低於w或r時，資料庫才分別變得不可用於寫入或讀取。
但是，即使在$w + r> n$的情況下，也可能存在返回陳舊值的邊緣情況。這取決於實現，但可能的情況包括：
* 如果使用寬鬆的法定人數（見“[寬鬆的法定人數與提示移交](#寬鬆的法定人數與提示移交)”），w個寫入和r個讀取落在完全不同的節點上，因此r節點和w之間不再保證有重疊節點【46】。
* 如果兩個寫入同時發生，不清楚哪一個先發生。在這種情況下，唯一安全的解決方案是合併併發寫入（請參閱第171頁的“處理寫入衝突”）。如果根據時間戳（最後寫入勝利）挑選出一個勝者，則由於時鐘偏差[35]，寫入可能會丟失。我們將返回“[檢測併發寫入](#檢測併發寫入)”中的此主題。
* 如果寫操作與讀操作同時發生，寫操作可能僅反映在某些副本上。在這種情況下，不確定讀取是返回舊值還是新值。
* 如果寫操作在某些副本上成功，而在其他節點上失敗（例如，因為某些節點上的磁碟已滿），在小於w個副本上寫入成功。所以整體判定寫入失敗，但整體寫入失敗並沒有在寫入成功的副本上回滾。這意味著如果一個寫入雖然報告失敗，後續的讀取仍然可能會讀取這次失敗寫入的值【47】。
* 如果攜帶新值的節點失敗，需要讀取其他帶有舊值的副本。並且其資料從帶有舊值的副本中恢復，則儲存新值的副本數可能會低於w，從而打破法定人數條件。
* 即使一切工作正常，有時也會不幸地出現關於**時序（timing）**的邊緣情況，我們將在第334頁上的“[線性化和法定人數](ch9.md#線性化和法定人數)”中看到這點。
因此，儘管法定人數似乎保證讀取返回最新的寫入值，但在實踐中並不那麼簡單。 Dynamo風格的資料庫通常針對可以忍受最終一致性的用例進行最佳化。允許透過引數w和r來調整讀取陳舊值的概率，但把它們當成絕對的保證是不明智的。
​ 尤其是，通常沒有得到“[與延遲有關的問題](#)”（讀取您的寫入，單調讀取或一致的字首讀取）中討論的保證，因此前面提到的異常可能會發生在應用程式中。更強有力的保證通常需要**事務**或**共識**。我們將在[第七章](ch7.md)和[第九章](ch9.md)回到這些話題。
#### 監控陳舊度
​ 從運維的角度來看，監視你的資料庫是否返回最新的結果是很重要的。即使應用可以容忍陳舊的讀取，您也需要了解複製的健康狀況。如果顯著落後，應該提醒您，以便您可以調查原因（例如，網路中的問題或超載節點）。
​ 對於基於領導者的複製，資料庫通常會公開復制滯後的度量標準，您可以將其提供給監視系統。這是可能的，因為寫入按照相同的順序應用於領導者和追隨者，並且每個節點在複製日誌中具有一個位置（在本地應用的寫入次數）。透過從領導者的當前位置中減去隨從者的當前位置，您可以測量複製滯後量。
​ 然而，在無領導者複製的系統中，沒有固定的寫入順序，這使得監控變得更加困難。而且，如果資料庫只使用讀修復（沒有反熵過程），那麼對於一個值可能會有多大的限制是沒有限制的 - 如果一個值很少被讀取，那麼由一個陳舊副本返回的值可能是古老的。
​ 已經有一些關於衡量無主複製資料庫中的複製陳舊度的研究，並根據引數n，w和r來預測陳舊讀取的預期百分比【48】。不幸的是，這還不是很常見的做法，但是將過時測量值包含在資料庫的標準度量標準中是一件好事。最終的一致性是故意模糊的保證，但是對於可操作性來說，能夠量化“最終”是很重要的。
### 寬鬆的法定人數與提示移交
​ 合理配置的法定人數可以使資料庫無需故障切換即可容忍個別節點的故障。也可以容忍個別節點變慢，因為請求不必等待所有n個節點響應——當w或r節點響應時它們可以返回。對於需要高可用、低延時、且能夠容忍偶爾讀到陳舊值的應用場景來說，這些特性使無主複製的資料庫很有吸引力。
​ 然而，法定人數（如迄今為止所描述的）並不像它們可能的那樣具有容錯性。網路中斷可以很容易地將客戶端從大量的資料庫節點上切斷。雖然這些節點是活著的，而其他客戶端可能能夠連線到它們，但是從資料庫節點切斷的客戶端，它們也可能已經死亡。在這種情況下，剩餘的可用節點可能會少於可用節點，因此客戶端可能無法達到法定人數。
​ 在一個大型的群集中（節點數量明顯多於n個），網路中斷期間客戶端可能連線到某些資料庫節點，而不是為了為特定值組成法定人數的節點們。在這種情況下，資料庫設計人員需要權衡一下：
* 將錯誤返回給我們無法達到w或r節點的法定數量的所有請求是否更好？
* 或者我們是否應該接受寫入，然後將它們寫入一些可達的節點，但不在n值通常存在的n個節點之間？
後者被認為是一個**寬鬆的法定人數（sloppy quorum）**【37】：寫和讀仍然需要w和r成功的響應，但是那些可能包括不在指定的n個“主”節點中的值。比方說，如果你把自己鎖在房子外面，你可能會敲開鄰居的門，問你是否可以暫時停留在沙發上。
​ 一旦網路中斷得到解決，代表另一個節點臨時接受的一個節點的任何寫入都被髮送到適當的“本地”節點。這就是所謂的**提示移交（hinted handoff）**。 （一旦你再次找到你的房子的鑰匙，你的鄰居禮貌地要求你離開沙發回家。）
​ 寬鬆的法定人數對寫入可用性的提高特別有用：只要有任何w節點可用，資料庫就可以接受寫入。然而，這意味著即使當$w + r> n$時，也不能確定讀取某個鍵的最新值，因為最新的值可能已經臨時寫入了n之外的某些節點【47】。
​ 因此，在傳統意義上，一個寬鬆的法定人數實際上不是一個法定人數。這只是一個保證，即資料儲存在w節點的地方。不能保證r節點的讀取直到提示已經完成。
​ 在所有常見的Dynamo實現中，寬鬆的法定人數是可選的。在Riak中，它們預設是啟用的，而在Cassandra和Voldemort中它們預設是禁用的【46,49,50】。
#### 運維多個數據中心
​ 我們先前討論了跨資料中心複製作為多主複製的用例（參閱“[多主複製](#多主複製)”）。無主複製還適用於多資料中心操作，因為它旨在容忍衝突的併發寫入，網路中斷和延遲尖峰。
​ Cassandra和Voldemort在正常的無主模型中實現了他們的多資料中心支援：副本的數量n包括所有資料中心的節點，在配置中，您可以指定每個資料中心中您想擁有的副本的數量。無論資料中心如何，每個來自客戶端的寫入都會發送到所有副本，但客戶端通常只等待來自其本地資料中心內的法定節點的確認，從而不會受到跨資料中心鏈路延遲和中斷的影響。對其他資料中心的高延遲寫入通常被配置為非同步發生，儘管配置有一定的靈活性【50,51】。
​ Riak將客戶端和資料庫節點之間的所有通訊保持在一個數據中心本地，因此n描述了一個數據中心內的副本數量。資料庫叢集之間的跨資料中心複製在後臺非同步發生，其風格類似於多領導者複製【52】。
### 檢測併發寫入
​ Dynamo風格的資料庫允許多個客戶端同時寫入相同的Key，這意味著即使使用嚴格的法定人數也會發生衝突。這種情況與多領導者複製相似（參閱“[處理寫入衝突](#處理寫入衝突)”），但在Dynamo樣式的資料庫中，在**讀修復**或**提示移交**期間也可能會產生衝突。
​ 問題在於，由於可變的網路延遲和部分故障，事件可能在不同的節點以不同的順序到達。例如，[圖5-12](../img/fig5-12.png)顯示了兩個客戶機A和B同時寫入三節點資料儲存區中的鍵X：
* 節點 1 接收來自 A 的寫入，但由於暫時中斷，從不接收來自 B 的寫入。
* 節點 2 首先接收來自 A 的寫入，然後接收來自 B 的寫入。
* 節點 3 首先接收來自 B 的寫入，然後從 A 寫入。
![](../img/fig5-12.png)
**圖5-12 併發寫入Dynamo風格的資料儲存：沒有明確定義的順序。**
​ 如果每個節點只要接收到來自客戶端的寫入請求就簡單地覆蓋了某個鍵的值，那麼節點就會永久地不一致，如[圖5-12](../img/fig5-12.png)中的最終獲取請求所示：節點2認為 X 的最終值是 B，而其他節點認為值是 A 。
​ 為了最終達成一致，副本應該趨於相同的值。如何做到這一點？有人可能希望複製的資料庫能夠自動處理，但不幸的是，大多數的實現都很糟糕：如果你想避免丟失資料，你（應用程式開發人員）需要知道很多有關資料庫衝突處理的內部資訊。
​ 在“[處理寫衝突](#處理寫入衝突)”一節中已經簡要介紹了一些解決衝突的技術。在總結本章之前，讓我們來更詳細地探討這個問題。
#### 最後寫入勝利（丟棄併發寫入）
​ 實現最終融合的一種方法是宣告每個副本只需要儲存最**“最近”**的值，並允許**“更舊”**的值被覆蓋和拋棄。然後，只要我們有一種明確的方式來確定哪個寫是“最近的”，並且每個寫入最終都被複制到每個副本，那麼複製最終會收斂到相同的值。
​ 正如**“最近”**的引號所表明的，這個想法其實頗具誤導性。在[圖5-12](../img/fig5-12.png)的例子中，當客戶端向資料庫節點發送寫入請求時，客戶端都不知道另一個客戶端，因此不清楚哪一個先發生了。事實上，說“發生”是沒有意義的：我們說寫入是**併發（concurrent）**的，所以它們的順序是不確定的。
​ 即使寫入沒有自然的排序，我們也可以強制任意排序。例如，可以為每個寫入附加一個時間戳，挑選最**“最近”**的最大時間戳，並丟棄具有較早時間戳的任何寫入。這種衝突解決演算法被稱為**最後寫入勝利（LWW, last write wins）**，是Cassandra 【53】唯一支援的衝突解決方法，也是Riak 【35】中的一個可選特徵。
​ LWW實現了最終收斂的目標，但以**永續性**為代價：如果同一個Key有多個併發寫入，即使它們都被報告為客戶端成功（因為它們被寫入 w 個副本），但只有一個寫入將存活，而其他寫入將被靜默丟棄。此外，LWW甚至可能會刪除不是併發的寫入，我們將在的“[有序事件的時間戳](ch8.md#有序事件的時間戳)”中討論。
​ 有一些情況，如快取，其中丟失的寫入可能是可以接受的。如果丟失資料不可接受，LWW是解決衝突的一個很爛的選擇。
​ 與LWW一起使用資料庫的唯一安全方法是確保一個鍵只寫入一次，然後視為不可變，從而避免對同一個金鑰進行併發更新。例如，Cassandra推薦使用的方法是使用UUID作為鍵，從而為每個寫操作提供一個唯一的鍵【53】。
#### “此前發生”的關係和併發
我們如何判斷兩個操作是否是併發的？為了建立一個直覺，讓我們看看一些例子：
* 在[圖5-9](fig5-9.png)中，兩個寫入不是併發的：A的插入發生在B的增量之前，因為B遞增的值是A插入的值。換句話說，B的操作建立在A的操作上，所以B的操作必須有後來發生。我們也可以說B是**因果依賴（causally dependent）**於A
* 另一方面，[圖5-12](fig5-12.png)中的兩個寫入是併發的：當每個客戶端啟動操作時，它不知道另一個客戶端也正在執行操作同樣的Key。因此，操作之間不存在因果關係。
如果操作B瞭解操作A，或者依賴於A，或者以某種方式構建於操作A之上，則操作A在另一個操作B之前發生。在另一個操作之前是否發生一個操作是定義什麼併發的關鍵。事實上，我們可以簡單地說，如果兩個操作都不在另一個之前發生，那麼兩個操作是併發的（即，兩個操作都不知道另一個）【54】。
​ 因此，只要有兩個操作A和B，就有三種可能性：A在B之前發生，或者B在A之前發生，或者A和B併發。我們需要的是一個演算法來告訴我們兩個操作是否是併發的。如果一個操作發生在另一個操作之前，則後面的操作應該覆蓋較早的操作，但是如果這些操作是併發的，則存在需要解決的衝突。
> #### 併發性，時間和相對性
>
> ​ 如果兩個操作**“同時”**發生，似乎應該稱為併發——但事實上，它們在字面時間上重疊與否並不重要。由於分散式系統中的時鐘問題，現實中是很難判斷兩個事件是否**同時**發生的，這個問題我們將在[第8章](ch8.md)中詳細討論。
>
> ​ 為了定義併發性，確切的時間並不重要：如果兩個操作都意識不到對方的存在，就稱這兩個操作**併發**，而不管它們發生的物理時間。人們有時把這個原理和狹義相對論的物理學聯絡起來【54】，它引入了資訊不能比光速更快的思想。因此，如果事件之間的時間短於光透過它們之間的距離，那麼發生一定距離的兩個事件不可能相互影響。
>
> ​ 在計算機系統中，即使光速原則上允許一個操作影響另一個操作，但兩個操作也可能是**並行的**。例如，如果網路緩慢或中斷，兩個操作間可能會出現一段時間間隔，且仍然是併發的，因為網路問題阻止一個操作意識到另一個操作的存在。
#### 捕獲"此前發生"關係
​ 來看一個演算法，它確定兩個操作是否為併發的，還是一個在另一個之前。為了簡單起見，我們從一個只有一個副本的資料庫開始。一旦我們已經制定了如何在單個副本上完成這項工作，我們可以將該方法概括為具有多個副本的無領導者資料庫。
[圖5-13]()顯示了兩個客戶端同時向同一購物車新增專案。 （如果這樣的例子讓你覺得太麻煩了，那麼可以想象，兩個空中交通管制員同時把飛機新增到他們正在跟蹤的區域）最初，購物車是空的。在它們之間，客戶端向資料庫發出五次寫入：
1. 客戶端 1 將牛奶加入購物車。這是該鍵的第一次寫入，伺服器成功儲存了它併為其分配版本號1，最後將值與版本號一起回送給客戶端。
2. 客戶端 2 將雞蛋加入購物車，不知道客戶端 1 同時添加了牛奶（客戶端 2 認為它的雞蛋是購物車中的唯一物品）。伺服器為此寫入分配版本號 2，並將雞蛋和牛奶儲存為兩個單獨的值。然後它將這兩個值**都**反回給客戶端 2 ，並附上版本號 2 。
3. 客戶端 1 不知道客戶端 2 的寫入，想要將麵粉加入購物車，因此認為當前的購物車內容應該是 [牛奶，麵粉]。它將此值與伺服器先前向客戶端 1 提供的版本號 1 一起傳送到伺服器。伺服器可以從版本號中知道[牛奶，麵粉]的寫入取代了[牛奶]的先前值，但與[雞蛋]的值是**併發**的。因此，伺服器將版本 3 分配給[牛奶，麵粉]，覆蓋版本1值[牛奶]，但保留版本 2 的值[蛋]，並將所有的值返回給客戶端 1 。
4. 同時，客戶端 2 想要加入火腿，不知道客端戶 1 剛剛加了麵粉。客戶端 2 在最後一個響應中從伺服器收到了兩個值[牛奶]和[蛋]，所以客戶端 2 現在合併這些值，並新增火腿形成一個新的值，[雞蛋，牛奶，火腿]。它將這個值傳送到伺服器，帶著之前的版本號 2 。伺服器檢測到新值會覆蓋版本 2 [雞蛋]，但新值也會與版本 3 [牛奶，麵粉]**併發**，所以剩下的兩個是v3 [牛奶，麵粉]，和v4：[雞蛋，牛奶，火腿]
5. 最後，客戶端 1 想要加培根。它以前在v3中從伺服器接收[牛奶，麵粉]和[雞蛋]，所以它合併這些，新增培根，並將最終值[牛奶，麵粉，雞蛋，培根]連同版本號v3發往伺服器。這會覆蓋v3[牛奶，麵粉]（請注意[雞蛋]已經在最後一步被覆蓋），但與v4[雞蛋，牛奶，火腿]併發，所以伺服器保留這兩個併發值。
![](../img/fig5-13.png)
**圖5-13 捕獲兩個客戶端之間的因果關係，同時編輯購物車。**
​ [圖5-13](../img/fig5-13.png)中的操作之間的資料流如[圖5-14](../img/fig5-14.png)所示。 箭頭表示哪個操作發生在其他操作之前，意味著後面的操作知道或依賴於較早的操作。 在這個例子中，客戶端永遠不會完全掌握伺服器上的資料，因為總是有另一個操作同時進行。 但是，舊版本的值最終會被覆蓋，並且不會丟失任何寫入。
![](../img/fig5-14.png)
**圖5-14 圖5-13中的因果依賴關係圖。**
​ 請注意，伺服器可以透過檢視版本號來確定兩個操作是否是併發的——它不需要解釋該值本身（因此該值可以是任何資料結構）。該演算法的工作原理如下：
* 伺服器為每個鍵保留一個版本號，每次寫入鍵時都增加版本號，並將新版本號與寫入的值一起儲存。
* 當客戶端讀取鍵時，伺服器將返回所有未覆蓋的值以及最新的版本號。客戶端在寫入前必須讀取。
* 客戶端寫入鍵時，必須包含之前讀取的版本號，並且必須將之前讀取的所有值合併在一起。 （來自寫入請求的響應可以像讀取一樣，返回所有當前值，這使得我們可以像購物車示例那樣連線多個寫入。）
* 當伺服器接收到具有特定版本號的寫入時，它可以覆蓋該版本號或更低版本的所有值（因為它知道它們已經被合併到新的值中），但是它必須保持所有值更高版本號（因為這些值與傳入的寫入同時發生）。
當一個寫入包含前一次讀取的版本號時，它會告訴我們寫入的是哪一種狀態。如果在不包含版本號的情況下進行寫操作，則與所有其他寫操作併發，因此它不會覆蓋任何內容 —— 只會在隨後的讀取中作為其中一個值返回。
#### 合併同時寫入的值
​ 這種演算法可以確保沒有資料被無聲地丟棄，但不幸的是，客戶端需要做一些額外的工作：如果多個操作併發發生，則客戶端必須透過合併併發寫入的值來擦屁股。 Riak稱這些併發值**兄弟（siblings）**。
​ 合併兄弟值，本質上是與多領導者複製中的衝突解決相同的問題，我們先前討論過（參閱“[處理寫入衝突](#處理寫入衝突)”）。一個簡單的方法是根據版本號或時間戳（最後寫入勝利）選擇一個值，但這意味著丟失資料。所以，你可能需要在應用程式程式碼中做更聰明的事情。
​ 以購物車為例，一種合理的合併兄弟方法就是集合求並。在[圖5-14](../img/fig5-14.png)中，最後的兩個兄弟是[牛奶，麵粉，雞蛋，燻肉]和[雞蛋，牛奶，火腿]。注意牛奶和雞蛋出現在兩個，即使他們每個只寫一次。合併的價值可能是像[牛奶，麵粉，雞蛋，培根，火腿]，沒有重複。
​ 然而，如果你想讓人們也可以從他們的手推車中**刪除**東西，而不是僅僅新增東西，那麼把兄弟求並可能不會產生正確的結果：如果你合併了兩個兄弟手推車，並且只在其中一個兄弟值裡刪掉了它，那麼被刪除的專案會重新出現在兄弟的並集中【37】。為了防止這個問題，一個專案在刪除時不能簡單地從資料庫中刪除;相反，系統必須留下一個具有合適版本號的標記，以指示合併兄弟時該專案已被刪除。這種刪除標記被稱為**墓碑（tombstone）**。 （我們之前在“[雜湊索引”](ch3.md#雜湊索引)中的日誌壓縮的上下文中看到了墓碑。）
​ 因為在應用程式程式碼中合併兄弟是複雜且容易出錯的，所以有一些資料結構被設計出來用於自動執行這種合併，如“[自動衝突解決]()”中討論的。例如，Riak的資料型別支援使用稱為CRDT的資料結構家族【38,39,55】可以以合理的方式自動合併兄弟，包括保留刪除。
#### 版本向量
​ [圖5-13](../img/fig5-13.png)中的示例只使用一個副本。當有多個副本但沒有領導者時，演算法如何修改？
​ [圖5-13](../img/fig5-13.png)使用單個版本號來捕獲操作之間的依賴關係，但是當多個副本併發接受寫入時，這是不夠的。相反，除了對每個鍵使用版本號之外，還需要在**每個副本**中使用版本號。每個副本在處理寫入時增加自己的版本號，並且跟蹤從其他副本中看到的版本號。這個資訊指出了要覆蓋哪些值，以及保留哪些值作為兄弟。
​ 所有副本的版本號集合稱為**版本向量（version vector）**【56】。這個想法的一些變體正在使用，但最有趣的可能是在Riak 2.0 【58,59】中使用的**分散版本向量（dotted version vector）**【57】。我們不會深入細節，但是它的工作方式與我們在購物車示例中看到的非常相似。
​ 與[圖5-13](../img/fig5-13.png)中的版本號一樣，當讀取值時，版本向量會從資料庫副本傳送到客戶端，並且隨後寫入值時需要將其傳送回資料庫。 （Riak將版本向量編碼為一個字串，它稱為**因果上下文（causal context）**）。版本向量允許資料庫區分覆蓋寫入和併發寫入。
​ 另外，就像在單個副本的例子中，應用程式可能需要合併兄弟。版本向量結構確保從一個副本讀取並隨後寫回到另一個副本是安全的。這樣做可能會建立兄弟，但只要兄弟姐妹合併正確，就不會丟失資料。
> #### 版本向量和向量時鐘
>
> ​ 版本向量有時也被稱為向量時鐘，即使它們不完全相同。 差別很微妙——請參閱參考資料的細節【57,60,61】。 簡而言之，在比較副本的狀態時，版本向量是正確的資料結構。
>
## 本章小結
在本章中，我們考察了複製的問題。複製可以用於幾個目的：
***高可用性***
​ 即使在一臺機器（或多臺機器，或整個資料中心）停機的情況下也能保持系統正常執行
***斷開連線的操作***
​ 允許應用程式在網路中斷時繼續工作
***延遲***
​ 將資料放置在距離使用者較近的地方，以便使用者能夠更快地與其互動
***可擴充套件性***
​ 能夠處理比單個機器更高的讀取量可以透過對副本進行讀取來處理
​ 儘管是一個簡單的目標 - 在幾臺機器上保留相同資料的副本，但複製卻是一個非常棘手的問題。它需要仔細考慮併發和所有可能出錯的事情，並處理這些故障的後果。至少，我們需要處理不可用的節點和網路中斷（甚至不考慮更隱蔽的故障，例如由於軟體錯誤導致的無提示資料損壞）。
​ 我們討論了複製的三種主要方法：
***單主複製***
​ 客戶端將所有寫入操作傳送到單個節點（領導者），該節點將資料更改事件流傳送到其他副本（追隨者）。讀取可以在任何副本上執行，但從追隨者讀取可能是陳舊的。
***多主複製***
​ 客戶端傳送每個寫入到幾個領導節點之一，其中任何一個都可以接受寫入。領導者將資料更改事件流傳送給彼此以及任何跟隨者節點。
***無主複製***
​ 客戶端傳送每個寫入到幾個節點，並從多個節點並行讀取，以檢測和糾正具有陳舊資料的節點。
每種方法都有優點和缺點。單主複製是非常流行的，因為它很容易理解，不需要擔心衝突解決。在出現故障節點，網路中斷和延遲峰值的情況下，多領導者和無領導者複製可以更加穩健，但以更難以推理並僅提供非常弱的一致性保證為代價。
​ 複製可以是同步的，也可以是非同步的，在發生故障時對系統行為有深遠的影響。儘管在系統執行平穩時非同步複製速度很快，但是在複製滯後增加和伺服器故障時要弄清楚會發生什麼，這一點很重要。如果一個領導者失敗了，並且你推動一個非同步更新的追隨者成為新的領導者，那麼最近承諾的資料可能會丟失。
​ 我們研究了一些可能由複製滯後引起的奇怪效應，我們討論了一些有助於決定應用程式在複製滯後時的行為的一致性模型：
***寫後讀***
​ 使用者應該總是看到自己提交的資料。
***單調讀***
使用者在一個時間點看到資料後，他們不應該在某個早期時間點看到資料。
***一致字首讀***
​ 使用者應該將資料視為具有因果意義的狀態：例如，按照正確的順序檢視問題及其答覆。
​ 最後，我們討論了多領導者和無領導者複製方法所固有的併發問題：因為他們允許多個寫入併發發生衝突。我們研究了一個數據庫可能使用的演算法來確定一個操作是否發生在另一個操作之前，或者它們是否同時發生。我們還談到了透過合併併發更新來解決衝突的方法。
​ 在下一章中，我們將繼續研究分佈在多個機器上的資料，透過複製的對應方式：將大資料集分割成分割槽。
## 參考文獻
1. Bruce G. Lindsay, Patricia Griffiths Selinger, C. Galtieri, et al.:
“[Notes on Distributed Databases](http://domino.research.ibm.com/library/cyberdig.nsf/papers/A776EC17FC2FCE73852579F100578964/$File/RJ2571.pdf),” IBM Research, Research Report RJ2571(33471), July 1979.
1. “[Oracle Active Data Guard Real-Time Data Protection and Availability](http://www.oracle.com/technetwork/database/availability/active-data-guard-wp-12c-1896127.pdf),” Oracle White Paper, June 2013.
1. “[AlwaysOn Availability Groups](http://msdn.microsoft.com/en-us/library/hh510230.aspx),” in *SQL Server Books Online*, Microsoft, 2012.
1. Lin Qiao, Kapil Surlaker, Shirshanka Das, et al.: “[On Brewing Fresh Espresso: LinkedIn’s Distributed Data Serving Platform](http://www.slideshare.net/amywtang/espresso-20952131),” at *ACM International Conference on Management of Data* (SIGMOD), June 2013.
1. Jun Rao: “[Intra-Cluster Replication for Apache Kafka](http://www.slideshare.net/junrao/kafka-replication-apachecon2013),” at *ApacheCon North America*, February 2013.
1. “[Highly Available Queues](https://www.rabbitmq.com/ha.html),” in *RabbitMQ Server Documentation*, Pivotal Software, Inc., 2014.
1. Yoshinori Matsunobu: “[Semi-Synchronous Replication at Facebook](http://yoshinorimatsunobu.blogspot.co.uk/2014/04/semi-synchronous-replication-at-facebook.html),” *yoshinorimatsunobu.blogspot.co.uk*, April 1, 2014.
1. Robbert van Renesse and Fred B. Schneider: “[Chain Replication for Supporting High Throughput and Availability](http://static.usenix.org/legacy/events/osdi04/tech/full_papers/renesse/renesse.pdf),” at *6th USENIX Symposium on Operating System Design and Implementation* (OSDI), December 2004.
1. Jeff Terrace and Michael J. Freedman: “[Object Storage on CRAQ: High-Throughput Chain Replication for Read-Mostly Workloads](https://www.usenix.org/legacy/event/usenix09/tech/full_papers/terrace/terrace.pdf),” at *USENIX Annual Technical Conference* (ATC), June 2009.
1. Brad Calder, Ju Wang, Aaron Ogus, et al.: “[Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency](http://sigops.org/sosp/sosp11/current/2011-Cascais/printable/11-calder.pdf),” at *23rd ACM Symposium on Operating Systems Principles* (SOSP), October 2011.
1. Andrew Wang: “[Windows Azure Storage](http://umbrant.com/blog/2016/windows_azure_storage.html),” *umbrant.com*, February 4, 2016.
1. “[Percona Xtrabackup - Documentation](https://www.percona.com/doc/percona-xtrabackup/2.1/index.html),” Percona LLC, 2014.
1. Jesse Newland: “[GitHub Availability This Week](https://github.com/blog/1261-github-availability-this-week),” *github.com*, September 14, 2012.
1. Mark Imbriaco: “[Downtime Last Saturday](https://github.com/blog/1364-downtime-last-saturday),” *github.com*, December 26, 2012.
1. John Hugg: “[‘All in’ with Determinism for Performance and Testing in Distributed Systems](https://www.youtube.com/watch?v=gJRj3vJL4wE),” at *Strange Loop*, September 2015. Amit Kapila: “[WAL Internals of PostgreSQL](http://www.pgcon.org/2012/schedule/attachments/258_212_Internals%20Of%20PostgreSQL%20Wal.pdf),” at *PostgreSQL Conference* (PGCon), May 2012.
1. [*MySQL Internals Manual*](http://dev.mysql.com/doc/internals/en/index.html). Oracle, 2014.
1. Yogeshwer Sharma, Philippe Ajoux, Petchean Ang, et al.: “[Wormhole: Reliable Pub-Sub to Support Geo-Replicated Internet Services](https://www.usenix.org/system/files/conference/nsdi15/nsdi15-paper-sharma.pdf),” at *12th USENIX Symposium on Networked Systems Design and Implementation* (NSDI), May 2015.
1. “[Oracle GoldenGate 12c: Real-Time Access to Real-Time Information](http://www.oracle.com/us/products/middleware/data-integration/oracle-goldengate-realtime-access-2031152.pdf),” Oracle White Paper, October 2013.
1. Shirshanka Das, Chavdar Botev, Kapil Surlaker, et al.: “[All Aboard the Databus!](http://www.socc2012.org/s18-das.pdf),” at
*ACM Symposium on Cloud Computing* (SoCC), October 2012.
1. Greg Sabino Mullane: “[Version 5 of Bucardo Database Replication System](http://blog.endpoint.com/2014/06/bucardo-5-multimaster-postgres-released.html),” *blog.endpoint.com*, June 23, 2014.
1. Werner Vogels: “[Eventually Consistent](http://queue.acm.org/detail.cfm?id=1466448),” *ACM Queue*, volume 6, number 6, pages 14–19, October 2008.
[doi:10.1145/1466443.1466448](http://dx.doi.org/10.1145/1466443.1466448)
1. Douglas B. Terry: “[Replicated Data Consistency Explained Through Baseball](http://research.microsoft.com/pubs/157411/ConsistencyAndBaseballReport.pdf),” Microsoft Research, Technical Report MSR-TR-2011-137, October 2011.
1. Douglas B. Terry, Alan J. Demers, Karin Petersen, et al.: “[Session Guarantees for Weakly Consistent Replicated Data](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.71.2269&rep=rep1&type=pdf),” at *3rd International Conference on Parallel and Distributed Information Systems* (PDIS), September 1994. [doi:10.1109/PDIS.1994.331722](http://dx.doi.org/10.1109/PDIS.1994.331722)
1. Terry Pratchett: *Reaper Man: A Discworld Novel*. Victor Gollancz, 1991. ISBN: 978-0-575-04979-6
1. “[Tungsten Replicator](http://tungsten-replicator.org/),” Continuent, Inc., 2014.
1. “[BDR 0.10.0 Documentation](http://bdr-project.org/docs/next/index.html),” The PostgreSQL Global Development Group, *bdr-project.org*, 2015.
1. Robert Hodges:
“[If You *Must* Deploy Multi-Master Replication, Read This First](http://scale-out-blog.blogspot.co.uk/2012/04/if-you-must-deploy-multi-master.html),” *scale-out-blog.blogspot.co.uk*,
March 30, 2012.
1. J. Chris Anderson, Jan Lehnardt, and Noah Slater: *CouchDB: The Definitive Guide*. O'Reilly Media, 2010.
ISBN: 978-0-596-15589-6
1. AppJet, Inc.: “[Etherpad and EasySync Technical Manual](https://github.com/ether/etherpad-lite/blob/e2ce9dc/doc/easysync/easysync-full-description.pdf),” *github.com*, March 26, 2011.
1. John Day-Richter: “[What’s Different About the New Google Docs: Making Collaboration Fast](http://googledrive.blogspot.com/2010/09/whats-different-about-new-google-docs.html),” *googledrive.blogspot.com*, 23 September 2010.
1. Martin Kleppmann and Alastair R. Beresford: “[A Conflict-Free Replicated JSON Datatype](http://arxiv.org/abs/1608.03960),”
arXiv:1608.03960, August 13, 2016.
1. Frazer Clement: “[Eventual Consistency – Detecting Conflicts](http://messagepassing.blogspot.co.uk/2011/10/eventual-consistency-detecting.html),” *messagepassing.blogspot.co.uk*, October 20, 2011.
1. Robert Hodges: “[State of the Art for MySQL Multi-Master Replication](https://www.percona.com/live/mysql-conference-2013/sessions/state-art-mysql-multi-master-replication),” at *Percona Live: MySQL Conference & Expo*, April 2013.
1. John Daily: “[Clocks Are Bad, or, Welcome to the Wonderful World of Distributed Systems](http://basho.com/clocks-are-bad-or-welcome-to-distributed-systems/),” *basho.com*, November 12, 2013.
1. Riley Berton: “[Is Bi-Directional Replication (BDR) in Postgres Transactional?](http://sdf.org/~riley/blog/2016/01/04/is-bi-directional-replication-bdr-in-postgres-transactional/),” *sdf.org*, January 4, 2016.
1. Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, et al.: “[Dynamo: Amazon's Highly Available Key-Value Store](http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf),” at *21st ACM Symposium on Operating Systems Principles* (SOSP), October 2007.
1. Marc Shapiro, Nuno Preguiça, Carlos Baquero, and Marek Zawirski: “[A Comprehensive Study of Convergent and Commutative Replicated Data Types](http://hal.inria.fr/inria-00555588/),” INRIA Research Report no. 7506,
January 2011.
1. Sam Elliott: “[CRDTs: An UPDATE (or Maybe Just a PUT)](https://speakerdeck.com/lenary/crdts-an-update-or-just-a-put),” at *RICON West*, October 2013.
1. Russell Brown: “[A Bluffers Guide to CRDTs in Riak](https://gist.github.com/russelldb/f92f44bdfb619e089a4d),” *gist.github.com*, October 28, 2013.
1. Benjamin Farinier, Thomas Gazagnaire, and Anil Madhavapeddy: “[Mergeable Persistent Data Structures](http://gazagnaire.org/pub/FGM15.pdf),” at *26es Journées Francophones des Langages Applicatifs* (JFLA), January 2015.
1. Chengzheng Sun and Clarence Ellis: “[Operational Transformation in Real-Time Group Editors: Issues, Algorithms, and Achievements](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.53.933&rep=rep1&type=pdf),” at *ACM Conference on Computer Supported Cooperative Work* (CSCW), November 1998.
1. Lars Hofhansl: “[HBASE-7709: Infinite Loop Possible in Master/Master Replication](https://issues.apache.org/jira/browse/HBASE-7709),” *issues.apache.org*, January 29, 2013.
1. David K. Gifford: “[Weighted Voting for Replicated Data](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.84.7698),” at *7th ACM Symposium on Operating Systems Principles* (SOSP), December 1979. [doi:10.1145/800215.806583](http://dx.doi.org/10.1145/800215.806583)
1. Heidi Howard, Dahlia Malkhi, and Alexander Spiegelman: “[Flexible Paxos: Quorum Intersection Revisited](https://arxiv.org/abs/1608.06696),” *arXiv:1608.06696*, August 24, 2016.
1. Joseph Blomstedt: “[Re: Absolute Consistency](http://lists.basho.com/pipermail/riak-users_lists.basho.com/2012-January/007157.html),” email to *riak-users* mailing list, *lists.basho.com*,
January 11, 2012.
1. Joseph Blomstedt: “[Bringing Consistency to Riak](https://vimeo.com/51973001),” at *RICON West*, October 2012.
1. Peter Bailis, Shivaram Venkataraman, Michael J. Franklin, et al.: “[Quantifying Eventual Consistency with PBS](http://www.bailis.org/papers/pbs-cacm2014.pdf),” *Communications of the ACM*, volume 57, number 8, pages 93–102, August 2014. [doi:10.1145/2632792](http://dx.doi.org/10.1145/2632792)
1. Jonathan Ellis: “[Modern Hinted Handoff](http://www.datastax.com/dev/blog/modern-hinted-handoff),” *datastax.com*, December 11, 2012.
1. “[Project Voldemort Wiki](https://github.com/voldemort/voldemort/wiki),” *github.com*, 2013.
1. “[Apache Cassandra 2.0 Documentation](http://www.datastax.com/documentation/cassandra/2.0/index.html),” DataStax, Inc., 2014.
1. “[Riak Enterprise: Multi-Datacenter Replication](http://basho.com/assets/MultiDatacenter_Replication.pdf).” Technical whitepaper, Basho Technologies, Inc.,
September 2014.
1. Jonathan Ellis: “[Why Cassandra Doesn't Need Vector Clocks](http://www.datastax.com/dev/blog/why-cassandra-doesnt-need-vector-clocks),” *datastax.com*, September 2, 2013.
1. Leslie Lamport: “[Time, Clocks, and the Ordering of Events in a Distributed System](http://research.microsoft.com/en-US/um/people/Lamport/pubs/time-clocks.pdf),” *Communications of the ACM*, volume 21, number 7, pages 558–565, July 1978. [doi:10.1145/359545.359563](http://dx.doi.org/10.1145/359545.359563)
1. Joel Jacobson: “[Riak 2.0: Data Types](http://blog.joeljacobson.com/riak-2-0-data-types/),” *blog.joeljacobson.com*, March 23, 2014.
1. D. Stott Parker Jr., Gerald J. Popek, Gerard Rudisin, et al.: “[Detection of Mutual Inconsistency in Distributed Systems](http://zoo.cs.yale.edu/classes/cs426/2013/bib/parker83detection.pdf),” *IEEE Transactions on Software Engineering*, volume 9, number 3, pages 240–247, May 1983. [doi:10.1109/TSE.1983.236733](http://dx.doi.org/10.1109/TSE.1983.236733)
1. Nuno Preguiça, Carlos Baquero, Paulo Sérgio Almeida, et al.: “[Dotted Version Vectors: Logical Clocks for Optimistic Replication](http://arxiv.org/pdf/1011.5808v1.pdf),” arXiv:1011.5808, November 26, 2010.
1. Sean Cribbs: “[A Brief History of Time in Riak](https://www.youtube.com/watch?v=HHkKPdOi-ZU),” at *RICON*, October 2014.
1. Russell Brown: “[Vector Clocks Revisited Part 2: Dotted Version Vectors](http://basho.com/posts/technical/vector-clocks-revisited-part-2-dotted-version-vectors/),” *basho.com*, November 10, 2015.
1. Carlos Baquero: “[Version Vectors Are Not Vector Clocks](https://haslab.wordpress.com/2011/07/08/version-vectors-are-not-vector-clocks/),” *haslab.wordpress.com*, July 8, 2011.
1. Reinhard Schwarz and Friedemann Mattern: “[Detecting Causal Relationships in Distributed Computations: In Search of the Holy Grail](http://dcg.ethz.ch/lectures/hs08/seminar/papers/mattern4.pdf),” *Distributed Computing*, volume 7, number 3, pages 149–174, March 1994. [doi:10.1007/BF02277859](http://dx.doi.org/10.1007/BF02277859)
--------
| 上一章 | 目錄 | 下一章 |
| :--------------------------------: | :-----------------------------: | :--------------------: |
| [第二部分：分散式資料](part-ii.md) | [設計資料密集型應用](README.md) | [第六章：分割槽](ch6.md) |

410
zh-tw/ch6.md Normal file
View File

@ -0,0 +1,410 @@
# 6. 分割槽
![](../img/ch6.png)
> 我們必須跳出電腦指令序列的窠臼。 敘述定義、描述元資料、梳理關係，而不是編寫過程。
>
> —— Grace Murray Hopper，未來的計算機及其管理（1962）
>
-------------
[TOC]
​ 在[第5章](ch5.md)中，我們討論了複製——即資料在不同節點上的副本,對於非常大的資料集,或非常高的吞吐量，僅僅進行復制是不夠的：我們需要將資料進行**分割槽（partitions）**，也稱為**分片（sharding）**[^i]
[^i]: 正如本章所討論的，分割槽是一種有意將大型資料庫分解成小型資料庫的方式。它與**網路分割槽（net splits）**無關，這是節點之間網路中的一種故障型別。我們將在[第8章](ch8.md)討論這些錯誤。
> ##### 術語澄清
>
> ​ 上文中的**分割槽(partition)**,在MongoDB,Elasticsearch和Solr Cloud中被稱為**分片(shard)**,在HBase中稱之為**區域(Region)**，Bigtable中則是 **表塊（tablet）**，Cassandra和Riak中是**虛節點（vnode)**, Couchbase中叫做**虛桶(vBucket)**.但是**分割槽(partition)** 是約定俗成的叫法。
>
​ 通常情況下，每條資料（每條記錄，每行或每個文件）屬於且僅屬於一個分割槽。有很多方法可以實現這一點，本章將進行深入討論。實際上，每個分割槽都是自己的小型資料庫，儘管資料庫可能支援同時進行多個分割槽的操作。
​ 分割槽主要是為了**可擴充套件性**。不同的分割槽可以放在不共享叢集中的不同節點上（參閱[第二部分](part-ii.md)關於[無共享架構](part-ii.md#無共享架構)的定義）。因此，大資料集可以分佈在多個磁碟上，並且查詢負載可以分佈在多個處理器上。
​ 對於在單個分割槽上執行的查詢，每個節點可以獨立執行對自己的查詢，因此可以透過新增更多的節點來擴大查詢吞吐量。大型，複雜的查詢可能會跨越多個節點並行處理，儘管這也帶來了新的困難。
​ 分割槽資料庫在20世紀80年代由Teradata和NonStop SQL【1】等產品率先推出，最近因為NoSQL資料庫和基於Hadoop的資料倉庫重新被關注。有些系統是為事務性工作設計的，有些系統則用於分析（參閱“[事務處理或分析]”）：這種差異會影響系統的運作方式，但是分割槽的基本原理均適用於這兩種工作方式。
​ 在本章中，我們將首先介紹分割大型資料集的不同方法，並觀察索引如何與分割槽配合。然後我們將討論[重新平衡分割槽](#重新平衡分割槽)，如果想要新增或刪除群集中的節點，則必須進行再平衡。最後，我們將概述資料庫如何將請求路由到正確的分割槽並執行查詢。
## 分割槽與複製
​ 分割槽通常與複製結合使用，使得每個分割槽的副本儲存在多個節點上。 這意味著，即使每條記錄屬於一個分割槽，它仍然可以儲存在多個不同的節點上以獲得容錯能力。
​ 一個節點可能儲存多個分割槽。 如果使用主從複製模型，則分割槽和複製的組合如[圖6-1]()所示。 每個分割槽領導者(主)被分配給一個節點，追隨者(從)被分配給其他節點。 每個節點可能是某些分割槽的領導者，同時是其他分割槽的追隨者。
我們在[第5章](ch5.md)討論的關於資料庫複製的所有內容同樣適用於分割槽的複製。 大多數情況下，分割槽方案的選擇與複製方案的選擇是獨立的，為簡單起見，本章中將忽略複製。
![](../img/fig6-1.png)
**圖6-1 組合使用複製和分割槽：每個節點充當某些分割槽的領導者，其他分割槽充當追隨者。**
## 鍵值資料的分割槽
​ 假設你有大量資料並且想要分割槽,如何決定在哪些節點上儲存哪些記錄呢？
​ 分割槽目標是將資料和查詢負載均勻分佈在各個節點上。如果每個節點公平分享資料和負載，那麼理論上10個節點應該能夠處理10倍的資料量和10倍的單個節點的讀寫吞吐量（暫時忽略複製）。
​ 如果分割槽是不公平的，一些分割槽比其他分割槽有更多的資料或查詢，我們稱之為**偏斜（skew）**。資料偏斜的存在使分割槽效率下降很多。在極端的情況下，所有的負載可能壓在一個分割槽上，其餘9個節點空閒的，瓶頸落在這一個繁忙的節點上。不均衡導致的高負載的分割槽被稱為**熱點（hot spot）**。
​ 避免熱點最簡單的方法是將記錄隨機分配給節點。這將在所有節點上平均分配資料，但是它有一個很大的缺點：當你試圖讀取一個特定的值時，你無法知道它在哪個節點上，所以你必須並行地查詢所有的節點。
​ 我們可以做得更好。現在假設您有一個簡單的鍵值資料模型，其中您總是透過其主鍵訪問記錄。例如，在一本老式的紙質百科全書中，你可以透過標題來查詢一個條目;由於所有條目按字母順序排序，因此您可以快速找到您要查詢的條目。
### 根據鍵的範圍分割槽
​ 一種分割槽的方法是為每個分割槽指定一塊連續的鍵範圍（從最小值到最大值），如紙百科全書的卷（[圖6-2]()）。如果知道範圍之間的邊界，則可以輕鬆確定哪個分割槽包含某個值。如果您還知道分割槽所在的節點，那麼可以直接向相應的節點發出請求（對於百科全書而言，就像從書架上選取正確的書籍）。
![](../img/fig6-2.png)
**圖6-2 印刷版百科全書按照關鍵字範圍進行分割槽**
​ 鍵的範圍不一定均勻分佈，因為資料也很可能不均勻分佈。例如在[圖6-2]()中，第1捲包含以A和B開頭的單詞，但第12卷則包含以T，U，V，X，Y和Z開頭的單詞。只是簡單的規定每個捲包含兩個字母會導致一些卷比其他卷大。為了均勻分配資料，分割槽邊界需要依據資料調整。
​ 分割槽邊界可以由管理員手動選擇，也可以由資料庫自動選擇（我們會在“[重新平衡分割槽]()”中更詳細地討論分割槽邊界的選擇）。 Bigtable使用了這種分割槽策略，以及其開源等價物HBase 【2, 3】，RethinkDB和2.4版本之前的MongoDB 【4】。
​ 在每個分割槽中，我們可以按照一定的順序儲存鍵（參見“[SSTables和LSM-樹]()”）。好處是進行範圍掃描非常簡單，您可以將鍵作為聯合索引來處理，以便在一次查詢中獲取多個相關記錄（參閱“[多列索引](#ch2.md#多列索引)”）。例如，假設我們有一個程式來儲存感測器網路的資料，其中主鍵是測量的時間戳（年月日時分秒）。範圍掃描在這種情況下非常有用，因為我們可以輕鬆獲取某個月份的所有資料。
​ 然而，Key Range分割槽的缺點是某些特定的訪問模式會導致熱點。 如果主鍵是時間戳，則分割槽對應於時間範圍，例如，給每天分配一個分割槽。 不幸的是，由於我們在測量發生時將資料從感測器寫入資料庫，因此所有寫入操作都會轉到同一個分割槽（即今天的分割槽），這樣分割槽可能會因寫入而過載，而其他分割槽則處於空閒狀態【5】。
​ 為了避免感測器資料庫中的這個問題，需要使用除了時間戳以外的其他東西作為主鍵的第一個部分。 例如，可以在每個時間戳前新增感測器名稱，這樣會首先按感測器名稱，然後按時間進行分割槽。 假設有多個感測器同時執行，寫入負載將最終均勻分佈在不同分割槽上。 現在，當想要在一個時間範圍內獲取多個感測器的值時，您需要為每個感測器名稱執行一個單獨的範圍查詢。
### 根據鍵的雜湊分割槽
​ 由於偏斜和熱點的風險，許多分散式資料儲存使用雜湊函式來確定給定鍵的分割槽。
​ 一個好的雜湊函式可以將將偏斜的資料均勻分佈。假設你有一個32位雜湊函式,無論何時給定一個新的字串輸入，它將返回一個0到$2^{32}$ -1之間的"隨機"數。即使輸入的字串非常相似，它們的雜湊也會均勻分佈在這個數字範圍內。
​ 出於分割槽的目的，雜湊函式不需要多麼強壯的加密演算法：例如，Cassandra和MongoDB使用MD5，Voldemort使用Fowler-Noll-Vo函式。許多程式語言都有內建的簡單雜湊函式（它們用於雜湊表），但是它們可能不適合分割槽：例如，在Java的`Object.hashCode()`和Ruby的`Object#hash`，同一個鍵可能在不同的程序中有不同的雜湊值【6】。
​ 一旦你有一個合適的鍵雜湊函式，你可以為每個分割槽分配一個雜湊範圍（而不是鍵的範圍），每個透過雜湊雜湊落在分割槽範圍內的鍵將被儲存在該分割槽中。如[圖6-3](../img/fig6-3.png)所示。
![](../img/fig6-3.png)
**圖6-3 按雜湊鍵分割槽**
​ 這種技術擅長在分割槽之間分配鍵。分割槽邊界可以是均勻間隔的，也可以是偽隨機選擇的（在這種情況下，該技術有時也被稱為**一致性雜湊（consistent hashing）**）。
> #### 一致性雜湊
>
> ​ 一致性雜湊由Karger等人定義。【7】 用於跨網際網路級別的快取系統，例如CDN中，是一種能均勻分配負載的方法。它使用隨機選擇的**分割槽邊界（partition boundaries）**來避免中央控制或分散式一致性的需要。 請注意，這裡的一致性與複製一致性（請參閱第5章）或ACID一致性（參閱[第7章](ch7.md)）無關，而是描述了重新平衡的特定方法。
>
> ​ 正如我們將在“[重新平衡分割槽](#重新平衡分割槽)”中所看到的，這種特殊的方法對於資料庫實際上並不是很好，所以在實際中很少使用（某些資料庫的文件仍然指的是一致性雜湊，但是它 往往是不準確的）。 因為有可能產生混淆，所以最好避免使用一致性雜湊這個術語，而只是把它稱為**雜湊分割槽（hash partitioning）**。
​ 不幸的是，透過使用Key雜湊進行分割槽，我們失去了鍵範圍分割槽的一個很好的屬性：高效執行範圍查詢的能力。曾經相鄰的金鑰現在分散在所有分割槽中，所以它們之間的順序就丟失了。在MongoDB中，如果您使用了基於雜湊的分割槽模式，則任何範圍查詢都必須傳送到所有分割槽【4】。Riak 【9】，Couchbase 【10】或Voldemort不支援主鍵上的範圍查詢。
​ Cassandra採取了折衷的策略【11, 12, 13】。 Cassandra中的表可以使用由多個列組成的複合主鍵來宣告。鍵中只有第一列會作為雜湊的依據，而其他列則被用作Casssandra的SSTables中排序資料的連線索引。儘管查詢無法在複合主鍵的第一列中按範圍掃表，但如果第一列已經指定了固定值，則可以對該鍵的其他列執行有效的範圍掃描。
​ 組合索引方法為一對多關係提供了一個優雅的資料模型。例如，在社交媒體網站上，一個使用者可能會發布很多更新。如果更新的主鍵被選擇為`(user_id, update_timestamp)`，那麼您可以有效地檢索特定使用者在某個時間間隔內按時間戳排序的所有更新。不同的使用者可以儲存在不同的分割槽上，對於每個使用者，更新按時間戳順序儲存在單個分割槽上。
### 負載傾斜與消除熱點
​ 如前所述，雜湊分割槽可以幫助減少熱點。但是，它不能完全避免它們：在極端情況下，所有的讀寫操作都是針對同一個鍵的，所有的請求都會被路由到同一個分割槽。
​ 這種場景也許並不常見，但並非聞所未聞：例如，在社交媒體網站上，一個擁有數百萬追隨者的名人使用者在做某事時可能會引發一場風暴【14】。這個事件可能導致大量寫入同一個鍵（鍵可能是名人的使用者ID，或者人們正在評論的動作的ID）。雜湊策略不起作用，因為兩個相同ID的雜湊值仍然是相同的。
​ 如今，大多數資料系統無法自動補償這種高度偏斜的負載，因此應用程式有責任減少偏斜。例如，如果一個主鍵被認為是非常火爆的，一個簡單的方法是在主鍵的開始或結尾新增一個隨機數。只要一個兩位數的十進位制隨機數就可以將主鍵分散為100種不同的主鍵,從而儲存在不同的分割槽中。
​ 然而，將主鍵進行分割之後，任何讀取都必須要做額外的工作，因為他們必須從所有100個主鍵分佈中讀取資料並將其合併。此技術還需要額外的記錄：只需要對少量熱點附加隨機數;對於寫入吞吐量低的絕大多數主鍵來說是不必要的開銷。因此，您還需要一些方法來跟蹤哪些鍵需要被分割。
​ 也許在將來，資料系統將能夠自動檢測和補償偏斜的工作負載；但現在，您需要自己來權衡。
## 分片與次級索引
​ 到目前為止，我們討論的分割槽方案依賴於鍵值資料模型。如果只通過主鍵訪問記錄，我們可以從該鍵確定分割槽，並使用它來將讀寫請求路由到負責該鍵的分割槽。
​ 如果涉及次級索引，情況會變得更加複雜（參考“[其他索引結構]()”）。輔助索引通常並不能唯一地標識記錄，而是一種搜尋記錄中出現特定值的方式：查詢使用者123的所有操作，查詢包含詞語`hogwash`的所有文章，查詢所有顏色為紅色的車輛等等。
​ 次級索引是關係型資料庫的基礎，並且在文件資料庫中也很普遍。許多鍵值儲存（如HBase和Volde-mort）為了減少實現的複雜度而放棄了次級索引，但是一些（如Riak）已經開始新增它們，因為它們對於資料模型實在是太有用了。並且次級索引也是Solr和Elasticsearch等搜尋伺服器的基石。
​ 次級索引的問題是它們不能整齊地對映到分割槽。有兩種用二級索引對資料庫進行分割槽的方法：**基於文件的分割槽（document-based）**和**基於關鍵詞（term-based）的分割槽**。
### 基於文件的二級索引進行分割槽
​ 假設你正在經營一個銷售二手車的網站（如[圖6-4](../img/fig6-4.png)所示）。 每個列表都有一個唯一的ID——稱之為文件ID——並且用文件ID對資料庫進行分割槽（例如，分割槽0中的ID 0到499，分割槽1中的ID 500到999等）。
​ 你想讓使用者搜尋汽車，允許他們透過顏色和廠商過濾，所以需要一個在顏色和廠商上的次級索引（文件資料庫中這些是**欄位（field）**，關係資料庫中這些是**列（column）** ）。 如果您聲明瞭索引，則資料庫可以自動執行索引[^ii]。例如，無論何時將紅色汽車新增到資料庫，資料庫分割槽都會自動將其新增到索引條目`color：red`的文件ID列表中。
[^ii]: 如果資料庫僅支援鍵值模型，則你可能會嘗試在應用程式程式碼中建立從值到文件ID的對映來實現輔助索引。 如果沿著這條路線走下去，請萬分小心，確保您的索引與底層資料保持一致。 競爭條件和間歇性寫入失敗（其中一些更改已儲存，但其他更改未儲存）很容易導致資料不同步 - 參見“[多物件事務的需求]()”。
![](../img/fig6-4.png)
**圖6-4 基於文件的二級索引進行分割槽**
​ 在這種索引方法中，每個分割槽是完全獨立的：每個分割槽維護自己的二級索引，僅覆蓋該分割槽中的文件。它不關心儲存在其他分割槽的資料。無論何時您需要寫入資料庫（新增，刪除或更新文件），只需處理包含您正在編寫的文件ID的分割槽即可。出於這個原因，**文件分割槽索引**也被稱為**本地索引（local index）**（而不是將在下一節中描述的**全域性索引（global index）**）。
​ 但是，從文件分割槽索引中讀取需要注意：除非您對文件ID做了特別的處理，否則沒有理由將所有具有特定顏色或特定品牌的汽車放在同一個分割槽中。在[圖6-4](../img/fig6-4.png)中，紅色汽車出現在分割槽0和分割槽1中。因此，如果要搜尋紅色汽車，則需要將查詢傳送到所有分割槽，併合並所有返回的結果。
​ 這種查詢分割槽資料庫的方法有時被稱為**分散/聚集（scatter/gather）**，並且可能會使二級索引上的讀取查詢相當昂貴。即使並行查詢分割槽，分散/聚集也容易導致尾部延遲放大（參閱“[實踐中的百分位點](ch1.md#實踐中的百分位點)”）。然而，它被廣泛使用：MongoDB，Riak 【15】，Cassandra 【16】，Elasticsearch 【17】，SolrCloud 【18】和VoltDB 【19】都使用文件分割槽二級索引。大多數資料庫供應商建議您構建一個能從單個分割槽提供二級索引查詢的分割槽方案，但這並不總是可行，尤其是當在單個查詢中使用多個二級索引時（例如同時需要按顏色和製造商查詢）。
### 基於關鍵詞(Term)的二級索引進行分割槽
​ 我們可以構建一個覆蓋所有分割槽資料的**全域性索引**，而不是給每個分割槽建立自己的次級索引（本地索引）。但是，我們不能只把這個索引儲存在一個節點上，因為它可能會成為瓶頸，違背了分割槽的目的。全域性索引也必須進行分割槽，但可以採用與主鍵不同的分割槽方式。
​ [圖6-5](../img/fig6-5.png)述了這可能是什麼樣子：來自所有分割槽的紅色汽車在紅色索引中，並且索引是分割槽的，首字母從`a`到`r`的顏色在分割槽0中，`s`到`z`的在分割槽1。汽車製造商的索引也與之類似（分割槽邊界在`f`和`h`之間）。
![](../img/fig6-5.png)
**圖6-5 基於關鍵詞對二級索引進行分割槽**
​ 我們將這種索引稱為**關鍵詞分割槽（term-partitioned）**，因為我們尋找的關鍵詞決定了索引的分割槽方式。例如，一個關鍵詞可能是：`顏色：紅色`。**關鍵詞(Term)** 來源於來自全文搜尋索引（一種特殊的次級索引），指文件中出現的所有單詞。
​ 和之前一樣，我們可以透過**關鍵詞**本身或者它的雜湊進行索引分割槽。根據它本身分割槽對於範圍掃描非常有用（例如對於數字,像汽車的報價），而對關鍵詞的雜湊分割槽提供了負載均衡的能力。
​ 關鍵詞分割槽的全域性索引優於文件分割槽索引的地方點是它可以使讀取更有效率：不需要**分散/收集**所有分割槽，客戶端只需要向包含關鍵詞的分割槽發出請求。全域性索引的缺點在於寫入速度較慢且較為複雜，因為寫入單個文件現在可能會影響索引的多個分割槽（文件中的每個關鍵詞可能位於不同的分割槽或者不同的節點上） 。
​ 理想情況下，索引總是最新的，寫入資料庫的每個文件都會立即反映在索引中。但是，在關鍵詞分割槽索引中，這需要跨分割槽的分散式事務，並不是所有資料庫都支援（請參閱[第7章](ch7.md)和[第9章](ch9.md)）。
​ 在實踐中，對全域性二級索引的更新通常是**非同步**的（也就是說，如果在寫入之後不久讀取索引，剛才所做的更改可能尚未反映在索引中）。例如，Amazon DynamoDB聲稱在正常情況下，其全域性次級索引會在不到一秒的時間內更新，但在基礎架構出現故障的情況下可能會有延遲【20】。
​ 全域性關鍵詞分割槽索引的其他用途包括Riak的搜尋功能【21】和Oracle資料倉庫，它允許您在本地和全域性索引之間進行選擇【22】。我們將在[第12章](ch12.md)中涉及實現關鍵字二級索引的話題。
## 分割槽再平衡
隨著時間的推移，資料庫會有各種變化。
* 查詢吞吐量增加，所以您想要新增更多的CPU來處理負載。
* 資料集大小增加，所以您想新增更多的磁碟和RAM來儲存它。
* 機器出現故障，其他機器需要接管故障機器的責任。
所有這些更改都需要資料和請求從一個節點移動到另一個節點。 將負載從叢集中的一個節點向另一個節點移動的過程稱為**再平衡（reblancing）**。
無論使用哪種分割槽方案，再平衡通常都要滿足一些最低要求：
* 再平衡之後，負載（資料儲存，讀取和寫入請求）應該在叢集中的節點之間公平地共享。
* 再平衡發生時，資料庫應該繼續接受讀取和寫入。
* 節點之間只移動必須的資料，以便快速再平衡，並減少網路和磁碟I/O負載。
### 平衡策略
有幾種不同的分割槽分配方法【23】,讓我們依次簡要討論一下。
#### 反面教材：hash mod N
​ 我們在前面說過（[圖6-3](../img/fig6-3.png)），最好將可能的雜湊分成不同的範圍，並將每個範圍分配給一個分割槽（例如，如果$0≤hash(key)<b_0$，則將鍵分配給分割槽0，如果$b_0 ≤ hash(key) <b_1$，則分配給分割槽1）
​ 也許你想知道為什麼我們不使用***mod***（許多程式語言中的％運算子）。例如，`hash(key) mod 10`會返回一個介於0和9之間的數字（如果我們將雜湊寫為十進位制數，雜湊模10將是最後一個數字）。如果我們有10個節點，編號為0到9，這似乎是將每個鍵分配給一個節點的簡單方法。
​ 模$N$方法的問題是，如果節點數量N發生變化，大多數金鑰將需要從一個節點移動到另一個節點。例如，假設$hash(key)=123456$。如果最初有10個節點，那麼這個鍵一開始放在節點6上（因為$123456\ mod\ 10 = 6$）。當您增長到11個節點時，金鑰需要移動到節點3（$123456\ mod\ 11 = 3$），當您增長到12個節點時，需要移動到節點0（$123456\ mod\ 12 = 0$）。這種頻繁的舉動使得重新平衡過於昂貴。
​ 我們需要一種只移動必需資料的方法。
#### 固定數量的分割槽
​ 幸運的是，有一個相當簡單的解決方案：建立比節點更多的分割槽，併為每個節點分配多個分割槽。例如，執行在10個節點的叢集上的資料庫可能會從一開始就被拆分為1,000個分割槽，因此大約有100個分割槽被分配給每個節點。
​ 現在，如果一個節點被新增到叢集中，新節點可以從當前每個節點中**竊取**一些分割槽，直到分割槽再次公平分配。這個過程如[圖6-6](../img/fig6-6.png)所示。如果從叢集中刪除一個節點，則會發生相反的情況。
​ 只有分割槽在節點之間的移動。分割槽的數量不會改變，鍵所指定的分割槽也不會改變。唯一改變的是分割槽所在的節點。這種變更並不是即時的 — 在網路上傳輸大量的資料需要一些時間 — 所以在傳輸過程中，原有分割槽仍然會接受讀寫操作。
![](../img/fig6-6.png)
**圖6-6 將新節點新增到每個節點具有多個分割槽的資料庫群集。**
​ 原則上，您甚至可以解決叢集中的硬體不匹配問題：透過為更強大的節點分配更多的分割槽，可以強制這些節點承載更多的負載。在Riak 【15】，Elasticsearch 【24】，Couchbase 【10】和Voldemort 【25】中使用了這種再平衡的方法。
​ 在這種配置中，分割槽的數量通常在資料庫第一次建立時確定，之後不會改變。雖然原則上可以分割和合並分割槽（請參閱下一節），但固定數量的分割槽在操作上更簡單，因此許多固定分割槽資料庫選擇不實施分割槽分割。因此，一開始配置的分割槽數就是您可以擁有的最大節點數量，所以您需要選擇足夠多的分割槽以適應未來的增長。但是，每個分割槽也有管理開銷，所以選擇太大的數字會適得其反。
​ 如果資料集的總大小難以預估（例如，如果它開始很小，但隨著時間的推移可能會變得更大），選擇正確的分割槽數是困難的。由於每個分割槽包含了總資料量固定比率的資料，因此每個分割槽的大小與叢集中的資料總量成比例增長。如果分割槽非常大，再平衡和從節點故障恢復變得昂貴。但是，如果分割槽太小，則會產生太多的開銷。當分割槽大小“恰到好處”的時候才能獲得很好的效能，如果分割槽數量固定，但資料量變動很大，則難以達到最佳效能。
#### 動態分割槽
​ 對於使用鍵範圍分割槽的資料庫（參閱“[按鍵範圍分割槽](#按鍵範圍分割槽)”），具有固定邊界的固定數量的分割槽將非常不便：如果出現邊界錯誤，則可能會導致一個分割槽中的所有資料或者其他分割槽中的所有資料為空。手動重新配置分割槽邊界將非常繁瑣。
​ 出於這個原因，按鍵的範圍進行分割槽的資料庫（如HBase和RethinkDB）會動態建立分割槽。當分割槽增長到超過配置的大小時（在HBase上，預設值是10GB），會被分成兩個分割槽，每個分割槽約佔一半的資料【26】。與之相反，如果大量資料被刪除並且分割槽縮小到某個閾值以下，則可以將其與相鄰分割槽合併。此過程與B樹頂層發生的過程類似（參閱“[B樹](ch2.md#B樹)”）。
​ 每個分割槽分配給一個節點，每個節點可以處理多個分割槽，就像固定數量的分割槽一樣。大型分割槽拆分後，可以將其中的一半轉移到另一個節點，以平衡負載。在HBase中，分割槽檔案的傳輸透過HDFS（底層分散式檔案系統）來實現【3】。
​ 動態分割槽的一個優點是分割槽數量適應總資料量。如果只有少量的資料，少量的分割槽就足夠了，所以開銷很小;如果有大量的資料，每個分割槽的大小被限制在一個可配置的最大值【23】。
​ 需要注意的是，一個空的資料庫從一個分割槽開始，因為沒有關於在哪裡繪製分割槽邊界的先驗資訊。資料集開始時很小，直到達到第一個分割槽的分割點，所有寫入操作都必須由單個節點處理，而其他節點則處於空閒狀態。為了解決這個問題，HBase和MongoDB允許在一個空的資料庫上配置一組初始分割槽（這被稱為**預分割（pre-splitting）**）。在鍵範圍分割槽的情況中，預分割需要提前知道鍵是如何進行分配的【4,26】。
​ 動態分割槽不僅適用於資料的範圍分割槽，而且也適用於雜湊分割槽。從版本2.4開始，MongoDB同時支援範圍和雜湊分割槽，並且都是進行動態分割分割槽。
#### 按節點比例分割槽
​ 透過動態分割槽，分割槽的數量與資料集的大小成正比，因為拆分和合並過程將每個分割槽的大小保持在固定的最小值和最大值之間。另一方面，對於固定數量的分割槽，每個分割槽的大小與資料集的大小成正比。在這兩種情況下，分割槽的數量都與節點的數量無關。
​ Cassandra和Ketama使用的第三種方法是使分割槽數與節點數成正比——換句話說，每個節點具有固定數量的分割槽【23,27,28】。在這種情況下，每個分割槽的大小與資料集大小成比例地增長，而節點數量保持不變，但是當增加節點數時，分割槽將再次變小。由於較大的資料量通常需要較大數量的節點進行儲存，因此這種方法也使每個分割槽的大小較為穩定。
​ 當一個新節點加入叢集時，它隨機選擇固定數量的現有分割槽進行拆分，然後佔有這些拆分分割槽中每個分割槽的一半，同時將每個分割槽的另一半留在原地。隨機化可能會產生不公平的分割，但是平均在更大數量的分割槽上時（在Cassandra中，預設情況下，每個節點有256個分割槽），新節點最終從現有節點獲得公平的負載份額。 Cassandra 3.0引入了另一種再分配的演算法來避免不公平的分割【29】。
​ 隨機選擇分割槽邊界要求使用基於雜湊的分割槽（可以從雜湊函式產生的數字範圍中挑選邊界）。實際上，這種方法最符合一致性雜湊的原始定義【7】（參閱“[一致性雜湊](#一致性雜湊)”）。最新的雜湊函式可以在較低元資料開銷的情況下達到類似的效果【8】。
### 運維：手動還是自動平衡
​ 關於再平衡有一個重要問題：自動還是手動進行？
​ 在全自動重新平衡（系統自動決定何時將分割槽從一個節點移動到另一個節點，無須人工干預）和完全手動（分割槽指派給節點由管理員明確配置，僅在管理員明確重新配置時才會更改）之間有一個權衡。例如，Couchbase，Riak和Voldemort會自動生成建議的分割槽分配，但需要管理員提交才能生效。
​ 全自動重新平衡可以很方便，因為正常維護的操作工作較少。但是，這可能是不可預測的。再平衡是一個昂貴的操作，因為它需要重新路由請求並將大量資料從一個節點移動到另一個節點。如果沒有做好，這個過程可能會使網路或節點負載過重，降低其他請求的效能。
​ 這種自動化與自動故障檢測相結合可能十分危險。例如，假設一個節點過載，並且對請求的響應暫時很慢。其他節點得出結論：過載的節點已經死亡，並自動重新平衡叢集，使負載離開它。這會對已經超負荷的節點，其他節點和網路造成額外的負載，從而使情況變得更糟，並可能導致級聯失敗。
​ 出於這個原因，再平衡的過程中有人参與是一件好事。這比完全自動的過程慢，但可以幫助防止運維意外。
## 請求路由
​ 現在我們已經將資料集分割到多個機器上執行的多個節點上。但是仍然存在一個懸而未決的問題：當客戶想要發出請求時，如何知道要連線哪個節點？隨著分割槽重新平衡，分割槽對節點的分配也發生變化。為了回答這個問題，需要有人知曉這些變化：如果我想讀或寫鍵“foo”，需要連線哪個IP地址和埠號？
​ 這個問題可以概括為 **服務發現(service discovery)** ，它不僅限於資料庫。任何可透過網路訪問的軟體都有這個問題，特別是如果它的目標是高可用性（在多臺機器上執行冗餘配置）。許多公司已經編寫了自己的內部服務發現工具，其中許多已經作為開源釋出【30】。
概括來說，這個問題有幾種不同的方案（如圖6-7所示）:
1. 允許客戶聯絡任何節點（例如，透過**迴圈策略的負載均衡（Round-Robin Load Balancer）**）。如果該節點恰巧擁有請求的分割槽，則它可以直接處理該請求;否則，它將請求轉發到適當的節點，接收回復並傳遞給客戶端。
2. 首先將所有來自客戶端的請求傳送到路由層，它決定了應該處理請求的節點，並相應地轉發。此路由層本身不處理任何請求；它僅負責分割槽的負載均衡。
3. 要求客戶端知道分割槽和節點的分配。在這種情況下，客戶端可以直接連線到適當的節點，而不需要任何中介。
以上所有情況中的關鍵問題是：作出路由決策的元件（可能是節點之一，還是路由層或客戶端）如何瞭解分割槽-節點之間的分配關係變化？
![](../img/fig6-7.png)
**圖6-7 將請求路由到正確節點的三種不同方式。**
​ 這是一個具有挑戰性的問題，因為重要的是所有參與者都同意 - 否則請求將被髮送到錯誤的節點，而不是正確處理。 在分散式系統中有達成共識的協議，但很難正確地實現（見[第9章](ch9.md)）。
​ 許多分散式資料系統都依賴於一個獨立的協調服務，比如ZooKeeper來跟蹤叢集元資料，如[圖6-8](../img/fig6-8.png)所示。 每個節點在ZooKeeper中註冊自己，ZooKeeper維護分割槽到節點的可靠對映。 其他參與者（如路由層或分割槽感知客戶端）可以在ZooKeeper中訂閱此資訊。 只要分割槽分配發生的改變，或者叢集中新增或刪除了一個節點，ZooKeeper就會通知路由層使路由資訊保持最新狀態。
![](../img/fig6-8.png)
**圖6-8 使用ZooKeeper跟蹤分割槽分配給節點。**
​ 例如，LinkedIn的Espresso使用Helix 【31】進行叢集管理（依靠ZooKeeper），實現瞭如[圖6-8](../img/fig6-8.png)所示的路由層。 HBase，SolrCloud和Kafka也使用ZooKeeper來跟蹤分割槽分配。 MongoDB具有類似的體系結構，但它依賴於自己的**配置伺服器（config server）** 實現和mongos守護程序作為路由層。
​ Cassandra和Riak採取不同的方法：他們在節點之間使用**流言協議（gossip protocol）** 來傳播群集狀態的變化。請求可以傳送到任意節點，該節點會轉發到包含所請求的分割槽的適當節點（[圖6-7]()中的方法1）。這個模型在資料庫節點中增加了更多的複雜性，但是避免了對像ZooKeeper這樣的外部協調服務的依賴。
​ Couchbase不會自動重新平衡，這簡化了設計。通常情況下，它配置了一個名為moxi的路由層，它會從叢集節點了解路由變化【32】。
​ 當使用路由層或向隨機節點發送請求時，客戶端仍然需要找到要連線的IP地址。這些地址並不像分割槽的節點分佈變化的那麼快，所以使用DNS通常就足夠了。
### 執行並行查詢
​ 到目前為止，我們只關注讀取或寫入單個鍵的非常簡單的查詢（對於文件分割槽的二級索引，另外還有分散/聚集查詢）。這與大多數NoSQL分散式資料儲存所支援的訪問級別有關。
​ 然而，通常用於分析的**大規模並行處理（MPP, Massively parallel processing）** 關係型資料庫產品在其支援的查詢型別方面要複雜得多。一個典型的資料倉庫查詢包含多個連線，過濾，分組和聚合操作。 MPP查詢最佳化器將這個複雜的查詢分解成許多執行階段和分割槽，其中許多可以在資料庫叢集的不同節點上並行執行。涉及掃描大規模資料集的查詢特別受益於這種並行執行。
​ 資料倉庫查詢的快速並行執行是一個專門的話題，由於分析有很重要的商業意義，可以帶來很多利益。我們將在第10章討論並行查詢執行的一些技巧。有關並行資料庫中使用的技術的更詳細的概述，請參閱參考文獻【1,33】。
## 本章小結
​ 在本章中，我們探討了將大資料集劃分成更小的子集的不同方法。資料量非常大的時候，在單臺機器上儲存和處理不再可行，則分割槽十分必要。分割槽的目標是在多臺機器上均勻分佈資料和查詢負載，避免出現熱點（負載不成比例的節點）。這需要選擇適合於您的資料的分割槽方案，並在將節點新增到叢集或從叢集刪除時進行再分割槽。
我們討論了兩種主要的分割槽方法：
***鍵範圍分割槽***
​ 其中鍵是有序的，並且分割槽擁有從某個最小值到某個最大值的所有鍵。排序的優勢在於可以進行有效的範圍查詢，但是如果應用程式經常訪問相鄰的主鍵，則存在熱點的風險。
​ 在這種方法中，當分割槽變得太大時，通常將分割槽分成兩個子分割槽，動態地再平衡分割槽。
***雜湊分割槽***
​ 雜湊函式應用於每個鍵，分割槽擁有一定範圍的雜湊。這種方法破壞了鍵的排序，使得範圍查詢效率低下，但可以更均勻地分配負載。
​ 透過雜湊進行分割槽時，通常先提前建立固定數量的分割槽，為每個節點分配多個分割槽，並在新增或刪除節點時將整個分割槽從一個節點移動到另一個節點。也可以使用動態分割槽。
兩種方法搭配使用也是可行的，例如使用複合主鍵：使用鍵的一部分來標識分割槽，而使用另一部分作為排序順序。
我們還討論了分割槽和二級索引之間的相互作用。次級索引也需要分割槽，有兩種方法：
* 基於文件分割槽（本地索引），其中二級索引儲存在與主鍵和值相同的分割槽中。這意味著只有一個分割槽需要在寫入時更新，但是讀取二級索引需要在所有分割槽之間進行分散/收集。
* 基於關鍵詞分割槽（全域性索引），其中二級索引存在不同的分割槽中。輔助索引中的條目可以包括來自主鍵的所有分割槽的記錄。當文件寫入時，需要更新多個分割槽中的二級索引；但是可以從單個分割槽中進行讀取。
最後，我們討論了將查詢路由到適當的分割槽的技術，從簡單的分割槽負載平衡到複雜的並行查詢執行引擎。
​ 按照設計，多數情況下每個分割槽是獨立執行的 — 這就是分割槽資料庫可以擴充套件到多臺機器的原因。但是，需要寫入多個分割槽的操作結果可能難以預料：例如，如果寫入一個分割槽成功，但另一個分割槽失敗，會發生什麼情況？我們將在下面的章節中討論這個問題。
參考文獻
--------------------
1. David J. DeWitt and Jim N. Gray: “[Parallel Database Systems: The Future of High Performance Database Systems](),”
*Communications of the ACM*, volume 35, number 6, pages 85–98, June 1992. [doi:10.1145/129888.129894](http://dx.doi.org/10.1145/129888.129894)
2. Lars George: “[HBase vs. BigTable Comparison](http://www.larsgeorge.com/2009/11/hbase-vs-bigtable-comparison.html),” *larsgeorge.com*, November 2009.
3. “[The Apache HBase Reference Guide](https://hbase.apache.org/book/book.html),” Apache Software Foundation, *hbase.apache.org*, 2014.
4. MongoDB, Inc.: “[New Hash-Based Sharding Feature in MongoDB 2.4](http://blog.mongodb.org/post/47633823714/new-hash-based-sharding-feature-in-mongodb-24),” *blog.mongodb.org*, April 10, 2013.
5. Ikai Lan: “[App Engine Datastore Tip: Monotonically Increasing Values Are Bad](http://ikaisays.com/2011/01/25/app-engine-datastore-tip-monotonically-increasing-values-are-bad/),” *ikaisays.com*,
January 25, 2011.
6. Martin Kleppmann: “[Java's hashCode Is Not Safe for Distributed Systems](http://martin.kleppmann.com/2012/06/18/java-hashcode-unsafe-for-distributed-systems.html),” *martin.kleppmann.com*, June 18, 2012.
7. David Karger, Eric Lehman, Tom Leighton, et al.: “[Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web](http://www.akamai.com/dl/technical_publications/ConsistenHashingandRandomTreesDistributedCachingprotocolsforrelievingHotSpotsontheworldwideweb.pdf),” at *29th Annual ACM Symposium on Theory of Computing* (STOC), pages 654–663, 1997. [doi:10.1145/258533.258660](http://dx.doi.org/10.1145/258533.258660)
8. John Lamping and Eric Veach: “[A Fast, Minimal Memory, Consistent Hash Algorithm](http://arxiv.org/pdf/1406.2294v1.pdf),” *arxiv.org*, June 2014.
9. Eric Redmond: “[A Little Riak Book](http://littleriakbook.com/),” Version 1.4.0, Basho Technologies, September 2013.
10. “[Couchbase 2.5 Administrator Guide](http://docs.couchbase.com/couchbase-manual-2.5/cb-admin/),” Couchbase, Inc., 2014.
11. Avinash Lakshman and Prashant Malik: “[Cassandra – A Decentralized Structured Storage System](http://www.cs.cornell.edu/Projects/ladis2009/papers/Lakshman-ladis2009.PDF),” at *3rd ACM SIGOPS International Workshop on
Large Scale Distributed Systems and Middleware* (LADIS), October 2009.
12. Jonathan Ellis: “[Facebook’s Cassandra Paper, Annotated and Compared to Apache Cassandra 2.0](http://www.datastax.com/documentation/articles/cassandra/cassandrathenandnow.html),”
*datastax.com*, September 12, 2013.
13. “[Introduction to Cassandra Query Language](http://www.datastax.com/documentation/cql/3.1/cql/cql_intro_c.html),” DataStax, Inc., 2014.
14. Samuel Axon: “[3% of Twitter's Servers Dedicated to Justin Bieber](http://mashable.com/2010/09/07/justin-bieber-twitter/),” *mashable.com*, September 7, 2010.
15. “[Riak 1.4.8 Docs](http://docs.basho.com/riak/1.4.8/),” Basho Technologies, Inc., 2014.
16. Richard Low: “[The Sweet Spot for Cassandra Secondary Indexing](http://www.wentnet.com/blog/?p=77),” *wentnet.com*, October 21, 2013.
17. Zachary Tong: “[Customizing Your Document Routing](http://www.elasticsearch.org/blog/customizing-your-document-routing/),” *elasticsearch.org*, June 3, 2013.
18. “[Apache Solr Reference Guide](https://cwiki.apache.org/confluence/display/solr/Apache+Solr+Reference+Guide),” Apache Software Foundation, 2014.
19. Andrew Pavlo: “[H-Store Frequently Asked Questions](http://hstore.cs.brown.edu/documentation/faq/),” *hstore.cs.brown.edu*, October 2013.
20. “[Amazon DynamoDB Developer Guide](http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/),” Amazon Web Services, Inc., 2014.
21. Rusty Klophaus: “[Difference Between 2I and Search](http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-October/006220.html),” email to *riak-users* mailing list, *lists.basho.com*, October 25, 2011.
22. Donald K. Burleson: “[Object Partitioning in Oracle](http://www.dba-oracle.com/art_partit.htm),”*dba-oracle.com*, November 8, 2000.
23. Eric Evans: “[Rethinking Topology in Cassandra](http://www.slideshare.net/jericevans/virtual-nodes-rethinking-topology-in-cassandra),” at *ApacheCon Europe*, November 2012.
24. Rafał Kuć: “[Reroute API Explained](http://elasticsearchserverbook.com/reroute-api-explained/),” *elasticsearchserverbook.com*, September 30, 2013.
25. “[Project Voldemort Documentation](http://www.project-voldemort.com/voldemort/),” *project-voldemort.com*.
26. Enis Soztutar: “[Apache HBase Region Splitting and Merging](http://hortonworks.com/blog/apache-hbase-region-splitting-and-merging/),” *hortonworks.com*, February 1, 2013.
27. Brandon Williams: “[Virtual Nodes in Cassandra 1.2](http://www.datastax.com/dev/blog/virtual-nodes-in-cassandra-1-2),” *datastax.com*, December 4, 2012.
28. Richard Jones: “[libketama: Consistent Hashing Library for Memcached Clients](https://www.metabrew.com/article/libketama-consistent-hashing-algo-memcached-clients),” *metabrew.com*, April 10, 2007.
29. Branimir Lambov: “[New Token Allocation Algorithm in Cassandra 3.0](http://www.datastax.com/dev/blog/token-allocation-algorithm),” *datastax.com*, January 28, 2016.
30. Jason Wilder: “[Open-Source Service Discovery](http://jasonwilder.com/blog/2014/02/04/service-discovery-in-the-cloud/),” *jasonwilder.com*, February 2014.
31. Kishore Gopalakrishna, Shi Lu, Zhen Zhang, et al.: “[Untangling Cluster Management with Helix](http://www.socc2012.org/helix_onecol.pdf?attredirects=0),” at *ACM Symposium on Cloud Computing* (SoCC), October 2012.
[doi:10.1145/2391229.2391248](http://dx.doi.org/10.1145/2391229.2391248)
32. “[Moxi 1.8 Manual](http://docs.couchbase.com/moxi-manual-1.8/),” Couchbase, Inc., 2014.
33. Shivnath Babu and Herodotos Herodotou: “[Massively Parallel Databases and MapReduce Systems](http://research.microsoft.com/pubs/206464/db-mr-survey-final.pdf),” *Foundations and Trends in Databases*, volume 5, number 1, pages 1–104, November 2013.[doi:10.1561/1900000036](http://dx.doi.org/10.1561/1900000036)
------
| 上一章 | 目錄 | 下一章 |
| :--------------------: | :-----------------------------: | :--------------------: |
| [第五章：複製](ch5.md) | [設計資料密集型應用](README.md) | [第七章：事務](ch7.md) |

958
zh-tw/ch7.md Normal file
View File

@ -0,0 +1,958 @@
# 7. 事務
![](../img/ch7.png)
> ​ 一些作者聲稱，支援通用的兩階段提交代價太大，會帶來效能與可用性的問題。讓程式設計師來處理過度使用事務導致的效能問題，總比缺少事務程式設計好得多。
>
> ​ ——James Corbett等人，Spanner：Google的全球分散式資料庫（2012）
------
[TOC]
在資料系統的殘酷現實中，很多事情都可能出錯：
- 資料庫軟體、硬體可能在任意時刻發生故障（包括寫操作進行到一半時）。
- 應用程式可能在任意時刻崩潰（包括一系列操作的中間）。
- 網路中斷可能會意外切斷資料庫與應用的連線，或資料庫之間的連線。
- 多個客戶端可能會同時寫入資料庫，覆蓋彼此的更改。
- 客戶端可能讀取到無意義的資料，因為資料只更新了一部分。
- 客戶之間的競爭條件可能導致令人驚訝的錯誤。
為了實現可靠性，系統必須處理這些故障，確保它們不會導致整個系統的災難性故障。但是實現容錯機制工作量巨大。需要仔細考慮所有可能出錯的事情，並進行大量的測試，以確保解決方案真正管用。
​ 數十年來，**事務（transaction）** 一直是簡化這些問題的首選機制。事務是應用程式將多個讀寫操作組合成一個邏輯單元的一種方式。從概念上講，事務中的所有讀寫操作被視作單個操作來執行：整個事務要麼成功（**提交（commit）**）要麼失敗（**中止（abort）**，**回滾（rollback）**）。如果失敗，應用程式可以安全地重試。對於事務來說，應用程式的錯誤處理變得簡單多了，因為它不用再擔心部分失敗的情況了，即某些操作成功，某些失敗（無論出於何種原因）。
​ 和事務打交道時間長了，你可能會覺得它顯而易見。但我們不應將其視為理所當然。事務不是天然存在的；它們是為了**簡化應用程式設計模型**而建立的。透過使用事務，應用程式可以自由地忽略某些潛在的錯誤情況和併發問題，因為資料庫會替應用處理好這些。（我們稱之為**安全保證（safety guarantees）**）。
​ 並不是所有的應用都需要事務，有時候弱化事務保證、或完全放棄事務也是有好處的（例如，為了獲得更高效能或更高可用性）。一些安全屬性也可以在沒有事務的情況下實現。
​ 怎樣知道你是否需要事務？為了回答這個問題，首先需要確切理解事務可以提供的安全保障，以及它們的代價。儘管乍看事務似乎很簡單，但實際上有許多微妙但重要的細節在起作用。
​ 本章將研究許多出錯案例，並探索資料庫用於防範這些問題的演算法。尤其會深入**併發控制**的領域，討論各種可能發生的競爭條件，以及資料庫如何實現**讀已提交**，**快照隔離**和**可序列化**等隔離級別。
​ 本章同時適用於單機資料庫與分散式資料庫；在[第8章](ch8.md)中將重點討論僅出現在分散式系統中的特殊挑戰。
## 事務的棘手概念
​ 現今，幾乎所有的關係型資料庫和一些非關係資料庫都支援**事務**。其中大多數遵循IBM System R（第一個SQL資料庫）在1975年引入的風格【1,2,3】。40年裡，儘管一些實現細節發生了變化，但總體思路大同小異：MySQL，PostgreSQL，Oracle，SQL Server等資料庫中的事務支援與System R異乎尋常地相似。
2000年以後，非關係（NoSQL）資料庫開始普及。它們的目標是透過提供新的資料模型選擇（參見第2章），並透過預設包含複製（第5章）和分割槽（第6章）來改善關係現狀。事務是這種運動的主要原因：這些新一代資料庫中的許多資料庫完全放棄了事務，或者重新定義了這個詞，描述比以前理解所更弱的一套保證【4】。
隨著這種新型分散式資料庫的炒作，人們普遍認為事務是可擴充套件性的對立面，任何大型系統都必須放棄事務以保持良好的效能和高可用性【5,6】。另一方面，資料庫廠商有時將事務保證作為“重要應用”和“有價值資料”的基本要求。這兩種觀點都是**純粹的誇張**。
事實並非如此簡單：與其他技術設計選擇一樣，事務有其優勢和侷限性。為了理解這些權衡，讓我們瞭解事務所提供保證的細節——無論是在正常執行中還是在各種極端（但是現實存在）情況下。
### ACID的含義
事務所提供的安全保證，通常由眾所周知的首字母縮略詞ACID來描述，ACID代表**原子性（Atomicity）**，**一致性（Consistency）**，**隔離性（Isolation）**和**永續性（Durability）**。它由TheoHärder和Andreas Reuter於1983年建立，旨在為資料庫中的容錯機制建立精確的術語。
但實際上，不同資料庫的ACID實現並不相同。例如，我們將會看到，關於**隔離性（Isolation）** 的含義就有許多含糊不清【8】。高層次上的想法很美好，但魔鬼隱藏在細節裡。今天，當一個系統聲稱自己“符合ACID”時，實際上能期待的是什麼保證並不清楚。不幸的是，ACID現在幾乎已經變成了一個營銷術語。
（不符合ACID標準的系統有時被稱為BASE，它代表**基本可用性（Basically Available）**，**軟狀態（Soft State）**和**最終一致性（Eventual consistency）**【9】，這比ACID的定義更加模糊，似乎BASE的唯一合理的定義是“不是ACID”，即它幾乎可以代表任何你想要的東西。）
讓我們深入瞭解原子性，一致性，隔離性和永續性的定義，這可以讓我們提煉出事務的思想。
#### 原子性（Atomicity）
一般來說，原子是指不能分解成小部分的東西。這個詞在計算機的不同領域中意味著相似但又微妙不同的東西。例如，在多執行緒程式設計中，如果一個執行緒執行一個原子操作，這意味著另一個執行緒無法看到該操作的一半結果。系統只能處於操作之前或操作之後的狀態，而不是介於兩者之間的狀態。
相比之下，ACID的原子性並**不**是關於**併發（concurrent）**的。它並不是在描述如果幾個程序試圖同時訪問相同的資料會發生什麼情況，這種情況包含在縮寫 ***I*** 中，即[**隔離性（Isolation）**](#隔離性（Isolation）)
ACID的原子性而是描述了當客戶想進行多次寫入，但在一些寫操作處理完之後出現故障的情況。例如程序崩潰，網路連線中斷，磁碟變滿或者某種完整性約束被違反。如果這些寫操作被分組到一個原子事務中，並且該事務由於錯誤而不能完成（提交），則該事務將被中止，並且資料庫必須丟棄或撤消該事務中迄今為止所做的任何寫入。
如果沒有原子性，在多處更改進行到一半時發生錯誤，很難知道哪些更改已經生效，哪些沒有生效。該應用程式可以再試一次，但冒著進行兩次相同變更的風險，可能會導致資料重複或錯誤的資料。原子性簡化了這個問題：如果事務被**中止（abort）**，應用程式可以確定它沒有改變任何東西，所以可以安全地重試。
ACID原子性的定義特徵是：**能夠在錯誤時中止事務，丟棄該事務進行的所有寫入變更的能力。** 或許 **可中止性（abortability）** 是更好的術語，但本書將繼續使用原子性，因為這是慣用詞。
#### 一致性（Consistency）
一致性這個詞被賦予太多含義：
* 在[第5章](ch5.md)中，我們討論了副本一致性，以及非同步複製系統中的最終一致性問題（參閱“[複製延遲問題](ch5.md#複製延遲問題)”）。
* [一致性雜湊（Consistency Hash）](ch6.md#一致性雜湊))是某些系統用於重新分割槽的一種分割槽方法。
* 在[CAP定理](ch9.md#CAP定理)中，一致性一詞用於表示[可線性化](ch9.md#線性化)。
* 在ACID的上下文中，**一致性**是指資料庫在應用程式的特定概念中處於“良好狀態”。
很不幸，這一個詞就至少有四種不同的含義。
ACID一致性的概念是，**對資料的一組特定約束必須始終成立**。即**不變數（invariants）**。例如，在會計系統中，所有賬戶整體上必須借貸相抵。如果一個事務開始於一個滿足這些不變數的有效資料庫，且在事務處理期間的任何寫入操作都保持這種有效性，那麼可以確定，不變數總是滿足的。
但是，一致性的這種概念取決於應用程式對不變數的觀念，應用程式負責正確定義它的事務，並保持一致性。這並不是資料庫可以保證的事情：如果你寫入違反不變數的髒資料，資料庫也無法阻止你。 （一些特定型別的不變數可以由資料庫檢查，例如外來鍵約束或唯一約束，但是一般來說，是應用程式來定義什麼樣的資料是有效的，什麼樣是無效的。—— 資料庫只管儲存。）
原子性，隔離性和永續性是資料庫的屬性，而一致性（在ACID意義上）是應用程式的屬性。應用可能依賴資料庫的原子性和隔離屬性來實現一致性，但這並不僅取決於資料庫。因此，字母C不屬於ACID[^i]。
[^i]: 喬·海勒斯坦（Joe Hellerstein）指出，在論Härder與Reuter的論文中，“ACID中的C”是被“扔進去湊縮寫單詞的”【7】，而且那時候大家都不怎麼在乎一致性。
#### 隔離性（Isolation）
大多數資料庫都會同時被多個客戶端訪問。如果它們各自讀寫資料庫的不同部分，這是沒有問題的，但是如果它們訪問相同的資料庫記錄，則可能會遇到**併發**問題（**競爭條件（race conditions）**）。
[圖7-1](../img/fig7-1.png)是這類問題的一個簡單例子。假設你有兩個客戶端同時在資料庫中增長一個計數器。（假設資料庫中沒有自增操作）每個客戶端需要讀取計數器的當前值，加 1 ，再回寫新值。[圖7-1](../img/fig7-1.png) 中，因為發生了兩次增長，計數器應該從42增至44；但由於競態條件，實際上只增至 43 。
ACID意義上的隔離性意味著，**同時執行的事務是相互隔離的**：它們不能相互冒犯。傳統的資料庫教科書將隔離性形式化為**可序列化（Serializability）**，這意味著每個事務可以假裝它是唯一在整個資料庫上執行的事務。資料庫確保當事務已經提交時，結果與它們按順序執行（一個接一個）是一樣的，儘管實際上它們可能是併發執行的【10】。
![](../img/fig7-1.png)
**圖7-1 兩個客戶之間的競爭狀態同時遞增計數器**
然而實踐中很少會使用可序列化隔離，因為它有效能損失。一些流行的資料庫如Oracle 11g，甚至沒有實現它。在Oracle中有一個名為“可序列化”的隔離級別，但實際上它實現了一種叫做**快照隔離（snapshot isolation）** 的功能，**這是一種比可序列化更弱的保證**【8,11】。我們將在“[弱隔離等級]()”中研究快照隔離和其他形式的隔離。
#### 永續性（Durability）
資料庫系統的目的是，提供一個安全的地方儲存資料，而不用擔心丟失。**永續性** 是一個承諾，即一旦事務成功完成，即使發生硬體故障或資料庫崩潰，寫入的任何資料也不會丟失。
在單節點資料庫中，永續性通常意味著資料已被寫入非易失性儲存裝置，如硬碟或SSD。它通常還包括預寫日誌或類似的檔案（參閱“[讓B樹更可靠](ch3.md#讓B樹更可靠)”），以便在磁碟上的資料結構損壞時進行恢復。在帶複製的資料庫中，永續性可能意味著資料已成功複製到一些節點。為了提供永續性保證，資料庫必須等到這些寫入或複製完成後，才能報告事務成功提交。
如“[可靠性](ch1.md#可靠性)”一節所述，**完美的永續性是不存在的** ：如果所有硬碟和所有備份同時被銷燬，那顯然沒有任何資料庫能救得了你。
> #### 複製和永續性
>
> 在歷史上，永續性意味著寫入歸檔磁帶。後來它被理解為寫入硬碟或SSD。最近它已經適應了“複製（replication）”的新內涵。哪種實現更好一些？
>
> 真相是，沒有什麼是完美的：
>
> * 如果你寫入磁碟然後機器宕機，即使資料沒有丟失，在修復機器或將磁碟轉移到其他機器之前，也是無法訪問的。這種情況下，複製系統可以保持可用性。
> * 一個相關性故障（停電，或一個特定輸入導致所有節點崩潰的Bug）可能會一次性摧毀所有副本（參閱「[可靠性](ch1.md#可靠性)」），任何僅儲存在記憶體中的資料都會丟失，故記憶體資料庫仍然要和磁碟寫入打交道。
> * 在非同步複製系統中，當主庫不可用時，最近的寫入操作可能會丟失（參閱「[處理節點宕機](ch5.md#處理節點宕機)」）。
> * 當電源突然斷電時，特別是固態硬碟，有證據顯示有時會違反應有的保證：甚至fsync也不能保證正常工作【12】。硬碟韌體可能有錯誤，就像任何其他型別的軟體一樣【13,14】。
> * 儲存引擎和檔案系統之間的微妙互動可能會導致難以追蹤的錯誤，並可能導致磁碟上的檔案在崩潰後被損壞【15,16】。
> * 磁碟上的資料可能會在沒有檢測到的情況下逐漸損壞【17】。如果資料已損壞一段時間，副本和最近的備份也可能損壞。這種情況下，需要嘗試從歷史備份中恢復資料。
> * 一項關於固態硬碟的研究發現，在執行的前四年中，30％到80％的硬碟會產生至少一個壞塊【18】。相比固態硬碟，磁碟的壞道率較低，但完全失效的概率更高。
> * 如果SSD斷電，可能會在幾周內開始丟失資料，具體取決於溫度【19】。
>
> 在實踐中，沒有一種技術可以提供絕對保證。只有各種降低風險的技術，包括寫入磁碟，複製到遠端機器和備份——它們可以且應該一起使用。與往常一樣，最好抱著懷疑的態度接受任何理論上的“保證”
### 單物件和多物件操作
回顧一下，在ACID中，原子性和隔離性描述了客戶端在同一事務中執行多次寫入時，資料庫應該做的事情：
***原子性***
如果在一系列寫操作的中途發生錯誤，則應中止事務處理，並丟棄當前事務的所有寫入。換句話說，資料庫免去了使用者對部分失敗的擔憂——透過提供“**寧為玉碎，不為瓦全（all-or-nothing）**”的保證。
***隔離性***
同時執行的事務不應該互相干擾。例如，如果一個事務進行多次寫入，則另一個事務要麼看到全部寫入結果，要麼什麼都看不到，但不應該是一些子集。
這些定義假設你想同時修改多個物件（行，文件，記錄）。通常需要**多物件事務（multi-object transaction）** 來保持多塊資料同步。[圖7-2](../img/fig7-2.png)展示了一個來自電郵應用的例子。執行以下查詢來顯示使用者未讀郵件數量：
```sql
SELECT COUNT（*）FROM emails WHERE recipient_id = 2 AND unread_flag = true
```
但如果郵件太多，你可能會覺得這個查詢太慢，並決定用單獨的欄位儲存未讀郵件的數量（一種反規範化）。現在每當一個新訊息寫入時，必須也增長未讀計數器，每當一個訊息被標記為已讀時，也必須減少未讀計數器。
在[圖7-2](../img/fig7-2.png)中，使用者2 遇到異常情況：郵件列表裡顯示有未讀訊息，但計數器顯示為零未讀訊息，因為計數器增長還沒有發生[^ii]。隔離性可以避免這個問題：透過確保使用者2 要麼同時看到新郵件和增長後的計數器，要麼都看不到。反正不會看到執行到一半的中間結果。
[^ii]: 可以說郵件應用中的錯誤計數器並不是什麼特別重要的問題。但換種方式來看，你可以把未讀計數器換成客戶賬戶餘額，把郵件收發看成支付交易。
![](../img/fig7-2.png)
**圖7-2 違反隔離性：一個事務讀取另一個事務的未被執行的寫入（“髒讀”）。**
[圖7-3](../img/fig7-3.png)說明了對原子性的需求：如果在事務過程中發生錯誤，郵箱和未讀計數器的內容可能會失去同步。在原子事務中，如果對計數器的更新失敗，事務將被中止，並且插入的電子郵件將被回滾。
![](../img/fig7-3.png)
**圖7-3 原子性確保發生錯誤時，事務先前的任何寫入都會被撤消，以避免狀態不一致**
多物件事務需要某種方式來確定哪些讀寫操作屬於同一個事務。在關係型資料庫中，通常基於客戶端與資料庫伺服器的TCP連線：在任何特定連線上，`BEGIN TRANSACTION` 和 `COMMIT` 語句之間的所有內容，被認為是同一事務的一部分.[^iii]
[^iii]: 這並不完美。如果TCP連線中斷，則事務必須中止。如果中斷髮生在客戶端請求提交之後，但在伺服器確認提交發生之前，客戶端並不知道事務是否已提交。為了解決這個問題，事務管理器可以透過一個唯一事務識別符號來對操作進行分組，這個識別符號並未繫結到特定TCP連線。後續再“[資料庫端到端的爭論](ch12.md#資料庫端到端的爭論)”一節將回到這個主題。
另一方面，許多非關係資料庫並沒有將這些操作組合在一起的方法。即使存在多物件API（例如，鍵值儲存可能具有在一個操作中更新幾個鍵的數個put操作），但這並不一定意味著它具有事務語義：該命令可能在一些鍵上成功，在其他的鍵上失敗，使資料庫處於部分更新的狀態。
#### 單物件寫入
當單個物件發生改變時，原子性和隔離也是適用的。例如，假設您正在向資料庫寫入一個 20 KB的 JSON文件：
- 如果在傳送第一個10 KB之後網路連線中斷，資料庫是否儲存了不可解析的10KB JSON片段？
- 如果在資料庫正在覆蓋磁碟上的前一個值的過程中電源發生故障，是否最終將新舊值拼接在一起？
- 如果另一個客戶端在寫入過程中讀取該文件，是否會看到部分更新的值？
這些問題非常讓人頭大，故儲存引擎一個幾乎普遍的目標是：對單節點上的單個物件（例如鍵值對）上提供原子性和隔離性。原子性可以透過使用日誌來實現崩潰恢復（參閱“[使B樹可靠]()”），並且可以使用每個物件上的鎖來實現隔離（每次只允許一個執行緒訪問物件） ）。
一些資料庫也提供更復雜的原子操作，例如自增操作，這樣就不再需要像 [圖7-1](../img/fig7-1.png) 那樣的讀取-修改-寫入序列了。同樣流行的是 **[比較和設定（CAS, compare-and-set）](#比較並設定（CAS）)** 操作，當值沒有被其他併發修改過時，才允許執行寫操作。
這些單物件操作很有用，因為它們可以防止在多個客戶端嘗試同時寫入同一個物件時丟失更新（參閱“[防止丟失更新](#防止丟失更新)”）。但它們不是通常意義上的事務。CAS以及其他單一物件操作被稱為“輕量級事務”，甚至出於營銷目的被稱為“ACID”【20,21,22】，但是這個術語是誤導性的。事務通常被理解為，**將多個物件上的多個操作合併為一個執行單元的機制**。[^iv]
[^iv]: 嚴格地說，**原子自增（atomic increment）** 這個術語在多執行緒程式設計的意義上使用了原子這個詞。 在ACID的情況下，它實際上應該被稱為 **孤立（isolated）** 的或**可序列化（serializable）** 的增量。 但這就太吹毛求疵了。
#### 多物件事務的需求
許多分散式資料儲存已經放棄了多物件事務，因為多物件事務很難跨分割槽實現，而且在需要高可用性或高效能的情況下，它們可能會礙事。但說到底，在分散式資料庫中實現事務，並沒有什麼根本性的障礙。[第9章](ch9.md) 將討論分散式事務的實現。
但是我們是否需要多物件事務？**是否有可能只用鍵值資料模型和單物件操作來實現任何應用程式？**
有一些場景中，單物件插入，更新和刪除是足夠的。但是許多其他場景需要協調寫入幾個不同的物件：
* 在關係資料模型中，一個表中的行通常具有對另一個表中的行的外來鍵引用。（類似的是，在一個圖資料模型中，一個頂點有著到其他頂點的邊）。多物件事務使你確信這些引用始終有效：當插入幾個相互引用的記錄時，外來鍵必須是正確的，最新的，不然資料就沒有意義。
* 在文件資料模型中，需要一起更新的欄位通常在同一個文件中，這被視為單個物件——更新單個文件時不需要多物件事務。但是，缺乏連線功能的文件資料庫會鼓勵非規範化（參閱“[關係型資料庫與文件資料庫在今日的對比](ch2.md#關係型資料庫與文件資料庫在今日的對比)”）。當需要更新非規範化的資訊時，如 [圖7-2](../img/fig7-2.png) 所示，需要一次更新多個文件。事務在這種情況下非常有用，可以防止非規範化的資料不同步。
* 在具有二級索引的資料庫中（除了純粹的鍵值儲存以外幾乎都有），每次更改值時都需要更新索引。從事務角度來看，這些索引是不同的資料庫物件：例如，如果沒有事務隔離性，記錄可能出現在一個索引中，但沒有出現在另一個索引中，因為第二個索引的更新還沒有發生。
這些應用仍然可以在沒有事務的情況下實現。然而，**沒有原子性，錯誤處理就要複雜得多，缺乏隔離性，就會導致併發問題**。我們將在“[弱隔離級別](#弱隔離級別)”中討論這些問題，並在[第12章]()中探討其他方法。
#### 處理錯誤和中止
事務的一個關鍵特性是，如果發生錯誤，它可以中止並安全地重試。 ACID資料庫基於這樣的哲學：如果資料庫有違反其原子性，隔離性或永續性的危險，則寧願完全放棄事務，而不是留下半成品。
然而並不是所有的系統都遵循這個哲學。特別是具有[無主複製](ch6.md#無主複製)的資料儲存，主要是在“盡力而為”的基礎上進行工作。可以概括為“資料庫將做盡可能多的事，執行遇到錯誤時，它不會撤消它已經完成的事情“ ——所以，從錯誤中恢復是應用程式的責任。
錯誤發生不可避免，但許多軟體開發人員傾向於只考慮樂觀情況，而不是錯誤處理的複雜性。例如，像Rails的ActiveRecord和Django這樣的**物件關係對映（ORM, object-relation Mapping）** 框架不會重試中斷的事務—— 這個錯誤通常會導致一個從堆疊向上傳播的異常，所以任何使用者輸入都會被丟棄，使用者拿到一個錯誤資訊。這實在是太恥辱了，因為中止的重點就是允許安全的重試。
儘管重試一箇中止的事務是一個簡單而有效的錯誤處理機制，但它並不完美：
- 如果事務實際上成功了，但是在伺服器試圖向客戶端確認提交成功時網路發生故障（所以客戶端認為提交失敗了），那麼重試事務會導致事務被執行兩次——除非你有一個額外的應用級除重機制。
- 如果錯誤是由於負載過大造成的，則重試事務將使問題變得更糟，而不是更好。為了避免這種正反饋迴圈，可以限制重試次數，使用指數退避演算法，並單獨處理與過載相關的錯誤（如果允許）。
- 僅在臨時性錯誤（例如，由於死鎖，異常情況，臨時性網路中斷和故障切換）後才值得重試。在發生永久性錯誤（例如，違反約束）之後重試是毫無意義的。
- 如果事務在資料庫之外也有副作用，即使事務被中止，也可能發生這些副作用。例如，如果你正在傳送電子郵件，那你肯定不希望每次重試事務時都重新發送電子郵件。如果你想確保幾個不同的系統一起提交或放棄，**二階段提交（2PC, two-phase commit）** 可以提供幫助（“[原子提交和兩階段提交（2PC）](ch9.md#原子提交與二階段提交（2PC）)”中將討論這個問題）。
- 如果客戶端程序在重試中失效，任何試圖寫入資料庫的資料都將丟失。
## 弱隔離級別
如果兩個事務不觸及相同的資料，它們可以安全地**並行（parallel）** 執行，因為兩者都不依賴於另一個。當一個事務讀取由另一個事務同時修改的資料時，或者當兩個事務試圖同時修改相同的資料時，併發問題（競爭條件）才會出現。
併發BUG很難透過測試找到，因為這樣的錯誤只有在特殊時機下才會觸發。這樣的時機可能很少，通常很難重現[^譯註i]。併發性也很難推理，特別是在大型應用中，你不一定知道哪些其他程式碼正在訪問資料庫。在一次只有一個使用者時，應用開發已經很麻煩了，有許多併發使用者使得它更加困難，因為任何一個數據都可能隨時改變。
[^譯註i]: 軼事：偶然出現的瞬時錯誤有時稱為***Heisenbug***，而確定性的問題對應地稱為***Bohrbugs***
出於這個原因，資料庫一直試圖透過提供**事務隔離（transaction isolation）** 來隱藏應用程式開發者的併發問題。從理論上講，隔離可以透過假裝沒有併發發生，讓你的生活更加輕鬆：**可序列化（serializable）** 的隔離等級意味著資料庫保證事務的效果如同連續執行（即一次一個，沒有任何併發）。
實際上不幸的是：隔離並沒有那麼簡單。**可序列化** 會有效能損失，許多資料庫不願意支付這個代價【8】。因此，系統通常使用較弱的隔離級別來防止一部分，而不是全部的併發問題。這些隔離級別難以理解，並且會導致微妙的錯誤，但是它們仍然在實踐中被使用【23】。
弱事務隔離級別導致的併發性錯誤不僅僅是一個理論問題。它們造成了很多的資金損失【24,25】，耗費了財務審計人員的調查【26】，並導致客戶資料被破壞【27】。關於這類問題的一個流行的評論是“如果你正在處理財務資料，請使用ACID資料庫！” —— 但是這一點沒有提到。即使是很多流行的關係型資料庫系統（通常被認為是“ACID”）也使用弱隔離級別，所以它們也不一定能防止這些錯誤的發生。
比起盲目地依賴工具，我們應該對存在的併發問題的種類，以及如何防止這些問題有深入的理解。然後就可以使用我們所掌握的工具來構建可靠和正確的應用程式。
在本節中，我們將看幾個在實踐中使用的弱（**不可序列化（nonserializable）**）隔離級別，並詳細討論哪種競爭條件可能發生也可能不發生，以便您可以決定什麼級別適合您的應用程式。一旦我們完成了這個工作，我們將詳細討論可序列性（請參閱“[可序列化](#可序列化)”）。我們討論的隔離級別將是非正式的，使用示例。如果你需要嚴格的定義和分析它們的屬性，你可以在學術文獻中找到它們[28,29,30]。
### 讀已提交
最基本的事務隔離級別是**讀已提交（Read Committed）**[^v]，它提供了兩個保證：
1. 從資料庫讀時，只能看到已提交的資料（沒有**髒讀（dirty reads）**）。
2. 寫入資料庫時，只會覆蓋已經寫入的資料（沒有**髒寫（dirty writes）**）。
我們來更詳細地討論這兩個保證。
[^v]: 某些資料庫支援甚至更弱的隔離級別，稱為**讀未提交（Read uncommitted）**。它可以防止髒寫，但不防止髒讀。
#### 沒有髒讀
設想一個事務已經將一些資料寫入資料庫，但事務還沒有提交或中止。另一個事務可以看到未提交的資料嗎？如果是的話，那就叫做**髒讀（dirty reads）**【2】。
在**讀已提交**隔離級別執行的事務必須防止髒讀。這意味著事務的任何寫入操作只有在該事務提交時才能被其他人看到（然後所有的寫入操作都會立即變得可見）。如[圖7-4]()所示，使用者1 設定了`x = 3`，但使用者2 的 `get x `仍舊返回舊值2 ，而使用者1 尚未提交。
![](../img/fig7-4.png)
**圖7-4 沒有髒讀：使用者2只有在使用者1的事務已經提交後才能看到x的新值。**
為什麼要防止髒讀，有幾個原因：
- 如果事務需要更新多個物件，髒讀取意味著另一個事務可能會只看到一部分更新。例如，在[圖7-2](../img/fig7-2.png)中，使用者看到新的未讀電子郵件，但看不到更新的計數器。這就是電子郵件的髒讀。看到處於部分更新狀態的資料庫會讓使用者感到困惑，並可能導致其他事務做出錯誤的決定。
- 如果事務中止，則所有寫入操作都需要回滾（如[圖7-3](../img/fig7-3.png)所示）。如果資料庫允許髒讀，那就意味著一個事務可能會看到稍後需要回滾的資料，即從未實際提交給資料庫的資料。想想後果就讓人頭大。
#### 沒有髒寫
如果兩個事務同時嘗試更新資料庫中的相同物件，會發生什麼情況？我們不知道寫入的順序是怎樣的，但是我們通常認為後面的寫入會覆蓋前面的寫入。
但是，如果先前的寫入是尚未提交事務的一部分，又會發生什麼情況，後面的寫入會覆蓋一個尚未提交的值？這被稱作**髒寫（dirty write）**【28】。在**讀已提交**的隔離級別上執行的事務必須防止髒寫，通常是延遲第二次寫入，直到第一次寫入事務提交或中止為止。
透過防止髒寫，這個隔離級別避免了一些併發問題：
- 如果事務更新多個物件，髒寫會導致不好的結果。例如，考慮 [圖7-5](../img/fig7-5.png)，[圖7-5](../img/fig7-5.png) 以一個二手車銷售網站為例，Alice和Bob兩個人同時試圖購買同一輛車。購買汽車需要兩次資料庫寫入：網站上的商品列表需要更新，以反映買家的購買，銷售發票需要傳送給買家。在[圖7-5](../img/fig7-5.png)的情況下，銷售是屬於Bob的（因為他成功更新了商品列表），但發票卻寄送給了愛麗絲（因為她成功更新了發票表）。讀已提交會阻止這樣這樣的事故。
- 但是，提交讀取並不能防止[圖7-1]()中兩個計數器增量之間的競爭狀態。在這種情況下，第二次寫入發生在第一個事務提交後，所以它不是一個髒寫。這仍然是不正確的，但是出於不同的原因，在“[防止更新丟失](#防止丟失更新)”中將討論如何使這種計數器增量安全。
![](../img/fig7-5.png)
**圖7-5 如果存在髒寫，來自不同事務的衝突寫入可能會混淆在一起**
#### 實現讀已提交
**讀已提交**是一個非常流行的隔離級別。這是Oracle 11g，PostgreSQL，SQL Server 2012，MemSQL和其他許多資料庫的預設設定【8】。
最常見的情況是，資料庫透過使用**行鎖（row-level lock）** 來防止髒寫：當事務想要修改特定物件（行或文件）時，它必須首先獲得該物件的鎖。然後必須持有該鎖直到事務被提交或中止。一次只有一個事務可持有任何給定物件的鎖；如果另一個事務要寫入同一個物件，則必須等到第一個事務提交或中止後，才能獲取該鎖並繼續。這種鎖定是讀已提交模式（或更強的隔離級別）的資料庫自動完成的。
如何防止髒讀？一種選擇是使用相同的鎖，並要求任何想要讀取物件的事務來簡單地獲取該鎖，然後在讀取之後立即再次釋放該鎖。這能確保不會讀取進行時，物件不會在髒的狀態，有未提交的值（因為在那段時間鎖會被寫入該物件的事務持有）。
但是要求讀鎖的辦法在實踐中效果並不好。因為一個長時間執行的寫入事務會迫使許多隻讀事務等到這個慢寫入事務完成。這會損失只讀事務的響應時間，並且不利於可操作性：因為等待鎖，應用某個部分的遲緩可能由於連鎖效應，導致其他部分出現問題。
出於這個原因，大多數資料庫[^vi]使用[圖7-4]()的方式防止髒讀：對於寫入的每個物件，資料庫都會記住舊的已提交值，和由當前持有寫入鎖的事務設定的新值。當事務正在進行時，任何其他讀取物件的事務都會拿到舊值。 只有當新值提交後，事務才會切換到讀取新值。
[^vi]: 在撰寫本文時，唯一在讀已提交隔離級別使用讀鎖的主流資料庫是使用`read_committed_snapshot = off`配置的IBM DB2和Microsoft SQL Server [23,36]。
### 快照隔離和可重複讀
如果只從表面上看讀已提交隔離級別你就認為它完成了事務所需的一切，那是可以原諒的。它允許**中止**（原子性的要求）；它防止讀取不完整的事務結果，並且防止併發寫入造成的混合。事實上這些功能非常有用，比起沒有事務的系統來，可以提供更多的保證。
但是在使用此隔離級別時，仍然有很多地方可能會產生併發錯誤。例如[圖7-6](../img/fig7-6.png)說明了讀已提交時可能發生的問題。
![](../img/fig7-6.png)
**圖7-6 讀取偏差：Alice觀察資料庫處於不一致的狀態**
愛麗絲在銀行有1000美元的儲蓄，分為兩個賬戶，每個500美元。現在一筆事務從她的一個賬戶中轉移了100美元到另一個賬戶。如果她在事務處理的同時檢視其賬戶餘額列表，不幸地在轉賬事務完成前看到收款賬戶餘額（餘額為500美元），而在轉賬完成後看到另一個轉出賬戶（已經轉出100美元，餘額400美元）。對愛麗絲來說，現在她的賬戶似乎只有900美元——看起來100美元已經消失了。
這種異常被稱為**不可重複讀（nonrepeatable read）**或**讀取偏差（read skew）**：如果Alice在事務結束時再次讀取賬戶1的餘額，她將看到與她之前的查詢中看到的不同的值（600美元）。在讀已提交的隔離條件下，**不可重複讀**被認為是可接受的：Alice看到的帳戶餘額時確實在閱讀時已經提交了。
> 不幸的是，術語**偏差（skew）** 這個詞是過載的：以前使用它是因為熱點的不平衡工作量（參閱“[偏斜的負載傾斜與消除熱點](ch6.md#負載傾斜與消除熱點)”），而這裡偏差意味著異常的時機。
對於Alice的情況，這不是一個長期持續的問題。因為如果她幾秒鐘後重新整理銀行網站的頁面，她很可能會看到一致的帳戶餘額。但是有些情況下，不能容忍這種暫時的不一致：
***備份***
​ 進行備份需要複製整個資料庫，對大型資料庫而言可能需要花費數小時才能完成。備份程序執行時，資料庫仍然會接受寫入操作。因此備份可能會包含一些舊的部分和一些新的部分。如果從這樣的備份中恢復，那麼不一致（如消失的錢）就會變成永久的。
***分析查詢和完整性檢查***
​ 有時，您可能需要執行一個查詢，掃描大部分的資料庫。這樣的查詢在分析中很常見（參閱“[事務處理或分析？](ch3.md#事務處理還是分析？)”），也可能是定期完整性檢查（即監視資料損壞）的一部分。如果這些查詢在不同時間點觀察資料庫的不同部分，則可能會返回毫無意義的結果。
**快照隔離（snapshot isolation）**【28】是這個問題最常見的解決方案。想法是，每個事務都從資料庫的**一致快照（consistent snapshot）** 中讀取——也就是說，事務可以看到事務開始時在資料庫中提交的所有資料。即使這些資料隨後被另一個事務更改，每個事務也只能看到該特定時間點的舊資料。
快照隔離對長時間執行的只讀查詢（如備份和分析）非常有用。如果查詢的資料在查詢執行的同時發生變化，則很難理解查詢的含義。當一個事務可以看到資料庫在某個特定時間點凍結時的一致快照，理解起來就很容易了。
快照隔離是一個流行的功能：PostgreSQL，使用InnoDB引擎的MySQL，Oracle，SQL Server等都支援【23,31,32】。
#### 實現快照隔離
與讀取提交的隔離類似，快照隔離的實現通常使用寫鎖來防止髒寫（請參閱“[讀已提交](#讀已提交)”），這意味著進行寫入的事務會阻止另一個事務修改同一個物件。但是讀取不需要任何鎖定。從效能的角度來看，快照隔離的一個關鍵原則是：**讀不阻塞寫，寫不阻塞讀**。這允許資料庫在處理一致性快照上的長時間查詢時，可以正常地同時處理寫入操作。且兩者間沒有任何鎖定爭用。
為了實現快照隔離，資料庫使用了我們看到的用於防止[圖7-4]()中的髒讀的機制的一般化。資料庫必須可能保留一個物件的幾個不同的提交版本，因為各種正在進行的事務可能需要看到資料庫在不同的時間點的狀態。因為它並排維護著多個版本的物件，所以這種技術被稱為**多版本併發控制（MVCC, multi-version concurrentcy control）**。
如果一個數據庫只需要提供**讀已提交**的隔離級別，而不提供**快照隔離**，那麼保留一個物件的兩個版本就足夠了：提交的版本和被覆蓋但尚未提交的版本。支援快照隔離的儲存引擎通常也使用MVCC來實現**讀已提交**隔離級別。一種典型的方法是**讀已提交**為每個查詢使用單獨的快照，而**快照隔離**對整個事務使用相同的快照。
[圖7-7]()說明了如何在PostgreSQL中實現基於MVCC的快照隔離【31】（其他實現類似）。當一個事務開始時，它被賦予一個唯一的，永遠增長[^vii]的事務ID（`txid`）。每當事務向資料庫寫入任何內容時，它所寫入的資料都會被標記上寫入者的事務ID。
[^vii]: 事實上，事務ID是32位整數，所以大約會在40億次事務之後溢位。 PostgreSQL的Vacuum過程會清理老舊的事務ID，確保事務ID溢位（回捲）不會影響到資料。
![](../img/fig7-7.png)
**圖7-7 使用多版本物件實現快照隔離**
表中的每一行都有一個 `created_by` 欄位，其中包含將該行插入到表中的的事務ID。此外，每行都有一個 `deleted_by` 欄位，最初是空的。如果某個事務刪除了一行，那麼該行實際上並未從資料庫中刪除，而是透過將 `deleted_by` 欄位設定為請求刪除的事務的ID來標記為刪除。在稍後的時間，當確定沒有事務可以再訪問已刪除的資料時，資料庫中的垃圾收集過程會將所有帶有刪除標記的行移除，並釋放其空間。[^譯註ii]
[^譯註ii]: 在PostgreSQL中，`created_by` 的實際名稱為`xmin`，`deleted_by` 的實際名稱為`xmax`
`UPDATE` 操作在內部翻譯為 `DELETE` 和 `INSERT` 。例如，在[圖7-7]()中，事務13 從賬戶2 中扣除100美元，將餘額從500美元改為400美元。實際上包含兩條賬戶2 的記錄：餘額為 \$500 的行被標記為**被事務13刪除**，餘額為 \$400 的行**由事務13建立**。
#### 觀察一致性快照的可見性規則
當一個事務從資料庫中讀取時，事務ID用於決定它可以看見哪些物件，看不見哪些物件。透過仔細定義可見性規則，資料庫可以嚮應用程式呈現一致的資料庫快照。工作如下：
1. 在每次事務開始時，資料庫列出當時所有其他（尚未提交或尚未中止）的事務清單，即使之後提交了，這些事務已執行的任何寫入也都會被忽略。
2. 被中止事務所執行的任何寫入都將被忽略。
3. 由具有較晚事務ID（即，在當前事務開始之後開始的）的事務所做的任何寫入都被忽略，而不管這些事務是否已經提交。
4. 所有其他寫入，對應用都是可見的。
這些規則適用於建立和刪除物件。在[圖7-7]()中，當事務12 從賬戶2 讀取時，它會看到 \$500 的餘額，因為 \$500 餘額的刪除是由事務13 完成的（根據規則3，事務12 看不到事務13 執行的刪除），且400美元記錄的建立也是不可見的（按照相同的規則）。
換句話說，如果以下兩個條件都成立，則可見一個物件：
- 讀事務開始時，建立該物件的事務已經提交。
- 物件未被標記為刪除，或如果被標記為刪除，請求刪除的事務在讀事務開始時尚未提交。
長時間執行的事務可能會長時間使用快照，並繼續讀取（從其他事務的角度來看）早已被覆蓋或刪除的值。由於從來不原地更新值，而是每次值改變時建立一個新的版本，資料庫可以在提供一致快照的同時只產生很小的額外開銷。
#### 索引和快照隔離
索引如何在多版本資料庫中工作？一種選擇是使索引簡單地指向物件的所有版本，並且需要索引查詢來過濾掉當前事務不可見的任何物件版本。當垃圾收集刪除任何事務不再可見的舊物件版本時，相應的索引條目也可以被刪除。
在實踐中，許多實現細節決定了多版本併發控制的效能。例如，如果同一物件的不同版本可以放入同一個頁面中，PostgreSQL的最佳化可以避免更新索引【31】。
在CouchDB，Datomic和LMDB中使用另一種方法。雖然它們也使用[B樹](ch2.md#B樹)，但它們使用的是一種**僅追加/寫時複製（append-only/copy-on-write）** 的變體，它們在更新時不覆蓋樹的頁面，而為每個修改頁面建立一份副本。從父頁面直到樹根都會級聯更新，以指向它們子頁面的新版本。任何不受寫入影響的頁面都不需要被複制，並且保持不變【33,34,35】。
使用僅追加的B樹，每個寫入事務（或一批事務）都會建立一顆新的B樹，當建立時，從該特定樹根生長的樹就是資料庫的一個一致性快照。沒必要根據事務ID過濾掉物件，因為後續寫入不能修改現有的B樹；它們只能建立新的樹根。但這種方法也需要一個負責壓縮和垃圾收集的後臺程序。
#### 可重複讀與命名混淆
快照隔離是一個有用的隔離級別，特別對於只讀事務而言。但是，許多資料庫實現了它，卻用不同的名字來稱呼。在Oracle中稱為**可序列化（Serializable）**的，在PostgreSQL和MySQL中稱為**可重複讀（repeatable read）**【23】。
這種命名混淆的原因是SQL標準沒有**快照隔離**的概念，因為標準是基於System R 1975年定義的隔離級別【2】，那時候**快照隔離**尚未發明。相反，它定義了**可重複讀**，表面上看起來與快照隔離很相似。 PostgreSQL和MySQL稱其**快照隔離**級別為**可重複讀（repeatable read）**，因為這樣符合標準要求，所以它們可以聲稱自己“標準相容”。
不幸的是，SQL標準對隔離級別的定義是有缺陷的——模糊，不精確，並不像標準應有的樣子獨立於實現【28】。有幾個資料庫實現了可重複讀，但它們實際提供的保證存在很大的差異，儘管表面上是標準化的【23】。在研究文獻【29,30】中已經有了可重複讀的正式定義，但大多數的實現並不能滿足這個正式定義。最後，IBM DB2使用“可重複讀”來引用可序列化【8】。
結果，沒有人真正知道**可重複讀**的意思。
### 防止丟失更新
到目前為止已經討論的**讀已提交**和**快照隔離**級別，主要保證了**只讀事務在併發寫入時**可以看到什麼。卻忽略了兩個事務併發寫入的問題——我們只討論了[髒寫](#髒寫)，一種特定型別的寫-寫衝突是可能出現的。
併發的寫入事務之間還有其他幾種有趣的衝突。其中最著名的是**丟失更新（lost update）** 問題，如[圖7-1]()所示，以兩個併發計數器增量為例。
如果應用從資料庫中讀取一些值，修改它並寫回修改的值（讀取-修改-寫入序列），則可能會發生丟失更新的問題。如果兩個事務同時執行，則其中一個的修改可能會丟失，因為第二個寫入的內容並沒有包括第一個事務的修改（有時會說後面寫入**狠揍（clobber）** 了前面的寫入）這種模式發生在各種不同的情況下：
- 增加計數器或更新賬戶餘額（需要讀取當前值，計算新值並寫回更新後的值）
- 在複雜值中進行本地修改：例如，將元素新增到JSON文件中的一個列表（需要解析文件，進行更改並寫回修改的文件）
- 兩個使用者同時編輯wiki頁面，每個使用者透過將整個頁面內容傳送到伺服器來儲存其更改，覆寫資料庫中當前的任何內容。
這是一個普遍的問題，所以已經開發了各種解決方案。
#### 原子寫
許多資料庫提供了原子更新操作，從而消除了在應用程式程式碼中執行讀取-修改-寫入序列的需要。如果你的程式碼可以用這些操作來表達，那這通常是最好的解決方案。例如，下面的指令在大多數關係資料庫中是併發安全的：
```sql
UPDATE counters SET value = value + 1 WHERE key = 'foo';
```
類似地，像MongoDB這樣的文件資料庫提供了對JSON文件的一部分進行本地修改的原子操作，Redis提供了修改資料結構（如優先順序佇列）的原子操作。並不是所有的寫操作都可以用原子操作的方式來表達，例如維基頁面的更新涉及到任意文字編輯[^viii]，但是在可以使用原子操作的情況下，它們通常是最好的選擇。
[^viii]: 將文字文件的編輯表示為原子的變化流是可能的，儘管相當複雜。參閱“[自動衝突解決](ch5.md#題外話：自動衝突解決)”。
原子操作通常透過在讀取物件時，獲取其上的排它鎖來實現。以便更新完成之前沒有其他事務可以讀取它。這種技術有時被稱為**遊標穩定性（cursor stability）**【36,37】。另一個選擇是簡單地強制所有的原子操作在單一執行緒上執行。
不幸的是，ORM框架很容易意外地執行不安全的讀取-修改-寫入序列，而不是使用資料庫提供的原子操作【38】。如果你知道自己在做什麼那當然不是問題，但它經常產生那種很難測出來的微妙Bug。
#### 顯式鎖定
如果資料庫的內建原子操作沒有提供必要的功能，防止丟失更新的另一個選擇是讓應用程式顯式地鎖定將要更新的物件。然後應用程式可以執行讀取-修改-寫入序列，如果任何其他事務嘗試同時讀取同一個物件，則強制等待，直到第一個**讀取-修改-寫入序列**完成。
例如，考慮一個多人遊戲，其中幾個玩家可以同時移動相同的棋子。在這種情況下，一個原子操作可能是不夠的，因為應用程式還需要確保玩家的移動符合遊戲規則，這可能涉及到一些不能合理地用資料庫查詢實現的邏輯。但你可以使用鎖來防止兩名玩家同時移動相同的棋子，如例7-1所示。
**例7-1 顯式鎖定行以防止丟失更新**
```plsql
BEGIN TRANSACTION;
SELECT * FROM figures
WHERE name = 'robot' AND game_id = 222
FOR UPDATE;
-- 檢查玩家的操作是否有效，然後更新先前SELECT返回棋子的位置。
UPDATE figures SET position = 'c4' WHERE id = 1234;
COMMIT;
```
- `FOR UPDATE`子句告訴資料庫應該對該查詢返回的所有行加鎖。
這是有效的，但要做對，你需要仔細考慮應用邏輯。忘記在程式碼某處加鎖很容易引入競爭條件。
#### 自動檢測丟失的更新
原子操作和鎖是透過強制**讀取-修改-寫入序列**按順序發生，來防止丟失更新的方法。另一種方法是允許它們並行執行，如果事務管理器檢測到丟失更新，則中止事務並強制它們重試其**讀取-修改-寫入序列**。
這種方法的一個優點是，資料庫可以結合快照隔離高效地執行此檢查。事實上，PostgreSQL的可重複讀，Oracle的可序列化和SQL Server的快照隔離級別，都會自動檢測到丟失更新，並中止惹麻煩的事務。但是，MySQL/InnoDB的可重複讀並不會檢測**丟失更新**【23】。一些作者【28,30】認為，資料庫必須能防止丟失更新才稱得上是提供了**快照隔離**，所以在這個定義下，MySQL下不提供快照隔離。
丟失更新檢測是一個很好的功能，因為它不需要應用程式碼使用任何特殊的資料庫功能，你可能會忘記使用鎖或原子操作，從而引入錯誤；但丟失更新的檢測是自動發生的，因此不太容易出錯。
#### 比較並設定（CAS）
在不提供事務的資料庫中，有時會發現一種原子操作：**比較並設定（CAS, Compare And Set）**（先前在“[單物件寫入]()”中提到）。此操作的目的是為了避免丟失更新：只有當前值從上次讀取時一直未改變，才允許更新發生。如果當前值與先前讀取的值不匹配，則更新不起作用，且必須重試讀取-修改-寫入序列。
例如，為了防止兩個使用者同時更新同一個wiki頁面，可以嘗試類似這樣的方式，只有當用戶開始編輯頁面內容時，才會發生更新：
```sql
-- 根據資料庫的實現情況，這可能也可能不安全
UPDATE wiki_pages SET content = '新內容'
WHERE id = 1234 AND content = '舊內容';
```
如果內容已經更改並且不再與“舊內容”相匹配，則此更新將不起作用，因此您需要檢查更新是否生效，必要時重試。但是，如果資料庫允許`WHERE`子句從舊快照中讀取，則此語句可能無法防止丟失更新，因為即使發生了另一個併發寫入，`WHERE`條件也可能為真。在依賴資料庫的CAS操作前要檢查其是否安全。
#### 衝突解決和複製
在複製資料庫中（參見[第5章](ch5.md)），防止丟失的更新需要考慮另一個維度：由於在多個節點上存在資料副本，並且在不同節點上的資料可能被併發地修改，因此需要採取一些額外的步驟來防止丟失更新。
鎖和CAS操作假定只有一個最新的資料副本。但是多主或無主複製的資料庫通常允許多個寫入併發執行，並非同步複製到副本上，因此無法保證只有一個最新資料的副本。所以基於鎖或CAS操作的技術不適用於這種情況。 （我們將在“[線性化](ch9.md#線性化)”中更詳細地討論這個問題。）
相反，如“[檢測併發寫入](ch5.md#檢測併發寫入)”一節所述，這種複製資料庫中的一種常見方法是允許併發寫入建立多個衝突版本的值（也稱為兄弟），並使用應用程式碼或特殊資料結構在事實發生之後解決和合並這些版本。
原子操作可以在複製的上下文中很好地工作，尤其當它們具有可交換性時（即，可以在不同的副本上以不同的順序應用它們，且仍然可以得到相同的結果）。例如，遞增計數器或向集合新增元素是可交換的操作。這是Riak 2.0資料型別背後的思想，它可以防止複製副本丟失更新。當不同的客戶端同時更新一個值時，Riak自動將更新合併在一起，以免丟失更新【39】。
另一方面，最後寫入勝利（LWW）的衝突解決方法很容易丟失更新，如“[最後寫入勝利（丟棄併發寫入）](ch5.md#最後寫入勝利（丟棄併發寫入）)”中所述。不幸的是，LWW是許多複製資料庫中的預設方案。
#### 寫入偏差與幻讀
前面的章節中，我們看到了**髒寫**和**丟失更新**，當不同的事務併發地嘗試寫入相同的物件時，會出現這兩種競爭條件。為了避免資料損壞，這些競爭條件需要被阻止——既可以由資料庫自動執行，也可以透過鎖和原子寫操作這類手動安全措施來防止。
但是，併發寫入間可能發生的競爭條件還沒有完。在本節中，我們將看到一些更微妙的衝突例子。
首先，想象一下這個例子：你正在為醫院寫一個醫生輪班管理程式。醫院通常會同時要求幾位醫生待命，但底線是至少有一位醫生在待命。醫生可以放棄他們的班次（例如，如果他們自己生病了），只要至少有一個同事在這一班中繼續工作【40,41】。
現在想象一下，Alice和Bob是兩位值班醫生。兩人都感到不適，所以他們都決定請假。不幸的是，他們恰好在同一時間點選按鈕下班。[圖7-8](../img/fig7-8.png)說明了接下來的事情。
![](../img/fig7-8.png)
**圖7-8 寫入偏差導致應用程式錯誤的示例**
在兩個事務中，應用首先檢查是否有兩個或以上的醫生正在值班；如果是的話，它就假定一名醫生可以安全地休班。由於資料庫使用快照隔離，兩次檢查都返回 2 ，所以兩個事務都進入下一個階段。Alice更新自己的記錄休班了，而Bob也做了一樣的事情。兩個事務都成功提交了，現在沒有醫生值班了。違反了至少有一名醫生在值班的要求。
#### 寫偏差的特徵
這種異常稱為**寫偏差**【28】。它既不是**髒寫**，也不是**丟失更新**，因為這兩個事務正在更新兩個不同的物件（Alice和Bob各自的待命記錄）。在這裡發生的衝突並不是那麼明顯，但是這顯然是一個競爭條件：如果兩個事務一個接一個地執行，那麼第二個醫生就不能歇班了。異常行為只有在事務併發進行時才有可能。
可以將寫入偏差視為丟失更新問題的一般化。如果兩個事務讀取相同的物件，然後更新其中一些物件（不同的事務可能更新不同的物件），則可能發生寫入偏差。在多個事務更新同一個物件的特殊情況下，就會發生髒寫或丟失更新（取決於時機）。
我們看到，有各種不同的方法來防止丟失的更新。隨著寫偏差，我們的選擇更受限制：
* 由於涉及多個物件，單物件的原子操作不起作用。
* 不幸的是，在一些快照隔離的實現中，自動檢測丟失更新對此並沒有幫助。在PostgreSQL的可重複讀，MySQL/InnoDB的可重複讀，Oracle可序列化或SQL Server的快照隔離級別中，都不會自動檢測寫入偏差【23】。自動防止寫入偏差需要真正的可序列化隔離（請參見“[可序列化](#可序列化)”）。
* 某些資料庫允許配置約束，然後由資料庫強制執行（例如，唯一性，外來鍵約束或特定值限制）。但是為了指定至少有一名醫生必須線上，需要一個涉及多個物件的約束。大多數資料庫沒有內建對這種約束的支援，但是你可以使用觸發器，或者物化檢視來實現它們，這取決於不同的資料庫【42】。
* 如果無法使用可序列化的隔離級別，則此情況下的次優選項可能是顯式鎖定事務所依賴的行。在例子中，你可以寫下如下的程式碼：
```sql
BEGIN TRANSACTION;
SELECT * FROM doctors
WHERE on_call = TRUE
AND shift_id = 1234 FOR UPDATE;
UPDATE doctors
SET on_call = FALSE
WHERE name = 'Alice'
AND shift_id = 1234;
COMMIT;
```
* 和以前一樣，`FOR UPDATE`告訴資料庫鎖定返回的所有行用於更新。
#### 寫偏差的更多例子
寫偏差乍看像是一個深奧的問題，但一旦意識到這一點，很容易會注意到更多可能的情況。以下是一些例子：
***會議室預訂系統***
假設你想強制執行，同一時間不能同時在兩個會議室預訂【43】。當有人想要預訂時，首先檢查是否存在相互衝突的預訂（即預訂時間範圍重疊的同一房間），如果沒有找到，則建立會議（請參見示例7-2）[^ix]。
[^ix]: 在PostgreSQL中，您可以使用範圍型別優雅地執行此操作，但在其他資料庫中並未得到廣泛支援。
**例7-2 會議室預訂系統試圖避免重複預訂（在快照隔離下不安全）**
```sql
BEGIN TRANSACTION;
-- 檢查所有現存的與12:00~13:00重疊的預定
SELECT COUNT(*) FROM bookings
WHERE room_id = 123 AND
end_time > '2015-01-01 12:00' AND start_time < '2015-01-01 13:00';
-- 如果之前的查詢返回0
INSERT INTO bookings(room_id, start_time, end_time, user_id)
VALUES (123, '2015-01-01 12:00', '2015-01-01 13:00', 666);
COMMIT;
```
不幸的是，快照隔離並不能防止另一個使用者同時插入衝突的會議。為了確保不會遇到排程衝突，你又需要可序列化的隔離級別了。
***多人遊戲***
在[例7-1]()中，我們使用一個鎖來防止丟失更新（也就是確保兩個玩家不能同時移動同一個棋子）。但是鎖定並不妨礙玩家將兩個不同的棋子移動到棋盤上的相同位置，或者採取其他違反遊戲規則的行為。按照您正在執行的規則型別，也許可以使用唯一約束，否則您很容易發生寫入偏差。
***搶注使用者名稱***
在每個使用者擁有唯一使用者名稱的網站上，兩個使用者可能會嘗試同時建立具有相同使用者名稱的帳戶。可以在事務檢查名稱是否被搶佔，如果沒有則使用該名稱建立賬戶。但是像在前面的例子中那樣，在快照隔離下這是不安全的。幸運的是，唯一約束是一個簡單的解決辦法（第二個事務在提交時會因為違反使用者名稱唯一約束而被中止）。
***防止雙重開支***
允許使用者花錢或積分的服務，需要檢查使用者的支付數額不超過其餘額。可以透過在使用者的帳戶中插入一個試探性的消費專案來實現這一點，列出帳戶中的所有專案，並檢查總和是否為正值【44】。有了寫入偏差，可能會發生兩個支出專案同時插入，一起導致餘額變為負值，但這兩個事務都不會注意到另一個。
#### 導致寫入偏差的幻讀
所有這些例子都遵循類似的模式：
1. 一個`SELECT`查詢找出符合條件的行，並檢查是否符合一些要求。（例如：至少有兩名醫生在值班；不存在對該會議室同一時段的預定；棋盤上的位置沒有被其他棋子佔據；使用者名稱還沒有被搶注；賬戶裡還有足夠餘額）
2. 按照第一個查詢的結果，應用程式碼決定是否繼續。（可能會繼續操作，也可能中止並報錯）
3. 如果應用決定繼續操作，就執行寫入（插入、更新或刪除），並提交事務。
這個寫入的效果改變了步驟2 中的先決條件。換句話說，如果在提交寫入後，重複執行一次步驟1 的SELECT查詢，將會得到不同的結果。因為寫入改變符合搜尋條件的行集（現在少了一個醫生值班，那時候的會議室現在已經被預訂了，棋盤上的這個位置已經被佔據了，使用者名稱已經被搶注，賬戶餘額不夠了）。
這些步驟可能以不同的順序發生。例如可以首先進行寫入，然後進行SELECT查詢，最後根據查詢結果決定是放棄還是提交。
在醫生值班的例子中，在步驟3中修改的行，是步驟1中返回的行之一，所以我們可以透過鎖定步驟1 中的行（`SELECT FOR UPDATE`）來使事務安全並避免寫入偏差。但是其他四個例子是不同的：它們檢查是否**不存在**某些滿足條件的行，寫入會**新增**一個匹配相同條件的行。如果步驟1中的查詢沒有返回任何行，則`SELECT FOR UPDATE`鎖不了任何東西。
這種效應：一個事務中的寫入改變另一個事務的搜尋查詢的結果，被稱為**幻讀**【3】。快照隔離避免了只讀查詢中幻讀，但是在像我們討論的例子那樣的讀寫事務中，幻讀會導致特別棘手的寫入偏差情況。
#### 物化衝突
如果幻讀的問題是沒有物件可以加鎖，也許可以人為地在資料庫中引入一個鎖物件？
例如，在會議室預訂的場景中，可以想象建立一個關於時間槽和房間的表。此表中的每一行對應於特定時間段（例如15分鐘）的特定房間。可以提前插入房間和時間的所有可能組合行（例如接下來的六個月）。
現在，要建立預訂的事務可以鎖定（`SELECT FOR UPDATE`）表中與所需房間和時間段對應的行。在獲得鎖定之後，它可以檢查重疊的預訂並像以前一樣插入新的預訂。請注意，這個表並不是用來儲存預訂相關的資訊——它完全就是一組鎖，用於防止同時修改同一房間和時間範圍內的預訂。
這種方法被稱為**物化衝突（materializing conflicts）**，因為它將幻讀變為資料庫中一組具體行上的鎖衝突【11】。不幸的是，弄清楚如何物化衝突可能很難，也很容易出錯，而讓併發控制機制洩漏到應用資料模型是很醜陋的做法。出於這些原因，如果沒有其他辦法可以實現，物化衝突應被視為最後的手段。在大多數情況下。**可序列化（Serializable）** 的隔離級別是更可取的。
## 可序列化
在本章中，已經看到了幾個易於出現競爭條件的事務例子。**讀已提交**和**快照隔離**級別會阻止某些競爭條件，但不會阻止另一些。我們遇到了一些特別棘手的例子，**寫入偏差**和**幻讀**。這是一個可悲的情況：
- 隔離級別難以理解，並且在不同的資料庫中實現的不一致（例如，“可重複讀”的含義天差地別）。
- 光檢查應用程式碼很難判斷在特定的隔離級別執行是否安全。 特別是在大型應用程式中，您可能並不知道併發發生的所有事情。
- 沒有檢測競爭條件的好工具。原則上來說，靜態分析可能會有幫助【26】，但研究中的技術還沒法實際應用。併發問題的測試是很難的，因為它們通常是非確定性的 —— 只有在倒黴的時機下才會出現問題。
這不是一個新問題，從20世紀70年代以來就一直是這樣了，當時首先引入了較弱的隔離級別【2】。一直以來，研究人員的答案都很簡單：使用**可序列化（serializable）** 的隔離級別！
**可序列化（Serializability）**隔離通常被認為是最強的隔離級別。它保證即使事務可以並行執行，最終的結果也是一樣的，就好像它們沒有任何併發性，連續挨個執行一樣。因此資料庫保證，如果事務在單獨執行時正常執行，則它們在併發執行時繼續保持正確 —— 換句話說，資料庫可以防止**所有**可能的競爭條件。
但如果可序列化隔離級別比弱隔離級別的爛攤子要好得多，那為什麼沒有人見人愛？為了回答這個問題，我們需要看看實現可序列化的選項，以及它們如何執行。目前大多數提供可序列化的資料庫都使用了三種技術之一，本章的剩餘部分將會介紹這些技術。
- 字面意義上地序列順序執行事務（參見“[真的序列執行](#真的序列執行)”）
- **兩相鎖定（2PL, two-phase locking）**，幾十年來唯一可行的選擇。（參見“[兩相鎖定（2PL）](#兩階段鎖定（2PL）)”）
- 樂觀併發控制技術，例如**可序列化的快照隔離（serializable snapshot isolation）**（參閱“[可序列化的快照隔離（SSI）](#序列化快照隔離（SSI）)”
現在將主要在單節點資料庫的背景下討論這些技術；在[第9章](ch9.md)中，我們將研究如何將它們推廣到涉及分散式系統中多個節點的事務。
#### 真的序列執行
避免併發問題的最簡單方法就是完全不要併發：在單個執行緒上按順序一次只執行一個事務。這樣做就完全繞開了檢測/防止事務間衝突的問題，由此產生的隔離，正是可序列化的定義。
儘管這似乎是一個明顯的主意，但資料庫設計人員只是在2007年左右才決定，單執行緒迴圈執行事務是可行的【45】。如果多執行緒併發在過去的30年中被認為是獲得良好效能的關鍵所在，那麼究竟是什麼改變致使單執行緒執行變為可能呢？
兩個進展引發了這個反思：
- RAM足夠便宜了，許多場景現在都可以將完整的活躍資料集儲存在記憶體中。（參閱“[在記憶體中儲存一切](ch3.md#在記憶體中儲存一切)”）。當事務需要訪問的所有資料都在記憶體中時，事務處理的執行速度要比等待資料從磁碟載入時快得多。
- 資料庫設計人員意識到OLTP事務通常很短，而且只進行少量的讀寫操作（參閱“[事務處理或分析？](ch3.md#事務處理還是分析？)”）。相比之下，長時間執行的分析查詢通常是隻讀的，因此它們可以在序列執行迴圈之外的一致快照（使用快照隔離）上執行。
序列執行事務的方法在VoltDB/H-Store，Redis和Datomic中實現【46,47,48】。設計用於單執行緒執行的系統有時可以比支援併發的系統更好，因為它可以避免鎖的協調開銷。但是其吞吐量僅限於單個CPU核的吞吐量。為了充分利用單一執行緒，需要與傳統形式不同的結構的事務。
#### 在儲存過程中封裝事務
​ 在資料庫的早期階段，意圖是資料庫事務可以包含整個使用者活動流程。例如，預訂機票是一個多階段的過程（搜尋路線，票價和可用座位，決定行程，在每段行程的航班上訂座，輸入乘客資訊，付款）。資料庫設計者認為，如果整個過程是一個事務，那麼它就可以被原子化地執行。
​ 不幸的是，人類做出決定和迴應的速度非常緩慢。如果資料庫事務需要等待來自使用者的輸入，則資料庫需要支援潛在的大量併發事務，其中大部分是空閒的。大多數資料庫不能高效完成這項工作，因此幾乎所有的OLTP應用程式都避免在事務中等待互動式的使用者輸入，以此來保持事務的簡短。在Web上，這意味著事務在同一個HTTP請求中被提交——一個事務不會跨越多個請求。一個新的HTTP請求開始一個新的事務。
​ 即使人類已經找到了關鍵路徑，事務仍然以互動式的客戶端/伺服器風格執行，一次一個語句。應用程式進行查詢，讀取結果，可能根據第一個查詢的結果進行另一個查詢，依此類推。查詢和結果在應用程式程式碼（在一臺機器上執行）和資料庫伺服器（在另一臺機器上）之間來回傳送。
​ 在這種互動式的事務方式中，應用程式和資料庫之間的網路通訊耗費了大量的時間。如果不允許在資料庫中進行併發處理，且一次只處理一個事務，則吞吐量將會非常糟糕，因為資料庫大部分的時間都花費在等待應用程式發出當前事務的下一個查詢。在這種資料庫中，為了獲得合理的效能，需要同時處理多個事務。
​ 出於這個原因，具有單執行緒序列事務處理的系統不允許互動式的多語句事務。取而代之，應用程式必須提前將整個事務程式碼作為儲存過程提交給資料庫。這些方法之間的差異如[圖7-9](../img/fig7-9.png) 所示。如果事務所需的所有資料都在記憶體中，則儲存過程可以非常快地執行，而不用等待任何網路或磁碟I/O。
![](../img/fig7-9.png)
**圖7-9 互動式事務和儲存過程之間的區別（使用圖7-8的示例事務）**
#### 儲存過程的優點和缺點
儲存過程在關係型資料庫中已經存在了一段時間了，自1999年以來它們一直是SQL標準（SQL/PSM）的一部分。出於各種原因，它們的名聲有點不太好：
- 每個資料庫廠商都有自己的儲存過程語言（Oracle有PL/SQL，SQL Server有T-SQL，PostgreSQL有PL/pgSQL等）。這些語言並沒有跟上通用程式語言的發展，所以從今天的角度來看，它們看起來相當醜陋和陳舊，而且缺乏大多數程式語言中能找到的庫的生態系統。
- 與應用伺服器相，比在資料庫中執行的管理困難，除錯困難，版本控制和部署起來也更為尷尬，更難測試，更難和用於監控的指標收集系統相整合。
- 資料庫通常比應用伺服器對效能敏感的多，因為單個數據庫例項通常由許多應用伺服器共享。資料庫中一個寫得不好的儲存過程（例如，佔用大量記憶體或CPU時間）會比在應用伺服器中相同的程式碼造成更多的麻煩。
但是這些問題都是可以克服的。現代的儲存過程實現放棄了PL/SQL，而是使用現有的通用程式語言：VoltDB使用Java或Groovy，Datomic使用Java或Clojure，而Redis使用Lua。
**儲存過程與記憶體儲存**，使得在單個執行緒上執行所有事務變得可行。由於不需要等待I/O，且避免了併發控制機制的開銷，它們可以在單個執行緒上實現相當好的吞吐量。
VoltDB還使用儲存過程進行復制：但不是將事務的寫入結果從一個節點複製到另一個節點，而是在每個節點上執行相同的儲存過程。因此VoltDB要求儲存過程是**確定性的**（在不同的節點上執行時，它們必須產生相同的結果）。舉個例子，如果事務需要使用當前的日期和時間，則必須透過特殊的確定性API來實現。
#### 分割槽
順序執行所有事務使併發控制簡單多了，但資料庫的事務吞吐量被限制為單機單核的速度。只讀事務可以使用快照隔離在其它地方執行，但對於寫入吞吐量較高的應用，單執行緒事務處理器可能成為一個嚴重的瓶頸。
為了擴充套件到多個CPU核心和多個節點，可以對資料進行分割槽（參見[第6章](ch6.md)），在VoltDB中支援這樣做。如果你可以找到一種對資料集進行分割槽的方法，以便每個事務只需要在單個分割槽中讀寫資料，那麼每個分割槽就可以擁有自己獨立執行的事務處理執行緒。在這種情況下可以為每個分割槽指派一個獨立的CPU核，事務吞吐量就可以與CPU核數保持線性擴充套件【47】。
但是，對於需要訪問多個分割槽的任何事務，資料庫必須在觸及的所有分割槽之間協調事務。儲存過程需要跨越所有分割槽鎖定執行，以確保整個系統的可序列性。
由於跨分割槽事務具有額外的協調開銷，所以它們比單分割槽事務慢得多。 VoltDB報告的吞吐量大約是每秒1000個跨分割槽寫入，比單分割槽吞吐量低幾個數量級，並且不能透過增加更多的機器來增加【49】。
事務是否可以是劃分至單個分割槽很大程度上取決於應用資料的結構。簡單的鍵值資料通常可以非常容易地進行分割槽，但是具有多個二級索引的資料可能需要大量的跨分割槽協調（參閱“[分片與次級索引](ch6.md#分片與次級索引)”）。
#### 序列執行小結
在特定約束條件下，真的序列執行事務，已經成為一種實現可序列化隔離等級的可行辦法。
- 每個事務都必須小而快，只要有一個緩慢的事務，就會拖慢所有事務處理。
- 僅限於活躍資料集可以放入記憶體的情況。很少訪問的資料可能會被移動到磁碟，但如果需要在單執行緒執行的事務中訪問，系統就會變得非常慢[^x]。
- 寫入吞吐量必須低到能在單個CPU核上處理，如若不然，事務需要能劃分至單個分割槽，且不需要跨分割槽協調。
- 跨分割槽事務是可能的，但是它們的使用程度有很大的限制。
[^x]: 如果事務需要訪問不在記憶體中的資料，最好的解決方案可能是中止事務，非同步地將資料提取到記憶體中，同時繼續處理其他事務，然後在資料載入完畢時重新啟動事務。這種方法被稱為**反快取（anti-caching）**，正如前面在第88頁“將所有內容儲存在記憶體”中所述。
### 兩階段鎖定（2PL）
大約30年來，在資料庫中只有一種廣泛使用的序列化演算法：**兩階段鎖定（2PL，two-phase locking）** [^xi]
[^xi]: 有時也稱為**嚴格兩階段鎖定（SS2PL, strict two-phase locking）**，以便和其他2PL變體區分。
> #### 2PL不是2PC
>
> 請注意，雖然兩階段鎖定（2PL）聽起來非常類似於兩階段提交（2PC），但它們是完全不同的東西。我們將在第9章討論2PC。
之前我們看到鎖通常用於防止髒寫（參閱“[沒有髒寫](沒有髒寫)”一節）：如果兩個事務同時嘗試寫入同一個物件，則鎖可確保第二個寫入必須等到第一個寫入完成事務（中止或提交），然後才能繼續。
兩階段鎖定定類似，但使鎖的要求更強。只要沒有寫入，就允許多個事務同時讀取同一個物件。但物件只要有寫入（修改或刪除），就需要**獨佔訪問（exclusive access）** 許可權：
- 如果事務A讀取了一個物件，並且事務B想要寫入該物件，那麼B必須等到A提交或中止才能繼續。 （這確保B不能在A底下意外地改變物件。）
- 如果事務A寫入了一個物件，並且事務B想要讀取該物件，則B必須等到A提交或中止才能繼續。 （像[圖7-1]()那樣讀取舊版本的物件在2PL下是不可接受的。）
在2PL中，寫入不僅會阻塞其他寫入，也會阻塞讀，反之亦然。快照隔離使得**讀不阻塞寫，寫也不阻塞讀**（參閱“[實現快照隔離](#實現快照隔離)”），這是2PL和快照隔離之間的關鍵區別。另一方面，因為2PL提供了可序列化的性質，它可以防止早先討論的所有競爭條件，包括丟失更新和寫入偏差。
#### 實現兩階段鎖
2PL用於MySQL（InnoDB）和SQL Server中的可序列化隔離級別，以及DB2中的可重複讀隔離級別【23,36】。
讀與寫的阻塞是透過為資料庫中每個物件新增鎖來實現的。鎖可以處於**共享模式（shared mode）**或**獨佔模式（exclusive mode）**。鎖使用如下：
- 若事務要讀取物件，則須先以共享模式獲取鎖。允許多個事務同時持有共享鎖。但如果另一個事務已經在物件上持有排它鎖，則這些事務必須等待。
- 若事務要寫入一個物件，它必須首先以獨佔模式獲取該鎖。沒有其他事務可以同時持有鎖（無論是共享模式還是獨佔模式），所以如果物件上存在任何鎖，該事務必須等待。
- 如果事務先讀取再寫入物件，則它可能會將其共享鎖升級為獨佔鎖。升級鎖的工作與直接獲得排他鎖相同。
- 事務獲得鎖之後，必須繼續持有鎖直到事務結束（提交或中止）。這就是“兩階段”這個名字的來源：第一階段（當事務正在執行時）獲取鎖，第二階段（在事務結束時）釋放所有的鎖。
由於使用了這麼多的鎖，因此很可能會發生：事務A等待事務B釋放它的鎖，反之亦然。這種情況叫做**死鎖（Deadlock）**。資料庫會自動檢測事務之間的死鎖，並中止其中一個，以便另一個繼續執行。被中止的事務需要由應用程式重試。
#### 兩階段鎖定的效能
兩階段鎖定的巨大缺點，以及70年代以來沒有被所有人使用的原因，是其效能問題。兩階段鎖定下的事務吞吐量與查詢響應時間要比弱隔離級別下要差得多。
這一部分是由於獲取和釋放所有這些鎖的開銷，但更重要的是由於併發性的降低。按照設計，如果兩個併發事務試圖做任何可能導致競爭條件的事情，那麼必須等待另一個完成。
傳統的關係資料庫不限制事務的持續時間，因為它們是為等待人類輸入的互動式應用而設計的。因此，當一個事務需要等待另一個事務時，等待的時長並沒有限制。即使你保證所有的事務都很短，如果有多個事務想要訪問同一個物件，那麼可能會形成一個佇列，所以事務可能需要等待幾個其他事務才能完成。
因此，執行2PL的資料庫可能具有相當不穩定的延遲，如果在工作負載中存在爭用，那麼可能高百分位點處的響應會非常的慢（參閱“[描述效能](ch1.md#描述效能)”）。可能只需要一個緩慢的事務，或者一個訪問大量資料並獲取許多鎖的事務，就能把系統的其他部分拖慢，甚至迫使系統停機。當需要穩健的操作時，這種不穩定性是有問題的。
基於鎖實現的讀已提交隔離級別可能發生死鎖，但在基於2PL實現的可序列化隔離級別中，它們會出現的頻繁的多（取決於事務的訪問模式）。這可能是一個額外的效能問題：當事務由於死鎖而被中止並被重試時，它需要從頭重做它的工作。如果死鎖很頻繁，這可能意味著巨大的浪費。
#### 謂詞鎖
在前面關於鎖的描述中，我們掩蓋了一個微妙而重要的細節。在“[導致寫入偏差的幻讀](#導致寫入偏差的幻讀)”中，我們討論了**幻讀（phantoms）**的問題。即一個事務改變另一個事務的搜尋查詢的結果。具有可序列化隔離級別的資料庫必須防止**幻讀**。
在會議室預訂的例子中，這意味著如果一個事務在某個時間視窗內搜尋了一個房間的現有預訂（見[例7-2]()），則另一個事務不能同時插入或更新同一時間視窗與同一房間的另一個預訂 （可以同時插入其他房間的預訂，或在不影響另一個預定的條件下預定同一房間的其他時間段）。
如何實現這一點？從概念上講，我們需要一個**謂詞鎖（predicate lock）**【3】。它類似於前面描述的共享/排它鎖，但不屬於特定的物件（例如，表中的一行），它屬於所有符合某些搜尋條件的物件，如：
```sql
SELECT * FROM bookings
WHERE room_id = 123 AND
end_time > '2018-01-01 12:00' AND
start_time < '2018-01-01 13:00';
```
謂詞鎖限制訪問，如下所示：
- 如果事務A想要讀取匹配某些條件的物件，就像在這個 `SELECT` 查詢中那樣，它必須獲取查詢條件上的**共享謂詞鎖（shared-mode predicate lock）**。如果另一個事務B持有任何滿足這一查詢條件物件的排它鎖，那麼A必須等到B釋放它的鎖之後才允許進行查詢。
- 如果事務A想要插入，更新或刪除任何物件，則必須首先檢查舊值或新值是否與任何現有的謂詞鎖匹配。如果事務B持有匹配的謂詞鎖，那麼A必須等到B已經提交或中止後才能繼續。
這裡的關鍵思想是，謂詞鎖甚至適用於資料庫中尚不存在，但將來可能會新增的物件（幻象）。如果兩階段鎖定包含謂詞鎖，則資料庫將阻止所有形式的寫入偏差和其他競爭條件，因此其隔離實現了可序列化。
#### 索引範圍鎖
不幸的是謂詞鎖效能不佳：**如果活躍事務持有很多鎖，檢查匹配的鎖會非常耗時。**因此，大多數使用2PL的資料庫實際上實現了索引範圍鎖（也稱為**間隙鎖（next-key locking）**），這是一個簡化的近似版謂詞鎖【41,50】。
透過使謂詞匹配到一個更大的集合來簡化謂詞鎖是安全的。例如，如果你有在中午和下午1點之間預訂123號房間的謂詞鎖，則鎖定123號房間的所有時間段，或者鎖定12:00~13:00時間段的所有房間（不只是123號房間）是一個安全的近似，因為任何滿足原始謂詞的寫入也一定會滿足這種更鬆散的近似。
在房間預訂資料庫中，您可能會在`room_id`列上有一個索引，並且/或者在`start_time` 和 `end_time`上有索引（否則前面的查詢在大型資料庫上的速度會非常慢）：
- 假設您的索引位於`room_id`上，並且資料庫使用此索引查詢123號房間的現有預訂。現在資料庫可以簡單地將共享鎖附加到這個索引項上，指示事務已搜尋123號房間用於預訂。
- 或者，如果資料庫使用基於時間的索引來查詢現有預訂，那麼它可以將共享鎖附加到該索引中的一系列值，指示事務已經將12:00~13:00時間段標記為用於預定。
無論哪種方式，搜尋條件的近似值都附加到其中一個索引上。現在，如果另一個事務想要插入，更新或刪除同一個房間和/或重疊時間段的預訂，則它將不得不更新索引的相同部分。在這樣做的過程中，它會遇到共享鎖，它將被迫等到鎖被釋放。
這種方法能夠有效防止幻讀和寫入偏差。索引範圍鎖並不像謂詞鎖那樣精確（它們可能會鎖定更大範圍的物件，而不是維持可序列化所必需的範圍），但是由於它們的開銷較低，所以是一個很好的折衷。
如果沒有可以掛載間隙鎖的索引，資料庫可以退化到使用整個表上的共享鎖。這對效能不利，因為它會阻止所有其他事務寫入表格，但這是一個安全的回退位置。
### 序列化快照隔離（SSI）
本章描繪了資料庫中併發控制的黯淡畫面。一方面，我們實現了效能不好（2PL）或者擴充套件性不好（序列執行）的可序列化隔離級別。另一方面，我們有效能良好的弱隔離級別，但容易出現各種競爭條件（丟失更新，寫入偏差，幻讀等）。序列化的隔離級別和高效能是從根本上相互矛盾的嗎？
也許不是：一個稱為**可序列化快照隔離（SSI, serializable snapshot isolation）** 的演算法是非常有前途的。它提供了完整的可序列化隔離級別，但與快照隔離相比只有只有很小的效能損失。 SSI是相當新的：它在2008年首次被描述【40】，並且是Michael Cahill的博士論文【51】的主題。
今天，SSI既用於單節點資料庫（PostgreSQL9.1 以後的可序列化隔離級別）和分散式資料庫（FoundationDB使用類似的演算法）。由於SSI與其他併發控制機制相比還很年輕，還處於在實踐中證明自己表現的階段。但它有可能因為足夠快而在未來成為新的預設選項。
#### 悲觀與樂觀的併發控制
兩階段鎖是一種所謂的**悲觀併發控制機制（pessimistic）** ：它是基於這樣的原則：如果有事情可能出錯（如另一個事務所持有的鎖所表示的），最好等到情況安全後再做任何事情。這就像互斥，用於保護多執行緒程式設計中的資料結構。
從某種意義上說，序列執行可以稱為悲觀到了極致：在事務持續期間，每個事務對整個資料庫（或資料庫的一個分割槽）具有排它鎖，作為對悲觀的補償，我們讓每筆事務執行得非常快，所以只需要短時間持有“鎖”。
相比之下，**序列化快照隔離**是一種**樂觀（optimistic）** 的併發控制技術。在這種情況下，樂觀意味著，如果存在潛在的危險也不阻止事務，而是繼續執行事務，希望一切都會好起來。當一個事務想要提交時，資料庫檢查是否有什麼不好的事情發生（即隔離是否被違反）；如果是的話，事務將被中止，並且必須重試。只有可序列化的事務才被允許提交。
樂觀併發控制是一個古老的想法【52】，其優點和缺點已經爭論了很長時間【53】。如果存在很多**爭用（contention）**（很多事務試圖訪問相同的物件），則表現不佳，因為這會導致很大一部分事務需要中止。如果系統已經接近最大吞吐量，來自重試事務的額外負載可能會使效能變差。
但是，如果有足夠的備用容量，並且事務之間的爭用不是太高，樂觀的併發控制技術往往比悲觀的要好。可交換的原子操作可以減少爭用：例如，如果多個事務同時要增加一個計數器，那麼應用增量的順序（只要計數器不在同一個事務中讀取）就無關緊要了，所以併發增量可以全部應用且無需衝突。
顧名思義，SSI基於快照隔離——也就是說，事務中的所有讀取都是來自資料庫的一致性快照（參見“[快照隔離和可重複讀取](#快照隔離和可重複讀)”）。與早期的樂觀併發控制技術相比這是主要的區別。在快照隔離的基礎上，SSI添加了一種演算法來檢測寫入之間的序列化衝突，並確定要中止哪些事務。
#### 基於過時前提的決策
先前討論了快照隔離中的寫入偏差（參閱“[寫入偏差和幻像](#寫入偏差與幻讀)”）時，我們觀察到一個迴圈模式：事務從資料庫讀取一些資料，檢查查詢的結果，並根據它看到的結果決定採取一些操作（寫入資料庫）。但是，在快照隔離的情況下，原始查詢的結果在事務提交時可能不再是最新的，因為資料可能在同一時間被修改。
換句話說，事務基於一個**前提（premise）** 採取行動（事務開始時候的事實，例如：“目前有兩名醫生正在值班”）。之後當事務要提交時，原始資料可能已經改變——前提可能不再成立。
當應用程式進行查詢時（例如，“當前有多少醫生正在值班？”），資料庫不知道應用邏輯如何使用該查詢結果。在這種情況下為了安全，資料庫需要假設任何對該結果集的變更都可能會使該事務中的寫入變得無效。 換而言之，事務中的查詢與寫入可能存在因果依賴。為了提供可序列化的隔離級別，如果事務在過時的前提下執行操作，資料庫必須能檢測到這種情況，並中止事務。
資料庫如何知道查詢結果是否可能已經改變？有兩種情況需要考慮：
- 檢測對舊MVCC物件版本的讀取（讀之前存在未提交的寫入）
- 檢測影響先前讀取的寫入（讀之後發生寫入）
#### 檢測舊MVCC讀取
回想一下，快照隔離通常是透過多版本併發控制（MVCC；見[圖7-10]()）來實現的。當一個事務從MVCC資料庫中的一致快照讀時，它將忽略取快照時尚未提交的任何其他事務所做的寫入。在[圖7-10]()中，事務43 認為Alice的 `on_call = true` ，因為事務42（修改Alice的待命狀態）未被提交。然而，在事務43想要提交時，事務42 已經提交。這意味著在讀一致性快照時被忽略的寫入已經生效，事務43 的前提不再為真。
![](../img/fig7-10.png)
**圖7-10 檢測事務何時從MVCC快照讀取過時的值**
為了防止這種異常，資料庫需要跟蹤一個事務由於MVCC可見性規則而忽略另一個事務的寫入。當事務想要提交時，資料庫檢查是否有任何被忽略的寫入現在已經被提交。如果是這樣，事務必須中止。
為什麼要等到提交？當檢測到陳舊的讀取時，為什麼不立即中止事務43 ？因為如果事務43 是隻讀事務，則不需要中止，因為沒有寫入偏差的風險。當事務43 進行讀取時，資料庫還不知道事務是否要稍後執行寫操作。此外，事務42 可能在事務43 被提交的時候中止或者可能仍然未被提交，因此讀取可能終究不是陳舊的。透過避免不必要的中止，SSI 保留快照隔離對從一致快照中長時間執行的讀取的支援。
#### 檢測影響之前讀取的寫入
第二種情況要考慮的是另一個事務在讀取資料之後修改資料。這種情況如[圖7-11](../img/fig7-11.png)所示。
![](../img/fig7-11.png)
**圖7-11 在可序列化快照隔離中，檢測一個事務何時修改另一個事務的讀取。**
在兩階段鎖定的上下文中，我們討論了[索引範圍鎖]()（請參閱“[索引範圍鎖]()”），它允許資料庫鎖定與某個搜尋查詢匹配的所有行的訪問權，例如 `WHERE shift_id = 1234`。可以在這裡使用類似的技術，除了SSI鎖不會阻塞其他事務。
在[圖7-11]()中，事務42 和43 都在班次1234 查詢值班醫生。如果在`shift_id`上有索引，則資料庫可以使用索引項1234 來記錄事務42 和43 讀取這個資料的事實。 （如果沒有索引，這個資訊可以在表級別進行跟蹤）。這個資訊只需要保留一段時間：在一個事務完成（提交或中止），並且所有的併發事務完成之後，資料庫就可以忘記它讀取的資料了。
當事務寫入資料庫時，它必須在索引中查詢最近曾讀取受影響資料的其他事務。這個過程類似於在受影響的鍵範圍上獲取寫鎖，但鎖並不會阻塞事務指導其他讀事務完成，而是像警戒線一樣只是簡單通知其他事務：你們讀過的資料可能不是最新的啦。
在[圖7-11]()中，事務43 通知事務42 其先前讀已過時，反之亦然。事務42首先提交併成功，儘管事務43 的寫影響了42 ，但因為事務43 尚未提交，所以寫入尚未生效。然而當事務43 想要提交時，來自事務42 的衝突寫入已經被提交，所以事務43 必須中止。
#### 可序列化的快照隔離的效能
與往常一樣，許多工程細節會影響演算法的實際表現。例如一個權衡是跟蹤事務的讀取和寫入的**粒度（granularity）**。如果資料庫詳細地跟蹤每個事務的活動（細粒度），那麼可以準確地確定哪些事務需要中止，但是簿記開銷可能變得很顯著。簡略的跟蹤速度更快（粗粒度），但可能會導致更多不必要的事務中止。
在某些情況下，事務可以讀取被另一個事務覆蓋的資訊：這取決於發生了什麼，有時可以證明執行結果無論如何都是可序列化的。 PostgreSQL使用這個理論來減少不必要的中止次數【11,41】。
與兩階段鎖定相比，可序列化快照隔離的最大優點是一個事務不需要阻塞等待另一個事務所持有的鎖。就像在快照隔離下一樣，寫不會阻塞讀，反之亦然。這種設計原則使得查詢延遲更可預測，變數更少。特別是，只讀查詢可以執行在一致的快照上，而不需要任何鎖定，這對於讀取繁重的工作負載非常有吸引力。
與序列執行相比，可序列化快照隔離並不侷限於單個CPU核的吞吐量：FoundationDB將檢測到的序列化衝突分佈在多臺機器上，允許擴充套件到很高的吞吐量。即使資料可能跨多臺機器進行分割槽，事務也可以在保證可序列化隔離等級的同時讀寫多個分割槽中的資料【54】。
中止率顯著影響SSI的整體表現。例如，長時間讀取和寫入資料的事務很可能會發生衝突並中止，因此SSI要求同時讀寫的事務儘量短（只讀長事務可能沒問題）。對於慢事務，SSI可能比兩階段鎖定或序列執行更不敏感。
## 本章小結
事務是一個抽象層，允許應用程式假裝某些併發問題和某些型別的硬體和軟體故障不存在。各式各樣的錯誤被簡化為一種簡單情況：**事務中止（transaction abort）**，而應用需要的僅僅是重試。
在本章中介紹了很多問題，事務有助於防止這些問題發生。並非所有應用都易受此類問題影響：具有非常簡單訪問模式的應用（例如每次讀寫單條記錄）可能無需事務管理。但是對於更復雜的訪問模式，事務可以大大減少需要考慮的潛在錯誤情景數量。
如果沒有事務處理，各種錯誤情況（程序崩潰，網路中斷，停電，磁碟已滿，意外併發等）意味著資料可能以各種方式變得不一致。例如，非規範化的資料可能很容易與源資料不同步。如果沒有事務處理，就很難推斷複雜的互動訪問可能對資料庫造成的影響。
本章深入討論了**併發控制**的話題。我們討論了幾個廣泛使用的隔離級別，特別是**讀已提交**，**快照隔離**（有時稱為可重複讀）和**可序列化**。並透過研究競爭條件的各種例子，來描述這些隔離等級：
***髒讀***
​ 一個客戶端讀取到另一個客戶端尚未提交的寫入。**讀已提交**或更強的隔離級別可以防止髒讀。
***髒寫***
​ 一個客戶端覆蓋寫入了另一個客戶端尚未提交的寫入。幾乎所有的事務實現都可以防止髒寫。
***讀取偏差（不可重複讀）***
​ 在同一個事務中，客戶端在不同的時間點會看見資料庫的不同狀態。**快照隔離**經常用於解決這個問題，它允許事務從一個特定時間點的一致性快照中讀取資料。快照隔離通常使用**多版本併發控制（MVCC）** 來實現。
***更新丟失***
​ 兩個客戶端同時執行**讀取-修改-寫入序列**。其中一個寫操作，在沒有合併另一個寫入變更情況下，直接覆蓋了另一個寫操作的結果。所以導致資料丟失。快照隔離的一些實現可以自動防止這種異常，而另一些實現則需要手動鎖定（`SELECT FOR UPDATE`）。
***寫偏差***
​ 一個事務讀取一些東西，根據它所看到的值作出決定，並將該決定寫入資料庫。但是，寫入時，該決定的前提不再是真實的。只有可序列化的隔離才能防止這種異常。
***幻讀***
​ 事務讀取符合某些搜尋條件的物件。另一個客戶端進行寫入，影響搜尋結果。快照隔離可以防止直接的幻像讀取，但是寫入偏差上下文中的幻讀需要特殊處理，例如索引範圍鎖定。
​弱隔離級別可以防止其中一些異常情況，此外讓應用程式開發人員手動處理剩餘那些（例如，使用顯式鎖定）。只有可序列化的隔離才能防範所有這些問題。我們討論了實現可序列化事務的三種不同方法：
***字面意義上的序列執行***
​ 如果每個事務的執行速度非常快，並且事務吞吐量足夠低，足以在單個CPU核上處理，這是一個簡單而有效的選擇。
***兩階段鎖定***
​ 數十年來，兩階段鎖定一直是實現可序列化的標準方式，但是許多應用出於效能問題的考慮避免使用它。
***可序列化快照隔離（SSI）***
​ 一個相當新的演算法，避免了先前方法的大部分缺點。它使用樂觀的方法，允許事務執行而無需阻塞。當一個事務想要提交時，它會進行檢查，如果執行不可序列化，事務就會被中止。
​ 本章中的示例主要是在關係資料模型的上下文中。使用關係資料模型。但是，正如在討論中，無論使用哪種資料模型，如“**[多物件事務的需求](#多物件事務的需求)**”中所討論的，事務都是重要的資料庫功能。
​ 本章主要是在單機資料庫的上下文中，探討了各種概念與想法。分散式資料庫中的事務，則引入了一系列新的困難挑戰，將在接下來的兩章中討論。
## 參考文獻
1. Donald D. Chamberlin, Morton M. Astrahan, Michael W. Blasgen, et al.: “[A History and Evaluation of System R](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.84.348&rep=rep1&type=pdf),” *Communications of the ACM*, volume 24, number 10, pages 632–646, October 1981.
[doi:10.1145/358769.358784](http://dx.doi.org/10.1145/358769.358784)
2. Jim N. Gray, Raymond A. Lorie, Gianfranco R. Putzolu, and Irving L. Traiger: “[Granularity of Locks and Degrees of Consistency in a Shared Data Base](http://citeseer.ist.psu.edu/viewdoc/download?doi=10.1.1.92.8248&rep=rep1&type=pdf),” in *Modelling in Data Base Management Systems: Proceedings of the IFIP Working Conference on Modelling in Data Base Management Systems*, edited by G. M. Nijssen, pages 364–394, Elsevier/North Holland Publishing, 1976. Also in *Readings in Database Systems*, 4th edition, edited by Joseph M. Hellerstein and Michael Stonebraker, MIT Press, 2005. ISBN: 978-0-262-69314-1
3. Kapali P. Eswaran, Jim N. Gray, Raymond A. Lorie, and Irving L. Traiger: “[The Notions of Consistency and Predicate Locks in a Database System](http://research.microsoft.com/en-us/um/people/gray/papers/On%20the%20Notions%20of%20Consistency%20and%20Predicate%20Locks%20in%20a%20Database%20System%20CACM.pdf),” *Communications of the ACM*, volume 19, number 11, pages 624–633, November 1976.
4. “[ACID Transactions Are Incredibly Helpful](http://web.archive.org/web/20150320053809/https://foundationdb.com/acid-claims),” FoundationDB, LLC, 2013.
5. John D. Cook: “[ACID Versus BASE for Database Transactions](http://www.johndcook.com/blog/2009/07/06/brewer-cap-theorem-base/),” *johndcook.com*, July 6, 2009.
6. Gavin Clarke: “[NoSQL's CAP Theorem Busters: We Don't Drop ACID](http://www.theregister.co.uk/2012/11/22/foundationdb_fear_of_cap_theorem/),” *theregister.co.uk*, November 22, 2012.
7. Theo Härder and Andreas Reuter: “[Principles of Transaction-Oriented Database Recovery](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.87.2812&rep=rep1&type=pdf),” *ACM Computing Surveys*, volume 15, number 4, pages 287–317, December 1983. [doi:10.1145/289.291](http://dx.doi.org/10.1145/289.291)
8. Peter Bailis, Alan Fekete, Ali Ghodsi, et al.: “[HAT, not CAP: Towards Highly Available Transactions](http://www.bailis.org/papers/hat-hotos2013.pdf),”
at *14th USENIX Workshop on Hot Topics in Operating Systems* (HotOS), May 2013.
9. Armando Fox, Steven D. Gribble, Yatin Chawathe, et al.: “[Cluster-Based Scalable Network Services](http://www.cs.berkeley.edu/~brewer/cs262b/TACC.pdf),” at
*16th ACM Symposium on Operating Systems Principles* (SOSP), October 1997.
10. Philip A. Bernstein, Vassos Hadzilacos, and Nathan Goodman: [*Concurrency Control and Recovery in Database Systems*](http://research.microsoft.com/en-us/people/philbe/ccontrol.aspx). Addison-Wesley, 1987. ISBN: 978-0-201-10715-9, available online at *research.microsoft.com*.
11. Alan Fekete, Dimitrios Liarokapis, Elizabeth O'Neil, et al.: “[Making Snapshot Isolation Serializable](https://www.cse.iitb.ac.in/infolab/Data/Courses/CS632/2009/Papers/p492-fekete.pdf),” *ACM Transactions on Database Systems*, volume 30, number 2, pages 492–528, June 2005.
[doi:10.1145/1071610.1071615](http://dx.doi.org/10.1145/1071610.1071615)
12. Mai Zheng, Joseph Tucek, Feng Qin, and Mark Lillibridge: “[Understanding the Robustness of SSDs Under Power Fault](https://www.usenix.org/system/files/conference/fast13/fast13-final80.pdf),” at *11th USENIX Conference on File and Storage Technologies* (FAST), February 2013.
13. Laurie Denness: “[SSDs: A Gift and a Curse](https://laur.ie/blog/2015/06/ssds-a-gift-and-a-curse/),” *laur.ie*, June 2, 2015.
14. Adam Surak: “[When Solid State Drives Are Not That Solid](https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/),” *blog.algolia.com*, June 15, 2015.
15. Thanumalayan Sankaranarayana Pillai, Vijay Chidambaram, Ramnatthan Alagappan, et al.: “[All File Systems Are Not Created Equal: On the Complexity of Crafting Crash-Consistent Applications](http://research.cs.wisc.edu/wind/Publications/alice-osdi14.pdf),” at *11th USENIX Symposium on Operating Systems Design and Implementation* (OSDI),
October 2014.
16. Chris Siebenmann: “[Unix's File Durability Problem](https://utcc.utoronto.ca/~cks/space/blog/unix/FileSyncProblem),” *utcc.utoronto.ca*, April 14, 2016.
17. Lakshmi N. Bairavasundaram, Garth R. Goodson, Bianca Schroeder, et al.: “[An Analysis of Data Corruption in the Storage Stack](http://research.cs.wisc.edu/adsl/Publications/corruption-fast08.pdf),” at *6th USENIX Conference on File and Storage Technologies* (FAST), February 2008.
18. Bianca Schroeder, Raghav Lagisetty, and Arif Merchant: “[Flash Reliability in Production: The Expected and the Unexpected](https://www.usenix.org/conference/fast16/technical-sessions/presentation/schroeder),” at *14th USENIX Conference on File and Storage Technologies* (FAST), February 2016.
19. Don Allison: “[SSD Storage – Ignorance of Technology Is No Excuse](https://blog.korelogic.com/blog/2015/03/24),” *blog.korelogic.com*, March 24, 2015.
20. Dave Scherer: “[Those Are Not Transactions (Cassandra 2.0)](http://web.archive.org/web/20150526065247/http://blog.foundationdb.com/those-are-not-transactions-cassandra-2-0),” *blog.foundationdb.com*, September 6, 2013.
21. Kyle Kingsbury: “[Call Me Maybe: Cassandra](http://aphyr.com/posts/294-call-me-maybe-cassandra/),” *aphyr.com*, September 24, 2013.
22. “[ACID Support in Aerospike](http://www.aerospike.com/docs/architecture/assets/AerospikeACIDSupport.pdf),” Aerospike, Inc., June 2014.
23. Martin Kleppmann: “[Hermitage: Testing the 'I' in ACID](http://martin.kleppmann.com/2014/11/25/hermitage-testing-the-i-in-acid.html),” *martin.kleppmann.com*, November 25, 2014.
24. Tristan D'Agosta: “[BTC Stolen from Poloniex](https://bitcointalk.org/index.php?topic=499580),” *bitcointalk.org*, March 4, 2014.
25. bitcointhief2: “[How I Stole Roughly 100 BTC from an Exchange and How I Could Have Stolen More!](http://www.reddit.com/r/Bitcoin/comments/1wtbiu/how_i_stole_roughly_100_btc_from_an_exchange_and/),” *reddit.com*, February 2, 2014.
26. Sudhir Jorwekar, Alan Fekete, Krithi Ramamritham, and S. Sudarshan: “[Automating the Detection of Snapshot Isolation Anomalies](http://www.vldb.org/conf/2007/papers/industrial/p1263-jorwekar.pdf),” at *33rd International Conference on Very Large Data Bases* (VLDB), September 2007.
27. Michael Melanson: “[Transactions: The Limits of Isolation](http://www.michaelmelanson.net/2014/03/20/transactions/),” *michaelmelanson.net*, March 20, 2014.
28. Hal Berenson, Philip A. Bernstein, Jim N. Gray, et al.: “[A Critique of ANSI SQL Isolation Levels](http://research.microsoft.com/pubs/69541/tr-95-51.pdf),”
at *ACM International Conference on Management of Data* (SIGMOD), May 1995.
29. Atul Adya: “[Weak Consistency: A Generalized Theory and Optimistic Implementations for Distributed Transactions](http://pmg.csail.mit.edu/papers/adya-phd.pdf),” PhD Thesis, Massachusetts Institute of Technology, March 1999.
30. Peter Bailis, Aaron Davidson, Alan Fekete, et al.: “[Highly Available Transactions: Virtues and Limitations (Extended Version)](http://arxiv.org/pdf/1302.0309.pdf),” at *40th International Conference on Very Large Data Bases* (VLDB), September 2014.
31. Bruce Momjian: “[MVCC Unmasked](http://momjian.us/main/presentations/internals.html#mvcc),” *momjian.us*, July 2014.
32. Annamalai Gurusami: “[Repeatable Read Isolation Level in InnoDB – How Consistent Read View Works](https://blogs.oracle.com/mysqlinnodb/entry/repeatable_read_isolation_level_in),” *blogs.oracle.com*, January 15, 2013.
33. Nikita Prokopov: “[Unofficial Guide to Datomic Internals](http://tonsky.me/blog/unofficial-guide-to-datomic-internals/),” *tonsky.me*, May 6, 2014.
34. Baron Schwartz: “[Immutability, MVCC, and Garbage Collection](http://www.xaprb.com/blog/2013/12/28/immutability-mvcc-and-garbage-collection/),” *xaprb.com*, December 28, 2013.
35. J. Chris Anderson, Jan Lehnardt, and Noah Slater: *CouchDB: The Definitive Guide*. O'Reilly Media, 2010.
ISBN: 978-0-596-15589-6 Rikdeb Mukherjee: “[Isolation in DB2 (Repeatable Read, Read Stability, Cursor Stability, Uncommitted Read) with Examples](http://mframes.blogspot.co.uk/2013/07/isolation-in-cursor.html),” *mframes.blogspot.co.uk*, July 4, 2013.
36. Steve Hilker: “[Cursor Stability (CS) – IBM DB2 Community](http://www.toadworld.com/platforms/ibmdb2/w/wiki/6661.cursor-stability-cs.aspx),” *toadworld.com*, March 14, 2013.
37. Nate Wiger: “[An Atomic Rant](http://www.nateware.com/an-atomic-rant.html),” *nateware.com*, February 18, 2010.
38. Joel Jacobson: “[Riak 2.0: Data Types](http://blog.joeljacobson.com/riak-2-0-data-types/),” *blog.joeljacobson.com*, March 23, 2014.
39. Michael J. Cahill, Uwe Röhm, and Alan Fekete: “[Serializable Isolation for Snapshot Databases](http://www.cs.nyu.edu/courses/fall12/CSCI-GA.2434-001/p729-cahill.pdf),” at *ACM International Conference on Management of Data* (SIGMOD), June 2008. [doi:10.1145/1376616.1376690](http://dx.doi.org/10.1145/1376616.1376690)
40. Dan R. K. Ports and Kevin Grittner: “[Serializable Snapshot Isolation in PostgreSQL](http://drkp.net/papers/ssi-vldb12.pdf),” at *38th International Conference on Very Large Databases* (VLDB), August 2012.
41. Tony Andrews: “[Enforcing Complex Constraints in Oracle](http://tonyandrews.blogspot.co.uk/2004/10/enforcing-complex-constraints-in.html),” *tonyandrews.blogspot.co.uk*, October 15, 2004.
42. Douglas B. Terry, Marvin M. Theimer, Karin Petersen, et al.: “[Managing Update Conflicts in Bayou, a Weakly Connected Replicated Storage System](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.141.7889&rep=rep1&type=pdf),” at *15th ACM Symposium on Operating Systems Principles* (SOSP), December 1995. [doi:10.1145/224056.224070](http://dx.doi.org/10.1145/224056.224070)
43. Gary Fredericks: “[Postgres Serializability Bug](https://github.com/gfredericks/pg-serializability-bug),” *github.com*, September 2015.
44. Michael Stonebraker, Samuel Madden, Daniel J. Abadi, et al.: “[The End of an Architectural Era (It’s Time for a Complete Rewrite)](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.137.3697&rep=rep1&type=pdf),” at *33rd International Conference on Very Large Data Bases* (VLDB), September 2007.
45. John Hugg: “[H-Store/VoltDB Architecture vs. CEP Systems and Newer Streaming Architectures](https://www.youtube.com/watch?v=hD5M4a1UVz8),” at *Data @Scale Boston*, November 2014.
46. Robert Kallman, Hideaki Kimura, Jonathan Natkins, et al.: “[H-Store: A High-Performance, Distributed Main Memory Transaction Processing System](http://www.vldb.org/pvldb/1/1454211.pdf),” *Proceedings of the VLDB Endowment*, volume 1, number 2, pages 1496–1499, August 2008.
47. Rich Hickey: “[The Architecture of Datomic](http://www.infoq.com/articles/Architecture-Datomic),” *infoq.com*, November 2, 2012.
48. John Hugg: “[Debunking Myths About the VoltDB In-Memory Database](http://voltdb.com/blog/debunking-myths-about-voltdb-memory-database),” *voltdb.com*, May 12, 2014.
49. Joseph M. Hellerstein, Michael Stonebraker, and James Hamilton: “[Architecture of a Database System](http://db.cs.berkeley.edu/papers/fntdb07-architecture.pdf),”
*Foundations and Trends in Databases*, volume 1, number 2, pages 141–259, November 2007.
[doi:10.1561/1900000002](http://dx.doi.org/10.1561/1900000002)
50. Michael J. Cahill: “[Serializable Isolation for Snapshot Databases](http://cahill.net.au/wp-content/uploads/2010/02/cahill-thesis.pdf),” PhD Thesis, University of Sydney, July 2009.
51. D. Z. Badal: “[Correctness of Concurrency Control and Implications in Distributed Databases](http://ieeexplore.ieee.org/abstract/document/762563/),” at *3rd International IEEE Computer Software and Applications Conference* (COMPSAC), November 1979.
52. Rakesh Agrawal, Michael J. Carey, and Miron Livny: “[Concurrency Control Performance Modeling: Alternatives and Implications](http://www.eecs.berkeley.edu/~brewer/cs262/ConcControl.pdf),” *ACM Transactions on Database Systems* (TODS), volume 12, number 4, pages 609–654, December 1987. [doi:10.1145/32204.32220](http://dx.doi.org/10.1145/32204.32220)
53. Dave Rosenthal: “[Databases at 14.4MHz](http://web.archive.org/web/20150427041746/http://blog.foundationdb.com/databases-at-14.4mhz),” *blog.foundationdb.com*, December 10, 2014.
------
| 上一章 | 目錄 | 下一章 |
| ---------------------- | ------------------------------- | ---------------------------------- |
| [第六章：分割槽](ch6.md) | [設計資料密集型應用](README.md) | [第八章：分散式系統的麻煩](ch8.md) |

781
zh-tw/ch8.md Normal file
View File

@ -0,0 +1,781 @@
# 第八章：分散式系統的麻煩
![](../img/ch8.png)
> 邂逅相遇
>
> 網路延遲
>
> 存之為吾
>
> 無食我數
>
> ​ —— Kyle Kingsbury, Carly Rae Jepsen 《網路分割槽的危害》（2013年）
---------
[TOC]
​ 最近幾章中反覆出現的主題是，系統如何處理錯誤的事情。例如，我們討論了**副本故障切換**（“[處理節點中斷](#ch5.md#處理節點宕機)”），**複製延遲**（“[複製延遲問題](ch6.md#複製延遲問題)”）和事務控制（“[弱隔離級別](ch7.md#弱隔離級別)”）。當我們瞭解可能在實際系統中出現的各種邊緣情況時，我們會更好地處理它們。
​ 但是，儘管我們已經談了很多錯誤，但之前幾章仍然過於樂觀。現實更加黑暗。我們現在將悲觀主義最大化，假設任何可能出錯的東西**都會**出錯[^i]。（經驗豐富的系統運維會告訴你，這是一個合理的假設。如果你問得好，他們可能會一邊治療心理創傷一邊告訴你一些可怕的故事）
[^i]: 除了一個例外：我們將假定故障是非拜占庭式的（參見“[拜占庭故障](#拜占庭故障)”）。
​ 使用分散式系統與在一臺計算機上編寫軟體有著根本的區別，主要的區別在於，有許多新穎和刺激的方法可以使事情出錯【1,2】。在這一章中，我們將瞭解實踐中出現的問題，理解我們能夠依賴，和不可以依賴的東西。
​ 最後，作為工程師，我們的任務是構建能夠完成工作的系統（即滿足使用者期望的保證），儘管一切都出錯了。 在[第9章](ch9.md)中，我們將看看一些可以在分散式系統中提供這種保證的演算法的例子。 但首先，在本章中，我們必須瞭解我們面臨的挑戰。
​ 本章對分散式系統中可能出現的問題進行徹底的悲觀和沮喪的總結。 我們將研究網路的問題（“[無法訪問的網路](#無法訪問的網路)”）; 時鐘和時序問題（“[不可靠時鐘](#不可靠時鐘)”）; 我們將討論他們可以避免的程度。 所有這些問題的後果都是困惑的，所以我們將探索如何思考一個分散式系統的狀態，以及如何推理髮生的事情（“[知識，真相和謊言](#知識，真相和謊言)”）。
## 故障與部分失效
​ 當你在一臺計算機上編寫一個程式時，它通常會以一種相當可預測的方式執行：無論是工作還是不工作。充滿錯誤的軟體可能會讓人覺得電腦有時候是“糟糕的一天”（這個問題通常是重新啟動的問題），但這主要是軟體寫得不好的結果。
​ 單個計算機上的軟體沒有根本性的不可靠原因：當硬體正常工作時，相同的操作總是產生相同的結果（這是確定性的）。如果存在硬體問題（例如，記憶體損壞或聯結器鬆動），其後果通常是整個系統故障（例如，核心恐慌，“藍色畫面宕機”，啟動失敗）。裝有良好軟體的個人計算機通常要麼功能完好，要麼完全失效，而不是介於兩者之間。
​ 這是計算機設計中的一個慎重的選擇：如果發生內部錯誤，我們寧願電腦完全崩潰，而不是返回錯誤的結果，因為錯誤的結果很難處理。因為計算機隱藏了模糊不清的物理實現，並呈現出一個理想化的系統模型，並以數學一樣的完美的方式運作。 CPU指令總是做同樣的事情；如果您將一些資料寫入記憶體或磁碟，那麼這些資料將保持不變，並且不會被隨機破壞。從第一臺數字計算機開始，*始終正確地計算*這個設計目標貫穿始終【3】。
​ 當你編寫執行在多臺計算機上的軟體時，情況有本質上的區別。在分散式系統中，我們不再處於理想化的系統模型中，我們別無選擇，只能面對現實世界的混亂現實。而在現實世界中，各種各樣的事情都可能會出現問題【4】，如下面的軼事所述：
> ​ 在我有限的經驗中，我已經和很多東西打過交道：單個**資料中心（DC）**中長期存在的網路分割槽，配電單元PDU故障，交換機故障，整個機架的意外重啟，整個資料中心主幹網路故障，整個資料中心的電源故障，以及一個低血糖的司機把他的福特皮卡撞在資料中心的HVAC（加熱，通風和空調）系統上。而且我甚至不是一個運維。
>
> ——柯達黑爾
​ 在分散式系統中，儘管系統的其他部分工作正常，但系統的某些部分可能會以某種不可預知的方式被破壞。這被稱為**部分失效（partial failure）**。難點在於部分失效是**不確定性的（nonderterministic）**：如果你試圖做任何涉及多個節點和網路的事情，它有時可能會工作，有時會出現不可預知的失敗。正如我們將要看到的，你甚至不知道是否成功了，因為訊息透過網路傳播的時間也是不確定的！
​ 這種不確定性和部分失效的可能性，使得分散式系統難以工作【5】。
### 雲端計算與超級計算機
關於如何構建大型計算系統有一系列的哲學：
* 規模的一端是高效能運算（HPC）領域。具有數千個CPU的超級計算機通常用於計算密集型科學計算任務，如天氣預報或分子動力學（模擬原子和分子的運動）。
* 另一個極端是**雲端計算（cloud computing）**，雲端計算並不是一個良好定義的概念【6】，但通常與多租戶資料中心，連線IP網路的商品計算機（通常是乙太網），彈性/按需資源分配以及計量計費等相關聯。
* 傳統企業資料中心位於這兩個極端之間。
不同的哲學會導致不同的故障處理方式。在超級計算機中，作業通常會不時地會將計算的狀態存檔到持久儲存中。如果一個節點出現故障，通常的解決方案是簡單地停止整個叢集的工作負載。故障節點修復後，計算從上一個檢查點重新開始【7,8】。因此，超級計算機更像是一個單節點計算機而不是分散式系統：透過讓部分失敗升級為完全失敗來處理部分失敗——如果系統的任何部分發生故障，只是讓所有的東西都崩潰（就像單臺機器上的核心恐慌一樣）。
在本書中，我們將重點放在實現網際網路服務的系統上，這些系統通常與超級計算機看起來有很大不同
* 許多與網際網路有關的應用程式都是**線上（online）**的，因為它們需要能夠隨時以低延遲服務使用者。使服務不可用（例如，停止群集以進行修復）是不可接受的。相比之下，像天氣模擬這樣的離線（批處理）工作可以停止並重新啟動，影響相當小。
* 超級計算機通常由專用硬體構建而成，每個節點相當可靠，節點透過共享記憶體和**遠端直接記憶體訪問（RDMA）**進行通訊。另一方面，雲服務中的節點是由商品機器構建而成的，由於規模經濟，可以以較低的成本提供相同的效能，而且具有較高的故障率。
* 大型資料中心網路通常基於IP和乙太網，以閉合拓撲排列，以提供更高的二等分頻寬【9】。超級計算機通常使用專門的網路拓撲結構，例如多維網格和環面 【10】，這為具有已知通訊模式的HPC工作負載提供了更好的效能。
* 系統越大，其元件之一就越有可能壞掉。隨著時間的推移，壞掉的東西得到修復，新的東西又壞掉，但是在一個有成千上萬個節點的系統中，有理由認為總是有一些東西是壞掉的【7】。當錯誤處理策略由簡單的放棄組成時，一個大的系統最終會花費大量時間從錯誤中恢復，而不是做有用的工作【8】。
* 如果系統可以容忍發生故障的節點，並繼續保持整體工作狀態，那麼這對於操作和維護非常有用：例如，可以執行滾動升級（參閱[第4章](ch4.md)），一次重新啟動一個節點，而服務繼續服務使用者不中斷。在雲環境中，如果一臺虛擬機器執行不佳，可以殺死它並請求一臺新的虛擬機器（希望新的虛擬機器速度更快）。
* 在地理位置分散的部署中（保持資料在地理位置上接近使用者以減少訪問延遲），通訊很可能透過網際網路進行，與本地網路相比，通訊速度緩慢且不可靠。超級計算機通常假設它們的所有節點都靠近在一起。
如果要使分散式系統工作，就必須接受部分故障的可能性，並在軟體中建立容錯機制。換句話說，我們需要從不可靠的元件構建一個可靠的系統。 （正如“[可靠性](ch1.md#可靠性)”中所討論的那樣，沒有完美的可靠性，所以我們需要理解我們可以實際承諾的限制。）
​ 即使在只有少數節點的小型系統中，考慮部分故障也是很重要的。在一個小系統中，很可能大部分元件在大部分時間都正常工作。然而，遲早會有一部分系統出現故障，軟體必須以某種方式處理。故障處理必須是軟體設計的一部分，並且作為軟體的運維，您需要知道在發生故障的情況下，軟體可能會表現出怎樣的行為。
​ 簡單地假設缺陷很罕見，只是希望始終保持最好的狀況是不明智的。考慮一系列可能的錯誤（甚至是不太可能的錯誤），並在測試環境中人為地建立這些情況來檢視會發生什麼是非常重要的。在分散式系統中，懷疑，悲觀和偏執狂是值得的。
> #### 從不可靠的元件構建可靠的系統
>
> 您可能想知道這是否有意義——直觀地看來，系統只能像其最不可靠的元件（最薄弱的環節）一樣可靠。事實並非如此：事實上，從不太可靠的潛在基礎構建更可靠的系統是計算機領域的一個古老思想【11】。例如：
>
> * 糾錯碼允許數字資料在通訊通道上準確傳輸，偶爾會出現一些錯誤，例如由於無線網路上的無線電干擾【12】。
> * **網際網路協議（Internet Protocol, IP）**不可靠：可能丟棄，延遲，複製或重排資料包。 傳輸控制協議（Transmission Control Protocol, TCP）在網際網路協議（IP）之上提供了更可靠的傳輸層：它確保丟失的資料包被重新傳輸，消除重複，並且資料包被重新組裝成它們被髮送的順序。
>
> 雖然這個系統可以比它的底層部分更可靠，但它的可靠性總是有限的。例如，糾錯碼可以處理少量的單位元錯誤，但是如果你的訊號被幹擾所淹沒，那麼透過通道可以得到多少資料，是有根本性的限制的【13】。 TCP可以隱藏資料包的丟失，重複和重新排序，但是它不能神奇地消除網路中的延遲。
>
> 雖然更可靠的高階系統並不完美，但它仍然有用，因為它處理了一些棘手的低階錯誤，所以其餘的錯誤通常更容易推理和處理。我們將在“[資料庫端到端的爭論](ch12.md#資料庫端到端的爭論)”中進一步探討這個問題。
## 不可靠的網路
​ 正如在第二部分的介紹中所討論的那樣，我們在本書中關注的分散式系統是無共享的系統，即透過網路連線的一堆機器。網路是這些機器可以通訊的唯一途徑——我們假設每臺機器都有自己的記憶體和磁碟，一臺機器不能訪問另一臺機器的記憶體或磁碟（除了透過網路向伺服器發出請求）。
​ **無共享**並不是構建系統的唯一方式，但它已經成為構建網際網路服務的主要方式，其原因如下：相對便宜，因為它不需要特殊的硬體，可以利用商品化的雲端計算服務，透過跨多個地理分佈的資料中心進行冗餘可以實現高可靠性。
​ 網際網路和資料中心（通常是乙太網）中的大多數內部網路都是**非同步分組網路（asynchronous packet networks）**。在這種網路中，一個節點可以向另一個節點發送一個訊息（一個數據包），但是網路不能保證它什麼時候到達，或者是否到達。如果您傳送請求並期待響應，則很多事情可能會出錯（其中一些如[圖8-1](../img/fig8-1.png)所示）：
1. 請求可能已經丟失（可能有人拔掉了網線）。
2. 請求可能正在排隊，稍後將交付（也許網路或收件人超載）。
3. 遠端節點可能已經失效（可能是崩潰或關機）。
4. 遠端節點可能暫時停止了響應（可能會遇到長時間的垃圾回收暫停；參閱“[暫停程序](#暫停程序)”），但稍後會再次響應。
5. 遠端節點可能已經處理了請求，但是網路上的響應已經丟失（可能是網路交換機配置錯誤）。
6. 遠端節點可能已經處理了請求，但是響應已經被延遲，並且稍後將被傳遞（可能是網路或者你自己的機器過載）。
![](../img/fig8-1.png)
**圖8-1 如果傳送請求並沒有得到響應，則無法區分（a）請求是否丟失，（b）遠端節點是否關閉，或（c）響應是否丟失。**
​ 傳送者甚至不能分辨資料包是否被髮送：唯一的選擇是讓接收者傳送響應訊息，這可能會丟失或延遲。這些問題在非同步網路中難以區分：您所擁有的唯一資訊是，您尚未收到響應。如果您向另一個節點發送請求並且沒有收到響應，則無法說明原因。
​ 處理這個問題的通常方法是**超時（Timeout）**：在一段時間之後放棄等待，並且認為響應不會到達。但是，當發生超時時，你仍然不知道遠端節點是否收到了請求（如果請求仍然在某個地方排隊，那麼即使發件人已經放棄了該請求，仍然可能會將其傳送給收件人）。
### 真實世界的網路故障
​ 我們幾十年來一直在建設計算機網路——有人可能希望現在我們已經找出了使網路變得可靠的方法。但是現在似乎還沒有成功。
​ 有一些系統的研究和大量的軼事證據表明，即使在像一家公司運營的資料中心那樣的受控環境中，網路問題也可能出乎意料地普遍。在一家中型資料中心進行的一項研究發現，每個月大約有12個網路故障，其中一半斷開一臺機器，一半斷開整個機架【15】。另一項研究測量了架頂式交換機，匯聚交換機和負載平衡器等元件的故障率【16】。它發現新增冗餘網路裝置不會像您所希望的那樣減少故障，因為它不能防範人為錯誤（例如，錯誤配置的交換機），這是造成中斷的主要原因。
​ 諸如EC2之類的公有云服務因頻繁的暫態網路故障而臭名昭著【14】，管理良好的私有資料中心網路可能是更穩定的環境。儘管如此，沒有人不受網路問題的困擾：例如，交換機軟體升級過程中的一個問題可能會引發網路拓撲重構，在此期間網路資料包可能會延遲超過一分鐘【17】。鯊魚可能咬住海底電纜並損壞它們 【18】。其他令人驚訝的故障包括網路介面有時會丟棄所有入站資料包，但是成功傳送出站資料包 【19】：僅僅因為網路連結在一個方向上工作，並不能保證它也在相反的方向工作。
> #### 網路分割槽
>
> ​ 當網路的一部分由於網路故障而被切斷時，有時稱為**網路分割槽（network partition）**或**網路斷裂（netsplit）**。在本書中，我們通常會堅持使用更一般的術語**網路故障（network fault）**，以避免與[第6章](ch6.md)討論的儲存系統的分割槽（分片）相混淆。
​ 即使網路故障在你的環境中非常罕見，故障可能發生的事實，意味著你的軟體需要能夠處理它們。無論何時透過網路進行通訊，都可能會失敗，這是無法避免的。
​ 如果網路故障的錯誤處理沒有定義與測試，武斷地講，各種錯誤可能都會發生：例如，即使網路恢復【20】，叢集可能會發生**死鎖**，永久無法為請求提供服務，甚至可能會刪除所有的資料【21】。如果軟體被置於意料之外的情況下，它可能會做出出乎意料的事情。
​ 處理網路故障並不意味著容忍它們：如果你的網路通常是相當可靠的，一個有效的方法可能是當你的網路遇到問題時，簡單地向用戶顯示一條錯誤資訊。但是，您確實需要知道您的軟體如何應對網路問題，並確保系統能夠從中恢復。有意識地觸發網路問題並測試系統響應（這是Chaos Monkey背後的想法；參閱“[可靠性](ch1.md#可靠性)”）。
### 檢測故障
許多系統需要自動檢測故障節點。例如：
* 負載平衡器需要停止向已死亡的節點轉發請求（即從**移出輪詢列表（out of rotation）**）。
* 在單主複製功能的分散式資料庫中，如果主庫失效，則需要將從庫之一升級為新主庫（參閱“[處理節點宕機](ch5.md#處理節點宕機)”）。
不幸的是，網路的不確定性使得很難判斷一個節點是否工作。在某些特定的情況下，您可能會收到一些反饋資訊，明確告訴您某些事情沒有成功：
* 如果你可以到達執行節點的機器，但沒有程序正在偵聽目標埠（例如，因為程序崩潰），作業系統將透過傳送FIN或RST來關閉並重用TCP連線。但是，如果節點在處理請求時發生崩潰，則無法知道遠端節點實際處理了多少資料【22】。
* 如果節點程序崩潰（或被管理員殺死），但節點的作業系統仍在執行，則指令碼可以通知其他節點有關該崩潰的資訊，以便另一個節點可以快速接管，而無需等待超時到期。例如，HBase做這個【23】。
* 如果您有權訪問資料中心網路交換機的管理介面，則可以查詢它們以檢測硬體級別的鏈路故障（例如，遠端機器是否關閉電源）。如果您透過網際網路連線，或者如果您處於共享資料中心而無法訪問交換機，或者由於網路問題而無法訪問管理介面，則排除此選項。
* 如果路由器確認您嘗試連線的IP地址不可用，則可能會使用ICMP目標不可達資料包回覆您。但是，路由器不具備神奇的故障檢測能力——它受到與網路其他參與者相同的限制。
關於遠端節點關閉的快速反饋很有用，但是你不能指望它。即使TCP確認已經傳送了一個數據包，應用程式在處理之前可能已經崩潰。如果你想確保一個請求是成功的，你需要應用程式本身的積極響應【24】。
​ 相反，如果出了什麼問題，你可能會在堆疊的某個層次上得到一個錯誤響應，但總的來說，你必須假設你根本就沒有得到任何迴應。您可以重試幾次（TCP重試是透明的，但是您也可以在應用程式級別重試），等待超時過期，並且如果在超時時間內沒有收到響應，則最終宣告節點已經死亡。
### 超時與無窮的延遲
​ 如果超時是檢測故障的唯一可靠方法，那麼超時應該等待多久？不幸的是沒有簡單的答案。
​ 長時間的超時意味著長時間等待，直到一個節點被宣告死亡（在這段時間內，使用者可能不得不等待，或者看到錯誤資訊）。短暫的超時可以更快地檢測到故障，但是實際上它只是經歷了暫時的減速（例如，由於節點或網路上的負載峰值）而導致錯誤地宣佈節點失效的風險更高。
​ 過早地宣告一個節點已經死了是有問題的：如果這個節點實際上是活著的，並且正在執行一些動作（例如，傳送一封電子郵件），而另一個節點接管，那麼這個動作可能會最終執行兩次。我們將在“[知識，真相和謊言](#知識，真相和謊言)”以及[第9章](ch9.md)和[第11章](ch11.md)中更詳細地討論這個問題。
​ 當一個節點被宣告死亡時，它的職責需要轉移到其他節點，這會給其他節點和網路帶來額外的負擔。如果系統已經處於高負荷狀態，則過早宣告節點死亡會使問題更嚴重。尤其是可能發生，節點實際上並沒有死亡，而是由於過載導致響應緩慢；將其負載轉移到其他節點可能會導致**級聯失效（cascading failure）**（在極端情況下，所有節點都宣告對方死亡，並且所有節點都停止工作）。
​ 設想一個虛構的系統，其網路可以保證資料包的最大延遲——每個資料包要麼在一段時間內傳送，要麼丟失，但是傳遞永遠不會比$d$更長。此外，假設你可以保證一個非故障節點總是在一段時間內處理一個請求$r$。在這種情況下，您可以保證每個成功的請求在$2d + r$時間內都能收到響應，如果您在此時間內沒有收到響應，則知道網路或遠端節點不工作。如果這是成立的，$2d + r$ 會是一個合理的超時設定。
​ 不幸的是，我們所使用的大多數系統都沒有這些保證：非同步網路具有無限的延遲（即儘可能快地傳送資料包，但資料包到達可能需要的時間沒有上限），並且大多數伺服器實現並不能保證它們可以在一定的最大時間內處理請求（請參閱“[響應時間保證](#響應時間保證)”）。對於故障檢測，系統大部分時間快速執行是不夠的：如果你的超時時間很短，往返時間只需要一個瞬時尖峰就可以使系統失衡。
#### 網路擁塞和排隊
​ 在駕駛汽車時，由於交通擁堵，道路交通網路的通行時間往往不盡相同。同樣，計算機網路上資料包延遲的可變性通常是由於排隊【25】：
* 如果多個不同的節點同時嘗試將資料包傳送到同一目的地，則網路交換機必須將它們排隊並將它們逐個送入目標網路鏈路（如[圖8-2](../img/fig8-2.png)所示）。在繁忙的網路鏈路上，資料包可能需要等待一段時間才能獲得一個插槽（這稱為網路連線）。如果傳入的資料太多，交換機佇列填滿，資料包將被丟棄，因此需要重新發送資料包 - 即使網路執行良好。
* 當資料包到達目標機器時，如果所有CPU核心當前都處於繁忙狀態，則來自網路的傳入請求將被作業系統排隊，直到應用程式準備好處理它為止。根據機器上的負載，這可能需要一段任意的時間。
* 在虛擬化環境中，正在執行的作業系統經常暫停幾十毫秒，而另一個虛擬機器使用CPU核心。在這段時間內，虛擬機器不能從網路中消耗任何資料，所以傳入的資料被虛擬機器監視器 【26】排隊（緩衝），進一步增加了網路延遲的可變性。
* TCP執行**流量控制（flow control）**（也稱為**擁塞避免（congestion avoidance）**或**背壓（backpressure）**），其中節點限制自己的傳送速率以避免網路鏈路或接收節點過載【27】。這意味著在資料甚至進入網路之前，在傳送者處需要進行額外的排隊。
![](../img/fig8-2.png)
**圖8-2 如果有多臺機器將網路流量傳送到同一目的地，則其交換機佇列可能會被填滿。在這裡，埠1,2和4都試圖傳送資料包到埠3**
​ 而且，如果TCP在某個超時時間內沒有被確認（這是根據觀察的往返時間計算的），則認為資料包丟失，丟失的資料包將自動重新發送。儘管應用程式沒有看到資料包丟失和重新傳輸，但它看到了延遲（等待超時到期，然後等待重新傳輸的資料包得到確認）。
     
> ### TCP與UDP
>
> ​ 一些對延遲敏感的應用程式（如影片會議和IP語音（VoIP））使用UDP而不是TCP。這是在可靠性和和延遲可變性之間的折衷：由於UDP不執行流量控制並且不重傳丟失的分組，所以避免了可變網路延遲的一些原因（儘管它仍然易受切換佇列和排程延遲的影響）。
>
> ​ 在延遲資料毫無價值的情況下，UDP是一個不錯的選擇。例如，在VoIP電話呼叫中，可能沒有足夠的時間重新發送丟失的資料包，並在揚聲器上播放資料。在這種情況下，重發資料包沒有意義——應用程式必須使用靜音填充丟失資料包的時隙（導致聲音短暫中斷），然後在資料流中繼續。重試發生在人類層。 （“你能再說一遍嗎？聲音剛剛斷了一會兒。“）
​ 所有這些因素都會造成網路延遲的變化。當系統接近其最大容量時，排隊延遲的範圍特別廣泛：
​ 擁有足夠備用容量的系統可以輕鬆排空佇列，而在高利用率的系統中，很快就能積累很長的佇列。
​ 在公共雲和多租戶資料中心中，資源被許多客戶共享：網路連結和交換機，甚至每個機器的網絡卡和CPU（在虛擬機器上執行時）。批處理工作負載（如MapReduce）（參閱[第10章](ch10.md)）可能很容易使網路連結飽和。由於無法控制或瞭解其他客戶對共享資源的使用情況，如果附近的某個人（嘈雜的鄰居）正在使用大量資源，則網路延遲可能會發生劇烈抖動【28,29】。
​ 在這種環境下，您只能透過實驗方式選擇超時：測量延長的網路往返時間和多臺機器的分佈，以確定延遲的預期可變性。然後，考慮到應用程式的特性，可以確定**故障檢測延遲**與**過早超時風險**之間的適當折衷。
​ 更好的一種做法是，系統不是使用配置的常量超時時間，而是連續測量響應時間及其變化（抖動），並根據觀察到的響應時間分佈自動調整超時時間。這可以透過Phi Accrual故障檢測器【30】來完成，該檢測器在例如Akka和Cassandra 【31】中使用。 TCP超時重傳機制也同樣起作用【27】。
### 同步網路 vs 非同步網路
​ 如果我們可以依靠網路來傳遞一些**最大延遲固定**的資料包，而不是丟棄資料包，那麼分散式系統就會簡單得多。為什麼我們不能在硬體層面上解決這個問題，使網路可靠，使軟體不必擔心呢？
​ 為了回答這個問題，將資料中心網路與非常可靠的傳統固定電話網路（非蜂窩，非VoIP）進行比較是很有趣的：延遲音訊幀和掉話是非常罕見的。一個電話需要一個很低的端到端延遲，以及足夠的頻寬來傳輸你聲音的音訊取樣資料。在計算機網路中有類似的可靠性和可預測性不是很好嗎？
​ 當您透過電話網路撥打電話時，它會建立一個電路：在兩個呼叫者之間的整個路線上為呼叫分配一個固定的，有保證的頻寬量。這個電路會保持至通話結束【32】。例如，ISDN網路以每秒4000幀的固定速率執行。呼叫建立時，每個幀內（每個方向）分配16位空間。因此，在通話期間，每一方都保證能夠每250微秒傳送一個精確的16位音訊資料【33,34】。
​ 這種網路是同步的：即使資料經過多個路由器，也不會受到排隊的影響，因為呼叫的16位空間已經在網路的下一跳中保留了下來。而且由於沒有排隊，網路的最大端到端延遲是固定的。我們稱之為**有限延遲（bounded delay）**。
#### 我們不能簡單地使網路延遲可預測嗎？
​ 請注意，電話網路中的電路與TCP連線有很大不同：電路是固定數量的預留頻寬，在電路建立時沒有其他人可以使用，而TCP連線的資料包**機會性地**使用任何可用的網路頻寬。您可以給TCP一個可變大小的資料塊（例如，一個電子郵件或一個網頁），它會盡可能在最短的時間內傳輸它。 TCP連線空閒時，不使用任何頻寬[^ii]。
[^ii]: 除了偶爾的keepalive資料包，如果TCP keepalive被啟用。
​ 如果資料中心網路和網際網路是電路交換網路，那麼在建立電路時就可以建立一個保證的最大往返時間。但是，它們並不是：乙太網和IP是**分組交換協議**，不得不忍受排隊的折磨，及其導致的網路無限延遲。這些協議沒有電路的概念。
​ 為什麼資料中心網路和網際網路使用分組交換？答案是，它們針對**突發流量（bursty traffic）**進行了最佳化。一個電路適用於音訊或影片通話，在通話期間需要每秒傳送相當數量的位元。另一方面，請求網頁，傳送電子郵件或傳輸檔案沒有任何特定的頻寬要求——我們只是希望它儘快完成。
​ 如果你想透過電路傳輸檔案，你將不得不猜測一個頻寬分配。如果您猜的太低，傳輸速度會不必要的太慢，導致網路容量閒置。如果你猜的太高，電路就無法建立（因為如果無法保證其頻寬分配，網路不能建立電路）。因此，使用用於突發資料傳輸的電路浪費網路容量，並且使傳輸不必要地緩慢。相比之下，TCP動態調整資料傳輸速率以適應可用的網路容量。
​ 已經有一些嘗試去建立支援電路交換和分組交換的混合網路，比如ATM[^iii] InfiniBand有一些相似之處【35】：它在鏈路層實現了端到端的流量控制，從而減少了在網路中排隊，儘管它仍然可能因鏈路擁塞而受到延遲【36】。透過仔細使用**服務質量（quality of service,）**（QoS，資料包的優先順序和排程）和**准入控制（admission control）**（限速傳送器），可以模擬分組網路上的電路交換，或提供統計上的**有限延遲**【25,32】。
[^iii]: **非同步傳輸模式（Asynchronous TransferMode, ATM）**在20世紀80年代是乙太網的競爭對手【32】，但在電話網核心交換機之外並沒有得到太多的採用。與自動櫃員機（也稱為自動取款機）無關，儘管共用一個縮寫詞。或許，在一些平行的世界裡，網際網路是基於像ATM這樣的東西，因為網際網路影片通話可能比我們的更可靠，因為它們不會遭受丟包和延遲的包裹。
​ 但是，目前在多租戶資料中心和公共雲或透過網際網路[^iv]進行通訊時，此類服務質量尚未啟用。當前部署的技術不允許我們對網路的延遲或可靠性作出任何保證：我們必須假設網路擁塞，排隊和無限的延遲總是會發生。因此，超時時間沒有“正確”的值——它需要透過實驗來確定。
[^iv]: 網際網路服務提供商之間的對等協議和透過**BGP閘道器協議（BGP）**建立路由之間的對等協議，與電路交換本身相比，與電路交換更接近。在這個級別上，可以購買專用頻寬。但是，網際網路路由在網路級別執行，而不是主機之間的單獨連線，而且執行時間要長得多。
> ### 延遲和資源利用
>
> ​ 更一般地說，可以將**延遲變化**視為**動態資源分割槽**的結果。
>
> ​ 假設兩臺電話交換機之間有一條線路，可以同時進行10,000個呼叫。透過此線路切換的每個電路都佔用其中一個呼叫插槽。因此，您可以將線路視為可由多達10,000個併發使用者共享的資源。資源以靜態方式分配：即使您現在是電話上唯一的電話，並且所有其他9,999個插槽都未使用，您的電路仍將分配與導線充分利用時相同的固定數量的頻寬。
>
> ​ 相比之下，網際網路動態分享網路頻寬。傳送者互相推擠並互相推擠以儘可能快地透過網路獲得它們的分組，並且網路交換機決定從一個時刻到另一個時刻傳送哪個分組（即，頻寬分配）。這種方法有排隊的缺點，但其優點是它最大限度地利用了電線。電線固定成本，所以如果你更好地利用它，你透過電線傳送的每個位元組都會更便宜。
>
> ​ CPU也會出現類似的情況：如果您在多個執行緒間動態共享每個CPU核心，則有一個執行緒有時必須等待作業系統的執行佇列，而另一個執行緒正在執行，這樣執行緒可以暫停不同的時間長度。但是，與為每個執行緒分配靜態數量的CPU週期相比，這會更好地利用硬體（參閱“[響應時間保證](#響應時間保證)”）。更好的硬體利用率也是使用虛擬機器的重要動機。
>
> ​ 如果資源是靜態分割槽的（例如，專用硬體和專用頻寬分配），則在某些環境中可以實現**延遲保證**。但是，這是以降低利用率為代價的——換句話說，它是更昂貴的。另一方面，動態資源分配的多租戶提供了更好的利用率，所以它更便宜，但它具有可變延遲的缺點。
>
> ​ 網路中的可變延遲不是一種自然規律，而只是成本/收益權衡的結果。
## 不可靠的時鐘
時鐘和時間很重要。應用程式以各種方式依賴於時鐘來回答以下問題：
1. 這個請求是否超時了？
2. 這項服務的第99百分位響應時間是多少？
3. 在過去五分鐘內，該服務平均每秒處理多少個查詢？
4. 使用者在我們的網站上花了多長時間？
5. 這篇文章在何時釋出？
6. 在什麼時間傳送提醒郵件？
7. 這個快取條目何時到期？
8. 日誌檔案中此錯誤訊息的時間戳是什麼？
[例1-4](ch1.md)測量[持續時間]()（例如，傳送請求與正在接收的響應之間的時間間隔），而[例5-8](ch5.md)描述**時間點（point in time）**（在特定日期，特定時間發生的事件）。
​ 在分散式系統中，時間是一件棘手的事情，因為通訊不是即時的：訊息透過網路從一臺機器傳送到另一臺機器需要時間。收到訊息的時間總是晚於傳送的時間，但是由於網路中的可變延遲，我們不知道多少時間。這個事實有時很難確定在涉及多臺機器時發生事情的順序。
​ 而且，網路上的每臺機器都有自己的時鐘，這是一個實際的硬體裝置：通常是石英晶體振盪器。這些裝置不是完全準確的，所以每臺機器都有自己的時間概念，可能比其他機器稍快或更慢。可以在一定程度上同步時鐘：最常用的機制是**網路時間協議（NTP）**，它允許根據一組伺服器報告的時間來調整計算機時鐘【37】。伺服器則從更精確的時間源（如GPS接收機）獲取時間。
### 單調鍾與時鐘
​ 現代計算機至少有兩種不同的時鐘：時鐘和單調鍾。儘管它們都衡量時間，但區分這兩者很重要，因為它們有不同的目的。
#### 時鐘
​ 時鐘是您直觀地瞭解時鐘的依據：它根據某個日曆（也稱為**掛鐘時間（wall-clock time）**）返回當前日期和時間。例如，Linux[^v]上的`clock_gettime(CLOCK_REALTIME)`和Java中的`System.currentTimeMillis()`返回自epoch（1970年1月1日 午夜 UTC，格里高利曆）以來的秒數（或毫秒），根據公曆日曆，不包括閏秒。有些系統使用其他日期作為參考點。
[^v]: 雖然時鐘被稱為實時時鐘，但它與實時作業系統無關，如第298頁上的“[響應時間保證](#響應時間保證)”中所述。
​ 時鐘通常與NTP同步，這意味著來自一臺機器的時間戳（理想情況下）意味著與另一臺機器上的時間戳相同。但是如下節所述，時鐘也具有各種各樣的奇特之處。特別是，如果本地時鐘在NTP伺服器之前太遠，則它可能會被強制重置，看上去好像跳回了先前的時間點。這些跳躍以及他們經常忽略閏秒的事實，使時鐘不能用於測量經過時間【38】。
​ 時鐘還具有相當粗略的解析度，例如，在較早的Windows系統上以10毫秒為單位前進【39】。在最近的系統中這已經不是一個問題了。
#### 單調鍾
​ 單調鍾適用於測量持續時間（時間間隔），例如超時或服務的響應時間：Linux上的`clock_gettime(CLOCK_MONOTONIC)`，和Java中的`System.nanoTime()`都是單調時鐘。這個名字來源於他們保證總是前進的事實（而時鐘可以及時跳回）。
​ 你可以在某個時間點檢查單調鐘的值，做一些事情，且稍後再次檢查它。這兩個值之間的差異告訴你兩次檢查之間經過了多長時間。但單調鐘的絕對值是毫無意義的：它可能是計算機啟動以來的納秒數，或類似的任意值。特別是比較來自兩臺不同計算機的單調鐘的值是沒有意義的，因為它們並不是一回事。
​ 在具有多個CPU插槽的伺服器上，每個CPU可能有一個單獨的計時器，但不一定與其他CPU同步。作業系統會補償所有的差異，並嘗試嚮應用執行緒表現出單調鐘的樣子，即使這些執行緒被排程到不同的CPU上。當然，明智的做法是不要太把這種單調性保證當回事【40】。
​ 如果NTP協議檢測到計算機的本地石英鐘比NTP伺服器要更快或更慢，則可以調整單調鍾向前走的頻率（這稱為**偏移（skewing）**時鐘）。預設情況下，NTP允許時鐘速率增加或減慢最高至0.05％，但NTP不能使單調時鐘向前或向後跳轉。單調時鐘的解析度通常相當好：在大多數系統中，它們能在幾微秒或更短的時間內測量時間間隔。
​ 在分散式系統中，使用單調鍾測量**經過時間（elapsed time）**（比如超時）通常很好，因為它不假定不同節點的時鐘之間存在任何同步，並且對測量的輕微不準確性不敏感。
### 時鐘同步與準確性
​ 單調鐘不需要同步，但是時鐘需要根據NTP伺服器或其他外部時間源來設定才能有用。不幸的是，我們獲取時鐘的方法並不像你所希望的那樣可靠或準確——硬體時鐘和NTP可能會變幻莫測。舉幾個例子：
​ 計算機中的石英鐘不夠精確：它會**漂移（drifts）**（執行速度快於或慢於預期）。時鐘漂移取決於機器的溫度。 Google假設其伺服器時鐘漂移為200 ppm（百萬分之一）【41】，相當於每30秒與伺服器重新同步一次的時鐘漂移為6毫秒，或者每天重新同步的時鐘漂移為17秒。即使一切工作正常，此漂移也會限制可以達到的最佳準確度。
* 如果計算機的時鐘與NTP伺服器的時鐘差別太大，可能會拒絕同步，或者本地時鐘將被強制重置【37】。任何觀察重置前後時間的應用程式都可能會看到時間倒退或突然跳躍。
* 如果某個節點被NTP伺服器意外阻塞，可能會在一段時間內忽略錯誤配置。有證據表明，這在實踐中確實發生過。
* NTP同步只能和網路延遲一樣好，所以當您在擁有可變資料包延遲的擁塞網路上時，NTP同步的準確性會受到限制。一個實驗表明，當透過網際網路同步時，35毫秒的最小誤差是可以實現的，儘管偶爾的網路延遲峰值會導致大約一秒的誤差。根據配置，較大的網路延遲會導致NTP客戶端完全放棄。
* 一些NTP伺服器錯誤或配置錯誤，報告時間已經過去了幾個小時【43,44】。 NTP客戶端非常強大，因為他們查詢多個伺服器並忽略異常值。儘管如此，在網際網路上陌生人告訴你的時候，你的系統的正確性還是值得擔憂的。
* 閏秒導致59分鐘或61秒長的分鐘，這混淆了未設計閏秒的系統中的時序假設【45】。閏秒已經使許多大型系統崩潰【38,46】的事實說明了，關於時鐘的假設是多麼容易偷偷溜入系統中。處理閏秒的最佳方法可能是透過在一天中逐漸執行閏秒調整（這被稱為**拖尾（smearing）**）【47,48】，使NTP伺服器“撒謊”，雖然實際的NTP伺服器表現各異【49】。
* 在虛擬機器中，硬體時鐘被虛擬化，這對於需要精確計時的應用程式提出了額外的挑戰【50】。當一個CPU核心在虛擬機器之間共享時，每個虛擬機器都會暫停幾十毫秒，與此同時另一個虛擬機器正在執行。從應用程式的角度來看，這種停頓表現為時鐘突然向前跳躍【26】。
* 如果您在未完全控制的裝置上執行軟體（例如，移動裝置或嵌入式裝置），則可能完全不能信任該裝置的硬體時鐘。一些使用者故意將其硬體時鐘設定為不正確的日期和時間，例如，為了規避遊戲中的時間限制，時鐘可能會被設定到很遠的過去或將來。
如果你足夠在乎這件事並投入大量資源，就可以達到非常好的時鐘精度。例如，針對金融機構的歐洲法規草案MiFID II要求所有高頻率交易基金在UTC時間100微秒內同步時鐘，以便除錯“閃崩”等市場異常現象，並幫助檢測市場操縱 【51】。
​ 透過GPS接收機，精確時間協議（PTP）【52】以及仔細的部署和監測可以實現這種精確度。然而，這需要很多努力和專業知識，而且有很多東西都會導致時鐘同步錯誤。如果你的NTP守護程序配置錯誤，或者防火牆阻止了NTP通訊，由漂移引起的時鐘誤差可能很快就會變大。
### 依賴同步時鐘
​ 時鐘的問題在於，雖然它們看起來簡單易用，但卻具有令人驚訝的缺陷：一天可能不會有精確的86,400秒，**時鐘**可能會前後跳躍，而一個節點上的時間可能與另一個節點上的時間完全不同。
​ 本章早些時候，我們討論了網路丟包和任意延遲包的問題。儘管網路在大多數情況下表現良好，但軟體的設計必須假定網路偶爾會出現故障，而軟體必須正常處理這些故障。時鐘也是如此：儘管大多數時間都工作得很好，但需要準備健壯的軟體來處理不正確的時鐘。
​ 有一部分問題是，不正確的時鐘很容易被視而不見。如果一臺機器的CPU出現故障或者網路配置錯誤，很可能根本無法工作，所以很快就會被注意和修復。另一方面，如果它的石英時鐘有缺陷，或者它的NTP客戶端配置錯誤，大部分事情似乎仍然可以正常工作，即使它的時鐘逐漸偏離現實。如果某個軟體依賴於精確同步的時鐘，那麼結果更可能是悄無聲息的，僅有微量的資料丟失，而不是一次驚天動地的崩潰【53,54】。
​ 因此，如果你使用需要同步時鐘的軟體，必須仔細監控所有機器之間的時鐘偏移。時鐘偏離其他時鐘太遠的節點應當被宣告死亡，並從叢集中移除。這樣的監控可以確保你在損失發生之前注意到破損的時鐘。
#### 有序事件的時間戳
​ 讓我們考慮一個特別的情況，一件很有誘惑但也很危險的事情：依賴時鐘，在多個節點上對事件進行排序。 例如，如果兩個客戶端寫入分散式資料庫，誰先到達？ 哪一個更近？
​ [圖8-3](../img/fig8-3.png)顯示了在具有多領導者複製的資料庫中對時鐘的危險使用（該例子類似於[圖5-9](../img/fig5-9.png)）。 客戶端A在節點1上寫入`x = 1`；寫入被複制到節點3；客戶端B在節點3上增加x（我們現在有`x = 2`）；最後這兩個寫入都被複制到節點2。
![](../img/fig8-3.png)
**圖8-3 客戶端B的寫入比客戶端A的寫入要晚，但是B的寫入具有較早的時間戳。**
​ 在[圖8-3]()中，當一個寫入被複制到其他節點時，它會根據發生寫入的節點上的時鐘時鐘標記一個時間戳。在這個例子中，時鐘同步是非常好的：節點1和節點3之間的偏差小於3ms，這可能比你在實踐中預期的更好。
​ 儘管如此，[圖8-3](../img/fig8-3.png)中的時間戳卻無法正確排列事件：寫入`x = 1`的時間戳為42.004秒，但寫入`x = 2`的時間戳為42.003秒，即使`x = 2`在稍後出現。當節點2接收到這兩個事件時，會錯誤地推斷出`x = 1`是最近的值，而丟棄寫入`x = 2`。效果上表現為，客戶端B的增量操作會丟失。
​ 這種衝突解決策略被稱為**最後寫入勝利（LWW）**，它在多領導者複製和無領導者資料庫（如Cassandra 【53】和Riak 【54】）中被廣泛使用（參見“[最後寫入勝利（丟棄併發寫入）](#最後寫入勝利（丟棄併發寫入）)”一節）。有些實現會在客戶端而不是伺服器上生成時間戳，但這並不能改變LWW的基本問題：
* 資料庫寫入可能會神祕地消失：具有滯後時鐘的節點無法覆蓋之前具有快速時鐘的節點寫入的值，直到節點之間的時鐘偏差消逝【54,55】。此方案可能導致一定數量的資料被悄悄丟棄，而未嚮應用報告任何錯誤。
* LWW無法區分**高頻順序寫入**（在[圖8-3](../img/fig8-3.png)中，客戶端B的增量操作**一定**發生在客戶端A的寫入之後）和**真正併發寫入**（寫入者意識不到其他寫入者）。需要額外的因果關係跟蹤機制（例如版本向量），以防止因果關係的衝突（請參閱“[檢測併發寫入](ch5.md#檢測併發寫入)”）。
* 兩個節點很可能獨立地生成具有相同時間戳的寫入，特別是在時鐘僅具有毫秒解析度的情況下。為了解決這樣的衝突，還需要一個額外的**決勝值（tiebreaker）**（可以簡單地是一個大隨機數），但這種方法也可能會導致違背因果關係【53】。
因此，儘管透過保留最“最近”的值並放棄其他值來解決衝突是很誘惑人的，但是要注意，“最近”的定義取決於本地的**時鐘**，這很可能是不正確的。即使用頻繁同步的NTP時鐘，一個數據包也可能在時間戳100毫秒（根據傳送者的時鐘）時傳送，並在時間戳99毫秒（根據接收者的時鐘）處到達——看起來好像資料包在傳送之前已經到達，這是不可能的。
​ NTP同步是否能足夠準確，以至於這種不正確的排序不會發生？也許不能，因為NTP的同步精度本身受到網路往返時間的限制，除了石英鐘漂移這類誤差源之外。為了進行正確的排序，你需要一個比測量物件（即網路延遲）要精確得多的時鐘。
​ 所謂的**邏輯時鐘（logic clock）**【56,57】是基於遞增計數器而不是振盪石英晶體，對於排序事件來說是更安全的選擇（請參見“[檢測併發寫入](ch5.md#檢測併發寫入)”）。邏輯時鐘不測量一天中的時間或經過的秒數，而僅測量事件的相對順序（無論一個事件發生在另一個事件之前還是之後）。相反，用來測量實際經過時間的**時鐘**和**單調鍾**也被稱為**物理時鐘（physical clock）**。我們將在“[順序保證](#順序保證)”中來看順序問題。
#### 時鐘讀數存在置信區間
​ 您可能能夠以微秒或甚至納秒的精度讀取機器的時鐘。但即使可以得到如此細緻的測量結果，這並不意味著這個值對於這樣的精度實際上是準確的。實際上，大概率是不準確的——如前所述，即使您每分鐘與本地網路上的NTP伺服器進行同步，幾毫秒的時間漂移也很容易在不精確的石英時鐘上發生。使用公共網際網路上的NTP伺服器，最好的準確度可能達到幾十毫秒，而且當網路擁塞時，誤差可能會超過100毫秒【57】。
​ 因此，將時鐘讀數視為一個時間點是沒有意義的——它更像是一段時間範圍：例如，一個系統可能以95％的置信度認為當前時間處於本分鐘內的第10.3秒和10.5秒之間，它可能沒法比這更精確了【58】。如果我們只知道±100毫秒的時間，那麼時間戳中的微秒數字部分基本上是沒有意義的。
​ 不確定性界限可以根據你的時間源來計算。如果您的GPS接收器或原子（銫）時鐘直接連線到您的計算機上，預期的錯誤範圍由製造商告知。如果從伺服器獲得時間，則不確定性取決於自上次與伺服器同步以來的石英鐘漂移的期望值，加上NTP伺服器的不確定性，再加上到伺服器的網路往返時間（只是獲取粗略近似值，並假設伺服器是可信的）。
​ 不幸的是，大多數系統不公開這種不確定性：例如，當呼叫`clock_gettime()`時，返回值不會告訴你時間戳的預期錯誤，所以你不知道其置信區間是5毫秒還是5年。
​ 一個有趣的例外是Spanner中的Google TrueTime API 【41】，它明確地報告了本地時鐘的置信區間。當你詢問當前時間時，你會得到兩個值：[最早，最晚]，這是最早可能的時間戳和最晚可能的時間戳。在不確定性估計的基礎上，時鐘知道當前的實際時間落在該區間內。區間的寬度取決於自從本地石英鐘最後與更精確的時鐘源同步以來已經過了多長時間。
#### 全域性快照的同步時鐘
​ 在“[快照隔離和可重複讀取](ch7.md#快照隔離和可重複讀取)”中，我們討論了快照隔離，這是資料庫中非常有用的功能，需要支援小型快速讀寫事務和大型長時間執行的只讀事務，用於備份或分析）。它允許只讀事務看到特定時間點的處於一致狀態的資料庫，且不會鎖定和干擾讀寫事務。
​ 快照隔離最常見的實現需要單調遞增的事務ID。如果寫入比快照晚（即，寫入具有比快照更大的事務ID），則該寫入對於快照事務是不可見的。在單節點資料庫上，一個簡單的計數器就足以生成事務ID。
​ 但是當資料庫分佈在許多機器上，也許可能在多個數據中心中時，由於需要協調，（跨所有分割槽）全域性單調遞增的事務ID會很難生成。事務ID必須反映因果關係：如果事務B讀取由事務A寫入的值，則B必須具有比A更大的事務ID，否則快照就無法保持一致。在有大量的小規模、高頻率的事務情景下，在分散式系統中建立事務ID成為一個難以防守的瓶頸[^vi]。
[^vi]: 存在分散式序列號生成器，例如Twitter的雪花（Snowflake），其以可擴充套件的方式（例如，透過將ID空間的塊分配給不同節點）近似單調地增加唯一ID。但是，它們通常無法保證與因果關係一致的排序，因為分配的ID塊的時間範圍比資料庫讀取和寫入的時間範圍要長。另請參閱“[順序保證](#順序保證)”。
​ 我們可以使用同步時鐘的時間戳作為事務ID嗎？如果我們能夠獲得足夠好的同步性，那麼這種方法將具有很合適的屬性：更晚的事務會有更大的時間戳。當然，問題在於時鐘精度的不確定性。
​ Spanner以這種方式實現跨資料中心的快照隔離【59，60】。它使用TrueTime API報告的時鐘置信區間，並基於以下觀察結果：如果您有兩個置信區間，每個置信區間包含最早和最晚可能的時間戳（ $A = [A_{earliest}, A_{latest}]$， $B=[B_{earliest}, B_{latest}]$），這兩個區間不重疊（即：$A_{earliest} < A_{latest} < B_{earliest} < B_{latest}$）的話，那麼B肯定發生在A之後——這是毫無疑問的。只有當區間重疊時，我們才不確定A和B發生的順序。
​ 為了確保事務時間戳反映因果關係，在提交讀寫事務之前，Spanner在提交讀寫事務時，會故意等待置信區間長度的時間。透過這樣，它可以確保任何可能讀取資料的事務處於足夠晚的時間，因此它們的置信區間不會重疊。為了保持儘可能短的等待時間，Spanner需要保持儘可能小的時鐘不確定性，為此，Google在每個資料中心都部署了一個GPS接收器或原子鐘，這允許時鐘在大約7毫秒內同步【41】。
​ 對分散式事務語義使用時鐘同步是一個活躍的研究領域【57,61,62】。這些想法很有趣，但是它們還沒有在谷歌之外的主流資料庫中實現。
### 暫停程序
​ 讓我們考慮在分散式系統中使用危險時鐘的另一個例子。假設你有一個數據庫，每個分割槽只有一個領導者。只有領導被允許接受寫入。一個節點如何知道它仍然是領導者（它並沒有被別人宣告為死亡），並且它可以安全地接受寫入？
​ 一種選擇是領導者從其他節點獲得一個**租約（lease）**，類似一個帶超時的鎖【63】。任一時刻只有一個節點可以持有租約——因此，當一個節點獲得一個租約時，它知道它在某段時間內自己是領導者，直到租約到期。為了保持領導地位，節點必須週期性地在租約過期前續期。
​ 如果節點發生故障，就會停止續期，所以當租約過期時，另一個節點可以接管。
​ 可以想象，請求處理迴圈看起來像這樣：
```java
while(true){
request=getIncomingRequest();
// 確保租約還剩下至少10秒
if (lease.expiryTimeMillis-System.currentTimeMillis()< 10000){
lease = lease.renew();
}
if(lease.isValid()){
process(request);
}}
}
```
​  這個程式碼有什麼問題？首先，它依賴於同步時鐘：租約到期時間由另一臺機器設定（例如，當前時間加上30秒，計算到期時間），並將其與本地系統時鐘進行比較。如果時鐘超過幾秒不同步，這段程式碼將開始做奇怪的事情。
​ 其次，即使我們將協議更改為僅使用本地單調時鐘，也存在另一個問題：程式碼假定在執行剩餘時間檢查`System.currentTimeMillis()`和實際執行請求`process(request)`中間的時間間隔非常短。通常情況下，這段程式碼執行得非常快，所以10秒的緩衝區已經足夠確保**租約**在請求處理到一半時不會過期。
​ 但是，如果程式執行中出現了意外的停頓呢？例如，想象一下，執行緒在`lease.isValid()`行周圍停止15秒，然後才終止。在這種情況下，在請求被處理的時候，租約可能已經過期，而另一個節點已經接管了領導。然而，沒有什麼可以告訴這個執行緒已經暫停了這麼長時間了，所以這段程式碼不會注意到租約已經到期了，直到迴圈的下一個迭代 ——到那個時候它可能已經做了一些不安全的處理請求。
​ 假設一個執行緒可能會暫停很長時間，這是瘋了嗎？不幸的是，這種情況發生的原因有很多種：
* 許多程式語言執行時（如Java虛擬機器）都有一個垃圾收集器（GC），偶爾需要停止所有正在執行的執行緒。這些“**停止所有處理（stop-the-world）**”GC暫停有時會持續幾分鐘【64】！甚至像HotSpot JVM的CMS這樣的所謂的“並行”垃圾收集器也不能完全與應用程式程式碼並行執行，它需要不時地停止所有處理【65】。儘管通常可以透過改變分配模式或調整GC設定來減少暫停【66】，但是如果我們想要提供健壯的保證，就必須假設最壞的情況發生。
* 在虛擬化環境中，可以**掛起（suspend）**虛擬機器（暫停執行所有程序並將記憶體內容儲存到磁碟）並恢復（恢復記憶體內容並繼續執行）。這個暫停可以在程序執行的任何時候發生，並且可以持續任意長的時間。這個功能有時用於虛擬機器從一個主機到另一個主機的實時遷移，而不需要重新啟動，在這種情況下，暫停的長度取決於程序寫入記憶體的速率【67】。
* 在終端使用者的裝置（如膝上型電腦）上，執行也可能被暫停並隨意恢復，例如當用戶關閉膝上型電腦的蓋子時。
* 當作業系統上下文切換到另一個執行緒時，或者當管理程式切換到另一個虛擬機器時（在虛擬機器中執行時），當前正在執行的執行緒可以在程式碼中的任意點處暫停。在虛擬機器的情況下，在其他虛擬機器中花費的CPU時間被稱為**竊取時間（steal time）**。如果機器處於沉重的負載下（即，如果等待執行的執行緒很長），暫停的執行緒再次執行可能需要一些時間。
* 如果應用程式執行同步磁碟訪問，則執行緒可能暫停，等待緩慢的磁碟I/O操作完成【68】。在許多語言中，即使程式碼沒有包含檔案訪問，磁碟訪問也可能出乎意料地發生——例如，Java類載入器在第一次使用時惰性載入類檔案，這可能在程式執行過程中隨時發生。 I/O暫停和GC暫停甚至可能合謀組合它們的延遲【69】。如果磁碟實際上是一個網路檔案系統或網路塊裝置（如亞馬遜的EBS），I/O延遲進一步受到網路延遲變化的影響【29】。
* 如果作業系統配置為允許交換到磁碟（分頁），則簡單的記憶體訪問可能導致**頁面錯誤（page fault）**，要求將磁碟中的頁面裝入記憶體。當這個緩慢的I/O操作發生時，執行緒暫停。如果記憶體壓力很高，則可能需要將不同的頁面換出到磁碟。在極端情況下，作業系統可能花費大部分時間將頁面交換到記憶體中，而實際上完成的工作很少（這被稱為**抖動（thrashing）**）。為了避免這個問題，通常在伺服器機器上禁用頁面排程（如果你寧願幹掉一個程序來釋放記憶體，也不願意冒抖動風險）。
* 可以透過傳送SIGSTOP訊號來暫停Unix程序，例如透過在shell中按下Ctrl-Z。 這個訊號立即阻止程序繼續執行更多的CPU週期，直到SIGCONT恢復為止，此時它將繼續執行。 即使你的環境通常不使用SIGSTOP，也可能由運維工程師意外發送。
所有這些事件都可以隨時**搶佔（preempt）**正在執行的執行緒，並在稍後的時間恢復執行，而執行緒甚至不會注意到這一點。這個問題類似於在單個機器上使多執行緒程式碼執行緒安全：你不能對時機做任何假設，因為隨時可能發生上下文切換，或者出現並行執行。
​ 當在一臺機器上編寫多執行緒程式碼時，我們有相當好的工具來實現執行緒安全：互斥量，訊號量，原子計數器，無鎖資料結構，阻塞佇列等等。不幸的是，這些工具並不能直接轉化為分散式系統操作，因為分散式系統沒有共享記憶體，只有透過不可靠網路傳送的訊息。
​ 分散式系統中的節點，必須假定其執行可能在任意時刻暫停相當長的時間，即使是在一個函式的中間。在暫停期間，世界的其它部分在繼續運轉，甚至可能因為該節點沒有響應，而宣告暫停節點的死亡。最終暫停的節點可能會繼續執行，在再次檢查自己的時鐘之前，甚至可能不會意識到自己進入了睡眠。
#### 響應時間保證
​ 在許多程式語言和作業系統中，執行緒和程序可能暫停一段無限制的時間，正如討論的那樣。如果你足夠努力，導致暫停的原因是**可以**消除的。
​ 某些軟體的執行環境要求很高，不能在特定時間內響應可能會導致嚴重的損失：飛機主控計算機，火箭，機器人，汽車和其他物體的計算機必須對其感測器輸入做出快速而可預測的響應。在這些系統中，軟體必須有一個特定的**截止時間（deadline）**，如果截止時間不滿足，可能會導致整個系統的故障。這就是所謂的**硬實時（hard real-time）**系統。
> #### 實時是真的嗎？
>
> 在嵌入式系統中，實時是指系統經過精心設計和測試，以滿足所有情況下的特定時間保證。這個含義與Web上實時術語的模糊使用相反，它描述了伺服器將資料推送到客戶端以及流處理，而沒有嚴格的響應時間限制（見[第11章](ch11.md)）。
例如，如果車載感測器檢測到當前正在經歷碰撞，你肯定不希望安全氣囊釋放系統因為GC暫停而延遲彈出。
​ 在系統中提供**實時保證**需要各級軟體棧的支援：一個實時作業系統（RTOS），允許在指定的時間間隔內保證CPU時間的分配。庫函式必須記錄最壞情況下的執行時間；動態記憶體分配可能受到限制或完全不允許（實時垃圾收集器存在，但是應用程式仍然必須確保它不會給GC太多的負擔）；必須進行大量的測試和測量，以確保達到保證。
​ 所有這些都需要大量額外的工作，嚴重限制了可以使用的程式語言，庫和工具的範圍（因為大多數語言和工具不提供實時保證）。由於這些原因，開發實時系統非常昂貴，並且它們通常用於安全關鍵的嵌入式裝置。而且，“**實時**”與“**高效能**”不一樣——事實上，實時系統可能具有較低的吞吐量，因為他們必須優先考慮及時響應高於一切（另請參見“[延遲和資源利用](#延遲和資源利用)“）。
​ 對於大多數伺服器端資料處理系統來說，實時保證是不經濟或不合適的。因此，這些系統必須承受在非實時環境中執行的暫停和時鐘不穩定性。
#### 限制垃圾收集的影響
​ 過程暫停的負面影響可以在不訴諸昂貴的實時排程保證的情況下得到緩解。語言執行時在計劃垃圾回收時具有一定的靈活性，因為它們可以跟蹤物件分配的速度和隨著時間的推移剩餘的空閒記憶體。
​ 一個新興的想法是將GC暫停視為一個節點的短暫計劃中斷，並讓其他節點處理來自客戶端的請求，同時一個節點正在收集其垃圾。如果執行時可以警告應用程式一個節點很快需要GC暫停，那麼應用程式可以停止向該節點發送新的請求，等待它完成處理未完成的請求，然後在沒有請求正在進行時執行GC。這個技巧隱藏了來自客戶端的GC暫停，並降低了響應時間的高百分比【70,71】。一些對延遲敏感的金融交易系統【72】使用這種方法。
​ 這個想法的一個變種是隻用垃圾收集器來處理短命物件（這些物件要快速收集），並定期在積累大量長壽物件（因此需要完整GC）之前重新啟動程序【65,73】。一次可以重新啟動一個節點，在計劃重新啟動之前，流量可以從節點移開，就像[滾動升級](ch4.md#滾動升級)一樣。
​ 這些措施不能完全阻止垃圾回收暫停，但可以有效地減少它們對應用的影響。
## 知識、真相與謊言
​ 本章到目前為止，我們已經探索了分散式系統與執行在單臺計算機上的程式的不同之處：沒有共享記憶體，只有透過可變延遲的不可靠網路傳遞的訊息，系統可能遭受部分失效，不可靠的時鐘和處理暫停。
​ 如果你不習慣於分散式系統，那麼這些問題的後果就會讓人迷惑不解。網路中的一個節點無法確切地知道任何事情——它只能根據它透過網路接收到（或沒有接收到）的訊息進行猜測。節點只能透過交換訊息來找出另一個節點所處的狀態（儲存了哪些資料，是否正確執行等等）。如果遠端節點沒有響應，則無法知道它處於什麼狀態，因為網路中的問題不能可靠地與節點上的問題區分開來。
​ 這些系統的討論與哲學有關：在系統中什麼是真什麼是假？如果感知和測量的機制都是不可靠的，那麼關於這些知識我們又能多麼確定呢？軟體系統應該遵循我們對物理世界所期望的法則，如因果關係嗎？
​ 幸運的是，我們不需要去搞清楚生命的意義。在分散式系統中，我們可以陳述關於行為（系統模型）的假設，並以滿足這些假設的方式設計實際系統。演算法可以被證明在某個系統模型中正確執行。這意味著即使底層系統模型提供了很少的保證，也可以實現可靠的行為。
​ 但是，儘管可以使軟體在不可靠的系統模型中表現良好，但這並不是可以直截了當實現的。在本章的其餘部分中，我們將進一步探討分散式系統中的知識和真理的概念，這將有助於我們思考我們可以做出的各種假設以及我們可能希望提供的保證。在[第9章](ch9.md)中，我們將著眼於分散式系統的一些例子，這些演算法在特定的假設條件下提供了特定的保證。
### 真理由多數所定義
​ 設想一個具有不對稱故障的網路：一個節點能夠接收發送給它的所有訊息，但是來自該節點的任何傳出訊息被丟棄或延遲【19】。即使該節點執行良好，並且正在接收來自其他節點的請求，其他節點也無法聽到其響應。經過一段時間後，其他節點宣佈它已經死亡，因為他們沒有聽到節點的訊息。這種情況就像夢魘一樣：**半斷開（semi-disconnected）**的節點被拖向墓地，敲打尖叫道“我沒死！” ——但是由於沒有人能聽到它的尖叫，葬禮隊伍繼續以堅忍的決心繼續行進。
​ 在一個稍微不那麼夢魘的場景中，半斷開的節點可能會注意到它傳送的訊息沒有被其他節點確認，因此意識到網路中必定存在故障。儘管如此，節點被其他節點錯誤地宣告為死亡，而半連線的節點對此無能為力。
​ 第三種情況，想象一個經歷了一個長時間**停止所有處理垃圾收集暫停（stop-the-world GC Pause）**的節點。節點的所有執行緒被GC搶佔並暫停一分鐘，因此沒有請求被處理，也沒有響應被髮送。其他節點等待，重試，不耐煩，並最終宣佈節點死亡，並將其丟到靈車上。最後，GC完成，節點的執行緒繼續，好像什麼也沒有發生。其他節點感到驚訝，因為所謂的死亡節點突然從棺材中抬起頭來，身體健康，開始和旁觀者高興地聊天。GC後的節點最初甚至沒有意識到已經經過了整整一分鐘，而且自己已被宣告死亡。從它自己的角度來看，從最後一次與其他節點交談以來，幾乎沒有經過任何時間。
​ 這些故事的寓意是，節點不一定能相信自己對於情況的判斷。分散式系統不能完全依賴單個節點，因為節點可能隨時失效，可能會使系統卡死，無法恢復。相反，許多分散式演算法都依賴於法定人數，即在節點之間進行投票（參閱“[讀寫的法定人數](ch5.md#讀寫的法定人數)“）：決策需要來自多個節點的最小投票數，以減少對於某個特定節點的依賴。
​ 這也包括關於宣告節點死亡的決定。如果法定數量的節點宣告另一個節點已經死亡，那麼即使該節點仍感覺自己活著，它也必須被認為是死的。個體節點必須遵守法定決定並下臺。
​ 最常見的法定人數是超過一半的絕對多數（儘管其他型別的法定人數也是可能的）。多數法定人數允許系統繼續工作，如果單個節點發生故障（三個節點可以容忍單節點故障；五個節點可以容忍雙節點故障）。系統仍然是安全的，因為在這個制度中只能有一個多數——不能同時存在兩個相互衝突的多數決定。當我們在[第9章](ch9.md)中討論**共識演算法（consensus algorithms）**時，我們將更詳細地討論法定人數的應用。
#### 領導者和鎖
通常情況下，一些東西在一個系統中只能有一個。例如：
* 資料庫分割槽的領導者只能有一個節點，以避免**腦裂（split brain）**（參閱“[處理節點宕機](ch5.md#處理節點宕機)”）。
* 特定資源的鎖或物件只允許一個事務/客戶端持有，以防同時寫入和損壞。
* 一個特定的使用者名稱只能被一個使用者所註冊，因為使用者名稱必須唯一標識一個使用者。
在分散式系統中實現這一點需要注意：即使一個節點認為它是“**天選者（the choosen one）**”（分割槽的負責人，鎖的持有者，成功獲取使用者名稱的使用者的請求處理程式），但這並不一定意味著有法定人數的節點同意！一個節點可能以前是領導者，但是如果其他節點在此期間宣佈它死亡（例如，由於網路中斷或GC暫停），則它可能已被降級，且另一個領導者可能已經當選。
​ 如果一個節點繼續表現為**天選者**，即使大多數節點已經宣告它已經死了，則在考慮不周的系統中可能會導致問題。這樣的節點能以自己賦予的權能向其他節點發送訊息，如果其他節點相信，整個系統可能會做一些不正確的事情。
​ 例如，[圖8-4](../img/fig8-4.png)顯示了由於不正確的鎖實現導致的資料損壞錯誤。 （這個錯誤不僅僅是理論上的：HBase曾經有這個問題【74,75】）假設你要確保一個儲存服務中的檔案一次只能被一個客戶訪問，因為如果多個客戶試圖寫對此，該檔案將被損壞。您嘗試透過在訪問檔案之前要求客戶端從鎖定服務獲取租約來實現此目的。
![](../img/fig8-4.png)
**圖8-4 分散式鎖的實現不正確：客戶端1認為它仍然具有有效的租約，即使它已經過期，從而破壞了儲存中的檔案**
​ 這個問題就是我們先前在“[程序暫停](#程序暫停)”中討論過的一個例子：如果持有租約的客戶端暫停太久，它的租約將到期。另一個客戶端可以獲得同一檔案的租約，並開始寫入檔案。當暫停的客戶端回來時，它認為（不正確）它仍然有一個有效的租約，並繼續寫入檔案。結果，客戶的寫入衝突和損壞的檔案。
#### 防護令牌
​ 當使用鎖或租約來保護對某些資源（如[圖8-4](../img/fig8-4.png)中的檔案儲存）的訪問時，需要確保一個被誤認為自己是“天選者”的節點不能擾亂系統的其它部分。實現這一目標的一個相當簡單的技術就是**防護（fencing）**，如[圖8-5]()所示
![](../img/fig8-5.png)
**圖8-5 只允許以增加防護令牌的順序進行寫操作，從而保證儲存安全**
​ 我們假設每次鎖定伺服器授予鎖或租約時，它還會返回一個**防護令牌（fencing token）**，這個數字在每次授予鎖定時都會增加（例如，由鎖定服務增加）。然後，我們可以要求客戶端每次向儲存服務傳送寫入請求時，都必須包含當前的防護令牌。
​ 在[圖8-5](../img/fig8-5.png)中，客戶端1以33的令牌獲得租約，但隨後進入一個長時間的停頓並且租約到期。客戶端2以34的令牌（該數字總是增加）獲取租約，然後將其寫入請求傳送到儲存服務，包括34的令牌。稍後，客戶端1恢復生機並將其寫入儲存服務，包括其令牌值33.但是，儲存伺服器會記住它已經處理了一個具有更高令牌編號（34）的寫入，因此它會拒絕帶有令牌33的請求。
​ 如果將ZooKeeper用作鎖定服務，則可將事務標識`zxid`或節點版本`cversion`用作防護令牌。由於它們保證單調遞增，因此它們具有所需的屬性【74】。
​ 請注意，這種機制要求資源本身在檢查令牌方面發揮積極作用，透過拒絕使用舊的令牌，而不是已經被處理的令牌來進行寫操作——僅僅依靠客戶端檢查自己的鎖狀態是不夠的。對於不明確支援防護令牌的資源，可能仍然可以解決此限制（例如，在檔案儲存服務的情況下，可以將防護令牌包含在檔名中）。但是，為了避免在鎖的保護之外處理請求，需要進行某種檢查。
​ 在伺服器端檢查一個令牌可能看起來像是一個缺點，但這可以說是一件好事：一個服務假定它的客戶總是守規矩並不明智，因為使用客戶端的人與執行服務的人優先順序非常不一樣【76】。因此，任何服務保護自己免受意外客戶的濫用是一個好主意。
### 拜占庭故障
​ 防護令牌可以檢測和阻止無意中發生錯誤的節點（例如，因為它尚未發現其租約已過期）。但是，如果節點有意破壞系統的保證，則可以透過使用假防護令牌傳送訊息來輕鬆完成此操作。
​ 在本書中，我們假設節點是不可靠但誠實的：它們可能很慢或者從不響應（由於故障），並且它們的狀態可能已經過時（由於GC暫停或網路延遲），但是我們假設如果節點它做出了迴應，它正在說出“真相”：盡其所知，它正在按照協議的規則扮演其角色。
​ 如果存在節點可能“撒謊”（傳送任意錯誤或損壞的響應）的風險，則分散式系統的問題變得更困難了——例如，如果節點可能聲稱其實際上沒有收到特定的訊息。這種行為被稱為**拜占庭故障（Byzantine fault）**，**在不信任的環境中達成共識的問題被稱為拜占庭將軍問題**【77】。
> ### 拜占庭將軍問題
>
> ​ 拜占庭將軍問題是所謂“兩將軍問題”的概括【78】，它想象兩個將軍需要就戰鬥計劃達成一致的情況。由於他們在兩個不同的地點建立了營地，他們只能透過信使進行溝通，信使有時會被延遲或丟失（就像網路中的資訊包一樣）。我們將在[第9章](ch9.md)討論這個共識問題。
>
> ​ 在這個拜占庭式的問題中，有n位將軍需要同意，他們的努力因為有一些叛徒在他們中間而受到阻礙。大多數的將軍都是忠誠的，因而發出了真實的資訊，但是叛徒可能會試圖透過傳送虛假或不真實的資訊來欺騙和混淆他人（在試圖保持未被發現的同時）。事先並不知道叛徒是誰。
>
> ​ 拜占庭是後來成為君士坦丁堡的古希臘城市，現在在土耳其的伊斯坦布林。沒有任何歷史證據表明拜占庭將軍比其他地方更容易出現陰謀和陰謀。相反，這個名字來源於拜占庭式的過度複雜，官僚，迂迴等意義，早在計算機之前就已經在政治中被使用了【79】。Lamport想要選一個不會冒犯任何讀者的國家，他被告知將其稱為阿爾巴尼亞將軍問題並不是一個好主意【80】。
​ 當一個系統在部分節點發生故障、不遵守協議、甚至惡意攻擊、擾亂網路時仍然能繼續正確工作，稱之為**拜占庭容錯（Byzantine fault-tolerant）**的，在特定場景下，這種擔憂在是有意義的：
* 在航空航天環境中，計算機記憶體或CPU暫存器中的資料可能被輻射破壞，導致其以任意不可預知的方式響應其他節點。由於系統故障非常昂貴（例如，飛機撞毀和炸死船上所有人員，或火箭與國際空間站相撞），飛行控制系統必須容忍拜占庭故障【81,82】。
* 在多個參與組織的系統中，一些參與者可能會試圖欺騙或欺騙他人。在這種情況下，節點僅僅信任另一個節點的訊息是不安全的，因為它們可能是出於惡意的目的而被髮送的。例如，像比特幣和其他區塊鏈一樣的對等網路可以被認為是讓互不信任的各方同意交易是否發生的一種方式，而不依賴於中央當局【83】。
然而，在本書討論的那些系統中，我們通常可以安全地假設沒有拜占庭式的錯誤。在你的資料中心裡，所有的節點都是由你的組織控制的（所以他們可以信任），輻射水平足夠低，記憶體損壞不是一個大問題。製作拜占庭容錯系統的協議相當複雜【84】，而容錯嵌入式系統依賴於硬體層面的支援【81】。在大多數伺服器端資料系統中，部署拜占庭容錯解決方案的成本使其變得不切實際。
​ Web應用程式確實需要預期受終端使用者控制的客戶端（如Web瀏覽器）的任意和惡意行為。這就是為什麼輸入驗證，資料清洗和輸出轉義如此重要：例如，防止SQL注入和跨站點指令碼。但是，我們通常不使用拜占庭容錯協議，而只是讓伺服器決定什麼是客戶端行為，而不是允許的。在沒有這種中心授權的對等網路中，拜占庭容錯更為重要。
​ 軟體中的一個錯誤可能被認為是拜占庭式的錯誤，但是如果您將相同的軟體部署到所有節點上，那麼拜占庭式的容錯演算法不能為您節省。大多數拜占庭式容錯演算法要求超過三分之二的節點能夠正常工作（即，如果有四個節點，最多隻能有一個故障）。要使用這種方法對付bug，你必須有四個獨立的相同軟體的實現，並希望一個bug只出現在四個實現之一中。
​ 同樣，如果一個協議可以保護我們免受漏洞，安全妥協和惡意攻擊，那麼這將是有吸引力的。不幸的是，這也是不現實的：在大多數系統中，如果攻擊者可以滲透一個節點，那他們可能會滲透所有這些節點，因為它們可能執行相同的軟體。因此傳統機制（認證，訪問控制，加密，防火牆等）仍然是抵禦攻擊者的主要保護措施。
#### 弱謊言形式
​ 儘管我們假設節點通常是誠實的，但值得向軟體中新增防止“撒謊”弱形式的機制——例如，由硬體問題導致的無效訊息，軟體錯誤和錯誤配置。這種保護機制並不是完全的拜占庭容錯，因為它們不能抵擋決心堅定的對手，但它們仍然是簡單而實用的步驟，以提高可靠性。例如：
* 由於硬體問題或作業系統，驅動程式，路由器等中的錯誤，網路資料包有時會受到損壞。通常，內建於TCP和UDP中的校驗和會俘獲損壞的資料包，但有時它們會逃避檢測【85,86,87】 。簡單的措施通常是採用充分的保護來防止這種破壞，例如應用程式級協議中的校驗和。
* 可公開訪問的應用程式必須仔細清理來自使用者的任何輸入，例如檢查值是否在合理的範圍內，並限制字串的大小以防止透過大記憶體分配拒絕服務。防火牆後面的內部服務可能能夠在對輸入進行較不嚴格的檢查的情況下逃脫，但是一些基本的理智檢查（例如，在協議解析中）是一個好主意。
* NTP客戶端可以配置多個伺服器地址。同步時，客戶端聯絡所有的伺服器，估計它們的誤差，並檢查大多數伺服器是否在對某個時間範圍內達成一致。只要大多數的伺服器沒問題，一個配置錯誤的NTP伺服器報告的時間會被當成特異值從同步中排除【37】。使用多個伺服器使NTP更健壯（比起只用單個伺服器來）。
### 系統模型與現實
​ 已經有很多演算法被設計以解決分散式系統問題——例如，我們將在[第9章](ch9.md)討論共識問題的解決方案。為了有用，這些演算法需要容忍我們在本章中討論的分散式系統的各種故障。
​ 演算法的編寫方式並不過分依賴於執行的硬體和軟體配置的細節。這又要求我們以某種方式將我們期望在系統中發生的錯誤形式化。我們透過定義一個系統模型來做到這一點，這個模型是一個抽象，描述一個演算法可能承擔的事情。
關於定時假設，三種系統模型是常用的：
***同步模型***
​ **同步模型（synchronous model）**假設網路延遲，程序暫停和和時鐘誤差都是有界限的。這並不意味著完全同步的時鐘或零網路延遲；這隻意味著你知道網路延遲，暫停和時鐘漂移將永遠不會超過某個固定的上限【88】。同步模型並不是大多數實際系統的現實模型，因為（如本章所討論的）無限延遲和暫停確實會發生。
***部分同步模型***
​ **部分同步（partial synchronous）**意味著一個系統在大多數情況下像一個同步系統一樣執行，但有時候會超出網路延遲，程序暫停和時鐘漂移的界限【88】。這是很多系統的現實模型：大多數情況下，網路和程序表現良好，否則我們永遠無法完成任何事情，但是我們必須承認，在任何時刻假設都存在偶然被破壞的事實。發生這種情況時，網路延遲，暫停和時鐘錯誤可能會變得相當大。
***非同步模型***
​ 在這個模型中，一個演算法不允許對時機做任何假設——事實上它甚至沒有時鐘（所以它不能使用超時）。一些演算法被設計為可用於非同步模型，但非常受限。
進一步來說，除了時間問題，我們還要考慮**節點失效**。三種最常見的節點系統模型是：
***崩潰-停止故障***
​ 在**崩潰停止（crash-stop）**模型中，演算法可能會假設一個節點只能以一種方式失效，即透過崩潰。這意味著節點可能在任意時刻突然停止響應，此後該節點永遠消失——它永遠不會回來。
***崩潰-恢復故障***
​ 我們假設節點可能會在任何時候崩潰，但也許會在未知的時間之後再次開始響應。在**崩潰-恢復（crash-recovery）**模型中，假設節點具有穩定的儲存（即，非易失性磁碟儲存）且會在崩潰中保留，而記憶體中的狀態會丟失。
***拜占庭（任意）故障***
​ 節點可以做（絕對意義上的）任何事情，包括試圖戲弄和欺騙其他節點，如上一節所述。
對於真實系統的建模，具有**崩潰-恢復故障（crash-recovery）**的**部分同步模型（partial synchronous）**通常是最有用的模型。分散式演算法如何應對這種模型？
#### 演算法的正確性
​ 為了定義演算法是正確的，我們可以描述它的屬性。例如，排序演算法的輸出具有如下特性：對於輸出列表中的任何兩個不同的元素，左邊的元素比右邊的元素小。這只是定義對列表進行排序含義的一種形式方式。
​ 同樣，我們可以寫下我們想要的分散式演算法的屬性來定義它的正確含義。例如，如果我們正在為一個鎖生成防護令牌（參閱“[防護令牌](防護令牌)”），我們可能要求演算法具有以下屬性：
***唯一性***
​ 沒有兩個防護令牌請求返回相同的值。
***單調序列***
​ 如果請求 $x$ 返回了令牌 $t_x$，並且請求$y$返回了令牌$t_y$，並且 $x$ 在 $y$ 開始之前已經完成，那麼$t_x <t_y$。
***可用性***
​ 請求防護令牌並且不會崩潰的節點，最終會收到響應。
如果一個系統模型中的演算法總是滿足它在我們假設可能發生的所有情況下的性質，那麼這個演算法是正確的。但這如何有意義？如果所有的節點崩潰，或者所有的網路延遲突然變得無限長，那麼沒有任何演算法能夠完成任何事情。
#### 安全性和活性
​ 為了澄清這種情況，有必要區分兩種不同的性質：**安全性（safety）**和**活性（liveness）**。在剛剛給出的例子中，**唯一性（uniqueness）**和**單調序列（monotonic sequence）**是安全屬性，但**可用性**是**活性（liveness）**屬性。
​ 這兩種性質有什麼區別？一個試金石就是，活性屬性通常在定義中通常包括“**最終**”一詞。 （是的，你猜對了——最終一致性是一個活性屬性【89】。）
​ 安全性通常被非正式地定義為，**沒有壞事發生**，而活性通常就類似：**最終好事發生**。但是，最好不要過多地閱讀那些非正式的定義，因為好與壞的含義是主觀的。安全性和活性的實際定義是精確的和數學的【90】：
* 如果安全屬性被違反，我們可以指向一個特定的時間點（例如，如果違反了唯一性屬性，我們可以確定重複的防護令牌返回的特定操作） 。違反安全屬性後，違規行為不能撤銷——損失已經發生。
* 活性屬性反過來：在某個時間點（例如，一個節點可能傳送了一個請求，但還沒有收到響應），它可能不成立，但總是希望在未來（即透過接受答覆）。
區分安全性和活性屬性的一個優點是可以幫助我們處理困難的系統模型。對於分散式演算法，在系統模型的所有可能情況下，要求**始終**保持安全屬性是常見的【88】。也就是說，即使所有節點崩潰，或者整個網路出現故障，演算法仍然必須確保它不會返回錯誤的結果（即保證安全性得到滿足）。
​ 但是，對於活性屬性，我們可以提出一些注意事項：例如，只有在大多數節點沒有崩潰的情況下，只有當網路最終從中斷中恢復時，我們才可以說請求需要接收響應。部分同步模型的定義要求系統最終返回到同步狀態——即任何網路中斷的時間段只會持續一段有限的時間，然後進行修復。
#### 將系統模型對映到現實世界
​ 安全性和活性屬性以及系統模型對於推理分散式演算法的正確性非常有用。然而，在實踐中實施演算法時，現實的混亂事實再一次地讓你咬牙切齒，很明顯系統模型是對現實的簡化抽象。
​ 例如，在故障恢復模型中的演算法通常假設穩定儲存器中的資料經歷了崩潰。但是，如果磁碟上的資料被破壞，或者由於硬體錯誤或錯誤配置導致資料被清除，會發生什麼情況？如果伺服器存在韌體錯誤並且在重新啟動時無法識別其硬碟驅動器，即使驅動器已正確連線到伺服器，那又會發生什麼情況？
​ 法定人數演算法（參見“[讀寫法定人數](ch5.md#讀寫法定人數)”）依賴節點來記住它聲稱儲存的資料。如果一個節點可能患有健忘症，忘記了以前儲存的資料，這會打破法定條件，從而破壞演算法的正確性。也許需要一個新的系統模型，在這個模型中，我們假設穩定的儲存大多存在崩潰，但有時可能會丟失。但是那個模型就變得更難以推理了。
​ 演算法的理論描述可以簡單宣稱一些事在假設上是不會發生的——在非拜占庭式系統中。但實際上我們還是需要對可能發生和不可能發生的故障做出假設，真實世界的實現，仍然會包括處理“假設上不可能”情況的程式碼，即使程式碼可能就是`printf("you sucks")`和`exit(666)`，實際上也就是留給運維來擦屁股。（這可以說是電腦科學和軟體工程間的一個差異）。
​ 這並不是說理論上抽象的系統模型是毫無價值的，恰恰相反。它們對於將實際系統的複雜性降低到一個我們可以推理的可處理的錯誤是非常有幫助的，以便我們能夠理解這個問題，並試圖系統地解決這個問題。我們可以證明演算法是正確的，透過表明它們的屬性總是保持在某個系統模型中。
​ 證明演算法正確並不意味著它在真實系統上的實現必然總是正確的。但這邁出了很好的第一步，因為理論分析可以發現演算法中的問題，這種問題可能會在現實系統中長期潛伏，直到你的假設（例如，時間）因為不尋常的情況被打破。理論分析與經驗測試同樣重要。
## 本章小結
在本章中，我們討論了分散式系統中可能發生的各種問題，包括：
* 當您嘗試透過網路傳送資料包時，資料包可能會丟失或任意延遲。同樣，答覆可能會丟失或延遲，所以如果你沒有得到答覆，你不知道訊息是否透過。
* 節點的時鐘可能會與其他節點顯著不同步（儘管您盡最大努力設定NTP），它可能會突然跳轉或跳回，依靠它是很危險的，因為您很可能沒有好的測量你的時鐘的錯誤間隔。
* 一個程序可能會在其執行的任何時候暫停一段相當長的時間（可能是因為停止所有處理的垃圾收集器），被其他節點宣告死亡，然後再次復活，卻沒有意識到它被暫停了。
這類**部分失效**可能發生的事實是分散式系統的決定性特徵。每當軟體試圖做任何涉及其他節點的事情時，偶爾就有可能會失敗，或者隨機變慢，或者根本沒有響應（最終超時）。在分散式系統中，我們試圖在軟體中建立**部分失效**的容錯機制，這樣整個系統即使在某些組成部分被破壞的情況下，也可以繼續執行。
​ 為了容忍錯誤，第一步是**檢測**它們，但即使這樣也很難。大多數系統沒有檢測節點是否發生故障的準確機制，所以大多數分散式演算法依靠**超時**來確定遠端節點是否仍然可用。但是，超時無法區分網路失效和節點失效，並且可變的網路延遲有時會導致節點被錯誤地懷疑發生故障。此外，有時一個節點可能處於降級狀態：例如，由於驅動程式錯誤【94】，千兆網絡卡可能突然下降到1 Kb/s的吞吐量。這樣一個“跛行”而不是死掉的節點可能比一個乾淨的失效節點更難處理。
​ 一旦檢測到故障，使系統容忍它也並不容易：沒有全域性變數，沒有共享記憶體，沒有共同的知識，或機器之間任何其他種類的共享狀態。節點甚至不能就現在是什麼時間達成一致，就不用說更深奧的了。資訊從一個節點流向另一個節點的唯一方法是透過不可靠的網路傳送資訊。重大決策不能由一個節點安全地完成，因此我們需要一個能從其他節點獲得幫助的協議，並爭取達到法定人數以達成一致。
​ 如果你習慣於在理想化的數學完美（同一個操作總能確定地返回相同的結果）的單機環境中編寫軟體，那麼轉向分散式系統的凌亂的物理現實可能會有些令人震驚。相反，如果能夠在單臺計算機上解決一個問題，那麼分散式系統工程師通常會認為這個問題是平凡的【5】，現在單個計算機確實可以做很多事情【95】。如果你可以避免開啟潘多拉的盒子，把東西放在一臺機器上，那麼通常是值得的。
​ 但是，正如在[第二部分](part-ii.md)的介紹中所討論的那樣，可擴充套件性並不是使用分散式系統的唯一原因。容錯和低延遲（透過將資料放置在距離使用者較近的地方）是同等重要的目標，而這些不能用單個節點實現。
​ 在本章中，我們也轉換了幾次話題，探討了網路，時鐘和程序的不可靠性是否是不可避免的自然規律。我們看到這並不是：有可能給網路提供硬實時的響應保證和有限的延遲，但是這樣做非常昂貴，且導致硬體資源的利用率降低。大多數非安全關鍵系統會選擇**便宜而不可靠**，而不是**昂貴和可靠**。
​ 我們還談到了超級計算機，它們採用可靠的元件，因此當元件發生故障時必須完全停止並重新啟動。相比之下，分散式系統可以永久執行而不會在服務層面中斷，因為所有的錯誤和維護都可以在節點級別進行處理——至少在理論上是如此。 （實際上，如果一個錯誤的配置變更被應用到所有的節點，仍然會使分散式系統癱瘓）。
​ 本章一直在講存在的問題，給我們展現了一幅黯淡的前景。在[下一章](ch9.md)中，我們將繼續討論解決方案，並討論一些旨在解決分散式系統中所有問題的演算法。
## 參考文獻
1. Mark Cavage: Just No Getting Around It: You’re Building a Distributed System](http://queue.acm.org/detail.cfm?id=2482856),” *ACM Queue*, volume 11, number 4, pages 80-89, April 2013.
[doi:10.1145/2466486.2482856](http://dx.doi.org/10.1145/2466486.2482856)
1. Jay Kreps: “[Getting Real About Distributed System Reliability](http://blog.empathybox.com/post/19574936361/getting-real-about-distributed-system-reliability),” *blog.empathybox.com*, March 19, 2012.
1. Sydney Padua: *The Thrilling Adventures of Lovelace and Babbage: The (Mostly) True Story of the First Computer*. Particular Books, April ISBN: 978-0-141-98151-2
1. Coda Hale: “[You Can’t Sacrifice Partition Tolerance](http://codahale.com/you-cant-sacrifice-partition-tolerance/),” *codahale.com*, October 7, 2010.
1. Jeff Hodges: “[Notes on Distributed Systems for Young Bloods](http://www.somethingsimilar.com/2013/01/14/notes-on-distributed-systems-for-young-bloods/),” *somethingsimilar.com*, January 14, 2013.
1. Antonio Regalado: “[Who Coined 'Cloud Computing&#x2019;?](http://www.technologyreview.com/news/425970/who-coined-cloud-computing/),” *technologyreview.com*, October 31, 2011.
1. Luiz André Barroso, Jimmy Clidaras, and Urs Hölzle: “[The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines, Second Edition](http://www.morganclaypool.com/doi/abs/10.2200/S00516ED2V01Y201306CAC024),” *Synthesis Lectures on Computer Architecture*, volume 8, number 3, Morgan & Claypool Publishers, July 2013.[doi:10.2200/S00516ED2V01Y201306CAC024](http://dx.doi.org/10.2200/S00516ED2V01Y201306CAC024), ISBN: 978-1-627-05010-4
1. David Fiala, Frank Mueller, Christian Engelmann, et al.: “[Detection and Correction of Silent Data Corruption for Large-Scale High-Performance Computing](http://moss.csc.ncsu.edu/~mueller/ftp/pub/mueller/papers/sc12.pdf),” at *International Conference for High Performance Computing, Networking, Storage and Analysis* (SC12), November 2012.
1. Arjun Singh, Joon Ong, Amit Agarwal, et al.: “[Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google’s Datacenter Network](http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p183.pdf),” at *Annual Conference of the ACM Special Interest Group on Data Communication* (SIGCOMM), August 2015. [doi:10.1145/2785956.2787508](http://dx.doi.org/10.1145/2785956.2787508)
1. Glenn K. Lockwood: “[Hadoop's Uncomfortable Fit in HPC](http://glennklockwood.blogspot.co.uk/2014/05/hadoops-uncomfortable-fit-in-hpc.html),” *glennklockwood.blogspot.co.uk*, May 16, 2014.
1. John von Neumann: “[Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components](https://ece.uwaterloo.ca/~ssundara/courses/prob_logics.pdf),” in *Automata Studies (AM-34)*, edited by Claude E. Shannon and John McCarthy, Princeton University Press, 1956. ISBN: 978-0-691-07916-5
1. Richard W. Hamming: *The Art of Doing Science and Engineering*. Taylor & Francis, 1997. ISBN: 978-9-056-99500-3
1. Claude E. Shannon: “[A Mathematical Theory of Communication](http://cs.brynmawr.edu/Courses/cs380/fall2012/shannon1948.pdf),” *The Bell System Technical Journal*, volume 27, number 3, pages 379–423 and 623–656, July 1948.
1. Peter Bailis and Kyle Kingsbury: “[The Network Is Reliable](https://queue.acm.org/detail.cfm?id=2655736),” *ACM Queue*, volume 12, number 7, pages 48-55, July 2014. [doi:10.1145/2639988.2639988](http://dx.doi.org/10.1145/2639988.2639988)
1. Joshua B. Leners, Trinabh Gupta, Marcos K. Aguilera, and Michael Walfish: “[Taming Uncertainty in Distributed Systems with Help from the Network](http://www.cs.nyu.edu/~mwalfish/papers/albatross-eurosys15.pdf),” at *10th European Conference on Computer Systems* (EuroSys), April 2015. [doi:10.1145/2741948.2741976](http://dx.doi.org/10.1145/2741948.2741976)
1. Phillipa Gill, Navendu Jain, and Nachiappan Nagappan: “[Understanding Network Failures in Data Centers: Measurement, Analysis, and Implications](http://conferences.sigcomm.org/sigcomm/2011/papers/sigcomm/p350.pdf),” at *ACM SIGCOMM Conference*, August 2011.
[doi:10.1145/2018436.2018477](http://dx.doi.org/10.1145/2018436.2018477)
1. Mark Imbriaco: “[Downtime Last Saturday](https://github.com/blog/1364-downtime-last-saturday),” *github.com*, December 26, 2012.
1. Will Oremus: “[The Global Internet Is Being Attacked by Sharks, Google Confirms](http://www.slate.com/blogs/future_tense/2014/08/15/shark_attacks_threaten_google_s_undersea_internet_cables_video.html),” *slate.com*, August 15,
2014.
1. Marc A. Donges: “[Re: bnx2 cards Intermittantly Going Offline](http://www.spinics.net/lists/netdev/msg210485.html),” Message to Linux *netdev* mailing list, *spinics.net*, September 13, 2012.
1. Kyle Kingsbury: “[Call Me Maybe: Elasticsearch](https://aphyr.com/posts/317-call-me-maybe-elasticsearch),” *aphyr.com*, June 15, 2014.
1. Salvatore Sanfilippo: “[A Few Arguments About Redis Sentinel Properties and Fail Scenarios](http://antirez.com/news/80),” *antirez.com*, October 21, 2014.
1. Bert Hubert: “[The Ultimate SO_LINGER Page, or: Why Is My TCP Not Reliable](http://blog.netherlabs.nl/articles/2009/01/18/the-ultimate-so_linger-page-or-why-is-my-tcp-not-reliable),” *blog.netherlabs.nl*, January 18, 2009.
1. Nicolas Liochon: “[CAP: If All You Have Is a Timeout, Everything Looks Like a Partition](http://blog.thislongrun.com/2015/05/CAP-theorem-partition-timeout-zookeeper.html),” *blog.thislongrun.com*, May 25, 2015.
1. Jerome H. Saltzer, David P. Reed, and David D. Clark: “[End-To-End Arguments in System Design](http://www.ece.drexel.edu/courses/ECE-C631-501/SalRee1984.pdf),” *ACM Transactions on Computer Systems*, volume 2, number 4, pages 277–288, November 1984. [doi:10.1145/357401.357402](http://dx.doi.org/10.1145/357401.357402)
1. Matthew P. Grosvenor, Malte Schwarzkopf, Ionel Gog, et al.: “[Queues Don’t Matter When You Can JUMP Them!](https://www.usenix.org/system/files/conference/nsdi15/nsdi15-paper-grosvenor_update.pdf),” at *12th USENIX Symposium on Networked Systems Design and Implementation* (NSDI), May 2015.
1. Guohui Wang and T. S. Eugene Ng: “[The Impact of Virtualization on Network Performance of Amazon EC2 Data Center](http://www.cs.rice.edu/~eugeneng/papers/INFOCOM10-ec2.pdf),” at *29th IEEE International Conference on Computer Communications* (INFOCOM), March 2010. [doi:10.1109/INFCOM.2010.5461931](http://dx.doi.org/10.1109/INFCOM.2010.5461931)
1. Van Jacobson: “[Congestion Avoidance and Control](http://www.cs.usask.ca/ftp/pub/discus/seminars2002-2003/p314-jacobson.pdf),” at *ACM Symposium on Communications Architectures and Protocols* (SIGCOMM), August 1988. [doi:10.1145/52324.52356](http://dx.doi.org/10.1145/52324.52356)
1. Brandon Philips: “[etcd: Distributed Locking and Service Discovery](https://www.youtube.com/watch?v=HJIjTTHWYnE),” at *Strange Loop*, September 2014.
1. Steve Newman: “[A Systematic Look at EC2 I/O](http://blog.scalyr.com/2012/10/a-systematic-look-at-ec2-io/),” *blog.scalyr.com*, October 16, 2012.
1. Naohiro Hayashibara, Xavier Défago, Rami Yared, and Takuya Katayama: “[The ϕ Accrual Failure Detector](http://hdl.handle.net/10119/4784),” Japan Advanced Institute of Science and Technology, School of Information Science, Technical Report IS-RR-2004-010, May 2004.
1. Jeffrey Wang: “[Phi Accrual Failure Detector](http://ternarysearch.blogspot.co.uk/2013/08/phi-accrual-failure-detector.html),” *ternarysearch.blogspot.co.uk*, August 11, 2013.
1. Srinivasan Keshav: *An Engineering Approach to Computer Networking: ATM Networks, the Internet, and the Telephone Network*. Addison-Wesley Professional, May 1997. ISBN: 978-0-201-63442-6
1. Cisco, “[Integrated Services Digital Network](http://docwiki.cisco.com/wiki/Integrated_Services_Digital_Network),” *docwiki.cisco.com*.
1. Othmar Kyas: *ATM Networks*. International Thomson Publishing, 1995. ISBN: 978-1-850-32128-6
1. “[InfiniBand FAQ](http://www.mellanox.com/related-docs/whitepapers/InfiniBandFAQ_FQ_100.pdf),” Mellanox Technologies, December 22, 2014.
1. Jose Renato Santos, Yoshio Turner, and G. (John) Janakiraman: “[End-to-End Congestion Control for InfiniBand](http://www.hpl.hp.com/techreports/2002/HPL-2002-359.pdf),” at *22nd Annual Joint Conference of the IEEE Computer and Communications Societies* (INFOCOM), April 2003. Also published by HP Laboratories Palo
Alto, Tech Report HPL-2002-359. [doi:10.1109/INFCOM.2003.1208949](http://dx.doi.org/10.1109/INFCOM.2003.1208949)
1. Ulrich Windl, David Dalton, Marc Martinec, and Dale R. Worley: “[The NTP FAQ and HOWTO](http://www.ntp.org/ntpfaq/NTP-a-faq.htm),” *ntp.org*, November 2006.
1. John Graham-Cumming: “[How and why the leap second affected Cloudflare DNS](https://blog.cloudflare.com/how-and-why-the-leap-second-affected-cloudflare-dns/),” *blog.cloudflare.com*, January 1, 2017.
1. David Holmes: “[Inside the Hotspot VM: Clocks, Timers and Scheduling Events – Part I – Windows](https://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks),” *blogs.oracle.com*, October 2, 2006.
1. Steve Loughran: “[Time on Multi-Core, Multi-Socket Servers](http://steveloughran.blogspot.co.uk/2015/09/time-on-multi-core-multi-socket-servers.html),” *steveloughran.blogspot.co.uk*, September 17, 2015.
1. James C. Corbett, Jeffrey Dean, Michael Epstein, et al.: “[Spanner: Google’s Globally-Distributed Database](http://research.google.com/archive/spanner.html),” at *10th USENIX Symposium on Operating System Design and Implementation* (OSDI), October 2012.
1. M. Caporaloni and R. Ambrosini: “[How Closely Can a Personal Computer Clock Track the UTC Timescale Via the Internet?](https://iopscience.iop.org/0143-0807/23/4/103/),” *European Journal of Physics*, volume 23, number 4, pages L17–L21, June 2012. [doi:10.1088/0143-0807/23/4/103](http://dx.doi.org/10.1088/0143-0807/23/4/103)
1. Nelson Minar: “[A Survey of the NTP Network](http://alumni.media.mit.edu/~nelson/research/ntp-survey99/),” *alumni.media.mit.edu*, December 1999.
1. Viliam Holub: “[Synchronizing Clocks in a Cassandra Cluster Pt. 1 – The Problem](https://blog.logentries.com/2014/03/synchronizing-clocks-in-a-cassandra-cluster-pt-1-the-problem/),” *blog.logentries.com*, March 14, 2014.
1. Poul-Henning Kamp: “[The One-Second War (What Time Will You Die?)](http://queue.acm.org/detail.cfm?id=1967009),” *ACM Queue*, volume 9, number 4, pages 44–48, April 2011. [doi:10.1145/1966989.1967009](http://dx.doi.org/10.1145/1966989.1967009)
1. Nelson Minar: “[Leap Second Crashes Half the Internet](http://www.somebits.com/weblog/tech/bad/leap-second-2012.html),” *somebits.com*, July 3, 2012.
1. Christopher Pascoe: “[Time, Technology and Leaping Seconds](http://googleblog.blogspot.co.uk/2011/09/time-technology-and-leaping-seconds.html),” *googleblog.blogspot.co.uk*, September 15, 2011.
1. Mingxue Zhao and Jeff Barr: “[Look Before You Leap – The Coming Leap Second and AWS](https://aws.amazon.com/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/),” *aws.amazon.com*, May 18, 2015.
1. Darryl Veitch and Kanthaiah Vijayalayan: “[Network Timing and the 2015 Leap Second](http://crin.eng.uts.edu.au/~darryl/Publications/LeapSecond_camera.pdf),” at *17th International Conference on Passive and Active Measurement* (PAM), April 2016. [doi:10.1007/978-3-319-30505-9_29](http://dx.doi.org/10.1007/978-3-319-30505-9_29)
1. “[Timekeeping in VMware Virtual Machines](http://www.vmware.com/resources/techresources/238),” Information Guide, VMware, Inc., December 2011.
1. “[MiFID II / MiFIR: Regulatory Technical and Implementing Standards – Annex I (Draft)](https://www.esma.europa.eu/sites/default/files/library/2015/11/2015-esma-1464_annex_i_-_draft_rts_and_its_on_mifid_ii_and_mifir.pdf),”
European Securities and Markets Authority, Report ESMA/2015/1464, September 2015.
1. Luke Bigum: “[Solving MiFID II Clock Synchronisation With Minimum Spend (Part 1)](https://www.lmax.com/blog/staff-blogs/2015/11/27/solving-mifid-ii-clock-synchronisation-minimum-spend-part-1/),” *lmax.com*, November 27, 2015.
1. Kyle Kingsbury: “[Call Me Maybe: Cassandra](https://aphyr.com/posts/294-call-me-maybe-cassandra/),” *aphyr.com*, September 24, 2013.
1. John Daily: “[Clocks Are Bad, or, Welcome to the Wonderful World of Distributed Systems](http://basho.com/clocks-are-bad-or-welcome-to-distributed-systems/),” *basho.com*, November 12, 2013.
1. Kyle Kingsbury: “[The Trouble with Timestamps](https://aphyr.com/posts/299-the-trouble-with-timestamps),” *aphyr.com*, October 12, 2013.
1. Leslie Lamport: “[Time, Clocks, and the Ordering of Events in a Distributed System](http://research.microsoft.com/en-US/um/people/Lamport/pubs/time-clocks.pdf),” *Communications of the ACM*, volume 21, number 7, pages 558–565, July 1978. [doi:10.1145/359545.359563](http://dx.doi.org/10.1145/359545.359563)
1. Sandeep Kulkarni, Murat Demirbas, Deepak Madeppa, et al.: “[Logical Physical Clocks and Consistent Snapshots in Globally Distributed Databases](http://www.cse.buffalo.edu/tech-reports/2014-04.pdf),” State University of New York at Buffalo, Computer Science and Engineering Technical Report 2014-04, May 2014.
1. Justin Sheehy: “[There Is No Now: Problems With Simultaneity in Distributed Systems](https://queue.acm.org/detail.cfm?id=2745385),” *ACM Queue*, volume 13, number 3, pages 36–41, March 2015. [doi:10.1145/2733108](http://dx.doi.org/10.1145/2733108)
1. Murat Demirbas: “[Spanner: Google's Globally-Distributed Database](http://muratbuffalo.blogspot.co.uk/2013/07/spanner-googles-globally-distributed_4.html),” *muratbuffalo.blogspot.co.uk*, July 4, 2013.
1. Dahlia Malkhi and Jean-Philippe Martin: “[Spanner's Concurrency Control](http://www.cs.cornell.edu/~ie53/publications/DC-col51-Sep13.pdf),” *ACM SIGACT News*, volume 44, number 3, pages 73–77, September 2013. [doi:10.1145/2527748.2527767](http://dx.doi.org/10.1145/2527748.2527767)
1. Manuel Bravo, Nuno Diegues, Jingna Zeng, et al.: “[On the Use of Clocks to Enforce Consistency in the Cloud](http://sites.computer.org/debull/A15mar/p18.pdf),” *IEEE Data Engineering Bulletin*,
volume 38, number 1, pages 18–31, March 2015.
1. Spencer Kimball: “[Living Without Atomic Clocks](http://www.cockroachlabs.com/blog/living-without-atomic-clocks/),” *cockroachlabs.com*, February 17, 2016.
1. Cary G. Gray and David R. Cheriton:“[Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency](http://web.stanford.edu/class/cs240/readings/89-leases.pdf),” at *12th ACM Symposium on Operating Systems Principles* (SOSP), December 1989.
[doi:10.1145/74850.74870](http://dx.doi.org/10.1145/74850.74870)
1. Todd Lipcon: “[Avoiding Full GCs in Apache HBase with MemStore-Local Allocation Buffers: Part 1](http://blog.cloudera.com/blog/2011/02/avoiding-full-gcs-in-hbase-with-memstore-local-allocation-buffers-part-1/),”
*blog.cloudera.com*, February 24, 2011.
1. Martin Thompson: “[Java Garbage Collection Distilled](http://mechanical-sympathy.blogspot.co.uk/2013/07/java-garbage-collection-distilled.html),” *mechanical-sympathy.blogspot.co.uk*, July 16, 2013.
1. Alexey Ragozin: “[How to Tame Java GC Pauses? Surviving 16GiB Heap and Greater](http://java.dzone.com/articles/how-tame-java-gc-pauses),” *java.dzone.com*, June 28, 2011.
1. Christopher Clark, Keir Fraser, Steven Hand, et al.: “[Live Migration of Virtual Machines](http://www.cl.cam.ac.uk/research/srg/netos/papers/2005-nsdi-migration.pdf),” at *2nd USENIX Symposium on Symposium on Networked Systems Design & Implementation* (NSDI), May 2005.
1. Mike Shaver: “[fsyncers and Curveballs](http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/),” *shaver.off.net*, May 25, 2008.
1. Zhenyun Zhuang and Cuong Tran: “[Eliminating Large JVM GC Pauses Caused by Background IO Traffic](https://engineering.linkedin.com/blog/2016/02/eliminating-large-jvm-gc-pauses-caused-by-background-io-traffic),” *engineering.linkedin.com*, February 10, 2016.
1. David Terei and Amit Levy: “[Blade: A Data Center Garbage Collector](http://arxiv.org/pdf/1504.02578.pdf),” arXiv:1504.02578, April 13, 2015.
1. Martin Maas, Tim Harris, Krste Asanović, and John Kubiatowicz: “[Trash Day: Coordinating Garbage Collection in Distributed Systems](https://timharris.uk/papers/2015-hotos.pdf),” at *15th USENIX Workshop on Hot Topics in Operating Systems* (HotOS), May 2015.
1. “[Predictable Low Latency](http://cdn2.hubspot.net/hubfs/1624455/Website_2016/content/White%20papers/Cinnober%20on%20GC%20pause%20free%20Java%20applications.pdf),” Cinnober Financial Technology AB, *cinnober.com*, November 24, 2013.
1. Martin Fowler: “[The LMAX Architecture](http://martinfowler.com/articles/lmax.html),” *martinfowler.com*, July 12, 2011.
1. Flavio P. Junqueira and Benjamin Reed: *ZooKeeper: Distributed Process Coordination*. O'Reilly Media, 2013. ISBN: 978-1-449-36130-3
1. Enis Söztutar: “[HBase and HDFS: Understanding Filesystem Usage in HBase](http://www.slideshare.net/enissoz/hbase-and-hdfs-understanding-filesystem-usage),” at *HBaseCon*, June 2013.
1. Caitie McCaffrey: “[Clients Are Jerks: AKA How Halo 4 DoSed the Services at Launch & How We Survived](http://caitiem.com/2015/06/23/clients-are-jerks-aka-how-halo-4-dosed-the-services-at-launch-how-we-survived/),” *caitiem.com*, June 23, 2015.
1. Leslie Lamport, Robert Shostak, and Marshall Pease: “[The Byzantine Generals Problem](http://research.microsoft.com/en-us/um/people/lamport/pubs/byz.pdf),” *ACM Transactions on Programming Languages and Systems* (TOPLAS), volume 4, number 3, pages 382–401, July 1982. [doi:10.1145/357172.357176](http://dx.doi.org/10.1145/357172.357176)
1. Jim N. Gray: “[Notes on Data Base Operating Systems](http://research.microsoft.com/en-us/um/people/gray/papers/DBOS.pdf),” in *Operating Systems: An Advanced Course*, Lecture
Notes in Computer Science, volume 60, edited by R. Bayer, R. M. Graham, and G. Seegmüller,
pages 393–481, Springer-Verlag, 1978. ISBN: 978-3-540-08755-7
1. Brian Palmer: “[How Complicated Was the Byzantine Empire?](http://www.slate.com/articles/news_and_politics/explainer/2011/10/the_byzantine_tax_code_how_complicated_was_byzantium_anyway_.html),” *slate.com*, October 20, 2011.
1. Leslie Lamport: “[My Writings](http://research.microsoft.com/en-us/um/people/lamport/pubs/pubs.html),” *research.microsoft.com*, December 16, 2014. This page can be found by searching the web for the 23-character string obtained by removing the hyphens from the string `allla-mport-spubso-ntheweb`.
1. John Rushby: “[Bus Architectures for Safety-Critical Embedded Systems](http://www.csl.sri.com/papers/emsoft01/emsoft01.pdf),” at *1st International Workshop on Embedded Software* (EMSOFT), October 2001.
1. Jake Edge: “[ELC: SpaceX Lessons Learned](http://lwn.net/Articles/540368/),” *lwn.net*, March 6, 2013.
1. Andrew Miller and Joseph J. LaViola, Jr.: “[Anonymous Byzantine Consensus from Moderately-Hard Puzzles: A Model for Bitcoin](http://nakamotoinstitute.org/static/docs/anonymous-byzantine-consensus.pdf),” University of Central Florida, Technical Report CS-TR-14-01, April 2014.
1. James Mickens: “[The Saddest Moment](https://www.usenix.org/system/files/login-logout_1305_mickens.pdf),” *USENIX ;login: logout*, May 2013.
1. Evan Gilman: “[The Discovery of Apache ZooKeeper’s Poison Packet](http://www.pagerduty.com/blog/the-discovery-of-apache-zookeepers-poison-packet/),” *pagerduty.com*, May 7, 2015.
1. Jonathan Stone and Craig Partridge: “[When the CRC and TCP Checksum Disagree](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.27.7611&rep=rep1&type=pdf),” at *ACM Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication* (SIGCOMM), August 2000. [doi:10.1145/347059.347561](http://dx.doi.org/10.1145/347059.347561)
1. Evan Jones: “[How Both TCP and Ethernet Checksums Fail](http://www.evanjones.ca/tcp-and-ethernet-checksums-fail.html),” *evanjones.ca*, October 5, 2015.
1. Cynthia Dwork, Nancy Lynch, and Larry Stockmeyer: “[Consensus in the Presence of Partial Synchrony](http://www.net.t-labs.tu-berlin.de/~petr/ADC-07/papers/DLS88.pdf),” *Journal of the ACM*, volume 35, number 2, pages 288–323, April 1988. [doi:10.1145/42282.42283](http://dx.doi.org/10.1145/42282.42283)
1. Peter Bailis and Ali Ghodsi: “[Eventual Consistency Today: Limitations, Extensions, and Beyond](http://queue.acm.org/detail.cfm?id=2462076),” *ACM Queue*, volume 11, number 3, pages 55-63, March 2013. [doi:10.1145/2460276.2462076](http://dx.doi.org/10.1145/2460276.2462076)
1. Bowen Alpern and Fred B. Schneider: “[Defining Liveness](https://www.cs.cornell.edu/fbs/publications/DefLiveness.pdf),” *Information Processing Letters*, volume 21, number 4, pages 181–185, October 1985. [doi:10.1016/0020-0190(85)90056-0](http://dx.doi.org/10.1016/0020-0190(85)90056-0)
1. Flavio P. Junqueira: “[Dude, Where’s My Metadata?](http://fpj.me/2015/05/28/dude-wheres-my-metadata/),” *fpj.me*, May 28, 2015.
1. Scott Sanders: “[January 28th Incident Report](https://github.com/blog/2106-january-28th-incident-report),” *github.com*, February 3, 2016.
1. Jay Kreps: “[A Few Notes on Kafka and Jepsen](http://blog.empathybox.com/post/62279088548/a-few-notes-on-kafka-and-jepsen),” *blog.empathybox.com*, September 25, 2013.
1. Thanh Do, Mingzhe Hao, Tanakorn Leesatapornwongsa, et al.: “[Limplock: Understanding the Impact of Limpware on Scale-out Cloud Systems](http://ucare.cs.uchicago.edu/pdf/socc13-limplock.pdf),” at *4th ACM Symposium on Cloud Computing* (SoCC), October 2013. [doi:10.1145/2523616.2523627](http://dx.doi.org/10.1145/2523616.2523627)
1. Frank McSherry, Michael Isard, and Derek G. Murray: “[Scalability! But at What COST?](http://www.frankmcsherry.org/assets/COST.pdf),” at *15th USENIX Workshop on Hot Topics in Operating Systems* (HotOS), May 2015.
------
| 上一章 | 目錄 | 下一章 |
| ---------------------- | ------------------------------- | ------------------------------ |
| [第七章：事務](ch7.md) | [設計資料密集型應用](README.md) | [第九章：一致性與共識](ch9.md) |

1205
zh-tw/ch9.md Normal file
View File

File diff suppressed because it is too large Load Diff

35
zh-tw/colophon.md Normal file
View File

@ -0,0 +1,35 @@
# 後記
## 關於作者
**Martin Kleppmann**是英國劍橋大學分散式系統的研究員。此前他曾在網際網路公司擔任過軟體工程師和企業家，其中包括LinkedIn和Rapportive，負責大規模資料基礎架構。在這個過程中，他以艱難的方式學習了一些東西，他希望這本書能夠讓你避免重蹈覆轍。
Martin是一位常規會議演講者，博主和開源貢獻者。他認為，每個人都應該有深刻的技術理念，深層次的理解能幫助我們開發出更好的軟體。
![](http://martin.kleppmann.com/2017/03/ddia-poster.jpg)
## 關於譯者
[馮若航](https://vonng.com/about)
PostgreSQL DBA @ TanTan
Alibaba+-Finplus 架構師/全棧工程師 (2015 ~ 2017)
## 後記
《設計資料密集型應用》封面上的動物是**印度野豬（Sus scrofa cristatus）**，它是在印度、緬甸、尼泊爾、斯里蘭卡和泰國發現的一種野豬的亞種。與歐洲野豬不同，它們有更高的背部鬃毛，沒有體表絨毛，以及更大更直的頭骨。
印度的野豬有一頭灰色或黑色的頭髮，脊背上有短而硬的毛。雄性有突出的犬齒（稱為T），用來與對手戰鬥或抵禦掠食者。雄性比雌性大，這些物種平均肩高33-35英寸，體重200-300磅。他們的天敵包括熊、老虎和各種大型貓科動物。
這些動物夜行且雜食——它們吃各種各樣的東西，包括根、昆蟲、腐肉、堅果、漿果和小動物。野豬經常因為破壞農作物的根被人們所熟知，他們造成大量的破壞，並被農民所敵視。他們每天需要攝入4,000 ~ 4,500卡路里的能量。野豬有發達的嗅覺，這有助於尋找地下植物和挖掘動物。然而，它們的視力很差。
野豬在人類文化中一直具有重要意義。在印度教傳說中，野豬是毗溼奴神的化身。在古希臘的喪葬紀念碑中，它是一個勇敢失敗者的象徵（與勝利的獅子相反）。由於它的侵略，它被描繪在斯堪的納維亞、日耳曼和盎格魯撒克遜戰士的盔甲和武器上。在中國十二生肖中，它象徵著決心和急躁。
O'Reilly封面上的許多動物都受到威脅，這些動物對世界都很重要。要了解有關如何提供幫助的更多資訊，請訪問animals.oreilly.com。
封面圖片來自Shaw's Zoology。封面字型是URW Typewriter和Guardian Sans。文字字型是Adobe Minion Pro；圖中的字型是Adobe Myriad Pro；標題字型是Adobe Myriad Condensed；程式碼字型是Dalton Maag的Ubuntu Mono。

377
zh-tw/glossary.md Normal file
View File

@ -0,0 +1,377 @@
# 術語表 【DRAFT】
> 請注意，本術語表中的定義簡短而簡單，旨在傳達核心思想，而不是術語的完整細微之處。 有關更多詳細資訊，請參閱正文中的參考資料。
[TOC]
### 非同步（asynchronous）
不等待某些事情完成（例如，將資料傳送到網路中的另一個節點），並且不會假設要花多長時間。請參閱第153頁上的“同步與非同步複製”，第284頁上的“同步與非同步網路”，以及第306頁上的“系統模型與現實”。
### 原子（atomic）
1.在併發操作的上下文中：描述一個在單個時間點看起來生效的操作，所以另一個併發程序永遠不會遇到處於“半完成”狀態的操作。另見隔離。
2.在事務的上下文中：將一些寫入操作分為一組，這組寫入要麼全部提交成功，要麼遇到錯誤時全部回滾。參見第223頁的“原子性”和第354頁的“原子提交和兩階段提交（2PC）”。
### 背壓（backpressure）
接收方接收資料速度較慢時，強制降低傳送方的資料傳送速度。也稱為流量控制。請參閱第441頁上的“訊息系統”。
### 批處理（batch process）
一種計算，它將一些固定的（通常是大的）資料集作為輸入，並將其他一些資料作為輸出，而不修改輸入。見第十章。
### 邊界（bounded）
有一些已知的上限或大小。例如，網路延遲情況（請參閱“超時和未定義的延遲”在本頁281）和資料集（請參閱第11章的介紹）。
### 拜占庭故障（Byzantine fault）
表現異常的節點，這種異常可能以任意方式出現，例如向其他節點發送矛盾或惡意訊息。請參閱第304頁上的“拜占庭故障”。
### 快取（cache）
一種元件，透過儲存最近使用過的資料，加快未來對相同資料的讀取速度。快取中通常存放部分資料：因此，如果快取中缺少某些資料，則必須從某些底層較慢的資料儲存系統中，獲取完整的資料副本。
### CAP定理（CAP theorem）
一個被廣泛誤解的理論結果，在實踐中是沒有用的。參見第336頁的“CAP定理”。
### 因果關係（causality）
事件之間的依賴關係，當一件事發生在另一件事情之前。例如，後面的事件是對早期事件的迴應，或者依賴於更早的事件，或者應該根據先前的事件來理解。請參閱第186頁上的“發生之前的關係和併發性”和第339頁上的“排序和因果關係”。
### 共識（consensus）
分散式計算的一個基本問題，就是讓幾個節點同意某些事情（例如，哪個節點應該是資料庫叢集的領導者）。問題比乍看起來要困難得多。請參閱第364頁上的“容錯共識”。
### 資料倉庫（data warehouse）
一個數據庫，其中來自幾個不同的OLTP系統的資料已經被合併和準備用於分析目的。請參閱第91頁上的“資料倉庫”。
### 宣告式（declarative）
描述某些東西應有的屬性，但不知道如何實現它的確切步驟。在查詢的上下文中，查詢最佳化器採用宣告性查詢並決定如何最好地執行它。請參閱第42頁上的“資料的查詢語言”。
### 非規範化（denormalize）
為了加速讀取，在標準資料集中引入一些冗餘或重複資料，通常採用快取或索引的形式。非規範化的值是一種預先計算的查詢結果，像物化檢視。請參見“單物件和多物件操作”（第228頁）和“從同一事件日誌中派生多個檢視”（第461頁）。
### 衍生資料（derived data）
一種資料集，根據其他資料透過可重複執行的流程建立。必要時，你可以執行該流程再次建立衍生資料。衍生資料通常用於提高特定資料的讀取速度。常見的衍生資料有索引、快取和物化檢視。參見第三部分的介紹。
### 確定性（deterministic）
描述一個函式，如果給它相同的輸入，則總是產生相同的輸出。這意味著它不能依賴於隨機數字、時間、網路通訊或其他不可預測的事情。
### 分散式（distributed）
在由網路連線的多個節點上執行。對於部分節點故障，具有容錯性：系統的一部分發生故障時，其他部分仍可以正常工作，通常情況下，軟體無需瞭解故障相關的確切情況。請參閱第274頁上的“故障和部分故障”。
### 持久（durable）
以某種方式儲存資料，即使發生各種故障，也不會丟失資料。請參閱第226頁上的“永續性”。
### ETL（Extract-Transform-Load）
提取-轉換-載入（Extract-Transform-Load）。從源資料庫中提取資料，將其轉換為更適合分析查詢的形式，並將其載入到資料倉庫或批處理系統中的過程。請參閱第91頁上的“資料倉庫”。
### 故障切換（failover）
在具有單一領導者的系統中，故障切換是將領導角色從一個節點轉移到另一個節點的過程。請參閱第156頁的“處理節點故障”。
### 容錯（fault-tolerant）
如果出現問題（例如，機器崩潰或網路連線失敗），可以自動恢復。請參閱第6頁上的“可靠性”。
### 流量控制（flow control）
見背壓（backpressure）。
### 追隨者（follower）
一種資料副本，僅處理領導者發出的資料變更，不直接接受來自客戶端的任何寫入。也稱為輔助、僕從、只讀副本或熱備份。請參閱第152頁上的“領導和追隨者”。
### 全文檢索（full-text search）
透過任意關鍵字來搜尋文字，通常具有附加特徵，例如匹配類似的拼寫詞或同義詞。全文索引是一種支援這種查詢的次級索引。請參閱第88頁上的“全文搜尋和模糊索引”。
### 圖（graph）
一種資料結構，由頂點（可以指向的東西，也稱為節點或實體）和邊（從一個頂點到另一個頂點的連線，也稱為關係或弧）組成。請參閱第49頁上的“和圖相似的資料模型”。
### 雜湊（hash）
將輸入轉換為看起來像隨機數值的函式。相同的輸入會轉換為相同的數值，不同的輸入一般會轉換為不同的數值，也可能轉換為相同數值（也被稱為衝突）。請參閱第203頁的“根據鍵的雜湊值分隔”。
### 冪等（idempotent）
用於描述一種操作可以安全地重試執行，即執行多次的效果和執行一次的效果相同。請參閱第478頁的“冪等”。
### 索引（index）
一種資料結構。透過索引，你可以根據特定欄位的值，在所有資料記錄中進行高效檢索。請參閱第70頁的“讓資料庫更強大的資料結構”。
### 隔離性（isolation）
在事務上下文中，用於描述併發執行事務的互相干擾程度。序列執行具有最強的隔離性，不過其它程度的隔離也通常被使用。請參閱第225頁的“隔離”。
### 連線（join）
彙集有共同點的記錄。在一個記錄與另一個記錄有關（外來鍵，文件參考，圖中的邊）的情況下最常用，查詢需要獲取參考所指向的記錄。請參閱第33頁上的“多對一和多對多關係”和第393頁上的“減少端連線和分組”。
### 領導者（leader）
當資料或服務被複制到多個節點時，由領導者分發已授權變更的資料副本。領導者可以透過某些協議選舉產生，也可以由管理者手動選擇。也被稱為主人。請參閱第152頁的“領導者和追隨者”。
### 線性化（linearizable）
表現為系統中只有一份透過原子操作更新的資料副本。請參閱第324頁的“線性化”。
### 區域性性（locality）
一種效能最佳化方式，如果經常在相同的時間請求一些離散資料，把這些資料放到一個位置。請參閱第41頁的“請求資料的區域性性”。
### 鎖（lock）
一種保證只有一個執行緒、節點或事務可以訪問的機制，如果其它執行緒、節點或事務想訪問相同元素，則必須等待鎖被釋放。請參閱第257頁的“兩段鎖（2PL）”和301頁的“領導者和鎖”。
### 日誌（log）
日誌是一個只能以追加方式寫入的檔案，用於存放資料。預寫式日誌用於在儲存引擎崩潰時恢復資料（請參閱第82頁的“使二叉樹更穩定”）；結構化日誌儲存引擎使用日誌作為它的主要儲存格式（請參閱第76頁的“有序字串表和日誌結構的合併樹”）；複製型日誌用於把寫入從領導者複製到追隨者（請參閱第152頁的“領導者和追隨者”）；事件性日誌可以表現為資料流（請參閱第446頁的“分段日誌”）。
### 物化（materialize）
急切地計算並寫出結果，而不是在請求時計算。請參閱第101頁的“聚合：資料立方和物化檢視”和419頁的“中間狀態的物化”。
### 節點（node）
計算機上執行的一些軟體的例項，透過網路與其他節點通訊以完成某項任務。
### 規範化（normalized）
以沒有冗餘或重複的方式進行結構化。 在規範化資料庫中，當某些資料發生變化時，您只需要在一個地方進行更改，而不是在許多不同的地方複製很多次。 請參閱第33頁上的“多對一和多對多關係”。
### OLAP（Online Analytic Processing）
線上分析處理。 透過對大量記錄進行聚合（例如，計數，總和，平均）來表徵的訪問模式。 請參閱第90頁上的“交易處理或分析？”。
### OLTP（Online Transaction Processing）
線上事務處理。 訪問模式的特點是快速查詢，讀取或寫入少量記錄，這些記錄通常透過鍵索引。 請參閱第90頁上的“交易處理或分析？”。
### 分割槽（partitioning）
將單機上的大型資料集或計算結果拆分為較小部分，並將其分佈到多臺機器上。 也稱為分片。 見第6章。
### 百分位點（percentile）
透過計算有多少值高於或低於某個閾值來衡量值分佈的方法。 例如，某個時間段的第95個百分位響應時間是時間t，則該時間段中，95％的請求完成時間小於t，5％的請求完成時間要比t長。 請參閱第13頁上的“描述效能”。
### 主鍵（primary key）
唯一標識記錄的值（通常是數字或字串）。 在許多應用程式中，主鍵由系統在建立記錄時生成（例如，按順序或隨機）; 它們通常不由使用者設定。 另請參閱二級索引。
### 法定人數（quorum）
在操作完成之前，需要對操作進行投票的最少節點數量。 請參閱第179頁上的“讀寫的法定人數”。
### 再平衡（rebalance）
將資料或服務從一個節點移動到另一個節點以實現負載均衡。 請參閱第209頁上的“再平衡分割槽”。
### 複製（replication）
在幾個節點（副本）上保留相同資料的副本，以便在某些節點無法訪問時，資料仍可訪問。請參閱第5章。
### 模式（schema）
一些資料結構的描述，包括其欄位和資料型別。 可以在資料生命週期的不同點檢查某些資料是否符合模式（請參閱第39頁上的“文件模型中的模式靈活性”），模式可以隨時間變化（請參閱第4章）。
### 次級索引（secondary index）
與主要資料儲存器一起維護的附加資料結構，使您可以高效地搜尋與某種條件相匹配的記錄。 請參閱第85頁上的“其他索引結構”和第206頁上的“分割槽和二級索引”。
### 可序列化（serializable）
保證多個併發事務同時執行時，它們的行為與按順序逐個執行事務相同。 請參閱第251頁上的“可序列化”。
### 無共享（shared-nothing）
與共享記憶體或共享磁碟架構相比，獨立節點（每個節點都有自己的CPU，記憶體和磁碟）透過傳統網路連線。 見第二部分的介紹。
### 偏斜（skew）
1.各分割槽負載不平衡，例如某些分割槽有大量請求或資料，而其他分割槽則少得多。也被稱為熱點。請參閱第205頁上的“工作負載偏斜和減輕熱點”和第407頁上的“處理偏斜”。
2.時間線異常導致事件以不期望的順序出現。 請參閱第237頁上的“快照隔離和可重複讀取”中的關於讀取偏斜的討論，第246頁上的“寫入偏斜和模糊”中的寫入偏斜以及第291頁上的“訂購事件的時間戳”中的時鐘偏斜。
### 腦裂（split brain）
兩個節點同時認為自己是領導者的情況，這種情況可能違反系統擔保。 請參閱第156頁的“處理節點中斷”和第300頁的“真相由多數定義”。
### 儲存過程（stored procedure）
一種對事務邏輯進行編碼的方式，它可以完全在資料庫伺服器上執行，事務執行期間無需與客戶端通訊。 請參閱第252頁的“實際序列執行”。
### 流處理（stream process）
持續執行的計算。可以持續接收事件流作為輸入，並得出一些輸出。 見第11章。
### 同步（synchronous）
非同步的反義詞。
### 記錄系統（system of record）
一個儲存主要權威版本資料的系統，也被稱為真相的來源。首先在這裡寫入資料變更，其他資料集可以從記錄系統衍生。 參見第三部分的介紹。
### 超時（timeout）
檢測故障的最簡單方法之一，即在一段時間內觀察是否缺乏響應。 但是，不可能知道超時是由於遠端節點的問題還是網路中的問題造成的。 請參閱第281頁上的“超時和無限延遲”。
### 全序（total order）
一種比較事物的方法（例如時間戳），可以讓您總是說出兩件事中哪一件更大，哪件更小。 總的來說，有些東西是無法比擬的（不能說哪個更大或更小）的順序稱為偏序。 請參見第341頁的“因果順序不是全序”。
### 事務（transaction）
為了簡化錯誤處理和併發問題，將幾個讀寫操作分組到一個邏輯單元中。 見第7章。
### 兩階段提交（2PC, two-phase commit）
一種確保多個數據庫節點全部提交或全部中止事務的演算法。 請參閱第354頁上的“原子提交和兩階段提交（2PC）”。
### 兩階段鎖定（2PL, two-phase locking）
一種用於實現可序列化隔離的演算法，該演算法透過事務獲取對其讀取或寫入的所有資料的鎖，直到事務結束。 請參閱第257頁上的“兩階段鎖定（2PL）”。
### 無邊界（unbounded）
沒有任何已知的上限或大小。 反義詞是邊界（bounded）。

29
zh-tw/part-i.md Normal file
View File

@ -0,0 +1,29 @@
# 第一部分 資料系統的基石
本書前四章介紹了資料系統底層的基礎概念，無論是在單臺機器上執行的單點資料系統，還是分佈在多臺機器上的分散式資料系統都適用。
1. [第一章](ch1.md)將介紹本書使用的術語和方法。**可靠性，可擴充套件性和可維護性** ，這些詞彙到底意味著什麼？如何實現這些目標？
2. [第二章](ch2.md)將對幾種不同的**資料模型和查詢語言**進行比較。從程式設計師的角度看，這是資料庫之間最明顯的區別。不同的資料模型適用於不同的應用場景。
3. [第三章](ch3.md)將深入**儲存引擎**內部，研究資料庫如何在磁碟上擺放資料。不同的儲存引擎針對不同的負載進行最佳化，選擇合適的儲存引擎對系統性能有巨大影響。
4. [第四章](ch4)將對幾種不同的 **資料編碼**進行比較。特別研究了這些格式在應用需求經常變化、模式需要隨時間演變的環境中表現如何。
第二部分將專門討論在**分散式資料系統**中特有的問題。
## 目錄
1. [可靠性、可擴充套件性、可維護性](ch1.md)
2. [資料模型與查詢語言](ch2.md)
3. [儲存與檢索](ch3.md)
4. [編碼與演化](ch4.md)
------
| 上一章 | 目錄 | 下一章 |
| ------------------ | ------------------------------- | -------------------------------------------- |
| [序言](preface.md) | [設計資料密集型應用](README.md) | [第一章：可靠性、可擴充套件性、可維護性](ch1.md) |

100
zh-tw/part-ii.md Normal file
View File

@ -0,0 +1,100 @@
# 第二部分： 分散式資料
> 一個成功的技術，現實的優先順序必須高於公關，你可以糊弄別人，但糊弄不了自然規律。
>
> ——羅傑斯委員會報告（1986）
>
-------
在本書的[第一部分](part-i.md)中，我們討論了資料系統的各個方面，但僅限於資料儲存在單臺機器上的情況。現在我們到了[第二部分](part-ii.md)，進入更高的層次，並提出一個問題：如果**多臺機器**參與資料的儲存和檢索，會發生什麼？
你可能會出於各種各樣的原因，希望將資料庫分佈到多臺機器上：
***可擴充套件性***
如果你的資料量、讀取負載、寫入負載超出單臺機器的處理能力，可以將負載分散到多臺計算機上。
***容錯/高可用性***
如果你的應用需要在單臺機器（或多臺機器，網路或整個資料中心）出現故障的情況下仍然能繼續工作，則可使用多臺機器，以提供冗餘。一臺故障時，另一臺可以接管。
***延遲***
如果在世界各地都有使用者，你也許會考慮在全球範圍部署多個伺服器，從而每個使用者可以從地理上最近的資料中心獲取服務，避免了等待網路資料包穿越半個世界。
### 擴充套件至更高的載荷
如果你需要的只是擴充套件至更高的**載荷（load）**，最簡單的方法就是購買更強大的機器（有時稱為**垂直擴充套件（vertical scaling）**或**向上擴充套件（scale up）**）。許多處理器，記憶體和磁碟可以在同一個作業系統下相互連線，快速的相互連線允許任意處理器訪問記憶體或磁碟的任意部分。在這種**共享記憶體架構（shared-memory architecture）**中，所有的元件都可以看作一臺單獨的機器。
[^i]: 在大型機中，儘管任意處理器都可以訪問記憶體的任意部分，但總有一些記憶體區域與一些處理器更接近（稱為**非均勻記憶體訪問（nonuniform memory access, NUMA）**【1】）。 為了有效利用這種架構特性，需要對處理進行細分，以便每個處理器主要訪問臨近的記憶體，這意味著即使表面上看起來只有一臺機器在執行，**分割槽（partitioning）**仍然是必要的。
共享記憶體方法的問題在於，成本增長速度快於線性增長：一臺有著雙倍處理器數量，雙倍記憶體大小，雙倍磁碟容量的機器，通常成本會遠遠超過原來的兩倍。而且可能因為存在瓶頸，並不足以處理雙倍的載荷。
共享記憶體架構可以提供有限的容錯能力，高階機器可以使用熱插拔的元件（不關機更換磁碟，記憶體模組，甚至處理器）——但它必然囿於單個地理位置的桎梏。
另一種方法是**共享磁碟架構（shared-disk architecture）**，它使用多臺具有獨立處理器和記憶體的機器，但將資料儲存在機器之間共享的磁碟陣列上，這些磁碟透過快速網路連線[^ii]。這種架構用於某些資料倉庫，但競爭和鎖定的開銷限制了共享磁碟方法的可擴充套件性【2】。
[^ii]: 網路附屬儲存（Network Attached Storage, NAS），或**儲存區網路（Storage Area Network, SAN）**
#### 無共享架構
相比之下，**無共享架構（shared-nothing architecture）**（有時稱為**水平擴充套件（horizontal scale）** 或**向外擴充套件（scale out）**）已經相當普及。在這種架構中，執行資料庫軟體的每臺機器/虛擬機器都稱為**節點（node）**。每個節點只使用各自的處理器，記憶體和磁碟。節點之間的任何協調，都是在軟體層面使用傳統網路實現的。
無共享系統不需要使用特殊的硬體，所以你可以用任意機器——比如價效比最好的機器。你也許可以跨多個地理區域分佈資料從而減少使用者延遲，或者在損失一整個資料中心的情況下倖免於難。隨著雲端虛擬機器部署的出現，即使是小公司，現在無需Google級別的運維，也可以實現異地分散式架構。
在這一部分裡，我們將重點放在無共享架構上。它不見得是所有場景的最佳選擇，但它是最需要你謹慎從事的架構。如果你的資料分佈在多個節點上，你需要意識到這樣一個分散式系統中約束和權衡 ——資料庫並不能魔術般地把這些東西隱藏起來。
雖然分散式無共享架構有許多優點，但它通常也會給應用帶來額外的複雜度，有時也會限制你可用資料模型的表達力。在某些情況下，一個簡單的單執行緒程式可以比一個擁有超過100個CPU核的叢集表現得更好【4】。另一方面，無共享系統可以非常強大。接下來的幾章，將詳細討論分散式資料會帶來的問題。
### 複製 vs 分割槽
資料分佈在多個節點上有兩種常見的方式：
***複製（Replication）***
​ 在幾個不同的節點上儲存資料的相同副本，可能放在不同的位置。 複製提供了冗餘：如果一些節點不可用，剩餘的節點仍然可以提供資料服務。 複製也有助於改善效能。 [第五章](ch5.md)將討論複製。
***分割槽 (Partitioning)***
​ 將一個大型資料庫拆分成較小的子集（稱為**分割槽（partitions）**），從而不同的分割槽可以指派給不同的**節點（node）**（亦稱**分片（shard）**）。 [第六章](ch6.md)將討論分割槽。
複製和分割槽是不同的機制，但它們經常同時使用。如[圖II-1](../img/figii-1.png)所示。
![](../img/figii-1.png)
**圖II-1 一個數據庫切分為兩個分割槽，每個分割槽都有兩個副本**
理解了這些概念，就可以開始討論在分散式系統中需要做出的困難抉擇。[第七章](ch7.md)將討論**事務(Transaction)**，這對於瞭解資料系統中可能出現的各種問題，以及我們可以做些什麼很有幫助。[第八章](ch8.md)和[第九章](ch9.md)將討論分散式系統的根本侷限性。
在本書的[第三部分](part-iii.md)中，將討論如何將多個（可能是分散式的）資料儲存整合為一個更大的系統，以滿足複雜的應用需求。 但首先，我們來聊聊分散式的資料。
## 索引
5. [複製](ch5.md)
6. [分片](ch6.md)
7. [事務](ch7.md)
8. [分散式系統的麻煩](ch8.md)
9. [一致性與共識](ch9.md)
## 參考文獻
1. Ulrich Drepper: “[What Every Programmer Should Know About Memory](https://people.freebsd.org/~lstewart/articles/cpumemory.pdf),” akka‐dia.org, November 21, 2007.
2. Ben Stopford: “[Shared Nothing vs. Shared Disk Architectures: An Independent View](http://www.benstopford.com/2009/11/24/understanding-the-shared-nothing-architecture/),” benstopford.com, November 24, 2009.
3. Michael Stonebraker: “[The Case for Shared Nothing](http://db.cs.berkeley.edu/papers/hpts85-nothing.pdf),” IEEE Database EngineeringBulletin, volume 9, number 1, pages 4–9, March 1986.
4. Frank McSherry, Michael Isard, and Derek G. Murray: “[Scalability! But at What COST?](http://www.frankmcsherry.org/assets/COST.pdf),” at 15th USENIX Workshop on Hot Topics in Operating Systems (HotOS),May 2015.
------
| 上一章 | 目錄 | 下一章 |
| ---------------------------- | ------------------------------- | ---------------------- |
| [第四章：編碼與演化](ch4.md) | [設計資料密集型應用](README.md) | [第五章：複製](ch5.md) |

44
zh-tw/part-iii.md Normal file
View File

@ -0,0 +1,44 @@
# 第三部分：衍生資料
在本書的[第一部分](part-i.md)和[第二部分](part-ii.md)中，我們自底向上地把所有關於分散式資料庫的主要考量都過了一遍。從資料在磁碟上的佈局，一直到出現故障時分散式系統一致性的侷限。但所有的討論都假定了應用中只用了一種資料庫。
現實世界中的資料系統往往更為複雜。大型應用程式經常需要以多種方式訪問和處理資料，沒有一個數據庫可以同時滿足所有這些不同的需求。因此應用程式通常組合使用多種元件：資料儲存，索引，快取，分析系統，等等，並實現在這些元件中移動資料的機制。
本書的最後一部分，會研究將多個不同資料系統（可能有著不同資料模型，並針對不同的訪問模式進行最佳化）整合為一個協調一致的應用架構時，會遇到的問題。軟體供應商經常會忽略這一方面的生態建設，並聲稱他們的產品能夠滿足你的所有需求。在現實世界中，整合不同的系統是實際應用中最重要的事情之一。
## 記錄和衍生資料系統
從高層次上看，儲存和處理資料的系統可以分為兩大類：
#### 記錄系統（System of record）
**記錄系統**，也被稱為**真相源（source of truth）**，持有資料的權威版本。當新的資料進入時（例如，使用者輸入）首先會記錄在這裡。每個事實正正好好表示一次（表示通常是**標準化的（normalized）**）。如果其他系統和**記錄系統**之間存在任何差異，那麼記錄系統中的值是正確的（根據定義）。
#### 衍生資料系統（Derived data systems）
**衍生系統**中的資料，通常是另一個系統中的現有資料以某種方式進行轉換或處理的結果。如果丟失衍生資料，可以從原始來源重新建立。典型的例子是**快取（cache）**：如果資料在快取中，就可以由快取提供服務；如果快取不包含所需資料，則降級由底層資料庫提供。非規範化的值，索引和物化檢視亦屬此類。在推薦系統中，預測彙總資料通常衍生自使用者日誌。
從技術上講，衍生資料是**冗餘的（redundant）**，因為它重複了已有的資訊。但是衍生資料對於獲得良好的只讀查詢效能通常是至關重要的。它通常是非規範化的。可以從單個源頭衍生出多個不同的資料集，使你能從不同的“視角”洞察資料。
並不是所有的系統都在其架構中明確區分**記錄系統**和**衍生資料系統**，但是這是一種有用的區分方式，因為它明確了系統中的資料流：系統的哪一部分具有哪些輸入和哪些輸出，以及它們如何相互依賴。
大多數資料庫，儲存引擎和查詢語言，本質上既不是記錄系統也不是衍生系統。資料庫只是一個工具：如何使用它取決於你自己。**記錄系統和衍生資料系統之間的區別不在於工具，而在於應用程式中的使用方式。**
透過梳理資料的衍生關係，可以清楚地理解一個令人困惑的系統架構。這將貫穿本書的這一部分。
## 章節概述
我們將從[第十章](ch10.md)開始，研究例如MapReduce這樣**面向批處理（batch-oriented）**的資料流系統。對於建設大規模資料系統，我們將看到，它們提供了優秀的工具和思想。[第十一章](ch11.md)將把這些思想應用到**流式資料（data streams）**中，使我們能用更低的延遲完成同樣的任務。[第十二章](ch12.md)將對本書進行總結，探討如何使用這些工具來構建可靠，可擴充套件和可維護的應用。
## 索引
10. [批處理](ch10.md)
11. [流處理](ch11.md)
12. [資料系統的未來](ch12.md)
------
| 上一章 | 目錄 | 下一章 |
| ------------------------------ | ------------------------------- | ------------------------- |
| [第九章：一致性與共識](ch9.md) | [設計資料密集型應用](README.md) | [第十章：批處理](ch10.md) |

102
zh-tw/preface.md Normal file
View File

@ -0,0 +1,102 @@
# 序言
如果近幾年從業於軟體工程，特別是伺服器端和後端系統開發，那麼您很有可能已經被大量關於資料儲存和處理的時髦詞彙轟炸過了： NoSQL！大資料！Web-Scale！分片！最終一致性！ACID！ CAP定理！雲服務！MapReduce！實時！
在最近十年中，我們看到了很多有趣的進展，關於資料庫，分散式系統，以及在此基礎上構建應用程式的方式。這些進展有著各種各樣的驅動力：
* 谷歌，雅虎，亞馬遜，臉書，領英，微軟和推特等網際網路公司正在和巨大的流量/資料打交道，這迫使他們去創造能有效應對如此規模的新工具。
* 企業需要變得敏捷，需要低成本地檢驗假設，需要透過縮短開發週期和保持資料模型的靈活性，快速地響應新的市場洞察。
* 免費和開源軟體變得非常成功，在許多環境中比商業軟體和定製軟體更受歡迎。
* 處理器主頻幾乎沒有增長，但是多核處理器已經成為標配，網路也越來越快。這意味著並行化程度只增不減。
* 即使您在一個小團隊中工作，現在也可以構建分佈在多臺計算機甚至多個地理區域的系統，這要歸功於譬如亞馬遜網路服務（AWS）等基礎設施即服務（IaaS）概念的踐行者。
* 許多服務都要求高可用，因停電或維護導致的服務不可用，變得越來越難以接受。
**資料密集型應用（data-intensive applications）**正在透過使用這些技術進步來推動可能性的邊界。一個應用被稱為**資料密集型**的，如果**資料是其主要挑戰**（資料量，資料複雜度或資料變化速度）—— 與之相對的是**計算密集型**，即處理器速度是其瓶頸。
幫助資料密集型應用儲存和處理資料的工具與技術，正迅速地適應這些變化。新型資料庫系統（“NoSQL”）已經備受關注，而訊息佇列，快取，搜尋索引，批處理和流處理框架以及相關技術也非常重要。很多應用組合使用這些工具與技術。
這些生意盎然的時髦詞彙體現出人們對新的可能性的熱情，這是一件好事。但是作為軟體工程師和架構師，如果要開發優秀的應用，我們還需要對各種層出不窮的技術及其利弊權衡有精準的技術理解。為了獲得這種洞察，我們需要深挖時髦詞彙背後的內容。
幸運的是，在技術迅速變化的背後總是存在一些持續成立的原則，無論您使用了特定工具的哪個版本。如果您理解了這些原則，就可以領會這些工具的適用場景，如何充分利用它們，以及如何避免其中的陷阱。這正是本書的初衷。
本書的目標是幫助您在飛速變化的資料處理和資料儲存技術大觀園中找到方向。本書並不是某個特定工具的教程，也不是一本充滿枯燥理論的教科書。相反，我們將看到一些成功資料系統的樣例：許多流行應用每天都要在生產中會滿足可擴充套件性、效能、以及可靠性的要求，而這些技術構成了這些應用的基礎。
我們將深入這些系統的內部，理清它們的關鍵演算法，討論背後的原則和它們必須做出的權衡。在這個過程中，我們將嘗試尋找**思考**資料系統的有效方式 —— 不僅關於它們**如何**工作，還包括它們**為什麼**以這種方式工作，以及哪些問題是我們需要問的。
閱讀本書後，你能很好地決定哪種技術適合哪種用途，並瞭解如何將工具組合起來，為一個良好應用架構奠定基礎。本書並不足以使你從頭開始構建自己的資料庫儲存引擎，不過幸運的是這基本上很少有必要。你將獲得對系統底層發生事情的敏銳直覺，這樣你就有能力推理它們的行為，做出優秀的設計決策，並追蹤任何可能出現的問題。
## 本書的目標讀者
如果你開發的應用具有用於儲存或處理資料的某種伺服器/後端系統，而且使用網路（例如，Web應用，移動應用或連線到網際網路的感測器），那麼本書就是為你準備的。
本書是為軟體工程師，軟體架構師，以及喜歡寫程式碼的技術經理準備的。如果您需要對所從事系統的架構做出決策 —— 例如您需要選擇解決某個特定問題的工具，並找出如何最好地使用這些工具，那麼這本書對您尤有價值。但即使你無法選擇你的工具，本書仍將幫助你更好地瞭解所使用工具的長處和短處。
您應當具有一些開發Web應用或網路服務的經驗，且應當熟悉關係型資料庫和SQL。任何您瞭解的非關係型資料庫和其他與資料相關工具都會有所幫助，但不是必需的。對常見網路協議如TCP和HTTP的大概理解是有幫助的。程式語言或框架的選擇對閱讀本書沒有任何不同影響。
如果以下任意一條對您為真，你會發現這本書很有價值：
* 您想了解如何使資料系統可擴充套件，例如，支援擁有數百萬使用者的Web或移動應用。
* 您需要提高應用程式的可用性（最大限度地減少停機時間），保持穩定執行。
* 您正在尋找使系統在長期執行過程易於維護的方法，即使系統規模增長，需求與技術也發生變化。
* 您對事物的運作方式有著天然的好奇心，並且希望知道一些主流網站和線上服務背後發生的事情。這本書打破了各種資料庫和資料處理系統的內幕，探索這些系統設計中的智慧是非常有趣的。
有時在討論可擴充套件的資料系統時，人們會說：“你又不在谷歌或亞馬遜，別操心可擴充套件性了，直接上關係型資料庫”。這個陳述有一定的道理：為了不必要的擴充套件性而設計程式，不僅會浪費不必要的精力，並且可能會把你鎖死在一個不靈活的設計中。實際上這是一種“過早最佳化”的形式。不過，選擇合適的工具確實很重要，而不同的技術各有優缺點。我們將看到，關係資料庫雖然很重要，但絕不是資料處理的終章。
## 本書涉及的領域
本書並不會嘗試告訴讀者如何安裝或使用特定的軟體包或API，因為已經有大量文件給出了詳細的使用說明。相反，我們會討論資料系統的基石——各種原則與利弊權衡，並探討了不同產品所做出的不同設計決策。
在電子書中包含了線上資源全文的連結。所有連結在出版時都進行了驗證，但不幸的是，由於網路的自然規律，連結往往會頻繁地破損。如果您遇到連結斷開的情況，或者正在閱讀本書的列印副本，可以使用搜索引擎查詢參考文獻。對於學術論文，您可以在Google學術中搜索標題，查詢可以公開獲取的PDF檔案。或者，您也可以在 https://github.com/ept/ddia-references 中找到所有的參考資料，我們在那兒維護最新的連結。
我們主要關注的是資料系統的**架構（architecture）**，以及它們被整合到資料密集型應用中的方式。本書沒有足夠的空間覆蓋部署，運維，安全，管理等領域 —— 這些都是複雜而重要的主題，僅僅在本書中用粗略的註解討論這些對它們很不公平。每個領域都值得用單獨的書去講。
本書中描述的許多技術都被涵蓋在 **大資料（Big Data）** 這個時髦詞的範疇中。然而“大資料”這個術語被濫用，缺乏明確定義，以至於在嚴肅的工程討論中沒有用處。這本書使用歧義更小的術語，如“單節點”之於”分散式系統“，或”線上/互動式系統“之於”離線/批處理系統“。
本書對 **自由和開源軟體（FOSS）** 有一定偏好，因為閱讀，修改和執行原始碼是瞭解某事物詳細工作原理的好方法。開放的平臺也可以降低供應商壟斷的風險。然而在適當的情況下，我們也會討論專利軟體（閉源軟體，軟體即服務 SaaS，或一些在文獻中描述過但未公開發行的公司內部軟體）。
## 本書綱要
本書分為三部分：
1. 在[第一部分](part-i.md)中，我們會討論設計資料密集型應用所賴的基本思想。我們從[第1章](ch1.md)開始，討論我們實際要達到的目標：可靠性，可擴充套件性和可維護性；我們該如何思考這些概念；以及如何實現它們。在[第2章](ch2.md)中，我們比較了幾種不同的資料模型和查詢語言，看看它們如何適用於不同的場景。在[第3章](ch3.md)中將討論儲存引擎：資料庫如何在磁碟上擺放資料，以便能高效地再次找到它。[第4章](ch4.md)轉向資料編碼（序列化），以及隨時間演化的模式。
2. 在[第二部分](part-ii.md)中，我們從討論儲存在一臺機器上的資料轉向討論分佈在多臺機器上的資料。這對於可擴充套件性通常是必需的，但帶來了各種獨特的挑戰。我們首先討論複製（[第5章](ch5.md)），分割槽/分片（[第6章](ch6.md)）和事務（[第7章](ch7.md)）。然後我們將探索關於分散式系統問題的更多細節（[第8章](ch8.md)），以及在分散式系統中實現一致性與共識意味著什麼（[第9章](ch9.md)）。
3. 在[第三部分](part-iii.md)中，我們討論那些從其他資料集衍生出一些資料集的系統。衍生資料經常出現在異構系統中：當沒有單個數據庫可以把所有事情都做的很好時，應用需要整合幾種不同的資料庫，快取，索引等。在[第10章](ch10.md)中我們將從一種衍生資料的批處理方法開始，然後在此基礎上建立在[第11章](ch11.md)中討論的流處理。最後，在[第12章](ch12.md)中，我們將所有內容彙總，討論在將來構建可靠，可伸縮和可維護的應用程式的方法。
## 參考文獻與延伸閱讀
本書中討論的大部分內容已經在其它地方以某種形式出現過了 —— 會議簡報，研究論文，部落格文章，程式碼，BUG跟蹤器，郵件列表，以及工程習慣中。本書總結了不同來源資料中最重要的想法，並在文字中包含了指向原始文獻的連結。 如果你想更深入地探索一個領域，那麼每章末尾的參考文獻都是很好的資源，其中大部分可以免費線上獲取。
## O‘Reilly Safari
[Safari](http://oreilly.com/safari) (formerly Safari Books Online) is a membership-based training and reference platform for enterprise, government, educators, and individuals.
Members have access to thousands of books, training videos, Learning Paths, interac‐ tive tutorials, and curated playlists from over 250 publishers, including O’Reilly Media, Harvard Business Review, Prentice Hall Professional, Addison-Wesley Pro‐ fessional, Microsoft Press, Sams, Que, Peachpit Press, Adobe, Focal Press, Cisco Press, John Wiley & Sons, Syngress, Morgan Kaufmann, IBM Redbooks, Packt, Adobe Press, FT Press, Apress, Manning, New Riders, McGraw-Hill, Jones & Bartlett, and Course Technology, among others.
For more information, please visit http://oreilly.com/safari.
## 致謝
本書融合了學術研究和工業實踐的經驗，融合並系統化了大量其他人的想法與知識。在計算領域，我們往往會被各種新鮮花樣所吸引，但我認為前人完成的工作中，有太多值得我們學習的地方了。本書有800多處引用：文章，部落格，講座，文件等，對我來說這些都是寶貴的學習資源。我非常感謝這些材料的作者分享他們的知識。
我也從與人交流中學到了很多東西，很多人花費了寶貴的時間與我討論想法並耐心解釋。特別感謝 Joe Adler, Ross Anderson, Peter Bailis, Márton Balassi, Alastair Beresford, Mark Callaghan, Mat Clayton, Patrick Collison, Sean Cribbs, Shirshanka Das, Niklas Ekström, Stephan Ewen, Alan Fekete, Gyula Fóra, Camille Fournier, Andres Freund, John Garbutt, Seth Gilbert, Tom Haggett, Pat Hel‐ land, Joe Hellerstein, Jakob Homan, Heidi Howard, John Hugg, Julian Hyde, Conrad Irwin, Evan Jones, Flavio Junqueira, Jessica Kerr, Kyle Kingsbury, Jay Kreps, Carl Lerche, Nicolas Liochon, Steve Loughran, Lee Mallabone, Nathan Marz, Caitie McCaffrey, Josie McLellan, Christopher Meiklejohn, Ian Meyers, Neha Narkhede, Neha Narula, Cathy O’Neil, Onora O’Neill, Ludovic Orban, Zoran Perkov, Julia Powles, Chris Riccomini, Henry Robinson, David Rosenthal, Jennifer Rullmann, Matthew Sackman, Martin Scholl, Amit Sela, Gwen Shapira, Greg Spurrier, Sam Stokes, Ben Stopford, Tom Stuart, Diana Vasile, Rahul Vohra, Pete Warden, 以及 Brett Wooldridge.
更多人透過審閱草稿並提供反饋意見在本書的創作過程中做出了無價的貢獻。我要特別感謝Raul Agepati, Tyler Akidau, Mattias Andersson, Sasha Baranov, Veena Basavaraj, David Beyer, Jim Brikman, Paul Carey, Raul Castro Fernandez, Joseph Chow, Derek Elkins, Sam Elliott, Alexander Gallego, Mark Grover, Stu Halloway, Heidi Howard, Nicola Kleppmann, Stefan Kruppa, Bjorn Madsen, Sander Mak, Stefan Podkowinski, Phil Potter, Hamid Ramazani, Sam Stokes, 以及Ben Summers。當然對於本書中的任何遺留錯誤或難以接受的見解，我都承擔全部責任。
為了幫助這本書落地，並且耐心地處理我緩慢的寫作和不尋常的要求，我要對編輯Marie Beaugureau，Mike Loukides，Ann Spencer和O'Reilly的所有團隊表示感謝。我要感謝Rachel Head幫我找到了合適的術語。我要感謝Alastair Beresford，Susan Goodhue，Neha Narkhede和Kevin Scott，在其他工作事務之外給了我充分地創作時間和自由。
特別感謝Shabbir Diwan和Edie Freedman，他們非常用心地為各章配了地圖。他們提出了不落俗套的靈感，創作了這些地圖，美麗而引人入勝，真是太棒了。
最後我要表達對家人和朋友們的愛，沒有他們，我將無法走完這個將近四年的寫作歷程。你們是最棒的。