实时鼠标指针
内容提要
Canva协作团队分享了他们在白板产品中实现实时鼠标指针的经验。他们最初使用了Websockets和Redis作为后端架构，但后来转向了WebRTC以获得更好的可扩展性和更低的延迟。他们在服务器实例之间传递鼠标指针位置时遇到了挑战，并使用了Redis Streams和PubSub的组合。该架构成功扩展到支持数十万用户。他们还通过使用二进制序列化和手动刷新Redis命令来优化CPU消耗。他们计划进一步改进架构以支持更高速率的位置更新。
延伸解读
从WebSocket到WebRTC：架构演进的关键考量
Canva团队最初采用WebSocket+Redis的架构，成功支撑了数十万用户和每秒10万次鼠标位置更新，但为了支持更高的更新频率（目标60次/秒），他们转向了WebRTC。这一转变的核心在于：WebRTC允许客户端直接点对点通信，绕过服务器中转，从而降低延迟和后端负载。然而，WebRTC也带来了前端复杂度的增加，例如需要处理信令、NAT穿透和连接状态管理。对于需要高吞吐量实时交互的应用，WebRTC是更优选择，但迁移过程需谨慎，Canva通过同时支持两种协议并优先使用WebRTC来保证平稳过渡。
Redis在实时消息传递中的优化实践
在WebSocket架构中，Canva使用Redis Streams和PubSub组合来传递消息：Streams用于需要可靠交付的会话控制信息，PubSub用于高频的鼠标位置更新。他们发现Redis 6.2的PubSub在集群中无法水平扩展，因此单独部署了一个单节点Redis实例处理PubSub，成功支撑了全部流量。此外，通过二进制序列化（protobuf替代JSON）和手动刷新Redis命令（禁用Lettuce的自动刷新并批量发送），分别降低了30%的后端CPU和Redis CPU消耗。这些优化对于构建高吞吐量的
WebRTC落地中的挑战与应对策略
WebRTC的mesh拓扑要求每个客户端与其他所有客户端建立连接，当用户数较多时，连接数会呈平方增长，因此Canva选择mesh是为了最小化后端负载。在实际部署中，约50%的连接需要通过TURN服务器中继，这会产生额外流量成本。此外，连接碰撞、旧浏览器兼容性以及连接状态管理都需要复杂的前端逻辑。Canva通过随机ID解决碰撞，使用adaptor.js处理兼容性，并优先由发起方管理连接状态。这些经验表明，WebRTC虽然能提升实时性，但需要投入更多工程资源来保证稳定性和用户体验。
Q&A
Canva团队是如何实现实时鼠标指针的？
Canva团队最初使用Websockets和Redis作为后端架构，后来转向WebRTC以提高可扩展性和降低延迟。
使用WebRTC的优势是什么？
WebRTC允许客户端之间建立点对点连接，减少延迟和后端负载，适合高吞吐量的实时应用。
Canva在实现实时鼠标指针时遇到了哪些挑战？
主要挑战是支持所有用户同时发送鼠标指针位置的基础设施的可靠性和复杂性。
Canva的架构如何优化CPU消耗？
通过使用二进制序列化和手动刷新Redis命令来优化CPU消耗，减少了30%的负载。
Canva计划如何进一步改进实时鼠标指针功能？
计划支持更高频率的位置更新，目标是每秒60次更新，以提升用户体验。
Websockets和WebRTC的主要区别是什么？
Websockets适合实时数据传输，而WebRTC提供更低延迟的点对点连接，适合高吞吐量应用。
