写点什么

有赞 NSQ 多集群多机房设计

  • 2019-07-19

  • 本文字数：4975 字

    阅读完需：约 16 分钟

有赞NSQ多集群多机房设计

一、Overview

从有赞双机房开始到金融云架构，针对业务方在多机房的应该部署以及消息发送订阅需求，需要 NSQ 针对双机房以及多机房部署提供消息发送与订阅服务。本文主要介绍了 NSQ 双机房以及多机房设计以及经验总结。

二、场景和需求

下图是一个机房内基本的 NSQ 消息生产和消费的部署。一个机房内生产者往 NSQ 集群发消息，多个消费者订阅消息。



双机房场景下，业务的生产和消费在两个机房都有部署，也有可能部署在不同机房中，如下图：



对于生产者和消费者，在满足升级房生产消费的同时，NSQ 的双机房方案需要做到业务方无感知，尽量降低业务方的使用成本。同时，NSQ 的双机方案署要能够实现 topic 切换，当某一机房不可用时，通过切换机房能够尽快恢复消息生产和消费。

三、NSQ 双机房设计

我们结合 NSQ 中的服务发现组件 nsqlookupd 的功能实现 NSQ 的双机房功能。nsqlookupd 是 NSQ 组件中用于 topic 生产以及 channel 订阅的额服务发现的组件，消息生产者/消费者通过 nsqlookupd 的查询接口发现目标 topic 所在的 nsqd 节点。目前有赞使用的 NSQ 经过分布式改造后，由于 topic 会在 nsqd 节点之间动态分配，消息在生产或消费前需要通过 nsqlookupd 进行服务发现。


有赞 NSQ 的双机房服务发现由 nsqlookupd 的服务发现入手，引入了 lookup-migrate（以下简称 migrate）。lookup-migrate 作为 nsqlookup 的代理，机房内的 lookup 请求首先发送到 lookup-migrate。migrate 根据双机房配置，返回对应机房中的 nsqd，如下图。



在双机房 NSQ 集群部署上，采用了镜像部署，一个 topic 在 2 个机房中都存在。由于有赞 NSQ 集群内已经实现了副本机制，消息只在一个机房落盘，不同步到对端机房。一旦本地机房 NSQ 无法正常服务，已经落盘的消息不会丢失（恢复前无法被消费）。


根据代理的路由配置，NSQ 的双机房方案经历了两个阶段。

3.1 NSQ 双机房方案一期

NSQ 的双机房方案目前计划分为两期，一期中读写流量全部通过 migrate 导到一个机房，对端机房中的 NSQ 集群作为冷备。如图 4 中所示，其中虚线的部分为消息的读写流量。由于本期方案中应用的读写全部在单以及防中，对于双机房部署的应用存在消息跨机房生产或消费的问题，存在一定的网络延迟。


3.2 NSQ 双机房方案二期

一期稳定运行一段时间后，而其中通过迁移的方式将一部分流量平滑导入到对端机房。二期中基于“本地生产，双机房消费”的策略，将应用的写请求路由到本地 NSQ 集群，对于消费者的消费请求，migrate 返回双机房的 nsqd 节点信息，如下图中所示。



写入的 lookup 请求统一路由到本地集群，而作为消费者会去消费双机房中所有 topic 的节点。相较于一期，二期不存在跨机房生产方的写入延迟，消费者通过消费所有机房的节点，保证了对于单机房部署的消费者应用能够消费到全量的消息。

四、lookup-migrate 的路由以及迁移策略

Migrate 的 lookup 路由涉及双机房 NSQ 的 lookup 查询以及查询结果的整合。先了解一下 youzan NSQ 的一个 lookup 请求以及返回结果。youzan 的 lookup 请求中，增加了 access 的读写参数，lookup 能够根据 access 来区分读写请求。


{    "channels": [        "default"    ],    "meta": {        "extend_support": true,        "ordered": false,        "partition_num": 2,        "replica": 2    },    "partitions": {        "0": {            "broadcast_address": "127.0.0.1",            "distributed_id": "127.0.0.1:4250:4150:871995",            "hostname": "nsq1",            "http_port": 4151,            "id": "127.0.0.1:59208",            "remote_address": "127.0.0.1:59208",            "tcp_port": 4150,            "version": "0.3.7-HA.1.9.5"        },        "1": {            "broadcast_address": "127.0.0.2",            "distributed_id": "127.0.0.2:4250:4150:1033760",            "hostname": "nsq2",            "http_port": 4151,            "id": "127.0.0.2:54296",            "remote_address": "127.0.0.2:54296",            "tcp_port": 4150,            "version": "0.3.7-HA.1.9.5"        }    },    "producers": [        {            "broadcast_address": "127.0.0.1",            "distributed_id": "127.0.0.1:4250:4150:871995",            "hostname": "nsq1",            "http_port": 4151,            "id": "127.0.0.1:59208",            "remote_address": "127.0.0.1:59208",            "tcp_port": 4150,            "version": "0.3.7-HA.1.9.5"        },        {            "broadcast_address": "127.0.0.2",            "distributed_id": "127.0.0.2:4250:4150:1033760",            "hostname": "nsq2",            "http_port": 4151,            "id": "127.0.0.2:54296",            "remote_address": "127.0.0.2:54296",            "tcp_port": 4150,            "version": "0.3.7-HA.1.9.5"        }    ]}
复制代码


查询结果中,partitions 包含了 topic 的分区信息映射，producers 中包含了分区信息中的 nsqd 节点以及开源版本的 nsqd 节点作为兼容方案。客户端在建连时依据如下约定：首先根据 partition 中的分区节点建立连接，之后从 producer 的节点中找出不属于 partitions 的节点建连。客户端会定时根据 lookup 的查询结果，更新 nsqd 的连接。


以此为基础我们进行改造，使得 lookup 的返回信息中能够包含 2 个机房的 nsqd 节点信息。partitions 中包含一个集群的 nsqd 信息，将另一个集群的 nsqd 节点信息更新到 producers 数组中。假设 topicA 配置为 1 分区 2 副本，双机房中 2 个节点 ip 分别为 11.0.0.1 以及 21.0.0.1。整合后的 lookup 结果为：


{    "channels": [        "default"    ],    "meta": {        "extend_support": true,        "ordered": false,        "partition_num": 1,        "replica": 2    },    "partitions": {        "0": {            "broadcast_address": "11.0.0.1",            "distributed_id": "11.0.0.1:4250:4150:871995",            "hostname": "nsq1",            "http_port": 4151,            "id": "11.0.0.1:59208",            "remote_address": "11.0.0.1:59208",            "tcp_port": 4150,            "version": "0.3.7-HA.1.9.5"        },        "1": {            "broadcast_address": "21.0.0.2",            "distributed_id": "21.0.0.2:4250:4150:1033760",            "hostname": "nsq2",            "http_port": 4151,            "id": "21.0.0.2:54296",            "remote_address": "21.0.0.2:54296",            "tcp_port": 4150,            "version": "0.3.7-HA.1.9.5"        }    },    "producers": [        {            "broadcast_address": "11.0.0.1",            "distributed_id": "11.0.0.1:4250:4150:871995",            "hostname": "nsq1",            "http_port": 4151,            "id": "11.0.0.1:59208",            "remote_address": "11.0.0.1:59208",            "tcp_port": 4150,            "version": "0.3.7-HA.1.9.5"        },        {            "broadcast_address": "21.0.0.2",            "distributed_id": "21.0.0.2:4250:4150:1033760",            "hostname": "nsq2",            "http_port": 4151,            "id": "21.0.0.2:54296",            "remote_address": "21.0.0.2:54296",            "tcp_port": 4150,            "version": "0.3.7-HA.1.9.5"        }    ]}
复制代码


上述 lookup 查询结果的整合便由 lookup-migrate 完成。以下为 lookup-migrate 的流程图，首先 migrate 根据配置信息查询对应的 lookup,之后将结果整合后返回结果。


迁移场景下，需要将生产以及消费的流量迁移到目标机房的 NSQ 上，考虑到尽量不引起消息积压，对于非顺序消费的 topic 主要有以下步骤：



  1. migrate 将 topic 消费者的消费请求代理到两个机房的 nsqd;

  2. 消费者建连后，migrate 将 topic 生产者的生产请求代理到目标 nsqd;

  3. migrate 将 topic 消费请求代理到目标 nsqd,和源机房的连接断开；


对于顺序消费业务，则需要先切换生产到目标机房，在确认源机房 channel 已无消息积压后，将消费请求迁移至目标机房。


一个在双机房代理基础上拓展出来的场景则顺序 topic 的不停机扩容。对于基于顺序 topic 的生产消费场景，当 topic 需要扩容时，由于涉及到分区变化可能引起消费到的消息在扩分区过程中出现乱序。通过 migrate 进行扩容，先对对端机房的 topic 进行扩容，扩容完成后，将顺序消息的生产和消费依次迁移至对端机房的 NSQ 集群后，在对本地机房进行扩容，等到全部扩容完成后将生产和消费迁移会本地机房。

五、双机房到多机房

随着业务增长，NSQ 集群上 topic 数量以及读写流量日渐增加，同时为了满足更多的业务场景，公司机房再度增加。migrate 的双机房方案的实现主要基于 NSQ 在两个集群间的迁移设计，而多机房场景下，生产消费流量要求在多个集群之间路由。针对新的多机房集群需求，我们重新设计了 migrate 的数据结构，提出了一种保存 lookup 数据格式，以及一种 lookup 地址的 schema。


{    "topics": [        {            "topicA": {                "#C": [                    "lookup_addr1",                    "lookup_addr2",                    "lookup_addr3"                ],                "#P": "lookup_addr1"            }        },        {            "#D": {                "#C": [                    "default lookup_addr1",                    "default lookup_addr2",                    "default lookup_addr3"                ],                "#P": "default lookup_addr"            }        }    ]}
复制代码


其中，#C 代表消费者要消费的各个 nsq 集群 lookup 地址数组，#P 代表生产者的要生产的 nsq 集群 lookup 地址，#D 表示默认的 topic 所对应的生产以及消费 lookup 地址。通过这个数据结构将 topic 与对应的生产和消费 NSQ 集群建立关联。实例中 lookup 地址在实际过程中可能对应了比价长的 URL,为了简化配置的数据量，通过一个 lookup 的 schema 将实际的 lookup 地址关联到 NSQ 集群名称上。


{    "lookupSchema": {        "nsq1": "this.is.url.of.nsq1:4161",        "nsq2": "this.is.url.of.nsq2:4161",        "nsq3": "this.is.url.of.nsq3:4161"    }}
复制代码


支持多机房 lookup 代理的流程如下图：


六、经验总结

在此针对 migrate 实现和运行过程中遇到的问题进行总结。


首先是部署问题，作为 nsqlookupd 的代理，对外暴露的端口为 nsqlookup 的公共端口。而 nsqlookupd 作为 topic 资源的管理和服务发现组件，除了 lookup 接口之外还有其他公共接口。migrate 在实现时，或者透传 lookup 请求之外的其他请求，或者通过其他反向代理，劫持 lookup 请求到 migrate 的端口。两种方案各有利弊，方案一额外实现了请求透传，而方案二对于运维有一定的要求，代理配置以及端口映射之间的梳理需要一定的工作量。


lookup 查询结果通过 migrate 进行聚合时，消费者的 lookup 结果可能包含多个 NSQ 集群的 lookup 信息，migrate 在查询各个 NSQ 集群时存在并发，如果 migrate 返回的结果中 partition 信息是更具 lookup 查询返回结果决定的，比如，先返回的节点设置为 partition。可能会导致部分客户端在处理连接时对已建连的连接重复进行断开/重连。migrate 在进行 lookup 查询前，根据 NSQ 集群信息进行排序，第一个 lookup 地址的查询结果设为为 partition 的信息。


migrate 需要针对 NSQ 集群可能返回的异常做处理，对于消费 lookup 请求，当查询的多个集群中有查询失败的情况下，返回给客户端的 lookup 相应中可以合并成功返回的节点信息。


有赞 NSQ 的 nsqlookupd 支持 listlookup 查询来发现集群中所有的 nsqlookupd 主备，migrate 可以考虑通过 listlookup 发现集群中的 nsqlookupd 节点，将代理的 lookup 请求负载到各个 nsqlookupd 节点中。


本文转载自公众号有赞 coder（ID：youzan_coder）。


原文链接：


https://mp.weixin.qq.com/s/uAlCMsefKGtYmKKg7LeHDQ


划线
评论
复制
2019-07-19 08:007975
技术管理部署最佳实践在离线混部大数据

评论

发布
暂无评论

更多内容推荐

发现更多内容

推荐阅读

电子书

大厂实战PPT下载

换一换
    Web 前端技术在智能电动汽车行业的探索
    Web 前端技术在智能电动汽车行业的探索

    谢晖 | 蔚来汽车 数字化业务发展研发工程师

    立即下载
    RWKV，开源模型架构，不一定是 Transformer

    罗璇 | 元始智能 联合创始人兼COO

    立即下载
    让玄学更可靠：构建复杂的 LLM 应用

    张海龙 | Babel CEO

    立即下载

腾讯云TDSQL- C Serverless 2.0版发布，多项核心技术首次公开解析

极客天地

私有化部署即时通讯平台，完美替代飞书和钉钉的SaaS系统

BeeWorks

使用云电脑9条注意事项

青椒云云电脑

云电脑

什么是云电脑？

青椒云云电脑

云电脑

【效率提升】手把手教你如何使用免费的 Amazon Code Whisperer 提升开发效率堪比 GitHub Copilot 平替

亚马逊云科技 (Amazon Web Services）

云桌面应用下的数据防护新思路

青椒云云电脑

云桌面

高性能存储 SIG 月度动态：erofs 新增支持多个重要特性，持续构建容器场景竞争力

OpenAnolis小助手

开源 容器 高性能存储 龙蜥社区 sig

祝贺！Databend Cloud 入驻 AWS 云市场

Databend

为什么要使用虚拟云桌面？

青椒云云电脑

云桌面 青椒云云桌面

作业

大肚皮狒狒

云桌面GPU技术方案

青椒云云电脑

图形工作站

WorkPlus打造统一用户管理平台，实现企业用户管理的一体化

BeeWorks

云桌面跟PC相比能有哪些不一样的体验？

青椒云云电脑

桌面云 云桌面

五点告诉我们云教室比传统机房好

青椒云云电脑

云教室

性能最佳实践

FunTester

八种十倍提升API性能的方式

树上有只程序猿

数据库 服务器 API 接口

不同构架云桌面的部署风险

青椒云云电脑

云桌面 青椒云云桌面

虚拟云桌面在实验教学中的应用与实践

青椒云云电脑

桌面云 云桌面

云桌面在教学中的应用

青椒云云电脑

云桌面

虚拟云桌面和共享云桌面有啥区别

青椒云云电脑

云桌面

海外运营视频直播App，服务器放在哪？

山东布谷科技胡月

语音聊天APP源码 国际版语音直播APP 交友软件开发 海外直播App开发 直播交友源码

WorkPlus——高效私有化办公平台，实现即时协作与信息安全的完美结合

BeeWorks

LeetCode题解：7. 整数反转，迭代，JavaScript，详细注释

Lee Chen

JavaScript LeetCode

如何实现虚拟云桌面？

青椒云云电脑

桌面云 云桌面

无障碍测试解读

QE_LAB

无障碍 测试技术干货 测试技术

影响云桌面性能的三个重要因素是什么？

青椒云云电脑

云桌面

不同构架云桌面的部署风险

青椒云云电脑

云桌面

WorkPlus Meet白板和文档共享功能上线，私有化视频会议全新升级

BeeWorks

业务喜报丨九科信息成功签约四川中烟工业有限责任公司成都卷烟厂RPA项目

九科Ninetech

RPA RPAxAI

Copyright © 2025, Geekbang Technology Ltd. All rights reserved. 极客邦控股（北京）有限公司 | 京 ICP 备 16027448 号 - 5京公网安备京公网安备 11010502039052号 | 产品资质
有赞NSQ多集群多机房设计_技术管理_鲁林_InfoQ精选文章