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

本次分享高并发应用场景介绍,对数据库可能带来的压力,如何从内核、数据库架构方面解决高并发场景调度问题。同时介绍阿里云RDS PG相比社区版本有哪些优势,客户CASE
展开查看详情

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更新库存