zoukankan      html  css  js  c++  java
  • kafka和rabbitMQ比较

    Kafka 应对场景:消息持久化、吞吐量是第一要求、状态由客户端维护、必须是分布式的。Kafka 认为 broker 不应该阻塞生产者,高效的磁盘顺序读写能够和网络 IO 一样快,同时依赖现代 OS 文件系统特性,写入持久化文件时并不调用 flush,仅写入 OS pagecache,后续由 OS flush。

    这些特性决定了 Kafka 没有做“确认机制”,而是直接将生产消息顺序写入文件、消息消费后不删除(避免文件更新),该实现充分利用了磁盘 IO,能够达到较高的吞吐量。代价是消费者要依赖 Zookeeper 记录队列消费位置、处理同步问题。没有消费确认机制,还导致了 Kafka 无法了解消费者速度,不能采用 push 模型以合理的速度向消费者推送数据,只能利用 pull 模型由消费者来拉消息(消费者承担额外的轮询开销)。

    如果在 Kafka 中引入消费者确认机制,就需要 broker 维护消息消费状态,要做到高可靠就需要写文件持久化并与生产消息同步,这将急剧降低 Kafka 的性能,这种设计也极类似 RabbitMQ。如果不改变 Kafka 的实现,而是在 Kafka 和消费者之间做一层封装,还是需要实现一套类似 RabbitMQ 的消费确认和持久化机制。

  • 相关阅读:
    Linux内核调试方法
    linux查看系统的日志------健康检查特性
    检测磁盘驱动的健康程度SMART
    用十条命令在一分钟内检查Linux服务器性能
    Nginx安装及配置
    getopts的使用
    grub rescue 主引导修复
    linux C中调用shell命令和运行shell脚本
    Makefile基础---编译
    OVMF基础
  • 原文地址:https://www.cnblogs.com/accpguoliang/p/11345593.html
Copyright © 2011-2022 走看看