亿动网
简介
可用性是指系统保持可用并正常运作的能力。在关键业务系统中，保持高可用性至关重要，因为它可以最大限度地减少宕机时间，提高用户满意度，并保证业务连续性。
高可用性实现方案
1. 负载均衡
负载均衡器通过将请求分布到多个服务器来提高可用性。当一台服务器发生故障时，其他服务器可以接管其工作负载，从而保持系统整体的可用性。
2. 冗余
冗余是指创建系统组件的多个副本，以防其中任何一个组件出现故障。例如，可以创建数据库、服务器和网络连接的冗余。
3. 故障转移
故障转移是一种在组件发生故障时自动将工作负载切换到备用组件的机制。这可以确保系统在发生故障的情况下快速恢复。
4. 监控和警报
实时监控系统健康状况对于检测和响应故障至关重要。警报系统可以及时通知管理员有关潜在问题的，以便采取纠正措施。
5. 维护和更新
定期进行维护和更新可以预防故障并提高系统可用性。这些活动可以包括软件更新、硬件维护和性能优化。
6. 灾难恢复计划
灾难恢复计划定义了在发生重大灾难（例如自然灾害或网络攻击）时恢复系统所需采取的步骤。这可以确保即使在最极端的情况下也能保持系统可用性。
最佳实践
- 采用多层次的高可用性解决方案，例如负载均衡、冗余和故障转移。
- 定期测试高可用性解决方案以确保其正常运行。
- 实施持续监控和警报系统以快速检测和解决问题。
- 制定并定期演练灾难恢复计划。
- 与供应商和服务提供商合作，确保他们提供高可用性服务和支持。
结论
实施高可用性解决方案对于保持关键业务系统持续可用至关重要。通过采用负载均衡、冗余、故障转移、监控、维护和灾难恢复计划等措施，组织可以显著提高其系统的可用性，从而提高用户满意度，降低业务风险，并确保业务连续性。
sql server高可用性解决方案都有哪些
SQL Server 提供了几个为服务器或数据库打造高可用性的可选方案。
高可用性可选方案包括：AlwaysOn 故障转移群集实例作为 SQL Server AlwaysOn 产品/服务的一部分，AlwaysOn 故障转移群集实例利用 Windows Server 故障转移群集 (WSFC) 功能通过冗余在实例级别（故障转移群集实例 (FCI)）提供了本地高可用性。
FCI 是在 Windows Server 故障转移群集 (WSFC) 节点上和（可能）多个子网中安装的单个 SQL Server 实例。
在网络中，FCI 显示为在单台计算机上运行的 SQL Server 实例，不过它提供了从一个 WSFC 节点到另一个 WSFC 节点的故障转移（如果当前节点不可用）。
有关详细信息，请参阅 AlwaysOn 故障转移群集实例 (SQL Server)。
AlwaysOn 可用性组AlwaysOn 可用性组 是 SQL Server 2012 中引入的企业级高可用性和灾难恢复解决方案，可使一个或多个用户数据库的可用性达到最高。
AlwaysOn 可用性组要求 SQL Server 实例驻留在 Windows Server 故障转移群集 (WSFC) 节点上。
有关详细信息，请参阅 AlwaysOn 可用性组 (SQL Server)。
注意 注意FCI 可利用 AlwaysOn 可用性组提供数据库级别的远程灾难恢复。
有关详细信息，请参阅故障转移群集和 AlwaysOn 可用性组 (SQL Server)。
数据库镜像注意 注意后续版本的 Microsoft SQL Server 将删除该功能。
请避免在新的开发工作中使用该功能，并着手修改当前还在使用该功能的应用程序。
建议改用 AlwaysOn 可用性组。
数据库镜像是一种解决方案，可提供几乎是瞬时的故障转移，以提高数据库的可用性。
数据库镜像可以用来维护相应生产数据库（称为“主体数据库”）的单个备用数据库（或“镜像数据库”）。
有关详细信息，请参阅数据库镜像 (SQL Server)。
日志传送与 AlwaysOn 可用性组 和数据库镜像一样，日志传送是数据库级操作。
可以使用日志传送来维护单个生产数据库（称为“主数据库”）的一个或多个热备用数据库（称为“辅助数据库”）。
有关日志传送的详细信息，请参阅关于日志传送 (SQL Server)。
MySQL高可用的几种方案
MySQL的各种高可用方案，大多是基于以下几种基础来部署的：基于主从复制；基于Galera协议；基于NDB引擎；基于中间件/proxy；基于共享存储；基于主机高可用；在这些可选项中，最常见的就是基于主从复制的方案，其次是基于Galera的方案，我们重点说说这两种方案。
其余几种方案在生产上用的并不多，我们只简单说下。
基于主从复制的高可用方案双节点主从 + keepalived/heartbeat一般来说，中小型规模的时候，采用这种架构是最省事的。
两个节点可以采用简单的一主一从模式，或者双主模式，并且放置于同一个VLAN中，在master节点发生故障后，利用keepalived/heartbeat的高可用机制实现快速切换到slave节点。
在这个方案里，有几个需要注意的地方：采用keepalived作为高可用方案时，两个节点最好都设置成BACKUP模式，避免因为意外情况下（比如脑裂）相互抢占导致往两个节点写入相同数据而引发冲突；把两个节点的auto_increment_increment（自增步长）和auto_increment_offset（自增起始值）设成不同值。
其目的是为了避免master节点意外宕机时，可能会有部分binlog未能及时复制到slave上被应用，从而会导致slave新写入数据的自增值和原先master上冲突了，因此一开始就使其错开；当然了，如果有合适的容错机制能解决主从自增ID冲突的话，也可以不这么做；slave节点服务器配置不要太差，否则更容易导致复制延迟。
作为热备节点的slave服务器，硬件配置不能低于master节点；如果对延迟问题很敏感的话，可考虑使用MariaDB分支版本，或者直接上线MySQL 5.7最新版本，利用多线程复制的方式可以很大程度降低复制延迟；对复制延迟特别敏感的另一个备选方案，是采用semi sync replication（就是所谓的半同步复制）或者后面会提到的PXC方案，基本上无延迟，不过事务并发性能会有不小程度的损失，需要综合评估再决定；keepalived的检测机制需要适当完善，不能仅仅只是检查mysqld进程是否存活，或者MySQL服务端口是否可通，还应该进一步做数据写入或者运算的探测，判断响应时间，如果超过设定的阈值，就可以启动切换机制；keepalived最终确定进行切换时，还需要判断slave的延迟程度。
需要事先定好规则，以便决定在延迟情况下，采取直接切换或等待何种策略。
直接切换可能因为复制延迟有些数据无法查询到而重复写入；keepalived或heartbeat自身都无法解决脑裂的问题，因此在进行服务异常判断时，可以调整判断脚本，通过对第三方节点补充检测来决定是否进行切换，可降低脑裂问题产生的风险。
双节点主从+keepalived/heartbeat方案架构示意图见下：图解：MySQL双节点（单向/双向主从复制），采用keepalived实现高可用架构。
多节点主从+MHA/MMM多节点主从，可以采用一主多从，或者双主多从的模式。
这种模式下，可以采用MHA或MMM来管理整个集群，目前MHA应用的最多，优先推荐MHA，最新的MHA也已支持MySQL 5.6的GTID模式了，是个好消息。
MHA的优势很明显：开源，用Perl开发，代码结构清晰，二次开发容易；方案成熟，故障切换时，MHA会做到较严格的判断，尽量减少数据丢失，保证数据一致性；提供一个通用框架，可根据自己的情况做自定义开发，尤其是判断和切换操作步骤；支持binlog server，可提高binlog传送效率，进一步减少数据丢失风险。
不过MHA也有些限制：需要在各个节点间打通ssh信任，这对某些公司安全制度来说是个挑战，因为如果某个节点被黑客攻破的话，其他节点也会跟着遭殃；自带提供的脚本还需要进一步补充完善，当然了，一般的使用还是够用的。
多节点主从+etcd/zookeeper在大规模节点环境下，采用keepalived或者MHA作为MySQL的高可用管理还是有些复杂或麻烦。
首先，这么多节点如果没有采用配置服务来管理，必然杂乱无章，线上切换时很容易误操作。
在较大规模环境下，建议采用etcd/zookeeper管理集群，可实现快速检测切换，以及便捷的节点管理。
基于Galera协议的高可用方案Galera是Codership提供的多主数据同步复制机制，可以实现多个节点间的数据同步复制以及读写，并且可保障数据库的服务高可用及数据一致性。
基于Galera的高可用方案主要有MariaDB Galera Cluster和Percona XtraDB Cluster（简称PXC），目前PXC用的会比较多一些。
PXC的架构示意图见下：(图片源自网络)，图解：在底层采用wsrep接口实现数据在多节点间的同步复制。
(图片源自网络)，图解：在PXC中，一次数据写入在各个节点间的验证/回滚流程。
PXC的优点服务高可用；数据同步复制(并发复制)，几乎无延迟；多个可同时读写节点，可实现写扩展，不过最好事先进行分库分表，让各个节点分别写不同的表或者库，避免让galera解决数据冲突；新节点可以自动部署，部署操作简单；数据严格一致性，尤其适合电商类应用；完全兼容MySQL；虽然有这么多好处，但也有些局限性：只支持InnoDB引擎；所有表都要有主键；不支持LOCK TABLE等显式锁操作；锁冲突、死锁问题相对更多；不支持XA；集群吞吐量/性能取决于短板；新加入节点采用SST时代价高；存在写扩大问题；如果并发事务量很大的话，建议采用InfiniBand网络，降低网络延迟；事实上，采用PXC的主要目的是解决数据的一致性问题，高可用是顺带实现的。
因为PXC存在写扩大以及短板效应，并发效率会有较大损失，类似semi sync replication机制。
其他高可用方案基于NDB Cluster，由于NDB目前仍有不少缺陷和限制，不建议在生产环境上使用；基于共享存储，一方面需要不太差的存储设备，另外共享存储可也会成为新的单点，除非采用基于高速网络的分布式存储，类似RDS的应用场景，架构方案就更复杂了，成本也可能更高；基于中间件(Proxy)，现在可靠的Proxy选择并不多，而且没有通用的Proxy，都有有所针对，比如有的专注解决读写分离，有的专注分库分表等等，真正好用的Proxy一般要自行开发；基于主机高可用，是指采用类似RHCS构建一个高可用集群后，再部署MySQL应用的方案。
老实说，我没实际用过，但从侧面了解到这种方案生产上用的并不多，可能也有些局限性所致吧；MySQL高可用的几种方案标签：
调研Redis高可用两种方案
导读：Redis是被广泛使用的基础软件之一。对于工程师和,架构师，运维人员来说，了解Redis的高可用方案和背后的原理，是必备的基础知识。本文作者深入分析了Redis高可用的方方面面，并且做了有效总结，相信对广大读者可以起到很好的领路作用。
作者 codedump 博主，多年从事互联网服务器后台开发工作。可访问作者博客阅读 codedump 更多文章。
Redis中为了实现高可用（High Availability，简称HA），采用了如下两个方式：
Redis中主从节点复制数据有全量复制和部分复制之分。
全量复制使用snyc命令来实现，其流程是：
旧版本全量复制功能，其最大的问题是从服务器断线重连时，即便在从服务器上已经有一部分数据了，也需要进行全量复制，这样做的效率很低，于是新版本的Redis在这部分做了改进。
新版本Redis使用psync命令来代替sync命令，该命令既可以实现完整全同步也可以实现部分同步。
执行复制的双方，主从服务器，分别会维护一个复制偏移量：
主服务器内部维护了一个固定长度的先进先出队列做为复制积压缓冲区，其默认大小为1MB。
在主服务器进行命令传播时，不仅会将写命令同步到从服务器，还会将写命令写入复制积压缓冲区。
每个Redis服务器，都有其运行ID，运行ID由服务器在启动时自动生成，主服务器会将自己的运行ID发送给从服务器，而从服务器会将主服务器的运行ID保存起来。
从服务器Redis断线重连之后进行同步时，就是根据运行ID来判断同步的进度：
有了前面的准备，下面开始分析psync命令的流程：
前面两种情况主服务器收到psync命令之后，会出现以下三种可能：
Redis使用哨兵机制来实现高可用(HA)，其大概工作原理是：
以上将Redis节点分为两类：
以上是大体的流程，这个流程需要解决以下几个问题：
以下来逐个回答这些问题。
哨兵节点通过三个定时监控任务监控Redis数据节点的服务可用性。
每隔10秒，每个哨兵节点都会向主、从Redis数据节点发送info命令，获取新的拓扑结构信息。
Redis拓扑结构信息包括了：
这样，哨兵节点就能从info命令中自动获取到从节点信息，因此那些后续才加入的从节点信息不需要显式配置就能自动感知。
这一操作实际上完成了两件事情： * 发现新的哨兵节点：如果有新的哨兵节点加入，此时保存下来这个新哨兵节点的信息，后续与该哨兵节点建立连接。 * 交换主节点的状态信息，作为后续客观判断主节点下线的依据。
每隔1秒，每个哨兵节点向主、从数据节点以及其他sentinel节点发送ping命令做心跳探测，这个心跳探测是后续主观判断数据节点下线的依据。
上面三个监控任务中的第三个探测心跳任务，如果在配置的down-after-milliseconds之后没有收到有效回复，那么就认为该数据节点“主观下线（sdown）”。
为什么称为“主观下线”？因为在一个分布式系统中，有多个机器在一起联动工作，网络可能出现各种状况，仅凭一个节点的判断还不足以认为一个数据节点下线了，这就需要后面的“客观下线”。
当一个哨兵节点认为主节点主观下线时，该哨兵节点需要通过”sentinel is-master-down-by addr”命令向其他哨兵节点咨询该主节点是否下线了，如果有超过半数的哨兵节点都回答了下线，此时认为主节点“客观下线”。
当主节点客观下线时，需要选举出一个哨兵节点做为哨兵领导者，以完成后续选出新的主节点的工作。
这个选举的大体思路是：
可以看到，这个选举领导者的流程很像raft中选举leader的流程。
在剩下的Redis从节点中，按照以下顺序来选择新的主节点：
选择了新的主节点之后，还需要最后的流程让该节点成为新的主节点：
原文地址：
参考阅读：
GIAC全球互联网架构大会深圳站将于2019年6月举行，掌阅资深架构师，畅销图书《Redis 深度历险：核心原理与应用实践》作者钱文品将作为数据库专场的讲师出席2019年GIAC深圳站，并做关于Redis高性能，高可用方面的的演讲。本届GIAC数据库专场邀请阿里云前数据库总负责人余峰作为出品人，议题如下。
参加 GIAC，盘点2019年最新技术，目前 购买7.5折优惠 ，多人购买有更多优惠。识别二维码 了解大会更多详情。
