中间件技术峰会分享|AliSQL 引领开源技术变革之路

摘要：首届阿里巴巴中间件技术峰会上，阿里巴巴数据库资深专家何登成带来“AliSQL 引领开源技术变革之路”的演讲，本文从回顾AliSQL发展史开始谈起，接着分析了X-KV接口的好处，最后着重分享了X-Cluster——AliSQL集群解决方案。

以下是精彩内容整理：

AliSQL发展历史简要回顾

为了去IOE，从2010年我们选择Alibaba的MySQL分支AliSQL。
我们为什么发展一个MySQL分支呢？最主要的思考还是在于生态，当我们去选择开源数据库时，我们会发现MySQL的整个生态、社区对于其它数据库来说是庞大的。我们发展MySQL开源分支是因为开源数据库在Alibaba体量下还是会碰到许多问题，比如性能、功能和可运维性，我们都作了相应优化。

X-KV：高性能K-V接口

X-KV是AliSQL高性能K-V接口，InnoDB Memcached Plugin的扩展。

• 我们将Data Type支持能力丰富了，不光支持Float/Double、Integer、Decimal，还包括DateTime、Char/Varchar、Custom Format。
• 用KV访问数据支持的接口比较有限，我们在功能上也做了增强，比如Multi get from multi tables，Non-unique index，composite indexes & prefix search，能够覆盖更多的场景。
• X-KV新协议。InnoDB Memcached Plugin存在一些问题，通过指定delimiter来区分每一列，delimiter如何选择？NULL和空值无法区分，NULL = 空。
  X-KV新协议将以上问题解决了，我们将返回的Field=Meta Info + Data,加Meta Info来描述返回数据，Meta Info有Version|Count|Length1|Length2|Length3…
• 可运维性优化。官方设计不考虑太多运维性，导致InnoDB Memcached Plugin存在一些问题，比如表结构变更后，如何使得KV接口能够无缝的切换到新的schema， 原有的plugin uninstall ->install 方式对业务有较大影响。X-KV通过扩充Container表，支持了在线的KV配置变更，通过版本号来控制新旧版本的schema配置并自动重新加载。
• 性能优化。
  

  

  我们模拟阿里的交易数据库上的Query请求做了验证，相对于走SQL，我们提升了5倍左右的性能。

X-Cluster：AliSQL集群解决方案

• 首先是数据一致性的问题。传统的数据库都是主备的异步复制，异步复制带来的是数据质量问题；官方为了解决问题，提出半同步复制，但半同步复制过段时间会降级。所以它们都很难百分百保证数据质量。
• 持续高可用问题。当我们搭建完MySQL主备后，主备本身不会做切换，不会做高可用，真正的高可用是在主备之外使用一个外部组件，比如基于zookeeper的HA来提供高可用功能。
• 区域化/全球化部署问题。过去几年我们分享最多的是异地双活和异地多活，我们要做到真正多城市多活高可用，需要集群能耗跨城市部署，跨国际部署。
• 上下游生态联动。我们的数据库不仅仅作数据存取，下游还要给其他系统作消费。

能不能用一种技术尝试解决掉这些问题呢？这是我们做X-Cluster的初衷。

• 一体化架构：运维友好
• 极致性能：同城三副本相对于单机性能下降在10%以内
• 可异地部署：异地部署，延时增加，但是保持高吞吐
• 稳定性：网络抖动高容忍性
• 兼容性：对原有生态100%兼容

我们交付出一个AliSQL集群化的解决方案，将分布式一致性协议Paxos引入到AliSQL上，我们可以去组件一个AliSQL真正的集群，通过Paxos实现日志的强同步，实现自动化选主。

X-Cluster核心技术

Batching & Pipelining

Pipelining是当一批往follower发送时，follower返回之前能不能把下一批在leader上已经完成的事务再发出去，这样就会同时有多批事务从leader等待follower达成多数派，这就是所谓的Pipelining。原来Batching时，是一次只能发一批，等应答后再发下一批，每一批至少会有一个网络的RTT，Pipelining好处是在第一批没有应答前就可以发送第二批···
引入Pipelining就会带来乱序，导致日志空洞，会出现乱序接收。Paxos可以作乱序确认，乱序确认的好处是，如果有日志空洞，任意两个副本达成多数派，都认为事务提交成功。每一个follower上都有空洞，但是将两个follower拼在一起，它是一个完整的日志流。

Locality Aware Content Distribution

日志实现

Asynchronously Commit

X-Cluster: vs MySQL Group Replication

X-Cluster生态

持续备份

原有MySQL备份逻辑是：定期备份Binlog文件；RPO一般比较大，例如：大于5分钟；备份跟MySQL的数据一致性保障困难。
X-Cluster可以解决备份的一些不便之处：备份节点作为X-Cluster的一个Learner节点，实时推送X-Cluster上达成多数派的日志；RPO < 1秒；由于备份的一定是达成多数派的日志，因此无数据一致性问题。

自动化高可用

自动化增量日志消费

原有MySQL下游日志消费准实时消费MySQL产生的日志，问题之一是数据一致性；问题之二是数据库主备切换与下游消费端的联动。
X-Cluster自动化增量日志消费，日志消费节点作为X-Cluster的Learner节点，只消费达成多数派的日志，保证数据一致性；X-Cluster自动选主，新Leader自动向日志消费节点推送新日志，彻底解决联动问题。

区域化/全球化部署

• 按需增加Learner节点：增加读能力，但是不会带来强同步开销
• 按需增加Log节点：Log节点只有日志，没有数据；Log节点可参与选主，但是没有新增存储开销。低成本节点；3节点X-Cluster = 2节点MySQL主备。
• 权重化体系：可以指定节点选主权重，控制每个节点的选主优先级。

X-Cluster实战总结

一路走来，我们并不是一帆风顺，也踩过很多坑，比如：

• 异常处理：硬件异常，网络异常：Leader Stickiness
• Batching & Pipelining：极大事务，极小事务，不同网络时延下的Batching/Pipelining策略，网络异常情况下的Batching/Pipelining策略
• 全球化部署下的优化：权重体系、热点带来的影响