mysql多用户并发_PostgreSQL分布式在海量并发TP场景的应用实践

最近是越来越偏爱PostgreSQL了，虽然日常工作中维护MySQL的分布式也不少，但适当的业务场景，个人期望有更多用户及开发的同学可以尝试将业务从MySQL生态过渡到PostgreSQL生态中来。

我们知道，一直以来，传统行业使用Oracle居多，互联网行业也基本是MySQL的天下。作为互联网行业工作的一份子，不得不说MySQL的习惯和技术栈在公司发展得根深蒂固。

过去我们常常说，MySQL比较适合互联网行业，原因有很多，其实技术发展到今天，MySQL适用的场景，很多PostgreSQL同样适用，互联网业务场景，PostgreSQL也未曾不可。

个人觉得，PostgreSQL在互联网行业同样存在很多的可能性。

下面简要总结一个最近基于PostgreSQL分布式设计上线的业务系统。

业务需求

业务产品一级导流TAP应用服务，用户量千万级别，产品功能上线的初步阶段写请求3000/s，读请求2w/s，后续请求量有可能出现快速增长情况。应用在深圳、上海双城部署，深圳可读可写，上海只读，要求SQL延时500ms以内。

可选的技术及组件

golang/java、Redis、MySQL及其分布式，PostgreSQL及其分布式，MongoDB··········

需求分解

1. 用户日活量高，数据量及请求量后续可能出现量级增长。可以预期，数据量、请求量都有可能突破单机的瓶颈。因此，弹性的扩展能力是我们在系统选型的不可忽略的能力。

2. SQL场景复杂：业务较多存在多表关联、group by、单列或多列排序取top结果集情况，且热点数据集中，数据倾斜严重。因此，一个具有强大优化器的数据库产品，在对业务的支持上会表现得更好。

3. 初步阶段写请求3000/s，读请求2w/s，典型的读多写少场景。读写分离是当下大多数数据库产品都具备的能力，就看哪个支持的更好，架构设计在性能、稳定性、运维成本等方面更优。

4. 应用跨城部署，数据多活读写请求，需要良好网络及数据同步技术保障。  

由于多表关联及复杂查询的存在，MySQL及其分布式看来是不太适用，尽管目前的8.0版本在多表关联等方面的特性有所加持。而PostgreSQL及其分布式则依靠其强大的复杂SQL优化器，及其分布式如pgxc、citus等可以提供很好的弹性扩展能力，会是一个相对比较友好的选择。

另外，在面对web类型应用的海量高并发场景，相对于MySQL的线程模型，PostgreSQL进程模型必须要加入连接池，以对后端DB进行保护，否则很容易发生DB负载过高引发DB瘫痪的故障。

在服务端，我们引入pgbouncer连接池，同时在客户端要求使用golang进行应用编码，这样可以更好的结合pgx客户端驱动，在客户端层面加入pgxpool。在服务端、客户端使用双向连接池长连接的情况下，可以有效减少业务短连接对服务端的资源消耗。

当然，单纯依靠连接池技术只是起到有效保护后端DB的作用，并不能够有效支撑应用业务请求。读多写少的场景，在应用和PostgreSQL之间引入缓存架构层，是一种很好的架构设计方案，缓存及读写分离技术，也是高并发场景比较重要的一环。

最后，整体的架构概念模型就是下面这个样子：

这样子，当所请求的数据不在缓存层而需求请求后端DB的时候，就可以首先通过分布式架构将数据shard到各个dn(比如分布为dn001到dn006)，然后各个shard节点可以水平扩展多个只读平面，比如为了对dn001进行读写分离，可以将dn001(主)进行扩展到8个只读平面：dn001(备)到dn008(备)。这样，我们可以很好的实现弹性水平扩缩容，以及较好的支持业务的独立分离需求。

鉴于跨region地域分布，这里还通过在负载均衡这里加入就近访问，让深圳的应用请求优先访问深圳的读或写平面的cn节点，上海的应用优先请求上海的读平面cn节点，最后由各平面的cn将请求路由到对应的dn节点。

当然，上面的架构图还是省略了connection pool连接池的示意图：

从现网运行情况来看，目前该PostgreSQL架构系统能将复杂的SQL查询延时保障在毫秒级别，通过水平扩展能力，在面对千万用户级别的压力下可以稳定运行，我们也期待PG分布式可以接受更多更大的实践考验。

最后，但愿文章对读者朋友没有产生误导。