Hi there 👋

Welcome to my blog

gRPC客户端负载均衡

gRPC 中的负载均衡包括服务端负载均衡和客户端负载均衡,本文将介绍客户端负载均衡,gRPC中的客户端负载均衡主要有2个部分:1) Name Resolver 2) Load Balancing Policy 接下来将依次介绍。 Name Resolver gRPC 中的默认 name-system 是 DNS , 同时各种客户端还提供了插件以使用自定义 name-system。gRPC Name Resolver 会根据 name-system 进行对应的解析,将用户提供的名称转换为对应的地址。 Load Balancing Policy gRPC 中内置了多种负载均衡策略,本文将介绍常见的几种负载均衡策略:1) pick_first 2) round_robin pick_first pick_first 是默认的负载均衡策略,该策略从 Name Resolver 获得到服务器的地址列表,按顺序依次对每个服务器地址进行连接,直到连接成功,如果某个地址连接成功则所有的RPC请求都会发送到这个服务器地址。 round_robin round_robin 策略,该策略从 Name Resolver 获得到服务器的地址列表,依次将请求发送到每一个地址,例如第一个请求将发送到 backend1 ,第二个请求将发送到 backend2 。 接下来分别使用这两种策略进行测试。 例子 我们先创建服务端,循环创建了3个服务端,分别使用30051、30052、30053端口。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 package main import ( "context" "fmt" "log" "net" "sync" "google....

March 30, 2024 · 4 min · overstarry

gRPC请求重试

前面的文章介绍了 gRPC 相关的功能,今天继续介绍 gRPC 的功能,本文将介绍 gRPC 的重试功能。 介绍 请求的重试是一个常见的功能,在我们日常的使用中,如果需要重试请求往往需要使用外部包进行实现,在gRPC 中内置了重试了功能,不需要我们自己实现。 通过查阅 gRPC 的文档可以看到,gRPC 会根据开发者设定的策略进行失败RPC的重试,有两种策略 1)重试策略:重试失败的RPC请求 2) hedging 策略:并行发生相同RPC请求。单个RPC请求可以选择两种重试策略中的一种,不能同时选择多种策略。 重试策略有以下参数可以使用: maxAttempts: 必填 RPC 最大请求次数,包括原始请求 initialBackoff, maxBackoff, backoffMultiplier: 必填 决定下次重试前的延迟时间 random(0, min(initialBackoff*backoffMultiplier**(n-1), maxBackoff)) retryableStatusCodes: 必填 收到服务器非正常状态码时,根据 retryableStatusCodes 中的状态码列表决定是否重试请求 hedging 策略可以主动发送单个请求的多个副本,而无需等待响应。需要注意的是,此策略可能会导致后端多次执行,因此最好仅对可以多次执行不会有不利影响的请求开启此策略。有如下参数: maxAttempts 必填 hedgingDelay 可选 nonFatalStatusCodes 可选 一个请求在没有收到成功响应时,经过 hedgingDelay没收到响应 将继续发送请求,直至达到 maxAttempts 最大次数或请求成功。当收到成功响应时,所有未完成的其它请求将停止。本质上hedging 策略可以看作在收到失败响应前重试请求。 使用 接下来讲解如何在 gRPC go语言版本中配置使用重试功能。 服务端 服务端创建一个服务,只有当请求次数达到第三次时,才返回成功响应。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 package main import ( "context" "flag" "fmt" "log" "net" "sync" "google....

March 23, 2024 · 3 min · overstarry

阿里云dms占用数据库连接问题及解决

问题 最近收到了阿里云云数据库的报警信息,提示数据库连接数过高,通过监控可以看到,数据库的连接数升高了50%,其它指标保持正常。 分析及解决 通过阿里云后台的一键诊断中的会话管理可以看到占用大量连接的ip地址,可以看到100.104.205.90、100.104.205.83 和100.104.205.6 这三个ip占用了大量连接,可以看到并没有sql请求,只是单纯的保持数据库连接,通过查看阿里云文档和询问客服,可以得知这个ip地址是阿里云dms服务的地址,。 找到原因后就好解决了,可以使用SELECT pg_terminate_backend(pid)语句释放数据库连接,使用语句释放与这三个ip相关的数据库连接:select pg_terminate_backend(pid) from pg_stat_activity where client_addr in ('100.104.205.90','100.104.205.83') ,过了一会数据库连接恢复正常了。 小结 本文通过阿里云数据库连接过高的问题,分析遇到此类问题时如何排查并解决。 参考 https://help.aliyun.com/zh/dms/configure-an-ip-address-whitelist

March 16, 2024 · 1 min · overstarry

Kubernetes 系统资源预留

前言 Kubernetes 的 pod 可以按照节点的资源进行调度,默认情况下 pod 能够使用节点的全部资源,这样往往会出现因为节点自身运行的一些驱动及 Kubernetes 系统守护进程,导致资源不足的问题。 例如有一个应用在运行中使用了大量的系统资源,导致 kubelet 和 apiserver 的心跳出现故障,导致节点处于 Not Ready 的状态,节点出现 Not Ready 的状况后,过一会儿会将 pod 调度到其它 node 节点上运行,往往会导致节点雪崩,一个接一个的出现 Not Ready 状况. 那么如何解决这个问题呢? 这时可以通过 为 Kubernetes 集群配置资源预留,kubelet 暴露了一个名为 Node Allocatable 的特性,有助于为系统守护进程预留计算资源,Kubernetes 也是推荐集群管理员按照每个节点上的工作负载来配置 Node Allocatable。 Node Allocatable Kubernetes 节点上的 Allocatable 被定义为 Pod 可用计算资源量。 调度器不会超额申请 Allocatable。 目前支持 CPU、内存 和 存储 这几个参数。可以通过 kubectl describe node 命令查看节点可分配资源的数据: 可以看到有 Capacity 和 Allocatable 两个内容,Allocatable 这个就是节点可分配资源,由于没有设置,所以默认 Capacity 和 Allocatable 是一致的。 Capacity 是节点所有的系统资源,kube-reserved 是给 kube 组件预留的资源,system-reserved 是给系统进程预留的资源,eviction-hard 是Kubelet 的驱逐阈值。...

March 9, 2024 · 2 min · overstarry

atop工具介绍及使用

前言 最近出现了服务器cpu、内存升高导致服务器宕机的问题,发生宕机后,往往由于对系统资源数据收集的不齐全,导致无法快速查明发生宕机的原因。在通过云厂商客服和网络相关资料帮助下,了解了 atop 这个工具,本机对 atop 的安装及使用进行介绍。 atop 介绍 atop 是一款用于监控 Linux 系统资源与进程的工具,能够报告所有进程的活动。其以一定的频率记录系统和进程活动,采集的数据包含 CPU、内存、磁盘、网络的资源使用情况和进程运行情况,并能以日志文件的方式保存在磁盘中。对于每个进程,会显示CPU使用率、内存增长、磁盘使用率、优先级、用户名、状态和退出码等。当服务器出现问题后,可以根据相应的atop日志文件进行分析。 安装 atop 不是系统的内部自带命令,需要进行安装,接下来以 Ubuntu 系统为例子,介绍如何安装 atop 命令。 1 更新软件源 执行 sudo apt update 进行软件源的更新。 2 安装 atop 执行 sudo apt install atop 命令安装 atop。 配置 安装完 atop 后,可以使用 atop 的默认配置使用,也可根据使用情况修改默认配置,atop 默认配置在 /etc/sysconfig/atop,查看默认配置文件内容: 1 2 3 4 5 6 7 # /etc/default/atop # see man atoprc for more possibilities to configure atop execution LOGOPTS="-R" LOGINTERVAL=600 LOGGENERATIONS=28 LOGPATH=/var/log/atop LOGINTERVAL 是监控周期,默认600s,LOGGENERATIONS是日志文件保留周期,默认是28天,可以根据具体的需求进行修改。...

March 2, 2024 · 1 min · overstarry