digoal
2022-10-22
PostgreSQL , 边界 , 自动驾驶 , 降级 , 保护
常见的数据库瓶颈影响业务的情况:
- 业务漏洞被攻击引起突发流量, 数据库雪崩影响业务,
- 或者由于临时的大查询耗费资源影响业务,
- 或者某些业务上线前未优化SQL, 导致影响其他业务的情况.
- 业务预估不准, 实际大于预估, 导致耗费过多数据库资源, 影响其他业务的情况.
遇到以上情况通常需要人为干预:
- 资源隔离
- 语句或锁或事务超时
- 现场杀SQL, 保其他业务
更多的时候是来的快去得快, 还没来得及处理, 事情过去了, 才进行复盘和追责.
根本上还是要将策略自动化, 而不是靠人, 人总是慢半拍.
市面上几乎没有数据库有良好的自动驾驶能力.
遇到以上情况, 并不是数据库烂, 但是数据库确实有可以改进的, 而不仅仅是人工干预.
就好比一辆车子, 它有各种的红线, 发动机转速, 最高时速, 如果你就是不按标准来, 非要一直在红线驾驶, 最终只会车毁人亡.
但是好的车子是有保护措施的, 例如设计极限往往大于用户可使用极限, 转速长时间超过多少可能会自动升档, 水温过高可能会有其他的保护等等.
期望:
1、人为的规则配置+自动驾驶
例如, 规则包括:
优先级规则:
- SQL优先级
- 用户优先级
- DB优先级
限制:
- 按SQL指纹设置QPS限制
- 用户、DB、全局的QPS限制
- 用户、DB、全局的连接数限制
- 大查询资源利用上限
- 白名单SQL或用户、DB等
- 排他锁的持锁时长
资源使用基准配置:
- cpu、IOPS、存储吞吐、网络吞吐
红线设置:
- cpu
- IOPS
- 存储吞吐
- 网络吞吐
自动驾驶:
- 超过QPS和连接数限制时, 对非白名单的SQL和连接进行限流
- 超过持锁时间, 自动cancel释放
- 对非白名单的SQL大查询超过资源利用上限对其进行限流, 类似cgroup限制资源使用的时间片分配
- 当遇到资源使用红线时, 触发优先级规则, 根据规则进行限流. 或者主动杀死SQL等.
设定基准
