Design Facebook Live Comments

最新推荐文章于 2024-10-03 17:11:20 发布

xxxmmc

最新推荐文章于 2024-10-03 17:11:20 发布

阅读量915

点赞数 10

文章标签：系统架构

本文链接：https://blog.csdn.net/xxxmmc/article/details/142023304

版权

Design Facebook Live Comments

Core Requirements

Viewers can post comments a live video need
Viewers will see all the comments in near time
Viewers can view the previous comments

Non-functional Requirements

availability > consistency
scale to big users
low latency 200ms comment broadcast

Core Entities

Comments
Live Video
User

API Design

POST /comment/create {
“liveVideoId”: “123”,
“message”: “xxx”
}

GET /comment/:liveVideoId

High level design

在这里插入图片描述

Viewers will see all the comments in near time, we need to adopt SSE(server-sent event). It’s a persistent connection. Server -> Client, Client X Seversince it’s a write << read system. When a user publishes a comment it will get broadcasted to every users. Compared with websocket it saves more resources.
Challenges: if the connections are routinely based accross multiple severs then we need to configure the load balancer pretty careful to maintain the connections.(简单来说要维持这个链接需要很小心的配置，头脑中要想着跟http比较)
handling reconnections need extra effort
pagnition. cursor pagnition+ cache的做法 cursor pagnition是分页的意思，在get请求体中，GET /comment/:liveVideoId？cursor={commentId}pagesize=10. 每次用户想加载更多评论时，都使用上一次响应中最后一条评论的 ID 作为新的 cursor。+ cache的意思是说我一次性先load 10*N条评论，放进cache里，query的时候先query cache中的
Challenge: cache和database的sync是一个问题，cache invalidation和更新是个比较复杂的问题

Deep Dive

我应该如何让我的system来支持成百上千万的用户？<=>
how do we distribute the load across multiple servers and how does each server know which comments to send to which viewers?
首先我需要多出一个real messaging service.这个service的目的sending comments to viewers，隔离原先的comment management service
两个service之间我需要有一个redis pub/sub，根据topic来subscribe

每个服务器需要处理它所连接的观众正在观看的所有直播的评论。
负载均衡器使用轮询方式分配新的连接，而不考虑服务器当前的负载情况。

为什么这个依旧不太好
现在，让我们逐步分析这个场景：S是server
初始状态：
S1: 直播A, 直播B, 直播C
S2: 直播D, 直播E, 直播F
S3: 直播G, 直播H, 直播I

这种状态看起来很均衡，因为每个服务器都处理3个不同的直播流。
接下来，假设有3个新观众加入，他们恰好选择了3个全新的直播：

新观众1选择观看直播J

负载均衡器将其分配给S1
S1现在需要处理4个直播流：A, B, C, J


新观众2选择观看直播K

负载均衡器将其分配给S2
S2现在需要处理4个直播流：D, E, F, K


新观众3选择观看直播L

负载均衡器将其分配给S3
S3现在需要处理4个直播流：G, H, I, L



结果：

S1: 直播A, 直播B, 直播C, 直播J
S2: 直播D, 直播E, 直播F, 直播K
S3: 直播G, 直播H, 直播I, 直播L
也就是说在非常复杂的情况下我的每个server还是要接收到所有的topic

造成这个问题的主要原因是当用户和服务器建立连接的时候，他是round robin分配connection

优化：layer 7 load balancer
在customer连接上server的时候，不是round robin连接，而是智能连接，这样的话我这一个server需要接收到的topic是固定的，
坏处的话是说在高峰期其实这个server是unbalanced

技术选型：在pub/sub system里面
For example, Kafka is a popular pub/sub system that is highly scalable and fault-tolerant, but it has a hard time adapting to scenarios where dynamic subscription and unsubscription based on user interactions, such as scrolling through a live feed or switching live videos, is required， operational complexity. Redis, on the other hand, is a more suitable option for scenarios requiring dynamic subscription and unsubscription thanks to its efficient in-memory storage and support for both blocking and non-blocking consumption methods, leading to improved latency.