【22期】為什么需要消息隊(duì)列？使用消息隊(duì)列有什么好處？
閱讀本文大概需要 2.8 分鐘。
來(lái)自：http://t.cn/EogJKg4
目錄
一、消息隊(duì)列的特性
二、為什么需要消息隊(duì)列？
三、使用消息隊(duì)列有什么好處？
四、為什么需要分布式？
五、分布式環(huán)境下需要解決哪些問(wèn)題？
六、如何實(shí)現(xiàn)？
七、常見消息隊(duì)列對(duì)比和選型
一、消息隊(duì)列的特性
二、為什么需要消息隊(duì)列？
三、使用消息隊(duì)列有什么好處？
3.1、提高系統(tǒng)響應(yīng)速度
3.2、提高系統(tǒng)穩(wěn)定性
異步化、解耦、消除峰值
邏輯節(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操作，玩家們都掉線了，服務(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é)寫入讀取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í)登錄上去了并且可以正常游戲，后面的玩家登錄不上。但是很可惜，十年前開始流行的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)。
四、為什么需要分布式？
4.1、多系統(tǒng)協(xié)作需要分布式
4.2、單系統(tǒng)內(nèi)部署環(huán)境需要分布式
五、分布式環(huán)境下需要解決哪些問(wèn)題？
5.1、并發(fā)問(wèn)題
5.2、簡(jiǎn)單的、統(tǒng)一的操作機(jī)制
5.3、容錯(cuò)
5.4、可橫向擴(kuò)展
六、如何實(shí)現(xiàn)？
七、常見消息隊(duì)列對(duì)比和選型
推薦閱讀：
【21期】你能說(shuō)說(shuō)Java中Comparable和Comparator的區(qū)別嗎
【19期】為什么Java線程沒(méi)有Running狀態(tài)？
微信掃描二維碼，關(guān)注我的公眾號(hào)
朕已閱?