首先是对于高可用性的整体概述，对于业务系统的高可用性，实际上包括了高可靠，高性能和高扩展三个方面的内容。而且三方面相互之间还存在相互的依赖和影响关系。
对于高可靠性来说，传统的HA架构，冗余设计都可以满足高可靠性要求，但是并不代表系统具备了高可靠性能和可扩展性能力。反过来说，当系统具备了高扩展性的时候，一般我们在设计扩展性的时候都会考虑到同时兼顾冗余和高可靠，比如我们常说的集群技术。
对于高性能和高扩展性两点来说，高扩展性是高性能的必要条件，但是并不是充分条件。一个业务系统的高性能不是简单的具备扩展能力就可以，而是需要业务系统本身软件架构设计，代码编写各方面都满足高性能设计要求。
对于高可靠和高性能，两者反而表现出来一种相互制约的关系，即在高性能支撑的状态下，往往是对系统的高可靠性形成严峻挑战，也正是这个原因我们会看到类似限流熔断，SLA服务降级等各种措施来控制异常状态下的大并发访问和调用。
前面已经看到，如果仅仅是高可靠性保障， 实际上是比较简单的事情。整个IT基础架构的复杂性实际上是为了高性能和可扩展，引入了集群和分布式架构导致。
对于集群和分布式实际两个概念经常在混淆使用。
在这里强调下分布式实际更多会谈数据本身的分布式存储问题，这个分布式存储是和前面集中化共享存储最大的一个差异点。即数据需要存储在多个分布式节点，可以是每个节点都存储全量(读写分离集群），也可以是每个节点都只存储部分数据，并采用多副本机制保障数据的高可靠性。
对于集群更多会在大量请求过来进行请求分发的时候使用，即集群节点本身也是分布式的，但是针对的是多个请求的均衡，一般不涉及状态问题，同时也不会再对单个完整请求进行拆分处理。
对于负载均衡来说实际不能算一个分布式集群，仅仅是做请求的路由分发工作。当谈到分布式集群的时候一般就会谈到两个点。
其一是状态和配置信息在集群节点的实时同步，其二就是集群节点的心跳检查，当节点出现问题的时候要实时从集群列表中去除掉直到恢复。
当前构建分布式集群比较常用的如Zookeeper，Etcd等，Dubbo分布式集群采用了Zookeeper，而对于Kurbernetes集群则采用Etcd来构建分布式集群管控。但是不论哪种开源实现，类似分布式锁，数据一致性保证，软负载均衡，心跳检查等都是最核心的基础能力.
一个高可用的Redis集群一般会涉及到6个节点，即三个哨兵节点，三个主从节点。Redis 官方的高可用解决方案。
简单的主从架构下虽然可以实现高可用，但是无法实现在监测到主节点出现问题后自动切换到从节点，也正是这个原因引入了sentinel节点。也就是说sentinel节点做的是类似KeepAlive心跳检查的事情。
sentinel节点自身也需要高可用，因此这里至少就需要两个节点来确保sentinel节点本身的高可用性。那么为何要引入三节点？
可以看到当前主流的分布式架构集群中，管理节点往往都引入3节点模式。
一种是仅仅为了高可靠性，一种是要进行实际的大流量负载分发。第一种情况往往存在通过心跳检查来进行主从切换的问题；而第二种情况往往还需要搭配软负载均衡能力，即管理端对于注册进入的节点，一方面可以进行负载均衡，一方面又可以通过心跳检查动态增删节点。类似k8s的分布式集群，自然是需要具备以上两个方面的能力。
如果你还是采用传统的负载均衡方式来实现集群，如果集群节点存在类似配置文件等有状态信息的下发你无法很好地完成，其次就是集群节点持续故障的时候很难做到的自动化的管理能力，比如出现问题后的自动卸载，恢复后的自动挂接等。
即使你使用硬件负载均衡来做大并发请求的路由分发，你仍然需要一个分布式集群的管理组件来实现集群节点的动态管理。比如我们在采用Weblogic的时候，对于整个集群仍然采用Weblogic Cluster来进行管理，包括节点检测，服务的部署等。但是对于所有节点又统一配置到硬件负载均衡设备上来提升负载均衡本身的性能。
