首页
/
每日頭條
/
生活
/
微博私信聊天沒有綠勾
微博私信聊天沒有綠勾
更新时间:2024-11-26 10:06:07

微博私信聊天沒有綠勾(貼吧變成即時聊天)1

刷微博是許多人每天的“例行指部鍛煉”,一掃一劃,就能評論熱點話題,訂閱熱門動态。當然,也有不少人對明星不感興趣,轉而去刷 Reddit、貼吧、虎撲、知識星球或是其他 BBS 社區。對于 90、80 後來說,這個被“刷”的對象可能是曾經的即刻、糗百,天涯、貓撲。

可以說,“聚衆看熱鬧”是人類永恒不變的愛好,但我們看熱鬧的方式卻并不豐富:要麼刷 BBS 社區,要麼紮進社交軟件的群聊。

不知你有沒有想過,如果将二者合二為一,讓微博、貼吧這樣的社區,全部變成即時聊天,各個博主、吧友的動态,全部以群聊消息的形式推送給你,你又可以即時地回複、互動,甚至和這些博主、吧友連麥視頻,情況會是怎樣的?

這将是一個超級社區,或者更準确地說,這将是一個無人數上限的“超級群”。

可是,這個“超級群”,實現起來将非常困難。在程序員看到産品設計的那一刻,就有精神崩潰的風險。

真正的服務器壓力

“崩潰”主要源自技術挑戰,更确切地說,是服務器面臨的巨大的讀寫壓力和存儲壓力。

微博曾出現過幾次著名的故障:趙麗穎領證、關曉彤官宣、王寶強離婚。在調侃微博崩潰的各種網絡段子背後,我們能看到的是,一個架構師面對一條微博下幾秒新增數萬條評論,服務器壓力瞬間暴漲幾十倍的無奈身影。

與此類似的是直播彈幕的分發場景。無論是近期的視頻号五月天跨年演唱會,還是 B 站春晚,彈幕過百萬輕而易舉(“二零一九最美的夜”bilibili 晚會彈幕超過 170 萬條)。

理論上講,每一條彈幕都要向直播間内觀衆做全量分發。以五月天跨年演唱會為例,當晚有 1,680 萬人在線上觀看,如果保守假設當晚共發送 100 萬條彈幕,那麼單是彈幕的寫操作,就至少要執行 16,800,000 x 1,000,000 次。因為實際支撐有困難,又要顧及用戶的屏幕根本無法同屏顯示上萬條評論,所以彈幕的轉發一般都是降級處理 —— 隻分發一小部分給你看,其他的略過。

而如果将微博評論、直播彈幕,全部“群聊化”,問題會更加恐怖。“群聊化”後,産品形态成為“超級群”,問題進入 IM 場景,可以做相應的流控,但不能丢棄信息。且無論是微博評論還是直播彈幕,對信息上下文的關注度都不高,但這恰恰是 IM 關注的重點。

可以說,至少在 3 年以前,能夠系統解決這些問題并将其打磨為一個成熟産品的人不多。直到 2018 年,國外出現了一個名叫 Discord 的軟件,網友才體驗到了這種全新的社區形式。Discord 最初隻服務于遊戲語音連麥,但很快演化為一個超級社區。2021 年,據 CNN 報道,Discord 已有超過 1.4 億名注冊用戶,微軟正在談判以 100 億美元收購它。而在 npr 的采訪中,美國芝加哥地區的一名 18 歲少年表示,他 2020 年的大部分時間都在 Discord 上閑逛,并将其形容為“Reddit 和群聊的混合體”。元宇宙的支持者們也驚奇地發現,所謂的“Discord 模式”,不就是未來元宇宙虛拟社區的基礎模式麼?在元宇宙裡,總不能先加個 500 人的群再開始聊天吧。

抛開模式創新不談,如果要深究 Discord 的技術核心,恰恰就是我們前面所描述的“超級群”。而在 2022 年 1 月 11 日,融雲也發布了一款名為“超級群”的 PaaS 産品,以此為例,我們或許能搞清楚,這種帶了點科幻色彩的未來社區,究竟是如何實現的。

超級群的設計架構和實施方案

超級群的底層技術支撐能力,可以簡單分為兩部分來談,分别是超級群業務能力、IM 底層技術能力。

微博私信聊天沒有綠勾(貼吧變成即時聊天)2

超級群的業務能力,在架構設計層面共分為四層,分别是加速網絡、接入層、核心服務層以及底層存儲。之所以要做這樣的劃分,是為了充分利用融雲自身的統一加速網絡機制, 保障網絡連通性以及連接質量,讓超級群可以根據自身業務需求, 在連接通道的基礎上,專心實現更高效的業務交互。

在融雲,傳統的群消息建立在收發模型(收件箱、發件箱)的基礎上,獨立維護會話列表和曆史消息存儲。從用戶發送群消息,到群内 (成員數量為 N ) 接收群消息。整個過程将産生四類消息:

  1. 一條發送方發件箱記錄;
  2. N-1 條接收方的收件箱記錄;
  3. 1 條群曆史消息記錄;
  4. N 條會話列表記錄。

消息存儲投遞流程為:

終端 A -> 發送消息 -> 接入服務 -> 群管理 (群消息上行) -> 分發 -> 群聊消息分發節點 -> 消息節點 -> 通知拉取 (直接發送) -> 終端 B/C/D

在這樣的流程下,消息分發節點與消息節點交互密切,通常合并部署。同時,消息節點也會直接觸發收件箱、發件箱的消息存儲。

但在超級群的場景下,群成員數量理論上是無上限的,無論是消息的上行、下行,還是消息在存儲層的寫入和查詢,都将導緻空前的服務承載壓力,以上方案因此不再适用。于是,融雲在現有連接機制之上, 針對超級群做了交互設計優化,設計了兩種分發模型: 分别叫做消息驅動模型和會話驅動模型。

對于消息驅動模型而言,消息節點将不再直接觸發收件箱存儲操作。融雲特别設計了一個環狀消息隊列, 通過内存搭配外部緩存的方式,完成最近 N 條消息的緩存, 并通過對消息存儲模型優化, 完成熱點數據的快速讀寫。對消息的下行,則做聚合處理,保障客戶端能夠處理大量消息變更通知,并且盡量減少交互次數,也讓消息的拉取變得更快速、精準。

會話驅動模型則是在消息驅動模型的基礎之上, 做進一步的優化。

首先,消息節點不會再通知客戶端拉取消息,而是通過觸發實時會話, 通知客戶端會話發生變更。而這裡的實時會話,則是實現客戶端訂閱機制的基礎, 讓客戶端可以隻獲知已訂閱的會話變更消息,從而進一步縮小需要處理的會話以及消息數量。

其次,客戶端在收到會話變更通知後, 會根據通知,判斷是否要發起會話消息查詢操作。如果是,則按照一定的機制查詢最新或特别範圍的消息。

除消息分發層面的優化外,對存儲的優化也非常關鍵。融雲超級群的所有服務,均按照業務維度進行一緻性哈希分發。比如,上行服務可以按照群 ID 或 channel ID 做哈希,分發服務可以按照接收方 ID 做哈希。核心目标在于确保熱數據的命中,優先使用内存、LRU 緩存、再使用分布式緩存、磁盤冷存儲。

APP、群組、信令級别的流控,則是另一重保障,它将一個看似無邊界的産品需求,轉化為了可琢磨、可實現的技術問題。因此,雖然流控不是超級群實現方案的重點,但依然不可或缺。

整體而言,融雲的超級群構建方案可以分為四個要點:

  1. 弱化原發件箱 / 收件箱模型, 尤其是收件箱, 以極大提升讀寫性能,避免因 I/O 而産生的性能瓶頸;
  2. 通過"變更通知"聚合等方式,盡量減少終端與服務端交互次數,減少因網絡交互而産生的延時;
  3. 設計專用數據結構 (環形隊列), 并設置内存、外部緩存等多級緩存結構, 提升超大規模下的消息分發存儲速度, 并提供快速查詢能力;
  4. 通過會話驅動模型, 進一步減少網絡交互過程中,待傳輸的數據量。

那麼,有了以上方案,是否就可以構建出一個“超級群”呢?顯然還不夠,在超級群的場景之下,IM 底層技術能力的積累可能更為重要。

IM 底層技術能力與網絡層性能優化

如果要對融雲超級群所依賴的 IM 基礎能力做一個解讀,恐怕一本迷你書也寫不完,其粗略架構圖如下:

微博私信聊天沒有綠勾(貼吧變成即時聊天)3

但好在,關于超級群,我們隻需重點關注其在網絡層面的依賴即可。對于所有的 IM 服務而言,底層網絡的加速能力都是關鍵。融雲的底層服務網絡全稱是融雲全球通信網絡 (以下簡稱為 SD-CAN,Software Defined - Communication Accelerate Network) ,集合了 BGP anycast、SD-WAN、對等連接、動态 CDN、智能 DNS 等多種網絡加速方式。

對于超級群來說,SD-CAN 允許客戶端 SDK 通過查詢和探測确定地域和運營商以及最後一公裡的網絡情況,将用戶就近調度到融雲的網絡邊緣節點, 邊緣節點依據信令的請求目标地址投遞到路由節點,完成數據彙集,再由路由節點識别并轉發到對應的數據中心。

舉個例子,如果北美用戶要訪問中國國内的數據中心,典型的兩條路徑是:

  1. 北美用戶 -> 直接連接 -> 國内數據中心接入服務 -> 業務服務;
  2. 北美用戶 -> anycast -> 北美數據中心邊緣節點 -> 北美數據中心路由節點 -> SD-WAN/ 對等連接 -> 國内數據中心路由節點 -> 國内數據中心接入服務 -> 業務服務;

客戶端會按照服務下發的策略,做并行探測并同時建立連接。對最優鍊路的選擇,依賴于建連延遲、心跳間隔、鍊路發送接收狀況等信息。服務器也會定期檢查連接的健康度,主動關閉長尾連接,結合客戶端的重連機制,一起保障對最優鍊路的調用。

PaaS 産品接近完備,或将填補元宇宙到來前的空白

除了技術實現,挑戰也出現在産品設計層面。

由于超級群中的信息量太大,需要支持将群分割為不同的頻道,類似傳統的 topic 或 channel。即使相同的群和群成員,通過不同的頻道,仍然能将會話、消息、未讀數分門别類聚合。用戶可以更關注自己感興趣的部分,提升用戶黏性。

這也反映了用戶在超級群場景下的真正需求:我或許會希望在一個有數十萬網友的超級群中建立社交關系,但卻不希望被數十萬消息打擾生活。

此外,對于融雲來說,超級群是個 PaaS 産品,這意味着要為客戶端留下充裕的可定制空間,在不同的場景,對信息推送的方式、邏輯、頻率都有不同的要求。同時,将信息和聊天結合的場景,一般都有多端的需求。不同的平台,比如 Android、iOS、Web 等,在海量消息的網絡請求和存儲方面都有不同的技術特點,甚至同平台不同廠商的推送通道特性也不同,這些都需要一一考慮。

最近幾年,社交領域的新興公司新增不多,整體增長呈下降趨勢。這一方面是因為流量向頭部高度集中,擠壓了新玩家的空間;另一方面也是因為缺少新模式,大家仍在圍繞存量用戶做競争。

超級群這一新應用形态,可能會對社交軟件整體的發展,産生巨大的牽引作用,從而帶來新的機會。同時,PaaS 産品的完備,也标志着實現産品創新的技術基礎已經夯實,這或将在産品層面,填補從微信、語聊房邁入元宇宙的最後一段空白。

,
Comments
Welcome to tft每日頭條 comments! Please keep conversations courteous and on-topic. To fosterproductive and respectful conversations, you may see comments from our Community Managers.
Sign up to post
Sort by
Show More Comments
Copyright 2023-2024 - www.tftnews.com All Rights Reserved