设计一个70w在线人数弹幕系统所需技术

原文：原文地址

下面主要对优化过程中需要的技术进行阐述：

带宽压力

http请求压缩

一个http数据包请求由4个部分组成：请求行、请求头标、空行、请求数据。

请求行分为了三个部分。请求方法，请求url与http版本。
请求头行，由关键字值对组成，使用：分隔
空行
请求数据，请求正文中可以包含客户提交的查询字符串信息。

使用http gzip进行将请求中内容进行压缩将传输的内容，解决传输过程中的带宽压力，原理就是把原来的请求头内容压缩，类似于平时使用压缩包，也可以进行请求头结构优化

频率控制

带宽控制：通过添加请求间隔参数（下次请求时间），保证客户端的请求频率服务端可控。以应对突发的流量增长问题，提供有损的服务。

稀疏控制：在弹幕稀疏和空洞的时间段，通过控制下次请求时间，避免客户端的无效请求。

这种可以通过sentinel的链路控制进行配置

弹幕卡顿，丢失问题

Long Polling via AJAX

客户端向服务器发送Ajax请求，服务器接到请求后保持住连接，直到有新消息才返回响应信息，客户端处理完响应信息后再向服务器发送新的请求。这样做的好处是可以省去很多无用的请求。但是需要服务端保持大量的连接。

WebSockets通信

WebSocket。服务器可以主动向客户端推送信息，客户端也可以主动向服务器发送信息，是真正的双向平等对话。在WebSocket API中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。

TCP长连接与短连接

短连接环境下，数据交互完毕后，主动释放连接。
长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。
在上文中，由于东南亚的弱网环境，tcp长连接也会因为网络问题断开，所以无论是Long Polling via AJAX还是WebSockets通信都不符合我们的业务需要。

服务拆分

发送弹幕与查询弹幕完全不在同一个量级，通过将业务进行拆分，将发送弹幕逻辑与查询弹幕逻辑拆分。可以让两个服务不互相影响，保证服务的可用性。

引入本地缓存

引入本地缓存的好处是，用户不必等待数据返回，而是读取内存中缓存的数据，大幅度降低调用时延

总结：

设计一个支持700,000在线人数的弹幕系统涉及多个方面的技术和架构选择。以下是可能涉及的一些关键技术和组件：

分布式架构： 为了支持如此大规模的在线人数，需要采用分布式架构，将负载分散到多个服务器上。可以考虑使用微服务架构，将不同的功能模块拆分为独立的微服务。

负载均衡： 使用负载均衡技术，将用户的请求分发到多个服务器上，以确保各个服务器的负载均衡。

消息队列： 使用消息队列系统来处理弹幕消息的发送和接收，例如使用Kafka或RabbitMQ。消息队列可以异步处理消息，减少对主服务器的直接压力。

实时数据处理： 弹幕系统需要实时处理大量的弹幕消息，可以考虑使用流式处理框架，如Apache Flink或Apache Kafka Streams，来处理实时数据。

数据库设计： 使用高性能的数据库，如NoSQL数据库（如MongoDB、Cassandra）或专门针对实时数据处理的数据库（如Redis）来存储和查询弹幕数据。

缓存技术： 使用缓存技术来缓存热门弹幕和用户信息，以减少数据库访问压力。可以考虑使用分布式缓存系统，如Redis集群。

网络协议： 使用高效的网络协议，如WebSocket，以支持实时的弹幕消息传输。

安全和认证： 为了确保系统的安全性，需要实施用户身份验证和授权机制，以防止恶意用户的滥用。

监控和分析： 集成监控和分析工具，以实时监测系统的性能和运行状态，并进行及时的故障排除和优化。

容灾和扩展性： 考虑到系统的可用性，需要实施容灾机制，如多活架构、冗余部署等。同时，要考虑系统的扩展性，以便在需要时可以方便地添加更多的资源。

实时搜索和过滤： 提供实时搜索和过滤功能，让用户可以根据关键词、用户等条件过滤和查找弹幕。

实时推送： 使用推送技术，如WebSocket或Server-Sent Events（SSE），将实时弹幕消息推送给用户。

容器化和自动化： 使用容器化技术（如Docker、Kubernetes）来部署和管理系统，以及自动化部署流程。

以上只是一些可能的技术和组件，实际的弹幕系统设计需要根据具体的业务需求和架构考虑来进行调整和定制。同时，对于如此大规模的系统，还需要进行性能测试和优化，以确保系统能够稳定运行并满足用户需求。