84669 person learning
152542 person learning
20005 person learning
5487 person learning
7821 person learning
359900 person learning
3350 person learning
180660 person learning
48569 person learning
18603 person learning
40936 person learning
1549 person learning
1183 person learning
32909 person learning
kafka 典型的场景是日志场景做数据分析,但是对于聊天服务器或者推送场景这种场景有人测试过吗?
这两种场景的区别:日志类:连接到中心服务器的终端较少并且比较固定,但是终端与服务器交换的数据量很大。推送或聊天:连接到中心服务器的终端很多并且不固定,但是交换的数据量不大。
用传统mq就可以了
为什么要用消息队列来做聊天服务器呢?聊天不是用消息对列来做的。推送服务器当然可以用kafka来做消息队列。消息队列与终端状态没有关系吧
kafka的设计主要是面相信息收集的,有很高的吞吐量,但是他吞吐量大的前提是他利用了磁盘的顺序写。他并不适合做聊天那种队列用的,如果用它做聊天,每个会话得有个topic吧,但是在kafka中建立topic是个比较重的操作,而且topic多了也非常影响性能。聊天还是用amqp的那种队列比较好。
用传统mq就可以了
为什么要用消息队列来做聊天服务器呢?聊天不是用消息对列来做的。推送服务器当然可以用kafka来做消息队列。消息队列与终端状态没有关系吧
kafka的设计主要是面相信息收集的,有很高的吞吐量,但是他吞吐量大的前提是他利用了磁盘的顺序写。他并不适合做聊天那种队列用的,如果用它做聊天,每个会话得有个topic吧,但是在kafka中建立topic是个比较重的操作,而且topic多了也非常影响性能。聊天还是用amqp的那种队列比较好。