蜜桃传媒一区二区,欧美熟女乱伦,国产乱伦一区,亚洲国产另类无码日韩,99亚州,亚洲日韩一区二区,婷婷综合伊人,中文字幕一区二区三区免费2023

程序員的成長(zhǎng)之路

互聯(lián)網(wǎng)/程序員/技術(shù)/資料共享?

閱讀本文大概需要 2.8 分鐘。

來(lái)自：http://t.cn/EogJKg4

一、消息隊(duì)列的特性
二、為什么需要消息隊(duì)列？
三、使用消息隊(duì)列有什么好處？
四、為什么需要分布式？
五、分布式環(huán)境下需要解決哪些問(wèn)題？
六、如何實(shí)現(xiàn)？
七、常見(jiàn)消息隊(duì)列對(duì)比和選型

一、消息隊(duì)列的特性

業(yè)務(wù)無(wú)關(guān)，一個(gè)具有普適性質(zhì)的消息隊(duì)列組件不需要考慮上層的業(yè)務(wù)模型，只做好消息的分發(fā)就可以了，上層業(yè)務(wù)的不同模塊反而需要依賴消息隊(duì)列所定義的規(guī)范進(jìn)行通信。

FIFO，先投遞先到達(dá)的保證是一個(gè)消息隊(duì)列和一個(gè)buffer的本質(zhì)區(qū)別。

容災(zāi)，對(duì)于普適的消息隊(duì)列組件來(lái)說(shuō)，節(jié)點(diǎn)的動(dòng)態(tài)增刪和消息的持久化，都是支持其容災(zāi)能力的重要基本特性。當(dāng)然，這個(gè)特性對(duì)于游戲服務(wù)器中大部分應(yīng)用中的消息隊(duì)列來(lái)說(shuō)不是必須的，這個(gè)也是跟應(yīng)用情景有關(guān)的，很多時(shí)候沒(méi)有這種持久化的需求。

性能，這個(gè)不必多說(shuō)了，消息隊(duì)列的吞吐量上去了，整個(gè)系統(tǒng)的內(nèi)部通信效率也會(huì)有提高。

二、為什么需要消息隊(duì)列？

當(dāng)系統(tǒng)中出現(xiàn)“生產(chǎn)“和“消費(fèi)“的速度或穩(wěn)定性等因素不一致的時(shí)候，就需要消息隊(duì)列，作為抽象層，彌合雙方的差異。“ 消息 ”是在兩臺(tái)計(jì)算機(jī)間傳送的數(shù)據(jù)單位。消息可以非常簡(jiǎn)單，例如只包含文本字符串；也可以更復(fù)雜，可能包含嵌入對(duì)象。消息被發(fā)送到隊(duì)列中，“ 消息隊(duì)列 ”是在消息的傳輸過(guò)程中保存消息的容器。

舉幾個(gè)例子

1）業(yè)務(wù)系統(tǒng)觸發(fā)短信發(fā)送申請(qǐng)，但短信發(fā)送模塊速度跟不上，需要將來(lái)不及處理的消息暫存一下，緩沖壓力。就可以把短信發(fā)送申請(qǐng)丟到消息隊(duì)列，直接返回用戶成功，短信發(fā)送模塊再可以慢慢去消息隊(duì)列中取消息進(jìn)行處理。

2）調(diào)遠(yuǎn)程系統(tǒng)下訂單成本較高，且因?yàn)榫W(wǎng)絡(luò)等因素，不穩(wěn)定，攢一批一起發(fā)送。

3）任務(wù)處理類的系統(tǒng)，先把用戶發(fā)起的任務(wù)請(qǐng)求接收過(guò)來(lái)存到消息隊(duì)列中，然后后端開(kāi)啟多個(gè)應(yīng)用程序從隊(duì)列中取任務(wù)進(jìn)行處理。

三、使用消息隊(duì)列有什么好處？

3.1、提高系統(tǒng)響應(yīng)速度

使用了消息隊(duì)列，生產(chǎn)者一方，把消息往隊(duì)列里一扔，就可以立馬返回，響應(yīng)用戶了。無(wú)需等待處理結(jié)果。

處理結(jié)果可以讓用戶稍后自己來(lái)取，如醫(yī)院取化驗(yàn)單。也可以讓生產(chǎn)者訂閱（如：留下手機(jī)號(hào)碼或讓生產(chǎn)者實(shí)現(xiàn)listener接口、加入監(jiān)聽(tīng)隊(duì)列），有結(jié)果了通知。獲得約定將結(jié)果放在某處，無(wú)需通知。

3.2、提高系統(tǒng)穩(wěn)定性

考慮電商系統(tǒng)下訂單，發(fā)送數(shù)據(jù)給生產(chǎn)系統(tǒng)的情況。電商系統(tǒng)和生產(chǎn)系統(tǒng)之間的網(wǎng)絡(luò)有可能掉線，生產(chǎn)系統(tǒng)可能會(huì)因維護(hù)等原因暫停服務(wù)。如果不使用消息隊(duì)列，電商系統(tǒng)數(shù)據(jù)發(fā)布出去，顧客無(wú)法下單，影響業(yè)務(wù)開(kāi)展。兩個(gè)系統(tǒng)間不應(yīng)該如此緊密耦合。應(yīng)該通過(guò)消息隊(duì)列解耦。同時(shí)讓系統(tǒng)更健壯、穩(wěn)定。

異步化、解耦、消除峰值

以上三點(diǎn)其實(shí)可以用一個(gè)例子來(lái)解釋——設(shè)想有一款MMO游戲，沒(méi)有人肉寫(xiě)的緩存層或者ORM，所有邏輯節(jié)點(diǎn)都直連MySQL，邏輯節(jié)點(diǎn)內(nèi)除了要關(guān)注場(chǎng)景、戰(zhàn)斗、交互等復(fù)雜邏輯以外，還要有個(gè)拼SQL語(yǔ)句的模塊，想想簡(jiǎn)直是蛋疼。先考慮一下這樣設(shè)計(jì)的弊端所在：

邏輯節(jié)點(diǎn)與Db的交互會(huì)有大量IO，即使把與Db交互的模塊耦合在邏輯節(jié)點(diǎn)內(nèi)，其實(shí)現(xiàn)對(duì)你來(lái)說(shuō)是黑盒，如果內(nèi)部是同步實(shí)現(xiàn)的，那就直接卡你游戲主邏輯，就因?yàn)橐淮未姹P(pán)操作，玩家們都掉線了，服務(wù)器也可以關(guān)掉了。
那么我們改進(jìn)一下，針對(duì)1的情況，可以把這個(gè)模塊做到一個(gè)線程里掛在邏輯節(jié)點(diǎn)上。這樣其實(shí)邏輯節(jié)點(diǎn)跟這個(gè)Db前端模塊的交互就會(huì)基于一個(gè)比較原始的消息隊(duì)列。但是這樣還有一個(gè)壞處，那就是這兩種任務(wù)一種是計(jì)算密集的（玩家的邏輯處理）、一種是IO密集的（只負(fù)責(zé)寫(xiě)入讀取MySQL），搞到一個(gè)節(jié)點(diǎn)中，擴(kuò)展起來(lái)會(huì)非常麻煩，而且耦合度太高。比如說(shuō)現(xiàn)在發(fā)現(xiàn)場(chǎng)景放單節(jié)點(diǎn)上有瓶頸，要按場(chǎng)景分節(jié)點(diǎn)，那么這種掛在上面的數(shù)據(jù)模塊怎么跟其他場(chǎng)景的交互呢？
峰值的問(wèn)題。在分布式系統(tǒng)中，一次分布式事務(wù)關(guān)聯(lián)的是多個(gè)節(jié)點(diǎn)，其中每一個(gè)節(jié)點(diǎn)出現(xiàn)問(wèn)題都會(huì)成為整個(gè)事務(wù)處理流程中的瓶頸。如果邏輯節(jié)點(diǎn)與數(shù)據(jù)庫(kù)之間沒(méi)有一個(gè)起到緩沖作用的節(jié)點(diǎn)，那就是每次操作都要訪問(wèn)數(shù)據(jù)庫(kù)，對(duì)于MMO來(lái)說(shuō)，一個(gè)玩家上線load幾百K數(shù)據(jù)，一個(gè)服10萬(wàn)個(gè)玩家上線已經(jīng)足夠搞垮一個(gè)mysql節(jié)點(diǎn)了。如果直接搞垮還是比較好的結(jié)果，至少是前面的玩家確實(shí)登錄上去了并且可以正常游戲，后面的玩家登錄不上。但是很可惜，十年前開(kāi)始流行的C10K說(shuō)法就是在講：并發(fā)量上來(lái)之后，會(huì)造成chain reaction，大量的并發(fā)不會(huì)直接掛掉你的mysql節(jié)點(diǎn)，但是會(huì)拖慢速度，降低吞吐量，一個(gè)玩家的請(qǐng)求由于處理時(shí)間太長(zhǎng)，導(dǎo)致玩家放棄重試，但是對(duì)于后端來(lái)說(shuō)，對(duì)該玩家之前的處理過(guò)程消耗的資源就全部浪費(fèi)了，陷入惡性循環(huán)。

所以，這種情景下，一個(gè)介于邏輯節(jié)點(diǎn)和db節(jié)點(diǎn)之間的緩存節(jié)點(diǎn)就是理所當(dāng)然的事情了。這個(gè)緩存節(jié)點(diǎn)其實(shí)很多時(shí)候也可以看作是一個(gè)更復(fù)雜的消息隊(duì)列節(jié)點(diǎn)。

四、為什么需要分布式？

4.1、多系統(tǒng)協(xié)作需要分布式

消息隊(duì)列中的數(shù)據(jù)需要在多個(gè)系統(tǒng)間共享數(shù)據(jù)才能發(fā)揮價(jià)值。所以必須提供分布式通信機(jī)制、協(xié)同機(jī)制。

4.2、單系統(tǒng)內(nèi)部署環(huán)境需要分布式

單系統(tǒng)內(nèi)部，為了更好的性能、為了避免單點(diǎn)故障，多為集群環(huán)境。集群環(huán)境中，應(yīng)用運(yùn)行在多臺(tái)服務(wù)器的多個(gè)JVM中；數(shù)據(jù)也保存在各種類型的數(shù)據(jù)庫(kù)或非數(shù)據(jù)庫(kù)的多個(gè)節(jié)點(diǎn)上。為了滿足多節(jié)點(diǎn)協(xié)作需要，需要提供分布式的解決方案。

五、分布式環(huán)境下需要解決哪些問(wèn)題？

5.1、并發(fā)問(wèn)題

需進(jìn)行良好的并發(fā)控制。確保“線程安全“。不要出現(xiàn)一個(gè)訂單被出貨兩次。不要出現(xiàn)顧客A下的單，發(fā)貨發(fā)給了顧客B等情況。

5.2、簡(jiǎn)單的、統(tǒng)一的操作機(jī)制

需定義簡(jiǎn)單的，語(yǔ)義明確的，業(yè)務(wù)無(wú)關(guān)的，恰當(dāng)穩(wěn)妥的統(tǒng)一的訪問(wèn)方式。

5.3、容錯(cuò)

控制好單點(diǎn)故障，確保數(shù)據(jù)安全。

5.4、可橫向擴(kuò)展

可便捷擴(kuò)容。

六、如何實(shí)現(xiàn)？

成熟的消息隊(duì)列中間件產(chǎn)品太多了，族繁不及備載。成熟產(chǎn)品經(jīng)過(guò)驗(yàn)證，接口規(guī)范，可擴(kuò)展性強(qiáng)。

結(jié)合事業(yè)環(huán)境因素、組織過(guò)程遺產(chǎn)、實(shí)施運(yùn)維考慮、技術(shù)路線考慮、開(kāi)發(fā)人員情況等原因綜合考慮。

七、常見(jiàn)消息隊(duì)列對(duì)比和選型

【20期】你知道為什么HashMap是線程不安全的嗎？

【19期】為什么Java線程沒(méi)有Running狀態(tài)？

5T技術(shù)資源大放送！包括但不限于：C/C++，Linux，Python，Java，PHP，人工智能，單片機(jī)，樹(shù)莓派，等等。在公眾號(hào)內(nèi)回復(fù)「2048」，即可免費(fèi)獲取！！

微信掃描二維碼，關(guān)注我的公眾號(hào)

寫(xiě)留言

朕已閱?

【22期】為什么需要消息隊(duì)列？使用消息隊(duì)列有什么好處？

目錄