SF同其它框架的差異點(diǎn)，主要在于以下幾個(gè)設(shè)計(jì)原則上：

1. 純分布式
2. 狀態(tài)的強(qiáng)一致并且可擴(kuò)展
3. 支持stateful的service，這里application默認(rèn)的模式基本都是一主多從的有狀態(tài)服務(wù)，所以論文里面提到的data aware，主要是 a. 放置或者routing時(shí)候渤闷，對(duì)于主或者從的選擇, b. fail over時(shí)候的策略

Layered Desgin

基于上面兩個(gè)最重要的需求，SF本身分成兩個(gè)層次來解決這個(gè)問題

1. Federation System: 解決兩個(gè)最關(guān)鍵的問題脖镀，系統(tǒng)節(jié)點(diǎn)的狀態(tài)和通信的路由問題
2. Reliability System: 解決Service相關(guān)的問題飒箭，例如如何放置，Service replica蜒灰，F(xiàn)ailover的選擇

15305958495419.jpg

Federation System

這一層算是整個(gè)SF最核心的部分弦蹂，主要解決對(duì)于系統(tǒng)狀態(tài)的強(qiáng)一致性共識(shí)。系統(tǒng)狀態(tài)包括：

• 處理某個(gè)服務(wù)（Key）的節(jié)點(diǎn)在哪
• 整個(gè)SF中節(jié)點(diǎn)的狀態(tài)
• 一個(gè)application的集群的狀態(tài)：例如leader是哪個(gè)

SF Ring

從邏輯上强窖，整個(gè)SF的世界可以抽象成一個(gè)SF Ring的結(jié)構(gòu)盈匾，一個(gè)SF Ring具備2^128個(gè)節(jié)點(diǎn)，Node和Key都會(huì)被Map到這個(gè)Ring上的某個(gè)點(diǎn)毕骡。

因?yàn)镾F從設(shè)計(jì)上需要避免對(duì)于單節(jié)點(diǎn)的依賴削饵，所以Ring上的一個(gè)Node的鄰居們，就需要負(fù)責(zé)Node之間的Failure Detection未巫，Membership管理等職責(zé)

Failure Detection & Membership Management

因?yàn)镾F通過Ring上的鄰居們相互監(jiān)督窿撬，所以設(shè)計(jì)中的強(qiáng)一致性狀態(tài)，指的也是這一批鄰居中對(duì)于節(jié)點(diǎn)的存活和系統(tǒng)成員的認(rèn)識(shí)是一致的叙凡。

SF這里將Membership的維護(hù)分成了兩個(gè)部分：

1. Failure的探測

   一個(gè)Node會(huì)有一個(gè)Monitor Set劈伴，基本上就是它在Ring上的鄰居，為了保證強(qiáng)一致性，所有Monitor都必須對(duì)同一個(gè)節(jié)點(diǎn)的狀態(tài)有共同的認(rèn)識(shí)跛璧。所以這個(gè)Node需要在所有Monitor上都申請(qǐng)一個(gè)Lease严里，在Lease期間，Monitor保證不會(huì)認(rèn)可提出它追城。同時(shí)一個(gè)Node需要從整個(gè)Monitor Set中獲取Lease刹碾，一旦一個(gè)Node無法在Set中獲取到所有的人的租約，這樣就會(huì)自己提出退出Membership座柱。

   在Ring上相鄰的X和Y兩個(gè)Node迷帜，一般都會(huì)互相為Monitor。這樣會(huì)在相互的狀態(tài)上認(rèn)知產(chǎn)生沖突色洞。例如X戏锹，Y可能相互認(rèn)為對(duì)方已經(jīng)離線，分別要求對(duì)方被踢出集群火诸。

2. Failure的決策

   為了達(dá)成分布式節(jié)點(diǎn)的一致性锦针，總而言之有兩種做法，一種是通過多數(shù)成員同意置蜀，另一種就是交給別人裁決伞插。SF這里采用了后一種方式。

   SF里面有一個(gè)特別的服務(wù)盾碗，Arbitrator用來裁決Failure的提議，所有成員節(jié)點(diǎn)可以通過自己的觀察進(jìn)行猜測舀瓢，產(chǎn)生提議廷雅，最終在Arbitrator進(jìn)行決定。

   Arbitrator本身也是一組互相獨(dú)立運(yùn)行的集群京髓，通過quorum方式運(yùn)作航缀，基本上等同于一個(gè)RSM。說白了就是要序列化對(duì)于集群狀態(tài)的修改堰怨，例如假設(shè)A和B都認(rèn)為對(duì)方掛了發(fā)出踢出對(duì)方的請(qǐng)求芥玉，那么Arbitrator最大的作用，就是確定那個(gè)提議為先而生效备图。

Route

SF的路由表類似Chord灿巧，已指數(shù)為步長記錄相鄰的節(jié)點(diǎn)，例如Node K記錄 距離為 K + 1, K + 2, K + 4 ...的節(jié)點(diǎn)揽涮，不過SF的Route是對(duì)稱的抠藕，順時(shí)針方向和逆時(shí)針方向都記錄。

所以一個(gè)Key的尋址蒋困，首先是查找它在Ring上的對(duì)應(yīng)的值K盾似，然后通過遞歸方式，每個(gè)節(jié)點(diǎn)查詢自己所知的節(jié)點(diǎn)里面離K值最近的節(jié)點(diǎn)雪标，直到查找到最終歸屬的節(jié)點(diǎn)零院。

所以在路由這方面溉跃，分為兩部分狀態(tài)需要維護(hù)

1. Node在Ring上的位置

   這里的一致性分為兩部分：

   • 鄰居的狀態(tài)，是強(qiáng)一致的
   • 其它節(jié)點(diǎn)告抄，通過類似gossip的方式獲取變化撰茎，最終一致性

2. 一個(gè)Key屬于哪個(gè)Node

   SF中每個(gè)Node會(huì)持有一個(gè)Token，對(duì)于一個(gè)Ring上的一個(gè)值玄妈，同時(shí)保證

   • Safetyness: 一個(gè)時(shí)間點(diǎn)乾吻，對(duì)于一個(gè)Key最多一個(gè)Token持有者
   • Liveness: 最終總會(huì)有Token接管這個(gè)Key

Leader Election

對(duì)于一個(gè)Key，Leader Election是隱性的拟蜻，就是持有這個(gè)Key所屬Token的那個(gè)節(jié)點(diǎn)绎签。這個(gè)極大的簡化了Leader變化的處理，減少了Leader變化帶來的可用性丟失的時(shí)間酝锅。

RELIABILITY SUBSYSTEM

在Federation對(duì)于系統(tǒng)有了強(qiáng)一致的共識(shí)之后诡必，之上的子系統(tǒng)主要解決放置，Replication搔扁，HA等

問題

1. 和別的平臺(tái)有啥不同爸舒，優(yōu)點(diǎn)在哪？

   SF最大的設(shè)計(jì)目標(biāo)感覺在于兩個(gè)點(diǎn)稿蹲；第一扭勉，支持大規(guī)模的集群；第二苛聘，支持Stateful的Service

   針對(duì)集群規(guī)模的問題涂炎，傳統(tǒng)由一個(gè)Master負(fù)責(zé)整個(gè)集群管理，這樣可以保證狀態(tài)的強(qiáng)一致设哗。最大的問題在于這個(gè)Master成為整個(gè)系統(tǒng)的瓶頸唱捣，另外也會(huì)帶來因?yàn)槠渚W(wǎng)絡(luò)的波動(dòng)導(dǎo)致了大量節(jié)點(diǎn)被踢出的問題。另外一個(gè)類似Serf這種网梢，通過gossip方式來最終一致震缭，問題是存在一個(gè)時(shí)期的不一致，需要一個(gè)anti-entrophy的過程战虏。SF使用了一個(gè)較小規(guī)模的Membership的Group來維護(hù)強(qiáng)一致的狀態(tài)拣宰，結(jié)合數(shù)據(jù)Token的方式，從而使得整個(gè)整個(gè)系統(tǒng)狀態(tài)是強(qiáng)一致的（這個(gè)挺有意思烦感，基本結(jié)合了Eventual Consistency的Long Distance的路由徐裸，加上Strong Consistency的Short Distance的路由，從而使一小部分的強(qiáng)一致的狀態(tài)啸盏，變成了整個(gè)Ring的強(qiáng)一致狀態(tài)）重贺。另外SF使用的Full Membership和O(log(n))的路由結(jié)合的方式，也保證了集群的擴(kuò)展性。

   針對(duì)第二個(gè)問題气笙，首先對(duì)比一般只支持stateless次企，帶來的額外挑戰(zhàn)在于為了HA，一個(gè)Service需要一個(gè)Replica Set, 那么對(duì)于寫請(qǐng)求潜圃，需要路由到相應(yīng)的Primary的Service上缸棵，另外在Fail Over的過程里面，平臺(tái)也需要知道有哪些Secondary的replica谭期，可以重新選擇一個(gè)作為Primary堵第。這個(gè)問題感覺最大的挑戰(zhàn)就是在于Failover等主從swap時(shí)候路由更新的問題，SF這里通過路由的方式解決隧出，一個(gè)Key始終通過持有負(fù)責(zé)它的Token的Node進(jìn)行路由踏志，也是極大的減少了在這個(gè)過程里面，系統(tǒng)達(dá)到穩(wěn)定狀態(tài)需要廣播的路由胀瞪。

2. 路由的單位應(yīng)該是Service针余，但是SF中Service是通過指定Key的方式進(jìn)行放置的，這個(gè)如何實(shí)現(xiàn)呢凄诞？

   大概是通過PLB給Service分配了Key吧圆雁，因?yàn)闊o法通過簡單Hash解決負(fù)載均衡的問題，另外放置一個(gè)service也有諸多限制帆谍。

   所以這個(gè)路由應(yīng)該要向FM獲取Service的Key

3. 支持stateful的service有意義么

   哪些application是無狀態(tài)的呢伪朽，無非是把復(fù)雜度往哪推罷了。汛蝙。

   有時(shí)候使用有狀態(tài)服務(wù)可能比依賴外部DB烈涮，或者QUEUE更簡單的情況是復(fù)雜的限制情況，不太好用現(xiàn)有的數(shù)據(jù)組件處理（例如write skew）患雇，與其依賴復(fù)雜的分布式鎖，還不如直接做成有狀態(tài)的簡單一點(diǎn)宇挫。苛吱。。