此文是根据周洋在【高可用架构群】中的分享内容整理而成,转发请注明出处.
不知道咱们群名什么时候改为"Python高可用架构群"了,所以不得不说,很荣幸能在此时此刻呢的一个小时里在Python群里讨论golang....
关于push系统对比与性能指标的讨论
很多同行比较关心go语言在实现push系统上的性能问题,单机性能究竟如何,能否和其他语言实现的类似系统做对比么?甚至问如果是创业,第三方云推送平台,推荐哪个?
其实各大厂都有类似的push系统,市场上也有类似功能的云服务.包括我们公司早期也有erlang,nodejs实现的类似系统,也一度被公司要求做类似的对比测试.我感觉在讨论对比数据的时候,很难保证大家环境和需求的统一,我只能说下我这里的体会,数据是有的,但这个数据前面估计会有很多定语~
第一个重要指标：单机的连接数指标
第二个重要指标:消息系统的内存使用量指标
这一点上,使用go语言情况下,由于协程的原因,会有一部分额外开销.但是要做两个推送系统的对比,也有些需要确定问题.比如系统从设计上是否需要全双工（即读写是否需要同时进行）如果半双工,理论上对一个用户的连接只需要使用一个协程即可（这种情况下,对用户的断线检测可能会有延时）,如果是全双工,那读/写各一个协程.两种场景内存开销是有区别的.
另外测试数据的大小往往决定我们对连接上设置的读写buffer是多大,是全局复用的,还是每个连接上独享的,还是动态申请的.另外是否全双工也决定buffer怎么开.不同的策略,可能在不同情况的测试中表现不一样.
第三个重要指标：每秒消息下发量
这一点上,也要看我们对消息到达的QoS级别(回复ack策略区别）,另外看架构策略,每种策略有其更适用的场景,是纯粹推?还是推拉结合?甚至是否开启了消息日志?日志库的实现机制、以及缓冲开多大?flush策略......这些都影响整个系统的吞吐量.
另外为了HA,增加了内部通信成本,为了避免一些小概率事件,提供闪断补偿策略,这些都要考虑进去.如果所有的都去掉,那就是比较基础库的性能了.
消息系统架构介绍
下面是对消息系统的大概介绍,之前一些同学可能在gopher china上可以看到分享,这里简单讲解下架构和各个组件功能,额外补充一些当时遗漏的信息：
架构图如下,所有的service都 written by golang.
几个大概重要组件介绍如下：
room Service,长连接网关,hold用户连接,并将用户注册进register service,本身也做一些接入安全策略、白名单、IP限制等.
register service是我们全局session存储组件,存储和索引用户的go语言心跳检测相关咨询,以供获取和查询.
coordinator service用来转发用户的上行数据,包括接入方订阅的用户状态信息的回调,另外做需要协调各个组件的异步操作,比如kick用户操作,需要从register拿出其他用户做异步操作.
center service提供给接入方的内部api服务器,比如单播或者广播接口,状态查询接口等一系列api,包括运维和管理的api.
举两个常见例子,了解工作机制：比如发一条单播给一个用户,center先请求Register获取这个用户之前注册的连接通道标识、room实例地址,通过room service下发给长连接 Center Service比较重的工作如全网广播,需要把所有的任务分解成一系列的子任务,分发给所有center,然后在所有的子任务里,分别获取在线和离线的所有用户,再批量推到Room Service.通常整个集群在那一瞬间压力很大.
deployd/agent service用于部署管理各个进程,收集各组件的状态和信息,zookeeper和keeper用于整个系统的配置文件管理和简单调度
关于推送的服务端架构
拉取的方式不说了,现在并不常用了,早期很多是nginx+lua+redis,长轮训,主要问题是开销比较大,时效性也不好,能做的优化策略不多.
但纯推送模型,有个很大问题,由于系统是异步的,他的时序性无法精确保证.这对于push需求来说是够用的,但如果复用推送系统做im类型通信,可能并不合适.
哪些因素决定推送系统的效果?
首先是sdk的完善程度,sdk策略和细节完善度,往往决定了弱网络环境下最终推送质量.
结合服务端做策略
go语言开发问题与解决方案
下面讲下,go开发过程中遇到挑战和优化策略,给大家看下当年的一张图,在第一版优化方案上线前一天截图~
当时出现问题,现在总结起来,大概以下几点
①散落在协程里的I/O,Buffer和对象不复用.
针对这个问题,应尽量控制协程创建,对于长连接这种应用,本身已经有几百万并发协程情况下,很多情况没必要在各个并发协程内部做异步io,因为程序的并行度是有限,理论上做协程内做阻塞操作是没问题.
如果有些需要异步执行,比如如果不异步执行,影响对用户心跳或者等待response无法响应,最好通过一个任务池,和一组常驻协程,来消耗,处理结果,通过channel再传回调用方.使用任务池还有额外的好处,可以对请求进行打包处理,提高吞吐量,并且可以加入控量策略.
go协程相比较以往高并发程序,如果做不好流控,会引起协程数量激增.早期的时候也会发现,时不时有部分主机内存会远远大于其他服务器,但发现时候,所有主要profiling参数都正常了.
后来发现,通信较多系统中,网络抖动阻塞是不可免的(即使是内网),对外不停accept接受新请求,但执行过程中,由于对内通信阻塞,大量协程被 创建,业务协程等待通信结果没有释放,往往瞬时会迎来协程暴涨.但这些内存在系统稳定后,virt和res都并没能彻底释放,下降后,维持高位.
处理这种情况,需要增加一些流控策略,流控策略可以选择在rpc库来做,或者上面说的任务池来做,其实我感觉放在任务池里做更合理些,毕竟rpc通信库可以做读写数据的限流,但它并不清楚具体的限流策略,到底是重试还是日志还是缓存到指定队列.任务池本身就是业务逻辑相关的,它清楚针对不同的接口需要的流控限制策略.
早期rpc通信框架比较简单,对内通信时候使用的也是短连接.这本来短连接开销和性能瓶颈超出我们预期,短连接io效率是低一些,但端口资源够,本身吞吐可以满足需要,用是没问题的,很多分层的系统,也有http短连接对内进行请求的
但早期go版本,这样写程序,在一定量级情况,是支撑不住的.短连接大量临时对象和临时buffer创建,在本已经百万协程的程序中,是无法承受的.所以后续我们对我们的rpc框架作了两次调整.
第二版的rpc框架,使用了连接池,通过长连接对内进行通信（复用的资源包括client和server的：编解码Buffer、Request/response）,大大改善了性能.
但这种在一次request和response还是占用连接的,如果网络状况ok情况下,这不是问题,足够满足需要了,但试想一个room实例要与后面的数百个的register,coordinator,saver,center,keeper实例进行通信,需要建立大量的常驻连接,每个目标机几十个连接,也有数千个连接被占用.
非持续抖动时候（持续逗开多少无解）,或者有延迟较高的请求时候,如果针对目标ip连接开少了,会有瞬时大量请求阻塞,连接无法得到充分利用.第三版增加了Pipeline操作,Pipeline会带来一些额外的开销,利用tcp的全双特性,以尽量少的连接完成对各个服务集群的rpc调用.
另外能否模仿nginx,fork多个进程监控同样端口,至少我们目前没有这样做,主要对于我们目前进程管理上,还是独立的运行的,对外监听不同端口程序,还有配套的内部通信和管理端口,实例管理和升级上要做调整.
解决gc的另两个手段,是内存池和对象池,不过最好做仔细评估和测试,内存池、对象池使用,也需要对于代码可读性与整体效率进行权衡.
这种程序一定情况下会降低并行度,因为用池内资源一定要加互斥锁或者原子操作做CAS,通常原子操作实测要更快一些.CAS可以理解为可操作的更细行为粒度的锁（可以做更多CAS策略,放弃运行,防止忙等）.这种方式带来的问题是,程序的可读性会越来越像C语言,每次要malloc,各地方用完后要free,对于对象池free之前要reset,我曾经在应用层尝试做了一个分层次结构的"无锁队列"
上图左边的数组实际上是一个列表,这个列表按大小将内存分块,然后使用atomic操作进行CAS.但实际要看测试数据了,池技术可以明显减少临时对象和内存的申请和释放,gc时间会减少,但加锁带来的并行度的降低,是否能给一段时间内的整体吞吐量带来提升,要做测试和权衡...
在我们消息系统,实际上后续去除了部分这种黑科技,试想在百万个协程里面做自旋操作申请复用的buffer和对象,开销会很大,尤其在协程对线程多对多模型情况下,更依赖于golang本身调度策略,除非我对池增加更多的策略处理,减少忙等,感觉是在把runtime做的事情,在应用层非常不优雅的实现.普遍使用开销理论就大于收益.
但对于rpc库或者codec库,任务池内部,这些开定量协程,集中处理数据的区域,可以尝试改造~
对于有些固定对象复用,比如固定的心跳包什么的,可以考虑使用全局一些对象,进行复用,针对应用层数据,具体设计对象池,在部分环节去复用,可能比这种无差别的设计一个通用池更能进行效果评估.
消息系统的运维及测试
下面介绍消息系统的架构迭代和一些迭代经验,由于之前在其他地方有过分享,后面的会给出相关链接,下面实际做个简单介绍,感兴趣可以去链接里面看
架构迭代~根据业务和集群的拆分,能解决部分灰度部署上线测试,减少点对点通信和广播通信不同产品的相互影响,针对特定的功能做独立的优化.
消息系统架构和集群拆分,最基本的是拆分多实例,其次是按照业务类型对资源占用情况分类,按用户接入网络和对idc布点要求分类（目前没有条件,所有的产品都部署到全部idc）
系统的测试go语言在并发测试上有独特优势.
对于压力测试,目前主要针对指定的服务器,选定线上空闲的服务器做长连接压测.然后结合可视化,分析压测过程中的系统状态.但压测早期用的比较多,但实现的统计报表功能和我理想有一定差距.我觉得最近出的golang开源产品都符合这种场景,go写网络并发程序给大家带来的便利,让大家把以往为了降低复杂度,拆解或者分层协作的组件,又组合在了一起.
QA
Q1:协议栈大小,超时时间定制原则?
消息持久化,通常是先存后发,存储用的redis,但落地用的mysql.mysql只做故障恢复使用.
如果是发送情况下,普通产品是不需要限速的,对于较大产品是有发送队列做控速度,按人数,按秒进行控速度发放,发送成功再发送下一条.
是这样的,我们正常就是println,我感觉基本上可以定位我所有问题,但也不排除由于并行性通过println无法复现的问题,目前来看只能靠经验了.只要常见并发尝试,经过分析是可以找到的.go很快会推出调试工具的~
是否有协议拓展功能?协议栈是tcp,整个系统tcp长连接,没有考虑扩展其功能~如果有好的经验,可以分享~
系统上行数据是根据协议头进行转发,协议头里面标记了产品和转发类型,在coordinator里面跟进产品和转发类型,回调用户,如果用户需要阻塞等待回复才能后续操作,那通过再发送消息,路由回用户.因为整个系统是全异步的.
不是一直打开,每个集群都有采样,但需要开启哪个可以后台控制.这个profling是通过接口调用.
Q10:为什么放弃erlang,而选择go,有什么特别原因吗?我们现在用的erlang?
erlang没有问题,原因是我们上线后,其他团队才做出来,经过qa一个部门对比测试,在没有显著性能提升下,选择继续使用go版本的push,作为公司基础服务.
Q11:流控问题有排查过网卡配置导致的idle问题吗?
流控是业务级别的流控,我们上线前对于内网的极限通信量做了测试,后续将请求在rpc库内,控制在小于内部通信开销的上限以下.在到达上限前作流控.
还在写,如果没耦合我们系统太多功能,一定会开源的,主要这意味着,我们所有的bind在sdk的库也需要开源~
FreeBSD
golang 的grpc库是
整个的网络过程和关键点如下图
说明：
第一段：服务注册中心的由来
假如没有服务注册中心,我们会干些什么事情呢?
在传统行业的项目架构中以下的方案最为常见了：
这种架构开发、部署都是最简单的,一般适用于中小企业访问量并不是太多的情况下,各个系统服务一台机器就搞定了.系统之间的调用也是拿到对方的IP+PORT直接连接.
此时此刻呢可能因为应用B开始访问量大了,单台机器已经不能满足我们的需求,于是一些反向代理工具应运而出,其中比较常见的有Apache、Nigix,架构演变为：
相比之前的应用B的单台机器访问,这种nginx代理的方式减轻了服务器的压力,但是可能会出现Nginx挂了,那么整个服务也不可用,于是又来了这么一套架构：
这样看方案算是完美了吧.然后事情并不是想象的那么一帆风顺,这还只是应用A调用一个应用B,如果应用A调用的可能是应用B、C、D、E...,这种完全就不知道他后面到底还想干嘛,这种架构看似可以,但是绝对会累死运维的（nginx的配置将会非常混乱,直接导致运维不干了）.
服务注册中心干些什么事情呢?
上面提到的那种靠人力（主要是运维干的事情）比较繁琐,还不好维护,有这么几点不方便：应用服务的地址变了、双十一搞活动服务器新增等等.那么我们可以有这么的一种架构：
? 服务注册中心主要是维护各个应用服务的ip+port列表,并保持与各应用服务的通讯,在一定时间间隔内进行心跳检测,如果心跳不能到达则对服务IP列表进行剔除,并同时通知给其它应用服务进行更新.同样要是有新增的服务进来,应用服务会向注册中心进行注册,服务注册中心将通知给其它应用进行更新.每个应用都有需要调用对应应用服务的地址列表,这样在进行调用时只要处理客户负载杂均衡即可.
第二段：微服务注册中心
①Zookeeper
ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件.它是一个为分布式应用提供一致性服务的软件,提供的功能包括：配置维护、域名服务、分布式同步、组服务等.
先来看一下euraka的架构图：
Register：服务注册
Renew：服务续约
Fetch Registries：获取注册列表信息
Cancel：服务下线
DiscoveryManager.getInstance().shutdownComponent()；
Eviction 服务剔除
自我保护机制：
consul推荐的架构图：
Nacos是阿里开源的服务注册中心,它可以与spring cloud aliaba集成使用.
Nacos的官方介绍：
? Nacos 致力于帮助您发现、配置和管理微服务.Nacos 提供了一组简单易用的特性集,帮助您实现动态服务发现、服务配置管理、服务及流量管理.
? Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台. Nacos 是构建以"服务"为中心的现代应用架构(例如微服务范式、云原生范式)的服务基础设施.
Nacos 地图
Nacos 生态图
如 Nacos 全景图所示,Nacos 无缝支持一些主流的开源生态,例如
Spring Cloud
Apache Dubbo and Dubbo Mesh TODO
Kubernetes and CNCF TODO
第三段：服务注册与发现技术选型
以下是来自网上的一个分享：
除了上述的几种以外,笔者更推荐使用Nacos作为服务注册中心.
推荐理由：
Nacos服务注册表结构Mapnamespace, Mapgroup::serviceName, Service采用多层次Map结构,控制的颗粒度更细,支持金丝雀模式发布,心跳同步机制也更快速,服务更新更及时.
TiDB 是 PingCAP 自主研发的开源分布式关系型数据库,具备商业级数据库的数据可靠性,可用性,安全性等特性,支持在线弹性水平扩展,兼容 MySQL 协议及生态,创新性实现 OLTP 及 OLAP 融合.
① 优化 Raft 副本之间的心跳机制,按照 Region 的活跃程度调整心跳频率,减小冷数据对集群的负担.
① 新增 Fast Analyze 功能,提升收集统计信息的速度,降低集群资源的消耗及对业务的影响.
① OLTP
① TiDB 持续优化 SQL 执行器,包括：优化 NOT EXISTS 子查询转化为 Anti Semi Join,优化多表 Join 时 Join 顺序选择等.
① 提升 SQL 转化成 KV Pairs 的性能,减少不必要的开销.
RBAC（Role-Based Access Control,基于角色的权限访问控制） 是商业系统中最常见的权限管理技术之一,通过 RBAC 思想可以构建最简单"用户-角色-权限"的访问权限控制模型.RBAC 中用户与角色关联,权限与角色关联,角色与权限之间一般是多对多的关系,用户通过成为什么样的角色获取该角色所拥有的权限,达到简化权限管理的目的,通过此版本的迭代 RBAC 功能开发完成.
IP 白名单功能（企业版特性） ：TiDB 提供基于 IP 白名单实现网络安全访问控制,用户可根据实际情况配置相关的访问策略.
Audit log 功能（企业版特性） ：Audit log 记录用户对数据库所执行的操作,通过记录 Audit log 用户可以对数据库进行故障分析,行为分析,安全审计等,帮助用户获取数据执行情况.
加密存储（企业版特性） ：TiDB 利用 RocksDB 自身加密功能,实现加密存储的功能,保证所有写入到磁盘的数据都经过加密,降低数据泄露的风险.
完善权限语句的权限检查 ,新增 ANALYZE,USE,SET GLOBAL,SHOW PROCESSLIST 语句权限检查.
未来我们会继续投入到系统稳定性,易用性,性能,弹性扩展方面,向用户提供极致的弹性伸缩能力,极致的性能体验,极致的用户体验.
弹性扩展方面,PD 将提供弹性扩展所需的元信息供外部系统调用,外部系统可根据元信息及负载情况动态伸缩集群规模,达成节省成本的目标.
切换到新语言始终是一大步,尤其是当您的团队成员只有一个时有该语言的先前经验.现在,Stream 的主要编程语言从 Python 切换到了 Go.这篇文章将解释stream决定放弃 Python 并转向 Go 的一些原因.
看看我如何开始 Go 教程中的一小段 Go 代码.（这是一个很棒的教程,也是学习 Go 的一个很好的起点.）
如果您是 Go 新手,那么在阅读那个小代码片段时不会有太多让您感到惊讶的事情.它展示了多个赋值、数据结构、指针、格式和一个内置的 HTTP 库.当我第一次开始编程时,我一直喜欢使用 Python 更高级的功能.Python 允许您在编写代码时获得相当的创意.例如,您可以：
这些功能玩起来很有趣,但是,正如大多数程序员会同意的那样,在阅读别人的作品时,它们通常会使代码更难理解.Go 迫使你坚持基础.这使得阅读任何人的代码并立即了解发生了什么变得非常容易. 注意：当然,它实际上有多"容易"取决于您的用例.如果你想创建一个基本的 CRUD API,我仍然推荐 Django + DRF或 Rails.
Go 的并发方法很容易使用.与 Node 相比,这是一种有趣的方法,开发人员必须密切关注异步代码的处理方式.Go 中并发的另一个重要方面是竞争检测器.这样可以很容易地确定异步代码中是否存在任何竞争条件.
Go 没有像 Rails 用于 Ruby、Django 用于 Python 或 Laravel 用于 PHP 那样的单一主导框架.这是 Go 社区内激烈争论的话题,因为许多人主张你不应该一开始就使用框架.我完全同意这对于某些用例是正确的.但是,如果有人想构建一个简单的 CRUD API,他们将更容易使用 Django/DJRF、Rails Laravel 或Phoenix.对于 Stream 的用例,我们更喜欢不使用框架.然而,对于许多希望提供简单 CRUD API 的新项目来说,缺乏主导框架将是一个严重的劣势.
Go 通过简单地从函数返回错误并期望调用代码来处理错误（或将其返回到调用堆栈）来处理错误.虽然这种方法有效,但很容易失去问题的范围,以确保您可以向用户提供有意义的错误.错误包通过允许您向错误添加上下文和堆栈跟踪来解决此问题.另一个问题是很容易忘记处理错误.像 errcheck 和 megacheck 这样的静态分析工具可以方便地避免犯这些错误.虽然这些变通办法效果很好,但感觉不太对劲.您希望该语言支持正确的错误处理.
Go 的包管理绝不是完美的.默认情况下,它无法指定特定版本的依赖项,也无法创建可重现的构建.Python、Node 和 Ruby 都有更好的包管理系统.但是,使用正确的工具,Go 的包管理工作得很好.您可以使用Dep来管理您的依赖项,以允许指定和固定版本.除此之外,我们还贡献了一个名为的开源工具VirtualGo,它可以更轻松地处理用 Go 编写的多个项目.
我们进行的一个有趣的实验是在 Python 中使用我们的排名提要功能并在 Go 中重写它.看看这个排名方法的例子：
Python 和 Go 代码都需要执行以下操作来支持这种排名方法：
与 Python 相比,我们系统的其他一些组件在 Go 中构建所需的时间要多得多.作为一个总体趋势,我们看到 开发 Go 代码需要更多的努力.但是,我们花更少的时间 优化 代码以提高性能.
我们评估的另一种语言是Elixir..Elixir 建立在 Erlang 虚拟机之上.这是一种迷人的语言,我们之所以考虑它,是因为我们的一名团队成员在 Erlang 方面拥有丰富的经验.对于我们的用例,我们注意到 Go 的原始性能要好得多.Go 和 Elixir 都可以很好地服务数千个并发请求.但是,如果您查看单个请求的性能,Go 对于我们的用例来说要快得多.我们选择 Go 而不是 Elixir 的另一个原因是生态系统.对于我们需要的组件,Go 有更成熟的库,而在许多情况下,Elixir 库还没有准备好用于生产环境.培训/寻找开发人员使用 Elixir 也更加困难.这些原因使天平向 Go 倾斜.Elixir 的 Phoenix 框架看起来很棒,绝对值得一看.
① 介绍
最近在研究一些消息中间件,常用的MQ如RabbitMQ,ActiveMQ,Kafka等.NSQ是一个基于Go语言的分布式实时消息平台,它基于MIT开源协议发布,由bitly公司开源出来的一款简单易用的消息中间件.
①1 Features
①.). Distributed
NSQ提供了分布式的,去中心化,且没有单点故障的拓扑结构,稳定的消息传输发布保障,能够具有高容错和HA（高可用）特性.
NSQ支持水平扩展,没有中心化的brokers.内置的发现服务简化了在集群中增加节点.同时支持pub-sub和load-balanced 的消息分发.
NSQ非常容易配置和部署,生来就绑定了一个管理界面.二进制包没有运行时依赖.官方有Docker image.
官方的 Go 和 Python库都有提供.而且为大多数语言提供了库.
NSQ推荐通过他们相应的nsqd实例使用协同定位发布者,这意味着即使面对网络分区,消息也会被保存在本地,直到它们被一个消费者读取.更重要的是,发布者不必去发现其他的nsqd节点,他们总是可以向本地实例发布消息.
NSQ
首先,一个发布者向它的本地nsqd发送消息,要做到这点,首先要先打开一个连接,然后发送一个包含topic和消息主体的发布命令,在这种情况下,我们将消息发布到事件topic上以分散到我们不同的worker中.
nsqd
每个channel的消息都会进行排队,直到一个worker把他们消费,如果此队列超出了内存限制,消息将会被写入到磁盘中.Nsqd节点首先会向nsqlookup广播他们的位置信息,一旦它们注册成功,worker将会从nsqlookup服务器节点上发现所有包含事件topic的nsqd节点.
nsqlookupd
①.）客户表示已经准备好接收消息
这确保了消息丢失唯一可能的情况是不正常结束 nsqd 进程.在这种情况下,这是在内存中的任何信息（或任何缓冲未刷新到磁盘）都将丢失.
如何防止消息丢失是最重要的,即使是这个意外情况可以得到缓解.一种解决方案是构成冗余 nsqd对（在不同的主机上）接收消息的相同部分的副本.因为你实现的消费者是幂等的,以两倍时间处理这些消息不会对下游造成影响,并使得系统能够承受任何单一节点故障而不会丢失信息.
单个 nsqd 实例被设计成可以同时处理多个数据流.流被称为"话题"和话题有 1 个或多个"通道".每个通道都接收到一个话题中所有消息的拷贝.在实践中,一个通道映射到下行服务消费一个话题.
efficiency
因为NSQ没有在守护程序之间共享信息,所以它从一开始就是为了分布式操作而生.个别的机器可以随便宕机随便启动而不会影响到系统的其余部分,消息发布者可以在本地发布,即使面对网络分区.
这种"分布式优先"的设计理念意味着NSQ基本上可以永远不断地扩展,需要更高的吞吐量?那就添加更多的nsqd吧.唯一的共享状态就是保存在lookup节点上,甚至它们不需要全局视图,配置某些nsqd注册到某些lookup节点上这是很简单的配置,唯一关键的地方就是消费者可以通过lookup节点获取所有完整的节点集.清晰的故障事件——NSQ在组件内建立了一套明确关于可能导致故障的的故障权衡机制,这对消息传递和恢复都有意义.虽然它们可能不像Kafka系统那样提供严格的保证级别,但NSQ简单的操作使故障情况非常明显.
不像其他的队列组件,NSQ并没有提供任何形式的复制和集群,也正是这点让它能够如此简单地运行,但它确实对于一些高保证性高可靠性的消息发布没有足够的保证.我们可以通过降低文件同步的时间来部分避免,只需通过一个标志配置,通过EBS支持我们的队列.但是这样仍然存在一个消息被发布后马上死亡,丢失了有效的写入的情况.
虽然Kafka由一个有序的日志构成,但NSQ不是.消息可以在任何时间以任何顺序进入队列.在我们使用的案例中,这通常没有关系,因为所有的数据都被加上了时间戳,但它并不适合需要严格顺序的情况.
NSQ对于超时系统,它使用了心跳检测机制去测试消费者是否存活还是死亡.很多原因会导致我们的consumer无法完成心跳检测,所以在consumer中必须有一个单独的步骤确保幂等性.
本文将nsq集群具体的安装过程略去,大家可以自行参考官网,比较简单.这部分介绍下笔者实验的拓扑,以及nsqadmin的go语言心跳检测相关咨询.
topology
NSQ基本没有配置文件,配置通过命令行指定参数.
主要命令如下:
LOOKUPD命令
NSQD命令
工具类,消费后存储到本地文件.
发布一条消息
对Streams的详细信息进行查看,包括NSQD节点,具体的channel,队列中的消息数,连接数等信息.
nsqadmin
channel
列出所有的NSQD节点:
nodes
消息的统计:
msgs
lookup主机的列表:
hosts
NSQ基本核心就是简单性,是一个简单的队列,这意味着它很容易进行故障推理和很容易发现bug.消费者可以自行处理故障事件而不会影响系统剩下的其余部分.
事实上,简单性是我们决定使用NSQ的首要因素,这方便与我们的许多其他软件一起维护,通过引入队列使我们得到了堪称完美的表现,通过队列甚至让我们增加了几个数量级的吞吐量.越来越多的consumer需要一套严格可靠性和顺序性保障,这已经超过了NSQ提供的简单功能.
结合我们的业务系统来看,对于我们所需要传输的发票消息,相对比较敏感,无法容忍某个nsqd宕机,或者磁盘无法使用的情况,该节点堆积的消息无法找回.这是我们没有选择该消息中间件的主要原因.简单性和可靠性似乎并不能完全满足.相比Kafka,ops肩负起更多负责的运营.另一方面,它拥有一个可复制的、有序的日志可以提供给我们更好的服务.但对于其他适合NSQ的consumer,它为我们服务的相当好,我们期待着继续巩固它的坚实的基础.
以上就是土嘎嘎小编为大家整理的go语言心跳检测相关主题介绍,如果您觉得小编更新的文章只要能对粉丝们有用,就是我们最大的鼓励和动力,不要忘记讲本站分享给您身边的朋友哦！！