2018网站开发最流行的语言wordpress用vps搭建

2018网站开发最流行的语言,wordpress用vps搭建,网站建设的中期目标,wordpress关键词内链图片Kafka与RocketMQ深度对比 前言 很多人问#xff1a;Kafka 和 RocketMQ 到底该选哪个#xff1f;这篇文章我们就来深入对比一下这两个消息队列的架构差异、功能特性和性能表现#xff0c;帮你做出更好的技术选型。 #x1f3e0;个人主页#xff1a;你的主页 文章目录 K…Kafka与RocketMQ深度对比前言很多人问Kafka 和 RocketMQ 到底该选哪个这篇文章我们就来深入对比一下这两个消息队列的架构差异、功能特性和性能表现帮你做出更好的技术选型。个人主页你的主页文章目录Kafka与RocketMQ深度对比一、一句话总结两者差异二、架构上做减法三、存储模型的差异四、主从同步机制对比五、功能上做加法六、性能差异的根本原因七、如何选型八、总结一、一句话总结两者差异RocketMQ 是在架构上做减法在功能上做加法。什么意思呢架构做减法简化了 Kafka 的一些设计让系统更轻量功能做加法增加了很多 Kafka 没有的实用功能但代价是什么性能。Kafka 每秒能处理 17 万级别的数据RocketMQ 是 10 万级别。不是 RocketMQ 弱而是 Kafka 性能太强了。二、架构上做减法2.1 用 NameServer 替换 ZookeeperKafka 早期依赖 Zookeeper 来管理集群元数据。但 Zookeeper 是一个重量级的分布式协调服务它能干的事情太多了服务注册与发现分布式锁配置管理Leader 选举…而 Kafka 只用到了其中一小部分功能这就好比你只想切个苹果却搬来一整套厨房设备。RocketMQ 的做法是既然用不到那么多功能那就换一个更轻量的组件——NameServer。打个比方Zookeeper 像一个功能齐全的智能家居中控系统能控制灯光、空调、窗帘、安防…NameServer 像一个简单的通讯录只负责告诉你某个服务在哪台机器上NameServer 的特点特性说明无状态每个 NameServer 节点相互独立不需要同步数据轻量代码量少部署简单高可用挂掉一个不影响其他节点不过值得一提的是Kafka 从2.8.0 版本开始也在逐步移除 Zookeeper 依赖引入了 KRaft 模式。看来大家都意识到 Zookeeper 太重了。2.2 简化分区模型Kafka 把 Topic 拆分成多个Partition分区来提升并发能力RocketMQ 也一样只不过换了个名字叫Queue队列。但两者的存储方式完全不同Kafka 的方式Topic ├── Partition-0 → 存储完整消息 ├── Partition-1 → 存储完整消息 └── Partition-2 → 存储完整消息每个 Partition 是一个独立的日志文件消息直接写在里面。RocketMQ 的方式Broker ├── CommitLog → 存储所有消息的完整数据顺序写入 ├── Queue-0 → 只存储 offset指向 CommitLog 的位置 ├── Queue-1 → 只存储 offset └── Queue-2 → 只存储 offsetQueue 里只存简要信息主要是 offset真正的消息数据都在CommitLog里。打个比方Kafka 像是每个部门都有自己的档案柜文件直接放在各自的柜子里RocketMQ 像是公司有一个统一的档案室CommitLog各部门只保留一个索引本Queue记录我的文件在档案室的第几页三、存储模型的差异3.1 读取性能对比因为存储方式不同读取消息的过程也不一样Kafka 读取消息1. 找到对应的 Partition 2. 直接读取消息 ✅ 一次搞定RocketMQ 读取消息1. 从 Queue 读取 offset 2. 根据 offset 去 CommitLog 读取完整消息RocketMQ 需要两次读取看起来效率更低别急继续往下看。3.2 写入性能对比这里就是 RocketMQ 设计的精妙之处了。Kafka 的写入问题假设一个 Broker 上有 100 个 Topic每个 Topic 有 10 个 Partition那就是 1000 个 Partition。每个 Partition 对应磁盘上不同位置的文件。写消息到 Topic-A-Partition-0 → 磁盘位置 A 写消息到 Topic-B-Partition-3 → 磁盘位置 B 写消息到 Topic-C-Partition-7 → 磁盘位置 C虽然单个 Partition 内是顺序写但多个 Partition 分布在磁盘不同位置整体上就变成了随机写。打个比方你要往 10 本不同的笔记本上写字每写一行就要换一本手忙脚乱。RocketMQ 的解决方案所有消息不管属于哪个 Topic统统写到同一个 CommitLog 文件里。消息1Topic-A→ CommitLog 消息2Topic-B→ CommitLog 消息3Topic-C→ CommitLog这样就把随机写变成了顺序写磁盘 IO 效率大大提升。打个比方不管什么内容都往同一本笔记本上写写完一页翻下一页行云流水。结论在多 Topic 场景下RocketMQ 的写入性能优于 Kafka。四、主从同步机制对比数据可靠性需要主从备份两者的同步方式也不同。Kafka 的主从同步Broker-1 (Leader) ├── Partition-0 ──同步──→ Broker-2 (Follower) Partition-0 ├── Partition-1 ──同步──→ Broker-3 (Follower) Partition-1 └── Partition-2 ──同步──→ Broker-2 (Follower) Partition-2以 Partition 为单位同步每个 Partition 单独建立同步通道。RocketMQ 的主从同步如果还像 Kafka 一样按分区同步就得把 CommitLog 里的内容拆开又退化成随机读写了。所以 RocketMQ 索性直接同步整个 CommitLog 文件Master Broker └── CommitLog ──整体同步──→ Slave Broker CommitLog以 Broker 为单位区分主从大大简化了备份模型。五、功能上做加法RocketMQ 在功能上比 Kafka 丰富很多这也是很多业务系统选择它的原因。5.1 消息过滤Tag假设你有一个user-events主题里面有各种用户事件注册、登录、下单、评论…Kafka 的做法// 消费者拿到所有消息自己过滤for(ConsumerRecordrecord:records){UserEventeventparse(record);if(event.getType().equals(ORDER)){// 处理订单事件}// 其他事件直接丢弃}问题消费者要拉取所有消息然后手动过滤浪费带宽和 CPU。RocketMQ 的做法// 生产者发送时打上 TagMessagemsgnewMessage(user-events,ORDER,data);// 消费者订阅时指定 Tag只拉取需要的消息consumer.subscribe(user-events,ORDER);Broker 端直接过滤消费者只收到自己关心的消息。5.2 事务消息两者都支持事务但含义不同。Kafka 的事务保证生产者发送的多条消息要么全部成功要么全部失败。producer.beginTransaction();producer.send(msg1);producer.send(msg2);producer.send(msg3);producer.commitTransaction();// 三条消息原子性提交这只是发送端的事务。RocketMQ 的事务保证发消息和本地业务操作要么同时成功要么同时失败。1. 发送半消息Half Message到 Broker消费者暂时看不到 2. 执行本地事务比如扣款 3. 根据本地事务结果提交或回滚消息举个例子用户下单扣款场景发送扣款成功消息到 MQ执行数据库扣款操作如果消息发了但数据库扣款失败了怎么办RocketMQ 的事务消息可以保证两者一致性。5.3 延迟队列场景用户下单后 30 分钟未支付自动取消订单。RocketMQ原生支持延迟消息MessagemsgnewMessage(order-timeout,data);msg.setDelayTimeLevel(5);// 延迟级别比如 5 代表 1 分钟producer.send(msg);Kafka不支持需要自己实现比如用定时任务扫描。5.4 死信队列消费失败的消息去哪了RocketMQ自动进入死信队列Dead Letter Queue方便后续排查和重试。Kafka原生不支持需要自己实现比如消费失败后手动发到另一个 Topic。5.5 消息回溯想重新消费历史消息怎么办功能KafkaRocketMQ按 Offset 回溯✅ 支持✅ 支持按时间回溯✅ 支持0.10.1✅ 支持这个功能两者都有Kafka 从 0.10.1 版本后也支持按时间回溯了。5.6 功能对比总结功能KafkaRocketMQ消息过滤Tag❌ 不支持✅ 支持事务消息⚠️ 仅发送端事务✅ 分布式事务延迟队列❌ 不支持✅ 支持死信队列❌ 不支持✅ 支持消息回溯✅ 支持✅ 支持六、性能差异的根本原因前面说了Kafka 性能17万/秒比 RocketMQ10万/秒高不少。RocketMQ 参考了 Kafka 的设计为什么性能反而不如答案是零拷贝技术的选择不同。6.1 什么是零拷贝消息队列的数据存在磁盘上。消费者要读取消息数据需要从磁盘发送到网络。传统方式没有零拷贝磁盘 → 内核缓冲区 → 用户空间 → Socket缓冲区 → 网卡 (拷贝1) (拷贝2) (拷贝3) (拷贝4)4 次拷贝2 次系统调用效率很低。6.2 两种零拷贝方案方案一mmap内存映射磁盘 → 内核缓冲区 ←映射→ 用户空间 → Socket缓冲区 → 网卡 (拷贝1) (不拷贝) (拷贝2) (拷贝3)省掉了内核到用户空间的拷贝还剩 3 次。关键点用户空间可以直接访问数据内容。方案二sendfile磁盘 → 内核缓冲区 → 网卡 (DMA拷贝) (DMA拷贝)只有 2 次拷贝而且都是 DMA 控制器在干活不占用 CPU。关键点用户空间完全不参与也看不到数据内容。6.3 为什么 RocketMQ 不用 sendfile看一下两个函数的返回值// mmap - 返回数据内容的指针void*mmap(void*addr,size_tlength,...);// sendfile - 返回发送了多少字节ssize_tsendfile(intout_fd,intin_fd,off_t*offset,size_tcount);mmap应用层能拿到消息内容可以做各种处理sendfile应用层只知道发了多少字节不知道具体内容是什么RocketMQ 的很多功能需要读取消息内容消息过滤需要读取 Tag死信队列需要知道是哪条消息失败了事务消息需要根据消息内容做二次投递如果用 sendfile根本拿不到消息内容这些功能就没法实现了。所以消息队列零拷贝方案原因Kafkasendfile追求极致性能不需要读取消息内容RocketMQmmap需要读取消息内容来实现丰富功能这就是 RocketMQ 性能不如 Kafka 的根本原因。七、如何选型说了这么多到底该选哪个7.1 选 Kafka 的场景大数据场景日志采集、实时计算、数据管道关键词Spark、Flink、Hadoop、数据湖、ETL特点数据量巨大对吞吐量要求极高功能需求简单日志服务 → Kafka → Flink → 数据仓库 用户行为 → Kafka → Spark → 实时分析7.2 选 RocketMQ 的场景业务系统场景电商、金融、订单、支付关键词事务、延迟、重试、可靠性特点功能需求复杂对可靠性要求高数据量相对可控订单服务 → RocketMQ → 库存服务 支付服务 → RocketMQ事务消息 → 积分服务7.3 简单粗暴的选型标准场景推荐能频繁听到 Spark、Flink 这些词Kafka其他业务场景RocketMQ八、总结本文从架构、存储、功能、性能四个维度对比了 Kafka 和 RocketMQ维度KafkaRocketMQ元数据管理Zookeeper正在移除NameServer轻量存储模型每个 Partition 存完整消息CommitLog 统一存储多 Topic 写入可能退化为随机写顺序写性能更好主从同步按 Partition 同步按 Broker 同步整个 CommitLog功能丰富度基础功能消息过滤、事务、延迟、死信队列零拷贝sendfilemmap吞吐量~17万/秒~10万/秒核心结论没有完美的架构只有适合的场景。Kafka 追求极致性能RocketMQ 追求功能丰富。做架构做到最后都是在做折中。热门专栏推荐Agent小册Java基础合集Python基础合集Go基础合集大数据合集前端小册数据库合集Redis 合集Spring 全家桶微服务全家桶数据结构与算法合集设计模式小册消息队列合集等等等还有许多优秀的合集在主页等着大家的光顾感谢大家的支持文章到这里就结束了如果有什么疑问的地方请指出诸佬们一起来评论区一起讨论希望能和诸佬们一起努力今后我们一起观看感谢您的阅读如果帮助到您不妨3连支持一下创造不易您们的支持是我的动力