PostgreSQL CITUS在物流经营结算中的实践

1、技术创新，变革未来PostgreSQL+CITUS在苏宁物流经营结算中的实践CITUS应用实践的问题苏宁物流经营结算产品介绍苏宁物流经营结算技术演进路线苏宁物流经营结算产品介绍数据接收：业务主数据、订单、状态等数据数据处理：数据分拣、数据预处理计费：计算单笔费用记账：生成日账单、月账单、客户账单结算：生成结算单据支付开票：客户确认账单，支付开票报表管理：多维度报表、经营分析计费平台计费平台计费平台能力业务链路处理量级最大处理能力(TPS)接收物流服务平台订单亿级/天2000+预处理物流服务平台订单亿级/天2000+接收物流服务查询系统状态数据亿级/天5000+接收快递服务系统包裹扫描信息千万级

2、/天1000+预处理快递服务系统包裹扫描信息千万级/天1000+接收物流分拨中心装卸车信息千万级/天1000+苏宁物流经营结算技术演进路线2006年以前ERP2006SAP + DB22015JAVA + DB22017JAVA +PG经营结算历史传统架构单机(SAP)数据孤岛数据中心化机器性能瓶颈数据丢失风险极大DB2CLIENT传统分库分表架构(JAVA+DB2)APP2APP1APP3APPN中间件DDB1DB1DB1B2DDB1DB1DB1B2DDB1DB1DB1B2DDB1DB1DB1B2现有架构(JAVA+PG+CITUS)WORKERWORKERWORKERWORKERMASTE

3、RAPP1APP1APPNmaster本地表分片表:参考表:Citus插件workerworkerworkerworkerCitus插件Citus插件Citus插件Citus插件明细表明细表明细表明细表维表维表维表维表现有架构(JAVA+PG+CITUS)选择现有架构的原因传统分库分表(DB2)PG+CITUSDB2维护成本巨大开源，成功实施案例分片字段变更很麻烦平滑扩容，逻辑复制，业务影响小机器扩容，开发需要做数据规整，有额外开发 工作量和额外的清理冗余，业务数据影响范围 大将开发从复杂的分库分表逻辑中释放 出来，更加专注于业务分库分表SQL 限制多单表操作跨库JOIN，开发需轮循多库，效率

4、低下可跨库JOIN应用层需管理数据路由，应用改造成本高苏宁物流经营结算系统规模应用集群近百台数据库共有15套CITUS集群，近千台机器，规模最小的1CN 4WORKER,规模最大的为1CN 32WORKER 3扩展WK 节点集群数据量级最大的数据总量近20T，其他集群数据量级平均10T。多张分片表的数据量级在50亿以上，最大的一张分片表总数据量接近200亿，单个分片在亿级以上DB2应用实践 分库分表规则PG+CITUS手动编写分库分表规则，维护工作量大定义好分片数量自动分片应用实践 分页查询PG+CITUSDB2轮循每个库每张表后进行合并分页客户端多线程查询后合并分页这个功能我们做不了结果集稍

5、大即产生OOMSelect * from table limit.数据量级几十亿级，传统分库分表怎么解？索引太多，性能怎么保证？磁盘空间怎 么办？应用实践 复杂查询应用实践 复杂查询DB2PG+CITUS每个查询条件建立索引索引占用磁盘空间太大轮循多库多表性能极差创建GIN索引一堆脚本，心力憔悴！应用实践 生产发布应用实践 生产发布DB2每个库每张表都要写脚本容易出错，检查脚本耗时耗 力，发布风险高PG+CITUS创建单份脚本一次执行应用实践 分片扩容PG+CITUSDB2新增新的分库分表规则编写数据迁移任务，重新按照新的 规则进行分布出错概率极大，定位问题难度极高应用迁移任务效率低，需要停机

6、， 业务中断影响大创建新的分片表在集群内直接使用copy进行数据迁 移Rename 表名应用实践 数据库扩容DB2数据重新打散分布整库复制，开发需要写应用删除 多余数据停机时间长，业务影响大PG+CITUS物理复制删除元数据和表停机时间缩短一半以上，业务影响小CITUS应用实践的问题CITUS应用实践的问题问题1 CN瓶颈在100多台APP的高并发请求下，单CN会存在瓶颈问题，CPU使用率会持续在70%以上当应用集群数量太多，CN节点连接数不变的情况下，每台应用分配的连接数过小，在 高并发下应用会获取不到连接解决方案：提高CN机器配置，比如虚机换物理机，调整CN节点连接数（临时）使用扩展WK，

7、将单CN变为多CN（长期）AApppp(普普通通)Appworkerpgbouncer包含元数据包含参考表数据不包含分片表数 据实时同步CN的DDL变更扩展worker为可 选组件workerpgbouncerCoordinatorPostgreSQL扩展worker(MX node) pgbouncerPostgreSQLPostgreSQLmetadatatb1workerpgbouncerworkerpgbouncermetad atatb1metad atatb1PostgreSQLtb1_1PostgreSQLtb1_2PostgreSQLtb1_3PostgreSQLtb1_4应用

8、通过JDBC多主机URL访问扩展workerjdbc:postgresql:/$扩展worker1,$扩展 worker2,./$dbname?targetServerType=any&loadBalan ceHosts=true&扩展worker(MX nodep)gbouncerCITUS应用实践的问题问题2 连接控制SQL中不带分片字段时，CN对所有worker上的所有分片同时发起连接，并执行SQL。在高 并发场景或慢SQL场景下很容易引起CPU/IO飙升或者连接数不够用的情况，并且压测时性 能上不去；解决方案：降低并发处理（临时）添加索引表，强制走分片（长期）WKWKWKWKCN请 求

9、请求请求请求请求WKWKWKWKCN请 求 2请求2请 求 1请求1CITUS应用实践的问题问题3 超大分片Citus只支持一个维度(字段)的分片，对于某些大数据量场景，即使分成128片，每个分片表仍然有上亿数据，不易维护。比如现有合作伙伴分片表，总量在137个亿左右，128分片， 在任务启动捞取数据，或者按时间段查询数据时，底表数据量级太大，会使得集群的IO使用瞬间100%解决方案：扩容分片数，减少单个分片的数据量。从业务发展考虑，合理评估分片数数据归档，保留半年时间的数据按时间分区，优化带时间范围的查询CITUS应用实践的问题问题5 数据库扩容现有数据库扩容采用的是物理复制方法，需要停机操作，在业务上没有做到完全的业务无 感知的地步，并且物理复制需要整数倍操作，对机器资源要求较高。解决方案：1.将物理服务改造成逻辑复制，可以扩容任意节点的WK，无需整数倍将新WK节点加入到集群中创建一个分片迁移任务 开启任务任务管理结束