高并发应用中的数据库系统设计实践

1 . PostgreSQL 高并发数据库应用数据 阿里云 digoal 

2 .目录 • PG生态 • 常见的高并发场景与业务 • 高并发场景带来的挑战 • 高并发场景数据库设计与优化 • 阿里RDS PG在高并发场景的内核改进 • 案例 

3 .PG生态 

4 .PG 版本发布周期 

5 .2017,2018被评为年度数据库 

6 .2018 中国PG用户会 

7 . PG 定位-企业数据库 时空、GIS、图像 OLTP、OLAP、 创 文本、时序、 SMP并行计算、 新 向量相似、图谱 GPU并行计算、 价 流计算、异构、 值 实时分析、 混合 机器学习、 JIT、向量计算 多模 多维计算、shard 负载 Oracle 商 稳定性 企业级 降低迁移成本。 用 可靠性 兼容 社区版： 可用性 ora2pg+orafce 价 安全、弹性 阿里云版： 值 容灾 ADAM+PPAS 

8 .PG 解决了企业最急迫的问题 • 合规、合法、可控(BSD-like许可) •  都是开源，许可大不同。 • 企业级业务对数据库的基本诉求 •  可靠性、可用性、稳定性、安全性、扩展性、弹性、性能、合规 • 企业“去O”推进超车道 •  兼容Oracle •  媲美Oracle的优化器 •  高并发，烂SQL，复杂SQL，框架生成SQL，计算型SQL通吃 • 解决传统行业开发者水平参差不齐问题 

9 .PG 典型企业用户 

10 .PostgreSQL 全球财富1000的⽤用户 

11 .国际典型用户 •  制造业：大量日系、德系汽车及其另配件生产线使用PostgreSQL •  电信业：以亚太区例 NTT、KT、台湾大哥大 •  金融业：星展银行、mastercard、德国证券交易所、西班牙储蓄银行、荷兰ABN集团 •  政府：NASA、欧洲宇航局、美国海空军、法国政府、波兰政府 •  互联网：苹果、Skype、Yahoo、SOE •  公共软件：SAP、saleforce •  其他：思科、EMC、软银、英国乐透、SAP、 

12 .国内典型用户 •  邮储银行 •  浙江省政府 •  去哪儿 •  平安集团 •  湖北移动 •  探探 •  招商局 •  中国虚拟天文台 •  科大讯飞 •  工行 •  国家电网 •  阿里巴巴 •  中信金融 •  金风 •  HELLOBIKE •  惠金所 •  税友 •  摩拜单车 •  天弘基金 •  用友 •  高德 •  人保 •  中车 •  海底捞 •  润和 •  亚信 •  碧桂园 •  。。。 。。。 •  南方航空 •  长鑫（半导体） •  中航信 •  千寻 •  大疆 

13 .常见的高并发场景与业务 •  2C •  秒杀 •  运营活动 •  游戏 

14 .高并发场景带来的挑战 •  高并发短连接挑战：建立连接成本高，效率低 •  进程模式 •  高并发场景：进程调度开销大，效率低下 •  锁竞争问题 •  隔离级别越高，问题可能越明显 •  死锁问题 •  雪崩隐患 •  高并发小事务挑战：IO刷盘频率高 •  计算能力挑战 •  读写分离，高压下的从库延迟，成本挑战等 •  高并发写压力下的索引IO 引入RT增加 

15 .高并发场景数据库设计与优化 •  内置连接池 •  锁超时 •  外置连接池 •  长连接 •  预计算、流计算 •  AD Lock •  Sharding •  乐观锁 •  读写分离 •  异步提交 •  GIN fast update •  组提交 

16 .阿里云PG产品线 支持Oracle\PG两套协议 支持Oracle\PG两套协议 计算存储分离 计算、存储横向弹性扩容、缩容 (企业级+Oracle兼容) 100TB OLTP+OLAP+多模混合处理 POLARDB for PG POLARDB 双机版 POLARDB 集群版 开源增强版 SMP、GPU 6TB OLTP+OLAP 

17 .产品架构 集群版： 自主研发（基于PG） 高度兼容Oracle、 核心业务系统、 超高并发、 超大容量。 高可用版： 业务系统、 基础版: 较小容量。 测试、边缘系统、 价格便宜 

18 .阿里RDS PG在高并发场景的内核改进 调度开销 池化，优化 

19 .存储 - 支持冷热数据分离 •  通过OSS扩展无限容量 PG\PPAS POLARDB PG 外部表、支持读写、并行 阿里云OSS海量对象存储 

20 .为什么要研发POLARDB PG •  计算存储分离集群版 

21 .

22 .问题根源？ •  SQL只能用到单CORE，慢 •  升级需要迁移数据，慢 •  增加只读节点，需要迁移数据，慢 •  读写分离依靠SLAVE增量复制、回放，延迟高 •  添加字段带来数据重写，逻辑SLAVE回放需要等待上游事务结束再开始，延 迟高 •  主节点写压力大，逻辑SLAVE容易中断 •  存储使用本地磁盘，容易达到空间上限 •  逻辑备份时，表结构不能变更，可能出现锁冲突 •  备份需要拖全量，实例越大，耗时越久 •  高并发访问时，实例扛不住 

23 .POLARDB PG vs 社区版 POLARDB 集群版 开源版 成本 低 较高 1、存储按量收费 1、存储预收费 2、只读节点只收计算资源的钱 2、只读节点需要复制数据，节点越多，价格越贵 计算弹性 好 较差 1、分钟级添加节点 1、取决于实例大小，TB级实例，数十小时 存储弹性 好 较差 1、近乎无限扩容，对业务无影响 1、扩容需要迁移数据，时间长，角色切换时影响业务 2、容量上限100T 2、容量上限几T 只读节点延迟 低 一般 1、共享数据，延迟低 1、需要复制、增量回放。 备份 快 较慢 1、秒级快照备份 1、取决于数据库大小，越大越慢，备份时可能影响性能 恢复 快 较慢 1、快照克隆，秒级 1、取决于数据库大小，越大恢复越慢 可靠性 高 一般 1、存储多副本，parallel raft协议，高效，保证强一致。RPO=0 1、依靠STANDBY，异步模式有数据丢失可能性 2、依靠STANDBY，quorumbased sync replica，RPO=0，但是会损耗性 能。 可用性 高 一般 1、异常failover：由于共享数据，切换时不需要等待恢复，切换时间非常 1、异常failover切换时，需要等待备库同步完成，激活，切换。流程较 短暂。 长。 2、未来支持multi-writer模式，做到zero downtime。 性能 高 一般 1、分布式块存储，RDMA网络，横向的能力扩展。 1、存储依赖本地设备能力，扩展性较差。 2、支持存储级计算、压缩、filter下推。 3、计算节点支持mpp模型，加速复杂计算SQL。 4、支持列存。 5、支持GPU加速。 

24 .传统分库分表架构 - 缺陷 传统分库分表 架构： 限制、缺陷。 

25 .POLARDB PG 分布式的性能、 单节点的操控。 

26 .案例 -乐观锁提高处理吞吐 https://github.com/digoal/blog/blob/master/201901/20190118_02.md 

27 .案例 - 秒杀 •  秒杀 

28 . 秒杀 •  超轻锁 (advisory LOCK) 解决高并发锁竞争问题 •  手段： 在CPU运算发现行锁之前就知道是不是有冲突，大大缩短CPU计算资源，等待资源 传统 - 行锁弊端 1. 无效等待多 2. 无效等待用户 长时间占用会话资源 3. 发现锁冲突的代码路径长 热点行 需要进行大量CPU运算 250000 231376 会话1 update 200000 持锁 150000 未优化 nowait优化 100000 66630 无效 advisory lock优化 其他会话 50000 2855 等待 0 TPS 等待行锁 

29 .ADLock代替行锁 - 秒杀 •  高并发扣减库存 •  高并发争抢锁 •  update tbl set x=x where id=? and pg_try_advisory_xact_lock(id) returning *; 单条记录被并发更 新，吞吐23万qps。 APP redis 1.  连接redis判断是否还有库存 2.  有，去PG扣减(ADLock)。没有则直接返回。 PostgreSQL 3.  扣减成功，去redis更新库存