如何設計高可用高併發的遊戲全服廣播?

2022-07-24 02:54:16 字數 768 閱讀 3192

我們需要再控制cpu和網路io開銷的情況下,使得廣播盡肯能快速的傳送給所有玩家,下面我們先講講如何控制cpu和網路io的開銷。

如果我們在每條廣播產生的時候就直接傳送給所有玩家,那麼當同一秒產生幾十條廣播的時候,那麼必然會產生cpu和網路io的峰值,所以我們得控制廣播的傳送頻率,比如同一時刻只傳送一條廣播,新產生的廣播進入訊息佇列,不立即傳送。

這麼做的優點是所有gatesvr傳送廣播的消耗是恆定的,不會因為廣播產生的快,加大cpu和網路id的壓力,但是它的缺點也很明顯,那就是新產生的廣播不能及時傳送給玩家。

一般來說廣播對於所有玩家來說都是一致的,所有可以通用把廣播處理好之後,比如轉成二進位制格式,再傳送給每個玩家,這樣可以降低cpu的負擔。

前面說過,控制傳送速度會導致玩家不能及時收到新產生的廣播,但是我們可以做到玩家將玩家收到廣播的延時控制在數秒以內,那就是將新產生的廣播加入待傳送池內,等到下一輪廣播的時候一次性傳送給玩家。

這樣玩家收到廣播的延遲不會超過兩輪的廣播傳送時長,從而使得盡可能的收到更多的廣播,且收到的廣播都是有時效性的。

通過前面的設計,我們已經設計出了乙個高可用高併發的廣播系統,在控制cpu和網路io的情況下使得玩家收到有時效性的廣播,但是如果在極端情況下,待傳送池累積了大量的廣播,一樣會對伺服器產生大的壓力,所有我們可以給待傳送池設計乙個上限,超過上限的時候丟棄部分較老的廣播。或者控制每輪廣播傳送的廣播數量。

該系統的設計主要是通過避免重複計算,順序傳送廣播,合併傳送廣播來降低cpu和網路io的消耗,保證玩家收到廣播的時效性。通過控制待傳送池廣播的數量來避免極端情況下的效能壓力。

如何保證redis高併發及高可用

1 面試題 如何保證redis的高併發和高可用?redis的主從複製原理能介紹一下麼?redis的哨兵原理能介紹一下麼?2 考點分析 其實問這個問題,主要是考考你,redis單機能承載多高併發?如果單機扛不住如何擴容抗更多的併發?redis會不會掛?既然redis會掛那怎麼保證redis是高可用的?...

如何保證Redis的高併發和高可用?

就是如果你用redis快取技術的話,肯定要考慮如何用redis來加多台機器,保證redis是高併發的,還有就是如何讓redis保證自己不是掛掉以後就直接死掉了,redis高可用 redis高併發 主從架構,一主多從,一般來說,很多專案其實就足夠了,單主用來寫入資料,單機幾萬qps,多從用來查詢資料,...

如何設計乙個高可用 高併發秒殺系統

如今的網際網路已經在海量服務領域有了很成熟的理論,因此自己也很慶幸,能夠從 0 到 1 完整踐行海量服務。微視春節專案中的集卡瓜分活動,是乙個典型的秒殺場景,自己參與其中,分享一些心得和總結。上圖是乙個典型的網際網路業務,使用者完成乙個寫操作,一般會通過接入層和邏輯層,這裡的服務都是無狀態,可以通過...