江苏龙网

  1. 首页 > 人文 > >

空心|Aurora，万字详文：腾讯数据库专家深度探索Amazon( 六 )


?所做的工作 ， 就是从持久化的日志数据中 ， 产生数据 ， 就如同系统故障时使用REDO日志做恢复的过程：解析REDO日志 ， 获取其中保存的数据页的修改后像 ， 恢复到类似于传统数据库的数据缓冲区中（这也是存储层需要存在“Caching”的一个明证） 。
之后 ， 第六步 ， 周期性地把修复后的日志数据和由日志生成的以页为单位的数据刷出到S3作为备份 。 第七步 ， 周期性地收集垃圾版本（PGMRPL ， 即ProtectionGroupMinReadPointLSN） ， 参考表1-2[⑨] ， 可以看到 ， 垃圾收集 ， 是以VDL为判断依据的 ， 当日志的LSN小于VDL ， 则可以被作为垃圾回收；第八步 ， 周期性地用CRC做数据校验 。
2.2储存层的设计讨论
现在再来反观Aurora的整体设计：
数据不再从数据缓冲区刷出 ， 消除了随机写操作 ， 减少了IO 。
计算和存储分离 ， 日志跨AZ写到多份存储节点 ， 存在网络IO 。
主备节点间传输日志和元数据 ， 存在网络IO 。
如上是三条核心点 ， 似乎网络IO占了三分之二条 ， 属于多数 。 但是网络IO都是批量数据顺序写 ， 可极大地抵消很多次的随机写的网络IO消耗 ， 而且通过数据冗余 ， 极大地保障了可用性和云数据的弹性 ， 从测试数据看 ， 整体性能得到了可观的提升 。 因此这样的设计是一个优秀的架构设计 。
数据冗余且有效 ， 是使用数据库系统的基本要求 。 逻辑备份与还原、物理备份与恢复、主从复制、两地三中心等灾备技术方案等都是数据冗余的相关技术 。 数据库走向对等分布式架构 ， 除了应对巨量数据的存储和计算的需要 ， 也要靠数据冗余来保证数据的可用性 。 所以数据冗余是数据系统架构设计的一个必须考虑点 。
Aurora自然也要实现数据冗余 。 如图1-5所示 ， 数据至少在3个AZ中存6份 。 如果不采用“thelogisthedatabase”的理念 ， 而使用传统数据库的技术 ， 在跨节点写出多份数据时 ， 势必需要采用2PC/3PC等多阶段的方式来保证提交数据的正确性 ， 这样网络交互的次数就会很多 ， 而且大量的随机写操作会在网络蔓延 。 所以“thelogisthedatabase”的理念客观上避免了传统的、耗时昂贵的分布式事务的处理机制 ， 而又达到了数据分布的目的 ， 这又是一个亮点 。
【空心|Aurora，万字详文：腾讯数据库专家深度探索Amazon】数据至少在3个AZ中存6份 ， 其目的是要保证数据库服务的持续可用 。 那么 ， 什么算是可用呢？无论是数据中心内部的局部故障还是跨数据中心甚至跨AZ出现故障 ， AWS也要在某些情况下提供数据服务的可用 。 这就要分两种情况确定 ， 这两种情况基于6个副本的前提[⑩]（3个副本能满足多数派的读写规则 ， 但是一旦其中一个副本不可用 ， 则其余2个就不能保证读写一致 ， 基于3个副本的分布式设计是脆弱的 ， 不能切实可用地起到依靠数据冗余来换取数据可用的保障）：
第1种：读写均可用 。
如图1-9 ， 当一个AZ出现问题 ， 即2个副本不可用 ， Aurora仍然能够保证读写可用 ， 保障数据一致 。 设置V=6 ， 读多数派为Vr=3 ， 写多数派为Vw=4 ， 所以一个AZ出现故障 ， 或者3个AZ中的两个数据中心出现故障 ， Aurora依然能够向外提供服务 。
第2种：至少读可用 。
当写服务不可用 ， 至少还可以提供读服务 。 设置V=6 ， 读多数派为Vr=3 ， 写多数派为Vw=4时 ， 一个AZ出现故障依旧能够提供读服务 ， 如图1-10甚至跨不同AZ的3个数据中心出现故障（概率非常小） ， 读服务依旧能够提供 。


推荐阅读


上一篇：几品飞车|互联网分层架构的本质

下一篇：三好先森|RC 发布，基于AntV的权限管理系统，CatchAdmin