覓食寶典
作為服務(wù)注冊(cè)中心，Eureka與Zookeeper區(qū)別
著名的CAP理論指出，一個(gè)分布式系統(tǒng)不可能同時(shí)滿足C(一致性)、A(可用性)和P(分區(qū)容錯(cuò)性)。由于分區(qū)容錯(cuò)性在是分布式系統(tǒng)中必須要保證的，因此我們只能在A和C之間進(jìn)行權(quán)衡。在此Zookeeper保證的是CP, 而Eureka則是AP。
RDBMS==>（MySql,Oracle,SqlServer等關(guān)系型數(shù)據(jù)庫(kù)）遵循的原則是：ACID原則（A：原子性。C：一致性。I：獨(dú)立性。D：持久性。）。
NoSql==>? ? （redis,Mogodb等非關(guān)系型數(shù)據(jù)庫(kù)）遵循的原則是：CAP原則（C：強(qiáng)一致性。A:可用性。P：分區(qū)容錯(cuò)性）。
在分布式領(lǐng)域有一個(gè)很著名的CAP定理：C：數(shù)據(jù)一致性。A：服務(wù)可用性。P：分區(qū)容錯(cuò)性（服務(wù)對(duì)網(wǎng)絡(luò)分區(qū)故障的容錯(cuò)性）。
Zookeeper保證CP
當(dāng)向注冊(cè)中心查詢服務(wù)列表時(shí)，我們可以容忍注冊(cè)中心返回的是幾分鐘以前的注冊(cè)信息，但不能接受服務(wù)直接down掉不可用。也就是說(shuō)，服務(wù)注冊(cè)功能對(duì)可用性的要求要高于一致性。但是zk會(huì)出現(xiàn)這樣一種情況，當(dāng)master節(jié)點(diǎn)因?yàn)榫W(wǎng)絡(luò)故障與其他節(jié)點(diǎn)失去聯(lián)系時(shí)，剩余節(jié)點(diǎn)會(huì)重新進(jìn)行l(wèi)eader選舉。問(wèn)題在于，選舉leader的時(shí)間太長(zhǎng)，30 ~ 120s, 且選舉期間整個(gè)zk集群都是不可用的，這就導(dǎo)致在選舉期間注冊(cè)服務(wù)癱瘓。在云部署的環(huán)境下，因網(wǎng)絡(luò)問(wèn)題使得zk集群失去master節(jié)點(diǎn)是較大概率會(huì)發(fā)生的事，雖然服務(wù)能夠最終恢復(fù)，但是漫長(zhǎng)的選舉時(shí)間導(dǎo)致的注冊(cè)長(zhǎng)期不可用是不能容忍的。
zookeeper原理
ZooKeeper是以Fast Paxos算法為基礎(chǔ)的，Paxos 算法存在活鎖的問(wèn)題，即當(dāng)有多個(gè)proposer交錯(cuò)提交時(shí)，有可能互相排斥導(dǎo)致沒(méi)有一個(gè)proposer能提交成功，而Fast Paxos作了一些優(yōu)化，通過(guò)選舉產(chǎn)生一個(gè)leader (領(lǐng)導(dǎo)者)，只有l(wèi)eader才能提交proposer，具體算法可見Fast Paxos。因此，要想弄懂ZooKeeper首先得對(duì)Fast Paxos有所了解。? ZooKeeper的基本運(yùn)轉(zhuǎn)流程： 1、選舉Leader。 2、同步數(shù)據(jù)。 3、選舉Leader過(guò)程中算法有很多，但要達(dá)到的選舉標(biāo)準(zhǔn)是一致的。 4、Leader要具有最高的執(zhí)行ID，類似root權(quán)限。 5、集群中大多數(shù)的機(jī)器得到響應(yīng)并接受選出的Leader。 其他 HBase和ZooKeeper HBase內(nèi)置有ZooKeeper，也可以使用外部ZooKeeper。 讓HBase使用一個(gè)已有的不被HBase托管的Zookeep集群，需要設(shè)置 conf/hbase env sh文件中的HBASE_MANAGES_ZK 屬性為 false ... # Tell HBase whether it should manage it's own instance of Zookeeper or not. export HBASE_MANAGES_ZK=false 接下來(lái)，指明Zookeeper的host和端口?？梢栽?hbase-site.xml中設(shè)置, 也可以在HBase的CLASSPATH下面加一個(gè)zoo.cfg配置文件。HBase 會(huì)優(yōu)先加載 zoo.cfg 里面的配置，把hbase-site.xml里面的覆蓋掉. 當(dāng)HBase托管ZooKeeper的時(shí)候，Zookeeper集群的啟動(dòng)是HBase啟動(dòng)腳本的一部分。但你需要自己去運(yùn)行。你可以這樣做 ${HBASE_HOME}/bin/hbase-daemons sh {start,stop} zookeeper 你可以用這條命令啟動(dòng)ZooKeeper而不啟動(dòng)HBase. HBASE_MANAGES_ZK 的值是 false， 如果你想在HBase重啟的時(shí)候不重啟ZooKeeper,你可以這樣做 對(duì)于獨(dú)立Zoopkeeper的問(wèn)題，你可以在 Zookeeper啟動(dòng)得到幫助 列如： zookeeper也可以作為注冊(cè)中心，用于服務(wù)治理（zookeeper還有其他用途，例如：分布式事務(wù)鎖等） ? 每啟動(dòng)一個(gè)微服務(wù)，就會(huì)去zk中注冊(cè)一個(gè)臨時(shí)子節(jié)點(diǎn)， 例如：5臺(tái)訂單服務(wù)，4臺(tái)商品服務(wù) （5臺(tái)訂單服務(wù)在zk中的訂單目錄下創(chuàng)建的5個(gè)臨時(shí)節(jié)點(diǎn)） （4臺(tái)商品服務(wù)在zk中的商品目錄下創(chuàng)建的4個(gè)臨時(shí)接點(diǎn)） 每當(dāng)有一個(gè)服務(wù)down機(jī)，由于是臨時(shí)接點(diǎn)，此節(jié)點(diǎn)會(huì)立即被刪除，并通知訂閱該服務(wù)的微服務(wù)更新服務(wù)列表 （zk上有watch，每當(dāng)有節(jié)點(diǎn)更新，都會(huì)通知訂閱該服務(wù)的微服務(wù)更新服務(wù)列表） 每當(dāng)有一個(gè)新的微服務(wù)注冊(cè)進(jìn)來(lái)，就會(huì)在對(duì)應(yīng)的目錄下創(chuàng)建臨時(shí)子節(jié)點(diǎn)，并通知訂閱該服務(wù)的微服務(wù)更新服務(wù)列表 （zk上有watch，每當(dāng)有節(jié)點(diǎn)更新，都會(huì)通知訂閱該服務(wù)的微服務(wù)更新服務(wù)列表） 每個(gè)微服務(wù)30s向zk獲取新的服務(wù)列表 |
Eureka保證AP
Eureka看明白了這一點(diǎn)，因此在設(shè)計(jì)時(shí)就優(yōu)先保證可用性。Eureka各個(gè)節(jié)點(diǎn)都是平等的，幾個(gè)節(jié)點(diǎn)掛掉不會(huì)影響正常節(jié)點(diǎn)的工作，剩余的節(jié)點(diǎn)依然可以提供注冊(cè)和查詢服務(wù)。而Eureka的客戶端在向某個(gè)Eureka注冊(cè)或時(shí)如果發(fā)現(xiàn)連接失敗，則會(huì)自動(dòng)切換至其它節(jié)點(diǎn)，只要有一臺(tái)Eureka還在，就能保證注冊(cè)服務(wù)可用(保證可用性)，只不過(guò)查到的信息可能不是最新的(不保證強(qiáng)一致性)。除此之外，Eureka還有一種自我保護(hù)機(jī)制，如果在15分鐘內(nèi)超過(guò)85%的節(jié)點(diǎn)都沒(méi)有正常的心跳，那么Eureka就認(rèn)為客戶端與注冊(cè)中心出現(xiàn)了網(wǎng)絡(luò)故障，此時(shí)會(huì)出現(xiàn)以下幾種情況：1. Eureka不再?gòu)淖?cè)列表中移除因?yàn)殚L(zhǎng)時(shí)間沒(méi)收到心跳而應(yīng)該過(guò)期的服務(wù) 2. Eureka仍然能夠接受新服務(wù)的注冊(cè)和查詢請(qǐng)求，但是不會(huì)被同步到其它節(jié)點(diǎn)上(即保證當(dāng)前節(jié)點(diǎn)依然可用) 3. 當(dāng)網(wǎng)絡(luò)穩(wěn)定時(shí)，當(dāng)前實(shí)例新的注冊(cè)信息會(huì)被同步到其它節(jié)點(diǎn)中
因此， Eureka可以很好的應(yīng)對(duì)因網(wǎng)絡(luò)故障導(dǎo)致部分節(jié)點(diǎn)失去聯(lián)系的情況，而不會(huì)像zookeeper那樣使整個(gè)注冊(cè)服務(wù)癱瘓。
eureka的核心角色
eureka server
存儲(chǔ)服務(wù)注冊(cè)列表
eureka client
eureka的客戶端
拉取server的注冊(cè)列表
周期性與server保持一個(gè)心跳機(jī)制（默認(rèn)周期30秒）
服務(wù)狀態(tài)
服務(wù)續(xù)約
eureka客戶端每隔30秒，發(fā)送一個(gè)心跳給eureka server，證明此服務(wù)是存活，進(jìn)行續(xù)約的操作行為
服務(wù)下線
當(dāng)application server應(yīng)用停止，向eureka server，發(fā)送cancel請(qǐng)求，server接受到此請(qǐng)求指令，就會(huì)從服務(wù)列表刪除此服務(wù)
服務(wù)剔除
eureka server啟動(dòng)后在后臺(tái)啟動(dòng)一個(gè)任務(wù)，此任務(wù)對(duì)在一定時(shí)間內(nèi)沒(méi)有續(xù)約的服務(wù)進(jìn)行剔除
保護(hù)模式
觸發(fā)了eureka server的自我保護(hù)機(jī)制
條件：Eureka Server 在運(yùn)行期間會(huì)去統(tǒng)計(jì)心跳失敗比例在 15 分鐘之內(nèi)是否低于 85%，如果低于 85%，Eureka Server 會(huì)將這些實(shí)例保護(hù)起來(lái)
哲學(xué)道理：寧可先保護(hù)此服務(wù)實(shí)例，都不會(huì)盲目的刪除此服務(wù)
eureka原理
| 每一個(gè)微服務(wù)中都有eureka client，用于服務(wù)的注冊(cè)于發(fā)現(xiàn) （服務(wù)的注冊(cè)：把自己注冊(cè)到eureka server） （服務(wù)的發(fā)現(xiàn)：從eureka server獲取自己需要的服務(wù)列表） 每一個(gè)微服務(wù)啟動(dòng)的時(shí)候，都需要去eureka server注冊(cè) 當(dāng)A服務(wù)需要調(diào)用B服務(wù)時(shí)，需要從eureka服務(wù)端獲取B服務(wù)的服務(wù)列表，然后把列表緩存到本地，然后根據(jù)ribbon的客戶端負(fù)載均衡規(guī)則，從服務(wù)列表中取到一個(gè)B服務(wù)，然后去調(diào)用此B服務(wù) 當(dāng)A服務(wù)下次再此調(diào)用B服務(wù)時(shí)，如果發(fā)現(xiàn)本地已經(jīng)存儲(chǔ)了B的服務(wù)列表，就不需要再?gòu)膃ureka服務(wù)端獲取B服務(wù)列表，直接根據(jù)ribbon的客戶端負(fù)載均衡規(guī)則，從服務(wù)列表中取到一個(gè)B服務(wù)，然后去調(diào)用B服務(wù) 微服務(wù)，默認(rèn)每30秒，就會(huì)從eureka服務(wù)端獲取一次最新的服務(wù)列表 如果某臺(tái)微服務(wù)down機(jī)，或者添加了幾臺(tái)機(jī)器， 此時(shí)eureka server會(huì)通知訂閱他的客戶端，并讓客戶端更新服務(wù)列表， 而且還會(huì)通知其他eureka server更新此信息 心跳檢測(cè)，微服務(wù)每30秒向eureka server發(fā)送心跳， eureka server若90s之內(nèi)都沒(méi)有收到某個(gè)客戶端的心跳，則認(rèn)為此服務(wù)出了問(wèn)題， 會(huì)從注冊(cè)的服務(wù)列表中將其刪除，并通知訂閱它的客戶端更新服務(wù)列表， 而且還會(huì)通知其他eureka server更新此信息 eureka server保護(hù)機(jī)制，通過(guò)打卡開關(guān)，可以讓eureka server處于保護(hù)狀態(tài)，主要是用于某eureka server由于網(wǎng)絡(luò)或其他原因，導(dǎo)致接收不到其他微服務(wù)的心跳，此時(shí)不能盲目的將其他微服務(wù)從服務(wù)列表中刪除。具體規(guī)則：如果一段時(shí)間內(nèi)，85%的服務(wù)都沒(méi)有發(fā)送心跳，則此server進(jìn)入保護(hù)狀態(tài)，此狀態(tài)下，可以正常接受注冊(cè)，可以正常提供查詢服務(wù)，但是不與其他server同步信息，也不會(huì)通知訂閱它的客戶端，這樣就不會(huì)誤殺其他微服務(wù) |