国产 无码 综合区,色欲AV无码国产永久播放,无码天堂亚洲国产AV,国产日韩欧美女同一区二区

APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐

這篇具有很好參考價(jià)值的文章主要介紹了APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐。希望對(duì)大家有所幫助。如果存在錯(cuò)誤或未考慮完全的地方,請(qǐng)大家不吝賜教,您也可以點(diǎn)擊"舉報(bào)違法"按鈕提交疑問(wèn)。

一分鐘精華速覽

分布式鏈路追蹤系統(tǒng)在企業(yè)的APM體系中扮演著重要的角色。本文分享了去哪兒旅行構(gòu)建分布式鏈路追蹤系統(tǒng)的實(shí)踐經(jīng)驗(yàn)。從APM整體架構(gòu)設(shè)計(jì)入手,講述了日志收集、Kafka傳輸和Flink任務(wù)處理等環(huán)節(jié)的性能優(yōu)化實(shí)踐和踩坑經(jīng)驗(yàn)。

同時(shí),作者結(jié)合豐富的分布式系統(tǒng)架構(gòu)經(jīng)驗(yàn),探討了APM系統(tǒng)和Trace數(shù)據(jù)的價(jià)值。通過(guò)閱讀本文,你將了解到去哪兒旅行在構(gòu)建APM體系中所面臨的挑戰(zhàn),并學(xué)習(xí)如何應(yīng)對(duì)這些挑戰(zhàn),實(shí)現(xiàn)更高效的性能監(jiān)控和管理。 APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐,容量治理 作者介紹

APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐,容量治理

去哪兒旅行基礎(chǔ)平臺(tái)架構(gòu)師——王 鵬 TakinTalks穩(wěn)定性社區(qū)專家團(tuán)成員。畢業(yè)于大連理工大學(xué),10年以上大型分布式基礎(chǔ)架構(gòu)經(jīng)驗(yàn),專注于大型分布式基礎(chǔ)架構(gòu)和大數(shù)據(jù)處理領(lǐng)域。曾就職于58集團(tuán),主要負(fù)責(zé)58到家基礎(chǔ)架構(gòu)工作。后進(jìn)入去哪兒旅行,負(fù)責(zé)分布式鏈路追蹤系統(tǒng)的建設(shè)以及APM體系的搭建。在大數(shù)據(jù)、高并發(fā)的場(chǎng)景有豐富的經(jīng)驗(yàn)。

溫馨提醒:本文約7000字,預(yù)計(jì)花費(fèi)10分鐘閱讀。

TakinTalks穩(wěn)定性社區(qū),公眾號(hào)后臺(tái)回復(fù) “交流” 進(jìn)入讀者交流群;回復(fù)“1012”獲取課件資料;

背景

APM并不是一個(gè)新的概念。從2012年到2016年,市場(chǎng)上涌現(xiàn)了許多開(kāi)源的APM組件,如SkyWalking、Jaeger等??梢哉f(shuō),在過(guò)去幾年中,隨著技術(shù)的發(fā)展和系統(tǒng)的復(fù)雜性增加,分布式鏈路追蹤系統(tǒng)和應(yīng)用性能管理(APM)已成為許多公司不可或缺的工具。

大多數(shù)公司都會(huì)根據(jù)其技術(shù)棧和業(yè)務(wù)體系來(lái)構(gòu)建自己的APM體系和分布式鏈路追蹤系統(tǒng)。以去哪兒旅行為例,我們的主要業(yè)務(wù)涉及搜索查詢和電子商務(wù)交易等領(lǐng)域。由于業(yè)務(wù)體系的不同,在技術(shù)選擇、方案設(shè)計(jì)方面可能存在一些差異。

在構(gòu)建和應(yīng)用APM體系的過(guò)程中,去哪兒遇到了許多挑戰(zhàn)。例如,在日志收集、Kafka傳輸以及Flink任務(wù)處理等環(huán)節(jié)遇到了一些問(wèn)題。這次會(huì)分享如何克服這些性能瓶頸,以及在這個(gè)過(guò)程中積累的經(jīng)驗(yàn)和教訓(xùn),希望這些經(jīng)驗(yàn)對(duì)其他公司在解決類似問(wèn)題時(shí)能夠有所幫助。

一、APM整體架構(gòu)是如何設(shè)計(jì)的?

作為一個(gè)OTA交易平臺(tái),去哪兒旅行的業(yè)務(wù)系統(tǒng)分為搜索和下單交易部分。從流量來(lái)看不會(huì)特別大,OTA的交易量無(wú)法與零售電商交易相比。因此,去哪兒在構(gòu)建APM體系上與其他電商公司可能存在一些不同。例如,大多數(shù)公司APM的Trace部分采用采樣策略,但對(duì)我們來(lái)說(shuō),每一次請(qǐng)求、每一次查詢或者每一次交易,尤其是交易鏈路的Trace非常少,每天幾百萬(wàn)的交易量,產(chǎn)生的Trace不會(huì)太多。因此,最終采用了交易鏈路全采樣的技術(shù)方案。

此外,從2020年開(kāi)始,全公司技術(shù)棧之前的虛擬機(jī)模式轉(zhuǎn)向了云原生的開(kāi)發(fā)架構(gòu)。在這三年中,從應(yīng)用層、開(kāi)發(fā)層和容器層,都已經(jīng)完成了遷移。在遷移完成后,需要將可觀測(cè)性的相關(guān)體系遷移到云上,或者說(shuō)適配云原生的開(kāi)發(fā)環(huán)境。

在構(gòu)建APM體系的早期,由于眾多開(kāi)源技術(shù)尚未出現(xiàn),進(jìn)行了大量的自研工作。例如,早期我們依賴自研的Java中間件記錄Trace。但現(xiàn)在,開(kāi)源社區(qū)已經(jīng)提供了許多優(yōu)秀的方案,可以根據(jù)公司環(huán)境、階段和技術(shù)路線做出合理的選擇。

經(jīng)過(guò)技術(shù)分析與選型后,去哪兒旅行的APM體系采用插樁Agent模式和中間件埋點(diǎn)并行的方式(如圖)。其中,紅色部分是重點(diǎn)改造部分。

APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐,容量治理

(去哪兒旅行APM體系整體架構(gòu))

首先,左上部分主要是如何記錄和獲取Trace信息。部分中間件以硬編碼的方式獲取Trace數(shù)據(jù),另外,一些開(kāi)源的第三方組件通過(guò)Agent模式獲取了Trace。

其次,關(guān)于如何收集這些數(shù)據(jù),去哪兒旅行采用了開(kāi)源的Apache Flume日志收集組件,并對(duì)其進(jìn)行了一系列改造。改造的原因是原生組件并未提供如配置管理功能、限流控制等一些必要的功能。

第三,處理層的任務(wù)非常繁重,選擇了Flink作為數(shù)據(jù)處理任務(wù)框架。數(shù)據(jù)處理不僅需要實(shí)時(shí)處理Trace的詳細(xì)數(shù)據(jù),還需要存儲(chǔ)并分析出的Trace異常、后置采樣、鏈路分析等等。

最后,Metrics部分則是一個(gè)標(biāo)準(zhǔn)的收集和處理流程,通過(guò)Statsd將數(shù)據(jù)存儲(chǔ)到時(shí)序DB,最終有Prometheus + Grafana去展示。

總的來(lái)說(shuō),去哪兒旅行的APM體系整體架構(gòu)設(shè)計(jì)結(jié)合了開(kāi)源技術(shù)和自研成果,以實(shí)現(xiàn)更高效的性能監(jiān)控和管理。

二、遇到了哪些“坑”?

2.1 日志收集組件的性能瓶頸優(yōu)化

在Trace數(shù)據(jù)收集過(guò)程中,確實(shí)存在許多挑戰(zhàn)。由于許多業(yè)務(wù)和監(jiān)控系統(tǒng)基于Trace和Metrics來(lái)判斷是否發(fā)出告警,因此這種收集需要比離線日志更實(shí)時(shí)。然而,這也意味著它們需要在保持高性能的同時(shí),保證不會(huì)影響宿主機(jī)的性能,這是一個(gè)非常大的挑戰(zhàn)。

2.1.1 問(wèn)題表現(xiàn):Trace數(shù)據(jù)中斷

APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐,容量治理

在對(duì)系統(tǒng)進(jìn)行改造前,發(fā)現(xiàn)有大量的Trace出現(xiàn)了數(shù)據(jù)中斷的問(wèn)題。這種問(wèn)題表現(xiàn)為Trace的某些部分(比如Span ID為1.4和1.4.2的部分)突然消失,而后面的部分(比如Span ID為1.5)又突然出現(xiàn)。這種情況可能由兩種原因?qū)е?,一種是中間件里沒(méi)有這部分?jǐn)?shù)據(jù),另一種是中間件里有數(shù)據(jù)但是沒(méi)有傳送過(guò)來(lái)。無(wú)論是哪種原因,都需要對(duì)系統(tǒng)進(jìn)行深入地分析。

2.1.2 抽樣分析:日志組件和配置問(wèn)題

嘗試把以上問(wèn)題拆解成可視化的指標(biāo),以便于理解和處理它。首先,查看了整個(gè)Trace的問(wèn)題比例,可以通過(guò)圖上的監(jiān)控看到Trace中斷率達(dá)到了驚人的70%~80%。這個(gè)結(jié)果說(shuō)明大部分的Trace數(shù)據(jù)都存在問(wèn)題。

APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐,容量治理 為了進(jìn)一步確定問(wèn)題的原因,我們對(duì)100個(gè)問(wèn)題數(shù)據(jù)進(jìn)行了抽樣分析。分析結(jié)果顯示,有一半的問(wèn)題是日志收集組件的問(wèn)題,也就是Qflume組件的問(wèn)題;另一部分問(wèn)題則是配置問(wèn)題,即沒(méi)有正確配置數(shù)據(jù)收集,導(dǎo)致數(shù)據(jù)沒(méi)有被收集到。除此之外,還存在一些其他的問(wèn)題。

對(duì)于配置問(wèn)題,可以通過(guò)統(tǒng)一刷新配置來(lái)解決。

而對(duì)于日志收集組件的問(wèn)題,則需要進(jìn)行更深入的分析和改造。首先需要對(duì)其內(nèi)部工作流程進(jìn)行了解。從左到右,這個(gè)流程圖展示了日志處理過(guò)程。

APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐,容量治理

在最左側(cè),業(yè)務(wù)應(yīng)用通過(guò)異步隊(duì)列將日志輸出到磁盤文件。這個(gè)隊(duì)列的長(zhǎng)度是有限的,用來(lái)控制內(nèi)存占用。如果隊(duì)列滿了,新的日志就會(huì)被丟棄。這就是日志丟失的一個(gè)原因。

還有其他兩個(gè)瓶頸——一個(gè)是系統(tǒng)通過(guò)單線程同步讀取日志,這個(gè)讀取速度跟不上日志生成的速度。另一個(gè)是系統(tǒng)使用同步發(fā)送Kafka來(lái)傳輸日志。

2.1.3 優(yōu)化效果

為了解決這些問(wèn)題,采取了兩個(gè)措施。首先,增加了異步隊(duì)列的長(zhǎng)度,但是也不能讓它過(guò)長(zhǎng),以免消耗過(guò)多的內(nèi)存。其次,將單線程讀取改為批量讀取,每次讀取一個(gè)批次的日志。此外,還將同步發(fā)送改為Kafka異步發(fā)送,發(fā)送完一批日志后立馬發(fā)送下一批,這樣可以大大的提高吞吐量。

APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐,容量治理

這樣優(yōu)化后,分鐘級(jí)傳輸?shù)臄?shù)據(jù)量有了顯著的提升,可以達(dá)到每分鐘80億甚至100億條數(shù)據(jù)量。

2.1.4 踩坑點(diǎn)1:傳輸失敗率大幅提高

問(wèn)題描述: 盡管解決了日志組件的性能問(wèn)題,可以快速地讀取和發(fā)送數(shù)據(jù)。然而,隨之而來(lái)的問(wèn)題是Kafka的數(shù)據(jù)量非常不穩(wěn)定,呈現(xiàn)出明顯的波動(dòng)。

APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐,容量治理

原因分析: 在查看相關(guān)數(shù)據(jù)后,發(fā)現(xiàn)了一個(gè)嚴(yán)重問(wèn)題:頻繁的內(nèi)存溢出(OOM)。這個(gè)問(wèn)題的原因在于,優(yōu)化后的日志組件以批量的方式讀取數(shù)據(jù),這會(huì)占用大量的內(nèi)存。如果內(nèi)存不足,就會(huì)發(fā)生OOM。

APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐,容量治理

一種解決這個(gè)問(wèn)題的方法是增大內(nèi)存,但這并不是一個(gè)長(zhǎng)久之計(jì),因?yàn)橘Y源有限,不能無(wú)限制地增加內(nèi)存。另外,Trace日志的實(shí)時(shí)性要求并不像業(yè)務(wù)那么高,晚幾秒甚至十幾秒都是可以接受的,只要數(shù)據(jù)最終能夠傳輸過(guò)去就可以。

如何解決? 解決思路是在保證高性能的前提下,對(duì)數(shù)據(jù)傳輸進(jìn)行限流,讓日志組件在一個(gè)可控的內(nèi)存使用范圍內(nèi)高效的工作。

APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐,容量治理

限流方案包括設(shè)定時(shí)間窗口和對(duì)單條日志大小做限制。在設(shè)定時(shí)間窗口的方法中,時(shí)間窗口是滑動(dòng)時(shí)間窗口,也可以是一條日志的處理時(shí)間。比如設(shè)置時(shí)間窗口為一秒、兩秒或五秒,然后規(guī)定在這個(gè)時(shí)間窗口內(nèi),限制數(shù)據(jù)傳輸?shù)拇笮?,比如不能超過(guò)200M。

盡管設(shè)置了時(shí)間窗口,但日志組件仍可能會(huì)出現(xiàn)OOM的問(wèn)題。原因在于有些日志非常大,一條日志就有幾兆甚至幾十兆。這種情況雖然不合理,但卻確實(shí)存在。如果遇到這樣的日志傳輸過(guò)來(lái),很可能會(huì)導(dǎo)致服務(wù)癱瘓。因此,團(tuán)隊(duì)還需要對(duì)單條日志的大小進(jìn)行限制,如果日志過(guò)長(zhǎng),就需要進(jìn)行截?cái)嗵幚怼?/p>

另外,如果出現(xiàn)OOM,團(tuán)隊(duì)也需要進(jìn)行斷點(diǎn)續(xù)傳的工作。不能重新傳輸已經(jīng)傳輸過(guò)的Trace,因?yàn)檫@樣會(huì)造成大量的資源浪費(fèi),且重復(fù)傳輸本身也是有問(wèn)題的。

通過(guò)這些限制,就可以保證堆內(nèi)存的使用不會(huì)超過(guò)限制,同時(shí)保持日志組件的高性能。

2.1.5 踩坑點(diǎn)2:接口耗時(shí)增長(zhǎng),吞吐量下降

問(wèn)題描述:

在解決日志組件內(nèi)存溢出問(wèn)題之后,又遇到了新的挑戰(zhàn):業(yè)務(wù)線反饋接口耗時(shí)突然大幅上升,吞吐量大幅下降,甚至有些業(yè)務(wù)應(yīng)用被操作系統(tǒng)直接終止,導(dǎo)致故障出現(xiàn)。這個(gè)問(wèn)題在一開(kāi)始是令人困惑的,因?yàn)橐呀?jīng)解決了OOM的問(wèn)題,并且對(duì)內(nèi)存使用進(jìn)行了嚴(yán)格的限制。怎會(huì)出現(xiàn)影響業(yè)務(wù)系統(tǒng)的情況呢?

原因分析:

在排查問(wèn)題時(shí),發(fā)現(xiàn)有問(wèn)題的服務(wù)器上,CPU利用率非常高,達(dá)到197%,內(nèi)存的使用率也非常高,幾乎已經(jīng)沒(méi)有剩余空間。那么,這是由什么原因引起的呢?回顧之前做的優(yōu)化工作,發(fā)現(xiàn)在優(yōu)化日志傳輸?shù)牟襟E中,將Kafka的發(fā)送操作變成了異步發(fā)送。而在異步發(fā)送過(guò)程中,會(huì)大量占用堆外內(nèi)存。

之前針對(duì)堆內(nèi)內(nèi)存做了限制,但是對(duì)堆外內(nèi)存并沒(méi)有做限制。如果Kafka大量發(fā)送數(shù)據(jù),但是由于某些原因傳輸不過(guò)來(lái),那么這些數(shù)據(jù)就需要放在堆外內(nèi)存中等待發(fā)送。這就是導(dǎo)致內(nèi)存使用率高漲,最后操作系統(tǒng)終止業(yè)務(wù)進(jìn)程。

如何解決?

那么,如何限制堆外內(nèi)存的大小呢?或者說(shuō),如何限制進(jìn)程使用的內(nèi)存空間呢?

從Docker這個(gè)容器技術(shù)中找到了靈感。熟悉Docker都知道,Docker容器中使用的資源是固定的,包括磁盤空間、CPU以及內(nèi)存等,不能超過(guò)容器在初始時(shí)分配的大小。那么,Docker是如何實(shí)現(xiàn)這個(gè)功能的呢?

這就涉及到CGroup技術(shù),也就是Linux內(nèi)核提供的控制組(Control Group)技術(shù)。CGroup技術(shù)主要用于限制和隔離進(jìn)程組應(yīng)用的物理資源,簡(jiǎn)單來(lái)說(shuō),可以通過(guò)CGroup技術(shù)將硬件資源切分成很多塊,并對(duì)每一塊資源設(shè)定使用限制,進(jìn)程和其產(chǎn)生的子進(jìn)程都不能超過(guò)這個(gè)限制。

通過(guò)CGroup技術(shù),限制進(jìn)程的堆外內(nèi)存使用和CPU使用,保證它們都在一個(gè)合理的范圍之內(nèi)。

2.1.6 優(yōu)化效果

CGroup進(jìn)行資源限制后,系統(tǒng)的效率得到了顯著提升。Root失敗率從原來(lái)的80%降低到了20%,優(yōu)化效果十分明顯。

APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐,容量治理

2.2 高并發(fā)下Kafka集群傳輸優(yōu)化

在解決了日志收集問(wèn)題,資源使用得到了限制之后,大量的日志被發(fā)送到了Kafka集群,然后Kafka集群再將日志傳輸給Flink任務(wù)進(jìn)行處理。這就引出了新的問(wèn)題:如何保證Kafka集群能夠高效穩(wěn)定地傳輸日志?

2.2.1 問(wèn)題表現(xiàn)

隨著日志收集客戶端在全公司范圍內(nèi)的推廣,大約有1萬(wàn)多個(gè)實(shí)例部署,Kafka集群開(kāi)始出現(xiàn)了不穩(wěn)定的情況。Kafka集群會(huì)出現(xiàn)大量的連接失敗,整個(gè)的數(shù)據(jù)接收量和發(fā)送量都會(huì)急劇下降。在這期間并沒(méi)有對(duì)集群做任何改動(dòng),收集組件也沒(méi)有做任何改動(dòng),但是卻頻繁出現(xiàn)這種不穩(wěn)定問(wèn)題。

APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐,容量治理

2.2.2 問(wèn)題分析

通過(guò)查看了Kafka集群的監(jiān)控,發(fā)現(xiàn)網(wǎng)絡(luò)空閑連接和線程數(shù)急劇下降。這可能是導(dǎo)致Kafka集群連接失敗,數(shù)據(jù)傳輸量下降的主要原因。

APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐,容量治理

在Kafka的架構(gòu)中,客戶端首先與網(wǎng)絡(luò)接收線程組進(jìn)行連接,發(fā)送日志數(shù)據(jù)。網(wǎng)絡(luò)接收線程組在接收到數(shù)據(jù)后,將任務(wù)轉(zhuǎn)發(fā)給RequestQueue進(jìn)行處理。 APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐,容量治理

Processor處理器的主要工作是將請(qǐng)求放入請(qǐng)求通道隊(duì)列(RequestChannel)。理論上,處理器的空閑量應(yīng)該較大,因?yàn)槠涔ぷ鞑⒉粡?fù)雜,僅僅是進(jìn)行內(nèi)存操作,將網(wǎng)絡(luò)接收的任務(wù)提交到隊(duì)列。然而,監(jiān)控?cái)?shù)據(jù)卻顯示處理器的空閑數(shù)急劇下降,變得非常繁忙,并沒(méi)有足夠的空閑鏈接去處理網(wǎng)絡(luò)請(qǐng)求。

進(jìn)一步分析,發(fā)現(xiàn)請(qǐng)求處理器(KafkaReuestHandler)從請(qǐng)求通道隊(duì)列中取出任務(wù)進(jìn)行處理,主要是將請(qǐng)求寫入磁盤。如果請(qǐng)求處理器處理不過(guò)來(lái),請(qǐng)求通道隊(duì)列的數(shù)據(jù)就會(huì)逐漸增多。當(dāng)隊(duì)列滿時(shí),新的請(qǐng)求無(wú)法進(jìn)入,導(dǎo)致網(wǎng)絡(luò)連接空閑數(shù)急劇下降。

綜合以上所述,問(wèn)題可能出在Kafka的請(qǐng)求處理器這一環(huán)節(jié)。主要可能是內(nèi)存不足或者刷盤速度不夠快。進(jìn)一步檢查后,發(fā)現(xiàn)確實(shí)有些機(jī)器的內(nèi)存不夠,有些機(jī)器的刷盤速度有問(wèn)題,甚至有些磁盤已經(jīng)損壞,導(dǎo)致部分機(jī)器的性能急劇下降。

2.2.3 優(yōu)化效果

將有問(wèn)題的機(jī)器從集群中移除,并增大了內(nèi)存。經(jīng)過(guò)這些優(yōu)化,整個(gè)Kafka集群恢復(fù)了正常狀態(tài)。

APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐,容量治理

(正常狀態(tài)下的集群)

優(yōu)化后的效果明顯,Kafka集群的收發(fā)狀態(tài)保持在一個(gè)正常的水平。在約1分鐘的時(shí)間里,可以收發(fā)1.7億多條數(shù)據(jù)。而且,根據(jù)業(yè)務(wù)的波峰波谷,數(shù)據(jù)的收發(fā)呈現(xiàn)出穩(wěn)定的狀態(tài),不再出現(xiàn)以前的陡增陡降的情況。

2.3 百萬(wàn)級(jí)QPS數(shù)據(jù)處理任務(wù)優(yōu)化

在數(shù)據(jù)處理過(guò)程中,任務(wù)這一環(huán)節(jié)是最核心的部分。在對(duì)比了Spark和Flink的流式處理后,發(fā)現(xiàn)后者更適合Trace場(chǎng)景。Flink任務(wù)本身也比較復(fù)雜,如何能保證它的高可靠和高性能?

2.3.1 數(shù)據(jù)處理任務(wù)

數(shù)據(jù)存儲(chǔ)量的QPS400w左右,峰值1000w。數(shù)據(jù)進(jìn)入任務(wù)首先進(jìn)行反序列化,之后開(kāi)始實(shí)時(shí)計(jì)算業(yè)務(wù)線的拓?fù)?、異常Trace拓?fù)?、Metrics和Trace關(guān)聯(lián)關(guān)系等。

APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐,容量治理

另一個(gè)重要的任務(wù)是存儲(chǔ)。每秒幾百GB的日志存儲(chǔ)到存儲(chǔ)介質(zhì)中,有HBase、ES、ClickHouse等存儲(chǔ)介質(zhì)。這些存儲(chǔ)還有一些關(guān)聯(lián)數(shù)據(jù),這些關(guān)聯(lián)數(shù)據(jù)需要拆分。例如,有很多Metrics和Trace的關(guān)聯(lián)數(shù)據(jù),需要先將它們解析出來(lái),然后做分布式的存儲(chǔ),將它們存入數(shù)據(jù)庫(kù)。這些計(jì)算都是在Flink的任務(wù)里面完成的。

2.3.2 Flink任務(wù)拆分

APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐,容量治理

上圖是一個(gè)大任務(wù),整個(gè)數(shù)據(jù)打散后分給不同的子任務(wù)去處理。這種方式有一個(gè)問(wèn)題,如果某個(gè)子任務(wù)處理速度較慢,會(huì)產(chǎn)生一些背壓。背壓會(huì)繼續(xù)向上反映到總的任務(wù)分發(fā)環(huán)節(jié)。分發(fā)環(huán)節(jié)處理速度慢,所有任務(wù)的處理速度也會(huì)變慢。所以,一個(gè)小任務(wù)出問(wèn)題,就導(dǎo)致整個(gè)鏈路出問(wèn)題。

APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐,容量治理

因此,將一些不關(guān)聯(lián)的Trace任務(wù)進(jìn)行拆分,而不是讓它們耦合在一起。這樣做可以大大降低問(wèn)題的發(fā)生概率。

2.3.3 背壓如何解決?

背壓(Back Pressure)是流控制中的一種策略,主要用于保護(hù)系統(tǒng)在高負(fù)載情況下的穩(wěn)定性。當(dāng)下游處理速度跟不上,上游數(shù)據(jù)輸入的速度時(shí),就會(huì)發(fā)生背壓,這就像水管出水口被堵住,壓力太大后就可能會(huì)導(dǎo)致水管崩裂。

解決背壓可以從以下幾個(gè)方面著手:

觀察Flink任務(wù)中子任務(wù)的消費(fèi)是否均勻。Flink任務(wù)會(huì)被分解為子任務(wù),子任務(wù)會(huì)被分配到不同的機(jī)器上執(zhí)行。如果某些高耗CPU或者高耗IO的任務(wù)集中在同一臺(tái)機(jī)器,會(huì)導(dǎo)致該機(jī)器的處理能力不足,從而影響整個(gè)任務(wù)的處理速度。因此,需要關(guān)注子任務(wù)的消費(fèi)均勻性,并嘗試調(diào)整資源的分配,使其更加均衡。 關(guān)注上下游算子的內(nèi)存是否充足。如果輸出算子的內(nèi)存不足,可能會(huì)導(dǎo)致輸入算子的數(shù)據(jù)無(wú)法正常傳遞。因此,需要通過(guò)內(nèi)存監(jiān)控,并合理設(shè)置不同算子的內(nèi)存大小。 盡量使用內(nèi)存的Map來(lái)替代Window。雖然Window可以保證數(shù)據(jù)的完整性,但在某些情況下,并不需要這么強(qiáng)的一致性,更多的時(shí)候只是對(duì)數(shù)據(jù)緩存,使用內(nèi)存的Map可以極大的節(jié)省內(nèi)存消耗。

善用Shared Group。Filter一定小心下游算子的擁堵導(dǎo)致全面的擁堵,Shared Group可以將頻繁進(jìn)行網(wǎng)絡(luò)傳輸?shù)乃阕臃诺揭粋€(gè)JVM內(nèi),這樣可以極大的節(jié)省網(wǎng)絡(luò)資源和計(jì)算資源。

2.3.4 優(yōu)化效果

通過(guò)優(yōu)化背壓?jiǎn)栴},平均寫入達(dá)到400萬(wàn)QPS,平均寫入耗時(shí)在600ms左右,這是一個(gè)非常不錯(cuò)的性能表現(xiàn)。

APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐,容量治理

三、如何看到APM和Trace數(shù)據(jù)的價(jià)值?

3.1 APM系統(tǒng)有哪些作用?

當(dāng)系統(tǒng)經(jīng)過(guò)幾年的發(fā)展,可能會(huì)變得雜亂無(wú)章,各個(gè)系統(tǒng)之間的聯(lián)系混亂不堪。在這樣的情況下,可能對(duì)系統(tǒng)的運(yùn)行邏輯一頭霧水,更別說(shuō)從這個(gè)混亂的拓?fù)渲姓页鰡?wèn)題所在。而APM系統(tǒng)的作用就是幫助理清這些混亂的聯(lián)系,然后指出可能出現(xiàn)問(wèn)題的地方。與僅有監(jiān)控系統(tǒng)相比,APM系統(tǒng)可以更清晰地定位問(wèn)題所在,這是一個(gè)巨大的價(jià)值點(diǎn)。

APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐,容量治理

(APM系統(tǒng)讓查問(wèn)題變得更簡(jiǎn)單)

3.2 Trace與Metrics怎么關(guān)聯(lián)

在業(yè)界很多并沒(méi)有關(guān)注Metrics和Trace的關(guān)聯(lián)關(guān)系,常見(jiàn)的做法是根據(jù)時(shí)間進(jìn)行隨機(jī)關(guān)聯(lián)。然而,這樣的關(guān)聯(lián)性并不強(qiáng)。因此,根據(jù)去哪兒的業(yè)務(wù)情況進(jìn)行了一些改進(jìn)。

針對(duì)三類指標(biāo)進(jìn)行分析:一類是Time類的指標(biāo),一類是Count類的指標(biāo),另一類是Rate類的指標(biāo)。

1、Time類指標(biāo):假如一種操作的耗時(shí)是最長(zhǎng)的,那么這種操作肯定是存在問(wèn)題的。所以這類指標(biāo)我們只取Top10即可。

2、Count類指標(biāo):處理方式會(huì)相對(duì)復(fù)雜一些,因?yàn)樗婕暗降臉I(yè)務(wù)概念較多。采用了隨機(jī)策略,比如在記錄某個(gè)指標(biāo)時(shí),無(wú)法將所有的Metrics與Trace的關(guān)聯(lián)關(guān)系全部記錄下來(lái),只需要隨機(jī)抽取一部分進(jìn)行記錄就可以了。另外一種策略是:報(bào)警策略,假如某個(gè)指標(biāo)出現(xiàn)報(bào)警,那么在這段時(shí)間內(nèi)這個(gè)指標(biāo)存在問(wèn)題的概率是非常大的,所以會(huì)提高采樣率,為了更可能命中存在問(wèn)題的Trace。還有一種策略是:關(guān)鍵詞策略,比如定義了一些業(yè)務(wù)異常,這種情況下,會(huì)進(jìn)行全采樣,因?yàn)檫@種Trace的價(jià)值非常大,例如ERRO FAILED EXCEPTION 等關(guān)鍵詞。

3、Rate類指標(biāo):處理起來(lái)會(huì)更為困難。因?yàn)镽ate類指標(biāo)往往是兩個(gè)數(shù)的比值,比如成功率和失敗率。這些指標(biāo)上升還好,但是如果下降,那么可能是因?yàn)闆](méi)有Trace關(guān)聯(lián)。所以對(duì)于Rate類指標(biāo),只能關(guān)注上升的情況。

在實(shí)際操作中,發(fā)現(xiàn)研發(fā)同學(xué)非常喜歡使用這個(gè)功能,因?yàn)榇蠹抑灰訄?bào)警就能找到問(wèn)題的Trace。以前要找這個(gè)問(wèn)題的Trace就需要在日志和代碼中反復(fù)查找,非常費(fèi)勁。而有了這個(gè)功能,他們只需要設(shè)置一個(gè)報(bào)警,只要出現(xiàn)問(wèn)題,他們就能找到對(duì)應(yīng)的Trace,這大大節(jié)省了排查問(wèn)題的時(shí)間。

3.3 Trace作為基礎(chǔ)底座如何應(yīng)用

作為一個(gè)基礎(chǔ)功能,Trace在很多公司都有廣泛的應(yīng)用,可以在其基礎(chǔ)上進(jìn)行許多工作?;赥race的高連通性,通過(guò)上下文傳遞來(lái)降低整個(gè)調(diào)用量。例如,在用戶中心的接口中,調(diào)用量通常非常大。如果不合理在上下層或同級(jí)之間進(jìn)行多次調(diào)用,用戶中心的調(diào)用量就會(huì)指數(shù)級(jí)增加。

如果能夠獲取Trace的上下文,那么在短時(shí)間內(nèi),一個(gè)Trace內(nèi)的用戶數(shù)據(jù)的變化可能非常小。絕大部分?jǐn)?shù)據(jù)是固定的,例如User ID。通過(guò)傳遞Trace的上下文,可以指數(shù)級(jí)別降低其調(diào)用量。在一個(gè)Trace內(nèi),調(diào)用次數(shù)可以被限制在幾百次以內(nèi)。如果通過(guò)上下文傳遞,只需要調(diào)用一次就夠了。這種優(yōu)化的方法在實(shí)際應(yīng)用中是可行的,還可以結(jié)合其他的技術(shù),比如將大量訪問(wèn)頻繁的數(shù)據(jù)存儲(chǔ)在緩存中,以降低信息在傳輸層的大小。

另外,Trace的高連通性對(duì)于混沌工程和全鏈路壓力測(cè)試非常重要。全鏈路壓力測(cè)試是基于Trace的連通性的。在進(jìn)行灰度環(huán)境的壓力測(cè)試時(shí),不允許將整個(gè)壓力施加到線上,以免造成故障。如何確保只在灰度鏈路內(nèi)進(jìn)行測(cè)試而不影響線上環(huán)境?這就是基于Trace的高連通性。高連通性意味著的鏈路拓?fù)鋺?yīng)該是一個(gè)全連通集的子集,不允許出現(xiàn)調(diào)用跳轉(zhuǎn)到線上的情況,如果出現(xiàn)則表明壓力測(cè)試的拓?fù)涫怯袉?wèn)題,需要終止。

此外,如果出現(xiàn)無(wú)法覆蓋整個(gè)Trace的情況,可以在網(wǎng)絡(luò)層面進(jìn)行攔截。在整個(gè)網(wǎng)絡(luò)拓?fù)渲?,不允許請(qǐng)求外部的線上機(jī)器或服務(wù)。如果有請(qǐng)求到線上機(jī)器或服務(wù)的情況,可以進(jìn)行攔截,終止壓力測(cè)試。

3.4 Trace數(shù)據(jù)有哪些價(jià)值

基于Trace的連通性,通過(guò)分析Trace數(shù)據(jù),可以了解整個(gè)鏈路的性能瓶頸和熱點(diǎn),從而給業(yè)務(wù)線提出優(yōu)化建議。

基于超時(shí)時(shí)間的鏈路拓?fù)浞治?,發(fā)現(xiàn)配置不合理的點(diǎn),是否有環(huán)裝調(diào)用 在分布式服務(wù)中,通常使用RPC框架(如Double或GRPC)進(jìn)行通信。在早期,這些框架需要手動(dòng)配置節(jié)點(diǎn)的超時(shí)時(shí)間。例如,上游的超時(shí)配置為1秒,下游的超時(shí)配置為3秒,這是一個(gè)不合理的配置,因?yàn)樯嫌我呀?jīng)在1秒之后超時(shí)了,下游的超時(shí)時(shí)間設(shè)置并沒(méi)有意義。這種不合理的配置可能出現(xiàn)在分布式系統(tǒng)中的許多節(jié)點(diǎn)中,難以尋找和識(shí)別。

通過(guò)分析每個(gè)請(qǐng)求的耗時(shí)數(shù)據(jù),可以將RPC框架的超時(shí)時(shí)間拿出來(lái),并對(duì)上下游配置進(jìn)行分析,從而發(fā)現(xiàn)不合理的配置。這樣,可以確定哪些超時(shí)配置是不合理的,以前很難解決的問(wèn)題現(xiàn)在可以通過(guò)鏈路分析發(fā)現(xiàn)。一旦我們找到這些點(diǎn),可以避免由于超時(shí)配置不合理導(dǎo)致的故障。

基于請(qǐng)求耗時(shí)占比,分析性能瓶頸 通常情況下,某個(gè)請(qǐng)求中會(huì)有一個(gè)或多個(gè)函數(shù)的耗時(shí)占比非常高。 APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐,容量治理

APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐,容量治理

通過(guò)觀察圖中的Span ID,某個(gè)請(qǐng)求的耗時(shí)占比超過(guò)了48%。如果某個(gè)函數(shù)的耗時(shí)占比過(guò)大,這可能是由于它本身的執(zhí)行速度較慢,或者它的實(shí)現(xiàn)方式存在問(wèn)題。這個(gè)函數(shù)可能成為整個(gè)鏈路的瓶頸,影響整體性能。在這種情況下,可以考慮將該函數(shù)改為異步操作,或者拆分為并行的請(qǐng)求,以幫助業(yè)務(wù)線提高性能。

基于同層并發(fā)請(qǐng)求重復(fù)次數(shù)占比,分析代碼不合理調(diào)用。 有時(shí)候我們會(huì)在同層中重復(fù)調(diào)用某個(gè)接口,例如在某個(gè)地方調(diào)用了應(yīng)用中心,又在另一個(gè)地方調(diào)用了應(yīng)用中心,然后在下一層又調(diào)用了應(yīng)用中心,這種重復(fù)調(diào)用是完全不合理的。

APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐,容量治理

在同層的情況下,這樣的調(diào)用可能會(huì)達(dá)到幾十次甚至上百次,這顯然是沒(méi)有必要的??赡苡行┩瑢W(xué)會(huì)說(shuō),只是把編寫好的代碼復(fù)制粘貼過(guò)來(lái),沒(méi)有去分析它的邏輯,長(zhǎng)此以往,這些重復(fù)調(diào)用會(huì)導(dǎo)致系統(tǒng)性能下降。

這些是我簡(jiǎn)單列舉的一些Trace數(shù)據(jù)有價(jià)值的點(diǎn),在實(shí)際過(guò)程中,它的應(yīng)用價(jià)值遠(yuǎn)不止這些。也歡迎大家開(kāi)放探討和交流。

四、總結(jié)展望

在構(gòu)建整個(gè)APM體系過(guò)程中,三個(gè)主要組件:日志收集組件、傳輸鏈路治理以及Flink任務(wù)性能優(yōu)化。日志收集組件和傳輸鏈路治理主要解決日志大流量和并發(fā)的問(wèn)題。在日志組件中,關(guān)注內(nèi)部和外部?jī)?nèi)存的限制。在傳輸層,關(guān)注任務(wù)調(diào)度和集群性能優(yōu)化。

最后,分析了APM系統(tǒng)的價(jià)值和意義。每家企業(yè)都建設(shè)自己的APM系統(tǒng),同時(shí)更需要深入挖掘其價(jià)值。APM系統(tǒng)的真正意義在于能夠通過(guò)數(shù)據(jù)客觀深入了解系統(tǒng)的性能。通過(guò)APM系統(tǒng),可以優(yōu)化系統(tǒng)的性能、提高用戶體驗(yàn)、減少故障和降低潛在風(fēng)險(xiǎn)。

Q&A

1、直播遷移到Docker 和使用CGroup 技術(shù)的成本怎么評(píng)估的?

2、如何及時(shí)發(fā)現(xiàn)未被監(jiān)控的指標(biāo)項(xiàng),避免未被觀測(cè)的指標(biāo)突變引發(fā)故障?

3、接口偶發(fā)性超時(shí),調(diào)用鏈只能看到超時(shí)接口名稱,看不到內(nèi)部方法,無(wú)法定位根因,也難以復(fù)現(xiàn),怎么辦?

以上問(wèn)題答案,歡迎點(diǎn)擊“閱讀全文”,觀看完整版解答!

本文由博客一文多發(fā)平臺(tái) OpenWrite 發(fā)布!文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-743162.html

到了這里,關(guān)于APM建設(shè)踩了哪些坑?去哪兒旅行分布式鏈路追蹤系統(tǒng)實(shí)踐的文章就介紹完了。如果您還想了解更多內(nèi)容,請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章,希望大家以后多多支持TOY模板網(wǎng)!

本文來(lái)自互聯(lián)網(wǎng)用戶投稿,該文觀點(diǎn)僅代表作者本人,不代表本站立場(chǎng)。本站僅提供信息存儲(chǔ)空間服務(wù),不擁有所有權(quán),不承擔(dān)相關(guān)法律責(zé)任。如若轉(zhuǎn)載,請(qǐng)注明出處: 如若內(nèi)容造成侵權(quán)/違法違規(guī)/事實(shí)不符,請(qǐng)點(diǎn)擊違法舉報(bào)進(jìn)行投訴反饋,一經(jīng)查實(shí),立即刪除!

領(lǐng)支付寶紅包贊助服務(wù)器費(fèi)用

相關(guān)文章

  • 什么是Python爬蟲分布式架構(gòu),可能遇到哪些問(wèn)題,如何解決

    什么是Python爬蟲分布式架構(gòu),可能遇到哪些問(wèn)題,如何解決

    目錄 什么是Python爬蟲分布式架構(gòu) 1. 調(diào)度中心(Scheduler): 2. 爬蟲節(jié)點(diǎn)(Crawler Node): 3. 數(shù)據(jù)存儲(chǔ)(Data Storage): 4. 反爬蟲處理(Anti-Scraping): 5. 分布式通信和協(xié)調(diào)(Communication and Coordination): Python爬蟲分布式架構(gòu)代碼示例 1. 調(diào)度中心(scheduler.py): 2. 爬蟲節(jié)點(diǎn)(crawl

    2024年02月10日
    瀏覽(21)
  • 【分布式】分布式鎖

    【分布式】分布式鎖

    單機(jī)多線程: 在 Java 中,我們通常使用 ReetrantLock 類、synchronized 這類 本地鎖 來(lái)控制一個(gè) JVM 進(jìn)程內(nèi)的多個(gè)線程對(duì)本地共享資源的訪問(wèn) 分布式系統(tǒng): 不同的服務(wù)/客戶端通常運(yùn)行在獨(dú)立的 JVM 進(jìn)程上。如果 多個(gè) JVM 進(jìn)程共享同一份資源 的話,使用本地鎖就沒(méi)辦法實(shí)現(xiàn)資

    2024年02月14日
    瀏覽(27)
  • 分布式系統(tǒng)中的分布式鏈路追蹤與分布式調(diào)用鏈路

    本文分享自天翼云開(kāi)發(fā)者社區(qū)《分布式系統(tǒng)中的分布式鏈路追蹤與分布式調(diào)用鏈路》,作者:c****w 在分布式系統(tǒng)中,由于服務(wù)間的調(diào)用關(guān)系復(fù)雜,需要實(shí)現(xiàn)分布式鏈路追蹤來(lái)跟蹤請(qǐng)求在各個(gè)服務(wù)中的調(diào)用路徑和時(shí)間消耗。這對(duì)問(wèn)題排查和性能監(jiān)控都很重要。 常用的分布式鏈

    2024年01月19日
    瀏覽(29)
  • 【分布式】分布式ID

    【分布式】分布式ID

    分布式場(chǎng)景下,一張表可能分散到多個(gè)數(shù)據(jù)結(jié)點(diǎn)上。因此需要一些分布式ID的解決方案。 分布式ID需要有幾個(gè)特點(diǎn): 全局唯一(必要) :在多個(gè)庫(kù)的主鍵放在一起也不會(huì)重復(fù) 有序(必要) :避免頻繁觸發(fā)索引重建 信息安全 :ID連續(xù),可以根據(jù)訂單編號(hào)計(jì)算一天的單量,造成

    2024年02月07日
    瀏覽(29)
  • 【分布式】分布式存儲(chǔ)架構(gòu)

    【分布式】分布式存儲(chǔ)架構(gòu)

    說(shuō)到分布式存儲(chǔ),我們先來(lái)看一下傳統(tǒng)的存儲(chǔ)是怎么個(gè)樣子。 傳統(tǒng)的存儲(chǔ)也稱為集中式存儲(chǔ), 從概念上可以看出來(lái)是具有集中性的,也就是整個(gè)存儲(chǔ)是集中在一個(gè)系統(tǒng)中的,但集中式存儲(chǔ)并不是一個(gè)單獨(dú)的設(shè)備,是集中在一套系統(tǒng)當(dāng)中的多個(gè)設(shè)備,比如下圖中的 EMC 存儲(chǔ)就需

    2024年02月10日
    瀏覽(28)
  • 分布式 - 談?wù)勀銓?duì)分布式的理解,為什么引入分布式?

    分布式 - 談?wù)勀銓?duì)分布式的理解,為什么引入分布式?

    不啰嗦,我們直接開(kāi)始! 真正了解分布式系統(tǒng)的概念,日后工作中具有分布式系統(tǒng)設(shè)計(jì)思想。 能否在設(shè)計(jì)中對(duì)系統(tǒng)穩(wěn)定性方面考慮周全。 能構(gòu)建高 QPS 健壯的系統(tǒng)架構(gòu)。 問(wèn)題分析: 各種分布式框架層出不窮,Spring Cloud,阿里的 Dubbo,無(wú)論使用哪一個(gè),原理都相同,考察下基

    2024年02月15日
    瀏覽(28)
  • 高級(jí)分布式系統(tǒng)-第15講 分布式機(jī)器學(xué)習(xí)--分布式機(jī)器學(xué)習(xí)算法

    高級(jí)分布式系統(tǒng)-第15講 分布式機(jī)器學(xué)習(xí)--分布式機(jī)器學(xué)習(xí)算法

    高級(jí)分布式系統(tǒng)匯總:高級(jí)分布式系統(tǒng)目錄匯總-CSDN博客 按照通信步調(diào),大致可以分為同步算法和異步算法兩大類。 同步算法下,通信過(guò)程中有一個(gè)顯式的全局同步狀態(tài),稱之為同步屏障。當(dāng)工作節(jié)點(diǎn)運(yùn)行到 同步屏障 ,就會(huì)進(jìn)入等待狀態(tài),直到其工作節(jié)點(diǎn)均運(yùn)行到同步屏障

    2024年01月18日
    瀏覽(30)
  • 分布式系統(tǒng)面試全集通第一篇(dubbo+redis+zookeeper----分布式+CAP+BASE+分布式事務(wù)+分布式鎖)

    分布式系統(tǒng)面試全集通第一篇(dubbo+redis+zookeeper----分布式+CAP+BASE+分布式事務(wù)+分布式鎖)

    什么是分布式 一個(gè)系統(tǒng)各組件分別部署在不同服務(wù)器。彼此通過(guò)網(wǎng)絡(luò)通信和協(xié)調(diào)的系統(tǒng)。 也可以指多個(gè)不同組件分布在網(wǎng)絡(luò)上互相協(xié)作,比如說(shuō)電商網(wǎng)站 也可以一個(gè)組件的多個(gè)副本組成集群,互相協(xié)作如同一個(gè)組件,比如數(shù)據(jù)存儲(chǔ)服務(wù)中為了數(shù)據(jù)不丟失而采取的多個(gè)服務(wù)備

    2024年04月11日
    瀏覽(29)
  • 分布式爬蟲架構(gòu)-對(duì)等分布式(2)

    前言 本文是該專欄的第45篇,后面會(huì)持續(xù)分享python爬蟲干貨知識(shí),記得關(guān)注。 在面對(duì)海量數(shù)據(jù)的采集需求時(shí),使用分布式爬蟲是非常有必要的。繼上一篇,詳細(xì)介紹主從分布式爬蟲架構(gòu),對(duì)主從分布式相關(guān)知識(shí)感興趣的同學(xué),可往前翻閱。而本文,筆者再單獨(dú)來(lái)詳細(xì)介紹分布

    2023年04月25日
    瀏覽(30)
  • 【分布式】分布式共識(shí)算法 --- RAFT

    【分布式】分布式共識(shí)算法 --- RAFT

    CAP原則又稱CAP定理,指的是在一個(gè)分布式系統(tǒng)中,一致性(Consistency)、可用性(Availability)、分區(qū)容錯(cuò)性(Partition tolerance) It states, that though its desirable to have Consistency, High-Availability and Partition-tolerance in every system, unfortunately no system can achieve all three at the same time. 在分布式系

    2024年02月06日
    瀏覽(26)

覺(jué)得文章有用就打賞一下文章作者

支付寶掃一掃打賞

博客贊助

微信掃一掃打賞

請(qǐng)作者喝杯咖啡吧~博客贊助

支付寶掃一掃領(lǐng)取紅包,優(yōu)惠每天領(lǐng)

二維碼1

領(lǐng)取紅包

二維碼2

領(lǐng)紅包