golang barrage system

goima>是B站开源的一个方便横向扩容的im系统，用来做聊天室系统非常合适，代码质量也非常不错。 组件 router, logic, comet, job

主要是 logic, comet

两个对外的服务

logic 是一个消息发生上行服务， 广告过滤系统集成在里面

comet 是一个支持ws和tcp协议的消息下发服务

job, router对内

job只是负责从kafka中获取msg， 根据策略，将消息rpc call 到comet

router 是一个状态保持服务， 设计原意是为了保存 uid --> comet, 达到可以发消息给指定uid的功能

内部使用rpc方式做调用

• logic --> router的访问负载中， 用hashRing方式做一致性hash代替普通hash方式， 来让uid分布到各个router

• 我们自己把广告过滤集成在里面， 是采用一个全局的manager 管理所有filter， 进程起来的时候， 初始化这些filter， filter跑在线程里， 可配置一个缓冲区长度，

• 为每个请求产生一个Msg的struct对象， 结果和回调函数， 绑定在对象上， 在channel中传递，过滤完成后，产生kafka消息， 和redis消息。

comet 个人已修复或完善了这些内容：

• 支持ws协议，不过B站自己没有使用， 测试也比较随意。更推荐是使用tcp的方式， ws发生text类型，冗余太多，耗流量， 且每条产生一个syscall，系统负担较大.

• 丢失消息的bug， 很容易重现

• 单个msgProto的body内， 有包含多个儿子msgProto的对象， 没办法支持ws message文本方式下发消息的方式。逐个把原设计中的大包， 拆成小包，再给ws下发. 同时也让它支持batch的方式

• 内存泄露的问题， 不只是ws协议下， tcp下应该也有。 闭包的问题导致连接对象的引用被hold住， 理论上是存在释放的机会的， 取决于timer的配置大小。

好的设计

• tcp方式下， 使用了自分配内存池， 预申请， 之后用这片内存池做readBuff和WriteBuff：

  • 主要是由Buffer对象组成的一个链表结构， 每个Buffer对象内是一个[]byte数组，不过它只是Pool对象内buf数组的引用， Pool的大小是 num * size个byte， Pool的grow()完成malloc，
  • 每个连接建立后会去Pool内拿内存， 创建一个自己的Writer， Writer也是经过封装的，这个Writer相当于在conn.Writer上层做了一次包装，缓冲一下，减少系统调用， 具体缓冲多少，是由Pool设置中的size来决定的。
  • job到comet调用过程中的buffer设计， 缓存短时间片内的房间消息， 防止频率过高的调用，但是buf每次都重新产生， 略有点耗。
  • comet中heartbeat协议侦的方式， 是用Ring buffer算法， 复用heartbeat对象，免去重复创建。
  • 封装的timer，做tick或是timeout callback，一样为了在高频率情况下，复用timer对象， 方便让上层调用者保持简洁的代码。
  • comet结构是 Bucket->room->Channel, 简化消息传递的时候， 寻找的复杂度。 广播类型， 直接走所有Bucket中的chs，到达最终连接，

room广播时， 先到Bucket的一个chan， 有多个线程处理将消息交给最终的room， 到达room下的所有连接。

• 有不少的地方， 使用map，代替array，比如 一个 []string的方式能实现了， 用 map[string]struct{}， map的查找，插入，删除均是O(1), 而array的插入和删除是O(n)，会涉及内存拷贝。

PS 关于golang的map性能， 官方是说不确保map一定在哪个性能， 似乎是个树实现， 而不是hashtable， 所以不一定是O(1)， 可能是O(logN)