//cloud.tencent.買粉絲/document/proct/845/19549 。
在6.5版本官方推出了CCR功能之后,集群間數據同步的難題就迎刃而解了。可以利用CCR來實現ES集群的異地容災:
CCR是類似于數據訂閱的方式,主集群為Leader, 備集群為Follower, 備集群以pull的方式從主集群拉取數據和寫請求;在定義好Follwer Index時,Follwer Index會進行初始化,從Leader中以snapshot的方式把底層的segment文件全量同步過來,初始化完成之后,再拉取寫請求,拉取完寫請求后,Follwer側進行重放,完成數據的同步。CCR的優點當然是因為可以同步UPDATE/DELETE操作,數據一致性問題解決了,同步延時也減小了。
另外,基于CCR可以和前面提到的跨機房容災的集群結合,實現兩地多中心的ES集群。在上海地域,部署有多可用區集群實現跨機房的高可用,同時在北京地域部署備集群作為Follwer利用CCR同步數據,從而在集群可用性上又向前走了一步,既實現了同城跨機房容災,又實現了跨地域容災。
但是在出現故障時需要把集群的訪問從上海切換到北京時,會有一些限制,因為CCR中的Follwer Index是只讀的,不能寫入,需要切換為正常的索引才能進行寫入,過程也是不可逆的。不過在業務側進行規避,比如寫入時使用新的正常的索引,業務使用別名進行查詢,當上海地域恢復時,再反向的把數據同步回去。
現在問題就是保證上海地域集群數據的完整性,在上海地域恢復后,可以在上海地域新建一個Follower Index,以北京地域正在進行寫的索引為Leader同步數據,待數據完全追平后,再切換到上海地域進行讀寫,注意切換到需要新建Leader索引寫入數據。
數據同步過程如下所示:
1.上海主集群正常提供服務,北京備集群從主集群Follow數據
2.上海主集群故障,業務切換到北京備集群進行讀寫,上海主集群恢復后從北京集群Follow數據
目前Kafka數據導入ClickHouse的常用方案有兩種,一種是通過ClickHouse內置的Kafka表引擎實現,另一種是借助數據流組件,如Logstash。
以下會分別介紹這兩種方案。
Kafka表引擎基于librdkafka庫實現與Kafka的通信,但它只充當一個數據管道的角色,負責拉取Kafka中的數據;所以還需要一張物化視圖將Kafka引擎表中的數據實時同步到本地MergeTree系列表中。
為了提高性能,接受的消息被分組為 maxinsertblocksize 大小(由kafkamax_block_size參數空值,默認值為65536)的塊。如果未在 streamflushinterval_ms 毫秒(默認500 ms)內形成塊,則不關心塊的完整性,都會將數據刷新到表中。
相關配置參數:
買粉絲s://github.買粉絲/edenhill/librdkafka/blob/master/CONFIGURATION.md
1)部署Kafka
2)創建Kafka引擎表
必選參數:
可選參數:
3)創建數據表
使用已有的數據表,以下只給出了分布表的創建語句。
4)創建物化視圖
與Elasticsearch寫入類似,通過Logstash的ClickHouse插件,訂閱Kafka中的數據并寫入CH中。其中,ClickHouse插件調用HTTP接口完成數據寫入。
1)部署Logstash
部署Logstash,并安裝ClickHouse插件:
2)創建Logstash配置文件
相關參數:
3)啟動Logstash
Kafka引擎表和Logstash都是常見的數據導入方式,
一、消息隊列概述
消息隊列中間件是分布式系統中重要的組件,主要解決應用耦合,異步消息,流量削鋒等問題。實現高性能,高可用,可伸縮和最終一致性架構。是大型分布式系統不可缺少的中間件。
目前在生產環境,使用較多的消息隊列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ等。
二、消息隊列應用場景
以下介紹消息隊列在實際應用中常用的使用場景。異步處理,應用解耦,流量削鋒和消息通訊四個場景。
2.1異步處理
場景說明:用戶注冊后,需要發注冊郵件和注冊短信。傳統的做法有兩種1.串行的方式;2.并行方式。
(1)串行方式:將注冊信息寫入數據庫成功后,發送注冊郵件,再發送注冊短信。以上三個任務全部完成后,返回給客戶端。(架構KKQ:466097527,歡迎加入)
(2)并行方式:將注冊信息寫入數據庫成功后,發送注冊郵件的同時,發送注冊短信。以上三個任務完成后,返回給客戶端。與串行的差別是,并行的方式可以提高處理的時間。
假設三個業務節點每個使用50毫秒鐘,不考慮網絡等其他開銷,則串行方式的時間是150毫秒,并行的時間可能是100毫秒。
因為CPU在單位時間內處理的請求數是一定的,假設CPU1秒內吞吐量是100次。則串行方式1秒內CPU可處理的請求量是7次(1000/150)。并行方式處理的請求量是10次(1000/100)。
小結:如以上案例描述,傳統的方式系統的性能(并發量,吞吐量,響應時間)會有瓶頸。如何解決這個問題呢?
引入消息隊列,將不是必須的業務邏輯,異步處理。改造后的架構如下:
按照以上約定,用戶的響應時間相當于是注冊信息寫入數據庫的時間,也就是50毫秒。注冊郵件,發送短信寫入消息隊列后,直接返回,因此寫入消息隊列的速度很快,基本可以忽略,因此用戶的響應時間可能是50毫秒。因此架構改變后,系統的吞吐量提高到每秒20 QPS。比串行提高了3倍,比并行提高了兩倍。
2.2應用解耦
場景說明:用戶下單后,訂單系統需要通知庫存系統。傳統的做法是,訂單系統調用庫存系統的接口。如下圖:
傳統模式的缺點:
1) 假如庫存系統無法訪問,則訂單減庫存將失敗,從而導致訂單失敗;
2) 訂單系統與庫存系統耦合;
如何解決以上問題呢?引入應用消息隊列后的方案,如下圖:
訂單系統:用戶下單后,訂單系統完成持久化處理,將消息寫入消息隊列,返回用戶訂單下單成功。
庫存系統:訂閱下單的消息,采用拉/推的方式,獲取下單信息,庫存系統根據下單信息,進行庫存操作。
假如:在下單時庫存系統不能正常使用。也不影響正常下單,因為下單后,訂單系統寫入消息隊列就不再關心其他的后續操作了。實現訂單系統與庫存系統的應用解耦。
2.3流量削鋒
流量削鋒也是消息隊列中的常用場景,一般在秒殺或團搶活動中使用廣泛。
應用場景:秒殺活動,一般會因為流量過大,導致流量暴增,應用掛掉。為解決這個問題,一般需要在應用前端加入消息隊列。
可以控制活動的人數;
可以緩解短時間內高流量壓垮應用;
用戶的請求,服務器接收后,首先寫入消息隊列。假如消息隊列長度超過最大數量,則直接拋棄用戶請求或跳轉到錯誤頁面;
秒殺業務根據消息隊列中的請求信息,再做后續處理。
2.4日志處理
日志處理是指將消息隊列用在日志處理中,比如Kafka的應用,解決大量日志傳輸的問題。架構簡化如下:
日志采集客戶端,負責日志數據采集,定時寫受寫入Kafka隊列;
Kafka消息隊列,負責日志數據的接收,存儲和轉發;
日志處理應用:訂閱并消費kafka隊列中的日志數據;
以下是新浪kafka日志處理應用案例:
(1)Kafka:接收用戶日志的消息隊列。
(2)Logstash:做日志解析,統一成JSON輸出給Elasticsearch。
(3)Elasticsearch:實時日志分析服務的核心技術,一個schemaless,實時的數據存儲服務,通過index組織數據,兼具強大的搜索和統計功能。
(4)Kibana:基于Elasticsearch的數據可視化組件,超強的數據可視化能力是眾多公司選擇ELK stack的重要原因。
2.5消息通訊
消息通訊是指,消息隊列一般都內置了高效的通信機制,因此也可以用在純的消息通訊。比如實現點對點消息隊列,或者聊天室等。
點對點通訊:
客戶端A和客戶端B使用同一隊列,進行消息通訊。
聊天室通訊:
客戶端A,客戶端B,客戶端N訂閱同一主題,進行消息發布和接收。實現類似聊天室效果。
以上實際是消息隊列的兩種消息模式,點對點或發布訂閱模式。模型為示意圖,供參考。
三、消息中間件示例
3.1電商系統
消息隊列采用高可用,可持久化的消息中間件。比如Active MQ,Rabbit MQ,Rocket Mq。(1)應用將主干邏輯處理完成后,寫入消息隊列。消息發送是否成功可以開啟消息的確認模式。(消息隊列返回消息接收成功狀態后,應用再返回,這樣保障消息的完整性)
(2)擴展流程(發短信,配送處理)訂閱隊列消息。采用推或拉的方式獲取消息并處理。
(3)消息將應用解耦的同時,帶來了數據一致性問題,可以采用最終一致性方式解決。比如主數據寫入數據庫,擴展應用根據消息隊列,并結合數據庫方式實現基于消息隊列的后續處理。
3.2日志收集系統
分為Zookeeper注冊中心,日志收集客戶端,Kafka集群和Storm集群(OtherApp)四部分組成。
Zookeeper注冊中心,提出負載均衡和地址查找服務;
日志收集客戶端,用于采集應用系統的日志,并將數據推送到kafka隊列;
四、JMS消息服務
講消息隊列就不得不提JMS 。JMS(Java Message Service,Java消息服務)API是一個消息服務的標準/規范,允許應用程序組件基于JavaEE平臺創建、發送、接收和讀取消息。它使分布式通信耦合度更低,消息服務更加可靠以及異步性。
在EJB架構中,有消息bean可以無縫的與JM消息服務集成。在J2EE架構模式中,有消息服務者模式,用于實現消息與應用直接的解耦。
4.1消息模型
在JMS標準中,有兩種消息模型P2P(Point to Point),Publish/Subscribe(Pub/Sub)。
4.1.1 P2P模式
P2P模式包含三個角色:消息隊列(Queue),發送者(Sender),接收者(Receiver)。每個消息都被發送到一個特定的隊列,接收者從隊列中獲取消息。隊列保留著消息,直到他們被消費或超時。
P2P的特點
每個消息只有一