阿里云InfluxDB®高可用设计

  1. 云栖社区>
  2. 阿里云InfluxDB®>
  3. 博客>
  4. 正文

阿里云InfluxDB®高可用设计

dengzhi 2019-12-11 17:33:22 浏览1208
展开阅读全文

阿里云InfluxDB®是一版免运维,稳定可靠,可弹性伸缩的在线时序数据库服务,目前围绕InfluxDB的TIG(Telegraf/InfluxDB/Grafana)生态和高可用服务版本已经商业化,可以在阿里云官网直接购买。在日常业务中,用户会比较关心两个问题:

  1. 实例故障后,之前写的数据会丢吗?
  2. 你的服务能提供不间断服务吗,实例故障后能不能迅速恢复?

对于问题1,阿里云InfluxDB®底层采用了自研盘古分布式存储系统,保证了数据99.9999999%的高可靠性;并且InfluxDB采用WAL机制来保障恢复重启实例中cache的写入数据;
对于问题2,目前阿里云InfluxDB®采用了基于raft一致性协议的三副本机制,当其中某个节点故障之后保证能够持续提供数据写入、查询服务。
高可用相对于单机版本,能提供更高服务SLA保障。本文接下来也主要针对阿里云InfluxDB®高可用设计和Raft协议内部原理展开具体描述。

高可用架构设计

数据服务高可用目前似乎是软件设计必要考虑要素。在实际的工程实践中,基于需求有各种不同的解决方案,如SQL Server的share everything;Oracle RAC的share storage;GPDB/Spanner的share nothing架构;最近,基于kubenetes容器编排技术的高可用方案也越来越受欢迎。
Share everything/storage架构方案一般会被具有资深研发背景的数据库厂商采用;在大部分互联网初创公司或者数据库产品发展的早期技术栈中,share nothing的分布式架构使用比较广泛,它利用多副本机制来保障服务的可靠性,某个节点出现故障时,能迅速切换到备用节点继续提供服务;容器编排技术通过将服务资源进行统一封装管理,当节点故障之后能够快速拉起继续提供服务。
阿里云InfluxDB®的高可用架构设计中,也充分调研了各种技术方案:
一、基于共享存储:各个实例通过挂载共享存储,共享存储在节点故障时不需要数据迁移,可以即时拉起,目前在计算存储分离架构中运用比较多。对于有状态的共享存储服务,常常需要解决用户态文件缓存和内存cache数据同步问题,也要避免写文件冲突,需要引入类似GFS的分布式文件系统,实现比较复杂。

二、Share nothing技术方案:Share nothing的各副本之间分为有角色管理和无角色管理两种。为了保证各个副本数据一致以及事务之间的隔离性,两种技术方案在实现细节上有较大的不同。

  • 无角色管理:无角色管理较为经典的有Dynamo的NWR模型,也称写多数协议,即在N个副本中需要至少写W个副本才能标记写入成功;对于读操作一样,查询次数R要保证R>N-W,从R份查询结果中找出数据的最新版本返回。NWR协议存在储存脏数据问题,InfluxDB Enterprise通过Anti-Entropy Repair技术对各个副本定期扫描修复来实现数据的最终一致性,但实现复杂度比较高,具有高延迟和高资源消耗。
  • 有角色管理:在左耳朵耗子的<分布式系统的事务处理>中,副本之前的角色主要分为M/S, M/M, Leader-Fellower等。M/S, M/M之间通过异步复制保证数据一致性,M/S需要容忍节点间延迟以及故障恢复时服务的短暂中断;M/M需要解决对同一条记录更新的写写冲突,需要引入逻辑时钟或者分布式锁的概念,技术难度高。

在分布式协议发展的后期,为了实现故障恢复时Master、Slave之间角色的自动轮转,实现了Paxos与Raft协议。本人觉得两阶段提交的Paxos与Raft协议同属于一个技术栈,Raft协议相对来说更易理解,在Go技术栈中运用更为广泛,故选取了Raft一致性协议来实现高可用副本之间数据的一致性问题。Raft协议的具体选举算法可以参考Paper<In Search of an Understandable Consensus Algorithm>以及译文<Raft一致性算法论文译文>。Raft协议通过先写数据操作日志,然后回放Apply操作来保证各个节点间数据的一致性。为了保证各个副本角色切换后Raft日志的一致性,Raft在日志写入和匹配的时候保证了以下特性:

  • 如果在不同日志中的两个条目有着相同的索引和任期号,则它们所存储的命令是相同的。
  • 如果在不同日志中的两个条目有着相同的索引和任期号,则它们之间的所有条目都是完全一样的。

第一条保证了任意一条日志的索引位置创建后不会改变;第二条保证了新的Leader被选举后,日志追加写入时,其它Fellower节点需要检查保证与Leader节点日志一致。时序的应用场景中,在有大量写入的业务中,需要保证写入节点不可用之后服务快速恢复,作为公有云服务,保证写入数据不丢失和查询的最终一致性,并且Raft实现比较轻量,最终我们采用了Raft这一开源的分布式协议。

阿里云InfluxDB®高可用方案

image
如上图所示,阿里云InfluxDB的高可用架构侧重于AP,对于数据/元数据的写和更新,采用Raft一致性协议;为缩短查询流程,读采用了弱一致性。

  • 元数据更新:为避免元数据脏写以及数据库元信息与实际数据不对称,元数据更新采用了串行执行的方案,apply之前必须保证其它所有操作Apply结束才进行元数据修改。
  • 时间点写入更新:为尽量减少节点间数据同步对写入吞吐的影响,考虑到时间点数据较少存在写冲突,对于时间点的写入采用了并发apply模型。当前节点接收到数据之后会同步到leader节点,序列化raft entry log。raft内部通信模块将这些entry log以message的方式批量同步到各个节点apply执行。当前阿里云InfluxDB®在请求接收点和master节点apply成功后便返回给客户端。
  • 数据查询:数据查询类操作为缩短执行流程,采用了弱一致性方案,没有走raft流程,在请求节点执行成功后便返回给客户端。

Raft一致性协议

关于raft的选举算法,在各篇文章中有详细的介绍,这里便不再做具体描述,下面主要介绍raft数据写入流程和数据存储策略。

raft数据写入流程

image
数据写入流程如上图所示:

  1. 若接收请求的节点(A)为follower节点,首先会将请求以message的形式发送到leader节点(B);
  2. leader节点(B)收到请求的raft entry log后,会将log序列化写入存储中;
  3. leader节点(B)raft内部的决策系统会轮循当前节点状态和log同步进度,定期将raft log以批量的方式同步到fellower节点(A/C);
  4. fellower节点(A/C)收到leader节点(B)推送的数据后也会将entry log序列化存储,并更新同步状态,处理完后回复leader节点(B);
  5. 当leader节点收到所有fellower节点数据同步完成之后更新commit index并回复propose节点(A);
  6. 各节点的raft模块并发扫描本地raft log entry 执行;
  7. 请求节点(A)apply 执行完成后返回给客户端。

raft storage

raft storage用于存储raft log entry,raft log由以下成员组成:

  • storage :存放已经持久化数据的storage接口,append数据将在此保存。
  • unstable ents:unstable结构体,用于保存应用层还没有持久化的数据。
  • committed index:保存当前提交的日志数据索引。
  • applied index:保存当前传入状态机的数据最高索引,索引之前的数据操作均已apply。
  • firstIndex: 保存了snapshot之后active raft log第一条日志的索引。
  • lastIndex: 保存了应用层持久化后的最后一条日志的索引。
  • unstable.offset:为lastIndex索引的下一个索引值。
    image

replicate时,如果next标记的索引值介于snapshot和unstable.offset之间(firstIndex<=next<=lastIndex),则从leader的持久化日志中读取entry进行同步;接着unstable ents也会发送到应用层storage中进行持久化;当storage持久化日志数据之后,便根据apply和commit信息进行回放数据操作。
阿里云InfluxDB®为了实现raft log的持久化和故障可恢复,采用了自研的hybrid storage方案,详细可以参考<阿里云InfluxDB® Raft HybridStorage实现方案>。

总结

本文主要从工程实践的角度出发,介绍了阿里云InfluxDB®高可用架构的实现以及raft内部机制。为了提高用户服务的SLA,当前阿里云InfluxDB®高可用版本已经商业化,技术方案也在不断的演进中。未来,我们将在降低使用成本、提高性能方面做进一步提升,希望对阿里云InfluxDB®或者高可用技术感兴趣的同学能一起交流,共同打造一款服务能力更强、价格更低的阿里云InfluxDB®时序数据库产品。
image

参考文献

  1. 分布式系统的事务处理
  2. Use Anti-Entropy service in InfluxDB Enterprise
  3. Raft一致性算法论文译文
  4. 阿里云InfluxDB® Raft HybridStorage实现方案

网友评论

登录后评论
0/500
评论
dengzhi
+ 关注
所属团队号: 阿里云InfluxDB®