主要从直播弹幕系统必备的高稳定、高可用、低延迟这三个方面出发，主要分享了bilibili直播弹幕服务架构上的最新实践。以下为正文：
高并发实时弹幕是一种互动的体验。对于互动来说，考虑最多的地方就是：高稳定性、高可用性以及低延迟这三个方面。
高稳定性，为了保证互动的实时性，所以要求连接状态稳定；
高可用性，相当于提供一种备用方案，比如，互动时如果一台机器挂了，此时必须保证可以和另外一台机器连接，这样就从侧面解决了，用户连接不中断的问题；
低延迟，弹幕的延迟周期控制在1秒以内，响应是比较快的，所以可以满足互动的需求。
B站直播弹幕服务架构(下面简称GOIM)的出现就是为了解决这一系列的需求。下面将对此进行详细的介绍。
图 1
直播聊天系统本质上也是一种推送系统，所谓推送系统就是，当你发送一条消息时，它可以将这个消 息推送给所有人。对于直播弹幕来说，用户在不断的发送消息，不断的进行广播，当一个房间里面有10万人时，一个消息就要发出10万次请求。在GOIM出现 之前，也用过另一个名为Gopush的项目，这个项目推出的目的就是进行推送。在此之后，基于一些针对性的应用场景，GOIM对Gopush进行了优化， 从而出现在我们视野当中。GOIM主要包含以下几个模块
(图1)
1. Client
客户端。与Comet建立链接。
2. Comet
维护客户端长链接。在上面可以规定一些业务需求，比如可以规定用户传送的信息的内容、输送用户信息等。Comet提供并维持服务端与客户端之间的链接，这里保证链接可用性的方法主要是发送链接协议(如Socket等)
3. Logic
对消息进行逻辑处理。用户建立连接之后会将消息转发给Logic，在Logic上可以进行账号验证。当然，类似于IP过滤以及黑名单设置此类的操作也可以经由Logic进行。
4. Router
存储消息。Comet将信息传送给Logic之后，Logic会对所收到的信息进行存储，采用register session的方式在Router上进行存储。Router里面会收录用户的注册信息，这样就可以知道用户是与哪个机器建立的连接。
5. Kafka(第三方服务)
消息队列系统。Kafka是一个分布式的基于发布/订阅的消息系统，它是支持水平扩展的。每条发布到Kafka集群的消息都会打上一个名为Topic(逻辑上可以被认为是一个queue)的类别，起到消息分布式分发的作用。
6. Jop
消息分发。可以起多个Jop模块放到不同的机器上进行覆盖，将消息收录之后，分发到所有的Comet上，之后再由Comet转发出去。
以上就是GOIM系统实现客户端建立链接，并进行消息转发的一个具体过程。一开始这个结构并不完善，在代码层面也存在一些问题。鉴于这些问题，B站提供了一些相关的优化操作。在高稳定性方面，提供了内存优化、模块优化以及网络优化，下面是对这些优化操作的介绍。
