譯者 | 李睿

審校 | 梁策 孫淑娟

什么是觀眾參與?

在線觀眾參與的一個簡單示例是：帶有主持人的直播和供觀眾成員實時互動的聊天系統。其他觀眾參與解決方案包括觀影派對、投票、測驗和排行榜等活動，涵蓋在線聊天或提問回答等功能，供參與者在分享體驗的同時進行交流。

1.設備和用戶在場

了解觀眾參與的一個方面是能夠知道誰在參與虛擬活動或用戶的“在場”。與在場情況密切相關的是用戶的狀態，這有關基本功能的實現，例如當有人在聊天窗口中鍵入消息時的指示，或設備的實時位置。

2.聊天

發送聊天消息是觀眾互動并向在線活動(例如直播)的主持人發送即時反饋的一種常用方式。Twitch就是一個早期例子，它很受游戲玩家的歡迎，讓玩家通過流媒體玩游戲，或通過網絡攝像頭實時觀看和評論游戲。

3.調查投票和提問回答

民意調查和提問回答是觀眾參與的額外環節。例如，主持人可能會問直播觀眾，“你最喜歡什么口味的冰淇淋?”并為參與者提供一個網頁，讓他們可以從一系列口味選項中進行在線投票，觀眾的答案可被實時可視化，以為條形圖、餅圖、甚至是文字云形式顯示在直播中，從而吸引觀眾參與。當參與者提交投票時，這類調查可能會讓響應激增。

提問回答的方式則與之相反。在線活動的主持人將共享一個鏈接，參與者可以跟蹤該鏈接并輸入問題和評論，以了解更多信息或實時給出反饋。

4.測驗功能和游戲化

另一種吸引觀眾的方式是多人知識競賽，參與者參加現場提問，回答問題，并在排行榜上查看他們的分數。競賽可以在獨立平臺上或集成到直播中，這在教育領域尤其流行。Mentimeter、Wooclap、Kahoot、Slido和HQTrivia等都是受歡迎的產品。

參與者使用邀請鏈接登錄特定的競賽，當問題實時出現時，他們會在自己的設備上回答問題，然后其分數會顯示在排行榜上，以添加游戲化元素。為公平起見，參與者有作答時限。需要同時向所有玩家發送問題(扇出)，且隨著他們在倒計時前完成挑戰，也會有相應地響應激增(扇入)。

實時更新鞏固了觀眾參與度

為了使上面列出的功能具有吸引力，它們需要以“實時”或接近實時的方式呈現，也就是低于人類感知的100毫秒閾值。建立在實時系統上的技術使用一系列事件(例如異步對話)，而不是典型同步通信的請求和響應范例。

事件驅動架構服務的用例需要立即處理數據，以提供令人滿意的用戶體驗。它消除了阻塞或持續輪詢的需要，并在感興趣的事件發生時通知應用程序代碼。

發布和訂閱(pub/sub)模式是事件驅動系統中的典型。當狀態發生變化時，事件生產者(發布者)發送事件消息，然后事件訂閱者使用它們。通常情況下，發布者和訂閱者之間會有一個專門的代理，使事件制作者能夠將責任轉移給代理，代理將大量通知發送給不同設備和平臺的消費者。

代理還將從生產者接收到的事件記錄為消息。事件歷史記錄會保留一定時間，以便訂閱者可以從任何特定點讀取事件歷史記錄。

構建實時架構的技術挑戰

實時的、事件驅動的架構是一個分布式系統，具有相關的可靠性、延遲和帶寬問題，網絡的不可預測性是一個重大挑戰。

1.消息完整性

在事件驅動的系統中，丟失、重復或無序的消息可能會產生重大后果。例如，聊天消息，它就依賴于明確定義的消息序列。如果它們無序到達或丟失，會給用戶體驗帶來缺陷。

• 丟失的消息

用戶的連接可以斷開并重新連接：例如他們出現電源故障或網絡上出現系統問題，他們正在移動，或者關閉聊天應用程序并稍后重新啟動。

從用戶的角度來看，由于連接不穩定而丟失消息是不可接受的。因此，當用戶重新連接時，應用程序需要以最小損害程度從用戶斷開連接之前的那一點重新開始。任何錯過的消息都需要在不復制已處理的消息的情況下傳遞，整個體驗需要完全無縫。

大多數事件驅動系統使用至少一次交付。當代理向事件消費者發送消息時，它需要確認已收到消息。如果代理沒有收到確認，它會再次發送消息，以確保它在第一次發送時沒有丟失(并將繼續發送消息直到收到確認為止)。但是，如果收到消息并且確認丟失了怎么辦?任何最近的消息現在都是原始消息的副本。

• 消息復制和排序

如果事件驅動系統使用冪等消息，則消息重復是可以接受的，冪等消息可以被多次處理，但在第一次之后不會更改系統。例如，對加熱恒溫器進行編程。如果在回家前輸入房間需要達到的準確溫度，那么指令是否發送多次并不重要。

恒溫器將設置為所需的溫度，可能會重復設置，但仍將是想要的溫度。但是，如果要求把空調的溫度調高，并且被多次發送的話，那么其高溫可能讓人難以忍受。

聊天應用程序中的消息重復對用戶來說與丟失消息或亂序消息一樣令人厭煩。一種常見的方法是，如果消息無法以任何順序成功處理，則使用唯一ID對消息進行排序。

除了冪等消息類型之外，許多事件驅動系統使用一次性處理保證來協調與重復消息相關的問題。應用重復數據消除過程，以便檢測并丟棄先前處理的消息。

2.性能

網絡延遲是數據到達目的地所需的時間，是成功吸引受眾的關鍵因素。在大規模分布式系統中，延遲在節點之間傳播得越遠，其性能就越差。

高延遲會完全破壞實時音頻通信和視頻質量，性能考慮全球受眾，或在互聯網基礎設施較差的地區托管用戶變得越來越重要。

低網絡延遲是由于自地理位置接近。數據應通過托管數據中心和邊緣加速點盡可能靠近用戶。然而，將延遲最小化是不夠的。用戶體驗需要將延遲差異降至最低，以確保可預測性。

服務器性能(處理速度、使用的硬件、可用內存)和延遲之間也存在很強的相關性。為了防止網絡擁塞和服務器超載，必須能夠動態增加服務器層的容量并重新分配負載。

3.可用性

觀眾參與度的一個特殊方面是無法預測會有多少參與者。對于許多活動來說，直到活動開始前幾小時或幾分鐘才能知道觀眾人數。這帶來的技術挑戰是，在任何支持該事件的系統中，都很難規劃和提供足夠的容量。

在處理大量負載的情況下，實現可用性和彈性，以滿足嚴格的正常運行時間要求不僅僅是故障切換這樣的傳統機制，而是關于管理容量的。面臨的挑戰是橫向擴展并迅速吸收數百萬個連接，而無需預先調配。

為確保網絡能夠適應此類情況，需要監控以下指標：

• 工作負載的百分比
• 負載的彈性和分布
• 最大連接數和吞吐量

當超過某些閾值時，采用一些辦法自動、動態地提供額外的容量，這對于確保超高的正常運行時間至關重要。

優化應包括最小化傳輸的數據量，例如，減少消息大小，僅發送對數據的更改(增量)而不是整個有效負載。

4.可靠性

可靠性至關重要，因為如果活動因故障而無法運行或中斷，會給主持人造成尷尬。觀眾參與的實時平臺需要具有容錯性，以便即使組件發生故障也可以繼續運行。

為了實現容錯，需要有多個組件能夠在某些組件丟失時維護系統。即使在多個基礎設施出現故障的情況下，區域和全球層面的冗余也能確保服務的連續性。不應該有單點擁塞和單點故障。

當一個或多個組件發生故障時，其余組件需要自行支持服務。了解可以容忍多少區域故障(例如，每秒實例故障的數量)至關重要。如果一個區域因故障轉移到另一個區域而脫機，則需要有足夠的容量來吸收額外的流量，即使在峰值負載下也是如此。

可靠性四大支柱

要構建一個為實時觀眾參與提供基礎的系統，需要具有低延遲、可擴展性和彈性的容錯基礎架構，以及確保消息傳遞完整性的架構。

企業如果為滿足業務具體要求構建自定義解決方案，可能終會背負基礎設施所有權、技術債務以及對工程持續投資帶來的高昂成本。

對于許多企業來說，將規模、延遲、數據完整性和可靠性的責任轉移到Ably這樣的第三方供應商更經濟，這些第三方供應商應具有性能、完整性、可靠性和可用性的四大可靠性支柱。

在構建實時解決方案以支持大規模受眾方面，這些平臺可以讓擔憂不復存在。因此企業可以專注于其核心產品，優先考慮受眾參與規劃，進而開發更多功能以保持競爭力。

原文標題：Realtime Challenges for Audience Engagement，作者：Jo Stichbury