哔哩哔哩直播统计项目

b站弹幕是用的ws与服务器连接来接收/发送消息的
这个弹幕和礼物的推送我感觉并不是很可靠,很有可能会有网络波动或连接断开的情况,所以我选择多个线程同时监听弹幕服务器的推送(当然多个线程可以选择跑在不同的进程跑在不同的机器上).

然后的问题是,把消息往mq里塞,还要消息不重复传.我这里没有选择用自带去重功能的rocketMQ,而是用的kafka(毕竟kafka性能和多语言客户端支持比rocketMQ好),三个Producer往mq里写消息之前,先试图往Redis里SetNX一个键值对,这个键就根据消息内容生成的,值为空字符串就好,如果写入成功,就由该线程将消息写入mq,如果没有写入成功,则表示有其他线程来往mq里写消息,自己直接返回即可.这里往redis里写的时候 过期时间我也不晓得应该设多少合适…多了占内存少了可能起不到作用…我现在是设的5s

然后mq的消息广播机制就很有作用了,我们可以有多个consumer,比如我服务器一直跑着一个consumer来往db里记录数据,然后我自己桌面可以开一个consumer来看实时弹幕(我这b站web端看直播经常没弹幕可看…)

大概画个图如下
20191212010837.png


2019年12月19日21:42:29 更新

最近把xshell换掉了,换了个新的ssh工具叫MobaXterm,这个工具在最底下就能看到资源使用情况,然后20191219214424.png???
然后看一下htop20191219214459.png这个这么长java运行参数的就是kafka…光它就吃了我一半的内存…然后上网上看了一下,说是kafka要服务器内存5g起步…算了算了

然后回想一下,我当初为啥用kafka来着???消息队列的意义在于解耦,削峰填谷和消息广播,我这个并发级别没那么高,应该没有什么峰谷可言,出于解耦和消息广播的目的用的mq.

emm,大致想到替代方案–用微服务架构,去掉mq,监听弹幕的线程写redis成功后直接调存db的服务.微服务架构感觉要选用grpc而不是dubbo了,出于解耦方面考虑.不过grpc好像没看到比较好的服务治理框架?周末去上海回来再看看吧(埋坑)

换微服务那一套的话,服务治理方面,集群容错机制也有广播的机制,在我这个项目中可以完美替代mq了.(毕竟别人用mq都是削峰填谷…)