3年部署3000套PG实例的架构设计与踩坑经验( 三 )

这个系统一个很大的特点就是对数据库的性能要求特别苛刻，当时使用的是单库的商业数据库，平时数据库的CPU利用率都在45%以上，大促期间更是超过80% ，可以说不堪重负。而且为了支撑今后的业务发展，这个系统必须在2017年双11前扩容十倍的容量，很显然单机的数据库已经没有任何性能扩容的空间，无法满足这一需求。
这个系统对数据库的使用主要包含下面3个不同的场景，其中每一个场景都对数据库有很高的性能要求。
1）明细表更新
实时更新包含400多个字段的宽表。数据加载速度要求达到5w/s以上，其中90%是UPDATE 。
2）报表计算
支持200+/min的实时报表计算
3）报表和明细查询
支持高并发的报表和明细查询
技术选型
考虑到这个系统当前对数据库的业务需求和未来的发展规划，我们希望扩容方案是基于SQL的开源分布式数据库。我们比较了几个候选方案，考虑到和业务场景的匹配度和今后的运维的便利性，最终选择了Citus ，一个能把多个单机的PostgreSQL变成分布式数据库集群的插件。

本文插图
部署架构
下面是这个系统使用Citus的部署架构，为了优化性能，我们做了一些架构上的优化。明细表更新不经过Coordinator节点，而是先到Coordinator节点批量查询待更新记录的位置信息，再直接到对应位置的Worker上以批量INSERT ON CONFLICT的方式更新明细数据。

本文插图
上线效果
根据POC压测的结果，把原单库的商业数据库替换成1CN + 8个Worker的Citus集群后，性能提升了10多倍，圆满达成扩容目标。

本文插图
新的系统从2017年上线后至今已平稳运行多年，生产集群规模也从最初上线的4个Worker逐步扩容到16个Worker ，而且CN和Worker平时的CPU利用率都保持在10%左右，很好的支撑了业务的发展。
四、PostgreSQL和Citus的推广
从2017上线第一套PostgreSQL以来，截止2019双11 ，我们已经部署了3000+PostgreSQL实例，其中80%以Citus集群的形式部署，其余是普通的PostgreSQL 。
使用PostgreSQL的应用，既有OLTP类的业务也有OLAP类的业务。下面介绍其中的3个业务案例。
案例一：计费结算
我们在很多计费结算类业务中使用了PostgreSQL + Citus的数据库架构，其中规模最大的系统是物流的计费平台。它有几百个数据库节点，多个大表的数据量超过百亿。这个系统原来使用的数据库是商业数据库，应用在业务层做分库分表。在业务层维护大量数据库节点的方式，大大增加了日常开发和管理上的成本。
举一个简单的例子，如果要在某个表上添加一个字段，需要先在几十个库的几百张分表里依次把字段加上，然后再修改上百个应用的配置，中间不能有任何错误和遗漏。而一次发布不会只改一个表，所有实际上每次发布光编辑发布脚本就是一项很大的工作。
后来我们把这个系统的数据库从一堆单机商业数据库迁移到了分布式的Citus 。迁移后不仅省掉了商业数据库的许可和维保成本，而且应用层去掉复杂的分库分表逻辑，使用体验得到了极大的提升。
迁移到Citus后，以前一些不容易做甚至没法做的事情变得可以做而且简单了，比如执行一些跨库的查询，包括跨库事务。这个系统中大量的业务请求是涉及跨库事务的。 Citus实现了基于2PC的分布式事务，支持分布式死锁检测和故障时的自动事务恢复，透明地支撑了业务的跨库访问。 Citus上的日常DDL发布也很简单，只要在Citus的Coordinator节点对逻辑表执行DDL就可以了，使用体验上和在普通单库上的DDL发布没什么区别。