作者回复: RabbitMQ属于比较传统的消息队列系统,支持标准的消息队列协议(AMQP, STOMP,MQTT等),如果你的应用程序需要支持这些协议,那么还是使用RabbitMQ。另外RabbitMQ支持比较复杂的consumer Routing,这点也是Kafka不提供的。
作者回复: 这个场景使用Kafka Streams比较适合,它就是为read-process-write场景服务的
作者回复: 一行一行啃下来的。如果你也有兴趣,我建议可以先从kafka.log包开始读起,会很有收获的~~
作者回复: mq和rpc的区别往大了说属于数据流模式(dataflow mode)的问题。我们常见的数据流有三种:1. 通过数据库;2. 通过服务调用(REST/RPC); 3. 通过异步消息传递(消息引擎,如Kafka)
RPC和MQ是有相似之处的,毕竟我们远程调用一个服务也可以看做是一个事件,但不同之处在于:
1. MQ有自己的buffer,能够对抗过载(overloaded)和不可用场景
2. MQ支持重试
3. 允许发布/订阅模式
当然它们还有其他区别。应该这样说RPC是介于通过数据库和通过MQ之间的数据流模式。
作者回复: 和Pulsar的斯杰、翟佳都相识,不敢妄下结论。Flink + Kafka最近的确有标准套餐的趋势:)
作者回复: hmmm... 使用Kafka自己把控度会高一些。另外很多公司对数据出公网是有顾虑的,使用云上的服务必然涉及到将 公司数据传给云服务器的问题。如果是敏感数据这也是要考虑的
作者回复: Kafka是以消息引擎起家的,后面转型成流处理平台。没有冒犯的意思,我不认为消息引擎是流处理的一种。事实上,流处理在意的是如何处理无限数据集的问题。它们是不同的领域:)
作者回复: 嗯嗯,确实不太容易。因为这种通信方式一般是异步且是单向的,如果你需要这种回馈机制,最好使用服务调用 的方式
作者回复: http不属于消息传输协议,它是网络通信协议的一种,严格来说这是两个范畴或者说是两个层次上的协议。
通常来说,两个进程进行数据流交互的方式一般有三种:
1. 通过数据库:进程1写入数据库;进程2读取数据库
2. 通过服务调用:比如REST或RPC,而HTTP协议通常就作为REST方式的底层通讯协议
3. 通过消息传递的方式:进程1发送消息给名为broker的中间件,然后进程2从该broker中读取消息。消息传输协议属于这种模式
因此我说虽然我们都称它们为协议,但它们不是一个层次上的协议。
作者回复: 嗯嗯,DDIA是一本神书:)
其实这个定义最早还是Kafka作者Jay Kreps提出的,有兴趣可以看看Kafka的论文:http://notes.stephenholiday.com/Kafka.pdf
以及Jay Kreps的 《I ❤️ Logs》
作者回复: 指定--zookeeper是老版本的消费者,新版本需要指定--bootstrap-server。新版本消费者API是0.9版本引入的,主要是为了移除消费者API对ZooKeeper的依赖。专栏后面有文章谈到这一点。
新版本使用方法:
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test
作者回复: 赞👍
作者回复: 不能拒绝。这个是留存策略。一旦超过阈值开启老消息删除,而不是拒绝新消息。
作者回复: Active MQ属于传统的消息中间件,支持传统的消息传输协议(AMQP, STOMP, MQTT),而且这些传统中间件(比如RabbitMQ)都支持比较复杂的消息路由,这些都是Kafka不具备的。如果你的应用要支持这些协议或者是用于SOA中的应用互联,那么这些传统消息中间件比较合适。
反观Kafka还是在大数据场景下孕育的框架,如果你的场景都是大数据方面的,可以考虑使用Kafka。
作者回复: 嗯嗯,是的,已提交勘误。谢谢您的反馈:)