0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

一文詳談高并發(fā)

如意 ? 來源:百家號(hào) ? 作者:CSDN ? 2020-06-30 17:18 ? 次閱讀

高并發(fā),幾乎是每個(gè)程序員都想擁有的經(jīng)驗(yàn)。原因很簡(jiǎn)單:隨著流量變大,會(huì)遇到各種各樣的技術(shù)問題,比如接口響應(yīng)超時(shí)、CPU load升高、GC頻繁、死鎖、大數(shù)據(jù)量存儲(chǔ)等等,這些問題能推動(dòng)我們?cè)诩夹g(shù)深度上不斷精進(jìn)。

在過往的面試中,如果候選人做過高并發(fā)的項(xiàng)目,我通常會(huì)讓對(duì)方談?wù)剬?duì)于高并發(fā)的理解,但是能系統(tǒng)性地回答好此問題的人并不多,大概分成這樣幾類:

1、對(duì)數(shù)據(jù)化的指標(biāo)沒有概念:不清楚選擇什么樣的指標(biāo)來衡量高并發(fā)系統(tǒng)?分不清并發(fā)量和QPS,甚至不知道自己系統(tǒng)的總用戶量、活躍用戶量,平峰和高峰時(shí)的QPS和TPS等關(guān)鍵數(shù)據(jù)。

2、設(shè)計(jì)了一些方案,但是細(xì)節(jié)掌握不透徹:講不出該方案要關(guān)注的技術(shù)點(diǎn)和可能帶來的副作用。比如讀性能有瓶頸會(huì)引入緩存,但是忽視了緩存命中率、熱點(diǎn)key、數(shù)據(jù)一致性等問題。

3、理解片面,把高并發(fā)設(shè)計(jì)等同于性能優(yōu)化:大談并發(fā)編程、多級(jí)緩存、異步化、水平擴(kuò)容,卻忽視高可用設(shè)計(jì)、服務(wù)治理和運(yùn)維保障。

4、掌握大方案,卻忽視最基本的東西:能講清楚垂直分層、水平分區(qū)、緩存等大思路,卻沒意識(shí)去分析數(shù)據(jù)結(jié)構(gòu)是否合理,算法是否高效,沒想過從最根本的IO和計(jì)算兩個(gè)維度去做細(xì)節(jié)優(yōu)化。

這篇文章,我想結(jié)合自己的高并發(fā)項(xiàng)目經(jīng)驗(yàn),系統(tǒng)性地總結(jié)下高并發(fā)需要掌握的知識(shí)和實(shí)踐思路,希望對(duì)你有所幫助。內(nèi)容分成以下3個(gè)部分:

如何理解高并發(fā)?

高并發(fā)系統(tǒng)設(shè)計(jì)的目標(biāo)是什么?

高并發(fā)的實(shí)踐方案有哪些?

如何理解高并發(fā)?

高并發(fā)意味著大流量,需要運(yùn)用技術(shù)手段抵抗流量的沖擊,這些手段好比操作流量,能讓流量更平穩(wěn)地被系統(tǒng)所處理,帶給用戶更好的體驗(yàn)。

我們常見的高并發(fā)場(chǎng)景有:淘寶的雙11、春運(yùn)時(shí)的搶票、微博大V的熱點(diǎn)新聞等。除了這些典型事情,每秒幾十萬請(qǐng)求的秒殺系統(tǒng)、每天千萬級(jí)的訂單系統(tǒng)、每天億級(jí)日活的信息流系統(tǒng)等,都可以歸為高并發(fā)。

很顯然,上面談到的高并發(fā)場(chǎng)景,并發(fā)量各不相同,那到底多大并發(fā)才算高并發(fā)呢?

1、不能只看數(shù)字,要看具體的業(yè)務(wù)場(chǎng)景。不能說10W QPS的秒殺是高并發(fā),而1W QPS的信息流就不是高并發(fā)。信息流場(chǎng)景涉及復(fù)雜的推薦模型和各種人工策略,它的業(yè)務(wù)邏輯可能比秒殺場(chǎng)景復(fù)雜10倍不止。因此,不在同一個(gè)維度,沒有任何比較意義。

2、業(yè)務(wù)都是從0到1做起來的,并發(fā)量和QPS只是參考指標(biāo),最重要的是:在業(yè)務(wù)量逐漸變成原來的10倍、100倍的過程中,你是否用到了高并發(fā)的處理方法去演進(jìn)你的系統(tǒng),從架構(gòu)設(shè)計(jì)、編碼實(shí)現(xiàn)、甚至產(chǎn)品方案等維度去預(yù)防和解決高并發(fā)引起的問題?而不是一味的升級(jí)硬件、加機(jī)器做水平擴(kuò)展。

此外,各個(gè)高并發(fā)場(chǎng)景的業(yè)務(wù)特點(diǎn)完全不同:有讀多寫少的信息流場(chǎng)景、有讀多寫多的交易場(chǎng)景,那是否有通用的技術(shù)方案解決不同場(chǎng)景的高并發(fā)問題呢?

我覺得大的思路可以借鑒,別人的方案也可以參考,但是真正落地過程中,細(xì)節(jié)上還會(huì)有無數(shù)的坑。另外,由于軟硬件環(huán)境、技術(shù)棧、以及產(chǎn)品邏輯都沒法做到完全一致,這些都會(huì)導(dǎo)致同樣的業(yè)務(wù)場(chǎng)景,就算用相同的技術(shù)方案也會(huì)面臨不同的問題,這些坑還得一個(gè)個(gè)趟。

因此,這篇文章我會(huì)將重點(diǎn)放在基礎(chǔ)知識(shí)、通用思路、和我曾經(jīng)實(shí)踐過的有效經(jīng)驗(yàn)上,希望讓你對(duì)高并發(fā)有更深的理解。

高并發(fā)系統(tǒng)設(shè)計(jì)的目標(biāo)是什么?

先搞清楚高并發(fā)系統(tǒng)設(shè)計(jì)的目標(biāo),在此基礎(chǔ)上再討論設(shè)計(jì)方案和實(shí)踐經(jīng)驗(yàn)才有意義和針對(duì)性。

2.1 宏觀目標(biāo)

高并發(fā)絕不意味著只追求高性能,這是很多人片面的理解。從宏觀角度看,高并發(fā)系統(tǒng)設(shè)計(jì)的目標(biāo)有三個(gè):高性能、高可用,以及高可擴(kuò)展。

1、高性能:性能體現(xiàn)了系統(tǒng)的并行處理能力,在有限的硬件投入下,提高性能意味著節(jié)省成本。同時(shí),性能也反映了用戶體驗(yàn),響應(yīng)時(shí)間分別是100毫秒和1秒,給用戶的感受是完全不同的。

2、高可用:表示系統(tǒng)可以正常服務(wù)的時(shí)間。一個(gè)全年不停機(jī)、無故障;另一個(gè)隔三差五出線上事故、宕機(jī),用戶肯定選擇前者。另外,如果系統(tǒng)只能做到90%可用,也會(huì)大大拖累業(yè)務(wù)。

3、高擴(kuò)展:表示系統(tǒng)的擴(kuò)展能力,流量高峰時(shí)能否在短時(shí)間內(nèi)完成擴(kuò)容,更平穩(wěn)地承接峰值流量,比如雙11活動(dòng)、明星離婚等熱點(diǎn)事件。

這3個(gè)目標(biāo)是需要通盤考慮的,因?yàn)樗鼈兓ハ嚓P(guān)聯(lián)、甚至也會(huì)相互影響。

比如說:考慮系統(tǒng)的擴(kuò)展能力,你會(huì)將服務(wù)設(shè)計(jì)成無狀態(tài)的,這種集群設(shè)計(jì)保證了高擴(kuò)展性,其實(shí)也間接提升了系統(tǒng)的性能和可用性。

再比如說:為了保證可用性,通常會(huì)對(duì)服務(wù)接口進(jìn)行超時(shí)設(shè)置,以防大量線程阻塞在慢請(qǐng)求上造成系統(tǒng)雪崩,那超時(shí)時(shí)間設(shè)置成多少合理呢?一般,我們會(huì)參考依賴服務(wù)的性能表現(xiàn)進(jìn)行設(shè)置。

2.2 微觀目標(biāo)

再從微觀角度來看,高性能、高可用和高擴(kuò)展又有哪些具體的指標(biāo)來衡量?為什么會(huì)選擇這些指標(biāo)呢?

性能指標(biāo)

通過性能指標(biāo)可以度量目前存在的性能問題,同時(shí)作為性能優(yōu)化的評(píng)估依據(jù)。一般來說,會(huì)采用一段時(shí)間內(nèi)的接口響應(yīng)時(shí)間作為指標(biāo)。

1、平均響應(yīng)時(shí)間:最常用,但是缺陷很明顯,對(duì)于慢請(qǐng)求不敏感。比如1萬次請(qǐng)求,其中9900次是1ms,100次是100ms,則平均響應(yīng)時(shí)間為1.99ms,雖然平均耗時(shí)僅增加了0.99ms,但是1%請(qǐng)求的響應(yīng)時(shí)間已經(jīng)增加了100倍。

2、TP90、TP99等分位值:將響應(yīng)時(shí)間按照從小到大排序,TP90表示排在第90分位的響應(yīng)時(shí)間, 分位值越大,對(duì)慢請(qǐng)求越敏感。

3、吞吐量:和響應(yīng)時(shí)間呈反比,比如響應(yīng)時(shí)間是1ms,則吞吐量為每秒1000次。

通常,設(shè)定性能目標(biāo)時(shí)會(huì)兼顧吞吐量和響應(yīng)時(shí)間,比如這樣表述:在每秒1萬次請(qǐng)求下,AVG控制在50ms以下,TP99控制在100ms以下。對(duì)于高并發(fā)系統(tǒng),AVG和TP分位值必須同時(shí)要考慮。

另外,從用戶體驗(yàn)角度來看,200毫秒被認(rèn)為是第一個(gè)分界點(diǎn),用戶感覺不到延遲,1秒是第二個(gè)分界點(diǎn),用戶能感受到延遲,但是可以接受。

因此,對(duì)于一個(gè)健康的高并發(fā)系統(tǒng),TP99應(yīng)該控制在200毫秒以內(nèi),TP999或者TP9999應(yīng)該控制在1秒以內(nèi)。

可用性指標(biāo)

高可用性是指系統(tǒng)具有較高的無故障運(yùn)行能力,可用性 = 平均故障時(shí)間 / 系統(tǒng)總運(yùn)行時(shí)間,一般使用幾個(gè)9來描述系統(tǒng)的可用性。

對(duì)于高并發(fā)系統(tǒng)來說,最基本的要求是:保證3個(gè)9或者4個(gè)9。原因很簡(jiǎn)單,如果你只能做到2個(gè)9,意味著有1%的故障時(shí)間,像一些大公司每年動(dòng)輒千億以上的GMV或者收入,1%就是10億級(jí)別的業(yè)務(wù)影響。

可擴(kuò)展性指標(biāo)

面對(duì)突發(fā)流量,不可能臨時(shí)改造架構(gòu),最快的方式就是增加機(jī)器來線性提高系統(tǒng)的處理能力。

對(duì)于業(yè)務(wù)集群或者基礎(chǔ)組件來說,擴(kuò)展性 = 性能提升比例 / 機(jī)器增加比例,理想的擴(kuò)展能力是:資源增加幾倍,性能提升幾倍。通常來說,擴(kuò)展能力要維持在70%以上。

但是從高并發(fā)系統(tǒng)的整體架構(gòu)角度來看,擴(kuò)展的目標(biāo)不僅僅是把服務(wù)設(shè)計(jì)成無狀態(tài)就行了,因?yàn)楫?dāng)流量增加10倍,業(yè)務(wù)服務(wù)可以快速擴(kuò)容10倍,但是數(shù)據(jù)庫可能就成為了新的瓶頸。

像MySQL這種有狀態(tài)的存儲(chǔ)服務(wù)通常是擴(kuò)展的技術(shù)難點(diǎn),如果架構(gòu)上沒提前做好規(guī)劃(垂直和水平拆分),就會(huì)涉及到大量數(shù)據(jù)的遷移。

因此,高擴(kuò)展性需要考慮:服務(wù)集群、數(shù)據(jù)庫、緩存和消息隊(duì)列等中間件、負(fù)載均衡、帶寬、依賴的第三方等,當(dāng)并發(fā)達(dá)到某一個(gè)量級(jí)后,上述每個(gè)因素都可能成為擴(kuò)展的瓶頸點(diǎn)。

高并發(fā)的實(shí)踐方案有哪些?

了解了高并發(fā)設(shè)計(jì)的3大目標(biāo)后,再系統(tǒng)性總結(jié)下高并發(fā)的設(shè)計(jì)方案,會(huì)從以下兩部分展開:先總結(jié)下通用的設(shè)計(jì)方法,然后再圍繞高性能、高可用、高擴(kuò)展分別給出具體的實(shí)踐方案。

3.1 通用的設(shè)計(jì)方法

通用的設(shè)計(jì)方法主要是從「縱向」和「橫向」兩個(gè)維度出發(fā),俗稱高并發(fā)處理的兩板斧:縱向擴(kuò)展和橫向擴(kuò)展。

縱向擴(kuò)展(scale-up)

它的目標(biāo)是提升單機(jī)的處理能力,方案又包括:

1、提升單機(jī)的硬件性能:通過增加內(nèi)存、CPU核數(shù)、存儲(chǔ)容量、或者將磁盤升級(jí)成SSD等堆硬件的方式來提升。

2、提升單機(jī)的軟件性能:使用緩存減少IO次數(shù),使用并發(fā)或者異步的方式增加吞吐量。

橫向擴(kuò)展(scale-out)

因?yàn)閱螜C(jī)性能總會(huì)存在極限,所以最終還需要引入橫向擴(kuò)展,通過集群部署以進(jìn)一步提高并發(fā)處理能力,又包括以下2個(gè)方向:

1、做好分層架構(gòu):這是橫向擴(kuò)展的提前,因?yàn)楦卟l(fā)系統(tǒng)往往業(yè)務(wù)復(fù)雜,通過分層處理可以簡(jiǎn)化復(fù)雜問題,更容易做到橫向擴(kuò)展。

上面這種圖是互聯(lián)網(wǎng)最常見的分層架構(gòu),當(dāng)然真實(shí)的高并發(fā)系統(tǒng)架構(gòu)會(huì)在此基礎(chǔ)上進(jìn)一步完善。比如會(huì)做動(dòng)靜分離并引入CDN,反向代理層可以是LVS+Nginx,Web層可以是統(tǒng)一的API網(wǎng)關(guān),業(yè)務(wù)服務(wù)層可進(jìn)一步按垂直業(yè)務(wù)做微服務(wù)化,存儲(chǔ)層可以是各種異構(gòu)數(shù)據(jù)庫。

2、各層進(jìn)行水平擴(kuò)展:無狀態(tài)水平擴(kuò)容,有狀態(tài)做分片路由。業(yè)務(wù)集群通常能設(shè)計(jì)成無狀態(tài)的,而數(shù)據(jù)庫和緩存往往是有狀態(tài)的,因此需要設(shè)計(jì)分區(qū)鍵做好存儲(chǔ)分片,當(dāng)然也可以通過主從同步、讀寫分離的方案提升讀性能。

3.2 具體的實(shí)踐方案

下面再結(jié)合我的個(gè)人經(jīng)驗(yàn),針對(duì)高性能、高可用、高擴(kuò)展3個(gè)方面,總結(jié)下可落地的實(shí)踐方案。

高性能的實(shí)踐方案

1、集群部署,通過負(fù)載均衡減輕單機(jī)壓力。

2、多級(jí)緩存,包括靜態(tài)數(shù)據(jù)使用CDN、本地緩存、分布式緩存等,以及對(duì)緩存場(chǎng)景中的熱點(diǎn)key、緩存穿透、緩存并發(fā)、數(shù)據(jù)一致性等問題的處理。

3、分庫分表和索引優(yōu)化,以及借助搜索引擎解決復(fù)雜查詢問題。

4、考慮NoSQL數(shù)據(jù)庫的使用,比如HBase、TiDB等,但是團(tuán)隊(duì)必須熟悉這些組件,且有較強(qiáng)的運(yùn)維能力。

5、異步化,將次要流程通過多線程、MQ、甚至延時(shí)任務(wù)進(jìn)行異步處理。

6、限流,需要先考慮業(yè)務(wù)是否允許限流(比如秒殺場(chǎng)景是允許的),包括前端限流、Nginx接入層的限流、服務(wù)端的限流。

7、對(duì)流量進(jìn)行削峰填谷,通過MQ承接流量。

8、并發(fā)處理,通過多線程將串行邏輯并行化。

9、預(yù)計(jì)算,比如搶紅包場(chǎng)景,可以提前計(jì)算好紅包金額緩存起來,發(fā)紅包時(shí)直接使用即可。

10、緩存預(yù)熱,通過異步任務(wù)提前預(yù)熱數(shù)據(jù)到本地緩存或者分布式緩存中。

11、減少IO次數(shù),比如數(shù)據(jù)庫和緩存的批量讀寫、RPC的批量接口支持、或者通過冗余數(shù)據(jù)的方式干掉RPC調(diào)用。

12、減少IO時(shí)的數(shù)據(jù)包大小,包括采用輕量級(jí)的通信協(xié)議、合適的數(shù)據(jù)結(jié)構(gòu)、去掉接口中的多余字段、減少緩存key的大小、壓縮緩存value等。

13、程序邏輯優(yōu)化,比如將大概率阻斷執(zhí)行流程的判斷邏輯前置、For循環(huán)的計(jì)算邏輯優(yōu)化,或者采用更高效的算法。

14、各種池化技術(shù)的使用和池大小的設(shè)置,包括HTTP請(qǐng)求池、線程池(考慮CPU密集型還是IO密集型設(shè)置核心參數(shù))、數(shù)據(jù)庫和Redis連接池等。

15、JVM優(yōu)化,包括新生代和老年代的大小、GC算法的選擇等,盡可能減少GC頻率和耗時(shí)。

16、鎖選擇,讀多寫少的場(chǎng)景用樂觀鎖,或者考慮通過分段鎖的方式減少鎖沖突。

上述方案無外乎從計(jì)算和 IO 兩個(gè)維度考慮所有可能的優(yōu)化點(diǎn),需要有配套的監(jiān)控系統(tǒng)實(shí)時(shí)了解當(dāng)前的性能表現(xiàn),并支撐你進(jìn)行性能瓶頸分析,然后再遵循二八原則,抓主要矛盾進(jìn)行優(yōu)化。

高可用的實(shí)踐方案

1、對(duì)等節(jié)點(diǎn)的故障轉(zhuǎn)移,Nginx和服務(wù)治理框架均支持一個(gè)節(jié)點(diǎn)失敗后訪問另一個(gè)節(jié)點(diǎn)。

2、非對(duì)等節(jié)點(diǎn)的故障轉(zhuǎn)移,通過心跳檢測(cè)并實(shí)施主備切換(比如redis的哨兵模式或者集群模式、MySQL的主從切換等)。

3、接口層面的超時(shí)設(shè)置、重試策略和冪等設(shè)計(jì)。

4、降級(jí)處理:保證核心服務(wù),犧牲非核心服務(wù),必要時(shí)進(jìn)行熔斷;或者核心鏈路出問題時(shí),有備選鏈路。

5、限流處理:對(duì)超過系統(tǒng)處理能力的請(qǐng)求直接拒絕或者返回錯(cuò)誤碼。

6、MQ場(chǎng)景的消息可靠性保證,包括producer端的重試機(jī)制、broker側(cè)的持久化、consumer端的ack機(jī)制等。

7、灰度發(fā)布,能支持按機(jī)器維度進(jìn)行小流量部署,觀察系統(tǒng)日志和業(yè)務(wù)指標(biāo),等運(yùn)行平穩(wěn)后再推全量。

8、監(jiān)控報(bào)警:全方位的監(jiān)控體系,包括最基礎(chǔ)的CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)的監(jiān)控,以及Web服務(wù)器、JVM、數(shù)據(jù)庫、各類中間件的監(jiān)控和業(yè)務(wù)指標(biāo)的監(jiān)控。

9、災(zāi)備演練:類似當(dāng)前的“混沌工程”,對(duì)系統(tǒng)進(jìn)行一些破壞性手段,觀察局部故障是否會(huì)引起可用性問題。

高可用的方案主要從冗余、取舍、系統(tǒng)運(yùn)維3個(gè)方向考慮,同時(shí)需要有配套的值班機(jī)制和故障處理流程,當(dāng)出現(xiàn)線上問題時(shí),可及時(shí)跟進(jìn)處理。

高擴(kuò)展的實(shí)踐方案

1、合理的分層架構(gòu):比如上面談到的互聯(lián)網(wǎng)最常見的分層架構(gòu),另外還能進(jìn)一步按照數(shù)據(jù)訪問層、業(yè)務(wù)邏輯層對(duì)微服務(wù)做更細(xì)粒度的分層(但是需要評(píng)估性能,會(huì)存在網(wǎng)絡(luò)多一跳的情況)。

2、存儲(chǔ)層的拆分:按照業(yè)務(wù)維度做垂直拆分、按照數(shù)據(jù)特征維度進(jìn)一步做水平拆分(分庫分表)。

3、業(yè)務(wù)層的拆分:最常見的是按照業(yè)務(wù)維度拆(比如電商場(chǎng)景的商品服務(wù)、訂單服務(wù)等),也可以按照核心接口和非核心接口拆,還可以按照請(qǐng)求源拆(比如To C和To B,APP和H5)。

最后的話

高并發(fā)確實(shí)是一個(gè)復(fù)雜且系統(tǒng)性的問題,由于篇幅有限,諸如分布式Trace、全鏈路壓測(cè)、柔性事務(wù)都是要考慮的技術(shù)點(diǎn)。另外,如果業(yè)務(wù)場(chǎng)景不同,高并發(fā)的落地方案也會(huì)存在差異,但是總體的設(shè)計(jì)思路和可借鑒的方案基本類似。

高并發(fā)設(shè)計(jì)同樣要秉承架構(gòu)設(shè)計(jì)的3個(gè)原則:簡(jiǎn)單、合適和演進(jìn)。“過早的優(yōu)化是萬惡之源”,不能脫離業(yè)務(wù)的實(shí)際情況,更不要過度設(shè)計(jì),合適的方案就是最完美的。

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • 嵌入式系統(tǒng)
    +關(guān)注

    關(guān)注

    41

    文章

    3534

    瀏覽量

    128990
  • 吞吐量
    +關(guān)注

    關(guān)注

    0

    文章

    47

    瀏覽量

    12312
  • 并發(fā)
    +關(guān)注

    關(guān)注

    0

    文章

    7

    瀏覽量

    2460
收藏 人收藏

    評(píng)論

    相關(guān)推薦

    百度言APP升級(jí)為小言

    百度宣布其文心言APP正式升級(jí)為小言,標(biāo)志著百度在智能搜索領(lǐng)域邁出了重要步。小言作為百度旗下的“新搜索”智能助手,不僅集成了富媒體搜索、多模態(tài)輸入等前沿技術(shù),還創(chuàng)新性地推出了文
    的頭像 發(fā)表于 09-04 16:06 ?295次閱讀

    想用個(gè)運(yùn)放做氏震蕩,OPA690可以做到40M以上嗎?

    想用個(gè)運(yùn)放做氏震蕩,OPA690可以做到40M以上嗎?氏震蕩的頻率和運(yùn)放的壓擺率是否成正比,如果我需要的頻率越高,是不是單純的選擇壓擺率的運(yùn)放?
    發(fā)表于 08-30 08:07

    并發(fā)物聯(lián)網(wǎng)云平臺(tái)是什么

    并發(fā)物聯(lián)網(wǎng)云平臺(tái)是種能夠處理大量設(shè)備同時(shí)連接并進(jìn)行數(shù)據(jù)交換的云計(jì)算平臺(tái)。這種平臺(tái)通常被設(shè)計(jì)用來應(yīng)對(duì)來自數(shù)以萬計(jì)甚至數(shù)十億計(jì)的物聯(lián)網(wǎng)設(shè)備的并發(fā)請(qǐng)求,保證系統(tǒng)的穩(wěn)定性和響應(yīng)速度。 首先
    的頭像 發(fā)表于 08-13 13:50 ?185次閱讀

    并發(fā)系統(tǒng)的藝術(shù):如何在流量洪峰中游刃有余

    尤為重要。用戶對(duì)在線服務(wù)的需求和期望不斷提高,系統(tǒng)的并發(fā)處理能力成為衡量其性能和用戶體驗(yàn)的關(guān)鍵指標(biāo)之。并發(fā)系統(tǒng)不僅僅是大型互聯(lián)網(wǎng)企業(yè)的專利,對(duì)于任何希望在市場(chǎng)中占據(jù)
    的頭像 發(fā)表于 08-05 13:43 ?180次閱讀
    <b class='flag-5'>高</b><b class='flag-5'>并發(fā)</b>系統(tǒng)的藝術(shù):如何在流量洪峰中游刃有余

    stm32wb55rg ZigBee和藍(lán)牙并發(fā)運(yùn)行時(shí),連接藍(lán)牙失敗的原因?怎么解決?

    在使用rt thread系統(tǒng)移植官方ZigBee_ble_dynamic的示例程序時(shí),兩者都能并發(fā)廣播,但是旦到藍(lán)牙連接時(shí),系統(tǒng)就會(huì)停止,直卡在ZbStartupWait info-&
    發(fā)表于 03-15 07:59

    HarmonyOS如何使用異步并發(fā)能力進(jìn)行開發(fā)

    、并發(fā)概述 并發(fā)是指在同時(shí)間段內(nèi),能夠處理多個(gè)任務(wù)的能力。為了提升應(yīng)用的響應(yīng)速度與幀率,以及防止耗時(shí)任務(wù)對(duì)主線程的干擾,HarmonyOS系統(tǒng)提供了異步
    的頭像 發(fā)表于 02-18 09:18 ?464次閱讀

    帶你了解 DAC

    了解 DAC
    的頭像 發(fā)表于 12-07 15:10 ?8268次閱讀
    <b class='flag-5'>一</b><b class='flag-5'>文</b>帶你了解 DAC

    看懂BLE Mesh

    看懂BLE Mesh
    的頭像 發(fā)表于 12-06 16:24 ?1344次閱讀
    <b class='flag-5'>一</b><b class='flag-5'>文</b>看懂BLE Mesh

    redis并發(fā)能力直接相關(guān)概念有哪些

    Redis是種高性能的開源內(nèi)存數(shù)據(jù)庫,具有出色的并發(fā)能力。為了實(shí)現(xiàn)并發(fā),需要有些相關(guān)概念和技術(shù)。下面是關(guān)于Redis
    的頭像 發(fā)表于 12-05 10:34 ?709次閱讀

    java redis鎖處理并發(fā)代碼

    并發(fā)編程中,個(gè)常見的問題是如何確保多個(gè)線程安全地訪問共享資源,避免產(chǎn)生競(jìng)態(tài)條件和數(shù)據(jù)異常。而Redis作為種高性能的內(nèi)存數(shù)據(jù)庫,可以提供分布式鎖的功能,通過Redis鎖,我們可以有效地解決
    的頭像 發(fā)表于 12-04 11:04 ?855次閱讀

    讀懂,什么是BLE?

    讀懂,什么是BLE?
    的頭像 發(fā)表于 11-27 17:11 ?2007次閱讀
    <b class='flag-5'>一</b><b class='flag-5'>文</b>讀懂,什么是BLE?

    服務(wù)器并發(fā)的概念

    自己調(diào)整系統(tǒng)的相關(guān)參數(shù) 并發(fā)的概念是什么?什么是并發(fā)? 對(duì)于服務(wù)器并發(fā)的概念,下面幾點(diǎn)是錯(cuò)誤的定義 ①服務(wù)器處理客戶端請(qǐng)求的數(shù)量:沒有時(shí)間、空間等限制,因此不能作為并發(fā)的概念 ②單位時(shí)
    的頭像 發(fā)表于 11-10 10:05 ?4219次閱讀
    服務(wù)器<b class='flag-5'>并發(fā)</b>的概念

    并發(fā)內(nèi)存池項(xiàng)目實(shí)現(xiàn)

    本項(xiàng)目實(shí)現(xiàn)了個(gè)并發(fā)內(nèi)存池,參考了Google的開源項(xiàng)目tcmalloc實(shí)現(xiàn)的簡(jiǎn)易版;其功能就是實(shí)現(xiàn)高效的多線程內(nèi)存管理。由功能可知,并發(fā)
    的頭像 發(fā)表于 11-09 11:16 ?627次閱讀
    <b class='flag-5'>高</b><b class='flag-5'>并發(fā)</b>內(nèi)存池項(xiàng)目實(shí)現(xiàn)

    shell腳本實(shí)現(xiàn)并發(fā)多進(jìn)程

    在Shell腳本中實(shí)現(xiàn)并發(fā)多進(jìn)程可以使用以下方法: 使用符號(hào)來將其放入后臺(tái)執(zhí)行,從而實(shí)現(xiàn)并發(fā)多進(jìn)程。例如: #!/bin/bash command1 command3 符號(hào),它們將在后臺(tái)并發(fā)執(zhí)行
    的頭像 發(fā)表于 11-08 10:20 ?1183次閱讀

    FastTime-純Rust編寫的并發(fā)快速時(shí)間庫

    FastTime, 純Rust編寫的快速時(shí)間庫, 并發(fā): 2800萬+/秒. 、組件
    的頭像 發(fā)表于 11-06 09:23 ?565次閱讀