架構(gòu)
ArangoDB的集群是遵循master/master架構(gòu)的，沒有單點(diǎn)故障，遵循CAP理論中的“CP”剑辫。“CP”的意思就是當(dāng)發(fā)生網(wǎng)絡(luò)分區(qū)通訊異常的時(shí)候渠欺，數(shù)據(jù)庫優(yōu)先考慮內(nèi)部一致性而非可用性妹蔽。使用“master / master”意味著客戶端可以將其請(qǐng)求發(fā)送到任意節(jié)點(diǎn)，并且在每個(gè)節(jié)點(diǎn)上看到的數(shù)據(jù)庫視圖都是一致的。 “沒有單點(diǎn)故障”意味著群集中任何一個(gè)節(jié)點(diǎn)完全宕機(jī)都不會(huì)對(duì)整個(gè)集群的服務(wù)產(chǎn)生任何影響讹开，集群都可以繼續(xù)提供服務(wù)盅视。
通過這種方式，ArangoDB被設(shè)計(jì)為分布式多模型數(shù)據(jù)庫旦万。本節(jié)簡(jiǎn)要介紹了集群體系結(jié)構(gòu)以及如何實(shí)現(xiàn)上述特性和功能闹击。
ArangoDB集群
ArangoDB集群由許多ArangoDB實(shí)例組成，這些實(shí)例通過網(wǎng)絡(luò)相互通信成艘。它們分別具備不同的角色赏半，關(guān)于各個(gè)角色的描述會(huì)在下面詳細(xì)解釋。集群的配置信息保存在“Agency”中淆两，Agency是一個(gè)高度可用的彈性分布式鍵/值存儲(chǔ)断箫，agency服務(wù)由奇數(shù)個(gè)進(jìn)行Raft復(fù)制的ArangoDB的實(shí)例組成。
對(duì)于ArangoDB集群中的各種實(shí)例秋冰，有4個(gè)不同的角色：Agent仲义，Coordinator,Primary 和Secondary DBserver。下面我們將會(huì)對(duì)每種角色進(jìn)行詳細(xì)闡述剑勾。請(qǐng)注意埃撵，無論實(shí)例是哪種角色，實(shí)例都是基于同一個(gè)Docker鏡像運(yùn)行相同的二進(jìn)制文件虽另。ArangoDB集群的整體架構(gòu)如下圖所示：
Agent
一個(gè)或多個(gè)Agent形成ArangoDB集群中服務(wù)“agency”暂刘。“agency”是整個(gè)集群配置信息的存儲(chǔ)中心捂刺∫ゼ穑“agency”執(zhí)行l(wèi)eader選舉并為整個(gè)群集提供其他同步服務(wù)∽逭梗“agency”是整個(gè)集群的心臟森缠，所有其他任何組件都依賴于“agency”。
“agency”對(duì)集群外部是不可見的仪缸。由于“agency”是整個(gè)ArangoDB集群的核心辅鲸，因此必須具備高容錯(cuò)性。為了實(shí)現(xiàn)這一點(diǎn)腹殿，Agent之間采用Raft 一致性算法進(jìn)行復(fù)制独悴。
"agency"管理一個(gè)大型配置樹。它支持在此樹上執(zhí)行??事務(wù)性讀取和寫入操作锣尉，而其他服務(wù)器可以為樹的所有更改訂閱HTTP回調(diào)刻炒。
Coordinator
若外部client端需要訪問ArangoDB，則必須通過Coordinator自沧。它們將協(xié)調(diào)集群任務(wù)坟奥，如執(zhí)行查詢和運(yùn)行Foxx服務(wù)树瞭。它們知道數(shù)據(jù)的存儲(chǔ)位置，并優(yōu)化用戶提交的查詢爱谁。Coordinator是無狀態(tài)的晒喷，因此可以根據(jù)需要隨時(shí)關(guān)閉或重新啟動(dòng)。
Primary DBserver
Primary DBserver是實(shí)際托管數(shù)據(jù)的服務(wù)器访敌。它們托管數(shù)據(jù)分片并使用進(jìn)行分片的同步復(fù)制凉敲，主分區(qū)可以是分片的領(lǐng)導(dǎo)者或跟隨者。
Client端不應(yīng)從外部直接訪問它們寺旺，而應(yīng)通過Coordinators間接訪問它們爷抓。Coordinator向其發(fā)起查詢，Primary DBserver負(fù)責(zé)執(zhí)行部分或者全部查詢阻塑。
Secondary DBserver
Secondary DBserver是Primary DBserver的異步復(fù)制蓝撇。如果只使用同步復(fù)制，則根本不需要Secondary DBserver陈莽。對(duì)于每個(gè)Primary DBserver渤昌，可以有一個(gè)或多個(gè)Secondary DBserver。由于復(fù)制以異步方式工作（最終一致性）走搁，因此復(fù)制不會(huì)影響Primary DBserver的性能独柑，但是，Secondary DBserver的數(shù)據(jù)副本可能會(huì)略微過時(shí)朱盐。Secondary DBserver非常適合用于備份群嗤，因?yàn)樗鼈儾粫?huì)影響正常的群集服務(wù)和操作菠隆。
Cluster ID
群集中的每個(gè)非 agency ArangoDB實(shí)例在其啟動(dòng)時(shí)都會(huì)為其分配一個(gè)唯一的ID兵琳。使用該ID，可以在整個(gè)群集中識(shí)別節(jié)點(diǎn)骇径。集群中的所有操作都將通過此ID進(jìn)行各個(gè)實(shí)例間的互相通信躯肌。
Sharding
ArangoDB集群以Shard的形式在各個(gè)Primary DBserver之間分布數(shù)據(jù)，而這個(gè)過程對(duì)集群外部來說是完全透明的破衔，通過這種方式清女，我們實(shí)現(xiàn)了“主 - 主復(fù)制”。Client端可以與任何Coordinator通信晰筛，無論何時(shí)讀取或?qū)懭霐?shù)據(jù)嫡丙，Coordinator都會(huì)自動(dòng)確定最優(yōu)的數(shù)據(jù)讀取或?qū)懙奈恢谩８鱾€(gè)Shard的相關(guān)信息也是存儲(chǔ)在“agency”中读第，各個(gè)Coordinator通過“agency”實(shí)現(xiàn)了Shard的信息的共享曙博。
集群配置建議
ArangoDB的架構(gòu)非常靈活，允許進(jìn)行多種配置怜瞒，以適用于不同的使用場(chǎng)景：
1.默認(rèn)配置是在每臺(tái)計(jì)算機(jī)上運(yùn)行一個(gè)coordinator和一個(gè)Primary DBserver父泳。這樣就自然的實(shí)現(xiàn)了經(jīng)典的主/主設(shè)置，因?yàn)樵诓煌?jié)點(diǎn)之間存在完美的對(duì)稱性，Client可以與任何一個(gè)協(xié)調(diào)器進(jìn)行通信惠窄，并且所有Client看到的數(shù)據(jù)視圖都是一致的蒸眠。
2.可以部署比DBservers更多的coordinators。當(dāng)需要部署大量的Foxx服務(wù)時(shí)杆融，這種方式比較適合楞卡，因?yàn)镕oxx是運(yùn)行在coordinator上的。
3.如果數(shù)據(jù)量比較大擒贸，而查詢請(qǐng)求并不多臀晃，則可以部署的DBServer的數(shù)量可以比Coordinator多。
4.DBServer與coordinator分開部署介劫』胀铮可以在應(yīng)用程序服務(wù)器（例如node.js服務(wù)器）上部署Coordinator，在另外的獨(dú)立的服務(wù)器上部署agent程序和DBServer座韵。這避免了應(yīng)用服務(wù)器和數(shù)據(jù)庫之間的網(wǎng)絡(luò)調(diào)準(zhǔn)次數(shù)险绘，從而減少了延遲。從本質(zhì)上講誉碴，這會(huì)將一些數(shù)據(jù)庫分發(fā)邏輯移動(dòng)到客戶端運(yùn)行的機(jī)器上宦棺。
綜上所述：Coordinator層是可以獨(dú)立于DBServer層進(jìn)行獨(dú)立部署和擴(kuò)展的。
Replication
ArangoDB在集群內(nèi)部提供了兩種data repliation的方式：同步和異步黔帕。下面我們將會(huì)分別對(duì)這兩種方式進(jìn)行詳細(xì)說明代咸。
具備自動(dòng)FailOver特性的同步復(fù)制
ArangoDB可以基于每個(gè)Shard進(jìn)行同步復(fù)制。您可以針對(duì)每個(gè)collection配置每個(gè)分片的副本數(shù)成黄。任何時(shí)候呐芥，只要某個(gè)shard中的其中一個(gè)副本聲明為“l(fā)eader”，所有其他副本就都是“follower”奋岁。針對(duì)此shard的寫入操作始終發(fā)送到持有l(wèi)eader副本的DBserver思瘟，該DBServer在完成本地副本的寫入之后，會(huì)將更改同步復(fù)制到所有的follower闻伶，只有在所有的follower都復(fù)制成功之后滨攻，才會(huì)報(bào)告給Coordinator并視為該寫入操作完成。讀取操作也都由持有l(wèi)eader副本的DBServer提供服務(wù)蓝翰，這樣就可以為復(fù)雜事務(wù)提供快照語義光绕。
如果持有某個(gè)Shard follower副本的DBserver宕機(jī)，則leader將無法再將其更改與該跟follower同步畜份。在短暫的超時(shí)（3秒）之后诞帐，leader就會(huì)放棄該follower，并聲明該follower已經(jīng)out of sync漂坏，并將該follower排除在外景埃，繼續(xù)服務(wù)媒至。當(dāng)持有follower副本的DBServer恢復(fù)正常后，它會(huì)自動(dòng)將其數(shù)據(jù)與leader重新同步谷徙，并恢復(fù)同步復(fù)制拒啰。
若持有某個(gè)shard的leader副本的DBServere宕機(jī)，那么該leader將不再服務(wù)于任何請(qǐng)求完慧。它也不再向“agency”發(fā)送心跳谋旦。因此，“agency”Raft leader中的監(jiān)控進(jìn)程將會(huì)采取必要措施（在丟失心跳15秒之后）屈尼，即將持有該shard的follower中的一個(gè)DBServer提升為該shard的leader册着。這會(huì)涉及到agency的重新配置，并導(dǎo)致coordinator將對(duì)該shard的請(qǐng)求定位到新的leader上脾歧。其他的follower會(huì)自動(dòng)將其數(shù)據(jù)與新的leader重新同步甲捏。當(dāng)具有原始leader副本的DBserver恢復(fù)時(shí)，它發(fā)現(xiàn)已經(jīng)產(chǎn)生了新的leader鞭执，因此它會(huì)將其數(shù)據(jù)與新領(lǐng)導(dǎo)者重新同步司顿。
所有shard的數(shù)據(jù)同步都以增量方式完成，通過這種方式重新同步會(huì)很快兄纺。通過這種同步方式可以在不中斷服務(wù)的情況下大溜，完成shard在不同DBServer之間的移動(dòng)。因此估脆，ArangoDB集群可以將特定DBServer上的所有數(shù)據(jù)移動(dòng)到其他DBServer钦奋，然后關(guān)閉該服務(wù)器，通過這種方式疙赠，可以在不中服務(wù)付材，不丟失數(shù)據(jù)的前提下進(jìn)行ArangoDB集群縮容。此外棺聊，可以手動(dòng)或自動(dòng)進(jìn)行shard的rebalance伞租。
所有這些操作都可以通過REST / JSON API或圖形Web UI觸發(fā)贞谓。所有故障轉(zhuǎn)移操作都在ArangoDB集群中自動(dòng)完全的限佩。
顯然，同步復(fù)制會(huì)降低寫入的性能（導(dǎo)致寫入操作延時(shí)增加）裸弦。但是祟同，用戶可以將復(fù)制因子設(shè)置為1，這意味著只保留每個(gè)分片的一個(gè)副本理疙，從而關(guān)閉同步復(fù)制晕城。對(duì)于低延遲寫入操作很重要但是又不太重要或易于恢復(fù)的數(shù)據(jù)，將復(fù)制因子設(shè)置為1比較合適窖贤。
具備自動(dòng)FailOver特性的同步復(fù)制
異步復(fù)制的工作機(jī)制與同步復(fù)制不同砖顷，因?yàn)樗婕暗绞褂胮rimary dbserver和secondary dbserver贰锁。每個(gè)secondary dbserver通過異步方式輪詢來復(fù)制primary dbserver上保存的所有數(shù)據(jù)。這個(gè)過程對(duì)primary dbserver的性能影響很小滤蝠。缺點(diǎn)是在secondary dbserver上的數(shù)據(jù)更新要晚于primary dbserver上的數(shù)據(jù)豌熄，存在數(shù)據(jù)更新的延時(shí)。如果primary dbserver在此延時(shí)期間宕機(jī)物咳，則提交和確認(rèn)的數(shù)據(jù)可能會(huì)丟失锣险。
不過，arangodb還針對(duì)異步復(fù)制提供了自動(dòng)故障轉(zhuǎn)移功能览闰。與同步復(fù)制情況相反芯肤，此處故障轉(zhuǎn)移管理是在ArangoDB集群外部完成的。在未來的版本中压鉴，arangodb可能會(huì)將此功能移至agency中崖咨，但截至目前，該功能是通過ArangoDB的Mesos框架調(diào)度程序完成的（見下文）油吭。
異步復(fù)制的粒度是一個(gè)完整的ArangoDB實(shí)例掩幢，包含駐留在該實(shí)例上的所有數(shù)據(jù)，這意味著若啟動(dòng)異步復(fù)制上鞠，那么arangodb的實(shí)例數(shù)量將會(huì)翻倍际邻。相比而言，同步復(fù)制更靈活芍阎，在同步復(fù)制中實(shí)例的大小是隨意的世曾，而且如果一個(gè)dbserver失敗，則可以在剩余的dbserver之間重新平衡數(shù)據(jù)谴咸。
微服務(wù)與零運(yùn)維
ArangoDB的設(shè)計(jì)和功能適用于微服務(wù)架構(gòu)轮听。使用Foxx服務(wù)，可以非常輕松地在ArangoDB集群中部署以數(shù)據(jù)為中心的微服務(wù)岭佳。
此外血巍，可以在同一個(gè)項(xiàng)目中部署多個(gè)ArangoDB實(shí)例。項(xiàng)目的一些模塊可能需要可擴(kuò)展的文檔存儲(chǔ)珊随，另一部分可能需要圖形數(shù)據(jù)庫述寡，而另一部分可能需要混合各種數(shù)據(jù)模型的多模型數(shù)據(jù)庫的全部功能。通過將單一技術(shù)用于項(xiàng)目中的各個(gè)模塊叶洞，可以極大地提升效率鲫凶。
為了盡量減少arangodb的運(yùn)維成本，我們盡可能地實(shí)現(xiàn)ArangoDB的零管理與零運(yùn)維衩辟。正在運(yùn)行的ArangoDB集群可以實(shí)現(xiàn)故障自愈螟炫。
Apache Mesos 集成
對(duì)于分布式部署，ArangoDB默認(rèn)使用Apache Mesos作為基礎(chǔ)部署組件艺晴。 ArangoDB是一個(gè)通過了全部認(rèn)證的DC / OS軟件包昼钻，一旦擁有現(xiàn)有的DC / OS集群掸屡，就可以簡(jiǎn)單地完成快速部署。即使在一個(gè)普通的Apache Mesos集群上然评，也可以只需一個(gè)API調(diào)用和一些JSON配置折晦，通過Marathon完成ArangoDB的部署。
這種方式的優(yōu)點(diǎn)是我們不僅可以實(shí)現(xiàn)初始部署沾瓦，還可以實(shí)現(xiàn)后續(xù)的自動(dòng)failover和ArangoDB集群的擴(kuò)容（手動(dòng)或甚至自動(dòng)觸發(fā)）满着。由于所有操作都是通過圖形Web UI或通過JSON / REST調(diào)用，因此甚至可以非常輕松地實(shí)現(xiàn)自動(dòng)縮放贯莺。
因?yàn)镈C / OS集群部署各種服務(wù)非常方便风喇，所以是部署微服務(wù)架構(gòu)的非常自然的環(huán)境，包括在同一DC / OS集群中可能存在多個(gè)ArangoDB集群實(shí)例缕探。內(nèi)置的服務(wù)發(fā)現(xiàn)使得連接各種微服務(wù)變得非常簡(jiǎn)單魂莫，Mesos會(huì)自動(dòng)處理各種任務(wù)的分發(fā)和部署。
查看 部署 章節(jié)爹耗，了解如何完成集群化部署耙考。
可以通過簡(jiǎn)單地使用正確的命令行選項(xiàng)啟動(dòng)一批Docker容器來構(gòu)建ArangoDB集群，甚至可以在單個(gè)機(jī)器上啟動(dòng)多個(gè)ArangoDB進(jìn)程來部署ArangoDB集群潭兽。在這種方式下倦始，在部署的ArangoDB集群中將會(huì)采用同步復(fù)制，并且可以提供自動(dòng)failover的功能山卦。但是鞋邑，由于ArangoDB集群本身無法啟動(dòng)其他實(shí)例，因此無法自動(dòng)更換故障節(jié)點(diǎn)账蓉，并且必須手動(dòng)就進(jìn)行擴(kuò)容和縮容枚碗。因此不建議在生產(chǎn)環(huán)境采用這種方式進(jìn)行部署。
數(shù)據(jù)模型及擴(kuò)展性
本節(jié)說明ArangoDB支持的不同的數(shù)據(jù)模型铸本。
Key/value 模型
K/V數(shù)據(jù)模型是最容易擴(kuò)展的肮雨。在ArangoDB中，由于文檔集合始終具有主鍵_key屬性箱玷，因此很容易給予文檔實(shí)現(xiàn)K/V存儲(chǔ)怨规，并且不存在其他二級(jí)索引的情況下，文檔集合的行為類似于簡(jiǎn)單的K/V存儲(chǔ)汪茧。
在K/V模型中唯一的操作就是單鍵查找和單鍵/值對(duì)插入和更新椅亚。如果_key是唯一的分片屬性限番，則分片是相對(duì)于主鍵完成的舱污，這時(shí)所有這些操作都是線性縮放的。如果_key是唯一的分片屬性或者根據(jù)文檔中的其他屬性值進(jìn)行分片弥虐，則即使查找單個(gè)鍵也會(huì)涉及訪問所有分片扩灯，因此服務(wù)能力不能線性擴(kuò)展媚赖。
Document模型
Document模型中，即使存在二級(jí)索引珠插，二級(jí)索引也和以及索引的屬性基本相同惧磺，因?yàn)榉制系乃饕c每個(gè)分片的本地索引基本相同。因此捻撑，單個(gè)文檔操作仍然會(huì)隨著群集的大小線性擴(kuò)展磨隘，除非特殊的分片配置才會(huì)是的文檔操作（查詢和寫入）的性能及其低下。
更深入的分析顾患，請(qǐng)參考 這篇博客 其中說明了如何實(shí)現(xiàn)ArangoDB對(duì)單文檔操作的線性可伸縮性番捂。
復(fù)雜查詢和Join
AQL查詢語言支持復(fù)雜查詢，二級(jí)索引以及join江解。特別是二級(jí)索引以及join查詢设预，這種操作的性能無法給予集群規(guī)模進(jìn)行提升，因?yàn)槿绻尤氲臄?shù)據(jù)駐留在不同的機(jī)器和分片上犁河，則必須掃描所有的分片鳖枕。 AQL查詢執(zhí)行引擎在整個(gè)集群中組織數(shù)據(jù)管道，以最有效的方式匯總結(jié)果桨螺。查詢優(yōu)化器知道集群的拓?fù)浣Y(jié)構(gòu)宾符，并知道哪些數(shù)據(jù)在哪里以及如何編制索引。因此灭翔，它可以在針對(duì)查詢的哪些部分應(yīng)該在集群中的哪個(gè)位置運(yùn)行時(shí)做出明智的決策吸奴。
雖然入冊(cè)，但是對(duì)于某些復(fù)雜的join查詢缠局，能采取的優(yōu)化措施還是有限的则奥。
圖數(shù)據(jù)庫
圖形數(shù)據(jù)庫特別適用于涉及進(jìn)行未知長(zhǎng)度路徑的查詢。例如：在圖中的兩個(gè)頂點(diǎn)之間找到最短路徑狭园，或者找到與在給定頂點(diǎn)處開始的特殊匹配的所有路徑读处。
但是，如果路徑上的頂點(diǎn)和邊分布在整個(gè)集群中唱矛，則需要在節(jié)點(diǎn)和分片之間需要進(jìn)行大量的通信罚舱，性能就會(huì)受到影響。為了在規(guī)模上實(shí)現(xiàn)良好性能绎谦，則需要在集群中的分片中合理地分布數(shù)據(jù)管闷。大多數(shù)時(shí)候，ArangoDB的應(yīng)用程序開發(fā)人員和用戶最了解他們的圖表是如何構(gòu)建的窃肠。因此包个，ArangoDB允許用戶根據(jù)圖數(shù)據(jù)的分片來指定。一個(gè)比較有效的優(yōu)化措施就是：確保始發(fā)于某個(gè)頂點(diǎn)的邊與該頂點(diǎn)位于同一個(gè)分片或者節(jié)點(diǎn)上冤留。
限制
ArangoDB沒有水平伸縮性限制碧囊。核心的“agency”模塊可以輕松地支持?jǐn)?shù)百臺(tái)DBServer和Coordinator树灶，一般的數(shù)據(jù)庫操作都是完全分布式的，一般不需要“agency”的介入糯而。
同樣天通，Agency的監(jiān)控進(jìn)程可以輕松監(jiān)控大量服務(wù)器，因?yàn)楸O(jiān)控進(jìn)程的所有活動(dòng)都不需要高性能熄驼。
顯然像寒，ArangoDB集群受CPU，內(nèi)存瓜贾，磁盤和網(wǎng)絡(luò)帶寬和延遲等可用資源的限制萝映。
參考：
https://docs.arangodb.com/3.3/Manual/Scalability/Architecture.html
https://docs.arangodb.com/3.3/Manual/Scalability/DataModels.html
