柚子快報(bào)邀請(qǐng)碼778899分享：架構(gòu) 微服務(wù)和kafka

http://yzkb.51969.com/

一、微服務(wù)簡(jiǎn)介

1.單體架構(gòu)

分布式--微服務(wù)--云原生

傳統(tǒng)架構(gòu)（單機(jī)系統(tǒng)），一個(gè)項(xiàng)目一個(gè)工程：比如商品、訂單、支付、庫(kù)存、登錄、注冊(cè)等等，統(tǒng)一部署，一個(gè)進(jìn)程

all in one的架構(gòu)方式，把所有的功能單元放在一個(gè)應(yīng)用里。然后把整個(gè)應(yīng)用部署到一臺(tái)服務(wù)器上。如果負(fù)載能力不行，將整個(gè)應(yīng)用進(jìn)行水平復(fù)制，進(jìn)行擴(kuò)展（擴(kuò)展是指模塊擴(kuò)展，不方便做開發(fā)測(cè)試），然后通過負(fù)載均衡實(shí)現(xiàn)訪問。

Java實(shí)現(xiàn)：JSP、Servlet，打包成一個(gè)jar、war部署易于開發(fā)和測(cè)試:也十分方便部署;當(dāng)需要擴(kuò)展時(shí)，只需要將war復(fù)制多份，然后放到多個(gè)服務(wù)器上，再做個(gè)負(fù)載均衡就可以了。如果某個(gè)功能模塊出問題，有可能全站不可訪問，修改Bug后、某模塊功能修改或升級(jí)后，需要停掉整個(gè)服務(wù)，重新整體重新打包、部署這個(gè)應(yīng)用war包，功能模塊相互之間耦合度高,相互影響,不適合當(dāng)今互聯(lián)網(wǎng)業(yè)務(wù)功能的快速迭代。特別是對(duì)于一個(gè)大型應(yīng)用，我們不可能吧所有內(nèi)容都放在一個(gè)應(yīng)用里面，我們?nèi)绾尉S護(hù)、如何分工合作都是問題。如果項(xiàng)目龐大，管理難度大

web應(yīng)用服務(wù)器：開源的tomcat、jetty、glassfish。商用的有weblogic、websphere、Jboss

2.微服務(wù)

Microservices Guide

每個(gè)模塊跑一個(gè)單獨(dú)應(yīng)用，微服務(wù)關(guān)注的業(yè)務(wù)邏輯（restful、API、http、grpc、tcp、http），

屬于SOA（Service Oriented Architecture）的子集

微服務(wù)化的核心就是將傳統(tǒng)的一站式應(yīng)用，根據(jù)業(yè)務(wù)拆分成一個(gè)一個(gè)的服務(wù)，徹底去掉耦合，每一個(gè)微服務(wù)提供單個(gè)業(yè)務(wù)功能，一個(gè)服務(wù)只做一件事。每個(gè)服務(wù)都圍繞著具體業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠被獨(dú)立地部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等

從技術(shù)角度講就是一種小而獨(dú)立的處理過程，類似與進(jìn)程的概念，能夠自行單獨(dú)啟動(dòng)或銷毀

微服務(wù)架構(gòu)（分布式系統(tǒng)），各個(gè)模塊/服務(wù)，各自獨(dú)立出來(lái)，"讓專業(yè)的人干專業(yè)的事"，獨(dú)立部署。分布式系統(tǒng)中，不同的服務(wù)可以使用各自獨(dú)立的數(shù)據(jù)庫(kù)。

服務(wù)之間采用輕量級(jí)的通信機(jī)制（通常是基于HTTP的RESTful API）。

微服務(wù)設(shè)計(jì)的思想改變了原有的企業(yè)研發(fā)團(tuán)隊(duì)組織架構(gòu)。傳統(tǒng)的研發(fā)組織架構(gòu)是水平架構(gòu)，前端、后端、DBA、測(cè)試分別有自己對(duì)應(yīng)的團(tuán)隊(duì)，屬于水平團(tuán)隊(duì)組織架構(gòu)。而微服務(wù)的設(shè)計(jì)思想對(duì)團(tuán)隊(duì)的劃分有著一定的影響，使得團(tuán)隊(duì)組織架構(gòu)的劃分更傾向于垂直架構(gòu)，比如用戶業(yè)務(wù)是一個(gè)團(tuán)隊(duì)來(lái)負(fù)責(zé)，支付業(yè)務(wù)是一個(gè)團(tuán)隊(duì)來(lái)負(fù)責(zé)。但實(shí)際上在企業(yè)中并不會(huì)把團(tuán)隊(duì)組織架構(gòu)拆分得這么絕對(duì)，垂直架構(gòu)只是一種理想的架構(gòu)

微服務(wù)的實(shí)現(xiàn)框架有多種，不同的應(yīng)用架構(gòu)，部署方式也有不同?

3.單體架構(gòu)和微服務(wù)比較

單體架構(gòu)的主要特征：

1.緊密耦合的組件：在單體架構(gòu)中，組件之間緊密耦合，這使得修改和擴(kuò)展應(yīng)用程序的各個(gè)部分而不影響整個(gè)系統(tǒng)變得更加困難。

2.單一代碼庫(kù)：應(yīng)用程序的所有部分都位于單一的代碼庫(kù)中，這對(duì)于開發(fā)和部署非常方便。

3.共享資源：組件共享相同的資源，如內(nèi)存和CPU，這可能導(dǎo)致性能瓶頸和爭(zhēng)用問題。

4.有限的可擴(kuò)展性：?jiǎn)误w應(yīng)用程序在水平方向上進(jìn)行擴(kuò)展可能具有挑戰(zhàn)性，因?yàn)閿U(kuò)展一個(gè)組件可能需要擴(kuò)展整個(gè)應(yīng)用程序。

5.復(fù)雜性：隨著應(yīng)用程序的增長(zhǎng)，由于復(fù)雜性增加，維護(hù)和理解可能變得困難。

微服務(wù)架構(gòu)的主要特征：

1.松散耦合：微服務(wù)之間松散耦合，允許每個(gè)服務(wù)獨(dú)立開發(fā)、部署和擴(kuò)展，而不影響其他服務(wù)。

2.分布式系統(tǒng)：微服務(wù)通過網(wǎng)絡(luò)通信，通常使用API，這需要仔細(xì)考慮網(wǎng)絡(luò)和通信模式。

3.獨(dú)立部署：服務(wù)可以獨(dú)立部署，實(shí)現(xiàn)持續(xù)交付和更快的發(fā)布周期。

4.專業(yè)化服務(wù)：每個(gè)微服務(wù)專注于特定的業(yè)務(wù)功能，使代碼庫(kù)更易于管理和維護(hù)。

5.可擴(kuò)展性：微服務(wù)可以單獨(dú)擴(kuò)展，根據(jù)需求有效地分配資源。

6.多語(yǔ)言架構(gòu)：不同的微服務(wù)可以使用最適合其需求的不同編程語(yǔ)言和技術(shù)進(jìn)行開發(fā)。?

4.微服務(wù)的優(yōu)缺點(diǎn)

微服務(wù)優(yōu)點(diǎn)：

每個(gè)服務(wù)足夠內(nèi)聚，足夠小，代碼容易理解。這樣能聚焦一個(gè)簡(jiǎn)單唯一的業(yè)務(wù)功能或業(yè)務(wù)需求。開發(fā)簡(jiǎn)單、開發(fā)效率提高，一個(gè)服務(wù)可能就是專業(yè)的只干一件事，微服務(wù)能夠被小團(tuán)隊(duì)單獨(dú)開發(fā)，這個(gè)小團(tuán)隊(duì)可以是2到5人的開發(fā)人員組成

微服務(wù)是松耦合的，是有功能意義的服務(wù)，無(wú)論是在開發(fā)階段或部署階段都是獨(dú)立的。

微服務(wù)能使用不同的語(yǔ)言開發(fā)，易于和第三方集成，微服務(wù)運(yùn)行容易且靈活的方式集成自動(dòng)部署，通過持續(xù)集成工具，如:Jenkins、Hudson、Bamboo

微服務(wù)易于被一個(gè)開發(fā)人員理解、修改和維護(hù)，這樣小團(tuán)隊(duì)能夠更關(guān)注自己的工作成果，無(wú)需通過合作才能體現(xiàn)價(jià)值

微服務(wù)允許你利用融合最新技術(shù)。微服務(wù)只是業(yè)務(wù)邏輯的代碼，不會(huì)和HTML/CSS或其他界面組件混合，即前后端分離

每個(gè)微服務(wù)都有自己的存儲(chǔ)能力，可以有自己的數(shù)據(jù)庫(kù)，也可以有統(tǒng)一數(shù)據(jù)庫(kù)

微服務(wù)缺點(diǎn)：（耦合性低，通信比較復(fù)雜，通過url）

微服務(wù)把原有的一個(gè)項(xiàng)目拆分成多個(gè)獨(dú)立工程，增加了開發(fā)(編寫API)、測(cè)試、運(yùn)維(上線，需要會(huì)docker)、監(jiān)控等的復(fù)雜度

微服務(wù)架構(gòu)需要保證不同服務(wù)之間的數(shù)據(jù)一致性，引入了分布式事務(wù)和異步補(bǔ)償機(jī)制，為設(shè)計(jì)和開發(fā)帶來(lái)一定挑戰(zhàn)

開發(fā)人員和運(yùn)維需要處理分布式系統(tǒng)的復(fù)雜性，需要更強(qiáng)的技術(shù)能力

微服務(wù)適用于復(fù)雜的大系統(tǒng)，對(duì)于小型應(yīng)用使用微服務(wù)，進(jìn)行盲目的拆分只會(huì)增加其維護(hù)和開發(fā)成本

微服務(wù)技術(shù)棧

微服務(wù)治理：

注冊(cè)中心：將所有API、網(wǎng)關(guān)、Url，接口、端口所有調(diào)用的關(guān)系，放到注冊(cè)中心去，所有客戶端先訪問一個(gè)中間件發(fā)現(xiàn)中心，然后發(fā)現(xiàn)中心可以找到對(duì)應(yīng)的調(diào)用關(guān)系，然后客戶再次訪問就可以訪問到對(duì)應(yīng)的api節(jié)點(diǎn)

一旦微服務(wù)發(fā)生變更，會(huì)同步到注冊(cè)中心/目錄下

配置中心是一種統(tǒng)一管理各種應(yīng)用配置的基礎(chǔ)服務(wù)組件。12

配置中心的主要作用是將配置從應(yīng)用中抽取出來(lái)，進(jìn)行統(tǒng)一管理，從而優(yōu)雅地解決配置的動(dòng)態(tài)變更、權(quán)限管理、持久化、運(yùn)維成本等問題。通過集中管理配置，配置中心將應(yīng)用的配置作為一個(gè)單獨(dú)的服務(wù)抽離出來(lái)，同時(shí)也需要解決新的問題，如版本管理（為了支持回滾）、權(quán)限管理等。在系統(tǒng)架構(gòu)中，配置中心是整個(gè)微服務(wù)基礎(chǔ)架構(gòu)體系中的一個(gè)組件，雖然其功能看似簡(jiǎn)單，即配置的管理和存取，但它是整個(gè)微服務(wù)架構(gòu)中不可或缺的一環(huán)。

微服務(wù)網(wǎng)關(guān)：做業(yè)務(wù)的擴(kuò)展，做OA系統(tǒng)（辦公、審計(jì)）

API網(wǎng)關(guān)：將多個(gè)不同業(yè)務(wù)的API整合在一起，業(yè)務(wù)的擴(kuò)展、動(dòng)態(tài)自制的管理反向代理、網(wǎng)關(guān)、負(fù)載均衡；API是入口，它還可以做限流（藍(lán)綠），流量控制、熔斷降級(jí)

微服務(wù)、分布式本質(zhì)是區(qū)域中心化

異步通信技術(shù)：削峰、限流

把5個(gè)技術(shù)棧整合在一起，就會(huì)用到微服務(wù)框架

5.常見的微服務(wù)框架

Dubbo

阿里開源貢獻(xiàn)給了ASF，目前已經(jīng)是Apache的頂級(jí)項(xiàng)目，一款高性能的Java RPC服務(wù)框架，微服務(wù)生態(tài)體系中的一個(gè)重要組件

將單體程序分解成多個(gè)功能服務(wù)模塊，模塊間使用Dubbo框架提供的高性能RPC通信

內(nèi)部協(xié)調(diào)使用 Zookeeper，實(shí)現(xiàn)服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)和服務(wù)治理

Spring cloud

一個(gè)完整的微服務(wù)解決方案，相當(dāng)于Dubbo的超集

微服務(wù)框架，將單體應(yīng)用拆分為粒度更小的單一功能服務(wù)

基于HTTP協(xié)議的REST(Representational State Transfer 表述性狀態(tài)轉(zhuǎn)移）風(fēng)格實(shí)現(xiàn)模塊間通信

二、ZooKeeper

1.zookeeper介紹（注冊(cè)中心、配置中心）

ZooKeeper 是一個(gè)開源的分布式協(xié)調(diào)服務(wù)，ZooKeeper框架最初是在“Yahoo!"上構(gòu)建的，用于以簡(jiǎn)單而穩(wěn)健的方式訪問他們的應(yīng)用程序。 后來(lái)，Apache ZooKeeper成為Hadoop，HBase和其他分布式框架使用的有組織服務(wù)的標(biāo)準(zhǔn)。 例如，Apache HBase使用ZooKeeper跟蹤分布式數(shù)據(jù)的狀態(tài)。ZooKeeper 的設(shè)計(jì)目標(biāo)是將那些復(fù)雜且容易出錯(cuò)的分布式一致性服務(wù)封裝起來(lái)，構(gòu)成一個(gè)高效可靠的原語(yǔ)集，并以一系列簡(jiǎn)單易用的接口提供給用戶使用。

ZooKeeper 是一個(gè)典型的分布式數(shù)據(jù)一致性解決方案，分布式應(yīng)用程序可以基于 ZooKeeper 實(shí)現(xiàn)諸如數(shù)據(jù)發(fā)布/訂閱、負(fù)載均衡、命名服務(wù)、分布式協(xié)調(diào)/通知、集群管理、Master 選舉、分布式鎖（為了保持一致性，API、URL、配置文件內(nèi)容保持一致）和分布式隊(duì)列等功能。

Zookeeper 一個(gè)最常用的使用場(chǎng)景就是用于擔(dān)任服務(wù)生產(chǎn)者和服務(wù)消費(fèi)者的注冊(cè)中心(提供發(fā)布訂閱服務(wù))。 服務(wù)生產(chǎn)者將自己提供的服務(wù)注冊(cè)到Zookeeper中心，服務(wù)的消費(fèi)者在進(jìn)行服務(wù)調(diào)用的時(shí)候先到Zookeeper中查找服務(wù)，獲取到服務(wù)生產(chǎn)者的詳細(xì)信息之后，再去調(diào)用服務(wù)生產(chǎn)者的內(nèi)容與數(shù)據(jù)。如下圖所示，在 Dubbo架構(gòu)中 Zookeeper 就擔(dān)任了注冊(cè)中心這一角色。

2.zookeeper工作原理

ZooKeeper 是一個(gè)分布式服務(wù)框架，它主要是用來(lái)解決分布式應(yīng)用中經(jīng)常遇到的一些數(shù)據(jù)管理問題，如：命名服務(wù)、狀態(tài)同步、配置中心、集群管理等。

①：ZooKeeper 功能

命名服務(wù)

命名服務(wù)是分布式系統(tǒng)中比較常見的一類場(chǎng)景。命名服務(wù)是分布式系統(tǒng)最基本的公共服務(wù)之一。在分布式系統(tǒng)中，被命名的實(shí)體通?？梢允羌褐械臋C(jī)器、提供的服務(wù)地址或遠(yuǎn)程對(duì)象等——這些我們都可以統(tǒng)稱它們?yōu)槊郑∟ame），其中較為常見的就是一些分布式服務(wù)框架（如RPC、RMI）中的服務(wù)地址列表，通過使用命名服務(wù)，客戶端應(yīng)用能夠根據(jù)指定名字來(lái)獲取資源的實(shí)體、服務(wù)地址和提供者的信息等。

Zookeeper 數(shù)據(jù)模型（樹狀結(jié)構(gòu)）

在 Zookeeper 中，節(jié)點(diǎn)分為兩類，第一類是指構(gòu)成Zookeeper集群的主機(jī)，稱之為主機(jī)節(jié)點(diǎn)；第二類則是指內(nèi)存中zookeeper數(shù)據(jù)模型中的數(shù)據(jù)單元，用來(lái)存儲(chǔ)各種數(shù)據(jù)內(nèi)容，稱之為數(shù)據(jù)節(jié)點(diǎn) ZNode。Zookeeper內(nèi)部維護(hù)了一個(gè)層次關(guān)系(樹狀結(jié)構(gòu))的數(shù)據(jù)模型，它的表現(xiàn)形式類似于Linux的文件系統(tǒng)，甚至操作的種類都一致。

Zookeeper數(shù)據(jù)模型中有自己的根目錄(/)，根目錄下有多個(gè)子目錄，每個(gè)子目錄后面有若干個(gè)文件,由斜杠(/)進(jìn)行分割的路徑，就是一個(gè)ZNode,每個(gè) ZNode上都會(huì)保存自己的數(shù)據(jù)內(nèi)容和一系列屬性信息.（把狀態(tài)，相關(guān)模塊都放在注冊(cè)中心）

狀態(tài)同步

每個(gè)節(jié)點(diǎn)除了存儲(chǔ)數(shù)據(jù)內(nèi)容和 node 節(jié)點(diǎn)狀態(tài)信息之外，還存儲(chǔ)了已經(jīng)注冊(cè)的APP 的狀態(tài)信息，當(dāng)有些節(jié)點(diǎn)或APP 不可用，就將當(dāng)前狀態(tài)同步給其他服務(wù)。

配置中心

現(xiàn)在我們大多數(shù)應(yīng)用都是采用的是分布式開發(fā)的應(yīng)用，搭建到不同的服務(wù)器上，我們的配置文件，同一個(gè)應(yīng)用程序的配置文件一樣，還有就是多個(gè)程序存在相同的配置，當(dāng)我們配置文件中有個(gè)配置屬性需要改變，我們需要改變每個(gè)程序的配置屬性，這樣會(huì)很麻煩的去修改配置，那么可用使用ZooKeeper 來(lái)實(shí)現(xiàn)配置中心， ZooKeeper 采用的是推拉相結(jié)合的方式：客戶端向服務(wù)端注冊(cè)自己需要關(guān)注的節(jié)點(diǎn)，一旦該節(jié)點(diǎn)的數(shù)據(jù)發(fā)生變更，那么服務(wù)端就會(huì)向相應(yīng)的客戶端發(fā)送Watcher事件通知，客戶端接收到這個(gè)消息通知后，需要主動(dòng)到服務(wù)端獲取最新的數(shù)據(jù)。

Apollo（阿波羅）是攜程框架部門研發(fā)的開源配置管理中心,此應(yīng)用比較流行

集群管理

所謂集群管理，包括集群監(jiān)控與集群控制兩大塊，前者側(cè)重對(duì)集群運(yùn)行時(shí)狀態(tài)的收集，后者則是對(duì)集群進(jìn)行操作與控制，在日常開發(fā)和運(yùn)維過程中，我們經(jīng)常會(huì)有類似于如下的需求：

希望知道當(dāng)前集群中究竟有多少機(jī)器在工作。

對(duì)集群中每臺(tái)機(jī)器的運(yùn)行時(shí)狀態(tài)進(jìn)行數(shù)據(jù)收集。對(duì)集群中機(jī)器進(jìn)行上下線操作。

ZooKeeper 具有以下兩大特性:

客戶端如果對(duì)ZooKeeper 的一個(gè)數(shù)據(jù)節(jié)點(diǎn)注冊(cè) Watcher監(jiān)聽，那么當(dāng)該數(shù)據(jù)節(jié)點(diǎn)的內(nèi)容或是其子節(jié)點(diǎn)列表發(fā)生變更時(shí)，ZooKeeper服務(wù)器就會(huì)向已注冊(cè)訂閱的客戶端發(fā)送變更通知。對(duì)在ZooKeeper上創(chuàng)建的臨時(shí)節(jié)點(diǎn)，一旦客戶端與服務(wù)器之間的會(huì)話失效，那么該臨時(shí)節(jié)點(diǎn)也就被自動(dòng)清除。

Watcher（事件監(jiān)聽器）是 Zookeeper 中的一個(gè)很重要的特性。Zookeeper 允許用戶在指定節(jié)點(diǎn)上注冊(cè)一些 Watcher，并且在一些特定事件觸發(fā)的時(shí)候， ZooKeeper 服務(wù)端會(huì)將事件通知到感興趣的客戶端上去，該機(jī)制是 Zookeeper 實(shí)現(xiàn)分布式協(xié)調(diào)服務(wù)的重要特性。

ZooKeeper 服務(wù)流程

1. 生產(chǎn)者啟動(dòng)

2. 生產(chǎn)者注冊(cè)至zookeeper

3. 消費(fèi)者啟動(dòng)并訂閱頻道

4. zookeeper 通知消費(fèi)者事件

5. 消費(fèi)者調(diào)用生產(chǎn)者

6. 監(jiān)控中心負(fù)責(zé)統(tǒng)計(jì)和監(jiān)控服務(wù)狀態(tài)

3.zookeeper單機(jī)部署

官方文檔:https://zookeeper.apache.org/doc/r3.9.0/zookeeperStarted.html#sc_InstallingSingleMode

配置 Java 環(huán)境

官方依賴介紹? ZooKeeper: Because Coordinating Distributed Systems is a Zoo

案例: 安裝單機(jī) zookeeper

wget -P /usr/local/src https://mirrors.tuna.tsinghua.edu.cn/apache/zookeeper/stable/apache-zookeeper3.9.0-bin.tar.gz

tar xf /usr/local/src/apache-zookeeper-3.9.0-bin.tar.gz -C /usr/local/? ---解壓包

ln -s /usr/local/apache-zookeeper-3.9.0-bin /usr/local/zookeeper? ---做軟鏈接

echo 'PATH=/usr/local/zookeeper/bin:$PATH' > /etc/profile.d/zookeeper.sh? ---做環(huán)境變量

. /etc/profile.d/zookeeper.sh? ?---運(yùn)行環(huán)境變量

cp /usr/local/zookeeper/conf/zoo_sample.cfg /usr/local/zookeeper/conf/zoo.cfg ---做數(shù)據(jù)目錄

?

tickTime=2000? #"滴答時(shí)間"，用于配置Zookeeper中最小的時(shí)間單元長(zhǎng)度，單位毫秒，是其它時(shí)間配置的基礎(chǔ)

initLimit=10?? #初始化時(shí)間，包含啟動(dòng)和數(shù)據(jù)同步，其值是tickTime的倍數(shù)

syncLimit=5??? #正常工作，心跳監(jiān)測(cè)的時(shí)間間隔，其值是tickTime的倍數(shù)

dataDir=/tmp/zookeeper #配置Zookeeper服務(wù)存儲(chǔ)數(shù)據(jù)的目錄,基于安全,可以修改為dataDir=/usr/local/zookeeper/data

#dataLogdir=/usr/local/zookeeper/logs #可以指定日志路徑

clientPort=2181 #配置當(dāng)前Zookeeper服務(wù)對(duì)外暴露的端口，用戶客戶端和服務(wù)端建立連接會(huì)話

autopurge.snapRetainCount=3 #3.4.0中的新增功能：?jiǎn)⒂煤螅琙ooKeeper 自動(dòng)清除功能,會(huì)將只保留此最新3個(gè)快照和相應(yīng)的事務(wù)日志,并分別保留在dataDir 和dataLogDir中，刪除其余部分，默認(rèn)值為3,最小值為3

autopurge.purgeInterval=24? #3.4.0及之后版本，ZK提供了自動(dòng)清理日志和快照文件的功能，這個(gè)參數(shù)指定了清理頻率，單位是小時(shí)，需要配置一個(gè)1或更大的整數(shù)，默認(rèn)是 0，表示不開啟自動(dòng)清理功能

啟動(dòng) ZooKeeper

zkServer.sh start-foreground

zkServer.sh start

4.zookeeper集群部署

ZooKeeper集群用于解決單點(diǎn)和單機(jī)性能及數(shù)據(jù)高可用等問題

?

zookeeper集群基于Master/Slave的模型，處于主要地位(處理寫操作)的主機(jī)稱為Master節(jié)點(diǎn)，處于次要地位(處理讀操作)的主機(jī)稱為 slave節(jié)點(diǎn)，生產(chǎn)中讀取的方式一般是以異步復(fù)制方式來(lái)實(shí)現(xiàn)的。

對(duì)于n臺(tái)server,每個(gè)server都知道彼此的存在。只要有>n/2臺(tái)server節(jié)點(diǎn)可用，整個(gè)zookeeper系統(tǒng)保持可用。保證zookeep是基數(shù)節(jié)點(diǎn)，不可以為偶數(shù)

因此zookeeper集群通常由奇數(shù)臺(tái)Server節(jié)點(diǎn)組成

當(dāng)進(jìn)行寫操作時(shí),由leader完成,并且同步到其它follower節(jié)點(diǎn),當(dāng)在保證寫操作在所有節(jié)點(diǎn)的總數(shù)過半后,才會(huì)認(rèn)為寫操作成功

下圖表示讀的比例越高,性能越好

機(jī)器越多，寫性能就越差

集群角色?

?

領(lǐng)導(dǎo)者(Leader)??? 負(fù)責(zé)處理寫入請(qǐng)求的，事務(wù)請(qǐng)求的唯一調(diào)度和處理者,負(fù)責(zé)進(jìn)行投票發(fā)起和決議，更新系統(tǒng)狀態(tài)

跟隨者(Follower) ??接收客戶請(qǐng)求并向客戶端返回結(jié)果，在選Leader過程中參與投票

觀察者(Observer)?? 轉(zhuǎn)交客戶端寫請(qǐng)求給leader節(jié)點(diǎn)，和同步leader狀態(tài)

? ? ? ? ? ? ? ? ? ? ? ? ? ?和Follower唯一區(qū)別就是不參與Leader投票,也不參與寫操作的"過半寫成功"策略

學(xué)習(xí)者(Learner)??? 和leader進(jìn)行狀態(tài)同步的節(jié)點(diǎn)統(tǒng)稱Learner，包括:Follower和Observer

客戶端(client) ?????請(qǐng)求發(fā)起方

選舉過程

節(jié)點(diǎn)角色狀態(tài)：

LOOKING：尋找 Leader 狀態(tài)，處于該狀態(tài)需要進(jìn)入選舉流程

LEADING：領(lǐng)導(dǎo)者狀態(tài)，處于該狀態(tài)的節(jié)點(diǎn)說明是角色已經(jīng)是Leader

FOLLOWING：跟隨者狀態(tài)，表示 Leader已經(jīng)選舉出來(lái)，當(dāng)前節(jié)點(diǎn)角色是follower

OBSERVER：觀察者狀態(tài)，表明當(dāng)前節(jié)點(diǎn)角色是 observer

選舉 ID：

ZXID（zookeeper transaction id）：每個(gè)改變 Zookeeper狀態(tài)的操作都會(huì)形成一個(gè)對(duì)應(yīng)的zxid。

ZXID最大的節(jié)點(diǎn)優(yōu)先選為L(zhǎng)eader

myid：服務(wù)器的唯一標(biāo)識(shí)(SID)，通過配置 myid 文件指定，集群中唯一,當(dāng)ZXID一樣時(shí),myid大的節(jié)點(diǎn)優(yōu)先選為L(zhǎng)eader

ZooKeeper 集群選舉過程：

當(dāng)集群中的 zookeeper 節(jié)點(diǎn)啟動(dòng)以后，會(huì)根據(jù)配置文件中指定的 zookeeper節(jié)點(diǎn)地址進(jìn)行l(wèi)eader 選擇操作，過程如下：

每個(gè)zookeeper 都會(huì)發(fā)出投票，由于是第一次選舉leader，因此每個(gè)節(jié)點(diǎn)都會(huì)把自己當(dāng)做leader 角色進(jìn)行選舉，每個(gè)zookeeper 的投票中都會(huì)包含自己的myid和zxid，此時(shí)zookeeper 1 的投票為myid 為 1，初始zxid有一個(gè)初始值0x0，后期會(huì)隨著數(shù)據(jù)更新而自動(dòng)變化，zookeeper2 的投票為myid 為2，初始zxid 為初始生成的值。每個(gè)節(jié)點(diǎn)接受并檢查對(duì)方的投票信息，比如投票時(shí)間、是否狀態(tài)為L(zhǎng)OOKING狀態(tài)的投票。對(duì)比投票，優(yōu)先檢查zxid，如果zxid 不一樣則 zxid 大的為leader，如果zxid相同則繼續(xù)對(duì)比myid，myid 大的一方為 leader成為 Leader 的必要條件： Leader 要具有最高的zxid；當(dāng)集群的規(guī)模是 n 時(shí)，集群中大多數(shù)的機(jī)器（至少n/2+1）得到響應(yīng)并follower 選出的 Leader。

心跳機(jī)制：Leader 與 Follower 利用 PING 來(lái)感知對(duì)方的是否存活，當(dāng) Leader無(wú)法響應(yīng)PING 時(shí)，將重新發(fā)起 Leader 選舉。當(dāng) Leader 服務(wù)器出現(xiàn)網(wǎng)絡(luò)中斷、崩潰退出與重啟等異常情況時(shí)，ZAB(Zookeeper Atomic Broadcast) 協(xié)議就會(huì)進(jìn)入恢復(fù)模式并選舉產(chǎn)生新的Leader服務(wù)器。這個(gè)過程大致如下：

Leader Election（選舉階段）：節(jié)點(diǎn)在一開始都處于選舉階段，只要有一個(gè)節(jié)點(diǎn)得到超半數(shù)節(jié)點(diǎn)的票數(shù)，它就可以當(dāng)選準(zhǔn) leader。

Discovery（發(fā)現(xiàn)階段）：在這個(gè)階段，followers 跟準(zhǔn) leader 進(jìn)行通信，同步 followers 最近接收的事務(wù)提議。

Synchronization（同步階段）:同步階段主要是利用 leader 前一階段獲得的最新提議歷史，同步集群中所有的副本。同步完成之后 準(zhǔn) leader 才會(huì)成為真正的 leader。

Broadcast（廣播階段） ：到了這個(gè)階段，Zookeeper 集群才能正式對(duì)外提供事務(wù)服務(wù)，并且leader 可以進(jìn)行消息廣播。同時(shí)如果有新的節(jié)點(diǎn)加入，還需要對(duì)新節(jié)點(diǎn)進(jìn)行同步

ZAB 協(xié)議介紹

ZAB（ZooKeeper Atomic Broadcast 原子廣播） 協(xié)議是為分布式協(xié)調(diào)服務(wù) ZooKeeper 專門設(shè)計(jì)的一種支持崩潰恢復(fù)的原子廣播協(xié)議。 在 ZooKeeper 中，主要依賴 ZAB 協(xié)議來(lái)實(shí)現(xiàn)分布式數(shù)據(jù)一致性，基于該協(xié)議，ZooKeeper 實(shí)現(xiàn)了一種主備模式的系統(tǒng)架構(gòu)來(lái)保持集群中各個(gè)副本之間的數(shù)據(jù)一致性。

ZooKeeper 集群特性

整個(gè)集群中只要有超過集群數(shù)量一半的 zookeeper工作是正常的，那么整個(gè)集群對(duì)外就是可用的假如有 2 臺(tái)服務(wù)器做了一個(gè) Zookeeper 集群，只要有任何一臺(tái)故障或宕機(jī)，那么這個(gè) ZooKeeper集群就不可用了，因?yàn)槭Ｏ碌囊慌_(tái)沒有超過集群一半的數(shù)量，但是假如有三臺(tái)zookeeper 組成一個(gè)集群， 那么損壞一臺(tái)就還剩兩臺(tái)，大于 3臺(tái)的一半，所以損壞一臺(tái)還是可以正常運(yùn)行的，但是再損壞一臺(tái)就只剩一臺(tái)集群就不可用了。那么要是 4 臺(tái)組成一個(gè)zookeeper集群，損壞一臺(tái)集群肯定是正常的，那么損壞兩臺(tái)就還剩兩臺(tái)，那么2臺(tái)不大于集群數(shù)量的一半，所以 3 臺(tái)的 zookeeper 集群和 4 臺(tái)的 zookeeper集群損壞兩臺(tái)的結(jié)果都是集群不可用，以此類推 5 臺(tái)和 6 臺(tái)以及 7 臺(tái)和 8臺(tái)都是同理

另外偶數(shù)節(jié)點(diǎn)可以會(huì)造成"腦裂"現(xiàn)象,所以這也就是為什么集群一般都是奇數(shù)的原因。

ZooKeeper 集群部署

運(yùn)行腳本進(jìn)行安裝

配置文件和單機(jī)模式略微不同之處

?nc 訪問 ZooKeeper

ZooKeeper支持某些特定的四字命令字母與其的交互。它們大多是查詢命令，用來(lái)獲取 ZooKeeper服務(wù)的當(dāng)前狀態(tài)及相關(guān)信息。用戶在客戶端可以通過 netcat 或telnet向zookeeper發(fā)送下面命令

conf #輸出相關(guān)服務(wù)配置的詳細(xì)信息

cons #列出所有連接到服務(wù)器的客戶端的完全的連接/會(huì)話的詳細(xì)信息

envi #輸出關(guān)于服務(wù)環(huán)境的詳細(xì)信息

dump #列出未經(jīng)處理的會(huì)話和臨時(shí)節(jié)點(diǎn)

stat #查看哪個(gè)節(jié)點(diǎn)被選擇作為Follower或者Leader

ruok #測(cè)試是否啟動(dòng)了該Server，若回復(fù)imok表示已經(jīng)啟動(dòng)

mntr #輸出一些運(yùn)行時(shí)信息

reqs #列出未經(jīng)處理的請(qǐng)求

wchs #列出服務(wù)器watch的簡(jiǎn)要信息

wchc #通過session列出服務(wù)器watch的詳細(xì)信息

wchp #通過路徑列出服務(wù)器watch的詳細(xì)信息

srvr #輸出服務(wù)的所有信息

srst #重置服務(wù)器統(tǒng)計(jì)信息

kill #關(guān)掉Server

isro #查看該服務(wù)的節(jié)點(diǎn)權(quán)限信息

將所有四字命令加入白名單

vim conf/zoo.cfg

4lw.commands.whitelist=*

echo stat | nc 127.0.0.1 2181

?

?

改完之后重啟服務(wù)：systemctl restart zookeeper.service?

圖形化客戶端 ZooInspector

git clone GitHub - zzhang5/zooinspector: An improved zookeeper inspector?? 然后結(jié)合阿里云加速進(jìn)行mvn編譯即可使用

cd zooinspector/

mvn clean package -Dmaven.test.skip=true

chmod +x target/zooinspector-pkg/bin/zooinspector.sh

target/zooinspector-pkg/bin/zooinspector.sh

三、kafka

消息隊(duì)列歷史

2007 年的時(shí)候，Rabbit 技術(shù)公司基于Erlang語(yǔ)言開發(fā)了符合AMQP 規(guī)范RabbitMQ 1.0。

從最開始用在金融行業(yè)里面，現(xiàn)在MQ 已經(jīng)在世界各地的公司中遍地開花。國(guó)內(nèi)的絕大部分大廠都在用MQ，包括頭條，美團(tuán)，滴滴，去哪兒，藝龍，淘寶也有用。

kafka的數(shù)據(jù)是存儲(chǔ)到zookeep中的/目錄下，kafka嫁接在zookeep上，kafka的消息是分片的，

MQ 定義

在分布式場(chǎng)景中，相對(duì)于大量的用戶請(qǐng)求來(lái)說，內(nèi)部的功能主機(jī)之間、功能模塊之間等，數(shù)據(jù)傳遞的數(shù)據(jù)量是無(wú)法想象的，因?yàn)橐粋€(gè)用戶請(qǐng)求，會(huì)涉及到各種內(nèi)部的業(yè)務(wù)邏輯跳轉(zhuǎn)等操作。那么，在大量用戶的業(yè)務(wù)場(chǎng)景中，如何保證所有的內(nèi)部業(yè)務(wù)邏輯請(qǐng)求都處于穩(wěn)定而且快捷的數(shù)據(jù)傳遞呢? 消息隊(duì)列(Message Queue)技術(shù)可以滿足此需求

消息隊(duì)列（Message Queue，簡(jiǎn)稱 MQ）是構(gòu)建分布式互聯(lián)網(wǎng)應(yīng)用的基礎(chǔ)設(shè)施，通過 MQ 實(shí)現(xiàn)的松耦合架構(gòu)設(shè)計(jì)可以提高系統(tǒng)可用性以及可擴(kuò)展性，是適用于現(xiàn)代應(yīng)用的最佳設(shè)計(jì)方案。

消息隊(duì)列是一種異步的服務(wù)間通信方式，適用于無(wú)服務(wù)器和微服務(wù)架構(gòu)。消息在被處理和刪除之前一直存儲(chǔ)在隊(duì)列上。每條消息僅可被一位用戶處理一次。消息隊(duì)列可被用于分離重量級(jí)處理、緩沖或批處理工作以及緩解高峰期工作負(fù)載。

MQ 使用場(chǎng)合

消息隊(duì)列作為高并發(fā)系統(tǒng)的核心組件之一，能夠幫助業(yè)務(wù)系統(tǒng)結(jié)構(gòu)提升開發(fā)效率和系統(tǒng)穩(wěn)定性

消息隊(duì)列主要有以下應(yīng)用場(chǎng)景

削峰填谷

諸如電商業(yè)務(wù)中的秒殺、搶紅包、企業(yè)開門紅等大型活動(dòng)時(shí)皆會(huì)帶來(lái)較高的流量脈沖，或因沒做相應(yīng)的保護(hù)而導(dǎo)致系統(tǒng)超負(fù)荷甚至崩潰，或因限制太過導(dǎo)致請(qǐng)求大量失敗而影響用戶體驗(yàn)，消息隊(duì)列可提供削峰填谷的服務(wù)來(lái)解決該問題。

異步解耦

交易系統(tǒng)作為淘寶等電商的最核心的系統(tǒng)，每筆交易訂單數(shù)據(jù)的產(chǎn)生會(huì)引起幾百個(gè)下游業(yè)務(wù)系統(tǒng)的關(guān)注，包括物流、購(gòu)物車、積分、流計(jì)算分析等等，整體業(yè)務(wù)系統(tǒng)龐大而且復(fù)雜，消息隊(duì)列可實(shí)現(xiàn)異步通信和應(yīng)用解耦，確保主站業(yè)務(wù)的連續(xù)性。

順序收發(fā)

細(xì)數(shù)日常中需要保證順序的應(yīng)用場(chǎng)景非常多，例如證券交易過程時(shí)間優(yōu)先原則，交易系統(tǒng)中的訂單創(chuàng)建、支付、退款等流程，航班中的旅客登機(jī)消息處理等等。與先進(jìn)先出FIFO（First In First Out）原理類似，消息隊(duì)列提供的順序消息即保證消息FIFO。

分布式事務(wù)一致性（zookeep）

交易系統(tǒng)、支付紅包等場(chǎng)景需要確保數(shù)據(jù)的最終一致性，大量引入消息隊(duì)列的分布式事務(wù)，既可以實(shí)現(xiàn)系統(tǒng)之間的解耦，又可以保證最終的數(shù)據(jù)一致性。

大數(shù)據(jù)分析

數(shù)據(jù)在“流動(dòng)”中產(chǎn)生價(jià)值，傳統(tǒng)數(shù)據(jù)分析大多是基于批量計(jì)算模型，而無(wú)法做到實(shí)時(shí)的數(shù)據(jù)分析，利用消息隊(duì)列與流式計(jì)算引擎相結(jié)合，可以很方便的實(shí)現(xiàn)業(yè)務(wù)數(shù)據(jù)的實(shí)時(shí)分析。

分布式緩存同步

電商的大促，各個(gè)分會(huì)場(chǎng)琳瑯滿目的商品需要實(shí)時(shí)感知價(jià)格變化，大量并發(fā)訪問數(shù)據(jù)庫(kù)導(dǎo)致會(huì)場(chǎng)頁(yè)面響應(yīng)時(shí)間長(zhǎng)，集中式緩存因帶寬瓶頸，限制了商品變更的訪問流量，通過消息隊(duì)列構(gòu)建分布式緩存，實(shí)時(shí)通知商品數(shù)據(jù)的變化

蓄流壓測(cè)

線上有些鏈路不方便做壓力測(cè)試，可以通過堆積一定量消息再放開來(lái)壓測(cè)

消息隊(duì)列在測(cè)試環(huán)境做壓測(cè)，先不在生產(chǎn)環(huán)境上線

主流 MQ

目前主流的消息隊(duì)列軟件有 kafka、RabbitMQ、ActiveMQ、RocketMQ等，還有相對(duì)小眾的消息隊(duì)列軟件如ZeroMQ、Apache Qpid 等。

kafka不能做集群，但是可以基于zookeep做集群

Kafka 介紹

Kafka 被稱為下一代分布式消息系統(tǒng)，由 Scala 和 Java編寫，是非營(yíng)利性組織ASF(Apache Software Foundation)基金會(huì)中的一個(gè)開源項(xiàng)目，比如:HTTP Server、Tomcat、Hadoop、ActiveMQ等開源軟件都屬于 Apache基金會(huì)的開源軟件，類似的消息系統(tǒng)還有RabbitMQ、ActiveMQ、ZeroMQ。

Kafka用于構(gòu)建實(shí)時(shí)數(shù)據(jù)管道和流應(yīng)用程序。 它具有水平可伸縮性，容錯(cuò)性，快速性，可在數(shù)千家組織中同時(shí)投入生產(chǎn)協(xié)同工作。

Kafka 特點(diǎn)和優(yōu)勢(shì)

特點(diǎn)

分布式: 多機(jī)實(shí)現(xiàn),不允許單機(jī)

分區(qū): 一個(gè)消息.可以拆分出多個(gè)，分別存儲(chǔ)在多個(gè)位置

多副本: 防止信息丟失，可以多來(lái)幾個(gè)備份

多訂閱者: 可以有很多應(yīng)用連接kafka，在kafka中沒有嚴(yán)格的說法，都叫訂閱者

Zookeeper: 早期版本的Kafka依賴于zookeeper， 2021年4月19日Kafka 2.8.0正式發(fā)布，此版本包括了很多重要改動(dòng)，最主要的是kafka通過自我管理的仲裁來(lái)替代ZooKeeper，即Kafka將不再需要ZooKeeper！

優(yōu)勢(shì)

Kafka 通過 O(1)的磁盤數(shù)據(jù)結(jié)構(gòu)提供消息的持久化，這種結(jié)構(gòu)對(duì)于即使數(shù)以 TB 級(jí)別以上的消息存儲(chǔ)也能夠保持長(zhǎng)時(shí)間的穩(wěn)定性能。

高吞吐量：即使是非常普通的硬件Kafka也可以支持每秒數(shù)百萬(wàn)的消息。支持通過Kafka 服務(wù)器分區(qū)消息。

分布式： Kafka 基于分布式集群實(shí)現(xiàn)高可用的容錯(cuò)機(jī)制，可以實(shí)現(xiàn)自動(dòng)的故障轉(zhuǎn)移

順序保證：在大多數(shù)使用場(chǎng)景下，數(shù)據(jù)處理的順序都很重要。大部分消息隊(duì)列本來(lái)就是排序的，并且能保證數(shù)據(jù)會(huì)按照特定的順序來(lái)處理。 Kafka保證一個(gè)Partiton內(nèi)的消息的有序性（分區(qū)間數(shù)據(jù)是無(wú)序的，如果對(duì)數(shù)據(jù)的順序有要求，應(yīng)將在創(chuàng)建主題時(shí)將分區(qū)數(shù)partitions設(shè)置為1）

支持 Hadoop 并行數(shù)據(jù)加載

通常用于大數(shù)據(jù)場(chǎng)合,傳遞單條消息比較大，而Rabbitmq （支持單條小消息）消息主要是傳輸業(yè)務(wù)的指令數(shù)據(jù),單條數(shù)據(jù)較小，不適合集群化大規(guī)模的場(chǎng)景

Kafka 角色

Producer：Producer即生產(chǎn)者，消息的產(chǎn)生者，是消息的入口。負(fù)責(zé)發(fā)布消息到Kafka broker。

Consumer：消費(fèi)者，用于消費(fèi)消息，即處理消息

Consumer group: 每個(gè)consumer 屬于一個(gè)特定的consumer group（可為每個(gè)consumer 指定 group name，若不指定 group name 則屬于默認(rèn)的group），使用 consumer high level API 時(shí)，同一topic的一條消息只能被同一個(gè)consumer group 內(nèi)的一個(gè)consumer 消費(fèi)，但多個(gè)consumer group 可同時(shí)消費(fèi)這一消息。

Broker：Broker是kafka實(shí)例，每個(gè)服務(wù)器上可以有一個(gè)或多個(gè)kafka的實(shí)例，假設(shè)每個(gè)broker對(duì)應(yīng)一臺(tái)服務(wù)器。每個(gè)kafka集群內(nèi)的broker都有一個(gè)不重復(fù)的編號(hào)，如: broker-0、broker-1等……

Topic ：消息的主題，可以理解為消息的分類，相當(dāng)于Redis的Key和ES中的索引，kafka的數(shù)據(jù)就保存在topic。在每個(gè)broker上都可以創(chuàng)建多個(gè)topic。物理上不同 topic 的消息分開存儲(chǔ)在不同的文件夾，邏輯上一個(gè) topic的消息雖然保存于一個(gè)或多個(gè)broker 上, 但用戶只需指定消息的topic即可生產(chǎn)或消費(fèi)數(shù)據(jù)而不必關(guān)心數(shù)據(jù)存于何處，topic 在邏輯上對(duì)record(記錄、日志)進(jìn)行分組保存，消費(fèi)者需要訂閱相應(yīng)的topic 才能消費(fèi)topic中的消息。

Replication: 同樣數(shù)據(jù)的副本，包括leader和follower的副本數(shù),基本于數(shù)據(jù)安全,建議至少2個(gè),是Kafka的高可靠性的保障，和ES不同的，ES中的副本數(shù)不包括主分片數(shù)

Partition ：是物理上的概念，每個(gè)topic 分割為一個(gè)或多個(gè)partition，即一個(gè)topic切分為多份.創(chuàng)建topic時(shí)可指定 parition 數(shù)量，partition的表現(xiàn)形式就是一個(gè)一個(gè)的文件夾,該文件夾下存儲(chǔ)該partition的數(shù)據(jù)和索引文件，分區(qū)的作用還可以實(shí)現(xiàn)負(fù)載均衡，提高kafka的吞吐量。同一個(gè)topic在不同的分區(qū)的數(shù)據(jù)是不重復(fù)的,一般Partition數(shù)不要超過節(jié)點(diǎn)數(shù)據(jù)，注意同一個(gè)partition數(shù)據(jù)是有順序的，但不同的partition則是無(wú)序的。為了實(shí)現(xiàn)數(shù)據(jù)的高可用，比如將分區(qū) 0 的數(shù)據(jù)分散到不同的kafka 節(jié)點(diǎn)，每一個(gè)分區(qū)都有一個(gè) broker 作為 Leader 和一個(gè) broker 作為Follower，類似于ES中的主分片和副本分片，

AR： Assigned Replicas，分區(qū)中的所有副本的統(tǒng)稱，AR= lSR+ OSR

lSR：ln Sync Replicas，所有與leader副本保持同步的副本 follower和leader本身組成的集合，是AR的子集

OSR：out-of-Sync Replied，所有與leader副本同步不能同步的 follower的集合，是AR的子集

分區(qū)的優(yōu)勢(shì)：

實(shí)現(xiàn)存儲(chǔ)空間的橫向擴(kuò)容，即將多個(gè)kafka服務(wù)器的空間結(jié)合利用提升性能，多服務(wù)器讀寫

實(shí)現(xiàn)高可用，分區(qū)leader 分布在不同的kafka 服務(wù)器，假設(shè)分區(qū)因子為 3, 分區(qū) 0 的leader為服務(wù)器A，則服務(wù)器 B 和服務(wù)器 C 為 A 的follower，而分區(qū) 1 的leader為服務(wù)器B，則服務(wù)器 A 和C 為服務(wù)器B 的follower，而分區(qū) 2 的leader 為C，則服務(wù)器A 和 B 為C 的follower。

假如設(shè)置一個(gè)wang的topic,它會(huì)生成多個(gè)目錄，在第一臺(tái)機(jī)器上有兩個(gè)目錄，一個(gè)存主本，一個(gè)存副本；第二個(gè)機(jī)器有兩個(gè)目錄，一個(gè)存主本，一個(gè)存副本；第三個(gè)機(jī)器有兩個(gè)目錄，都存副本。交叉是為了防止崩，這樣做可以保證數(shù)據(jù)的高可用

Kafka 寫入消息的流程

Kafka 部署

當(dāng)前版本 Kafka 依賴 Zookeeper 服務(wù),但以后將不再依賴

環(huán)境說明

#在三個(gè)節(jié)點(diǎn)提前部署zookeeper和kafka三個(gè)節(jié)點(diǎn)復(fù)用

node1:192.168.10.110

node2:192.168.10.110

node3:192.168.10.110

注意:生產(chǎn)中zookeeper和kafka一般是分開獨(dú)立部署的,kafka安裝前需要安裝java環(huán)境；確保三個(gè)節(jié)點(diǎn)的zookeeper啟動(dòng)

Kafka 節(jié)點(diǎn)配置

配置文件說明

#配置文件 ./conf/server.properties內(nèi)容說明

############################# Server Basics###############################

# broker的id，值為整數(shù)，且必須唯一，在一個(gè)集群中不能重復(fù)

broker.id=1

############################# Socket ServerSettings ######################

# kafka監(jiān)聽端口，默認(rèn)9092

listeners=PLAINTEXT://10.0.0.101:9092

# 處理網(wǎng)絡(luò)請(qǐng)求的線程數(shù)量，默認(rèn)為3個(gè)

num.network.threads=3

# 執(zhí)行磁盤IO操作的線程數(shù)量，默認(rèn)為8個(gè)

num.io.threads=8

# socket服務(wù)發(fā)送數(shù)據(jù)的緩沖區(qū)大小，默認(rèn)100KB

socket.send.buffer.bytes=102400

# socket服務(wù)接受數(shù)據(jù)的緩沖區(qū)大小，默認(rèn)100KB

socket.receive.buffer.bytes=102400

# socket服務(wù)所能接受的一個(gè)請(qǐng)求的最大大小，默認(rèn)為100M

socket.request.max.bytes=104857600

############################# Log Basics###################################

# kafka存儲(chǔ)消息數(shù)據(jù)的目錄

log.dirs=../data

# 每個(gè)topic默認(rèn)的partition

num.partitions=1

# 設(shè)置副本數(shù)量為3,當(dāng)Leader的Replication故障，會(huì)進(jìn)行故障自動(dòng)轉(zhuǎn)移。

default.replication.factor=3

# 在啟動(dòng)時(shí)恢復(fù)數(shù)據(jù)和關(guān)閉時(shí)刷新數(shù)據(jù)時(shí)每個(gè)數(shù)據(jù)目錄的線程數(shù)量

num.recovery.threads.per.data.dir=1

############################# Log FlushPolicy #############################

# 消息刷新到磁盤中的消息條數(shù)閾值

log.flush.interval.messages=10000

# 消息刷新到磁盤中的最大時(shí)間間隔,1s

log.flush.interval.ms=1000

############################# Log RetentionPolicy #########################

# 日志保留小時(shí)數(shù)，超時(shí)會(huì)自動(dòng)刪除，默認(rèn)為7天

log.retention.hours=168

# 日志保留大小，超出大小會(huì)自動(dòng)刪除，默認(rèn)為1G

#log.retention.bytes=1073741824

# 日志分片策略，單個(gè)日志文件的大小最大為1G，超出后則創(chuàng)建一個(gè)新的日志文件

log.segment.bytes=1073741824

# 每隔多長(zhǎng)時(shí)間檢測(cè)數(shù)據(jù)是否達(dá)到刪除條件,300s

log.retention.check.interval.ms=300000

############################# Zookeeper ####################################

# Zookeeper連接信息，如果是zookeeper集群，則以逗號(hào)隔開

zookeeper.connect=192.168.10.110:2181,192.168.10.120:2181,192.168.10.130:2181

# 連接zookeeper的超時(shí)時(shí)間,6s

zookeeper.connection.timeout.ms=6000

Kafka 讀寫數(shù)據(jù)?

kafka-topics.sh # 消息的管理命令

kafka-console-producer.sh?? #生產(chǎn)者的模擬命令

kafka-console-consumer.sh?? #消費(fèi)者的模擬命令

創(chuàng)建 Topic

創(chuàng)建名為 wang，partitions(分區(qū))為3，replication(每個(gè)分區(qū)的副本數(shù)/每個(gè)分區(qū)的分區(qū)因子)為 2 的topic(主題)

/usr/local/kafka/bin/kafka-topics.sh --create --topic wang --bootstrap-server 192.168.10.110:9092 --partitions 3 --replication-factor 2

#? 在各節(jié)點(diǎn)上觀察生成的相關(guān)數(shù)據(jù)

ls /usr/local/kafka/data/

#? 獲取所有 Topic

/usr/local/kafka/bin/kafka-topics.sh --list --bootstrap-server 192.168.10.110:9092

#? 驗(yàn)證 Topic 詳情

/usr/local/kafka/bin/kafka-topics.sh --describe --bootstrapserver 192.168.10.110:9092 --topic wang

#? 生產(chǎn) Topic

/usr/local/kafka/bin/kafka-console-producer.sh --broker-list 192.168.10.110:9092,192.168.10.120:9092,192.168.10.130:9092 --topic wang

#? 消費(fèi) Topic

/usr/local/kafka/bin/kafka-console-consumer.sh --topic wang --bootstrap-server 192.168.10.110:9092 --from-beginning

#? 刪除 Topic

/usr/local/kafka/bin/kafka-topics.sh --delete --bootstrap-server 192.168.10.110:2181,192.168.10.120:2181,192.168.10.130:2181 --topic wang

?

創(chuàng)建消息

?在toplic中生產(chǎn)一下對(duì)應(yīng)的生產(chǎn)消息

?消費(fèi)消息

刪除wang這條消息

如何在應(yīng)用程序中關(guān)聯(lián)kafka

首先基于filebeat從應(yīng)用/web端將數(shù)據(jù)先收集進(jìn)來(lái)，然后將數(shù)據(jù)先放入kafka中，然后將其適當(dāng)?shù)姆制瑀edis做緩存，kafka做消息，然后將基于logstash的INPUT模塊去關(guān)聯(lián)kafka，把kafka/redis中消息消費(fèi)出來(lái)，然后輸出值es中

柚子快報(bào)邀請(qǐng)碼778899分享：架構(gòu) 微服務(wù)和kafka

http://yzkb.51969.com/

推薦鏈接