KES分布式架构与集群实战

KES分布式架构与集群实战前面的内容里我们把KES单节点的安装部署、代码开发、日常优化、分区使用还有常规运维这些内容都逐一学完了。但是放到现在这个环境里业务数据越来越多线上并发也越来越高。单节点运行的数据库慢慢就会暴露不少问题。今天我结合政务云、大型电商、能源行业这些真实落地的项目经验和大家聊一聊KES各类集群架构。内容会讲到分布式部署、分片规则、集群日常运维还有读写分离这类常用方案。文中的配置和脚本大家都可以直接拿来用看完之后就能自己动手搭建企业里在用的集群环境。一、 本章学习导读1.1 学习目标能分清KES不同集群架构分别适合什么样的业务场景理解集群最基础的设计思路。熟练完成主备集群、读写分离集群的搭建工作掌握对应的配置项和日常维护操作。搞懂分布式分片的基础逻辑学会挑选分片键、设计分片规则理解数据路由的工作方式。了解分布式环境下的SQL写法还有跨节点查询、事务处理需要注意的地方。学会查看集群运行状态处理节点故障、集群扩容、缩容这类常见运维操作。避开分布式架构里的常见问题比如数据分片倾斜、跨库事务、路由异常、主备同步延迟等。1.2 本章重点对比KES几种主流集群架构教大家根据业务做选型主备高可用集群完整搭建步骤还有故障切换的操作读写分离集群的部署方式、请求路由规则和应用端适配方法分布式分片表的设计思路、各类分片策略和数据分布特点分布式场景下的SQL编写要求、事务处理要点省级政务云分布式集群的真实落地案例二、 为什么要使用集群与分布式架构项目刚起步的时候单节点KES完全可以支撑日常业务。随着上线时间变长用户体量不断上涨业务模块也越做越多。单节点的短板就慢慢显现出来了。首先是性能方面的问题。单台服务器的CPU、内存、硬盘IO都是有上限的。线上并发高的时候大量接口就会出现超时的情况。其次是存储容量的问题。数据日积月累很快就会达到单套磁盘、单数据目录的承载上限没法存放TB级别甚至更大的数据。最后还有单点故障的隐患。一旦这台服务器宕机或者系统出问题整套业务都会停掉没办法满足7×24小时运行的要求。针对不同规模的业务KES提供了多种集群方案。如果业务并发不算高主要诉求是保证服务不中断那就选用主备集群。如果系统里读请求远远多于写请求就可以搭建读写分离集群。要是数据量和并发都突破了单节点的上限再考虑使用分布式分片集群。大家不用一味去搭建复杂架构结合自身业务选择就可以。三、️ KES主流集群架构总览开始动手搭建之前我们先把三种核心集群的特点、组成部分和适用场景梳理清楚这也是做架构选型的基础。3.1 主备高可用集群这种架构也是目前企业里用得最多的一种。整体由1个主节点 多个备节点组成。所有新增、修改、删除、查询这类读写请求都由主节点负责处理。备节点会实时同步主节点的数据平时只做数据备份和故障备用。一旦主节点出现故障集群可以自动把备节点提升为新的主节点保证业务不会中断。适用的场景一般是传统政务系统、中小型金融系统、企业内部管理平台。这类业务读写请求数量相对均衡核心需求就是保证数据安全、服务持续运行。3.2 读写分离集群它算是在主备集群的基础上做的扩展。主节点专门用来处理写操作也就是新增、修改、删除。所有的查询、统计、报表这类读请求都会分发到各个备节点上。靠这种方式分摊读取压力整体查询速度会提升不少。这种架构适合前台查询类系统、后台报表平台、资讯类项目。这类业务有个明显特点读请求占比通常会超过七成。3.3 分布式分片集群大家也会叫它分库分表集群。它会把一张超大的数据表按照预设规则拆分存放到多个独立节点上。集群里各个数据节点地位对等一起分担存储和计算压力。同时会搭配管理节点做统一调度。应用侧感知不到底层拆分使用起来和单表差别不大。适合存储亿级流水、海量用户数据、全国性大型平台。主要目的就是打破单节点在存储和性能上的限制。四、 主备高可用集群实战搭建不管是读写分离还是分布式集群底层都依赖主备同步机制。所以我们先从最基础的一主一备架构开始讲解本次基于KES V9R1C10版本演示。4.1 环境规划我们采用两台配置、系统完全一致的服务器来搭建主节点MasterIP 192.168.1.100端口54321备节点StandbyIP 192.168.1.101端口54321操作系统CentOS 7 / 银河麒麟统一数据库运行用户kingbase数据目录/opt/KingbaseData4.2 前期准备① 两台服务器关闭防火墙放行54321端口和集群通信端口② 配置主机名和域名解析保证两台机器网络互通③ 两台机器的数据库版本、安装路径、数据目录保持完全一致④ 主节点必须开启归档日志这是主备数据同步的前提。4.2.1 主节点开启归档修改主节点配置文件kingbase.confwal_level replica archive_mode on archive_command cp %p /opt/KingbaseData/archive/%f max_wal_senders 10 wal_keep_segments 64执行命令创建归档目录并修改目录所属用户mkdir-p/opt/KingbaseData/archivechown-Rkingbase:kingbase /opt/KingbaseData/archive再修改访问控制文件pg_hba.conf允许备节点发起同步连接host replication all 192.168.1.101/24 scram-sha-256配置修改完成后重启主节点数据库服务sys_ctl restart-D/opt/KingbaseData4.3 备节点初始化备节点不能直接新建空数据库必须基于主节点的物理备份来初始化保证两边初始数据完全一致。① 先停止备节点的数据库服务清空原有数据目录② 在备节点执行备份拉取命令同步主节点数据sys_basebackup-h192.168.1.100-p54321-Usys-D/opt/KingbaseData-Xstream-P③ 在备节点新建恢复配置文件recovery.conf指定主节点地址和账号standby_mode on primary_conninfo host192.168.1.100 port54321 usersys password你的密码 restore_command cp /opt/KingbaseData/archive/%f %p4.4 启动集群与状态验证① 启动备节点数据库服务sys_ctl start-D/opt/KingbaseData② 登录主节点执行SQL查看复制状态SELECTpid,usename,application_name,state,write_lagFROMsys_stat_replication;查询结果里状态显示为streaming就代表主备同步已经正常运行。4.5 手动/自动故障切换4.5.1 手动切换一般在业务低峰期做版本升级、硬件维护时使用。在备节点执行下面命令就能把备节点提升为新主库# 备节点执行提升为主库sys_ctl promote-D/opt/KingbaseData4.5.2 自动切换生产环境建议搭配KES高可用组件。主节点故障之后大概30秒内就能完成自动切换。生产环境尽量配置虚拟IPVIP就算节点切换应用也不用修改连接地址用户完全感知不到变化。4.6 主备集群日常运维要点定期查询同步状态一旦同步延迟超过1秒就要及时排查原因定时清理归档日志避免日志文件过多占满磁盘空间不要直接在备节点执行写操作备节点默认是只读状态在主节点执行建表、改表这类DDL语句后确认备节点同步完成再执行业务变更。五、 读写分离集群实战读写分离算是在主备架构之上做的扩展专门用来解决读请求压力过大的问题目前很多互联网项目、政务前台系统都在使用。5.1 架构组成主节点唯一的写节点负责处理INSERT、UPDATE、DELETE操作多个备节点作为读节点承担查询、报表、统计类请求访问代理KES自带代理组件负责请求路由。应用只需要连接代理地址不用关心后端多节点。5.2 路由规则设计代理内置了两种常用路由模式自动路由写请求全部转发到主节点读请求轮流分发到各个备节点自定义路由可以指定部分查询语句固定走主节点其余读请求分发到备节点。5.3 部署与应用适配读写分离底层沿用主备同步的配置只需要额外部署代理服务。应用端只需要修改连接地址为代理IP和端口原有SQL语句不需要改动适配起来很简单。5.4 读写分离避坑点数据同步会存在短暂延迟。刚写入的数据立刻去备节点查询有可能查不到。对数据实时性要求高的查询一定要路由到主节点复杂的大报表SQL可以单独指定读节点执行避免抢占普通查询的资源尽量把请求均匀分发到各个读节点防止单个节点压力过高。六、 分布式分片集群深度实战当单表数据达到亿级别单节点的存储和性能都触顶之后就需要用到分布式分片集群。KES分布式集群主要由管理节点、数据节点、计算节点组成。6.1 核心概念讲解分片Shard把一张大表按照规则拆分拆分后的每一部分数据就叫做一个分片存放在不同数据节点分片键用来判断数据归属哪个节点的字段。这个字段选定之后后期修改难度很大分片规则分为范围分片、哈希分片、列表分片逻辑和单表分区类似但作用在不同物理节点上。6.2 三大分片策略实战6.2.1 范围分片按照字段数值、时间区间来拆分数据比较适合订单这类按时间增长的数据。缺点是容易出现数据集中在部分节点的情况。-- 分布式环境创建范围分片表CREATETABLEt_order_shard(order_idBIGINT,user_idINT,order_timeDATE,amountNUMERIC(12,2))SHARDBYRANGE(order_time);6.2.2 哈希分片根据分片键做哈希计算把数据均匀分散到各个节点。用户账号、ID这类无规律字段用得最多也是目前最常用的分片方式。CREATETABLEt_user_shard(uidBIGINT,username VARCHAR2(50),phoneCHAR(11))SHARDBYHASH(uid);6.2.3 列表分片按照地域、业务类型这类离散值拆分比如按照省份、地市划分政务数据。6.3 分片键选型黄金规则 优先选择查询语句里经常作为筛选条件的字段 尽量选择字段值分布零散的列避免数据全部集中在单个节点 两张需要关联查询的表尽量使用相同分片键让数据落在同一个节点提升查询速度 不要频繁更新分片键字段会造成数据在节点之间迁移影响性能。6.4 分布式SQL编写规范查询语句尽量带上分片键请求会路由到单个节点执行速度最快不携带分片键会遍历所有节点查询速度会下降这类语句尽量少写单个分片内部的事务和单节点用法一致。跨节点事务性能偏弱业务设计阶段尽量规避自定义函数、复杂触发器在分布式环境里尽量少用。6.5 集群扩容与数据重分布现有节点存储不足、并发压力变大时可以在线新增数据节点。集群会按照原有分片规则自动迁移部分数据到新节点。整个过程不会中断线上业务可以实现弹性扩容。七、 集群监控与日常运维不管是主备、读写分离还是分布式集群监控巡检都是运维工作里的重点。下面整理了通用监控项和常用查询语句。7.1 核心监控指标节点运行状态确认所有节点服务正常在线主备同步进度、分片数据同步情况各节点CPU、内存、磁盘、IO的资源使用率读写请求数量、慢SQL条数、数据库连接数查看各个分片的数据量判断是否出现数据倾斜。7.2 常用集群查询语句-- 查看集群所有节点信息SELECT*FROMsys_cluster_nodes;-- 查看分片表的数据分布情况SELECTtable_name,shard_node,count(*)FROMsys_shard_tablesGROUPBYtable_name,shard_node;-- 查看集群内慢SQLSELECTquery,total_timeFROMsys_stat_statementsORDERBYtotal_timeDESC;7.3 日常运维规范每日巡检检查节点状态、同步延迟、磁盘使用率、备份文件是否正常每周巡检查看分片数据分布、清理无用SQL、优化索引集群执行DDL、版本更新等操作必须先在测试环境验证每个数据节点都要单独做备份保证数据可以完整恢复。八、 真实企业案例省级政务云分布式集群落地8.1 业务背景某省级政务云平台汇总了全省各个地市的办件数据。整体数据量超过5亿条每天新增数据大概30万条。早期使用单节点部署经常出现查询超时、磁盘告警的问题。普通主备集群也解决不了存储上限的问题最后选择搭建哈希分片分布式集群。8.2 架构方案集群规划1个管理节点 6个数据节点每个数据节点都搭配备节点兼顾性能和高可用分片设计选用用户编号作为哈希分片键保证数据均匀分布读写拆分查询请求分流到各节点的备机降低写入节点的压力冷热分离把历史归档数据迁移到低成本存储设备。8.3 实施过程统一版本和配置搭建整套分布式集群按照分片规则重建业务表使用DTS工具迁移存量数据改造应用端连接配置对接集群代理完成全功能测试和压力测试确认跨节点查询、事务运行稳定逐步切换线上流量下线原有单节点环境。8.4 落地效果✅ 彻底解决单节点存储瓶颈查询响应时间从5秒缩短到0.2秒以内✅ 支持在线扩容后续新增地市业务不用重新改造架构✅ 节点故障可以自动切换全年没有出现业务中断的情况✅ 兼容原有Oracle语法应用侧改动量很小。九、⚠️ 集群与分布式高频坑点汇总结合线上大量运维经验整理集群使用过程中容易出现的问题大事务、网络波动、归档日志堆积都会造成主备延迟变大尽量拆分大事务优化网络环境读写分离架构下实时查询放到读节点会出现数据不一致这类查询建议路由到主节点分片键选择不合理会出现数据倾斜大部分数据集中在单个节点又变回单节点瓶颈跨节点事务性能差还存在风险业务设计阶段尽量避开没有定位真实瓶颈就盲目新增节点没法解决问题优先优化SQL和索引集群各个节点的数据库版本、运行参数不统一容易引发同步异常、语法报错。