作者回复: 主要是设计上的选择问题,Kafka中到处都是“批量和异步”设计,它更关注的是整体的吞吐量,而RocketMQ的设计选择更多的是尽量及时处理请求。
比如发消息,同样是用户调用了send()方法,RockMQ它会直接把这个消息发出去,而Kafka会把这个消息放到本地缓存里面,然后择机异步批量发送。
所以,RocketMQ它的时延更小一些,而Kafka的吞吐量更高。
作者回复: 当然可以,架构无所谓好坏,关键是适合。用多套MQ好处是发挥各自的长处,代价是维护成本比较高。具体是不是适合,还是要架构师根据各种实际情况来权衡。
作者回复: 你咋知道我是詹密呢?
作者回复: 正确的使用RabbitMQ是可以保证严格有序的,你在学习完“03 消息模型:主题和队列有什么区别?”之后,再看一下RabbitMQ的配置应该就会知道该如何解决你的问题了。
作者回复: exchange确实是AMQP协议中定义的,RabbitMQ是AMQP的一个实现。
作者回复: 配置得当的情况下,可以做到2-3ms。
作者回复: emq是专注于MQTT场景的一个消息队列,如果你的使用场景是连接海量的IoT设备,可以考虑。
nsq使用Go语言开发,如果团队的技术栈是基于Go语言搭建的,nsq是一个很好的选择。
这两个消息队列我都没有深入的使用和测试过,所以没办法跟你分享它们的优缺点和性能。
作者回复: 我们提到的都是消息队列本身的性能,不包括生产者和消费者处理各自业务逻辑的时间。一般测试消息队列性能的时候,生产者和消费者是没有任何业务逻辑的。
作者回复: 当然可以,在京东就是这样的集中式大集群,为所有业务提供消息服务。
作者回复: 建议看一下batch.size和linger.ms这两个参数的含义
作者回复: 金融级只是一种说法,并没有什么标准。但确实有很多涉及金融类的系统选择使用RocketMQ。
作者回复: 但我个人的意见:这个需求不太适合用MQ来实现。
另外,是不是可以换个思路来考虑这个问题,你一定需要一个设备离线的通知来触发什么业务逻辑吗?还是只是需要查询设备的时候,能正确的给出设备是否在线就可以了?
如果是后者,实现代价要低很多。
作者回复: 挖坟的问题,受内存大小的限制,不太好解决。这和采用那种消息队列关系不太大。有条件的话,可以使用SSD结合Raid,消费速度基本上是可以打满万兆网卡的。
作者回复: 所以需要好好学英语哦。