1、PostgreSQL+CITUS在苏宁物流经营结算中的实践姓名：薛俊邮箱：公司：苏宁科技集团云软件公司CITUS应用实践的问题苏宁物流经营结算产品介绍苏宁物流经营结算技术演进路线苏宁物流经营结算产品介绍 数据接收：业务主数据、订单、状态等数据 数据处理：数据分拣、数据预处理 计费：计算单笔费用 记账：生成日账单、月账单、客户账单 结算：生成结算单据 支付开票：客户确认账单，支付开票 报表管理：多维度报表、经营分析计费平台计费平台计费平台能力业务链路业务链路处理量级处理量级最大处理能力最大处理能力(TPS)接收物流服务平台订单亿级/天2000+预处理物流服务平台订单亿级/天2000+接收物流服务

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

3、VA+PG+CITUS)WORKERWORKERWORKERWORKERMASTERAPP1APP1APPNmasterworkerworkerworkerworker本地表分片表:参考表:明细表明细表明细表明细表明细表明细表明细表明细表维表维表维表维表维表维表维表维表Citus插件Citus插件Citus插件Citus插件Citus插件现有架构(JAVA+PG+CITUS)选择现有架构的原因传统分库分表(DB2)PG+CITUSDB2维护成本巨大开源，成功实施案例分片字段变更很麻烦 平滑扩容，逻辑复制，业务影响小机器扩容，开发需要做数据规整，有额外开发工作量和额外的清理冗余，业务数据影响范围

4、大将开发从复杂的分库分表逻辑中释放出来，更加专注于业务分库分表SQL 限制多单表操作跨库JOIN，开发需轮循多库，效率低下可跨库JOIN应用层需管理数据路由，应用改造成本高苏宁物流经营结算系统规模应用集群近百台数据库共有15套CITUS集群，近千台机器，规模最小的1CN 4 WORKER,规模最大的为1CN 32WORKER 3扩展WK 节点集群数据量级最大的数据总量近20T，其他集群数据量级平均10T。多张分片表的数据量级在50亿以上，最大的一张分片表总数据量接近200亿，单个分片在亿级以上DB2应用实践 分库分表规则PG+CITUS手动编写分库分表规则，维护工作量大定义好分片数量自动分片应

5、用实践 分页查询DB2PG+CITUS轮循每个库每张表后进行合并分页客户端多线程查询后合并分页这个功能我们做不了结果集稍大即产生OOMSelect*from table limit.数据量级几十亿级，传统分库分表怎么解？索引太多，性能怎么保证？磁盘空间怎么办？应用实践 复杂查询应用实践 复杂查询DB2PG+CITUS每个查询条件建立索引索引占用磁盘空间太大轮循多库多表性能极差创建GIN索引一堆脚本，心力憔悴！应用实践 生产发布应用实践 生产发布DB2PG+CITUS每个库每张表都要写脚本容易出错，检查脚本耗时耗力，发布风险高创建单份脚本一次执行应用实践 分片扩容DB2PG+CITUS新增新的分

6、库分表规则编写数据迁移任务，重新按照新的规则进行分布出错概率极大，定位问题难度极高应用迁移任务效率低，需要停机，业务中断影响大创建新的分片表在集群内直接使用copy进行数据迁移Rename 表名应用实践 数据库扩容DB2PG+CITUS数据重新打散分布整库复制，开发需要写应用删除多余数据停机时间长，业务影响大物理复制删除元数据和表停机时间缩短一半以上，业务影响小CITUS应用实践的问题CITUS应用实践的问题问题1 CN瓶颈1.在100多台APP的高并发请求下，单CN会存在瓶颈问题，CPU使用率会持续在70%以上2.当应用集群数量太多，CN节点连接数不变的情况下，每台应用分配的连接数过小，在高

7、并发下应用会获取不到连接解决方案：1.提高CN机器配置，比如虚机换物理机，调整CN节点连接数（临时）2.使用扩展WK，将单CN变为多CN（长期）PostgreSQLPostgreSQLApp(普通)App(普通)Appworkerworkerpgbouncer包含元数据包含参考表数据不包含分片表数据实时同步CN的DDL变更扩展worker为可选组件pgbouncerPostgreSQLCoordinator扩展worker(MX node)扩展worker(MX node)PostgreSQLpgbouncerPostgreSQLpgbouncermetadatatb1PostgreSQLPo

8、stgreSQLworkerworkerpgbouncerpgbouncermetadatatb1metadatatb1tb1_1tb1_2tb1_3tb1_4 应用通过JDBC多主机URL访问扩展worker jdbc:postgresql:/$扩展worker1,$扩展worker2,./$dbname?targetServerType=any&loadBalanceHosts=true&CITUS应用实践的问题问题2 连接控制SQL中不带分片字段时，CN对所有worker上的所有分片同时发起连接，并执行SQL。在高并发场景或慢SQL场景下很容易引起CPU/IO飙升或者连接数不够用的情况，

9、并且压测时性能上不去；解决方案：1.降低并发处理（临时）2.添加索引表，强制走分片（长期）WKWKWKWKCN请求请求请求请求请求WKWKWKWKCN请求2请求2请求1请求1CITUS应用实践的问题问题3 超大分片Citus只支持一个维度(字段)的分片，对于某些大数据量场景，即使分成128片，每个分片表仍然有上亿数据，不易维护。比如现有合作伙伴分片表，总量在137个亿左右，128分片，在任务启动捞取数据，或者按时间段查询数据时，底表数据量级太大，会使得集群的IO使用瞬间100%解决方案：1.扩容分片数，减少单个分片的数据量。从业务发展考虑，合理评估分片数2.数据归档，保留半年时间的数据3.按时

10、间分区，优化带时间范围的查询CITUS应用实践的问题问题5 数据库扩容现有数据库扩容采用的是物理复制方法，需要停机操作，在业务上没有做到完全的业务无感知的地步，并且物理复制需要整数倍操作，对机器资源要求较高。解决方案：1.将物理服务改造成逻辑复制，可以扩容任意节点的WK，无需整数倍开启任务创建一个分片迁移任务将新WK节点加入到集群中任务管理结束任务停止业务访问数据库停止所有CN和Worker备库提升新Worker为“主”恢复业务读写DROP新老Worker上的冗余分片修改元数据添加新Worker到Citus集群总结 实现了去IOE，拥抱开源 系统扩展能力得到了加强 使开发能够更加专注于应用层开发 为未来多机房部署，实现多活提供了很好的方案