作者：王涛（改天）
一、双十一数据库回顾
阿里双11期间成交额4982亿，高峰订单58.3万笔/秒，数据库高峰TPS1.4亿/秒。核心数据库，比如手机淘宝上看到的交易、购物车、商品、商品详情优惠等，都来自于我们团队数据库，核心链路采用云数据库专属集群（MyBase）模式，基于云原生数据库构建上万个节点RPO=0。全面采用云原生管控形态，交易单元核心链路实现100% PaaS云化，扩容效率提升10倍，与此前相比，扩容时间由30分钟缩短至3分钟。
二、数据库应用场景介绍
1）阿里业务特性介绍—RDS高可用版
一种是RDS的高可用版， RDS的高可用版是我们平时标准的一种数据库形式，采用是一组多备的模式。大家可以看到上图，一个Master，一个Slave，拖了多个RO节点，这个RO节点就是只读节点，它有个缺点，无法真正做到RPO=0。
MySQL基于半同步来做，但是半同步有一个问题，如果当Slave挂掉，半同步会自动降级。MySQL最主要核心还是为了保证主库的高可用，而不是数据一致的高可用，像Oracle等其他商业数据库，当备库被挂掉的情况下，如果你设置合理，备库会摘主库写的操作，但是MySQL不会，所以说无法真正做到RPO=0。
2）阿里业务特性介绍—RDS三节点企业版（一）
使用RDS三节点企业版的目标：解决RPO=0的问题。
RDS三节点企业版理论依据：第一点是基于CAP原则 or BASE理论，CAP原理指一致性(Consistency)，可用性(Availability)，分区容忍性(Partition)。一般来说，CAP原理只能满足CA或CP，很难保证三个都满足，最后还是做了取舍，满足一致性和可用性为主。
第二个是BASE理论，BASE理论表示最终一致性，中间允许有一定的不一致，但是作为数据库OLTP系统来说没法使用BASE理论。所以还是要遵循CAP原则。
MySQL不丢数据的实现方式：
- MySQL半同步，问题是半同步一定要等备库返回才会执行，如果在备库挂的情况下，MySQL不等备库，会造成MySQL半同步降级，主库写了备库没有接收到日志，所以没办法用。
- MySQL Group Replication
第一点，它的性能不是很好；第二点，“Group Replication”中所谓的Group，至少要三个节点以上，三个节点表示有三份数据，成本开销巨大。
- RDS自研
RDS自研，是目前使用的方式。
实现协议
- Paxos协议 or Raft协议？
目前业界主流的分布式协议主要是两个，一个是Paxos协议，一个是基于Raft协议，我们最终选择使用的是Raft协议。
3）阿里业务特性介绍—RDS三节点企业版（二）
上图, P代表Prepare，Prepare表示事务准备提交，A代表Accept，Accept表示一定接受。
第一点，P3.1准备提交，如果A3.1还没提交，大家没有达成一致的情况下，又发起P4.5提交，这时候可以发起 P4.5动作，但如果是Raft协议，一定要P3.1全部提交，A3.1全部确认完以后，它才能启动P4.5。
第二点，A3.1和A4.5，他们同时进行提交，只要达到多数派我们就能提交。Paxos协议和Raft的协议最大的区别就在于Paxos协议可以乱序，只要最终一致就可以；Raft的协议是有序的，如果有一个日志没有进行下去，那么下一个没办法开始，而 Paxos可以。
Paxos有三个角色，Propose，发起者；Accept，接收者；Learn，观察者。
RDS三节点企业版，我们进行针对MySQL的应用场景，进行重新的角色设计：
Propose – Leader
Accept – Follower/Logger
Learn – Learner
Leader是数据库的主节点，主要针对数据库的读和写，主要是写，Follower有全量数据，有资格成为Leader。Logger节点主要是存放数据，保证三节点的投票和协议能够进行下去。Learner有全量数据，但是没有投票权。
重新设计角色可以更好地满足Paxos协议，同时性能更好，节省成本。Leader和Follower可以有全量的数据；Logger只有日志，没有数据，但是有投票权，不过它不能成为Leader；Learner有全量数据，但没有投票权。这就是当前使用的RDS三节点企业版。
4）阿里业务特性介绍—RDS异地多写
由于阿里的业务比较复杂，所以是异地多写的。见上图左半部分，我们有多套环境，环境一对应一组应用，有交易、购物车、商品等，然后写到中心数据库：Store或者Wright。Store主要的作用是从数据库里面脱下日志，Wright主要是将Store上的日志应用到对应单元去，又通过Store，然后Wright反写回去。ThreadId保证了数据标识及事务表做记录，异地多写的过程不会产生循环复制。
5）阿里业务特性介绍—业务异地多活
异地多活主要解决以下几个问题：
- 具备Region级别逃逸能力
- 用户可以在任意单元进行交易
上图表示，用户按照一定的规则分流，可能写在中心，也可能写在单元。单元是自封闭的，然后呈星状复制。
异地多活意义：
- 水平扩展能力
- 异地容灾能力
6）阿里业务特性介绍—RDS异地只读
异地只读意义：
- Learner全量数据
- Learner不影响Paxos协议
- 每个Learner都有灾备节点
- 基于数据库原生复制一致性高
三、数据库上云方案选择
1）上云方案选择—数据上云方案选择
数据上云方式对比
上云的方案选择，原来阿里巴巴都是全部在自建IDC，方案选择上一是逻辑迁移，MySQL和DTS都认为是逻辑牵引；二是物理迁移。
如何选择通过以下几点对比总结：
效率上，MySQL dump效率没有直传恢复效率高，直传恢复可以实现一个t一个小时，如果使用MySQL dump，从导出到导入一个t大约需要2-3个小时。
迁移性上，数据对象的平滑迁移，如阿里巴巴的数据库可能比较简单，只有table，但是有的业务数据库还有其他类型数据，就不太适合使用MySQL dump。
数据的一致性，备库用数据直传恢复比较好，用户自定义的权限很容易丢，如果使用直传恢复就很少会发生，所以使用直传恢复XtraBackup来做。
RDS产品支持物理迁移对比
RDS产品支持物理迁移对比，现有两个产品，RDS的版本它是不支持的，但是RDS的MyBase版本是支持的， MyBase数据库主机支持 extra backup物理直传上云。
2）上云方案选择—网络特性调研
网络特性对比
网络特性方面，刚开始使用ALB。现在RDS基本上都使用ALB和NGLB，ALB方案成熟，但有个问题，每一条数据的读和写都会经过ALB，会多一层，达不到极致性能要求；NGLB解决了每一条读和写都会经过的问题，只要首包经过，但是例如在双十一0点数据爆发的时候，性能压力会比较大，这种情况不一定适合使用NGLB；ENI弹性网卡，弹性网卡是标准的云产品，目前的亚马逊等其他云厂商都在使用，程序弹性网卡不支持物理机，ECS的绑卡限制，信息安全组，都是它的一些限制，但是ENI+MyBase可以解决这个问题。
总结来说：应用和数据库在同一网络平面上，然后中间没有代理层，没有NGLB或者ALB这一层，效率会比较高，管控和用户在两个IP上面，管控有IP，用户应用又是一个IP，需要管控这边进行实现。
思考+结论
基于上面有两个思考，就是数据要双向流动又能出，还有性能的考虑，所以使用是弹性网卡+MyBase的方案。
3）上云方案选择—网络拓扑图
如上图所示是网络拓扑图，最上层是数据库控制面，数据库管控，需要去创建RDS实例等，RDS部署在一个VPC环境，RDS售卖区的VPC是中心的VPC， 每个ECS上可以部署多个数据库，这里换了n多个POd，一个POd就代表一个数据库，对应的是一个弹性网卡， ECS上面飘了一个弹性网卡，连到了用户的VPC，用户之间的VPC是互相打通的，这里用的是 CEN阿里巴巴云企业网，保证用户 VPC和VPC之间相通，上面部分ECS和ECS之间的弹性网卡也就通了，因为数据库访问到对应的用户VPC，用户之间通过云企业网直接打通。用户自建网络和VPC相通是通过拉专线。
4）上云方案选择—逻辑金属服务器介绍（一）
如上图所示是阿里云的逻辑金属服务器，最底层是阿里云X-Dragon芯片，上面跑着容器第三方虚拟化等；X-Dragon云服务器，上面跑着Doctor、 Container、 Punch等一些容器。
5）上云方案选择--逻辑金属服务器介绍（二）
逻辑金属服务器分为以下几块：
绿色部分的MOC卡主要是一个独立的小型计算机，作用是联通VPC\SLB，EBS云盘。逻辑金属服务器上还有一个独立的CPU和内存，如果是在机器上硬件本地的，想要访问这个ECS的云盘等就是通过下面的MOC卡，然后再录过去。
使用逻辑金属服务器是因为几个特性：
- 分钟级交付， 资源弹性
- 兼容 VPC/SLB/RDS 等
- 云盘启动云盘挂载（系统盘和数据盘，使用的都是云盘）
- 兼容虚拟机镜像
- 物理机的性能 + 隔离性
- 虚拟机VNC/控 制台/OpenAPI 体验
- 宕机迁移恢复
- 免人肉自动运维
6）上云方案选择—机器选择
如上图综合对比，从运维自动化、计算、存储、网络、ecs等多角度，逻辑金属服务器是最优的。
7）上云方案选择—存储选择
还有一个存储的选择。目前本地盘最大的规格支持6t，而云盘的规格最大支持16t，从数据的扩展角度来说，云盘最好。云盘的快照能力，云盘具有很强的扩张能力，可以支持分钟级的备份，如果本地盘全量备份一次，用XtraBackup，是一个t一个小时，和数据量成正比，而云盘不会这么慢。
分钟级的克隆。RDS界面可以支持数据克隆，如果基于云盘快照来做克隆，会更快。跨Region的克隆，云盘是支持，如果数据在是本地盘，想看备份，那本地的数据传到异地，过程就会非常漫长，克隆的恢复时间也是巨大的。
云盘支持在线扩容，本地盘不支持，如果本地盘买的是500M实例，要扩到510G可能还有空间，可以很快地进行扩容；如果500g要突然间扩成6个T，机器上没有这么多空间的情况下，那是没办法做在线扩容，这时候要挪数据，在运维窗口中切换等，时间又是一个非常慢的过程。
磁盘IOPS可配置性。云盘上可以选PL1到PL3，可以选磁盘的性能等级，但本地盘是没有可选项的。
MySQL原子写。通过云盘可以保证原子写，而本地盘MySQL有double right的写，主要保证写的原始性，MySQL一个页的大小是16k， Linux最大的一个页写入就是4k，云盘没有这个问题，只要一次写就可以了，本地盘要写两遍。
可靠性方面，云盘的可靠性会比本地盘高，本地盘做的是LVM，但是云盘有三副本。
8）上云方案选择 – 充分利用MyBase特性
传统的RDS是随机打散的，客户买了一个4c4g的实力或者8c8g的实力，不知道部署在哪里，更多买的是一个MySQL服务，如果我们使用MyBase特性，有几个特点，亲和性等，可以调度MyBase实例，实例上面跑的是购物车或者商品，其他的东西都是可以自己去指定的。
如上图所示，Leader和Follower交叉部署，可以保证一个性能最大化，50%是A业务的组，50%是B业务的组，这样的效率是最高的，弹性、隔离、超慢都可以自己实现，每个机器上挂的是分布式存储，可以快速的弹性，从a节点快速弹到b节点。
9）上云方案选择 – 异地只读(GDN)
异地只读是在阿里云官网买的实例就是各Region独立。在这个项目里面，上云的时候，使用了GDN方案(Global Database Network)，如上图所示，是上海三节点，上海的APP通过Mark scale进行了读和写，都在上海本地，如果深圳的APP通过Mark scale进行读写分离，然后把读的流量路由到上海中心，写的流量在深圳本地，这样就可以做到了读写分离的作用，而目前只是在阿里内部使用。
四、未来展望
2020双11，MySQL数据使用的是MyBase产品形态，客户可以自己选择亲和性隔离等，经过了上游评估、网络评估、机器评估、数据库本身的形态评估还有异地只读，保证了2020年双11的平滑。
整个RDS经过了几个过程：
- 物理机形态，物理机形态就是最早的RDS；
- 存计分离形态，存计分离形态就是的云盘板形态；
- MyBase形态，多样性方面已在灰度；
- 智能化，通过RDS控制台可以看到大致的页面，已经在做智能化方向，后面智能调参，SQL优化、SQL诊断，性能诊断等都是要做的方向。
