苏宁citus架构演进之路

1、 扬帆起航苏宁citus架构演进之路目录lCitus的架构演进lCitus扩容的方案演进l痛点分享如今的Citus在苏宁支撑了哪些业务TP业务物流订单的定价、结算业务数据库的性能监控数据AP业务大数据分析平台金融，物流，商户等的BI分析业务缘起为了支撑某业务的10倍扩容性能要求高负载类型多样Spark任务分析平台明细表报表维表报表计算200+聚合/min业务系统1业务系统2抽取明细更新5w/s(400+字段 2.5KB/row)90%UPDATE + 10%INSERTn 扩容前的数据库(DB2)硬件：24C/256GB/4800GB SSD平时：45% CPU利用率大促：80%+ CPU利用

2、率(不堪重负！)DB2分布式数据库选型（2017年）方案优点缺点结论Greenplum 支持列存 支持压缩 SQL兼容好 更新慢 并发低不符合明细更新的性能要求postgres_fdw+ pg_pathmanSQL兼容好 不支持聚合下推(PG10以后支持) 不支持并行查询分片表管理不便不符合明细表查询性能要求PG-XLSQL兼容好 GTM对性能的影响？ 稳定性，维护成本？ 社区不活跃版本更新慢未深入评估citus Just a extension 分片表管理方便 成功案例较多 部分SQL不支持不支持全局一致性读基本匹配业务场景最初为了应对业务系统的复杂负载需求，做了如下的一些比较，最终选择了c

3、itus初期的部署架构(含连接池)App(普通)App(A普pp通)worker1worker2PostgreSQLCitus插件PostgreSQLCitus插件CoordinatorPostgreSQLCitus插件pgbouncer(wk1)pgbouncer(wk2)系统表（元数据）说明pg_dist_nodeWorker node tablepg_dist_partitionPartition tablepg_dist_shardShard tablepg_dist_placementShard placement tablepg_dist_colocationCo-location

4、 group table架构的变更史2017/51CN+4Worker(PG9.6+Citus6.1)1CN+4Worker(PG9.6+Citus7.1)升级1CN+8Worker+2只读CN(PG9.6+Citus7.1)扩容升级1CN+8Worker+2只读CN(PG10.2+Citus7.2)1CN+16Worker+4只读CN(PG10.2+Citus7.2)扩容2018/10(双11前)该系统上线以来成功实施了多次升级和扩容第一套系统已上线数十个系统约1500实例2018年上半年试点阶段开始普及痛点CoordinatorApp(普通)App(A普pp通)worker1worker2

5、PostgreSQLCitus插件PostgreSQLCitus插件PostgreSQLCitus插件pgbouncer(wk1)pgbouncer(wk2)workerNPostgreSQLCitus插件不断扩容出现单CN瓶颈Pgbouncer部署在CN上 阻碍分片间通信(分片修 复和分片迁移)多CN部署架构PostgreSQLPostgreSQLAApppp(普普通通)App参 考 ： /ChenHuajun/chenh uajun.github.io/blob/master/_posts/20 18-06-11-citus实战系列之四多CN部 署.mdworker1pgbouncerwo

6、rker2pgbouncerPostgreSQLCoordinator扩展worker(MX node)pgbouncer扩展worker(MX node)pgbouncermetadatatb1PostgreSQLworker4pgbouncerPostgreSQLmetadatatb1PostgreSQLmetadatatb1tb1_1tb1_2tb1_3tb1_4包含元数据包含参考表数据不包含分片表数据实时同步CN的DDL变更扩展worker为可选组件应用通过JDBC多主机URL访问扩展workerjdbc:postgresql:/$扩展worker1,$扩展worker2,./$dbn

7、ame?targetServerType=any&loadBalanceHosts=true&支持DDL & DMLPgbouncer在WK节点Citus插件Citus插件Citus插件Citus插件woCrkiteru3s版本升级pgb到oun7ce.r4PostgreSQL支持部追分D加ML 了新的节点身份：扩展WK多CN架构的现状 集群规模这套架构上线1年多，截止到2019年双11，已经有311套citus集群（约3000PG实例），其中大部分是1CN 4WK或者8WK的规模，其中规模最 大的几套库，有1个CN节点， 3个扩展WK节点和32个普通WK节点 数据量数据量最大的两套库，整个集

8、群的数据总量有30T和15T左右，其他的库 基本单个WK的数据量也在400G左右新的痛点（需求）Coordinator(主)Worker2 (主)Worker1(主)Worker3 (主)Coordinator(备)Worker1(备)Worker2(备)Worker3(备)Worker4(备)流复制流复制流复制流复制流复制写流量读流量App写业务读业务Worker备库资源闲置， 仅仅是作为HA而已Worker4 (主)抽数业务影响交易业务，AP和TP业务在同时跑读写分离的新架构Coordinator(主)Worker2 (主)Worker1(主)Worker3 (主)Worker4 (主)C

9、oordinator(备)Worker1(备)Worker2(备)Worker3(备)Worker4(备)流复制流复制流复制流复制写流量读流量App写业务App读业务CN通过PG流复制保持数据 同步，那么如何在一份元 数据的前提下，实现CN备 库到WK备库流量划拨呢？流复制/etc/hosts主机名称映射通过在/etc/hosts中配置主机名的映射来先实现CN备库到WK备库 流量的划拨CN主库# citus集群各WK主库的IP citus_wk1 xxx.xxx.xxx.xxx citus_wk2 xxx.xxx.xxx.xxx.CN备库# citus集群各WK备库的IP citus_wk1

10、xxx.xxx.xxx.xxx citus_wk2 xxx.xxx.xxx.xxx.Citus元数据1 |1 |citus_wk1 |6432 |default |f|t| primary | default2 |2 |citus_wk2 |6432 |default |f|t| primary | defaultCN主备节点上的元数据均为下面的形式，nodename中以主机名来代替早期架 构中使用的vippostgres=# select * from pg_dist_node;nodeid | groupid |nodename| nodeport | noderack | hasmeta

11、data | isactive | noderole | nodecluster-+-+-+-+-+-+-+-+-1 |1 | |6432 |default |f|t| primary | default2 |2 | |6432 |default |f|t| primary | default主备库分别识别各自映射的WK ippostgres=# select * from pg_dist_node;nodeid | groupid |nodename| nodeport | noderack | hasmetadata | isactive | noderole | nodecluster-

12、+-+-+-+-+-+-+-+-新架构支持跨机房部署CN(主)WK1(主)WK1(中继)WK2(中继)CN(备)WK1(备)WK2(备)WK1(备)WK2(备)流复制流复制WK2 (主)流复制流复制流复制CN(中继)CN(备)流复制写流量读流量/etc/hostscitus_wk1 citus_wk2 /etc/hostscitus_wk1 citus_wk2 机房1机房2目录lCitus的架构演进lCitus扩容的方案演进l痛点分享扩容（基于物理复制）适用架构 目前的三种架构均可使用这种方案扩容适用条件每个WK上的分片数必须是2的整数倍扩容后的WK数量是扩容前的2倍扩容步骤预先将删除冗余分片

13、sql分发到各WK计算分片的分布逻辑流复制全量备份WK1和2的数据每个WK保留一 半的分片WK1(备)WK1(主)shard_1 Shard_3 Shard_5 Shard_7WK2(备)WK2(主)shard_2 Shard_4 Shard_6 Shard_8WK3(备)shard_1 Shard_3 Shard_5 Shard_7WK4(备)shard_2 Shard_4 Shard_6 Shard_8扩容步骤WK1(备)WK1(主)shard_1 Shard_3 Shard_5 Shard_7WK2(备)WK2(主)shard_2 Shard_4 Shard_6 Shard_8WK3(主

14、)shard_1 Shard_3 Shard_5 Shard_7WK4(主)shard_2 Shard_4 Shard_6 Shard_8停止业务访问数据库停止所有CN和Worker备库 提升新Worker为“主”恢复业务读写DROP新老Worker上的冗余分片修改元数据添加新Worker到Citus集群- 更新分片表已迁移到新worker的shard位置 update pg_dist_shard_placement - 插入参考表在新worker上的shard位置 insert into pg_dist_shard_placement select master_add_node($work

15、er_ip,$port); select master_add_node($worker_ip,$port);回退步骤提升扩容前的所有备库为主库起动扩容前的所有备库停止扩容前的所有主库恢复业务访问恢复备库WK1(旧主)WK2(旧主)WK2(新主)shard_2 Shard_4 Shard_6 Shard_8WK3(主)shard_1 Shard_3 Shard_5 Shard_7WK4(主)shard_2 Shard_4 Shard_6 Shard_8重建备库重建备库WK1(新主)shard_1 Shard_3 Shard_5 Shard_7优势与不足优适 用 目 前 所 有 的 架 构 物

16、理 复 制 可 以 保 证 数 据 准 确 性 回退速度快， 且可保证能恢复到扩容前的状态劣对机器资源需求很大（ 必须成倍扩容）扩容步骤繁琐， 手动操作出错的概率高业务需要短时间停机， 且只能扩容不能缩容需要业务停读写， 不够平滑解决方案基于逻辑复制的分片迁移策略 用PG的逻辑复制同步数据，省去物理复制带来的配置变更等操 作 迁移粒度从整库迁移缩小到表级别，对业务影响更小，风险更 可控 业务可连续运行，仅在变更元数据的瞬间有锁表（访问排他锁） 自定义元数据记录迁移状态，便于平台管理迁移任务新的方案能做什么 任意数量的WK节点扩容 集群缩容 WK节点的迁移（遇到虚机故障，磁盘资源不足等等情况）

17、集群内分片的再平衡一次迁移任务的流程开启任务创建一个分片迁移任务将新WK节点加入到集群中任务管理结束任务select master_add_node($worker_ip,$port); select master_add_node($worker_ip,$port);sn_create_rebalance_job()sn_start_shard_migration_task(jobid,taskid)sn_complete_shard_migration_task(jobid,taski d)sn_task_cleanup(jobid,taskid)sn_monitor_shard_migr

18、ation_task(jobid,taskid) sn_cancel_shard_migration_task(jobid,taskid)监控迁移进度取消迁移任务任务出错后的重试环境清理变更citus元数据清理旧分片副本变更迁移任务的元数据WK数据迁移场景再平衡场景缩容场景创建迁移任务逻辑（再平衡场景下）每个WK上的分片按亲和关系分组，互相亲和的分片捆绑一起迁移计算每个WK上分片数的均衡值，算法：分片数/WK数 = WK上分片数 = (分片数+WK数-1)/WK数WK上分片数大于均衡值的就是迁移源WK，小于均衡值的则为迁移的 目标WK生成的迁移任务写入任务元数据表（pg_citus_shard

19、_migration）中， 用于管理限制 PG逻辑复制本身的限制（replica id，HA切换后的管理，复制 延迟，PG10不支持truncate） 分片表名长度的限制（PG限制63字节，分片之后有shardid后 缀，表名长度被进一步压缩） 同源/同目的的迁移任务不可并行（实现工具的限制，未来可解） 有迁移任务的情况下，不可再创建分片表，不可执行变更现有 分片表的DDL（用事件触发器实现）目录lCitus的架构演进lCitus扩容的方案演进l痛点分享Pgbouncer后端连接不足原因：业务有不带分片字段的查询或者更新（ 抽数， 导数这类业务） ， c i t u s 默认的执行 器（ re

20、 a l - t i m e ） 会对每个分片建一个连接。通常这类S Q L 执行时间也较长， 当有 多个并发的时候， 就出现p g b o u n c e r 后端连接不足的情况。解决：1 .改大p g b o u n c e r 后端连接数的配置 2 .尽可能让S Q L 带上分片字段. 用读写分离的新架构. 新版c i t u s 支持a d a p te r e xe c u to r 有所改进查询的中间结果集过大问题：ERROR: the intermediate result size exceedscitus.max_intermediate_result_size (currently 1048576 kB)影响：业务每2个小时下载一次数据集，因为临近双11，数据量增大，出 现上面的问题，导致每次下载任务都失败查询的中间结果集过大优化1：简单粗暴，把citus.max_inter