数据的高可用性
什么是高可用?
高可用性(High Availability),简称 HA 。一般指一个系统经过专门的系统架构设计,保证长时间不间断的提供服务,保持其服务的高度可用性。高可用性通常通过提高系统的容错能力来实现。定义一个系统怎样才算具有高可用性往往需要根据不同的场景来采取不同的措施。
衡量高可用的标准
业界主要使用 Service Level Agrement ,简称 SLA 。中文名为:服务级别协议,也称服务等级协议、服务水平协议,是服务提供商与用户之间定义的正式承诺。也就是我们使用的的各大云服务厂商所标识的可用性「5 个 9」99.999% 这类的数字,就是基于这个协议来计算的。
常见的计算公式为:故障发生到恢复的时间。
可用性% | 宕机时间/年 | 宕机时间/月 | 宕机时间/周 | 宕机时间/天 |
---|---|---|---|---|
90% (1 个 9) | 36.5 天 | 72 小时 | 16.8 小时 | 2.4 小时 |
99% (2 个 9) | 3.65 天 | 7.20 小时 | 1.68 小时 | 14.4 分 |
99.9% (3 个 9) | 8.76 小时 | 43.8 分 | 10.1 分钟 | 1.44 分 |
99.99% (4 个 9) | 52.56 分 | 4.38 分 | 1.01 分钟 | 8.66 秒 |
99.999% (5 个 9) | 5.26 分 | 25.9 秒 | 6.05 秒 | 0.87 秒 |
数据高可用的常见解决方案
- 简单备份,一般指定期或按需数据全量或增量进行复制,并保存为副本,从而降低数据丢失风险的一种方式。场景1:在凌晨通过定时任务把数据库数据备份 OSS 云存储中。场景2:通过 scp 命令全量备份数据到其他服务器。场景3:通过 rsync 命令增量把数据备份到其他服务器。
-
双主节点,指存在多个 Master(主)节点,各自都提供完整的读写服务,数据备份之间的互相拷贝为了不影响读写请求的性能,通常是异步进行的。比如 MySQL Redis ,一般都是通过异步处理备份,因为同步会导致读写延迟,增加请求时间。缺陷是关于事务处理的,本地事务(即单个存储节点)可以提交成功,但是全局事务(所有存储节点)却可能失败。如果实现全局事务的时候,Multi-Master 往往不是一个好的选择。
-
读写分离,指存在一个可读可写(或者只写)的 Master 节点,而存在多个只读的 Slave 节点,每当有通过 Master 的更新出现,数据会以异步的方式单向拷贝到所有的 Slave 节点上去。 MySQL Redis 很多大型项目都是采用这个模式,缺点就是只有一个写入节点,一般会有一台容灾备份主节点、或者从节点切换为主节点,通过 VIP 配合 HAProxy 、Keepalived 来实现负载均衡高可用。Redis 则可以使用官方提供的哨兵(sentinel)模式。
-
分布式集群模式,集群模式的解决单机性能瓶颈而产生的一种解决方案,适用于超大型的项目,难点在数据一致性。
-
容灾备份,这个一般是服务提供商、云服务厂商处理,指 IDC 机房所在区域发生自然灾害,如地震,台风、火灾等等,提供同城双活、两地三中心来解决高可用,同城双活指一个城市有生产、灾备两个数据中心。两地三中心指通一个城市有生产中心、容灾中心,异地容灾中心。容灾备份是上个月参加 AWS 的训练营培训听老师讲的,之前还没关注过这个。
全文完。
打赏作者
您将是第一位评论人!