接上篇：https://developer.aliyun.com/article/1223114?spm=a2c6h.13148508.setting.27.44ec4f0eNvAByn
PolarDB1.0计算存储分离时，可以通过读写分离将TP事务型查询均匀地打散到不同节点上。但该架构在处理AP型查询时存在一些问题，因为查询只能在计算节点上处理，无法发挥多个计算节点的能力。
因此，PolarDB在存储计算分离架构上进一步实现了HTAP架构。如图中所示，在计算层实现了分布式并行计算引擎。任何一个计算节点均支持单机查询引擎，也支持分布式并行计算查询引擎。
如上图，最左侧节点可用于处理单机TP型查询，用户可将业务中所有TP查询、点查发送到该节点。同时，分析性查询可利用多个计算节点的特性来完成计算（上图中的只读节点），四个节点基于MPP工作原理。
最终，我们实现了一套系统，既可以做单机点查、点写，也可以做多机并行计算引擎处理AP分析。
以上架构实现了一体化存储，TP和AP共享一份数据，用户将TP数据写到共享存储，AP做分析时可以实现毫秒级的数据新鲜度。传统的解决方案下，TP库到AP库之间的复制延迟非常长。另外，使用一份存储也减少了存储成本。
其次，该架构将TP和AP做了物理隔离，可以将部分节点配置为负责处理TP查询，单机执行；然后将其他节点部署为分布式MPP执行，实现了TP和AP的物理隔离，甚至可以实现不同业务域运行在不同计算节点上，避免AP查询对TP查询的影响。
另外，该架构也具备了Serverless弹性扩展能力，任何RO节点均可以发起MPP查询。传统MPP查询中存在一个协调节点，而PolarDB里每个节点均可看到所有数据以及元数据，所有节点本质上是对等的，因此任何节点都可以作为MPP查询的协调节点。
同时，实现了SQL级别调整单机执行并行度以及SQL级别调整MPP执行节点范围。这意味着计算能力不足时，可以迅速增加计算节点。因此新增节点可以直接访问共享存储，对计算能力做扩展时，无需对数据做重分布。传统MPP统在新增节点时需要对数据做重分布，过程相当漫长，而PolarDB几乎可以实现秒级生效。另外，如果存储容量不足需要增加机器，也无需再做扩容，因为PolarDB底层为分布式存储，存储池化后容量按需分配，可以认为容量无限大，无需担心存储容量不足的问题。
HTAP架构内置了两个优化器，其一为传统内置优化器，用于处理单机查询。其二为GPORCA优化器，用于处理分布式查询。
执行器层引入了大量算子。除了单机执行引擎所需要的算子之外，还需要对以上算子做并行化改造，比如支持Shuffle节点、支持对顺序扫描节点的并行化操作。
事务层，PolarDB HTAP完整兼容事务，执行MPP时完备兼容事务的可见性级别。
PolarDB HTAP实现了SQL全兼容，做了大量工作实现SQL特性。
PolarDB除了支持存储计算分离和HTAP架构，还支持三节点高可用架构。该架构为基于X-Paxos做流复制，同时可以将PolarDB部署在本地盘，在可用区内部通过X-Paxos实现了低延迟系统。由于接入了X-Paxos协议，在某个节点宕机时可自动选择leader节点、自动做恢复、自动做集群节点变更。
同时，借助DataMax既可以支持日志+存储的部署方式，也支持仅部署日志的方式，实现两地三中心的部署。如图所示，可以将可用区域1中的日志通过异步或同步方式复制到Log Syncer进程，该进程在本地盘只存储了日志，并不存储数据，同时将WAL日志向下游做复制，复制到另一可用区。从而既保证了可用性，又从成本上得到了进一步控制。
PolarDB支持存储计算分离架构、HTAP架构以及三节点高可用架构，可以通过不同的配置文件部署成不同的方式，三个架构为正交关系。
如上图左侧，可以是云原生和HTAP混合使用的方式，业务可以根据自己的需求将TP和AP流量分别发送到不同的计算节点，且只需一份存储。
如上图右侧，可以借助X-Paxos将PolarDB以本地盘的方式进行部署，有一个leader和两个follower，可实现高可用。同时，本地盘的方式也可以支持HTAP的业务负载，比如可以将TP查询发送到leader节点上，同时将AP查询发送到follower上。且多个follower节点和leader节点可以组织成分布式查询，解决了传统TP数据库主备方式做分析时计算能力扩展的问题。
接下篇：https://developer.aliyun.com/article/1223111?groupCode=polardbforpg
