20172017人穩(wěn)|Java9正式發(fā)布，新特性解讀正式開(kāi)源其RPC框架文章|Kafka數(shù)據(jù)可靠性深度解MySQL到底能不能放到Docker里跑觀點(diǎn)|AIOpsAI專區(qū)|AIgRPC客戶端創(chuàng)建和調(diào)用原理解2卷首語(yǔ)論AI時(shí)代的融合型人才作者騰訊Andymhuang（在剛剛過(guò)去的幾個(gè)月，發(fā)生了一些有趣的事情。IEEESpectrumPython受歡迎的語(yǔ)言，NIPS2017門票創(chuàng)造了最快售罄記錄，Apple布會(huì)推出FaceID，GTCChina2017?；鸨邪殡S著AI時(shí)代的到來(lái)，AI人才，尤其是算法工和數(shù)據(jù)科學(xué)家，受到前所未有的高度關(guān)注（也產(chǎn)生了一定的）。但是這不代表擅長(zhǎng)工來(lái)實(shí)現(xiàn)，否則就是鏡花水月。在看來(lái)，優(yōu)秀架構(gòu)師的重要性一點(diǎn)也沒(méi)降低，但是他們也需要懂一點(diǎn)AI了。其實(shí)仔細(xì)研究的話，很容易會(huì)發(fā)現(xiàn)，優(yōu)秀的工程型人才，熟悉計(jì)算機(jī)系統(tǒng)和理論，有1-2門拿手的言，能寫(xiě)出優(yōu)雅而高效的代碼，設(shè)計(jì)高可用的架構(gòu)。講究快、優(yōu)秀的算法型人才，精通各種數(shù)學(xué)公式和推導(dǎo)，了解各種優(yōu)化Java9正式發(fā)布，新作作在歷經(jīng)多次跳票之后，Java9終于在千呼萬(wàn)喚中正式發(fā)布。從這個(gè)版本開(kāi)始，Java將每半年發(fā)布一個(gè)版本。作為霸占編程語(yǔ)言榜鰲頭多年的老牌語(yǔ)言，Java9中有哪些不得不說(shuō)的新特性？Java語(yǔ)言的未針對(duì)Java9特性的介紹已經(jīng)非常多了，我這里不想再做一個(gè)百科首先，談到Java9家往往第一個(gè)想到的就是Jigsaw項(xiàng)目，這是大家知道，Java經(jīng)發(fā)展超過(guò)20年（95年最初發(fā)布），Java相關(guān)生態(tài)在不斷豐富的同時(shí)也越來(lái)越出一些問(wèn)題，比如Java運(yùn)行環(huán)同版本的類庫(kù)交叉依賴導(dǎo)致Jar等讓人頭疼的問(wèn)題，這些都阻礙了Java開(kāi)發(fā)和運(yùn)行效率的提升。但是由于兼容性等各方面的掣肘，對(duì)Java行大刀闊斧的革新越來(lái)越，Jigsaw從Java7階段就開(kāi)始籌備，Java8階段進(jìn)行了大量工作，終于在Java9里，有種千呼萬(wàn)喚始出來(lái)的意味。Jigsaw目的目標(biāo)是改進(jìn)JavaSE平臺(tái)，使其可以適應(yīng)不同大小的計(jì)算設(shè)備；改進(jìn)其安全性，可性，提高性能；簡(jiǎn)化各種類庫(kù)和大型應(yīng)這個(gè)項(xiàng)目的工作量和難度大大超出了初始規(guī)劃。JSR376Java平臺(tái)模塊化系統(tǒng)（JPMS,JavaPlatformModuleSystem）作為Jigsaw項(xiàng)目的,其主體部分被分解成6個(gè)JEP(JDKEnhancementProposals)200:TheModular201:ModularSource220:ModularRun-Time260:EncapsulateMostInternal261:Module282:jlink:TheJava可以看到這是一個(gè)龐大的系統(tǒng)工程，Java的方方面面，包括JDK譯工具，運(yùn)行時(shí)，Java共API私有代碼等等，完全是一個(gè)整體性的隨著Java平臺(tái)模塊化系統(tǒng)的，開(kāi)發(fā)無(wú)需再為不斷膨脹的Java臺(tái)苦惱，例如，您可以jlink工具，根據(jù)需要定制運(yùn)行時(shí)環(huán)從開(kāi)發(fā)實(shí)踐的角度，Java語(yǔ)言層面提供對(duì)模塊的支持，可以鼓勵(lì)（當(dāng)然在某種程度上也可以看作強(qiáng)制）更加規(guī)范的開(kāi)發(fā)實(shí)踐，利用業(yè)廣泛的場(chǎng)景達(dá)到或接近本地語(yǔ)言的性能。但是，直到今天，談到Java，很多C/C++開(kāi)發(fā)者還是會(huì)不屑地評(píng)價(jià)為啟動(dòng)慢，吃內(nèi)存。簡(jiǎn)單說(shuō)，這主要是因?yàn)镴ava譯產(chǎn)生的類文件是Java擬機(jī)可以理解的二進(jìn)制代碼，而不是真正的可執(zhí)行的本地代碼Java機(jī)但是實(shí)際應(yīng)用可能非常龐大，大型Java用的預(yù)熱往往非常耗時(shí)，而且非熱點(diǎn)代碼可能根本沒(méi)有機(jī)會(huì)被JIT編譯。在JDK9中，AOT（JEP295:Ahead-of-TimeCompilation）作為實(shí)驗(yàn)特性被引入進(jìn)來(lái)，開(kāi)發(fā)者可以利用新的jaotc工具將重點(diǎn)代碼轉(zhuǎn)換另外JVMCI（JEP243:Java-LevelJVMCompilerInterface）等引起了廣泛關(guān)注。目前GraalCoreAPI已經(jīng)被集成進(jìn)入Java9，雖然還只是初始一小步，但是完全用Java言來(lái)實(shí)現(xiàn)的可靠的、高性能的動(dòng)態(tài)編譯器，似乎不再是遙不可及，這是Java虛擬機(jī)開(kāi)發(fā)工的。與此同時(shí)，隨著Truffle框架和SubstrateVM的發(fā)展，已經(jīng)讓個(gè)別信心滿滿的工高呼“OneVMtoRuleThemAll!”，也許就在不遠(yuǎn)的將來(lái)Ploygot以一種另類的方式成為現(xiàn)實(shí)。談?wù)凧ava的未前面簡(jiǎn)短地談了談Java9中的一些令人激動(dòng)的特性，Java9在取了那些呢？非常突出的一點(diǎn)就是，由于Jigsaw目的延期，導(dǎo)致Java9的發(fā)布一再推遲，這帶來(lái)了很多影響。大批特性已經(jīng)完成多時(shí)，卻無(wú)法及時(shí)被存在的問(wèn)題或改進(jìn)。這不禁讓人Java傳統(tǒng)的研發(fā)模式的局限性。針對(duì)這些情況，Java席架構(gòu)師MarkReinhold經(jīng)發(fā)出倡議，建議從傳統(tǒng)的以特性驅(qū)動(dòng)的發(fā)布周期，轉(zhuǎn)變?yōu)橐詴r(shí)間驅(qū)動(dòng)的（6個(gè)月為周期）發(fā)布模式，并逐步的將OracleJDK原有商業(yè)特性進(jìn)行開(kāi)源，JavaFlightRecorder等級(jí)工具和特性，一定會(huì)大受開(kāi)發(fā)者的歡迎。針對(duì)企業(yè)客戶的需求，Oracle將以三年為周期發(fā)布長(zhǎng)期支持版本（longterm第二，隨著云計(jì)算和AI技術(shù)浪潮，當(dāng)前的計(jì)算模式和場(chǎng)景正在發(fā)生翻天覆地的變化，不僅對(duì)Java的發(fā)展速度提出了更高要求，也深刻影響著Java術(shù)的發(fā)展方向。傳統(tǒng)的大型企業(yè)或互聯(lián)網(wǎng)應(yīng)用，正在被云端，容器化應(yīng)用、模塊化的微服務(wù)甚至是函數(shù)（FaaS，F(xiàn)unction-as-a-Java需要在新的計(jì)算場(chǎng)景下，改進(jìn)開(kāi)發(fā)效率。這話說(shuō)的有點(diǎn)籠統(tǒng)，我談一些自己的體會(huì)，Java代碼雖然進(jìn)行了一些類型推斷等改進(jìn)，更易用的集合API等，但仍然給開(kāi)發(fā)者留下了過(guò)于刻板、形式主義的印象，這是一個(gè)長(zhǎng)期的改進(jìn)方向，例如，JEP286:Local-VariableTypeInference；持續(xù)改進(jìn)并發(fā)計(jì)算框架，Java的并發(fā)特性非常強(qiáng)大和系統(tǒng)，但某種程度上過(guò)于復(fù)雜，在今年的JVMLS上，阿里巴巴AJDK組介紹了利用協(xié)程改進(jìn)并發(fā)的實(shí)踐，這是一個(gè)令人眼前一亮的創(chuàng)新；Java非常需要更加友好的本地代碼支持，相關(guān)的特性有很多好的想法和嘗試，比如Panama項(xiàng)目；ValueTypes和改進(jìn)的泛型，有可以參考Valhalla最后，進(jìn)一步改進(jìn)啟動(dòng)和運(yùn)行性能、優(yōu)化計(jì)算資源使用。目前Java庫(kù)和虛擬機(jī)特性都是針對(duì)長(zhǎng)時(shí)間、大數(shù)據(jù)量、高并發(fā)等注的FaaS用，短時(shí)間、無(wú)狀態(tài)的函數(shù)正在成為常見(jiàn)的計(jì)算單元。那么在這種場(chǎng)景下，Java必須進(jìn)行相應(yīng)的改進(jìn)和創(chuàng)新，才能保持和強(qiáng)化目前在開(kāi)發(fā)領(lǐng)域的競(jìng)爭(zhēng)力。比如，提高Java運(yùn)行時(shí)啟動(dòng)速度，尤其是在容器環(huán)境的初始化表現(xiàn)；保證CPU計(jì)算資源調(diào)度能力能夠適應(yīng)容器環(huán)境的新情況，最直接的Java臺(tái)需要支持基于cgroup技術(shù)的資源管理；針對(duì)新場(chǎng)景下的GC化；如何提高數(shù)據(jù)密度和計(jì)算效率等等。改進(jìn)都是依賴于相關(guān)語(yǔ)言基礎(chǔ)技術(shù)的進(jìn)步和突破，Java的進(jìn)步需要持之最后，歡迎大家能夠參與到OpenJDK區(qū)，Java大家的，向OpenJDK提供建議、意見(jiàn)或者直接提交自己的改進(jìn)，在社區(qū)中聽(tīng)見(jiàn)越來(lái)越多的來(lái)自中國(guó)是非常令人高興的事情，讓攜手促進(jìn)Java正式開(kāi)源其RPC框架作框架brpc。brpc是一個(gè)基于protobuf接口的RPC框架，在稱為從目前的性能測(cè)試數(shù)據(jù)來(lái)看，brpc的性能領(lǐng)跑于其他同類RPC產(chǎn)品。brpc開(kāi)發(fā)2014年，主要使用的語(yǔ)言是C++和Java，是使用最為廣泛的RPC框架，它經(jīng)受了高并發(fā)高負(fù)載的生產(chǎn)環(huán)境驗(yàn)證，并支撐了大約75萬(wàn)個(gè)同時(shí)的實(shí)例。據(jù)InfoQ了解，曾有多款RPC框架2014年時(shí)還開(kāi)源過(guò)另外一款RPC框架sofa-pbrpc。那brpc是在什么樣的背景下誕生的？它有什么樣的優(yōu)勢(shì)？又為何要開(kāi)源？就這些問(wèn)題，InfoQ采訪了brpc。InfoQ：談?wù)刡rpc一些基本情況？什么時(shí)候開(kāi)始研發(fā)的？經(jīng)過(guò)了怎么樣的迭代和升級(jí)？目前在應(yīng)用情況如何？：brpc2014年創(chuàng)建，在稱為“baidu-rpc”。到目前為止，brpc一共進(jìn)行了3000次左右的改動(dòng)，現(xiàn)在仍在持續(xù)優(yōu)化中，內(nèi)的wiki上可以查詢到每次改動(dòng)的描述。brpc的主要語(yǔ)言是C+Java，對(duì)其他語(yǔ)言的支持主要是通過(guò)包裝C版本，比brpcPython版包含C++版的大部分功能。brpc目前支撐大約75萬(wàn)個(gè)同時(shí)的實(shí)例（不含client），超過(guò)500種服務(wù)（去年的統(tǒng)計(jì)，現(xiàn)在已不統(tǒng)計(jì)這類數(shù)據(jù)）。大量的檢索服務(wù)都使用了brpc。brpc第一次了內(nèi)分布式系InfoQ：為什么當(dāng)時(shí)要研發(fā)brpc：在實(shí)踐中，RPC作為最基礎(chǔ)的通信組件，當(dāng)時(shí)的百度已經(jīng)不領(lǐng)先了。我當(dāng)時(shí)的經(jīng)理曾是的工，非常重視基發(fā)、調(diào)試、都要考慮到，如果用戶效率真的被提高了，用戶會(huì)想著你的，靠吹噓或政令推廣的東西得不了人心。創(chuàng)建brpc的初衷是解決業(yè)務(wù)所的實(shí)際，同時(shí)也希望成為同學(xué)最喜愛(ài)的工具，哪怕離開(kāi)也會(huì)brpc。希望在提供了一個(gè)好用框架的同時(shí)，也展現(xiàn)了一種工作方法：注釋怎么寫(xiě)，日志怎么打，ChangeLog怎么寫(xiě)，版還不錯(cuò)，brpc的wiki可能是內(nèi)被點(diǎn)贊最多的內(nèi)容之一。InfoQ：與其他的一些開(kāi)源的RPC框架相比，brpc的優(yōu)勢(shì)是什么：brpc主打的是深度和易用性。一方面沒(méi)有精力像那樣攤大餅，什么都做。另一方面也注意到gRPC（包括更早的文檔非常牛，但實(shí)戰(zhàn)中可能就是另一回事了，為什么各個(gè)公司都要造自受RPC真正的痛點(diǎn)是可靠性、易用性和定位問(wèn)題的便利性。服有工具支持快速排查。而這些在目前開(kāi)源的RPC框架中做的并不好，它們大多很牛，但就是無(wú)法在自己組織中推廣開(kāi)來(lái)?；氐角懊婺侨c(diǎn)，brpc是如何做的呢？可靠性。這一方面是代碼質(zhì)量問(wèn)題，通過(guò)為brc團(tuán)隊(duì)設(shè)立很高的招聘門檻，以及在團(tuán)隊(duì)中深入的技術(shù)，確保了穩(wěn)固的代碼基礎(chǔ)。另一個(gè)問(wèn)題是長(zhǎng)尾問(wèn)題，這是設(shè)計(jì)問(wèn)題，bpc其實(shí)包含了很多模塊，其中的bhrad是一個(gè):N線程庫(kù)，就是為了更好地提高并發(fā)避免阻塞。bpc中的讀和寫(xiě)都是itfre的，這是最高程度的發(fā)。術(shù)細(xì)看。有，但一旦出問(wèn)題，則是用戶“配置錯(cuò)了”。而且這樣用戶還非的選項(xiàng)也很難受。brpc對(duì)于增加選項(xiàng)非常謹(jǐn)慎，框架能自己做判能用。認(rèn)為這對(duì)用戶體驗(yàn)來(lái)說(shuō)非常重要。定位問(wèn)題的便利性。這點(diǎn)其它開(kāi)源框架目前做的都不好，正常使用是可以的，但出問(wèn)題就麻煩了。這個(gè)問(wèn)題在其實(shí)也很嚴(yán)重，rc之前用戶排查問(wèn)題都要拉RPC同學(xué)一起排查，PC框架對(duì)用戶是個(gè)黑盒，用戶根本不知道里面發(fā)生了什么。按的經(jīng)srv卡頓，len超時(shí)之類的問(wèn)題，排查問(wèn)題是常態(tài)，人手必然不夠。時(shí)間長(zhǎng)了用戶就覺(jué)得你這個(gè)框架各種問(wèn)題，人還拽的不行很少回他們消息。brpc的解決辦法是給server內(nèi)加入各種HTTP接口的內(nèi)置服務(wù)，通過(guò)這些服務(wù)，用戶可以很快看到server的延時(shí)、錯(cuò)誤、連接、某個(gè)RPU熱點(diǎn)、內(nèi)存分配、鎖競(jìng)爭(zhēng)等信息，用戶還可以使用bvar來(lái)自定義各類統(tǒng)計(jì)信息，并在的運(yùn)維平臺(tái)NOAH上匯總。這樣大部分問(wèn)題用戶可以自助解決。其實(shí)去看也是看這些，只是InfoQ：作為公司的RPC框架，在服務(wù)治理方面有什么考慮還會(huì)通過(guò)localRPC工程框架和策略代碼。這么多年下來(lái)，服務(wù)周邊的系統(tǒng)也比較全面了：編譯是BCLOUD，發(fā)布是Agile，服務(wù)和發(fā)現(xiàn)BNS，認(rèn)證是Giano，和運(yùn)維是NOAH。在，brpc和這些系統(tǒng)InfoQ：之前還開(kāi)源過(guò)sofa-pbrpc，brpc與它的區(qū)別是什么：sofa-pbrpc也是開(kāi)發(fā)的一個(gè)比較早期的RPC框架，屬于點(diǎn):非常多的協(xié)議，基于Protobuf的，基于HTTP的，內(nèi)的nshead/mcpack，開(kāi)源的Redis/Memcached，甚至RTMP/FLV/HLS協(xié)議，aware（局部知）四種算法，用戶還能定制。多線程質(zhì)量更好。多線程編程是非常的，看起來(lái)簡(jiǎn)單的RC遍布多線程陷阱，比如處理超時(shí)的代碼可能在PC還沒(méi)發(fā)出去時(shí)就運(yùn)行了；發(fā)送函數(shù)還沒(méi)結(jié)束，處理回復(fù)的回調(diào)就被運(yùn)行了；一個(gè)回復(fù)還在被處理另一個(gè)回復(fù)回來(lái)了，諸如此類。另外，一個(gè)異步PC的回調(diào)里發(fā)起一個(gè)同步RC會(huì)發(fā)生什么，帶著鎖做同步RPC會(huì)發(fā)生什么。些問(wèn)不能sfpbp找到滿的答。如何讓用戶參與進(jìn)來(lái)定制他們感的指標(biāo)，為此設(shè)計(jì)了bvar，讓用戶能用比原子變量代價(jià)還小的方式地定制各種指標(biāo)，用戶能在瀏覽器上看到指標(biāo)的變化曲線，或在運(yùn)維平臺(tái)NOAH看到匯總的數(shù)據(jù)。brpc還加入了大量?jī)?nèi)置服務(wù)方便用戶調(diào)試程序，查看連接，修改gflags，追蹤RPC，分析CPU熱點(diǎn)，內(nèi)無(wú)需諱言，brpc在誕生之初和sofa-pbrpc在是有競(jìng)爭(zhēng)關(guān)系的，但就像其他地方一樣，這種競(jìng)爭(zhēng)帶來(lái)了。類似的，brpc和其他InfoQ：談?wù)刡rpc的整體架構(gòu)？以去看下開(kāi)源出來(lái)的文檔。brpc在架構(gòu)上強(qiáng)調(diào)“在不犧牲易用性的前提下增強(qiáng)可擴(kuò)展性”，比如brpc支持非常多的協(xié)議，在一個(gè)brpcserver同端口可以支持二十幾種協(xié)議，這對(duì)于服務(wù)的平滑遷移就非常好持也是在這個(gè)背景下做的，這兩個(gè)客戶端比Client好用多了，感興名字服務(wù)、負(fù)載均衡也都可以定制。但為了對(duì)用戶負(fù)責(zé)，也不勵(lì)“太”的定制，比如一點(diǎn)點(diǎn)需求的變化就要搞個(gè)新的，這時(shí)更需要想清楚本質(zhì)區(qū)別是什么。這個(gè)事情在內(nèi)的支持群里每天都在做是放的乙方，但也嚴(yán)厲”乙方。 的性能如何？這么高的性能是怎么做到的：性能是非?？粗械囊稽c(diǎn)，它和用戶體驗(yàn)也是緊密聯(lián)系的。好用但性能不行，或不好用但性能很牛，用戶會(huì)很難受，不希望用戶 地圖ELF學(xué)習(xí)框臺(tái)服和其他RPC框架（包含thrift、gRPC）的性能對(duì)比可以見(jiàn)這里開(kāi)源文檔中概括了性能上的設(shè)計(jì)，“RPCindepth”這一節(jié)下的文InfoQ：為什么要將brpc開(kāi)源？接下來(lái)在開(kāi)源項(xiàng)目的迭代方面有什么：因?yàn)轳R上還有不少依賴RPC的系統(tǒng)要開(kāi)源啊。RPC作為最以及使用brpc的bigflow，讓流式計(jì)算變得很順手。這些年對(duì)開(kāi)源的認(rèn)識(shí)也在不斷加深，開(kāi)源看似了的技術(shù)，但帶來(lái)的生態(tài)影響力更重要。從Apollo、PaddlePaddle開(kāi)始，真的開(kāi)始擁抱開(kāi)源了。brpc的開(kāi)源版和版很接近，只是去掉了對(duì)獨(dú)有的一些基礎(chǔ)設(shè)嘉賓介Kafka數(shù)據(jù)可靠性作作Kafka起初是由LinkedIn公司開(kāi)發(fā)的一個(gè)分布式的消息系統(tǒng)，后成為Apache的一部分，它使用Scala編寫(xiě)，以可水平擴(kuò)展和高吞吐率而被廣泛使用。目前越來(lái)越多的開(kāi)源分布式處理系統(tǒng)如Cloudera、ApacheStorm、Spark等都支持與Kafka集成。概Kafka與傳統(tǒng)消息系統(tǒng)相比，有以下不同它被設(shè)計(jì)為一個(gè)分布式系統(tǒng)，易于向外它同時(shí)為發(fā)布和訂閱提供高吞吐量它支持多訂閱者，當(dāng)失敗時(shí)能自動(dòng)平衡消費(fèi)者它將消息持久化到磁盤，因此可用于批量消費(fèi)，例如ETL以及實(shí)時(shí)應(yīng)Kafka憑借著自身的優(yōu)勢(shì)，越來(lái)越受到互聯(lián)網(wǎng)企業(yè)的青睞，唯品會(huì)也用Kafka作為其消息擎之Kafka作為一商業(yè)消息間件，消息可靠性的重要性可想而知。如何確保消息的精確傳輸？如何確保消息的準(zhǔn)確？如何確保消息的正確消費(fèi)？這些都是需要考慮的問(wèn)KafkaKafka對(duì)kakfa的機(jī)制、原、同理、可靠和持性保證等等過(guò)benark對(duì)Kafka靠Kafka體系架如上圖所示，一個(gè)典型的Kafka體系架構(gòu)包括若干Producer（可以是服務(wù)器日志，業(yè)務(wù)數(shù)據(jù)，頁(yè)面前端產(chǎn)生的pageview），若干broker（Kafka支持水平擴(kuò)展，一般broker數(shù)量越多，集群吞吐率越高）若干Consumer(Group)，以及一個(gè)Zookeeper集群。Kafka通過(guò)Zookeeper管理集群配置，leader，以及在consumergroup發(fā)生變化時(shí)進(jìn)行rebalance。Producer使用push(推)模式將消息發(fā)布到broker，Consumerpull(式broker訂閱并消費(fèi)消息。： 屬Topic&topic可以認(rèn)為一個(gè)一類消息，每個(gè)topic將被分成多個(gè)partition，每個(gè)partition在層面是appendlog文件。任何發(fā)布記一條消息。每條消息都被appendpartition，是順序?qū)懘疟P，因此效率非常高（經(jīng)驗(yàn)證，順序?qū)懘疟P效率比隨機(jī)寫(xiě)內(nèi)存還要高，這是每一條消息被發(fā)送到broker中，會(huì)根據(jù)partition規(guī)則選擇被到哪一個(gè)partition。如果partition規(guī)則設(shè)置的合理，所有消息可以均勻分布到不同的partition里，這樣就實(shí)現(xiàn)了水平擴(kuò)展。（如果一個(gè)topic對(duì)應(yīng)一個(gè)文件，那這個(gè)文件所在的機(jī)I/O將會(huì)成為這topic性能瓶頸，而partition解決了這個(gè)問(wèn)題在創(chuàng)建topic時(shí)可以在$KAFKA_HOME/config/perties中指定這個(gè)partition的數(shù)量（如下所示），當(dāng)然可以在topic創(chuàng)建partition的數(shù)量。#Thedefaultnumberoflogpartitionspertopic.Morepartitionsallowgreater#parallelismforconsumption,butthiswillalsoresultinmorefilesacross#thebrokers.在發(fā)送一條消息時(shí)，可以指定這個(gè)消息的key，producer根據(jù)這key和partition機(jī)制來(lái)判斷這個(gè)消息發(fā)送到哪個(gè)partition。partition機(jī)制可以通過(guò)指定producerpartition.class這一參數(shù)來(lái)指定，該class必須實(shí)現(xiàn)ducer.Partitioner接口。有關(guān)Topic與Partition的細(xì)節(jié)，可以參考下面的“Kafka文件高可靠性分進(jìn)而對(duì)其的有個(gè)微觀的認(rèn)知。之后通過(guò)Kafka原理和同步方式來(lái)闡述宏觀層面的概念。最后從ISR，HW，leader以及數(shù)據(jù)可靠性和持久性保證等等各個(gè)維度來(lái)豐富對(duì)Kafka相關(guān)知識(shí)點(diǎn)的認(rèn)知Kafka文件機(jī)Kafka中消息是topic進(jìn)行分類的，生產(chǎn)者通過(guò)topicKafkabroker發(fā)送消息，消費(fèi)者通過(guò)topic數(shù)據(jù)。然而topic在物理層面又能以partition為分組，一個(gè)topic可以分成若干個(gè)partition，那么topic以及partition又是怎么的呢？partition還可以segment一個(gè)partition物理上由多個(gè)segment那么這些segment又是什么呢？下面來(lái)一一揭曉。為了便于說(shuō)明問(wèn)題，假設(shè)這里只有一個(gè)Kafka集群，且這個(gè)集群只有Kafkabroker，即只有一臺(tái)物理機(jī)。在這Kafkabroker配置（$KAFKA_HOME/config/perties）log.dirs=/tmp/kafka-logs，以此來(lái)設(shè)置Kafka消息文件，與此同時(shí)創(chuàng)建一個(gè)topic：topic_vms_test，partition的數(shù)量為4（$KAFKA_HOME/bin/kafka-topics.sh--create--zookeeperlocalhost:2181--partitions--topictopic_vms_test--replication-factor4）。那么此時(shí)可/tmp/kafka-logs中可以看4個(gè)：drwxr-xr-x2rootroot4096Apr1016:10topic_vms_test-drwxr-xr-x2rootroot4096Apr1016:10topic_vms_test-drwxr-xr-x2rootroot4096Apr1016:10topic_vms_test-drwxr-xr-x2rootroot4096Apr1016:10topic_vms_test-在Kafka文件中，同一個(gè)topic下有多個(gè)不同的partition，每個(gè)partiton一partition則為：topic序序號(hào)，第一個(gè)序號(hào)從0始計(jì)，最大的序號(hào)為partition1，partition是實(shí)際物理上的概念，而topic是邏輯上的概念。上面提到partition還可以細(xì)分為segment，這個(gè)segment又是什么？如果就以partition為最小單位，可以想象當(dāng)Kafkaproducer不斷發(fā)送消息，必然會(huì)引起partition文件的無(wú)限擴(kuò)張，這樣對(duì)于消息文件的以及已經(jīng)被消費(fèi)的消息的清理帶來(lái)嚴(yán)重的影響，所以這里以segment單位partition分。每partition()相當(dāng)于一個(gè)巨型文件被平均分配到多個(gè)大小相等的segment(據(jù)文件中（每個(gè)segment文件中消息數(shù)量不一定相等）這種特性也方便oldsegment的刪除，即方便已被消費(fèi)的消息的清理，提高磁盤的利用率。每個(gè)partition只需要支持順序讀寫(xiě)就行，segment的文件生命周期由服務(wù)端分別表示為segment索引文件和數(shù)據(jù)文件。這兩個(gè)文件令規(guī)則為：上一segment件最后一條消息的offset小為64，20位數(shù)字字符長(zhǎng)度，沒(méi)有數(shù)字用0填充，如下：segmentsegment：如上圖，“.index”索引文件大量的元數(shù)據(jù)，“.log”數(shù)據(jù)文件大量的消息，索引文件中的元數(shù)據(jù)指應(yīng)數(shù)據(jù)文件中message的物理偏移地址。其中以“.index”索引文件中的元數(shù)據(jù)[3,348]為例，在“.log”數(shù)據(jù)文件表示第3個(gè)消息，即在全局partition中表示170410+3=170413個(gè)消息，該消息的物理偏移地址為348。partitionoffsetmessage圖為例，offset=170418的消息，首先查找segment文件，其中00000000000000000000.index00000000000000170410.index（起始偏移為170410+1=170411），而第三個(gè)文件為00000000000000239430.index（起始偏移為239430+1=239431），所以這個(gè)offset=170418就落到了第二個(gè)文件之中。其他后續(xù)文件可以依次類推，以其實(shí)偏移量命名并排列這些文件，然后根據(jù)二分查找法就可以快速定位到具體文件位置。其次根據(jù)00000000000000170410.index文件中的[8,1325]定位00000000000000170410.log的1325。要是offset=170418從00000000000000170410.log文件中的1325的位置進(jìn)行，那么怎么知道何時(shí)讀完本條消息，否則就讀到下一條消息的內(nèi)容了？這個(gè)就需要聯(lián)系到消息的物理結(jié)構(gòu)了，消息都具有固定的物理結(jié)構(gòu)，包括：offset（8Bytes）、消息體的大?。?Bytes）、crc32（4Bytes）、magic（1Byte）、attributes（1Byte）、keylength（4Bytes）、key（KBytes）、payload(NBytes)等等字段，可以確定一條消息的大小，即到哪里截止。3.2原理和同步方Kafkatopic的每個(gè)partition有一個(gè)預(yù)寫(xiě)式的日志文件，雖然partition可以繼續(xù)細(xì)分為若干個(gè)segment文件，但是對(duì)于上層應(yīng)用來(lái)說(shuō)可以將partition看成最小的單元（一個(gè)有多個(gè)segment文件拼接的這些消息被連續(xù)的追加到partition中上圖中有兩個(gè)新名詞：HW和LEO。這里先介紹下LEO，LogEndOffset的縮寫(xiě)，表示每個(gè)partitionlog最后一條Message的位置。HWHighWatermark的縮寫(xiě)，是指consumer能夠看到的partition的位置，言歸正傳，為了提高消息的可靠性，Kafka每個(gè)topic的partition有N個(gè)副（replicas其中N(大于等于1)是topic的因（replicafator）的個(gè)數(shù)。Kafka通過(guò)多副本機(jī)制實(shí)現(xiàn)故障自動(dòng)轉(zhuǎn)移，當(dāng)Kafka集群中一個(gè)broker失效情況下仍然保證服務(wù)可用。在Kafka中發(fā)生時(shí)確保partition的日志能寫(xiě)到其他節(jié)點(diǎn)上，N個(gè)replicas中，其中一個(gè)replicaleader，其他都為follower,leaderpartition的所有讀寫(xiě)請(qǐng)求，與此同時(shí)，follower會(huì)定期地去leader上的數(shù)如下圖所示，Kafka集群4broker,topic3且因子即副本個(gè)數(shù)也為Kafka提供了數(shù)據(jù)算法保證，如果leader發(fā)生故障或掛掉，一個(gè)新leader被并被接受客戶端的消息成功寫(xiě)入。Kafka確保從同步副本列表中一個(gè)副本為leader，或者說(shuō)follower追趕leader數(shù)據(jù)。leader負(fù)責(zé)和ISR(In-SyncReplicas的縮寫(xiě)，表示副本同步隊(duì)之后才被成功到所有的同步副本。消息延遲受最慢的followerleader會(huì)把它ISR刪除。上節(jié)涉及到ISR(In-SyncReplicas)，這個(gè)是指副本同步隊(duì)列。副本數(shù)對(duì)Kafka的吞吐率是有一定的影響，但極大的增強(qiáng)了可用性。默認(rèn)情況下Kafkareplica數(shù)量為1，即每個(gè)partition都有一個(gè)唯一的leader，為了確保消息的可靠性，通常應(yīng)用中broker的參數(shù)offsets.topic.replication.factor指定)大小設(shè)置為大于1，比3。所有的副本（replicas）統(tǒng)稱為AssignedReplicas，即AR。ISR是AR中的一個(gè)子集，由leaderISR列表，follower從leader同步數(shù)據(jù)有一些延遲（包括延遲時(shí)間replica.lag.time.max.ms和延遲條數(shù)replica.lag.max.messages兩個(gè)維度,當(dāng)前的版本0.10.x中只支持replica.lag.time.max.ms這個(gè)維度），任意一個(gè)超過(guò)閾值都follower除ISR,OSR（Outof-SyncReplicas）列表，新加入的follower也會(huì)先存放在OSR中。AR=ISR+OSR。Kafka0.10.x后移replica.lag.max.messages數(shù)，只保留了replica.lag.time.max.msISR中副本管理的參數(shù)。為什么這樣做呢？replica.lag.max.messages表示當(dāng)前某個(gè)副本leaeder的消息數(shù)量超過(guò)了這個(gè)參數(shù)的值，那么leader就會(huì)followerISR中刪除。假設(shè)設(shè)replica.lag.max.messages=4，那producer次傳broker的消息數(shù)量都小于4條時(shí)，因?yàn)樵趌eader接受到producer發(fā)送的消息之后而follower副本開(kāi)始拉取這些消息之前followerleader的消息數(shù)不會(huì)4條消息，故此沒(méi)followerISR，所以這時(shí)候replica.lag.max.message的設(shè)置似乎是合理的。但是producer發(fā)起瞬時(shí)流量，producer一次發(fā)送的消息超4就是超replica.lag.max.messagesfollower會(huì)被認(rèn)為是與leader副本不同步了，從而被踢出了ISR。但實(shí)際上這follower都是存活狀態(tài)的且沒(méi)有性能問(wèn)題。那么在之后追上leader,并被重新加入了ISR。于是就會(huì)出現(xiàn)它們不斷地剔出ISR然后重新回歸ISR，這無(wú)疑增加了無(wú)謂的性能損耗。而且這個(gè)參數(shù)是broker全局的。設(shè)置太大了，影響真正“”follower的移除；設(shè)置的太小了，導(dǎo)致follower的頻繁進(jìn)出。無(wú)法給定一個(gè)合適的replica.lag.max.messages的值，故此，新版本的Kafka移除了這個(gè)參數(shù)。上面一節(jié)還涉及到一個(gè)概念，即HW。HW俗稱高水位，HighWatermark的縮寫(xiě)，取一個(gè)partition對(duì)應(yīng)的ISR中最小LEOHW，consumer最多只能消費(fèi)到HW所在的位置。另外每個(gè)replica都有HW,leaderfollower各自負(fù)責(zé)更新自己的HW的狀態(tài)。對(duì)leader新寫(xiě)入的消息，consumer不能立刻消費(fèi)，leader會(huì)等待該消息被所有ISRreplicas同步后更新HW，此時(shí)消息才能被consumer消費(fèi)。這樣就保證了如果leader所在的broker失效，該消息仍然可以從新的leader中獲取。對(duì)于來(lái)自broKer的請(qǐng)求，沒(méi)有HW的限制。下圖詳細(xì)的說(shuō)明了當(dāng)producer生產(chǎn)消息至broker，ISR由此可見(jiàn)，Kafka的機(jī)制既不是完全的同步，也不是單純的異步。事實(shí)上，同步要求所有能工作的follower都完，這條消息才會(huì)被commit，這種方式極大的影響了吞吐率。而異步方式下，follower異步的從leader數(shù)據(jù)，數(shù)據(jù)只要被leader寫(xiě)入log就被認(rèn)為已經(jīng)commit，這種情況下如果follower都還沒(méi)有完，于leader時(shí)，突然leader宕機(jī)，則會(huì)丟失數(shù)據(jù)。而Kafka的這種使ISR的方式則很好的均衡了確保數(shù)據(jù)不丟失以及吞吐率。Kafka的ISR的管理最終都會(huì)反饋到Zookeeper節(jié)點(diǎn)上。具置為/brokers/topics/[topic]/partitions/[partition]/state。目前有兩個(gè)地方會(huì)對(duì)這個(gè)Zookeeper的節(jié)點(diǎn)進(jìn)行：Controller來(lái)：Kafka集群中的其中一個(gè)Broker會(huì)被為Controller，主要負(fù)責(zé)Partition管理和副本狀態(tài)管理，也會(huì)執(zhí)行類似于重分配partition之類的管理任務(wù)。在符合某些特定條件下，Controller下的LeaderSelector會(huì)新的leader，ISR和新的leader_epoch及controller_epoch寫(xiě)入Zookeeper的相關(guān)節(jié)點(diǎn)中。同時(shí)發(fā)起LeaderAndIsrRequest通知所有的replicas。leader來(lái)：leader有單獨(dú)的線程定期檢測(cè)ISR中follower是否脫離ISR,如果發(fā)現(xiàn)ISR變化，則會(huì)將新的ISR的信息返回到Zookeeper的相關(guān)節(jié)點(diǎn)中。數(shù)據(jù)可靠性和持久性保producerleader送數(shù)據(jù)時(shí)以通過(guò)request.required.acks參數(shù)來(lái)設(shè)置數(shù)據(jù)可靠性的級(jí)別：1（默認(rèn)）：這意味著producer在ISR中的leader已成功收到的數(shù)-1：podcer需要等待ISR中的所有olowr都確認(rèn)接收到數(shù)據(jù)后才算一次發(fā)送完成，可靠性最高。但是這樣也不能保證數(shù)據(jù)不丟失，比如當(dāng)ISR中只有l(wèi)edr時(shí)（前面IR那一節(jié)講到，ISR中的成員由于某些情況會(huì)增加也會(huì)減少，最少就只剩一個(gè)eder），這ak=1如果要提高數(shù)據(jù)的可靠性，在設(shè)置request.required.acks=-1的同面進(jìn)行設(shè)置)的配合，這樣才能發(fā)揮最大的功效。min.insync.replicas這個(gè)參數(shù)設(shè)定ISR中的最小副本數(shù)是多少，默認(rèn)值為1，當(dāng)且僅當(dāng)request.required.acks參數(shù)設(shè)置為-1時(shí)，此參數(shù)才生效。如果ISR中的副本數(shù)少于min.insync.replicas配置的數(shù)量時(shí)，客戶端會(huì)返回異常：or Messagesarerejectedsincetherearefewerin-syncreplicasthanrequired。接下來(lái)acks=11的兩種情況進(jìn)行詳細(xì)分析producer數(shù)據(jù)leader，leader本地日志成功，返回客戶端成功；此時(shí)ISR中的副本還沒(méi)有來(lái)得及拉取該消息，leader宕機(jī)了，request.required.acks=-同步（Kafka默認(rèn)為同步，即producer.type=sync）的發(fā)送模式replication.factor>=2min.insync.replicas>=2的情況下，不會(huì)失數(shù)據(jù)有兩種典型情況。acks=-1的情況下（如無(wú)特殊說(shuō)明，以下acks都表示為參數(shù)request.required.acks），數(shù)據(jù)發(fā)送到leader,ISR的follower全部完成數(shù)據(jù)同步后，leader此時(shí)掛掉，那么會(huì)出新的acks=-1的情況下，數(shù)據(jù)發(fā)送到leader，部分ISR的副本同步，leader此時(shí)掛掉。比如follower1hfollower2都有可能變成新的leader,producer會(huì)得到返回異常，producer會(huì)重新發(fā)送數(shù)據(jù)，數(shù)當(dāng)然上圖中如果在leadercrashfollower2還沒(méi)有同步到任何數(shù)據(jù)，而且follower2被為新的leader的話，這樣消息就不會(huì)關(guān)于HW的進(jìn)一步考慮上圖（即acks=-1,部分ISR副本同步）中的另一種情況，如果在Leader掛掉的時(shí)候，follower1同步了消息4,5，follower2同步了消息4，與此同時(shí)follower2被為leader，那么此時(shí)follower1中的多出的消息5該做如何處理呢？這里就需要HW協(xié)同配合了。如前所述，一partitionISR列表中，leaderHW是所ISR列表里副本中最小的那個(gè)LEO。類似如下圖，某個(gè)topicpartition有三個(gè)副本，分別為A、B、CAleaderLEO最高，B緊隨其后，C機(jī)器由于配置比較低，網(wǎng)絡(luò)比較差，故而同步最慢。這個(gè)時(shí)候A機(jī)器宕機(jī)，這時(shí)候如果B成為leader，假如沒(méi)有HW，在A新恢復(fù)之后會(huì)做同步(makeFollower)LEO，會(huì)產(chǎn)生數(shù)據(jù)不一致的情況，所以使用HW避免這種情況。A做同步操作的時(shí)候，先將log件截?cái)嗟街白訦W3，之后再?gòu)腂中拉取消息進(jìn)行同步。如果失敗follower恢復(fù)過(guò)來(lái)，它首先將自己的log文件截?cái)嗟絚heckpointed時(shí)刻的HW的位置，之后再?gòu)膌eader中同步消息。leader掛掉會(huì)重新，新的leader會(huì)發(fā)送“指令”讓其余的follower截?cái)嘀磷陨淼腍W的位置然后再拉取新的消息。當(dāng)ISR中的個(gè)副本的LEO不一致時(shí)，如果此時(shí)leader掛掉，新leader時(shí)并不是按照LEO的高低進(jìn)行，而是按照ISR中的順序Leader認(rèn)為已提交。這樣就避免了部分?jǐn)?shù)據(jù)被寫(xiě)進(jìn)了leader，還沒(méi)來(lái)得及被任可以選擇是否等待消息commit，這可以通過(guò)request.required.acks設(shè)置。這種機(jī)制確保了只要ISR有一個(gè)或者follower，一條被commit的消息就不會(huì)丟失。有一個(gè)很重要的問(wèn)題是當(dāng)leader宕機(jī)了，怎樣在follower中出新的leader，因?yàn)閒ollower可能很多或者直接crash了，所以必須確保選擇“”的follower作為新的leader。一個(gè)基本的原則就是，leader不在了，新leader須擁有原leadercommit的所有消息。這就需要做一個(gè)折中，如果leader在表名一個(gè)消息被commit前等待的follower確認(rèn)，那么在它掛掉之后就有的follower可以成為新的leader，但這也會(huì)造成吞吐率的下降。一種非常常用的leader的方式是“少數(shù)服從多數(shù)”，Kafka并不是采用這種方式。這種模式下，如果有2f+1個(gè)副本，那么在commit之前必須保證有f+1個(gè)replica完消息，同時(shí)為了保證能正確出新的leader，失敗的副本數(shù)過(guò)f個(gè)。這種方式有個(gè)很大的優(yōu)勢(shì)，系統(tǒng)的延遲取決于最快的幾臺(tái)機(jī)器，也就是說(shuō)比如副本數(shù)為3，那么延遲就取決于最快的那follower是最慢的那個(gè)?！吧贁?shù)服從多數(shù)”的方式也有一些劣勢(shì)，為了保證leader的正常進(jìn)行，它所能的follower數(shù)比較少，如果要1follower掛掉，那么至少要3個(gè)以上的副本，如果要2個(gè)follower掛掉，必須要有5個(gè)以上的副本。也就是說(shuō)，在生產(chǎn)環(huán)境下為了保證較高的容錯(cuò)率，必須要有大量的副本，而大量的副本又會(huì)在大數(shù)據(jù)量下導(dǎo)致性能的急劇下降。這種算法用在Zookeeper這種共享集群配置的系統(tǒng)中而很少在需要大量數(shù)據(jù)的系統(tǒng)中使用的原因。HDFS的HA功能也是基于“少數(shù)服從多數(shù)的方，但其數(shù)不是用這樣方式。實(shí)際上，leader的算法非常多，比如Zookeeper的Zab、Raft以及ViewstampedReplication。而Kafka所使用的leader算法更像是微軟的PacificA算法。Kafka在Zookeeper中為每一個(gè)partition動(dòng)態(tài)的了一個(gè)ISR，ISR里的所replica都跟上leader，只有ISR里的成員才能有被選為leader的可能（unclean.leader.election.enable=false）。在這種模式下，對(duì)于f+1個(gè)副本Kafkatopic能在保證不丟失已經(jīng)commit消息的前提下f個(gè)副本，在大多數(shù)使用場(chǎng)景下，這種模方式ISRcommit需要等待的副本的數(shù)量是一樣的ISR要上文提到ISR中至少有一follower時(shí)，Kafka可以確保已經(jīng)commit的數(shù)據(jù)不丟失，但如果某一個(gè)partitionreplica都掛了，ISR中任意一replica“活”過(guò)來(lái)，并且選它作為選擇第一個(gè)“活”過(guò)來(lái)的replica（一定是在ISR中）作為leader這就需要在可用性和一致性當(dāng)中作出一個(gè)簡(jiǎn)單的抉擇。如果一定要等待ISRreplica“活”過(guò)來(lái)，那不可用的時(shí)間就可能會(huì)相對(duì)較長(zhǎng)。而且如ISR中所有的replica都無(wú)法”過(guò)來(lái)了，或者數(shù)據(jù)丟失了，這個(gè)partition將不可用。選擇第一個(gè)“活”過(guò)來(lái)的replica作為leader,這replicaISRreplica,使它并不保障已經(jīng)包含了所有已commit的消息，它也會(huì)成為leader作consumer的數(shù)據(jù)源。默認(rèn)情況下，Kafka采用第二種策略，即unclean.leader.unclean.leader.election.enable這個(gè)參數(shù)對(duì)于leader的、系統(tǒng)的可用性以及數(shù)據(jù)的可靠性都有至關(guān)重要的影響。下面來(lái)分析下幾如果上圖所示，假設(shè)某個(gè)partition中的副本數(shù)為3，replica-0,replica-1,replica-2分別存放在broker0,broker1broker2AR=(0,1,2)ISR=(0,1)。設(shè)置request.required.acks=-1,min.insync.replicas=2unclean.leader.election.enable=false這里講broker0中的副本也稱之為broker0broker0為leader，broker1為當(dāng)ISR中的replica-0出現(xiàn)crash的情況時(shí)，broker1為新的leader[ISR=(1)]，因?yàn)槭躮in.insync.replicas=2影響，write不嘗試恢復(fù)(重啟)replica-0，如果能起來(lái)，系統(tǒng)正常如果replica-0不能恢復(fù)，需要將min.insync.replicas1，恢復(fù)write功能當(dāng)ISR中的replica-0出現(xiàn)crash，緊接著replica-1也出現(xiàn)了crash,此時(shí)[ISR=(1),leader=-1],不能對(duì)外提供服務(wù)，此種情況如果replica-0起來(lái)，而replica-1不能起來(lái)，這時(shí)候仍然不能選出leader，因?yàn)楫?dāng)設(shè)置unclean.leader.election.enable=false時(shí)，leader只能從ISR中，當(dāng)ISR中所有副本都失效之后，需要ISR中最后失效的那個(gè)副本能恢復(fù)之后才能leader,即replica-0先失效，replica-1后失效，需要replica-1恢復(fù)后才能leader。保守的方案建議把unclean.leader.election.enable設(shè)置為true,但是這樣會(huì)有丟失數(shù)據(jù)的情況發(fā)生，這樣可以恢復(fù)read服務(wù)。同樣需要將min.insync.replicas設(shè)置為1，恢復(fù)write功能；write功能replica-0和replica-1都不能恢復(fù)，這種情況可以參考情形當(dāng)ISR中的replica-0,replica-1同時(shí)宕機(jī),此時(shí)[ISR=(0,1)],不能對(duì)外提供服務(wù)，此種情況恢復(fù)方案：嘗試恢復(fù)replica-0和服務(wù)。直到2個(gè)副本恢復(fù)正常，write功能才能恢復(fù)，或者將將Kafka的發(fā)送模Kafkaproducerproducer.type這個(gè)參數(shù)指定了在線程中消息的發(fā)送方式是同步的還是異步的，默認(rèn)是同步的方式，即producer.type=sync。如果設(shè)置成異步的模式，即producer.type=async，可以是producer以batchpushbroker的性能，但是這樣會(huì)增加丟失數(shù)據(jù)的風(fēng)險(xiǎn)。如producer.typesync。對(duì)于異步模式，還有4個(gè)配套的參數(shù)，如默認(rèn)值：5000。啟用異步模式時(shí)，producer緩存消息的時(shí)間。比 設(shè)置1000時(shí)，它會(huì)緩存1s的數(shù)據(jù)再一次發(fā)送出去，這樣可以極大的增加broker吞如果超過(guò)這個(gè)值，producer就會(huì)阻塞或者丟掉消息。默認(rèn)值：-1。當(dāng)達(dá)到上面參數(shù)時(shí)producer會(huì)阻塞等待的時(shí)間。如果設(shè)置為0，buffer隊(duì)列滿時(shí)producer不會(huì)阻塞，消息直接被丟掉；若設(shè)置為-1，producer會(huì)被阻塞，不會(huì)丟消息。緩以batch的方式推送數(shù)據(jù)可以極大的提高處理效率，afkaprodcer可以將消息在內(nèi)存中累計(jì)到一定數(shù)量后作為一個(gè)batch發(fā)送請(qǐng)求。batch的數(shù)量大小可以通過(guò)prduer的參數(shù)（ac.nm.esas）控制。通過(guò)增加ath的大小，可以減少網(wǎng)絡(luò)請(qǐng)求和磁盤O的次數(shù)，當(dāng)然具體參數(shù)設(shè)置需要在效率和時(shí)效性方面做一個(gè)權(quán)高可靠性使用分消息傳輸前面已經(jīng)介紹了Kafka如何進(jìn)行有效的，以及了解了producer和consumer如何工作。接下來(lái)的是Kafka如何確保消息在producer和consumer之間傳輸。有以下三種可能的傳輸保障（deliveryAtmostonce:息可能會(huì)丟，但絕不會(huì)重復(fù)傳Atleastonce：消息絕不會(huì)丟，但可能會(huì)重復(fù)傳Exactlyonce：每條消息肯定會(huì)被傳輸一次且僅傳輸一Kafka的消息傳輸保障機(jī)制非常直觀。producerbroker發(fā)送消息時(shí)，一旦這條消息被commit，由于副本機(jī)制（replication）的存在，它就不會(huì)丟失。但是如果producer發(fā)送數(shù)據(jù)給broker后，遇到的網(wǎng)絡(luò)問(wèn)題而造成通信中斷，那producer就無(wú)法判斷該條消息是否已經(jīng)提交（commit）。雖然Kafka無(wú)法確定網(wǎng)絡(luò)故障期間發(fā)生了什么，但是producer可以retry多次，確保消息已經(jīng)正確傳輸?shù)絙roker中，所以目前Kafka實(shí)現(xiàn)的atleastonce。consumer從broker中消息后，可以選擇commit，該操作會(huì)在Zookeeper中存下該consumer在該partition下的消息的offset。該consumer下一次再讀該partition時(shí)會(huì)從下一條開(kāi)始。如未commit，下一次的開(kāi)始位置會(huì)跟上一次commit之后的開(kāi)始位置相同。當(dāng)然也可以將consumer設(shè)置為 mit，即consumer一旦到數(shù)據(jù)立即自動(dòng)commit。如果只這一消息的過(guò)程，那Kafka是確保了exactlyonce,但是如果由于前面producer與broker之間的某種原因?qū)е孪⒌闹貜?fù)，那么這里就是atleastonce。在這consumercommit還沒(méi)來(lái)得及crashatmostonce讀完消息先處理再commit。這種模如果處理完了消息在commit之前consumercrash了，下次重新開(kāi)始工作時(shí)還會(huì)處理剛剛未commit的消息，實(shí)際上該消息已經(jīng)被處理過(guò)了，這就對(duì)應(yīng)于atleast如上一節(jié)所述，Kafkaproducerconsumer端都會(huì)出現(xiàn)消息的Kafka中提GUID(GloballyUniqueIdentifier)通過(guò)客戶端生成算法得到每個(gè)消息的uniqueid，同時(shí)可至broker上的地址，即通過(guò)GUID便可查詢提取消息內(nèi)容，也便于發(fā)送方的冪等針對(duì)GUID,如果從客戶端的角度去重，那么需要引入集中式緩存，不只Kafka,類似RabbitMQRocketMQ這類商業(yè)級(jí)中間件也只保障atleastonce,且也無(wú)法從自身去進(jìn)行消息去重。所以建議業(yè)借助Redis等其他產(chǎn)品進(jìn)行去重處理。高可靠性Kafka提供了很高的數(shù)據(jù)冗余彈性，對(duì)于需要數(shù)據(jù)高可靠性的場(chǎng)景，要保證數(shù)據(jù)寫(xiě)入到Kafka是安全的，高可靠的，需要如下的配置topic的配置：replication.factor>=3,即副本數(shù)至少是3個(gè)broker的配置：leader的條件unclean.leader.election.BenKafka在唯品會(huì)有著很深的歷史淵源，根據(jù)唯品會(huì)消息中間（VMS）所掌握的資料顯示，在VMS團(tuán)隊(duì)運(yùn)Kafka集群中所支撐的topic數(shù)已接近2000，每天的請(qǐng)求量也已達(dá)百億級(jí)。這里就以KafkaKafka的認(rèn)知，為大家在以后高效的使用Kafka時(shí)提供一份依據(jù)。Kafkabroker用到4臺(tái)機(jī)器，分別為broker[0/1/2/3]配置如下CPU:Memory:Network:OS/kernel:CentOsrelease6.6Disk:-Xmx8G-Xms8G-server-XX:+UseParNewGC--XX:+CMSClassUnloadingEnabled--XX:+DisableExplicitGC-Djava.awt.headless=true-Xloggc:/apps/service/kafka/bin/../logs/kafkaServer-gc.log-verbose:gc-XX:+Printetails-XX:+PrintateStamps-XX:+PrintGCTimeStamps.sun.management.jmxremote.sun.management.jmxremote.authenticate=false.sun.management.jmxremote.ssl=false.sun.management.jmxremote.客戶端機(jī)器配CPU:Memory:Network:OS/kernel:CentOsrelease6.3Disk:不同場(chǎng)景場(chǎng)景1：測(cè)試不同的副本數(shù)、min.insync.replicas策略以及request.required.acks策略（以下簡(jiǎn)稱acks策略）對(duì)于發(fā)送速度（TPS）的具體配置：一個(gè)producer；發(fā)送方式為sync；消息體大小為1kB；partition數(shù)為12。副本為：1/2/4；min.insync.replicas分別為1/2/4；acks分別為-1（all）/1/0。具體測(cè)試數(shù)據(jù)如下表（min.insync.replicas只在acks=-1時(shí)有效-110-210-220-410-420-440010020040110120140分析客戶端的acks策略對(duì)發(fā)送的TPS有較大的影響，TPS：acks_0>acks_1>ack_-1;acks=0/1時(shí)，TPS與min.insync.replicas參數(shù)以及副本數(shù)無(wú)關(guān)，僅受acks策略的影響。下面partition的個(gè)數(shù)設(shè)置為1，來(lái)進(jìn)一步確認(rèn)下不同的acks略、不同的min.insync.replicas策略以及不同的副本數(shù)對(duì)于發(fā)送速度的影響，詳細(xì)請(qǐng)看情景2和情景3。場(chǎng)景2：在partition個(gè)數(shù)固定為1，測(cè)試不同的副本replicas策略對(duì)發(fā)送速度的影具體配置：一個(gè)producer；發(fā)送方式為sync；消息體大小為1kB；如下21223132414244分析：副本數(shù)越高，TPS越低（這點(diǎn)與場(chǎng)景1的測(cè)試結(jié)論吻TPS場(chǎng)景3：在partition個(gè)數(shù)固定為1，測(cè)試不同的acks策略和副本數(shù)對(duì)發(fā)具體producer；發(fā)送方式sync；消1kB；min.insync.replicas=1。topic副本數(shù)為：1/2/4；acks：0/1/-1。如下1020401121411-2-4-分析（與情1一致副本數(shù)越多，TPS越低客戶端的acks策略對(duì)發(fā)送的TPS有較大的影響，TPS：acks_0>acks_1>ack_-1。場(chǎng)景4：測(cè)試不同partition數(shù)對(duì)發(fā)送速率的影響具體配置：一個(gè)producer；消息體大小為1KB；發(fā)送方式為sync；topic副本數(shù)為2；min.insync.replicas=2；acks=-1。partition數(shù)量設(shè)置為1/2/4/8/12。見(jiàn)下分析：partition不同會(huì)影響TPS，隨著partitionpartition數(shù)量的增加反而會(huì)TPS略微降場(chǎng)景5：通過(guò)將集群中部分broker設(shè)置成不可服務(wù)狀態(tài)，測(cè)試對(duì)客戶端以具體配producer消息體大1KB發(fā)送方式sync；topic副本數(shù)為4；min.insync.replicas設(shè)置為2；acks=-1；retries=0/100000000；partition數(shù)為12。具體測(cè)試數(shù)據(jù)如下表-420錯(cuò)誤-42錯(cuò)誤-42出錯(cuò)信錯(cuò)誤1：客戶端返回異常，部分?jǐn)?shù)據(jù)可落盤，部分失?。簅rg.mon.errors.NetworkException:Theserverdisconnectedbeforearesponsewasreceived.錯(cuò)誤2[WARN]internals.SenderGoterrorproduceresponsewithcorrelationid19369ontopic-partitiondefault_channel_replicas_4_1-3,retrying(999999999attemptsleft).Error:錯(cuò)誤3[WARN]internals.Sender-Goterrorproduceresponsewithcorrelationid77890ontopic-partitiondefault_channel_replicas_4_1-8,retrying(999999859attemptsleft).Error:NOT_ENOUGH_REPLICAS錯(cuò)誤4[WARN]internals.Sender-Goterrorproduceresponsewithcorrelationid77705ontopic-partitiondefault_channel_replicas_4_1-3,retrying(999999999attemptsleft).Error:NOT_ENOUGH_REPLICAS_AFTER_APPEND分析kill兩臺(tái)broker后，客戶端可以繼續(xù)發(fā)送。broker減少后，partition的leader分布在剩余的兩臺(tái)broker上，造成了TPS的減??；當(dāng)retries不為0時(shí)，消息有重復(fù)落盤；客戶端成功返回的消息都場(chǎng)景6：測(cè)試單個(gè)producer具體配置：：一個(gè)producer；消息體大小1KB；發(fā)送方式為sync；topic副本數(shù)為4；min.insync.replicas設(shè)置為2；acks=-1；partition數(shù)為12。測(cè)試數(shù)據(jù)及結(jié)果（單位為發(fā)送1314各場(chǎng)景測(cè)試總當(dāng)acks=-1時(shí)，Kafka發(fā)送端的TPS受限于topic的副本數(shù)量中），副本越多TPS越低acks=0時(shí)，TPS最高，其次為1，為-1，即TPS：acks_0>acks_1>ack_-1；min.insync.replicas參數(shù)不影響partition的不同會(huì)影響TPS，隨著partition的個(gè)數(shù)的增長(zhǎng)TPS會(huì)有所增長(zhǎng)，但并不是一直成正比關(guān)系，到達(dá)一定臨界值時(shí)，Kafka在acks=-1,min.insync.replicas>=1時(shí)，具有高可靠性，所作者介要從事消息中間件（RabbitMQ，Kafka等）相關(guān)的研究。MySQL到底能不能放到Docker里跑作作Talkischeap，showmethedemo。MySQL到底能不能放到Docker里跑？同程旅游目前已經(jīng)有超過(guò)一千個(gè)MySQL實(shí)例安全穩(wěn)定地跑在Docker平臺(tái)上。前前幾?？吹接蠱ySQL到底能不能放到Docker里跑的各種。所以MySQL的Docker實(shí)踐，到目前已有超一千多個(gè)MySQL例Docker臺(tái)安全穩(wěn)定地跑著，DB維能力發(fā)生了質(zhì)的提高（DBA再也不用擔(dān)心刪庫(kù)跑路了）。們?cè)贛ySQL的Docker化上的實(shí)踐給大家。背景介同程旅游早期的數(shù)據(jù)庫(kù)都以MSSQL主，這個(gè)產(chǎn)品有個(gè)特點(diǎn)就是UI換為MySQL后也是按照傳統(tǒng)的運(yùn)維方式管理。導(dǎo)致大部分的工作需要人當(dāng)然像早期使用過(guò)的MSSQL也是有優(yōu)點(diǎn)的：就是單機(jī)性能比較好，在當(dāng)年那個(gè)資源不夠的年代里常可以在高可用的實(shí)例上運(yùn)行多個(gè)但是MSSQL的缺陷也很多，比如做水平拆分比較，導(dǎo)致數(shù)據(jù)庫(kù)成為系統(tǒng)中最大的一個(gè)瓶頸。但在使用MySQL+中間件（做這個(gè)中間件也是下了不少心思的，以后可以一下）做水平拆分后就開(kāi)始解幅上升。舉個(gè)例子做1024分片的話一般是做32個(gè)node，一主一從是必須的（大部分情況是一主兩從），那么至少64實(shí)例，再加上應(yīng)急擴(kuò)展和備份用的節(jié)點(diǎn)那就了（中間件的開(kāi)發(fā)者更希望是1024片就是1024個(gè)實(shí)例）。一次上線做一個(gè)32node片擴(kuò)展從庫(kù)，兩個(gè)DBA足花了4個(gè)小時(shí)。另外，如果做單機(jī)單實(shí)例那肯定更，別的不說(shuō)，成本也會(huì)是個(gè)大問(wèn)題，且物理機(jī)的資源也未能最大化利用。況且因?yàn)镸ySQL單體的性運(yùn)維動(dòng)作等問(wèn)題也會(huì)讓DBA一頭糟，忙碌又容易出錯(cuò)的工作其實(shí)是有了單機(jī)多實(shí)例運(yùn)行MySQL實(shí)例的需求。單機(jī)多實(shí)例要思考的主要問(wèn)題就是如果進(jìn)行資源和限制，實(shí)現(xiàn)方案有很多，怎么選？KVM，Docker，Cgroups是目前的可以實(shí)現(xiàn)主流方案。KVM對(duì)一個(gè)DB的來(lái)說(shuō)太重了，性能影響太大，在生產(chǎn)環(huán)境用不合適。這是因?yàn)镸ySQL運(yùn)行的就是個(gè)進(jìn)程而且對(duì)IO要求比較高，所以KVM不滿足要然優(yōu)化以后IO能有cgroups比較輕，雖然性不是很高，但對(duì)于的MySQL多實(shí)例來(lái)說(shuō)是完全夠用了（Docker的資源限制用的就是cgroups）。但是還想針對(duì)每個(gè)MySQL實(shí)例運(yùn)行額外的管理進(jìn)程(比如等等)。用cgroups實(shí)現(xiàn)起來(lái)會(huì)比較復(fù)雜，并且還想讓實(shí)例管理和物理機(jī)區(qū)分開(kāi)，那cgroups也放棄。至于Docker，那就很不錯(cuò)了，那些用cgroups的麻煩它都給搞定了。并且有API可以提供支持，開(kāi)發(fā)成本低。而且可以基于Docker鏡像來(lái)做部署自動(dòng)化，那么環(huán)境的一至性也可輕松解決。所以最終選擇了Docker作為臺(tái)的資源方案(當(dāng)然過(guò)程中也做了很多性能、穩(wěn)定性等的適配工作，這里就不贅述了)。下面兩個(gè)圖可以形象展示這款產(chǎn)品帶來(lái)的性意義用的資源，并且天生自帶高可用、自動(dòng)備份、告警、慢日志分析等功能，無(wú)需用戶關(guān)心資源背后的事情。其次才是各種日常的DBA運(yùn)維操作需求服務(wù)化輸出。下面就來(lái)講講這個(gè)平臺(tái)是如何一步步實(shí)現(xiàn)的。平臺(tái)實(shí)現(xiàn)過(guò)站在巨人的肩膀度、人才儲(chǔ)備等等。當(dāng)然對(duì)于一個(gè)臺(tái)也一樣，所以進(jìn)行了短平快者對(duì)已有開(kāi)源產(chǎn)品進(jìn)行二次開(kāi)發(fā)以后實(shí)現(xiàn)定制化的需求。以下是當(dāng)時(shí)下面選幾個(gè)產(chǎn)品簡(jiǎn)單說(shuō)一下通過(guò)它實(shí)現(xiàn)什么功能Percona：的備份、慢日志分析、過(guò)載保護(hù)等功能都是基pt-tools具包來(lái)實(shí)現(xiàn)的Prometheus：性能優(yōu)越且功能強(qiáng)大的TSDB，用于實(shí)現(xiàn)整個(gè)平臺(tái)實(shí)例的告警。缺點(diǎn)是沒(méi)有集群功能，單機(jī)性能是個(gè)瓶頸(雖然單機(jī)的處理能力已經(jīng)很強(qiáng)了)，所以在業(yè)務(wù)層面進(jìn)行了DB拆Consul：分布式的服務(wù)發(fā)現(xiàn)和配置共享，配合prometheus實(shí)現(xiàn)節(jié)點(diǎn)。Python：管理Docker容器中MySQL實(shí)例的agent以及部分操Docker：承載MySQL實(shí)例并實(shí)現(xiàn)資源和資源限制容器調(diào)度的開(kāi)源產(chǎn)品主要有Kubernetes和mesos，但是并沒(méi)有選用這兩個(gè)。主要原因是已經(jīng)開(kāi)發(fā)了一套基于Docker的資源理、調(diào)度的系統(tǒng)，至今穩(wěn)定2多了。這套架構(gòu)稍作修改是符合需另外第的資源調(diào)度系統(tǒng)兼容目前的高可用架構(gòu)，其他自動(dòng)化會(huì)做到計(jì)算調(diào)度和調(diào)度分離的情況下可能會(huì)轉(zhuǎn)向Kubernetes的先會(huì)根據(jù)集群規(guī)模主一從還是一主多從，或者是分片集群定要?jiǎng)?chuàng)建的實(shí)例數(shù)量，然后根據(jù)這個(gè)需求按照的資源篩選規(guī)則(比如主從不能在同一臺(tái)機(jī)器、內(nèi)存配置不允許超賣等等從現(xiàn)有的資源配出可用資源，然后依次創(chuàng)建主從關(guān)系、創(chuàng)建高可用管理、檢查集群狀態(tài)、推送集群信息到中間件了中間件的情況下中心、最后將以上相關(guān)信息都同步到CMDB。以上的每一個(gè)工作都是通過(guò)服務(wù)端發(fā)送消息到agent，然后由agent執(zhí)行對(duì)應(yīng)的，會(huì)返回指定格式的執(zhí)行結(jié)果，這些是由DBA開(kāi)發(fā)的。這種方式的優(yōu)勢(shì)在于，DBA比任何人都了解數(shù)據(jù)庫(kù)，所以通過(guò)這種方式可以有效提升項(xiàng)目開(kāi)發(fā)效率，也能讓DBA參與到項(xiàng)目當(dāng)中去。開(kāi)發(fā)只需要寫(xiě)前臺(tái)邏輯，DBA負(fù)責(zé)后端具體執(zhí)行的指令。如果未來(lái)功能有變更或迭代的話，只需要迭代即可，量極小。經(jīng)過(guò)對(duì)同程多年的DB維數(shù)據(jù)分析得到如下經(jīng)驗(yàn)CPU大超賣3，內(nèi)存不超同一機(jī)房?jī)?yōu)先選擇資源最空閑的機(jī)器主從角色不允許在同一臺(tái)機(jī)器上若有VIP求的主從端口需要一致，無(wú)VIP求直接對(duì)接中間分片的集群將節(jié)點(diǎn)分布在多臺(tái)物理機(jī)上功以上是已經(jīng)上線的部分功能，還有很多功能就不再一一展示備份恢復(fù)備份工具是用percona-xtrabackup。通過(guò)流備份的方式將數(shù)據(jù)一定要關(guān)注磁盤IO和網(wǎng)絡(luò)，所以的備份策略會(huì)限制單個(gè)物理機(jī)上并備份任務(wù)始終保持到指定的數(shù)量。假如整個(gè)機(jī)房并行的是50個(gè)任務(wù)，那么這50個(gè)當(dāng)中如果有5提前備份完成，那么會(huì)新加入5個(gè)等待備份的任務(wù)進(jìn)入這個(gè)備份隊(duì)列。告警zabbix功能的確非常強(qiáng)大，但是后端的數(shù)據(jù)庫(kù)是個(gè)瓶頸，當(dāng)然可以通過(guò)數(shù)據(jù)庫(kù)要的指標(biāo)比較多，如果的項(xiàng)目比較多，zabbix就需要加proxy，架構(gòu)越來(lái)越復(fù)雜，再加上和平臺(tái)對(duì)接的成本比較高，對(duì)一些復(fù)雜的統(tǒng)計(jì)類查詢(95值、值等)性能比較差。所以選了一款TSDB——prometheus，這是一款性能極強(qiáng)、極其但凡事又有兩面性，它的缺點(diǎn)就是不支持集群架構(gòu)(不過(guò)解決了擴(kuò)展的問(wèn)題，下面會(huì)講到)。prometheus的使用應(yīng)該是從一年前就開(kāi)始的，那時(shí)候只是把它作為輔助的系統(tǒng)來(lái)使用的，隨著逐漸熟悉，越來(lái)越覺(jué)得這個(gè)是容器監(jiān)控的絕佳解決方案。所以在上臺(tái)的時(shí)候就選擇了它作為整個(gè)平臺(tái)的監(jiān)prometheus是支持pushgateway和pull的方式。選用了pull的方式。因?yàn)榻Y(jié)構(gòu)簡(jiǎn)單，開(kāi)發(fā)成本低的同時(shí)還能和的系統(tǒng)完美對(duì)接。consul集群負(fù)責(zé)實(shí)例信息和服務(wù)信息，比如MySQL實(shí)例主從對(duì)應(yīng)的服務(wù)、Linux主從對(duì)應(yīng)的服務(wù)、容器對(duì)應(yīng)的服務(wù)。然后prometheus通過(guò)consul上的信息來(lái)獲取目標(biāo)，然后去pull數(shù)據(jù)?？蛻舳耸且詀gent的形式存在，prometheus通過(guò)HTTP協(xié)議獲取agent端到的數(shù)據(jù)。不得不說(shuō)grafana是畫(huà)圖界的扛把子，功能齊全的度量和圖形編輯器，經(jīng)過(guò)簡(jiǎn)單配置就能完成各種圖形的展示。然后打只要點(diǎn)擊按鈕即可告警管理分為：告警發(fā)送、告警接收人管理、告警靜默等功能。prometheus有一個(gè)告警發(fā)送模塊alertmanager，通過(guò)webhook的方式讓alertmanager把告警到臺(tái)的告警API，然后在臺(tái)來(lái)根據(jù)后面的邏輯進(jìn)行告警內(nèi)容發(fā)送alertmanager推過(guò)來(lái)的只是實(shí)例緯度的告警，所以結(jié)合告警平臺(tái)的實(shí)例相關(guān)信息，會(huì)拼出一個(gè)信息的告警內(nèi)容。讓DBA一看就知管理方式不是想要的，所以就想把a(bǔ)lertmanager對(duì)告警信息處理的但是文檔并沒(méi)有提及到alertmanager的API，通過(guò)對(duì)源碼的分析，找到了告警管理相關(guān)的API。然后alertmanager的原生UI上操作的功能完美移植到了的臺(tái)，同時(shí)新增了實(shí)例相關(guān)集群名稱、下面是一些操作樣例當(dāng)前告添加告警靜默已創(chuàng)建的靜默規(guī)則慢日志分析系慢日志的收集是通過(guò)pt-query-digest每小時(shí)進(jìn)行本地分析，分析完成以后將結(jié)果寫(xiě)入慢日志的數(shù)據(jù)庫(kù)來(lái)完成的。當(dāng)然如果用戶需要以在UI點(diǎn)擊慢日志查看，就能看到該實(shí)例的慢日志分析結(jié)果。它同時(shí)集成了explain、查看tablestatus等功能。這些功能就是DBA運(yùn)維中經(jīng)常需要用到的。的設(shè)計(jì)思路是以集群示過(guò)多無(wú)用的信息，亂還有可能導(dǎo)致誤操作?？戳讼聢D中的這些功能圖中只是一部分有部分未展示出的功能(集成中間件、Dashboard、黑屏窗口等)，在后版能高可高可用方案使用了目前最流行的MySQL高可用方案MHA。MHA的優(yōu)缺點(diǎn)就不在這里講了，有DBA同學(xué)的應(yīng)該都已經(jīng)很熟悉了。這里我說(shuō)一下基于同程業(yè)務(wù)做的調(diào)整。因?yàn)橹饕褂玫腗ariaDB，但是MHA版本也是不能支持MariaDB的GTID切換。所以在原有的基礎(chǔ)上做了改進(jìn)，支持了MariaDB的GTID。使用GTID以后靈活切換是一個(gè)方面，另外一個(gè)方面是sync_master_info和sync_relay_log_info就不需要設(shè)置成1了(MariaDB不支持寫(xiě)table，只能寫(xiě)file)，極大減少了從庫(kù)帶來(lái)的在切換時(shí)調(diào)整sync_binlog和innodb_flush_log_at_trx_樣相對(duì)數(shù)據(jù)最安全，但是IO也最高。云服務(wù)的多實(shí)例部署會(huì)導(dǎo)致一臺(tái)物理機(jī)上既有master又有slave?？隙ú幌Ｍ鹲lave產(chǎn)生太高的IO影響到同機(jī)器的其他slave(雖然可以IO，但是優(yōu)先降低不必要IO才靠譜)。所以理論上來(lái)說(shuō)Master上面設(shè)置雙1，slave則可以不這樣設(shè)置。但是切換后原來(lái)的salve可能會(huì)變成了master。所以默認(rèn)slave非雙1，在MHA切換的時(shí)候會(huì)自動(dòng)將新master的這兩個(gè)參數(shù)設(shè)置為1。在多個(gè)點(diǎn)部署了哨兵服務(wù)。這個(gè)哨兵是一個(gè)簡(jiǎn)單的API服務(wù)，帶上響應(yīng)的參數(shù)可以請(qǐng)求到指定的實(shí)例。當(dāng)MHAmanager檢測(cè)到有Master觸發(fā)secondarycheck帶著master相關(guān)信息請(qǐng)求哨兵節(jié)點(diǎn)的API，根據(jù)哨兵節(jié)點(diǎn)返回情況，若超過(guò)半數(shù)無(wú)法連接高可用切換對(duì)接DBDB中間件和DB通過(guò)物理IP連接，當(dāng)發(fā)生高可用切換時(shí)將的MasterIP、Masterport息推送到DB中間件控制中心，DB間件拿實(shí)例、庫(kù)遷分等需求。實(shí)現(xiàn)原理也很簡(jiǎn)單，用mydumper指定數(shù)據(jù)備份下來(lái)以后，再用myloader恢復(fù)到指定數(shù)據(jù)庫(kù)。這是一個(gè)全量的過(guò)程，增量用的是用自己開(kāi)發(fā)的一個(gè)支持并行的工具，這個(gè)工具還支持等冪處理，使用更靈活。沒(méi)有用原生就需要對(duì)binlog做過(guò)濾，這里面涉及到配置修改，實(shí)例重啟，實(shí)現(xiàn)過(guò)程并沒(méi)有高大上是完全滿足需求。當(dāng)mydumpermyloader也有一些問(wèn)題，也做了小改動(dòng)以后才實(shí)現(xiàn)的。后面計(jì)劃用流的方式去做數(shù)據(jù)導(dǎo)出導(dǎo)入(類似于阿里開(kāi)源的datax)。問(wèn)題，提供了自研的數(shù)據(jù)校驗(yàn)工具。實(shí)測(cè)300G的數(shù)據(jù)校驗(yàn)時(shí)間約為2至3分鐘，快慢取決于開(kāi)多少線程。底層物理資提升資源利用率(CPU、內(nèi)存)通過(guò)單機(jī)多實(shí)例，CPU資源可超賣，有效提高CPU資源的利用。內(nèi)有足夠的內(nèi)存。若有剩余內(nèi)存