网站建设用什么系统,华为弹性云做网站,医院网站开发百度文库,中信建设有限责任公司项目人员配置在 Milvus 的云原生架构中#xff0c;消息队列#xff08;Log Broker#xff09;可谓任重道远#xff0c;它不仅要具备流式数据持久性、支持 TT 同步、事件通知等能力#xff0c;还要确保工作节点从系统崩溃中恢复时增量数据的完整性。 在 Milvus 的架构中#xff0c;一切… 在 Milvus 的云原生架构中消息队列Log Broker可谓任重道远它不仅要具备流式数据持久性、支持 TT 同步、事件通知等能力还要确保工作节点从系统崩溃中恢复时增量数据的完整性。 在 Milvus 的架构中一切围绕消息队列构建遵循日志结构化存储的原则消息队列在 Milvus 中的作用可以类比于传统数据库的 WALRedo Log的角色。在 Milvus 2.3 之前Milvus 官方支持 RocksMQStandalone 模式限定Milvus 官方基于 RockDB 实现的 MQ 系统以及 Pulsar、Kafka 等传统 MQ。 在 Milvus Standalone 模式下相比于 Pulsar 和 KafkaRocksMQ 是最简单的 MQ 部署方案。但由于 RocksMQ 基于 RocksDB在大消息体以及海量消息的场景下性能表现一般。同时 RocksMQ 需要 rocksdb频繁的调用 CGO带来额外的性能负担。在 Milvus 2.3中Milvus Standalone 最新引入了新的基于 NATS 的单机 MQ 实现给用户提供在不同的使用场景下更多的 MQ 选择。 本文将介绍新 MQ 的使用方式以及与其他 MQ 的对比。 01.什么是 NATS NATS 是 GO 实现的分布式系统连接技术支持 Request-Reply、Publish-Subscribe 等跨系统沟通模式通过底层的 JetStream 支持数据的持久化以及内置的 RAFT 来提供分布式能力。想要系统的了解 NATS可以查看官方网站https://nats.io/。 NATS 支持的 Feature 非常多在 Milvus 2.3 standalone 模式下Milvus 利用单机版的 NATSJetStreamPubSub 模式提供 MQ 能力。同时Nats-server 被 Embedding 进了 Milvus 的程序中不需要额外的 NATS 部署即可实现 NATSMQ。 02.如何启用 NATS 在 Milvus 2.3中新引入了mq.type作为 MQ 类型的控制选项为了保持向上兼容NATS 不会进入默认的 MQ 选择优先级中需要使用mq.typenatsmq强制指定。在 Milvus 实例启动后如果看到以下的日志则说明 Milvus使用了 NATS 作为 MQ。 [INFO] [dependency/factory.go:83] [try to init mq] [standalonetrue] [mqTypenatsmq] 03.NATS 配置项详解 当前配置项支持下述的定制化配置能力 natsmq: server: # server side configuration for natsmq. port: 4222 # 4222 by default, Port for nats server listening. storeDir: /var/lib/milvus/nats # /var/lib/milvus/nats by default, directory to use for JetStream storage of nats. maxFileStore: 17179869184 # (B) 16GB by default, Maximum size of the file storage. maxPayload: 8388608 # (B) 8MB by default, Maximum number of bytes in a message payload. maxPending: 67108864 # (B) 64MB by default, Maximum number of bytes buffered for a connection Applies to client connections. initializeTimeout: 4000 # (ms) 4s by default, waiting for initialization of natsmq finished. monitor: trace: false # false by default, If true enable protocol trace log messages. debug: false # false by default, If true enable debug log messages. logTime: true # true by default, If set to false, log without timestamps. logFile: /tmp/milvus/logs/nats.log # /tmp/milvus/logs/nats.log by default, Log file path relative to .. of milvus binary if use relative path. logSizeLimit: 536870912 # (B) 512MB by default, Size in bytes after the log file rolls over to a new one. retention: maxAge: 4320 # (min) 3 days by default, Maximum age of any message in the P-channel. maxBytes: # (B) None by default, How many bytes the single P-channel may contain. Removing oldest messages if the P-channel exceeds this size. maxMsgs: # None by default, How many message the single P-channel may contain. Removing oldest messages if the P-channel exceeds this limit. server.port由于 Nats 为 C-S 模式程序当前不支持使用类似于 unix socket 等不占用端口的套接字方案当前在 Milvus 中需要指定server.port作为 NATS Server 的端口如果出现端口冲突则 Milvus 不能正常启动。填写server.port-1可以随机选择端口。 storeDir用于指定底层的 JetStream 持久化机制的存储目录建议将该目录挂载在高性能的 SSD 上来提升 Milvus 的读写吞吐。如果出现 Milvus 无法启动的情况请检查该目录是否存在或者目录的使用权限。 maxFileStore用于限制 JetStream 的存储量上限如果超出该上限将会出现禁止写入的情况。 maxPayload单个消息的硬大小限制Milvus 最大的消息chunk支持到5MB因此该配置应该要保持在5MB以上并留有一定的余量否则可能出现 Milvus 拒绝写入的情况。 initializeTimeout用于控制 Milvus 启动时Nats Server 的启动超时配置。如果出现以下日志可以适当调高该配置。 [WARN] [nmq/nmq_server.go:77] [nmq is not ready within timeout] monitor用于配置 NATS 的独立日志建议在日常运行环境中启用 trace 日志。 retention用于控制 NATS 消息的保持机制由于当前 Milvus 的消息保持机制与消息消费机制尚未实现同步。因此请务必保持该配置有充足的余量让 Milvus 可以在消息被消息队列清退前消费完毕否则 Milvus 可能会出现数据丢失的情况。 以上的绝大部分配置都与 NATS 官方配置对齐如果需要了解更多的配置或者希望 Milvus 引入更多的定制化配置可以查看 NATS 的官方文档 https://docs.nats.io/running-a-nats-service/config。 04.RocksMQ 迁移至 NATS 可以采用 Milvus 的通用 MQ 迁移方案。 停止 Milvus 一切的写入操作。 调用 FlushALL 操作等待 FlushALL 完毕后关闭Milvus 进程。 修改配置项 mq.typenatsmq以及 natsmq下相关需要修改的配置项如果出现端口冲突或者目录权限等问题 启动 2.3 版本的 Milvus 进程 日志应当出现 mqTypenatsmq日志。 natsm.server.storeDir配置的目录下应当出现 jetstream 文件夹。 可选备份并清理原rocksmq.path存储目录下的文件数据。 05.NATS 和 RocksMQ 对比 Pub/Sub 性能对比 测试平台与方案 M1 Pro Chip / Memory: 16GB 启动 MQ同时对一个 Topic 进行订阅和发布随机内容数据包循环 N 次发布操作后直到订阅得到最后一次发布结果时测试结束。 测试结果 NATS 为纯 GO 的实现而 RocksMQ 使用 CGO 与 rocksdb 的 lib 交互。因此 NATS 的绝大部分内存由 GO 的 GC 接管而 RocksMQ 依赖 lib 自身的内存管理。NATS 的内存开销会更高。 在数据包较小小于 64kb的场景下RocksMQ 不论在内存、CPU 还是在响应速度都具备较大优势。(1kb message rocksmq 有1x 以上性能优势) 在数据包较大的场景下(大于 64kb)NATS 在内存充足以及理想的 GC 场景下在响应速度方面有较大的优势(5MB message NATS 有 1x 以上性能优势) 存储方面RocksMQ 当前有 Zstd 压缩加持消耗的磁盘空间更少(NATS 未开压缩) Milvus 集成测试 在 1 亿级别的向量对比测试中NATS 可以支持更低的检索延迟。 在数据量较少的场景下NATS 与 RocksMQ 的差距不大。 以上就是关于 Milvus 新消息队列 NATS 的全部内容如果大家有任何疑问都可以跟我们沟通下一篇我们会继续讲解 Milvus 2.3 的新功能——MMap敬请期待。 如果在使用 Milvus 或 Zilliz 产品有任何问题可添加小助手微信 “zilliz-tech” 加入交流群。 欢迎关注微信公众号“Zilliz”了解最新资讯。 本文由 mdnice 多平台发布
