PolarDB 非官方课程第五节--PolarDB代理很重要吗？--答题领奖品-优快云博客

本文链接：https://blog.youkuaiyun.com/liuhuayang/article/details/149385699

❝
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3300人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群近400 9群 200+，开10群PolarDB超100人专业学习群 7月份开课多名同学已经获奖查询获奖名字在文章下方)

这是PolarDB的第五节课，在我们传统的环境中数据库使用都是不需要代理的，如我们的MySQL,SQL SERVER,Oracle,PostgreSQL,但在现代的数据库中，我们很少看到没有数据库代理的数据库，如PolarDB ,Oceanbase,Tidb,TDSQL,等。那么我们不禁要问，为什么现代数据库要代理。

这就要从数据库的模式和成型来讲了，现代数据库大多不是单体数据库，不是分布式就是插件类数据库产品（积木数据库），在多种功能和节点合力下，完成了一个超级数据库的功能输出，方便程序和数据库使用人员快速掌握这样的数据库产品的使用。

代理

PolarDB的数据库代理成为了PolarDB for MySQL和PolarDB for PostgreSQL 的重要组成部门也是完成多种数据库功能的核心架构。

那么在PolarDB的代理有什功能，我们不妨跟着视频先来了解。这里有几个问题，视频里面有一些需要再深入的部分。这也是PolarDB的甄平老师（PolarDB for MySQL的研发负责人 serverless部分）看完视频后，我们交流的后的我对PolarDB的代理方面的新的知识的灌入，请大家注意以下的文字是对视频的讲解进行的部分概念的纠正。

1 视频中我们提出不建议大家使用全事务拆分，怕产生业务逻辑的错误的部分，这个地方需要更新，在任何的情况下全事务拆分是不会产生业务逻辑的问题，因为全拆分后，事务里面虽然有读和写，但不会有乱序的情况，也就是在一个事务里面从节点是基于MySQL的REDO Log 进行的物理的复制，不会和MySQL一样如果全部拆分后，会有逻辑业务乱序的问题，因为PolarDB默认如果从库读不到会直接切换到主库去读，又基于主从节点数据一致性的原理的驱动型，全事务拆分是不会出现业务逻辑错误的问题。（所以PolarDB 物理复制解决了乱序的问题，代理提供了从库万一读不到可以将请求发给写库进行数据读取的能力）

2 视频中还有一个关于设置session 部分的连接池的解读，认为将连接模式设置为session并不能提高连接的利用率，这个观点在大量使用k8s的为应用扩展的情况下是不对的，有些业务通过k8s会大量的进行短连接，而选择了session的连接池是完全可以对这样的业务类型有相关的帮助。

3 在视频中最后的部分有一个按需连接的部分，这里需要补充，在一些客户中，有非常多的ro节点的情况下，按需连接可以减少大量的初始化连接的数量，有助于减少应用端出来后，首次建立连接的性能损耗。

请学习的同学注意上面的文字，同时这也证明学习并不是一时的，而是一世的，不断学习不断刷新知识和认知。

相信大家看完视频后，对于PolarDB的数据库的代理有了一定懂得了解。

这里我们有三个小问题，想和大家进行互动。请在文章下方针对以下三道题作答，答对者将有机会获得保温水壶一个：

1 在PolarDB中代理的主要功能是那些（多选）

A 支持数据库的访问，针对读写分离进行支持

B 支持数据库的数据一致性的选择，提供多种数据库一致性服务给客户进行选择

C 支持多种数据访问方式，可以建立多个代理服务节点，满足不同的应用使用接入方式，如OLTP OLAP 或HTAP等模式

D 代理可有可无,PolarDB 可以跳过代理直接访问数据库。

E 以上都对

2 在PolarDB for Mysql 和 PolarDB for PostgreSQL代理在数据一致性上都进行了支持，如下说法中你的看法是什么？