写在前面
在京举行的2017中国数据库技术大会上，来自阿里巴巴集团研究员张瑞发表了题为《面向未来的数据库体系架构的思考》的主题演讲，主要介绍了阿里数据库技术团队正在建设阿里下一代数据库技术体系的想法和经验，希望能够把阿里的成果、踩过的坑以及面向未来思考介绍给与会者，为中国数据库技术的发展出一份力。
张瑞发会上讲了以下几方面内容：首先是在内核上的一点创新、数据库怎么实现弹性调度、关于智能化的思考、最后是曾经踩过的坑和看到未来的方向。
阿里场景下数据库所面临的问题
首先说一下，阿里巴巴最早一代使用的数据库技术是Oracle，后面大家也知道一件事情就是去IOE，去IOE过程中我们迈向了使用开源数据库的时代，这个时代今天已经过去，这个过程大概持续了五六年，整个阿里巴巴有一个大家都知道的开源MYSQL分支--AliSQL，在上面做了大量的改进。面向未来的下一代数据库技术、数据库架构会往哪个方向走。
今天的阿里巴巴是一个技术的公司，所以很多时候我们会看比如说Google或者是一些互联网的大的公司，他们在技术上创新点来自于哪里？来自于问题。
可以看到其实阿里巴巴的应用和Facebook、Google的还是有很大区别的，他们的业务场景真的不一样，首先阿里巴巴的主要应用是交易型的，这些应用会有些什么要求，你会看到有这些点，下面主要讲一下我们的思考。
今天数据的高可用和强一致是非常重要的，数据不一致带来的问题是非常非常巨大的，大家也用淘宝，也是阿里巴巴一些服务的用户，数据不一致带来的问题，每一个用户都会关注这些事情。
第二，今天存储成本是非常高的，所有的数据中心已经在用SSD，但数据的存储成本依然是一个大型企业面临的一个非常大的问题，这都是实实在在钱的问题。
另外刚才也提到了，数据都是有生命周期的，那么数据尤其是交易数据是有非常明显的冷和热的状态，大家一定很少看自己一年前在淘宝的购买记录，但是当下的购买记录会去看，那系统就需要经常会去读它、更新它。
还有一个特点是今天阿里的业务还是相对简单的，比如要在OLTP性能上做到极致性。还有一个阿里巴巴特有的点就是双十一，双十一本质上是什么，本质上就是制造了一个技术上非常大的热点效应。这对我们提出什么样的需求呢？需求就是一个极致弹性的能力，数据库实际上在这个方向是非常欠缺的，数据库怎么样去做到弹性伸缩是非常难的事情。
最后说说DBA，阿里在智能化这个方向上得到的思考是什么样的，有海量的数据，也有很多经验很丰富的DBA，但这些DBA怎么样去完成下一步的转型、怎么样不成为业务的瓶颈？数据库怎么样做到自诊断、自优化。
阿里在数据库内核方向上的思考
我先讲一下我们在数据库内核上的思考。首先我很尊敬做国产数据库的厂商，凡是在内核上改进的人都知道，其实每个功能都是要一行行代码写出来都是非常不容易的，我想表达对国产数据库厂商包括这些技术人的尊敬。今天我要讲的内容是我第一次在国内的会议上来讲，首先我会讲一下AliSQL X-Cluster。X-Cluster是在AliSQL上做的一个三节点集群，这是在引入了Paxos一致性协议，保证MySQL变成一个集群，并且这个集群具有数据强一致、面向异地部署，且能够容忍网络高延迟等一系列特性。
今天很多数据库都会和Paxos联系在一起，比如大家都知道的Google的Spanser数据库，但是以前大家没有特别想过数据库和Paxos会有什么关系，其实以前确实没有什么关系的，但是今天的数据库在几个地方是需要用到Paxos协议的，第一个我们需要用Paxos来选举，尤其在高可用的场景下需要唯一地选举出一个节点作为主节点，这就需要用到Paxos；第二是用Paxos协议来保证数据库在没有共享存储的前提下数据的强一致，就是数据怎么样在多个节点间保证是强一致，且保证高可用。
所以说现在的数据库架构设计上Paxos的应用非常广泛，今天外面很多展商包括Goolge Spanser也都在用Paxos协议和数据库结合在一起来做。所以AliSQL的三节点集群也是一样，就是利用Paxos协议变成一个数据强一致的集群。下面我大概解释一下Paxos协议在数据库里的作用是什么。
本质上来说Paxos也是现在通用的技术，大家都是搞数据库的，简单来说，Paxos协议用在我们数据库里面，就是一个事务组的提交在一个节点并落地后，必须在多个节点同时落地，也就是说原来写入只需要写入一个节点上，但是现在需要跨网络写到另外一个节点上，这个节点可能是异地的，也可能是全球的另外一个城市，中间需要经过非常漫长的网络时延，这时候需要有一些核心技术。
我们的目标是什么？首先没有办法抗拒物理时延，过去在数据库上的操作只要提交到本地，但现在数据库全球部署、异地部署，甚至跨网络，这个时延特性是没有办法克服的，但是在这种情况下我们能做到什么？在时延增长情况下尽可能保证吞吐不下降，原来做多少QPS、TPS，这一点是可以保证的，只要工程做的好是可以保证的，但是时延一定会提升。
这也是大家经常在Goolgle Spanser论文里看到的“我的时延很高”的描述，在这种时延很高的情况下，怎么样写一个好的应用来保证可用、高吞吐，这是另外一个话题。大家很长一段时间里已经习惯一个概念，那就是数据库一定是时延很低的，时延高就会导致应用出问题，实际上这个问题要花另外一个篇幅去讲，那就是应用程序必须要去适应这种时延高的数据库系统。当然用了Batching和Pipelining技术，本质上是通用的工程优化，让跨网络多复本同步变的高效，但是时延一定会增加。
实际上大家知道数据库要做三副本或者三节点，本质上就是为了实现数据强一致，而且大家都在这个方向上做努力，比如Oracle前一段时间推出的Group replication，也是三节点技术，X-Cluster和它的区别是，一开始的目标就是跨城市，最开始设计的时候就认为这个节点一定要跨非常远的距离来部署的，设计之初提出这个目标造成在设计上、工程实践上、包括最终的性能上有比较大的差异。
这里阿里巴巴做了一些X-Cluster和Oracle的Group replication的对比，同城的环境下我们要比他们好一些；在异地场景下这个差异就更大了，因为本来设计的时候就是面向异地的场景。可能大家也知道，阿里一直在讲异地多活的概念，就是IDC之间做异地多活怎么样能够做到，所以最开始设计的就是面向异地的场景做的。
这是一个典型的X-Cluster在异地多活的场景下怎么做的架构图，这是一个典型的3城市4份数据5份日志架构，如果要简化且考虑数据存储成本的话，实际上可以做到3份数据5份日志，这样的话就可以保证城市级、机房机、包括单机任何的故障都可以避免，并且是零数据丢失的，在今天阿里巴巴可以这么做，且能保证数据是零丢失、强一
再讲一个小的，但是非常实用的创新点，可能大家都比较感兴趣，这就是X-KV。这里还要说一下，阿里巴巴所有的下一代技术组件都是以X开头的。这个X-KV是基于原来MYSQL的Memcached plugin做的改进，做到非常高的性能，大家可能都了解MySQL的Memcached plugin，可以通过Memcached plugin的接口直接访问InnoDB buffer 里的数据，读的性能可以做到非常高，这对于大家来说，或者对于所谓的架构师，或者设计的过程中意义在什么地方呢？
那就是很多场景下不需要缓存了，因为数据库+缓存结构基本上是所有业务通用的场景，但是缓存的问题在于缓存和数据库里的数据永远是不一致的，需要一个同步或者失效机制来做这个事情。使用X-KV后读的问题基本上就能解决掉。这是因为一份数据只要通过这个接口访问就基本上做到和原来访问缓存差不多的能力，或者说在大部分情况下其实就不需要缓存了。
所以建议建立两个平台：1、建立一个支撑的平台，这个支撑的平台尽可能把下层存储的复杂性屏蔽掉，对上层提供统一的接口和服务；2、建立一个服务的平台，明确面向研发的平台，研发人员可以直接通过这个平台来用数据库的服务。我看到很多公司把运维平台和DBA开发的平台混在一起，但阿里的思路是，支撑平台和服务平台是两个分层的平台，支撑平台在下面，上层服务平台为所有的开发人员服务，开发人员上了这个平台就能看到我用了什么数据库，性能怎么样，在上面可以做什么事情，这样就可以大量节省DBA的人力。
