GateWay框架的疑問(wèn)
像我們這種分布式的框架，針對(duì)sendToUid，在某個(gè)進(jìn)程中其實(shí)無(wú)法感知到具體的uid綁定的連接是在哪個(gè)服務(wù)節(jié)點(diǎn)的進(jìn)程中的，當(dāng)前的實(shí)現(xiàn)是應(yīng)該屬于廣播式的把發(fā)送指令廣播到所有的gateway進(jìn)程中，讓他們自己判斷當(dāng)前的進(jìn)程中是否存在需要被發(fā)送的uid所綁定的鏈接，從而完成消息發(fā)送，但是這樣一來(lái)，如果作為一款I(lǐng)M的應(yīng)用，
假如： 10萬(wàn)的用戶在線量，平均每個(gè)用戶每秒發(fā)送一條，那么按照這樣廣播的發(fā)送消息方式。
是不是意味著不管我們gateway擴(kuò)增到多少臺(tái)節(jié)點(diǎn)上，每個(gè)gateway進(jìn)程其實(shí)都將固定承受來(lái)自廣播的 10w qps壓力？
1個(gè)回答
打賞
理論上試這樣的。原生gatewayWorker適合連接量大，但是和客戶端通訊不頻繁的業(yè)務(wù)，例如聊天類IM。IM 業(yè)務(wù)10萬(wàn)在線不會(huì)出現(xiàn)10萬(wàn)人每秒都發(fā)消息的情況。
如果你的業(yè)務(wù)和客戶端通訊量大，需要自己優(yōu)化下相關(guān)接口，例如bindUid時(shí)將uid與clientid關(guān)系存儲(chǔ)在redis里,sendToUid先從redis中讀取client_id列表，然后調(diào)用sendToClient發(fā)送，這樣避免與每個(gè)gateway進(jìn)程通訊?？蛻舳岁P(guān)閉時(shí)從redis刪除映射
-
z54123321 2020-08-13只是突發(fā)奇想，倒是沒(méi)有這樣的IM業(yè)務(wù)，比較好奇的是，像針對(duì)這種業(yè)務(wù)類型，在構(gòu)建分布式服務(wù)的時(shí)候需要如何去做通知的精準(zhǔn)度來(lái)減少進(jìn)程的壓力。如果通過(guò)緩存來(lái)處理映射關(guān)系的話，一方面可能會(huì)存在緩存失效或者更新緩存和查詢緩存之間錯(cuò)開(kāi)的情況導(dǎo)致消息不能準(zhǔn)確的發(fā)送給相關(guān)的進(jìn)程，另一方面隨著通信的壓力增大，緩存組件的壓力肯定也會(huì)飆升。不知道那些做IM通信架構(gòu)的是如何提高這種通知的精準(zhǔn)度的呢
-
walkor 2020-08-18
映射關(guān)系要放到安全的存儲(chǔ)里，放在緩存不太合適。redis也不是只能做緩存。各個(gè)存儲(chǔ)都有自己的分布式方案，如果存儲(chǔ)通訊量大了可以加機(jī)器分擔(dān)。更新數(shù)據(jù)和查詢數(shù)據(jù)錯(cuò)開(kāi)的問(wèn)題實(shí)際上屬于離線消息范疇，映射關(guān)系更新數(shù)據(jù)還未完成，這時(shí)候當(dāng)前用戶有消息屬于離線消息。如果消息不重要，沒(méi)收到也不影響。如果消息重要，每個(gè)消息發(fā)送之前必須要存在mysql等存儲(chǔ)里的，并且有已讀未讀標(biāo)記，客戶端正式上線后，需要從存儲(chǔ)里讀取一遍未讀消息，這樣就保證消息可靠性。
