PolarDB-X与X-DB、PolarDB都是阿里巴巴的数据库产品。那么他们之间有什么样的关系？
要回答这个问题，我们首先要搞明白，什么是X-DB。
什么是X-DB？
简言之，X-DB主要指在MySQL的基础上基于XEngine引擎打造的分布式跨AZ高可用数据库。
X-DB的核心能力之一是基于Paxos跨AZ RPO为0。最初阿里内部所使用的MySQL，是传统的主备架构，每一个MySQL实例由两个节点组成。
这种架构有一个重要缺陷，如果发生主备切换，可能会导致副本数据的不一致。为了解决主备架构的问题，阿里最初是采用了非常多的运维手段来解决这种问题，例如：
一套叫ADHA的系统，专门用来对MySQL服务进行探活、主备切换等操作
在主备切换之前做一些复杂的数据校验，确保主备数据一致才会进行切换（所以万一无法一致，如何切换？）
在跨城场景下，使用自研的数据同步服务来代替MySQL内部的同步机制
业务的数据的回滚回补，利用一套很复杂的数据订正程序（跟业务相关，并且对业务的表结构是有一定要求的） ...
这套架构虽然work，但并不优雅，复杂度和使用成本都非常的高，很难跟得上业务的发展。
16年，阿里内部开始了X-DB的研发。X-DB首先就是要克服副本数据一致性的问题。 X-DB的团队选择自研Paxos协议来替代MySQL内置的主备同步逻辑。Paxos的介绍有很多文章了，这里就不再赘述，有兴趣的同学可以自行进行检索。
这里简单列举下使用了Paxos协议后的MySQL的两个最核心的优势： 1. 可以在任意时刻进行切主操作，不会产生任何数据一致性问题，RPO=0 2. Leader选举、探活等完全由X-DB内核（MySQL进程）内完成，无需依赖任何外部系统
X-DB的Paxos协议库结合MySQL的方案在阿里内部经过几年的发展，目前已经完全替代了存量的传统的主备MySQL集群，具有很高的可靠性。
PolarDB-X与X-DB
从上文看出，X-DB比较好的解决了是灾备、故障恢复这类问题，但是服务场景的通适性以及水平扩展的能力就是PolarDB-X的强项了。
PolarDB-X 2.0的数据节点（DN）融合X-DB的集群容灾技术，在这之上提供了水平扩展的能力。
此外，从业界来看，使用类似Paxos的协议来构造存储节点，是众多分布式数据库的共同选择，例如TiKV使用Raft协议，OceanBase使用Paxos协议等。
例如：TiKV中的Raft三副本：
实际上，X-DB与PolarDB-X的关系远不止Paxos协议这一点，在分布式事务、扩展性、计算能力的下推、HTAP等地方，都做了大量的开发工作，请关注我们后续的文章。
PolarDB-X与PolarDB
PolarDB（这里指PolarDB For MySQL）是一个基于共享存储技术的云原生数据库。PolarDB在存储空间上可以做到很强的弹性能力，但一般使用情况下，其计算能力、写入能力依然存在单机的上限。
PolarDB-X 2.0这种share-nothing的架构，使得包括计算、写入、读取、存储等在内的所有资源，都具备了可水平扩展的能力，因此不会存在单机的瓶颈上限。
但是，share-nothing的架构在单纯的数据容量的弹性上，是不如PolarDB的共享存储架构的。
举个例子，无论使用哪一种share-nothing数据库，例如PolarDB-X 2.0、TiDB，假如现在一共10台机器，10T的数据，现在想通过加机器的方式，扩展存储空间，那总是有一半的数据需要进行搬迁到新的机器上，而这个搬迁所需要的时间，会跟数据量成正相关（比如一般情况下，十几T量级的数据进行搬迁一般都至少需要数小时的时间）。
对于PolarDB来说，上面的场景需要分钟级即可扩容完成。
那么，有没有可能结合share-nothing的优势与shared-storage/share-everything的优势呢？
答案是肯定的。
目前，下一代分布式数据库，就是会在DN引入PolarDB基于RDMA硬件+共享存储架构的核心技术，从而达到在所有资源都可以水平扩展的同时，大幅降低容量弹性的代价。
PolarDB-X 本地盘版与共享存储版未来将会是一个长期并存的关系，不会存在谁完全替代谁的问题。因为本地盘版不依赖任何特殊硬件，主要对专有云轻量化输出更为友好，目标是基于用户3台机器完成PolarDB-X的交付；共享存储版容量上具备高弹性，但这种弹性需要在一定规模下的公有云上才会有很好的体现（公有云上才有足够大的机器池子供业务去弹性）。
PolarDB-X 会是一个划时代的产品，欢迎大家持续关注！
