译者 | 李睿

审校 | 梁策 孙淑娟

什么是观众参与?

在线观众参与的一个简单示例是：带有主持人的直播和供观众成员实时互动的聊天系统。其他观众参与解决方案包括观影派对、投票、测验和排行榜等活动，涵盖在线聊天或提问回答等功能，供参与者在分享体验的同时进行交流。

编辑搜图

1.设备和用户在场

了解观众参与的一个方面是能够知道谁在参与虚拟活动或用户的“在场”。与在场情况密切相关的是用户的状态，这有关基本功能的实现，例如当有人在聊天窗口中键入消息时的指示，或设备的实时位置。

2.聊天

发送聊天消息是观众互动并向在线活动(例如直播)的主持人发送即时反馈的一种常用方式。Twitch就是一个早期例子，它很受游戏玩家的欢迎，让玩家通过流媒体玩游戏，或通过网络摄像头实时观看和评论游戏。

3.调查投票和提问回答

民意调查和提问回答是观众参与的额外环节。例如，主持人可能会问直播观众，“你最喜欢什么口味的冰淇淋?”并为参与者提供一个网页，让他们可以从一系列口味选项中进行在线投票，观众的答案可被实时可视化，以为条形图、饼图、甚至是文字云形式显示在直播中，从而吸引观众参与。当参与者提交投票时，这类调查可能会让响应激增。

提问回答的方式则与之相反。在线活动的主持人将共享一个链接，参与者可以跟踪该链接并输入问题和评论，以了解更多信息或实时给出反馈。

4.测验功能和游戏化

另一种吸引观众的方式是多人知识竞赛，参与者参加现场提问，回答问题，并在排行榜上查看他们的分数。竞赛可以在独立平台上或集成到直播中，这在教育领域尤其流行。Mentimeter、Wooclap、Kahoot、Slido和HQTrivia等都是受欢迎的产品。

参与者使用邀请链接登录特定的竞赛，当问题实时出现时，他们会在自己的设备上回答问题，然后其分数会显示在排行榜上，以添加游戏化元素。为公平起见，参与者有作答时限。需要同时向所有玩家发送问题(扇出)，且随着他们在倒计时前完成挑战，也会有相应地响应激增(扇入)。

实时更新巩固了观众参与度

为了使上面列出的功能具有吸引力，它们需要以“实时”或接近实时的方式呈现，也就是低于人类感知的100毫秒阈值。建立在实时系统上的技术使用一系列事件(例如异步对话)，而不是典型同步通信的请求和响应范例。

事件驱动架构服务的用例需要立即处理数据，以提供令人满意的用户体验。它消除了阻塞或持续轮询的需要，并在感兴趣的事件发生时通知应用程序代码。

发布和订阅(pub/sub)模式是事件驱动系统中的典型。当状态发生变化时，事件生产者(发布者)发送事件消息，然后事件订阅者使用它们。通常情况下，发布者和订阅者之间会有一个专门的代理，使事件制作者能够将责任转移给代理，代理将大量通知发送给不同设备和平台的消费者。

代理还将从生产者接收到的事件记录为消息。事件历史记录会保留一定时间，以便订阅者可以从任何特定点读取事件历史记录。

编辑搜图

构建实时架构的技术挑战

实时的、事件驱动的架构是一个分布式系统，具有相关的可靠性、延迟和带宽问题，网络的不可预测性是一个重大挑战。

1.消息完整性

在事件驱动的系统中，丢失、重复或无序的消息可能会产生重大后果。例如，聊天消息，它就依赖于明确定义的消息序列。如果它们无序到达或丢失，会给用户体验带来缺陷。

• 丢失的消息

用户的连接可以断开并重新连接：例如他们出现电源故障或网络上出现系统问题，他们正在移动，或者关闭聊天应用程序并稍后重新启动。

从用户的角度来看，由于连接不稳定而丢失消息是不可接受的。因此，当用户重新连接时，应用程序需要以最小损害程度从用户断开连接之前的那一点重新开始。任何错过的消息都需要在不复制已处理的消息的情况下传递，整个体验需要完全无缝。

大多数事件驱动系统使用至少一次交付。当代理向事件消费者发送消息时，它需要确认已收到消息。如果代理没有收到确认，它会再次发送消息，以确保它在第一次发送时没有丢失(并将继续发送消息直到收到确认为止)。但是，如果收到消息并且确认丢失了怎么办?任何最近的消息现在都是原始消息的副本。

• 消息复制和排序

如果事件驱动系统使用幂等消息，则消息重复是可以接受的，幂等消息可以被多次处理，但在第一次之后不会更改系统。例如，对加热恒温器进行编程。如果在回家前输入房间需要达到的准确温度，那么指令是否发送多次并不重要。

恒温器将设置为所需的温度，可能会重复设置，但仍将是想要的温度。但是，如果要求把空调的温度调高，并且被多次发送的话，那么其高温可能让人难以忍受。

聊天应用程序中的消息重复对用户来说与丢失消息或乱序消息一样令人厌烦。一种常见的方法是，如果消息无法以任何顺序成功处理，则使用唯一ID对消息进行排序。

除了幂等消息类型之外，许多事件驱动系统使用一次性处理保证来协调与重复消息相关的问题。应用重复数据消除过程，以便检测并丢弃先前处理的消息。

2.性能

网络延迟是数据到达目的地所需的时间，是成功吸引受众的关键因素。在大规模分布式系统中，延迟在节点之间传播得越远，其性能就越差。

高延迟会完全破坏实时音频通信和视频质量，性能考虑全球受众，或在互联网基础设施较差的地区托管用户变得越来越重要。

低网络延迟是由于自地理位置接近。数据应通过托管数据中心和边缘加速点尽可能靠近用户。然而，将延迟最小化是不够的。用户体验需要将延迟差异降至最低，以确保可预测性。

服务器性能(处理速度、使用的硬件、可用内存)和延迟之间也存在很强的相关性。为了防止网络拥塞和服务器超载，必须能够动态增加服务器层的容量并重新分配负载。

3.可用性

观众参与度的一个特殊方面是无法预测会有多少参与者。对于许多活动来说，直到活动开始前几小时或几分钟才能知道观众人数。这带来的技术挑战是，在任何支持该事件的系统中，都很难规划和提供足够的容量。

在处理大量负载的情况下，实现可用性和弹性，以满足严格的正常运行时间要求不仅仅是故障切换这样的传统机制，而是关于管理容量的。面临的挑战是横向扩展并迅速吸收数百万个连接，而无需预先调配。

为确保网络能够适应此类情况，需要监控以下指标：

• 工作负载的百分比

• 负载的弹性和分布

• 最大连接数和吞吐量

当超过某些阈值时，采用一些办法自动、动态地提供额外的容量，这对于确保超高的正常运行时间至关重要。

优化应包括最小化传输的数据量，例如，减少消息大小，仅发送对数据的更改(增量)而不是整个有效负载。

4.可靠性

可靠性至关重要，因为如果活动因故障而无法运行或中断，会给主持人造成尴尬。观众参与的实时平台需要具有容错性，以便即使组件发生故障也可以继续运行。

为了实现容错，需要有多个组件能够在某些组件丢失时维护系统。即使在多个基础设施出现故障的情况下，区域和全球层面的冗余也能确保服务的连续性。不应该有单点拥塞和单点故障。

当一个或多个组件发生故障时，其余组件需要自行支持服务。了解可以容忍多少区域故障(例如，每秒实例故障的数量)至关重要。如果一个区域因故障转移到另一个区域而脱机，则需要有足够的容量来吸收额外的流量，即使在峰值负载下也是如此。

可靠性四大支柱

要构建一个为实时观众参与提供基础的系统，需要具有低延迟、可扩展性和弹性的容错基础架构，以及确保消息传递完整性的架构。

企业如果为满足业务具体要求构建自定义解决方案，可能终会背负基础设施所有权、技术债务以及对工程持续投资带来的高昂成本。

对于许多企业来说，将规模、延迟、数据完整性和可靠性的责任转移到Ably这样的第三方供应商更经济，这些第三方供应商应具有性能、完整性、可靠性和可用性的四大可靠性支柱。

在构建实时解决方案以支持大规模受众方面，这些平台可以让担忧不复存在。因此企业可以专注于其核心产品，优先考虑受众参与规划，进而开发更多功能以保持竞争力。