支撑百万用户同时在线的高并发直播弹幕系统是如何炼成的？

正文

请到「今天看啥」查看全文

读消息流程是:  前端 -> Redis。

不过这里有一个隐藏的并发问题：用户可能丢消息。

如上图所示，某个用户从第 6 号评论开始拉取，同时有两个用户在发表评论，分别是 10 ， 11 号评论。

如果 11 号评论先写入，用户刚好把 6 ， 7 ， 8 ， 9 ， 11 号拉走，用户下次再拉取消息，就从 12 号开始拉取，结果是：用户没有看到 10 号消息。

为了解决这个问题，我们加上了两个机制：

• 在前端机， 同一个直播间的同一种消息类型，写入 Kafka 的同一个 partition。

• 在处理机， 同一个直播间的同一种消息类型，通过 synchronized 保证写入 Redis 的串行。

消息模型及并发问题解决后，开发就比较顺畅，系统很快就实现上线，达到了预先设定的目标。

上线后暴露问题的解决

上线后，随着消息量的逐渐增加，系统陆续暴露出三个比较严重的问题，我们一一进行了解决。

问题一：消息串行写入 Redis，如果某个直播间消息量很大，那么消息会堆积在 Kafka 中，消息延迟较大。

解决办法：

• 消息写入流程：前端机-> Kafka -> 处理机 -> Redis。

• 前端机：如果延迟小，则只写入一个 Kafka 的 partion；如果延迟大，则这个直播的这种消息类型写入 Kafka 的多个 partion。

• 处理机：如果延迟小，加锁串行写入 Redis；如果延迟大，则取消锁。

  因此有四种组合，四个档位，分别是：

• 一个 partion ， 加锁串行写入 Redis, 最大并发度：1。

• 多个 partition ， 加锁串行写入 Redis ， 最大并发度：Kafka partion的个数。

• 一个 partion ， 不加锁并行写入 Redis ， 最大并发度：处理机的线程池个数。

• 多个 partion ， 不加锁并行写入 Redis，最大并发度: Kafka partition 个数处理机线程池的个数。

• 延迟程度判断：前端机写入消息时，打上消息的统一时间戳，处理机拿到后，延迟时间 = 现在时间 - 时间戳。

• 档位选择：自动选择档位，粒度：某个直播间的某个消息类型。

问题二：用户轮询最新消息，需要进行 Redis 的 ZrangByScore 操作，redis slave 的性能瓶颈较大。

请到「今天看啥」查看全文