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