在技術(shù)方面，我自己熱衷于 Open Source，寫了很多 Open Source 的東西，擅長的是 Infrastructure 領(lǐng)域。Infrastructure 領(lǐng)域現(xiàn)在范圍很廣，比如說很典型的分布式 Scheduler、Mesos、Kubernetes，另外它和 Microservices 所結(jié)合的東西也特別多。Infrastructure 領(lǐng)域還有比如 Database 有分 AP（分析型）和 TP（事務型），比如說很典型的大家知道的 Spark、Greenplum、Apache Phoenix 等等，這些都屬于在 AP 的，它們也會去嘗試支持有限的 TP。另外，還有一個比較有意思的就是 Kudu——Cloudera Open Source 的那個項目，它的目標很有意思：我不做最強的 AP 系統(tǒng)，也不做最強的 TP 系統(tǒng)，我選擇一個相對折中的方案。從文化哲學上看，它比較符合中國的中庸思想。

另外，我先后創(chuàng)建了 Codis、TiDB。去年12月份創(chuàng)建了 TiKV 這個 project，TiKV 在所有的 rust 項目里目前排名前三。

首先我們聊聊 Database 的歷史，在已經(jīng)有這么多種數(shù)據(jù)庫的背景下我們?yōu)槭裁匆獎?chuàng)建另外一個數(shù)據(jù)庫；以及說一下現(xiàn)在方案遇到的困境，說一下 Google Spanner 和 F1、TiKV 和 TiDB，說一下架構(gòu)的事情，在這里我們會重點聊一下 TiKV。因為我們產(chǎn)品的很多特性是 TiKV 提供的，比如說跨數(shù)據(jù)中心的復制、Transaction、auto-scale。

接下來聊一下為什么 TiKV 用 Raft 能實現(xiàn)所有這些重要的特性，以及 scale、MVCC 和事務模型。東西非常多，我今天不太可能把里面的技術(shù)細節(jié)都描述得特別細，因為幾乎每一個話題都可以找到一篇或者是多篇論文，所以詳細的技術(shù)問題大家可以單獨來找我聊。

后面再說一下我們現(xiàn)在遇到的窘境，就是大家常規(guī)遇到的分布式方案有哪些問題，比如 MySQL Sharding。我們創(chuàng)建了無數(shù) MySQL Proxy，比如官方的 MySQL proxy、Youtube 的 Vitess、淘寶的 Cobar、TDDL以及基于 Cobar 的 MyCAT、金山的 Kingshard、360 的 Atlas、京東的 JProxy，我在豌豆莢也寫了一個。可以說，隨便一個大公司都會造一個 MySQL Sharding 的方案。

為什么我們要創(chuàng)建另外一個數(shù)據(jù)庫？

昨天晚上我還跟一個同學聊到，基于 MySQL 的方案它的天花板在哪里，它的天花板特別明顯。有一個思路是能不能通過 MySQL 的 server 把 InnoDB 變成一個分布式數(shù)據(jù)庫，聽起來這個方案很完美，但是很快就會遇到天花板。因為 MySQL 生成的執(zhí)行計劃是個單機的，它認為整個計劃的 cost 也是單機的，我讀取一行和讀取下一行之間的開銷是很小的，比如迭代 next row 可以立刻拿到下一行。實際上在一個分布式系統(tǒng)里面，這是不一定的。

另外，你把數(shù)據(jù)都拿回來計算這個太慢了，很多時候我們需要把我們的 expression 或者計算過程等等運算推下去，向上返回一個最終的計算結(jié)果，這個一定要用分布式的 plan，前面控制執(zhí)行計劃的節(jié)點，它必須要理解下面是分布式的東西，才能生成最好的 plan，這樣才能實現(xiàn)最高的執(zhí)行效率。

比如說你做一個 sum，你是一條條拿回來加，還是讓一堆機器一起算，最后給我一個結(jié)果。 例如我有 100 億條數(shù)據(jù)分布在 10 臺機器上，并行在這 10臺機器我可能只拿到 10 個結(jié)果，如果把所有的數(shù)據(jù)每一條都拿回來，這就太慢了，完全喪失了分布式的價值。聊到 MySQL 想實現(xiàn)分布式，另外一個實現(xiàn)分布式的方案就是 Proxy。但是 Proxy 本身的天花板在那里，就是它不支持分布式的 transaction，它不支持跨節(jié)點的 join，它無法理解復雜的 plan，一個復雜的 plan 打到 Proxy 上面，Proxy 就傻了，我到底應該往哪一個節(jié)點上轉(zhuǎn)發(fā)呢，如果我涉及到 subquery sql 怎么辦？所以這個天花板是瞬間會到，在傳統(tǒng)模型下面的修改，很快會達不到我們的要求。

另外一個很重要的是，MySQL 支持的復制方式是半同步或者是異步，但是半同步可以降級成異步，也就是說任何時候數(shù)據(jù)出了問題你不敢切換，因為有可能是異步復制，有一部分數(shù)據(jù)還沒有同步過來，這時候切換數(shù)據(jù)就不一致了。前一陣子出現(xiàn)過某公司突然不能支付了這種事件，今年有很多這種類似的 case，所以微博上大家都在說“說好的異地多活呢？”……

為什么傳統(tǒng)的方案在這上面解決起來特別的困難，天花板馬上到了，基本上不可能解決這個問題。另外是多數(shù)據(jù)中心的復制和數(shù)據(jù)中心的容災，MySQL 在這上面是做不好的。

在前面三十年基本上是關(guān)系數(shù)據(jù)庫的時代，那個時代創(chuàng)建了很多偉大的公司，比如說 IBM、Oracle、微軟也有自己的數(shù)據(jù)庫，早期還有一個公司叫 Sybase，有一部分特別老的程序員同學在當年的教程里面還可以找到這些東西，但是現(xiàn)在基本上看不到了。

另外是 NoSQL。NoSQL 也是一度非常火，像 Cassandra、MongoDB 等等，這些都屬于在互聯(lián)網(wǎng)快速發(fā)展的時候創(chuàng)建這些能夠 scale 的方案，但 Redis scale 出來比較晚，所以很多時候大家把 Redis 當成一個 Cache，現(xiàn)在慢慢大家把它當成存儲不那么重要的數(shù)據(jù)的數(shù)據(jù)庫。因為它有了 scale 支持以后，大家會把更多的數(shù)據(jù)放在里面。

然后到了 2015，嚴格來講是到 2014 年到 2015 年之間，Raft 論文發(fā)表以后，真正的 NewSQL 的理論基礎(chǔ)終于完成了。我覺得 NewSQL 這個理論基礎(chǔ)，最重要的劃時代的幾篇論文，一個是谷歌的 Spanner，是在 2013 年初發(fā)布的；再就是 Raft 是在 2014 年上半年發(fā)布的。這幾篇相當于打下了分布式數(shù)據(jù)庫 NewSQL 的理論基礎(chǔ)，這個模型是非常重要的，如果沒有模型在上面是堆不起來東西的。說到現(xiàn)在，大家可能對于模型還是可以理解的，但是對于它的實現(xiàn)難度很難想象。

前面我大概提到了我們?yōu)槭裁葱枰硗庖粋€數(shù)據(jù)庫，說到 Scalability 數(shù)據(jù)的伸縮，然后我們講到需要 SQL，比如你給我一個純粹的 key-velue 系統(tǒng)的 API，比如我要查找年齡在 10 歲到 20 歲之間的 email 要滿足一個什么要求的。如果只有 KV 的 API 這是會寫死人的，要寫很多代碼，但是實際上用 SQL 寫一句話就可以了，而且 SQL 的優(yōu)化器對整個數(shù)據(jù)的分布是知道的，它可以很快理解你這個 SQL，然后會得到一個最優(yōu)的 plan，他得到這個最優(yōu)的 plan 基本上等價于一個真正理解 KV 每一步操作的人寫出來的程序。通常情況下，SQL 的優(yōu)化器是為了更加了解或者做出更好的選擇。

另外一個就是 ACID 的事務，這是傳統(tǒng)數(shù)據(jù)庫必須要提供的基礎(chǔ)。以前你不提供 ACID 就不能叫數(shù)據(jù)庫，但是近些年大家寫一個內(nèi)存的 map 也可以叫自己是數(shù)據(jù)庫。大家寫一個 append-only 文件，我們也可以叫只讀數(shù)據(jù)庫，數(shù)據(jù)庫的概念比以前極大的泛化了。

另外就是高可用和自動恢復，他們的概念是什么呢？有些人會有一些誤解，因為今天還有朋友在現(xiàn)場問到，出了故障，比如說一個機房掛掉以后我應該怎么做切換，怎么操作。這個實際上相當于還是上一代的概念，還需要人去干預，這種不算是高可用。

未來的高可用一定是系統(tǒng)出了問題馬上可以自動恢復，馬上可以變成可用。比如說一個機房掛掉了，十秒鐘不能支付，十秒鐘之后系統(tǒng)自動恢復了變得可以支付，即使這個數(shù)據(jù)中心再也不起來我整個系統(tǒng)仍然是可以支付的。Auto-Failover 的重要性就在這里。大家不希望在睡覺的時候被一個報警給拉起來，我相信大家以后具備這樣一個能力，5 分鐘以內(nèi)的報警不用理會，掛掉一個機房，又掛掉一個機房，這種連續(xù)報警才會理。我們內(nèi)部開玩笑說，希望大家都能睡個好覺，很重要的事情就是這個。

說完應用層的事情，現(xiàn)在很有很多業(yè)務，在應用層自己去分片，比如說我按照 user ID在代碼里面分片，還有一部分是更高級一點我會用到一致性哈希。問題在于它的復雜度，到一定程度之后我自動的分庫，自動的分表，我覺得下一代數(shù)據(jù)庫是不需要理解這些東西的，不需要了解什么叫做分庫，不需要了解什么叫做分表，因為系統(tǒng)是全部自動搞定的。同時復雜度，如果一個應用不支持事務，那么在應用層去做，通常的做法是引入一個外部隊列，引入大量的程序機制和狀態(tài)轉(zhuǎn)換，A 狀態(tài)的時候允許轉(zhuǎn)換到 B 狀態(tài)，B 狀態(tài)允許轉(zhuǎn)換到 C 狀態(tài)。

舉一個簡單的例子，比如說在京東上買東西，先下訂單，支付狀態(tài)之后這個商品才能出庫，如果不是支付狀態(tài)一定不能出庫，每一步都有嚴格的流程。

Google Spanner / F1

說一下 Google 的 Spanner 和 F1，這是我非常喜歡的論文，也是我最近幾年看過很多遍的論文。 Google Spanner 已經(jīng)強大到什么程度呢？Google Spanner 是全球分布的數(shù)據(jù)庫，在國內(nèi)目前普遍做法叫做同城兩地三中心，它們的差別是什么呢？以 Google 的數(shù)據(jù)來講，谷歌比較高的級別是他們有 7 個副本，通常是美國保存 3 個副本，再在另外 2 個國家可以保存 2 個副本，這樣的好處是萬一美國兩個數(shù)據(jù)中心出了問題，那整個系統(tǒng)還能繼續(xù)可用，這個概念就是比如美國 3 個副本全掛了，整個數(shù)據(jù)都還在，這個數(shù)據(jù)安全級別比很多國家的安全級別還要高，這是 Google 目前做到的，這是全球分布的好處。

現(xiàn)在國內(nèi)主流的做法是兩地三中心，但現(xiàn)在基本上都不能自動切換。大家可以看到很多號稱實現(xiàn)了兩地三中心或者異地多活，但是一出現(xiàn)問題都說不好意思這段時間我不能提供服務了。大家無數(shù)次的見到這種 case， 我就不列舉了。

Spanner 現(xiàn)在也提供一部分 SQL 特性。在以前，大部分 SQL 特性是在 F1 里面提供的，現(xiàn)在 Spanner 也在逐步豐富它的功能，Google 是全球第一個做到這個規(guī)模或者是做到這個級別的數(shù)據(jù)庫。事務支持里面 Google 有點黑科技（其實也沒有那么黑），就是它有GPS 時鐘和原子鐘。大家知道在分布式系統(tǒng)里面，比如說數(shù)千臺機器，兩個事務啟動先后順序，這個順序怎么界定(事務外部一致性)。這個時候 Google 內(nèi)部使用了 GPS 時鐘和原子鐘，正常情況下它會使用一個GPS 時鐘的一個集群，就是說我拿的一個時間戳，并不是從一個 GPS 上來拿的時間戳，因為大家知道所有的硬件都會有誤差。如果這時候我從一個上拿到的 GPS 本身有點問題，那么你拿到的這個時鐘是不精確的。而 Google 它實際上是在一批 GPS 時鐘上去拿了能夠滿足 majority 的精度，再用時間的算法，得到一個比較精確的時間。大家知道 GPS 也不太安全，因為它是美國軍方的，對于 Google 來講要實現(xiàn)比國家安全級別更高的數(shù)據(jù)庫，而 GPS 是可能受到干擾的，因為 GPS 信號是可以調(diào)整的，這在軍事用途上面很典型的，大家知道導彈的制導需要依賴 GPS，如果調(diào)整了 GPS 精度，那么導彈精度就廢了。所以他們還用原子鐘去校正 GPS，如果 GPS 突然跳躍了，原子鐘上是可以檢測到 GPS 跳躍的，這部分相對有一點黑科技，但是從原理上來講還是比較簡單，比較好理解的。

最開始它 Spanner 最大的用戶就是 Google 的 Adwords，這是 Google 最賺錢的業(yè)務，Google 就是靠廣告生存的，我們一直覺得 Google 是科技公司，但是他的錢是從廣告那來的，所以一定程度來講 Google 是一個廣告公司。Google 內(nèi)部的方向先有了 Big table ，然后有了 MegaStore ，MegaStore 的下一代是 Spanner ，F(xiàn)1 是在 Spanner 上面構(gòu)建的。

TiDB and TiKV

TiKV 和 TiDB 基本上對應 Google Spanner 和 Google F1，用 Open Source 方式重建。目前這兩個項目都開放在 GitHub 上面，兩個項目都比較火爆，TiDB 是更早一點開源的， 目前 TiDB 在 GitHub 上 有 4300 多個 Star，每天都在增長。

另外，對于現(xiàn)在的社會來講，我們覺得 Infrastructure 領(lǐng)域閉源的東西是沒有任何生存機會的。沒有任何一家公司，愿意把自己的身家性命壓在一個閉源的項目上。舉一個很典型的例子，在美國有一個數(shù)據(jù)庫叫 FoundationDB，去年被蘋果收購了。FoundationDB 之前和用戶簽的合約都是一年的合約。比如說，我給你服務周期是一年，現(xiàn)在我被另外一個公司收購了，我今年服務到期之后，我是滿足合約的。但是其他公司再也不能找它服務了，因為它現(xiàn)在不叫 FoundationDB 了，它叫 Apple了，你不能找 Apple 給你提供一個 Enterprise service。

TiDB 和 TiKV 為什么是兩個項目，因為它和 Google 的內(nèi)部架構(gòu)對比差不多是這樣的：TiKV 對應的是 Spanner，TiDB 對應的是 F1 。F1 里面更強調(diào)上層的分布式的 SQL 層到底怎么做，分布式的 Plan 應該怎么做，分布式的 Plan 應該怎么去做優(yōu)化。同時 TiDB 有一點做的比較好的是，它兼容了 MySQL 協(xié)議，當你出現(xiàn)了一個新型的數(shù)據(jù)庫的時候，用戶使用它是有成本的。大家都知道作為開發(fā)很討厭的一個事情就是，我要每個語言都寫一個 Driver，比如說你要支持 C++、你要支持 Java、你要支持 Go 等等，這個太累了，而且用戶還得改他的程序，所以我們選擇了一個更加好的東西兼容 MySQL 協(xié)議，讓用戶可以不用改。一會我會用一個視頻來演示一下，為什么一行代碼不改就可以用，用戶就能體會到 TiDB 帶來的所有的好處。

這個圖實際上是整個協(xié)議棧或者是整個軟件棧的實現(xiàn)。大家可以看到整個系統(tǒng)是高度分層的，從最底下開始是 RocksDB ，然后再上面用 Raft 構(gòu)建一層可以被復制的 RocksDB ，在這一層的時候它還沒有 Transaction，但是整個系統(tǒng)現(xiàn)在的狀態(tài)是所有寫入的數(shù)據(jù)一定要保證它復制到了足夠多的副本。也就是說只要我寫進來的數(shù)據(jù)一定有足夠多的副本去 cover 它，這樣才比較安全，在一個比較安全的 Key-value store 上面， 再去構(gòu)建它的多版本，再去構(gòu)建它的分布式事務，然后在分布式事務構(gòu)建完成之后，就可以輕松的加上 SQL 層，再輕松的加上MySQL 協(xié)議的支持。然后，這兩天我比較好奇，自己寫了 MongoDB 協(xié)議的支持，然后我們可以用 MongoDB 的客戶端來玩，就是說協(xié)議這一層是高度可插拔的。TiDB 上可以在上面構(gòu)建一個 MongoDB 的協(xié)議，相當于這個是構(gòu)建一個 SQL 的協(xié)議，可以構(gòu)建一個 NoSQL 的協(xié)議。這一點主要是用來驗證 TiKV 在模型上面的支持能力。

這是整個 TiKV 的架構(gòu)圖，從這個看來，整個集群里面有很多 Node，比如這里畫了四個 Node ，分別對應了四個機器。每一個 Node 上可以有多個 Store，每個 Store 里面又會有很多小的 Region，就是說一小片數(shù)據(jù)，就是一個 Region 。從全局來看所有的數(shù)據(jù)被劃分成很多小片，每個小片默認配置是 64M，它已經(jīng)足夠小，可以很輕松的從一個節(jié)點移到另外一個節(jié)點，Region 1 有三個副本，它分別在 Node1、Node 2 和 Node4 上面， 類似的Region 2，Region 3 也是有三個副本。每個 Region 的所有副本組成一個 Raft Group，整個系統(tǒng)可以看到很多這樣的 Raft groups。

Raft 細節(jié)我不展開了，大家有興趣可以找我私聊或者看一下相應的資料。

因為整個系統(tǒng)里面我們可以看到上一張圖里面有很多 Raft group 給我們，不同 Raft group 之間的通訊都是有開銷的。所以我們有一個類似于 MySQL 的 group commit 機制 ，你發(fā)消息的時候?qū)嶋H上可以 share 同一個 connection ， 然后 pipeline + batch 發(fā)送，很大程度上可以省掉大量 syscall 的開銷。

另外，其實在一定程度上后面我們在支持壓縮的時候，也有非常大的幫助，就是可以減少數(shù)據(jù)的傳輸。對于整個系統(tǒng)而言，可能有數(shù)百萬的 Region，它的大小可以調(diào)整，比如說 64M、128M、256M，這個實際上依賴于整個系統(tǒng)里面當前的狀況。

比如說我們曾經(jīng)在有一個用戶的機房里面做過測試，這個測試有一個香港機房和新加坡的機房。結(jié)果我們在做復制的時候，新加坡的機房大于 256M 就復制不過去，因為機房很不穩(wěn)定，必須要保證數(shù)據(jù)切的足夠小，這樣才能復制過去。

如果一個 Region 太大以后我們會自動做 SPLIT，這是非常好玩的過程，有點像細胞的分裂。

然后 TiKV 的 Raft 實現(xiàn)，是從 etcd 里面 port 過來的，為什么要從 etcd 里面 port 過來呢？首先 TiKV 的 Raft 實現(xiàn)是用 Rust 寫的。作為第一個做到生產(chǎn)級別的 Raft 實現(xiàn)，所以我們從 etcd 里面把它用 Go 語言寫的 port 到這邊。

這個是 Raft 官網(wǎng)上面列出來的 TiKV在里面的狀態(tài)，大家可以看到 TiKV 把所有 Raft 的 feature 都實現(xiàn)了。 比如說 Leader Election、Membership Changes，這個是非常重要的，整個系統(tǒng)的 scale 過程高度依賴 Membership Changes，后面我用一個圖來講這個過程。后面這個是 Log Compaction，這個用戶不太關(guān)心。

這是很典型的細胞分裂的圖，實際上 Region 的分裂過程和這個是類似的。

我們看一下擴容是怎么做的。

比如說以現(xiàn)在的系統(tǒng)假設(shè)，我們剛開始說只有三個節(jié)點，有 Region1 分別是在 1 、2、4，我用虛線連接起來代表它是一個 Raft group ，大家可以看到整個系統(tǒng)里面有三個 Raft group ，在每一個 Node 上面數(shù)據(jù)的分布是比較均勻的，在這個假設(shè)每一個 Region 是 64M ，相當于只有一個 Node 上面負載比其他的稍微大一點點。

一個在線視頻默認我們都是推薦 3 個副本或者 5 個副本的配置。Raft 本身有一個特點，如果一個 leader down 掉之后，其它的節(jié)點會選一個新的 leader ，那么這個新的 leader 會把它還沒有 commit 但已經(jīng) reply 過去的 log 做一個 commit ，然后會再做 apply ，這個有點偏 Raft 協(xié)議，細節(jié)我不講了。

復制數(shù)據(jù)的小的 Region，它實際上是跨多個數(shù)據(jù)中心做的復制。這里面最重要的一點是永遠不丟失數(shù)據(jù)，無論如何我保證我的復制一定是復制到 majority ，任何時候我只要對外提供服務，允許外面寫入數(shù)據(jù)一定要復制到 majority 。很重要的一點就是恢復的過程一定要是自動化的，我前面已經(jīng)強調(diào)過，如果不能自動化恢復，那么中間的宕機時間或者對外不可服務的時間，便不是由整個系統(tǒng)決定的，這是相對回到了幾十年前的狀態(tài)。

MVCC

MVCC 我稍微仔細講一下這一塊。MVCC 的好處，它很好支持 Lock-free 的 snapshot read ，一會兒我有一個圖會展示 MVCC 是怎么做的。isolation level 就不講了， MySQL 里面的級別是可以調(diào)的，我們的 TiKV 有 SI，還有 SI+lock，默認是支持 SI 的這種隔離級別，然后你寫一個 select for update 語句，這個會自動的調(diào)整到 SI 加上 lock 這個隔離級別。這個隔離級別基本上和 SSI 是一致的。還有一個就是 GC 的問題，如果你的系統(tǒng)里面的數(shù)據(jù)產(chǎn)生了很多版本，你需要把這個比較老的數(shù)據(jù)給 GC 掉，比如說正常情況下我們是不刪除數(shù)據(jù)的， 你寫入一行，然后再寫入一行，不斷去 update 同一行的時候，每一次 update 會產(chǎn)生新的版本，新的版本就會在系統(tǒng)里存在，所以我們需要一個 GC 的模塊把比較老的數(shù)據(jù)給 GC 掉，實際上這個 GC 不是 Go 里面的GC，不是 Java 的 GC，而是數(shù)據(jù)的 GC。

這是一個數(shù)據(jù)版本，大家可以看到我們的數(shù)據(jù)分成兩塊，一個是 meta，一個是 data。meta 相對于描述我的數(shù)據(jù)當前有多少個版本。大家可以看到綠色的部分，比如說我們的 meta key 是 A ，keyA 有三個版本，是 A1 、A2、A3，我們把 key 自己和 version 拼到一起。那我們用 A1、A2、A3 分別描述 A 的三個版本，那么就是 version 1/2/3。meta 里面描述，就是我的整個 key 相對應哪個版本，我想找到那個版本。比如說我現(xiàn)在要讀取 key A 的版本10，但顯然現(xiàn)在版本 10 是沒有的，那么小于版本 10 最大的版本是 3，所以這時我就能讀取到 3，這是它的隔離級別決定的。關(guān)于 data，我剛才已經(jīng)講過了。

分布式事務模型

接下來是分布式事務模型，其實是基于 Google Percolator，這是 Google 在 2006 發(fā)表的一篇論文，是 Google 在做內(nèi)部增量處理的時候發(fā)現(xiàn)了這個方法，本質(zhì)上還是二階段提交的。這使用的是一個樂觀鎖，比如說我提供一個 transaction ，我去改一個東西，改的時候是發(fā)布在本地的，并沒有馬上 commit 到數(shù)據(jù)存儲那一端，這個模型就是說，我修改的東西我馬上去 Lock 住，這個基本就是一個悲觀鎖。但如果到最后一刻我才提交出去，那么鎖住的這一小段的時間，這個時候?qū)崿F(xiàn)的是樂觀鎖。樂觀鎖的好處就是當你沖突很小的時候可以得到非常好的性能，因為沖突特別小，所以我本地修改通常都是有效的，所以我不需要去 Lock ，不需要去 roll back 。本質(zhì)上分布式事務就是 2PC (兩階段提交) 或者是 2+x PC，基本上沒有 1PC，除非你在別人的級別上做弱化。比如說我允許你讀到當前最新的版本，也允許你讀到前面的版本，書里面把這個叫做幻讀。如果你調(diào)到這個程度是比較容易做 1PC 的，這個實際上還是依賴用戶設(shè)定的隔離級別的，如果用戶需要更高的隔離級別，這個 1PC就不太好做了。

這是一個路由，正常來講，大家可能會好奇一個 SQL 語句怎么最后會落到存儲層，然后能很好的運行，最后怎么能映射到 KV 上面，又怎么能路由到正確的節(jié)點，因為整個系統(tǒng)可能有上千個節(jié)點，你怎么能正確路由到那一個的節(jié)點。我們在 TiDB 有一個 TiKV driver ， 另外 TiKV 對外使用的是 Google Protocol Buffer 來作為通訊的編碼格式。

Placement Driver

來說一下 Placement Driver 。Placement Driver 是什么呢？整個系統(tǒng)里面有一個節(jié)點，它會時刻知道現(xiàn)在整個系統(tǒng)的狀態(tài)。比如說每個機器的負載，每個機器的容量，是否有新加的機器，新加機器的容量到底是怎么樣的，是不是可以把一部分數(shù)據(jù)挪過去，是不是也是一樣下線， 如果一個節(jié)點在十分鐘之內(nèi)無法被其他節(jié)點探測到，我認為它已經(jīng)掛了，不管它實際上是不是真的掛了，但是我也認為它掛了。因為這個時候是有風險的，如果這個機器萬一真的掛了，意味著你現(xiàn)在機器的副本數(shù)只有兩個，有一部分數(shù)據(jù)的副本數(shù)只有兩個。那么現(xiàn)在你必須馬上要在系統(tǒng)里面重新選一臺機器出來，它上面有足夠的空間，讓我現(xiàn)在只有兩個副本的數(shù)據(jù)重新再做一份新的復制，系統(tǒng)始終維持在三個副本。整個系統(tǒng)里面如果機器掛掉了，副本數(shù)少了，這個時候應該會被自動發(fā)現(xiàn)，馬上補充新的副本，這樣會維持整個系統(tǒng)的副本數(shù)。這是很重要的 ，為了避免數(shù)據(jù)丟失，必須維持足夠的副本數(shù)，因為副本數(shù)每少一個，你的風險就會再增加。這就是 Placement Driver 做的事情。

同時，Placement Driver 還會根據(jù)性能負載，不斷去 move 這個 data 。比如說你這邊負載已經(jīng)很高了，一個磁盤假設(shè)有 100G，現(xiàn)在已經(jīng)用了 80G，另外一個機器上也是 100G，但是他只用了 20G，所以這上面還可以有幾十 G 的數(shù)據(jù)，比如 40G 的數(shù)據(jù)，你可以 move 過去，這樣可以保證系統(tǒng)有很好的負載，不會出現(xiàn)一個磁盤巨忙無比，數(shù)據(jù)已經(jīng)多的裝不下了，另外一個上面還沒有東西，這是 Placement Driver 要做的東西。

Raft 協(xié)議還提供一個很高級的特性叫 leader transfer。leader transfer 就是說在我不移動數(shù)據(jù)的時候，我把我的 leadership 給你，相當于從這個角度來講，我把流量分給你，因為我是 leader，所以數(shù)據(jù)會到我這來，但我現(xiàn)在把 leader給你，我讓你來當 leader，原來打給我的請求會被打給你，這樣我的負載就降下來。這就可以很好的動態(tài)調(diào)整整個系統(tǒng)的負載，同時又不搬移數(shù)據(jù)。不搬移數(shù)據(jù)的好處就是，不會形成一個抖動。

MySQL Sharding

MySQL Sharding 我前面已經(jīng)提到了它的各種天花板，MySQL Sharding 的方案很典型的就是解決基本問題以后，業(yè)務稍微復雜一點，你在 sharding 這一層根本搞不定。它永遠需要一個 sharding key，你必須要告訴我的 proxy，我的數(shù)據(jù)要到哪里找，對用戶來說是極不友好的，比如我現(xiàn)在是一個單機的，現(xiàn)在我要切入到一個分布式的環(huán)境，這時我必須要改我的代碼，我必須要知道我這個 key ，我的 row 應該往哪里 Sharding。如果是用 ORM ，這個基本上就沒法做這個事情了。有很多 ORM 它本身假設(shè)我后面只有一個 MySQL。但 TiDB 就可以很好的支持，因為我所有的角色都是對的，我不需要關(guān)注 Sharding 、分庫、分表這類的事情。

這里面有一個很重要的問題沒有提，我怎么做 DDL。如果這個表非常大的話，比如說我們有一百億吧，橫跨了四臺機器，這個時候你要給它做一個新的 Index，就是我要添加一個新的索引，這個時候你必須要不影響任何現(xiàn)有的業(yè)務，實際上這是多階段提交的算法，這個是 Google 和 F1 一起發(fā)出來那篇論文。

簡單來講是這樣的，先把狀態(tài)標記成 delete only ，delete only 是什么意思呢？因為在分布式系統(tǒng)里面，所有的系統(tǒng)對于 schema 的視野不是一致的，比如說我現(xiàn)在改了一個值，有一部分人發(fā)現(xiàn)這個值被改了，但是還有一部分人還沒有開始訪問這個，所以根本不知道它被改了。然后在一個分布系統(tǒng)里，你也不可能實時通知到所有人在同一時刻發(fā)現(xiàn)它改變了。比如說從有索引到?jīng)]有索引，你不能一步切過去，因為有的人認為它有索引，所以他給它建了一個索引，但是另外一個機器他認為它沒有索引，所以他就把數(shù)據(jù)給刪了，索引就留在里面了。這樣遇到一個問題，我通過索引找的時候告訴我有， 實際數(shù)據(jù)卻沒有了，這個時候一致性出了問題。比如說我 count 一個 email 等于多少的，我通過 email 建了一個索引，我認為它是在，但是 UID 再轉(zhuǎn)過去的時候可能已經(jīng)不存在了。

比如說我先標記成 delete only，我刪除它的時候不管它現(xiàn)在有沒有索引，我都會嘗試刪除索引，所以我的數(shù)據(jù)是干凈的。如果我刪除掉的話，我不管結(jié)果是什么樣的，我嘗試去刪一下，可能這個索引還沒 build 出來，但是我仍然刪除，如果數(shù)據(jù)沒有了，索引一定沒有了，所以這可以很好的保持它的一致性。后面再類似于前面，先標記成 write only 這種方式，連續(xù)再迭代這個狀態(tài)，就可以迭代到一個最終可以對外公開的狀態(tài)。比如說當我迭代到一定程度的時候，我可以從后臺 build index ，比如說我一百億，正在操作的 index 會馬上 build，但是還有很多沒有 build index ，這個時候后臺不斷的跑 map-reduce 去 build index ，直到整個都 build 完成之后，再對外 public ，就是說我這個索引已經(jīng)可用了，你可以直接拿索引來找，這個是非常經(jīng)典的。在這個 Online，Asynchronous Schema Change in F1 paper之前，大家都不知道這事該怎么做。

Proxy Sharding 的方案不支持分布式事務，更不用說跨數(shù)據(jù)中心的一致性事務了。 TiKV 很好的支持 transaction，剛才提到的 Raft 除了增加副本之外，還有 leader transfer，這是一個傳統(tǒng)的方案都無法提供的特性。以及它帶來的好處，當我瞬間平衡整個系統(tǒng)負載的時候，對外是透明的， 做 leader transfer 的時候并不需要移動數(shù)據(jù)，只是個簡單的 leader transfer 消息。

然后說一下如果大家想?yún)⑴c我們項目的話是怎樣的過程，因為整個系統(tǒng)是完全開源的，如果大家想?yún)⑴c其中任何一部分都可以，比如說我想?yún)⑴c到分布式 KV，可以直接貢獻到 TiKV。TiKV 需要寫 Rust，如果大家對這塊特別有激情可以體驗寫 Rust 的感覺 。

TiDB 是用 Go 寫的，Go 在中國的群眾基礎(chǔ)是非常多的，目前也有很多人在貢獻。整個 TiDB 和TiKV 是高度協(xié)作的項目，因為 TiDB 目前還用到了 etcd ，我們在和 CoreOS 在密切的合作，也特別感謝 CoreOS 幫我們做了很多的支持，我們也為 CoreOS 的 etcd 提了一些 patch。同時，TiKV 使用 RocksDB ，所以我們也為 RocksDB 提了一些 patch 和 test，我們也非常感謝 Facebook RocksDB team 對我們項目的支持。

另外一個是 PD，就是我們前面提的 Placement Driver，它負責監(jiān)控整個系統(tǒng)。這部分的算法比較好玩，大家如果有興趣的話，可以去自己控制整個集群的調(diào)度，它和 Kubernetes 或者是Mesos 的調(diào)度算法是不一樣的，因為它調(diào)度的維度實際上比那個要更多。比如說磁盤的容量，你的 leader 的數(shù)量，你的網(wǎng)絡(luò)當前的使用情況，你的 IO 的負載和 CPU 的負載都可以放進去。同時你還可以讓它調(diào)度不要跨一個機房里面建多個副本。

from:http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0831/3395.html

編輯推薦：稀土掘金，這是一個針對技術(shù)開發(fā)者的一個應用，你可以在掘金上獲取最新最優(yōu)質(zhì)的技術(shù)干貨，不僅僅是Android知識、前端、后端以至于產(chǎn)品和設(shè)計都有涉獵，想成為全棧工程師的朋友不要錯過！

原文：http://www.csdn.net/article/2015-08-31/2825579 

JSON——大家可能都知道它是幾乎所有現(xiàn)代服務器都使用的輕量級數(shù)據(jù)交換格式。它體量輕，可讀性強，通常比老式的、不友好的XML開發(fā)起來更加便捷友好。JSON是不依賴于開發(fā)語言的數(shù)據(jù)格式，但是在解析數(shù)據(jù)并將其轉(zhuǎn)換到如Java對象時，會消耗我們的時間和存儲資源。

幾天前，F(xiàn)acebook宣布，其Android應用程序大幅提升了數(shù)據(jù)處理性能。這是由于幾乎在全部應用程序中放棄了JSON數(shù)據(jù)格式，用FlatBuffers取而代之了。閱讀這篇文章可以獲得關(guān)于FlatBuffers的基礎(chǔ)知識，學會如何從JSON轉(zhuǎn)換到FlatBuffers。

雖然這東西是非常有前景的，但是乍一看其實現(xiàn)過程不是一下子就能明白的。而且Facebook也沒有說得很詳細。這就是為什么我要寫這篇文章，在其中展示我們是如何使用Flatbuffers開展工作的。

FlatBuffers

總之，FlatBuffers是Google專門為游戲開發(fā)而創(chuàng)建的跨平臺序列化庫，就像Facebook所展示的那樣，它在Android平臺上遵循快速響應UI的16ms規(guī)則。

但是，在把所有數(shù)據(jù)遷移到FlatBuffers之前，你要確定確實需要這樣做。因為，這樣做有時對性能的影響是潛移默化的，而且數(shù)據(jù)安全性要比計算速度上幾十毫秒的差異更重要。

什么使得Flatbuffers如此奏效？

• 由于是以二進制形式緩存，訪問序列化數(shù)據(jù)時也無需數(shù)據(jù)解析過程。即使對于層次化數(shù)據(jù)也不需要解析。多虧不需要初始化解析器（初始化意味著要建立復雜的字段映射）和解析數(shù)據(jù)，這些都是需要花費時間的。

• Flatbuffers數(shù)據(jù)不需要分配比自身使用緩沖區(qū)還要多的內(nèi)存。我們不必像在JSON中那樣為解析數(shù)據(jù)的整個層次分配額外對象。

要獲得正宗的數(shù)據(jù)，就再讀一讀Facebook上關(guān)于FlatBuffers遷移問題的文章，還有Google自己的文檔。

實現(xiàn)

本文將介紹在Android應用程序中使用Flatbuffers的最簡單方法：

• JSON數(shù)據(jù)在應用程序之外的某個地方被轉(zhuǎn)換成FlatBuffer格式的文件（例如，將二進制數(shù)據(jù)以文件的形式提交，還可以從API直接返回FlatBuffer二進制文件）。

• 在flatc (FlatBuffer編譯器)的幫助下，手工生成數(shù)據(jù)模型（Java類）。

• JSON文件存在一定的局限性（不能使用null字段，日期格式也被解析為字符串）。

將來，我們或許會提出更復雜的解決方案。

FlatBuffers編譯器

首先，我們需要flatc，即flatbuffers編譯器。該編譯器可以從Google所屬的源代碼構(gòu)建，源代碼位于Flatbuffers資源庫中。我們下載并克隆它。整個構(gòu)建過程在FlatBuffers構(gòu)建文檔中都做了描述。如果你是Mac用戶的話，需要這樣來構(gòu)建：

1. 在\{extract directory}\build\XcodeFlatBuffers.xcodeproj路徑下，打開已下載的源代碼。

2. 點擊Play按鈕或⌘ + R，運行flatc scheme（默認情況下應該是被選中的）。

3. flatc可執(zhí)行文件就會在項目的根目錄下出現(xiàn)。

現(xiàn)在，我們可以使用schema編譯器了，該編譯器能夠把給定的schema（在Java、C#、Python、GO和C++語言中的schema）生成為模型類，還可以把JSON轉(zhuǎn)換成Flatbuffer的二進制文件。

Schema文件

接著，我們必須準備schema文件，該文件定義了要進行序列化和反序列化的數(shù)據(jù)結(jié)構(gòu)。這個schema將用于flatc創(chuàng)建Java模型，把JSON轉(zhuǎn)換成FlatBuffers的二進制文件。

這里是JSON文件的一部分。

完整版本在這里。這是略微修改后的版本，可以從Github API調(diào)用：https://api.github.com/users/google/repos 。

Flatbuffer schema是編寫得很好的文檔，所以就不深入探討這個問題了。另外，本文中的schema不會很復雜。我們所要做的僅僅是創(chuàng)建3張表：ReposList, Repo和User，并定義root_type。這是schema的重要組成部分。

完整的schema文件在這里。

FlatBuffers數(shù)據(jù)文件

真棒，我們現(xiàn)在要做的是把repos_json.json轉(zhuǎn)換成FlatBuffers二進制文件，生成能夠以Java風格表示數(shù)據(jù)的Java模型（此處操作所需的全部文件都在我們的代碼庫中）：

$ ./flatc -j -b repos_schema.fbs repos_json.json

如果一切順利，會產(chǎn)生下列文件：

• repos_json.bin（要將重命名它為 repos_flat.bin）

• Repos/Repo.java

• Repos/ReposList.java

• Repos/User.java

Android應用程序

現(xiàn)在來創(chuàng)建示例程序，在實踐中來看看Flatbuffers格式是如何起作用的。這是截圖：

在UI部分，ProgressBar僅用于顯示不恰當?shù)臄?shù)據(jù)處理對用戶界面順暢度的影響。

應用文件看起來是這個樣子：app/build.gradle

當然，在本例中不是必須要用Rx或ButterKnife這樣的視圖注入利器，但是為什么不讓應用更細致一些呢？？

我們把repos_flat.bin 和 repos_json.json文件放到res/raw/目錄下。RawDataReader是工具類，它幫助我們讀取Android應用中的原始文件。

最后，把Repo，ReposList和User這三張表對應的模型類代碼放到項目源代碼中。

FlatBuffers庫

使用Java語言編程過程中，F(xiàn)latBuffers提供了可以直接處理這種數(shù)據(jù)格式的庫，也這是flatbuffers-java-1.2.0-SNAPSHOT.jar文件。如果你想手工生成該文件，需要下載FlatBuffers源代碼，再到目錄java/下，用Maven生成該庫：

$ mvn install

現(xiàn)在將.jar文件放到Android項目的app/libs/目錄下。

好了，當務之急是實現(xiàn)MainActivity類，這是完整源代碼。

我們最為關(guān)注的兩個方法是：

• parseReposListJson(String reposStr) - 這個方法初始化Gson解析器，并把JSON字符串轉(zhuǎn)換成Java對象。

• loadFlatBuffer(byte[] bytes)  - 這個方法將字節(jié)（repos_flat.bin文件）轉(zhuǎn)換成Java對象。

使用FlatBuffers的結(jié)果

現(xiàn)在讓我們把JSON和FlatBuffers在加載時間和資源消耗方面的差異形象化。測試是在帶有Android M（beta版）的Nexus 5上進行的。

加載時間

測量的過程是將其他文件轉(zhuǎn)換為Java源文件，對所有（90個）元素進行迭代。

• 使用JSON：JSON文件（大小：478kB）平均加載時間200ms（時間區(qū)間：180ms～250ms）；

• 使用FlatBuffers：FlatBuffers二進制文件（大小：352kB）平均加載時間5ms（時間區(qū)間：3ms～10ms）。

記得16ms規(guī)則嗎？我們在UI線程中調(diào)用這些方法的原因就是要看看在這種情況下界面表現(xiàn)如何：

JSON數(shù)據(jù)加載效果：

FlatBuffers數(shù)據(jù)加載效果：

看出區(qū)別了嗎？JSON數(shù)據(jù)的加載過程中， ProgressBar停頓了一會，界面不是那么順暢（加載時間超過了16ms）。

內(nèi)存分配、CPU等資源

還有什么想要測量的嗎？也許應該測量一下Android Studio 1.3，還有那些新特性。例如，內(nèi)存分配跟蹤器（Allocation Tracker），內(nèi)存狀態(tài)查看器（Memory Viewer）和方法跟蹤器（Method Tracer）。

源代碼

這里所講解項目的完整源代碼都在Github代碼庫中。你不需要接觸整個FlatBuffers項目，所需的內(nèi)容全都在flatbuffers/目錄下。

（ 翻譯/張揮戈  友情審校/白云鵬）

文章來源：froger_mcs dev blog

作者簡介：

Miroslaw Stanek，Azimo Money Transfer公司移動項目負責人，Android和iOS平臺程序員，視頻游戲玩家，冰雪運動愛好者。個人博客：http://frogermcs.github.io。

from:http://www.oschina.net/news/75092/android-flatbuffers-json

你可能會問，既然我們已經(jīng)有很標準的JSON以及轉(zhuǎn)換庫比如GSON和Jackson，為什么還要使用新的工具呢？

不妨先試一下FlatBuffers，然后你就會發(fā)現(xiàn)它比JSON快得多。

FlatBuffers是什么？

FlatBuffers是一個高效的跨平臺序列化類庫，可以在C++、C#、C、Go、Java、JavaScript、PHP和Python中使用。是Google開發(fā)的，是為了應用在游戲開發(fā)，以及其他注重性能的應用上。

為什么要使用FlatBuffers？

• 不需要解析/拆包就可以訪問序列化數(shù)據(jù) — FlatBuffers與其他庫不同之處就在于它使用二進制緩沖文件來表示層次數(shù)據(jù)，這樣它們就可以被直接訪問而不需解析與拆包，同時還支持數(shù)據(jù)結(jié)構(gòu)進化（前進、后退兼容性）。

• 內(nèi)存高效速度快 — 訪問數(shù)據(jù)時只需要訪問內(nèi)存中的緩沖區(qū)。它不需要多余的內(nèi)存分配（至少在C++是這樣，其他語言中可能會有變動）。FlatBuffers還適合配合 mmap或數(shù)據(jù)流使用，只需要緩沖區(qū)的一部分存儲在內(nèi)存中。訪問時速度接近原結(jié)構(gòu)訪問，只有一點延遲（一種虛函數(shù)表vtable），是為了允許格式升級以 及可選字段。FlatBuffers適合那些花費了大量時間和空間（內(nèi)存分配）來訪問和構(gòu)建序列化數(shù)據(jù)的項目，比如游戲以及其他對表現(xiàn)敏感的應用。可以參 考這里的基準。

• 靈活 — 由于有可選字段，你不但有很強的升級和回退兼容性（對于歷史悠久的游戲尤其重要，不用為了每個版本升級所有數(shù)據(jù)），在選擇要存儲哪些數(shù)據(jù)以及設(shè)計數(shù)據(jù)結(jié)構(gòu)時也很自由。

• 輕量的code footprint — FlatBuffers只需要很少量的生成代碼，以及一個表示最小依賴的很小的頭文件，很容易集成。細節(jié)上可以看上面的基準頁。

• 強類型 — 編譯時報錯，而不需要自己寫重復的容易出錯的運行時檢查。它可以自動生成有用的代碼。

• 使用方便 — 生成的C++代碼允許精簡訪問與構(gòu)建代碼。還有可選的用于實現(xiàn)圖表解析、類似JSON的運行時字符串展示等功能的方法。（后者比JSON解析庫更快，內(nèi)存效率更高）

• 代碼跨平臺且沒有依賴 — C++代碼可以運行在任何近代的gcc/clang和VS2010上。同時還有用于測試和范例的構(gòu)建文件（Android中.mk文件，其他平臺是cmake文件）。

都有誰使用FlatBuffers?

• BobbleApp，印度第一貼圖App。我們在BobbleApp中使用FlatBuffers后App的性能明顯增強。

• Cocos2d-x，第一開源移動游戲引擎，使用FlatBuffers來序列化所有的游戲數(shù)據(jù)。

• Facebook使用FlatBuffers在Android App中進行客戶端服務端的溝通。他們寫了一篇文章來描述FlatBuffers是如何加速加載內(nèi)容的。

• Google的Fun Propulsion Labs在他們所有的庫和游戲中大量使用FlatBuffers。

App性能有多大提高？

• 解析速度 解析一個20KB的JSON流（這差不多是BobbleApp的返回大小）需要35ms，超過了UI刷新間隔也就是16.6ms。如果解析JSON的話，我們就在滑動時就會因為要從磁盤加載緩存而導致掉幀（視覺上的卡頓）。

• 解析器初始化 一個JSON解析器需要先構(gòu)建字段映射再進行解析，這會花100ms到200ms，很明顯的拖緩App啟動時間。

• 垃圾回收 在解析JSON時創(chuàng)建了很多小對象，在我們的試驗中，解析20kb的JSON流時，要分配大約100kb的瞬時存儲，對Java內(nèi)存回收造成很大壓力。

FlatBuffers vs JSON

我嘗試使用FlatBuffers和JSON解析4mb的JSON文件。

FlatBuffers花了1-5ms，JSON花了大約2000ms。在使用FlatBuffers期間Android App中沒有GC，而在使用JSON時發(fā)生了很多次GC。在使用JSON時UI完全卡住，所以真實使用時只能在后臺線程進行解析。

如何使用FlatBuffer呢？

我在我的GitHub中寫了一個示例，里面手把手教你如何使用FlatBuffer。

原文鏈接:https://medium.freecodecamp.com/why-consider-flatbuffer-over-json-2e4aa8d4ed07

稿源：infoQ  作者Amit Shekhar  譯者程大治

from:http://www.jdon.com/46111

本文來自Pivotal，分析了中國鐵路總公司12306這個世界上最大的鐵路系統(tǒng)的火車票預訂系統(tǒng)。

在這個星球上人類最大的年度運動大概算是中國農(nóng)歷新年，又稱春節(jié)。有3488萬人次通過航空和235萬人次通過鐵路踏上他們的旅途。從歷史上看，鐵路旅行意味著排長龍隊伍買票，中國鐵路總公司（CRC）現(xiàn)在開始在網(wǎng)上賣火車票，提供比車站售票處或通過電話購買更方便的方法。

隨著越來越多人的使用車票預訂系統(tǒng)，12306鐵路訂票系統(tǒng)打破了其傳統(tǒng)的RDBMS關(guān)系數(shù)據(jù)庫系統(tǒng)，需要重新開始了一個新的項目，以改善原有系統(tǒng)性能和可伸縮性的問題，能夠承受像春節(jié)度假旅游期間的尖峰的壓力。目前該網(wǎng)站成為中國最受歡迎網(wǎng)站的之一。在這樣嚴苛的訪問條件下，系統(tǒng)出現(xiàn)以下很差用戶體驗：使用中斷，性能差，預訂錯誤，支付失敗，票務確認出現(xiàn)問題等等。

中國鐵道科學研究院的副主任朱劍圣首先解決性能問題，早在2011年，朱博士確保新系統(tǒng)解決基于下面兩個性能瓶頸：

1.關(guān)系型數(shù)據(jù)庫超負載，以至于不能處理傳入的請求，無論是規(guī)模擴展性還是可靠性，都不能滿足SLA要求的水平。 

2.UNIX服務器的計算能力不足以解決容量需求。

朱博士說：“傳統(tǒng)關(guān)系型數(shù)據(jù)庫和大型機的計算模式并不具有擴展性，系統(tǒng)不能基于內(nèi)存擴展跨多個節(jié)點上運行。我們的網(wǎng)站證明了這一點，而試圖擴展我們的遺留系統(tǒng)將變得非常昂貴”。

使用In-memory內(nèi)存數(shù)據(jù)網(wǎng)格解決擴展性和可靠性
朱博士的團隊開始尋找新的解決方案，大型機被發(fā)現(xiàn)和關(guān)系數(shù)據(jù)庫有同樣的瓶頸，在內(nèi)存數(shù)據(jù)網(wǎng)格(IMDG)領(lǐng)域，他們發(fā)現(xiàn)了Pivotal GemFire，在海運貨物系統(tǒng) 金融服務，航空，電子商務等多個行業(yè)都擁有成功解決最具挑戰(zhàn)性的數(shù)據(jù)問題的良好記錄。為了執(zhí)行評估，朱博士和他的團隊選擇了國際綜合系統(tǒng)公司（IISI）。IISI擁有強大為政府機構(gòu)工作的跟蹤記錄，包括在開發(fā)交通運輸解決方案，遷移遺留系統(tǒng)到云計算架構(gòu)等方面經(jīng)歷，有與Pivotal GemFire合作經(jīng)驗。他們開始試點，相信了GemFire​​將滿足性能，可擴展性和可用性的要求，包括能夠在低成本硬件上運行。

IISI創(chuàng)造了一個概念證明和展示了GemFire幾個優(yōu)點​​。售票計算速度提高50到100倍。當負載增加時，響應時間保持10-100毫秒的延遲。他們可以看到，通過增加容量，能實現(xiàn)近乎線性增長的可擴展性和高可用性的能力。項目組在短短兩個月內(nèi)建立了一個試點，四個月后，新的在線系統(tǒng)全面部署，跨越5700火車站。

該小組負責鐵路網(wǎng)上預訂系統(tǒng)每年增長高達50％。他們的網(wǎng)站每天的平均水平預訂250萬票。

72臺UNIX系統(tǒng)和關(guān)系數(shù)據(jù)庫換成了10臺初始和10個備份的x86服務器，這是一個更具成本效益的模式，能在內(nèi)存中處理2TB或一個月的的火車票數(shù)據(jù)。

朱博士認為：“首先，Pivotal GemFire​​提供了一個在真實的測試環(huán)境的證明。然后，在生產(chǎn)環(huán)境面對意想不到的尖峰也是成功的，具體采取了一個迭代的方法來部署，克服了一系列大規(guī)模的挑戰(zhàn)。在最近的2013春運期間，該系統(tǒng)具備了運行穩(wěn)定的性能和正常運行時間。現(xiàn)在，我們有一個可靠，經(jīng)濟合理的生產(chǎn)體系​​，支持記錄容量增長的空間。這個規(guī)模實現(xiàn)10-100毫秒的延遲。”

基于高可用性，冗余和故障切換機制上的GemFire​​提供了連續(xù)正常運行，它已超出了所有在該領(lǐng)域的CRC校驗的指標，并幫助他們維護他們的SLA。

具體PDF下載

     摘要: from:http://www.infoq.com/cn/news/2016/08/Elasticsearch-5-0-Elastic大家好，非常高興能在這里給大家分享，首先簡單自我介紹一下，我叫曾勇，是Elastic的工程師。Elastic將在今年秋季的時候發(fā)布一個Elasticsearch V5.0的大版本，這次的微信分享將給大家介紹一下5.0版里面的一些新的特性和改進。5.0？ 天啦嚕，你是...  閱讀全文

from:http://www.infoq.com/cn/articles/anatomy-of-an-elasticsearch-cluster-part02

剖析Elasticsearch集群系列涵蓋了當今最流行的分布式搜索引擎Elasticsearch的底層架構(gòu)和原型實例。

本文是這個系列的第二篇，我們將討論Elasticsearch如何處理分布式的三個C((共識(consensus)、并發(fā)(concurrency)和一致(consistency))的問題、Elasticsearch分片的內(nèi)部概念，比如translog(預寫日志，WAL(Write Ahead Log))，以及Lucene中的段。

本系列已經(jīng)得到原文著者Ronak Nathani的授權(quán)

在本系列的前一篇中，我們討論了Elasticsearch的底層存儲模型及CRUD（創(chuàng)建、讀取、更新和刪除）操作的工作原理。在本文中，我將分享Elasticsearch是如何應對分布式系統(tǒng)中的一些基本挑戰(zhàn)的，以及分片的內(nèi)部概念。這其中包括了一些操作方面的事情，Insight Data的工程師們已經(jīng)在使用Elasticsearch構(gòu)建的數(shù)據(jù)平臺之上成功地實踐并真正理解。我將在本文中主要講述：

• 共識——裂腦問題及法定票數(shù)的重要性
• 并發(fā)
• 一致——確保讀寫一致
• Translog(預寫日志)
• Lucene的段

共識——裂腦問題及法定票數(shù)的重要性

共識是分布式系統(tǒng)的一項基本挑戰(zhàn)。它要求系統(tǒng)中的所有進程/節(jié)點必須對給定數(shù)據(jù)的值/狀態(tài)達成共識。已經(jīng)有很多共識算法諸如Raft、Paxos等，從數(shù)學上的證明了是行得通的。但是，Elasticsearch卻實現(xiàn)了自己的共識系統(tǒng)(zen discovery)，Elasticsearch之父Shay Banon在這篇文章中解釋了其中的原因。zen discovery模塊包含兩個部分：

• Ping: 執(zhí)行節(jié)點使用ping來發(fā)現(xiàn)彼此
• 單播(Unicast):該模塊包含一個主機名列表，用以控制哪些節(jié)點需要ping通

Elasticsearch是端對端的系統(tǒng)，其中的所有節(jié)點彼此相連，有一個master節(jié)點保持活躍，它會更新和控制集群內(nèi)的狀態(tài)和操作。建立一個新的Elasticsearch集群要經(jīng)過一次選舉，選舉是ping過程的一部分，在所有符合條件的節(jié)點中選取一個master，其他節(jié)點將加入這個master節(jié)點。ping間隔參數(shù)ping_interval的默認值是1秒，ping超時參數(shù)ping_timeout的默認值是3秒。因為節(jié)點要加入，它們會發(fā)送一個請求給master節(jié)點，加入超時參數(shù)join_timeout的默認值是ping_timeout值的20倍。如果master出現(xiàn)問題，那么群集中的其他節(jié)點開始重新ping以啟動另一次選舉。這個ping的過程還可以幫助一個節(jié)點在忽然失去master時，通過其他節(jié)點發(fā)現(xiàn)master。

注意：默認情況下，client節(jié)點和data節(jié)點不參與這個選舉過程。可以在elasticsearch.yml配置文件中，通過設(shè)置discovery.zen.master_election.filter_client屬性和discovery.zen.master_election.filter_data屬性為false來改變這種默認行為。

故障檢測的原理是這樣的，master節(jié)點會ping所有其他節(jié)點，以檢查它們是否還活著；然后所有節(jié)點ping回去，告訴master他們還活著。

如果使用默認的設(shè)置，Elasticsearch有可能遭到裂腦問題的困擾。在網(wǎng)絡(luò)分區(qū)的情況下，一個節(jié)點可以認為master死了，然后選自己作為master，這就導致了一個集群內(nèi)出現(xiàn)多個master。這可能會導致數(shù)據(jù)丟失，也可能無法正確合并數(shù)據(jù)。可以按照如下公式，根據(jù)有資格參加選舉的節(jié)點數(shù)，設(shè)置法定票數(shù)屬性的值，來避免爆裂的發(fā)生。

discovery.zen.minimum_master_nodes = int(# of master eligible nodes/2)+1

這個屬性要求法定票數(shù)的節(jié)點加入新當選的master節(jié)點，來完成并獲得新master節(jié)點接受的master身份。對于確保群集穩(wěn)定性和在群集大小變化時動態(tài)地更新，這個屬性是非常重要的。圖a和b演示了在網(wǎng)絡(luò)分區(qū)的情況下，設(shè)置或不設(shè)置minimum_master_nodes屬性時，分別發(fā)生的現(xiàn)象。

注意：對于一個生產(chǎn)集群來說，建議使用3個節(jié)點專門做master，這3個節(jié)點將不服務于任何客戶端請求，而且在任何給定時間內(nèi)總是只有1個活躍。

我們已經(jīng)搞清楚了Elasticsearch中共識的處理，現(xiàn)在讓我們來看看它是如何處理并發(fā)的。

并發(fā)

Elasticsearch是一個分布式系統(tǒng)，支持并發(fā)請求。當創(chuàng)建/更新/刪除請求到達主分片時，它也會被平行地發(fā)送到分片副本上。但是，這些請求到達的順序可能是亂序的。在這種情況下，Elasticsearch使用樂觀并發(fā)控制，來確保文檔的較新版本不會被舊版本覆蓋。

每個被索引的文檔都擁有一個版本號，版本號在每次文檔變更時遞增并應用到文檔中。這些版本號用來確保有序接受變更。為了確保在我們的應用中更新不會導致數(shù)據(jù)丟失，Elasticsearch的API允許我們指定文件的當前版本號，以使變更被接受。如果在請求中指定的版本號比分片上存在的版本號舊，請求失敗，這意味著文檔已經(jīng)被另一個進程更新了。如何處理失敗的請求，可以在應用層面來控制。Elasticsearch還提供了其他的鎖選項，可以通過這篇來閱讀。

當我們發(fā)送并發(fā)請求到Elasticsearch后，接下來面對的問題是——如何保證這些請求的讀寫一致？現(xiàn)在，還無法清楚回答，Elasticsearch應落在CAP三角形的哪條邊上，我不打算在這篇文章里解決這個素來已久的爭辯。

但是，我們要一起看下如何使用Elasticsearch實現(xiàn)寫讀一致。

一致——確保讀寫一致

對于寫操作而言，Elasticsearch支持的一致性級別，與大多數(shù)其他的數(shù)據(jù)庫不同，允許預檢查，來查看有多少允許寫入的可用分片。可選的值有quorum、one和all。默認的設(shè)置為quorum，也就是說只有當大多數(shù)分片可用時才允許寫操作。即使大多數(shù)分片可用，還是會因為某種原因發(fā)生寫入副本失敗，在這種情況下，副本被認為故障，分片將在一個不同的節(jié)點上重建。

對于讀操作而言，新的文檔只有在刷新時間間隔之后，才能被搜索到。為了確保搜索請求的返回結(jié)果包含文檔的最新版本，可設(shè)置replication為sync(默認)，這將使操作在主分片和副本碎片都完成后才返回寫請求。在這種情況下，搜索請求從任何分片得到的返回結(jié)果都包含的是文檔的最新版本。即使我們的應用為了更高的索引率而設(shè)置了replication=async，我們依然可以為搜索請求設(shè)置參數(shù)_preference為primary。這樣，搜索請求將查詢主分片，并確保結(jié)果中的文檔是最新版本。

我們已經(jīng)了解了Elasticsearch如何處理共識、并發(fā)和一致，讓我們來看看分片內(nèi)部的一些主要概念，正是這些特點讓Elasticsearch成為一個分布式搜索引擎。

Translog(預寫日志)

因為關(guān)系數(shù)據(jù)庫的發(fā)展，預寫日志(WAL)或者事務日志(translog)的概念早已遍及數(shù)據(jù)庫領(lǐng)域。在發(fā)生故障的時候，translog能確保數(shù)據(jù)的完整性。translog的基本原理是，變更必須在數(shù)據(jù)實際的改變提交到磁盤上之前，被記錄下來并提交。

當新的文檔被索引或者舊的文檔被更新時，Lucene索引將發(fā)生變更，這些變更將被提交到磁盤以持久化。這是一個很昂貴的操作，如果在每個請求之后都被執(zhí)行。因此，這個操作在多個變更持久化到磁盤時被執(zhí)行一次。正如我們在上一篇文章中描述的那樣，Lucene提交的沖洗(flush)操作默認每30分鐘執(zhí)行一次或者當translog變得太大(默認512MB)時執(zhí)行。在這樣的情況下，有可能失去2個Lucene提交之間的所有變更。為了避免這種問題，Elasticsearch采用了translog。所有索引/刪除/更新操作被寫入到translog，在每個索引/刪除/更新操作執(zhí)行之后（默認情況下是每5秒），translog會被同步以確保變更被持久化。translog被同步到主分片和副本之后，客戶端才會收到寫請求的確認。

在兩次Lucene提交之間發(fā)生硬件故障的情況下，可以通過重放translog來恢復自最后一次Lucene提交前的任何丟失的變更，所有的變更將會被索引所接受。

注意：建議在重啟Elasticsearch實例之前顯式地執(zhí)行沖洗translog，這樣啟動會更快，因為要重放的translog被清空。POST /_all/_flush命令可用于沖洗集群中的所有索引。

使用translog的沖洗操作，在文件系統(tǒng)緩存中的段被提交到磁盤，使索引中的變更持久化。現(xiàn)在讓我們來看看Lucene的段。

Lucene的段

Lucene索引是由多個段組成，段本身是一個功能齊全的倒排索引。段是不可變的，允許Lucene將新的文檔增量地添加到索引中，而不用從頭重建索引。對于每一個搜索請求而言，索引中的所有段都會被搜索，并且每個段會消耗CPU的時鐘周、文件句柄和內(nèi)存。這意味著段的數(shù)量越多，搜索性能會越低。

為了解決這個問題，Elasticsearch會合并小段到一個較大的段（如下圖所示），提交新的合并段到磁盤，并刪除那些舊的小段。

這會在后臺自動執(zhí)行而不中斷索引或者搜索。由于段合并會耗盡資源，影響搜索性能，Elasticsearch會節(jié)制合并過程，為搜索提供足夠的可用資源。

接下來有什么？

從搜索請求角度來說，一個Elasticsearch索引中給定分片內(nèi)的所有Lucene段都會被搜索，但是，從Elasticsearch集群角度而言，獲取所有匹配的文檔或者深入有序結(jié)果文檔是有害的。在本系列的后續(xù)文章中我們將揭曉原因，讓我們來看一下接下來的主題，內(nèi)容包括了一些在Elasticsearch中為相關(guān)性搜索結(jié)果的低延遲所做的權(quán)衡。

• Elasticsearch準實時性方面的內(nèi)容
• 為什么搜索中的深層分頁是有害的？
• 搜索相關(guān)性計算中的權(quán)衡之道

查看原文地址：Anatomy of an Elasticsearch Cluster: Part II

from:http://www.infoq.com/cn/articles/anatomy-of-an-elasticsearch-cluster-part03

剖析Elasticsearch集群系列涵蓋了當今最流行的分布式搜索引擎Elasticsearch的底層架構(gòu)和原型實例。本文是這個系列的第三篇，我們將討論Elasticsearch是如何提供近實時搜索并權(quán)衡搜索相關(guān)性計算的。

本系列已經(jīng)得到原文著者Ronak Nathani的授權(quán)

在本系列的前一篇中，我們討論了Elastisearch如何解決分布式系統(tǒng)中的一些基本挑戰(zhàn)。在本文中，我們將探討Elasticsearch在近實時搜索及其權(quán)衡計算搜索相關(guān)性方面的內(nèi)容，Insight Data的工程師們已經(jīng)在使用Elasticsearch構(gòu)建的數(shù)據(jù)平臺之上，對此有所實踐。我將在本文中主要講述：

• 近實時搜索
• 為什么深層分頁在分布式搜索中是有害的？
• 計算搜索相關(guān)性中的權(quán)衡

近實時搜索

雖然Elasticsearch中的變更不能立即可見，它還是提供了一個近實時的搜索引擎。如前一篇中所述，提交Lucene的變更到磁盤是一個代價昂貴的操作。為了避免在文檔對查詢依然有效的時候，提交變更到磁盤，Elasticsearch在內(nèi)存緩沖和磁盤之間提供了一個文件系統(tǒng)緩存。內(nèi)存緩存(默認情況下)每1秒刷新一次，在文件系統(tǒng)緩存中使用倒排索引創(chuàng)建一個新的段。這個段是開放的并對搜索有效。

文件系統(tǒng)緩存可以擁有文件句柄，文件可以是開放的、可讀的或者是關(guān)閉的，但是它存在于內(nèi)存之中。因為刷新間隔默認是1秒，變更不能立即可見，所以說是近實時的。因為translog是尚未落盤的變更持久化記錄，它能有助于CRUD操作方面的近實時性。對于每次請求來說，在查找相關(guān)段之前，任何最近的變更都能從translog搜索到，因此客戶端可以訪問到所有的近實時變更。

你可以在創(chuàng)建/更新/刪除操作后顯式地刷新索引，使變更立即可見，但我并不推薦你這樣做，因為這樣會創(chuàng)建出來非常多的小segment而影響搜索性能。對于每次搜索請求來說，給定Elasticsearch索引分片中的全部Lucene段都會被搜索到，但是，對于Elasticsearch來說，獲取全部匹配的文檔或者很深結(jié)果頁的文檔是有害的。讓我們來一起看看為什么是這樣。

為什么深層分頁在分布式搜索中是有害的？

當我們的一次搜索請求在Elasticsearch中匹配了很多的文檔，默認情況下，返回的第一頁只包含前10條結(jié)果。search API提供了from和size參數(shù)，用于指定對于匹配搜索的全部文檔，要返回多深的結(jié)果。舉例來說，如果我們想看到匹配搜索的文檔中，排名為50到60之間的文檔，可以設(shè)置from=50，size=10。當每個分片接收到這個搜索請求后，各自會創(chuàng)建一個容量為from+size的優(yōu)先隊列來存儲該分片上的搜索結(jié)果，然后將結(jié)果返回給協(xié)調(diào)節(jié)點。

如果我們想看到排名為50,000到50,010的結(jié)果，那么每個分片要創(chuàng)建一個容量為50,010的優(yōu)先隊列來存儲結(jié)果，而協(xié)調(diào)節(jié)點要在內(nèi)存中對數(shù)量為shards * 50,010的結(jié)果進行排序。這個級別的分頁有可能得到結(jié)果，也有可以無法實現(xiàn)，這取決于我們的硬件資源，但是這足以說明，我們得非常小心地使用深分頁，因為這非常容易使我們的集群崩潰。

一種獲取全部匹配結(jié)果文檔的可行性方案是使用scroll API，它的角色更像關(guān)系數(shù)據(jù)庫中的游標。使用scroll API無法進行排序，每個分片只要有匹配搜索的文檔，就會持續(xù)發(fā)送結(jié)果給協(xié)調(diào)節(jié)點。

獲取大量文檔的時候，對結(jié)果進行得分排序會非常昂貴。并且由于Elasticsearch是分布式系統(tǒng)，為每個文檔計算搜索相關(guān)性得分是非常昂貴的。現(xiàn)在，讓我們一起看看計算搜索相關(guān)性的諸多權(quán)衡中的一種。

計算搜索相關(guān)性中的權(quán)衡

Elasticsearch使用tf-idf來計算搜索相關(guān)性。由于其分布式的性質(zhì)，計算全局的idf(inverse document frequency，逆文檔頻率)非常昂貴。反之可以這樣，每個分片計算本地的idf并將相關(guān)性得分分配給結(jié)果文檔，返回的結(jié)果只關(guān)乎該分片上的文檔。同樣地，所有分片使用本地idf計算的相關(guān)性得分，返回結(jié)果文檔，協(xié)調(diào)節(jié)點對所有結(jié)果排序并返回前幾條。這樣做在大多數(shù)情況下是沒有問題的，除非索引的關(guān)鍵字詞項有傾斜或者單個分片上沒有代表全局的足夠數(shù)據(jù)。

比如說，如果我們搜索“insight”這個詞，但包含"insight"這個詞項的大多數(shù)文檔都存放在一個分片上，這樣以來匹配查詢的文檔將不能公平地在每個分片上進行排序，因為每個分片上的本地idf的值非常不同，得到的搜索結(jié)果可能不會非常相關(guān)。同樣地，如果沒有足夠的數(shù)據(jù)，那么對于某些搜索而言，本地idf的值可能大有不同，結(jié)果也會不如預期相關(guān)。在有足夠數(shù)據(jù)的真實場景中，本地idf值一般會趨于均等，搜索結(jié)果是相關(guān)的，因為文檔得到了公平的得分。

這里有2種應對本地idf得分的辦法，但都不建議真正在生產(chǎn)環(huán)境中使用。

• 一種辦法是一索引一分片，本地idf即是全局idf，但這沒有為并行計算/水平伸縮留有余地，對于大型索引并不實用。
• 另一種辦法是在搜索請求中使用dfs_query_then_search (dfs = distributed frequency search，分布式頻率搜索) 參數(shù)，這樣以來，會首先計算每個分片的本地idf，然后綜合這些本地idf的值來計算整個索引的全局idf值，最后使用全局idf計算相關(guān)性得分來返回結(jié)果。這種方式不為生產(chǎn)環(huán)境推薦，因為有足夠的數(shù)據(jù)確保詞項頻率分布均勻。

在本系列的過去幾篇中，我們回顧了一些Elasticsearch的基本原則，對于我們理解并上手Elasticsearch，這些內(nèi)容非常重要。在接下來的一篇中，我將使用Apache Spark來研究Elasticsearch中的索引數(shù)據(jù)。

查看英文原文：Anatomy of an Elasticsearch Cluster: Part III

from:http://www.infoq.com/cn/articles/analysis-of-elasticsearch-cluster-part01

剖析Elasticsearch集群系列涵蓋了當今最流行的分布式搜索引擎Elasticsearch的底層架構(gòu)和原型實例。

本文是這個系列的第一篇，在本文中，我們將討論的Elasticsearch的底層存儲模型及CRUD（創(chuàng)建、讀取、更新和刪除）操作的工作原理。

本系列已經(jīng)得到原文著者Ronak Nathani的授權(quán)

Elasticsearch是當今最流行的分布式搜索引擎，GitHub、 SalesforceIQ、Netflix等公司將其用于全文檢索和分析應用。在Insight，我們用到了Elasticsearch的諸多不同功能，比如：

• 全文檢索
  • 比如找到與搜索詞項(term)最相關(guān)的維基百科文章。
• 聚合
  • 比如在廣告網(wǎng)絡(luò)中，可視化的搜索詞項的競價直方圖。
• 地理空間API
  • 比如在順風車平臺，匹配最近的司機和乘客。

正是因為Elasticsearch如此流行并且就在我們身邊，我決定深入研究一下。本文，我將分享Elasticsearch的存儲模型和CRUD操作的工作原理。

當我在思考分布式系統(tǒng)是如何工作時，我腦海里的圖案是這樣的：

水面以上的是API，以下的才是真正的引擎，一切魔幻般的事件都發(fā)生在水下。本文所關(guān)注的就是水下的部分，我們將關(guān)注：

• Elasticsearch是主從架構(gòu)還是無主架構(gòu)
• Elasticsearch的存儲模型是什么樣的
• Elasticsearch是怎么執(zhí)行寫操作的
• Elasticsearch是怎么執(zhí)行讀操作的
• 如何定義搜索結(jié)果的相關(guān)性

在我們深入這些概念之前，讓我們熟悉下相關(guān)的術(shù)語。

1 辨析Elasticsearch的索引與Lucene的索引

Elasticsearch中的索引是組織數(shù)據(jù)的邏輯空間(就好比數(shù)據(jù)庫)。1個Elasticsearch的索引有1個或者多個分片(默認是5個)。分片對應實際存儲數(shù)據(jù)的Lucene的索引，分片自身就是一個搜索引擎。每個分片有0或者多個副本(默認是1個)。Elasticsearch的索引還包含"type"(就像數(shù)據(jù)庫中的表)，用于邏輯上隔離索引中的數(shù)據(jù)。在Elasticsearch的索引中，給定一個type，它的所有文檔會擁有相同的屬性(就像表的schema)。

(點擊放大圖像)

圖a展示了一個包含3個分片的Elasticsearch索引，每個分片擁有1個副本。這些分片組成了一個Elasticsearch索引，每個分片自身是一個Lucene索引。圖b展示了Elasticsearch索引、分片、Lucene索引和文檔之間的邏輯關(guān)系。

對應于關(guān)系數(shù)據(jù)庫術(shù)語

Elasticsearch Index == Database  Types == Tables  Properties == Schema

現(xiàn)在我們熟悉了Elasticsearch世界的術(shù)語，接下來讓我們看一下節(jié)點有哪些不同的角色。

2 節(jié)點類型

一個Elasticsearch實例是一個節(jié)點，一組節(jié)點組成了集群。Elasticsearch集群中的節(jié)點可以配置為3種不同的角色：

• 主節(jié)點：控制Elasticsearch集群，負責集群中的操作，比如創(chuàng)建/刪除一個索引，跟蹤集群中的節(jié)點，分配分片到節(jié)點。主節(jié)點處理集群的狀態(tài)并廣播到其他節(jié)點，并接收其他節(jié)點的確認響應。

  每個節(jié)點都可以通過設(shè)定配置文件elasticsearch.yml中的node.master屬性為true(默認)成為主節(jié)點。

  對于大型的生產(chǎn)集群來說，推薦使用一個專門的主節(jié)點來控制集群，該節(jié)點將不處理任何用戶請求。

• 數(shù)據(jù)節(jié)點：持有數(shù)據(jù)和倒排索引。默認情況下，每個節(jié)點都可以通過設(shè)定配置文件elasticsearch.yml中的node.data屬性為true(默認)成為數(shù)據(jù)節(jié)點。如果我們要使用一個專門的主節(jié)點，應將其node.data屬性設(shè)置為false。

• 客戶端節(jié)點：如果我們將node.master屬性和node.data屬性都設(shè)置為false，那么該節(jié)點就是一個客戶端節(jié)點，扮演一個負載均衡的角色，將到來的請求路由到集群中的各個節(jié)點。

Elasticsearch集群中作為客戶端接入的節(jié)點叫協(xié)調(diào)節(jié)點。協(xié)調(diào)節(jié)點會將客戶端請求路由到集群中合適的分片上。對于讀請求來說，協(xié)調(diào)節(jié)點每次會選擇不同的分片處理請求，以實現(xiàn)負載均衡。

在我們開始研究發(fā)送給協(xié)調(diào)節(jié)點的CRUD請求是如何在集群中傳播并被引擎執(zhí)行之前，讓我們先來看一下Elasticsearch內(nèi)部是如何存儲數(shù)據(jù)，以支持全文檢索結(jié)果的低延遲服務的。

存儲模型

Elasticsearch使用了Apache Lucene，后者是Doug Cutting(Apache Hadoop之父)使用Java開發(fā)的全文檢索工具庫，其內(nèi)部使用的是被稱為倒排索引的數(shù)據(jù)結(jié)構(gòu)，其設(shè)計是為全文檢索結(jié)果的低延遲提供服務。文檔是Elasticsearch的數(shù)據(jù)單位，對文檔中的詞項進行分詞，并創(chuàng)建去重詞項的有序列表，將詞項與其在文檔中出現(xiàn)的位置列表關(guān)聯(lián)，便形成了倒排索引。

這和一本書后面的索引非常類似，即書中包含的詞匯與其出現(xiàn)的頁碼列表關(guān)聯(lián)。當我們說文檔被索引了，我們指的是倒排索引。我們來看下如下2個文檔是如何被倒排索引的：

文檔1(Doc 1): Insight Data Engineering Fellows Program
文檔2(Doc 2): Insight Data Science Fellows Program

如果我們想找包含詞項"insight"的文檔，我們可以掃描這個(單詞有序的)倒排索引，找到"insight"并返回包含改詞的文檔ID，示例中是Doc 1和Doc 2。

為了提高可檢索性(比如希望大小寫單詞都返回)，我們應當先分析文檔再對其索引。分析包括2個部分：

• 將句子詞條化為獨立的單詞
• 將單詞規(guī)范化為標準形式

默認情況下，Elasticsearch使用標準分析器，它使用了：

• 標準分詞器以單詞為界來切詞
• 小寫詞條(token)過濾器來轉(zhuǎn)換單詞

還有很多可用的分析器在此不列舉，請參考相關(guān)文檔。

為了實現(xiàn)查詢時能得到對應的結(jié)果，查詢時應使用與索引時一致的分析器，對文檔進行分析。

注意：標準分析器包含了停用詞過濾器，但默認情況下沒有啟用。

現(xiàn)在，倒排索引的概念已經(jīng)清楚，讓我們開始CRUD操作的研究吧。我們從寫操作開始。

剖析寫操作

創(chuàng)建((C)reate)

當我們發(fā)送索引一個新文檔的請求到協(xié)調(diào)節(jié)點后，將發(fā)生如下一組操作：

• Elasticsearch集群中的每個節(jié)點都包含了改節(jié)點上分片的元數(shù)據(jù)信息。協(xié)調(diào)節(jié)點(默認)使用文檔ID參與計算，以便為路由提供合適的分片。Elasticsearch使用MurMurHash3函數(shù)對文檔ID進行哈希，其結(jié)果再對分片數(shù)量取模，得到的結(jié)果即是索引文檔的分片。

  shard = hash(document_id) % (num_of_primary_shards)

• 當分片所在的節(jié)點接收到來自協(xié)調(diào)節(jié)點的請求后，會將該請求寫入translog(我們將在本系列接下來的文章中講到)，并將文檔加入內(nèi)存緩沖。如果請求在主分片上成功處理，該請求會并行發(fā)送到該分片的副本上。當translog被同步(fsync)到全部的主分片及其副本上后，客戶端才會收到確認通知。
• 內(nèi)存緩沖會被周期性刷新(默認是1秒)，內(nèi)容將被寫到文件系統(tǒng)緩存的一個新段上。雖然這個段并沒有被同步(fsync)，但它是開放的，內(nèi)容可以被搜索到。
• 每30分鐘，或者當translog很大的時候，translog會被清空，文件系統(tǒng)緩存會被同步。這個過程在Elasticsearch中稱為沖洗(flush)。在沖洗過程中，內(nèi)存中的緩沖將被清除，內(nèi)容被寫入一個新段。段的fsync將創(chuàng)建一個新的提交點，并將內(nèi)容刷新到磁盤。舊的translog將被刪除并開始一個新的translog。

下圖展示了寫請求及其數(shù)據(jù)流。

(點擊放大圖像)

更新((U)pdate)和刪除((D)elete)

刪除和更新也都是寫操作。但是Elasticsearch中的文檔是不可變的，因此不能被刪除或者改動以展示其變更。那么，該如何刪除和更新文檔呢？

磁盤上的每個段都有一個相應的.del文件。當刪除請求發(fā)送后，文檔并沒有真的被刪除，而是在.del文件中被標記為刪除。該文檔依然能匹配查詢，但是會在結(jié)果中被過濾掉。當段合并(我們將在本系列接下來的文章中講到)時，在.del文件中被標記為刪除的文檔將不會被寫入新段。

接下來我們看更新是如何工作的。在新的文檔被創(chuàng)建時，Elasticsearch會為該文檔指定一個版本號。當執(zhí)行更新時，舊版本的文檔在.del文件中被標記為刪除，新版本的文檔被索引到一個新段。舊版本的文檔依然能匹配查詢，但是會在結(jié)果中被過濾掉。

文檔被索引或者更新后，我們就可以執(zhí)行查詢操作了。讓我們看看在Elasticsearch中是如何處理查詢請求的。

剖析讀操作((R)ead)

讀操作包含2部分內(nèi)容：

• 查詢階段
• 提取階段

我們來看下每個階段是如何工作的。

查詢階段

在這個階段，協(xié)調(diào)節(jié)點會將查詢請求路由到索引的全部分片(主分片或者其副本)上。每個分片獨立執(zhí)行查詢，并為查詢結(jié)果創(chuàng)建一個優(yōu)先隊列，以相關(guān)性得分排序(我們將在本系列的后續(xù)文章中講到)。全部分片都將匹配文檔的ID及其相關(guān)性得分返回給協(xié)調(diào)節(jié)點。協(xié)調(diào)節(jié)點創(chuàng)建一個優(yōu)先隊列并對結(jié)果進行全局排序。會有很多文檔匹配結(jié)果，但是，默認情況下，每個分片只發(fā)送前10個結(jié)果給協(xié)調(diào)節(jié)點，協(xié)調(diào)節(jié)點為全部分片上的這些結(jié)果創(chuàng)建優(yōu)先隊列并返回前10個作為hit。

提取階段

當協(xié)調(diào)節(jié)點在生成的全局有序的文檔列表中，為全部結(jié)果排好序后，它將向包含原始文檔的分片發(fā)起請求。全部分片填充文檔信息并將其返回給協(xié)調(diào)節(jié)點。

下圖展示了讀請求及其數(shù)據(jù)流。

(點擊放大圖像)

如上所述，查詢結(jié)果是按相關(guān)性排序的。接下來，讓我們看看相關(guān)性是如何定義的。

搜索相關(guān)性

相關(guān)性是由搜索結(jié)果中Elasticsearch打給每個文檔的得分決定的。默認使用的排序算法是tf/idf(詞頻/逆文檔頻率)。詞頻衡量了一個詞項在文檔中出現(xiàn)的次數(shù) (頻率越高 == 相關(guān)性越高)，逆文檔頻率衡量了詞項在全部索引中出現(xiàn)的頻率，是一個索引中文檔總數(shù)的百分比(頻率越高 == 相關(guān)性越低)。最后的得分是tf-idf得分與其他因子比如(短語查詢中的)詞項接近度、(模糊查詢中的)詞項相似度等的組合。

接下來有什么？

這些CRUD操作由Elasticsearch內(nèi)部的一些數(shù)據(jù)結(jié)構(gòu)所支持，這對于理解Elasticsearch的工作機制非常重要。在接下來的系列文章中，我將帶大家走進類似的那些概念并告訴大家在使用Elasticsearch中有哪些坑。

• Elasticsearch中的腦裂問題及防治措施
• 事務日志
• Lucene的段
• 為什么搜索時使用深層分頁很危險
• 計算搜索相關(guān)性中困難及權(quán)衡
• 并發(fā)控制
• 為什么Elasticsearch是準實時的
• 如何確保讀和寫的一致性

查看原文地址：http://insightdataengineering.com/blog/elasticsearch-crud

from:http://www.infoq.com/cn/articles/what-complete-micro-service-system-should-include?utm_source=infoq&utm_medium=popular_widget&utm_campaign=popular_content_list&utm_content=homepage

近幾年，微服務架構(gòu)迅速在整個技術(shù)社區(qū)竄紅，它被認為是IT軟件架構(gòu)的未來方向，大神Martin Fowler也給微服務極高的評價。那為什么我們需要微服務，微服務的真正優(yōu)勢到底是什么，一個完整的微服務系統(tǒng)，應該包含哪些功能，本文作者劉彥夫在軟件設(shè)計和開發(fā)領(lǐng)域有10多年工作經(jīng)驗，他將會從他的角度給出答案。

對微服務的基本理解

顧名思義，微服務要從兩個方面來理解，一個是“微”，一個是“服務”。體型小到一定程度才能叫“微”，這個程度是什么呢？一個身高1米6，體重90斤的MM，我們說她苗條。微服務也一樣，根據(jù)亞馬遜CEO Bezos給出的有趣定義，單個微服務的設(shè)計、開發(fā)、測試和運維的所有人加在一起吃飯，只需要兩個批薩就夠了，這是就是著名的two pizza team rule。

具備什么樣的能力才能算是“服務”？這個話題很大，我這里按照自己的片面理解總結(jié)一下，所謂服務就一定會區(qū)別于系統(tǒng)的功能，服務是一個或者一組相對的較小且獨立的功能單元，是用戶可以感知的功能最小集，比如：購物車，訂單，信用卡結(jié)算等都可以作為單個服務獨立提供。

這個理解顯然不夠深刻，為了進一步理解為什么微服務在近兩年業(yè)界迅速竄紅，理解為什么微服務會被認為是IT軟件架構(gòu)的未來方向，就要理解為什么我們需要微服務？它能給企業(yè)帶來什么價值。傳統(tǒng)企業(yè)的IT軟件大多都是各種獨立系統(tǒng)的堆砌，這些系統(tǒng)的問題總結(jié)來說就是擴展性差，可靠性不高，維護成本高。后來有了一個叫SOA的軟件架構(gòu)專門針對這些問題給出了一套解決方案，很多企業(yè)也因此將自身IT系統(tǒng)遷移到SOA架構(gòu)上。

但是，由于SOA早期均使用了總線模式，這種總線模式是與某種技術(shù)棧強綁定的，比如：J2EE。這導致很多企業(yè)的遺留系統(tǒng)很難對接，切換時間太長，成本太高，新系統(tǒng)穩(wěn)定性的收斂也需要一些時間。最終SOA開起來很美，但卻成為了企業(yè)級奢侈品，中小公司都望而生畏。

依然SOA

微服務，從本質(zhì)意義上看，還是SOA架構(gòu)。但內(nèi)涵有所不同，微服務并不綁定某種特殊的技術(shù)，在一個微服務的系統(tǒng)中，可以有Java編寫的服務，也可以有Python編寫的服務，他們是靠Restful架構(gòu)風格統(tǒng)一成一個系統(tǒng)的。

最粗淺的理解就是將微服務之間的交互看作是各種字符串的傳遞，各種語言都可以很好的處理字符串，所以微服務本身與具體技術(shù)實現(xiàn)無關(guān)，擴展性強。另一個不同是微服務架構(gòu)本身很輕，底層也有類似于SOA的總線，不過非常輕薄，現(xiàn)在看到的就兩種方式：MQ和HTTP，而HTTP都不能完全等同于總線，而僅僅是個信息通道。

所以，基于這種簡單的的協(xié)議規(guī)范，無論是兼容老舊系統(tǒng)，還是上線新業(yè)務，都可以隨著時代的步伐，滾動升級。比如：你去年還在使用.NET技術(shù)，今年就可以平滑的過度到Go了，而且系統(tǒng)已有服務不用改動。所以微服務架構(gòu)，既保護用戶已有投資，又很容易向新技術(shù)演進。

微服務水下的冰山

人月不是銀彈，微服務更不是銀彈，好像軟件微服務化了，軟件系統(tǒng)就能夠應對各種問題了。其實微服務的水面下藏著巨大的冰山。下面是微服務提供的能力，以及背后需要付出的代價。

1. 單個微服務代碼量小，易修改和維護。但是，系統(tǒng)復雜度的總量是不變的，每個服務代碼少了，但服務的個數(shù)肯定就多了。就跟拼圖游戲一樣，切的越碎，越難拼出整幅圖。一個系統(tǒng)被拆分成零碎的微服務，最后要集成為一個完整的系統(tǒng)，其復雜度肯定比大塊的功能集成要高很多。

2. 單個微服務數(shù)據(jù)獨立，可獨立部署和運行。雖然微服務本身是可以獨立部署和運行的，但仍然避免不了業(yè)務上的你來我往，這就涉及到要對外通信，當微服務的數(shù)量達到一定量級的時候，如何提供一個高效的集群通信機制成為一個問題。

3. 單個微服務擁有自己的進程，進程本身就可以動態(tài)的啟停，為無縫升級的打好了基礎(chǔ)，但誰來啟動和停止進程，什么時機，選擇在哪臺設(shè)備上做這件事情才是無縫升級的關(guān)鍵。這個能力并不是微服務本身提供的，而是需要背后強大的版本管理和部署能力。

4. 多個相同的微服務可以做負載均衡，提高性能和可靠性。正是因為相同微服務可以有多個不同實例，讓服務按需動態(tài)伸縮成為可能，在高峰期可以啟動更多的相同的微服務實例為更多用戶服務，以此提高響應速度。同時這種機制也提供了高可靠性，在某個微服務故障后，其他相同的微服務可以接替其工作，對外表現(xiàn)為某個設(shè)備故障后業(yè)務不中斷。同樣的道理，微服務本身是不會去關(guān)心系統(tǒng)負載的，那么什么時候應該啟動更多的微服務，多個微服務的流量應該如何調(diào)度和分發(fā)，這背后也有一套復雜的負載監(jiān)控和均衡的系統(tǒng)在起作用。

5. 微服務可以獨立部署和對外提供服務，微服務的業(yè)務上線和下線是動態(tài)的，當一個新的微服務上線時，用戶是如何訪問到這種新的服務？這就需要有一個統(tǒng)一的入口，新的服務可以動態(tài)的注冊到這個入口上，用戶每次訪問時可以從這個入口拿到系統(tǒng)所有服務的訪問地址，類似于到餐廳吃飯，新菜要寫到“菜單”中，以供用戶選擇。這個統(tǒng)一的系統(tǒng)入口并不是微服務本身的一部分，所以這種能力需要系統(tǒng)單獨提供。

6. 還有一些企業(yè)級關(guān)注的系統(tǒng)問題，比如，安全策略如何集中管理？系統(tǒng)故障如何快速審計和跟蹤到具體服務？整個系統(tǒng)狀態(tài)如何監(jiān)控？服務之間的依賴關(guān)系如何管理？等等這些問題都不是單個微服務考慮的范疇，而需要有一個系統(tǒng)性的考慮和設(shè)計，讓每個微服務都能夠按照系統(tǒng)性的要求和約束提供對應的安全性，可靠性，可維護性的能力。

綜上所述，微服務關(guān)鍵其實不僅僅是微服務本身，而是系統(tǒng)要提供一套基礎(chǔ)的架構(gòu)，這種架構(gòu)使得微服務可以獨立的部署、運行、升級，不僅如此，這個系統(tǒng)架構(gòu)還讓微服務與微服務之間在結(jié)構(gòu)上“松耦合”，而在功能上則表現(xiàn)為一個統(tǒng)一的整體。這種所謂的“統(tǒng)一的整體”表現(xiàn)出來的是統(tǒng)一風格的界面，統(tǒng)一的權(quán)限管理，統(tǒng)一的安全策略，統(tǒng)一的上線過程，統(tǒng)一的日志和審計方法，統(tǒng)一的調(diào)度方式，統(tǒng)一的訪問入口等等。

這些系統(tǒng)性的功能也需要有一些服務來提供，這些服務不會直接呈現(xiàn)給最終用戶，也就是微服務系統(tǒng)冰山下面的部分，我們可以簡稱它為微服務系統(tǒng)的“底座”。所有的微服務都像一個APP，插在這個底座的上面，享受這個底座提供的系統(tǒng)能力比如：元數(shù)據(jù)存放、灰度發(fā)布、藍綠部署等等。

微服務系統(tǒng)底座

一個完整的微服務系統(tǒng)，它的底座最少要包含以下功能：

• 日志和審計，主要是日志的匯總，分類和查詢

• 監(jiān)控和告警，主要是監(jiān)控每個服務的狀態(tài)，必要時產(chǎn)生告警

• 消息總線，輕量級的MQ或HTTP

• 注冊發(fā)現(xiàn)

• 負載均衡

• 部署和升級

• 事件調(diào)度機制

• 資源管理，如：底層的虛擬機，物理機和網(wǎng)絡(luò)管理

以下功能不是最小集的一部分，但也屬于底座功能：

• 認證和鑒權(quán)

• 微服務統(tǒng)一代碼框架，支持多種編程語言

• 統(tǒng)一服務構(gòu)建和打包

• 統(tǒng)一服務測試

• 微服務CI/CD流水線

• 服務依賴關(guān)系管理

• 統(tǒng)一問題跟蹤調(diào)試框架，俗稱調(diào)用鏈

• 灰度發(fā)布

• 藍綠部署

令人困惑的幾個問題

微服務的底座是不是必須的？

是的，基本上是必須的。你可以不用代碼實現(xiàn)一個資源管理服務，可以手工用Excel管理你的所有機器資源，但是不代表微服務系統(tǒng)沒有這個功能，只不過這個功能是人工實現(xiàn)的。再舉個例子，日志系統(tǒng)如果只是簡單的打印文件，那么多個微服務的日志就需要手工收集，人工分類和篩選。所以，微服務的底座最小集一定會存在，問題是看怎樣實現(xiàn)它。

這里僅僅是總結(jié)了對微服務系統(tǒng)的基本理解，而實現(xiàn)這個架構(gòu)有很多技術(shù)，這里不進行詳細展開。實踐方面，推薦王磊的《微服務架構(gòu)與實踐》，他描述了使用Ruby相關(guān)的技術(shù)實現(xiàn)了一整套微服務系統(tǒng)，特別是書中后面的實踐部分講解了如何將已有的系統(tǒng)演化為微服務架構(gòu)，是很好的參考和指導材料。

是不是所有軟件都能做微服務？

這個命題有些微妙，也很難說清楚，回答這個命題本身就是一種挑戰(zhàn)，可能最終也沒有正確答案。不過，我還是把我自己的理解寫在這里，讓大家去拍磚。在我這里，答案是否定的。我只需舉出一個反例，比如：存儲系統(tǒng)，其架構(gòu)是傳統(tǒng)的分層架構(gòu)，每一層都使用下面一層的服務，并為上一層提供服務。雖然可以將這種架構(gòu)調(diào)整為基于服務的架構(gòu)，但沒辦法做成微服務。

區(qū)別在哪里呢？核心的區(qū)別在于獨立性上，微服務大多是可以獨立的運行和使用的，而存儲這種非常底層和基礎(chǔ)的系統(tǒng)，每層部件都不能單獨被使用，比如：Pool管理、CHUNK管理、VOL管理、NFS文件系統(tǒng)，這些功能都無法離開另外一些功能而獨立運行，要對外提供可用的存儲功能，一大堆功能必須一起上。這種系統(tǒng)做到極致，最多也就能夠使其部件可以獨立的部署和升級，俗稱打熱補丁。

這也就是為什么這種底層傳統(tǒng)系統(tǒng)架構(gòu)通常是單塊架構(gòu)的原因。由于單塊架構(gòu)的各個部分調(diào)用關(guān)系緊密，做成微服務后系統(tǒng)集成成本會大大增加，不僅如此，這樣的架構(gòu)做成微服務并不能提高交付效率，因為各個部分根本就無法獨立的運行和測試。

什么樣的軟件做成微服務？

能不能做成微服務，取決于四個要素：

• 小：微服務體積小，2 pizza團隊。

• 獨：能夠獨立的部署和運行。

• 輕：使用輕量級的通信機制和架構(gòu)。

• 松：為服務之間是松耦合的。

針對于小、輕、松都是可以通過某些技術(shù)手段達到目的，而獨立的部署和運行，則是和業(yè)務本身有關(guān)系，如果你這個系統(tǒng)提供的業(yè)務是貼近最終用戶的，并且這些功能之間的耦合性很小，則微服務就可以按照業(yè)務功能本身的獨立性來劃分，則這類系統(tǒng)做成微服務是非常合適的。如果系統(tǒng)提供的業(yè)務是非常底層的，如：操作系統(tǒng)內(nèi)核、存儲系統(tǒng)、網(wǎng)絡(luò)系統(tǒng)、數(shù)據(jù)庫系統(tǒng)等等，這類系統(tǒng)都偏底層，功能和功能之間有著緊密的配合關(guān)系，如果強制拆分為較小的服務單元，會讓集成工作量急劇上升，并且這種人為的切割無法帶來業(yè)務上的真正的隔離，所以無法做到獨立部署和運行，也就更加無法做到真正的微服務了。

---

感謝郭蕾對本文的審校。

給InfoQ中文站投稿或者參與內(nèi)容翻譯工作，請郵件至editors@cn.infoq.com。也歡迎大家通過新浪微博（@InfoQ，@丁曉昀），微信（微信號：InfoQChina）關(guān)注我們。