05 | 复杂度来源：高可用

古人有言：先解决有无，再解决优化。所以可用更难，性能次之，找对象同理。

这么多回复里，没有人提到高可用和高性能的量化指标，没有这个指标前提下，无法断定哪个更复杂吧。打个比方，高可用两条99就行了，你觉得会复杂，会难么？高性能要求你在并发百万，千万级调用十几个服务前提下，仍能保持10多毫秒，你觉得简单？复杂与否还是要指标。另外，很多人都关注应用节点和硬件节点高可用，却忽略了业务高可用这个视角，系统全挂了，你人工接入业务，在后台帮用户开通，办理，对业务来说也是高可用吧。以上个人看法

高可用的解决方法不是解决，而是减少或者规避，而规避某个问题的时候，一般都会引发另一个问题，只是这个问题比之前的小，高可用的设计过程其实也是一个取舍的过程。这也就是为什么系统可用性永远只是说几个九，永远缺少那个一。 而高性能，这个基本上就是定义计算能力，可以通过架构的优化，算法的改进，硬件的升级都可以得到很好的解决，从而达到我们心里对性能的预期…

老师，银行账务类强一致性业务，适用最终一致性方案吗？我们通常要求既要实时看到账务操作结果，又要提供高性能，最终只能用依赖于数据库实现一致性，但性能压力很大

核心思想：网站高可用的主要技术手段是服务与数据的冗余备份与失效转移。同一服务组件部署在多台服务器上；数据存储在多台服务器上互相备份。通过上述技术手段，当任何一台服务器宕机或出现各种不可预期的问题时，就将相应的服务切换到其他可用的服务器上，不影响系统的整体可用性，也不会导致数据丢失。 从架构角度看可用性：当前网站系统多采用经典的分层模型，从上到下为：应用层、服务层与数据层。应用层主要实现业务逻辑处理；服务层提供可复用的服务；数据层负责数据读写；在部署架构上常采用应用和数据分离部署，应用会部署到不同服务器上，这些服务器被称为应用层的服务器；这些可复用的服务也会各自部署在不同服务器上，称为服务层的服务器；而各类数据库系统、文件柜等数据则部署在数据层的服务器。 硬件故障方面引起不可用的技术解决措施：(1)应用服务器。可通过负载均衡设备将多个应用服务器构建为集群对外提供服务（前提是这些服务需要设计为无状态，即应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行业务逻辑的操作响应），当均衡设备通过心跳检测手段检测到应用服务器不可用时，则将其从集群中移除，并将请求切换到其他可用的应用服务上。(2)服务层服务器。这些服务器被应用层通过分布式服务框架（如Dubbo）访问，分布式服务框架可在应用层客户端程序中实现软件负载均衡，并通过服务注册中心提供服务的服务器进行心跳检测，当发现有服务器不可用时，立即通知客户端程序修改服务列表，同时移除响应的服务器。(3)数据服务器。需要在数据写入时进行数据同步复制，将数据写入多台服务器上，实现数据冗余备份；当数据服务器宕机时，应用程序将访问切换到有备份数据的服务器上。

就我一个人注意到ZK的选举算法不是Paxos吗？虽然不是本文重点😂

冷备、温备、热备的具体区别是

高性能虽然复杂，但是只要通过合理的集群方案还是可以解决业务的性能需求，但是高可用也只能做到相对高可用，绝对高可用是不存在的，总会有诸多突发外界因素进行干扰，高性能的实现是受人为控制的，只要是在人的控制范围内，那问题都不是问题，但是要做到高可用，很多事情都不是人能控制的，比如天灾人祸

相对而言还是高可用更难些，按照作者说的高性能其实就是容量，在负载均衡系统高可用的情况下加机器就可以了，而想做到各个环节的高可用不是靠加机器就能搞定的，通常需要复杂的算法、引入更多的中间件、牺牲一定的性能才能实现，这其中还要进行各种权衡取舍裁剪才可以

有些人把高可用与高可靠混淆了，高可用是不要中断服务，高可靠是数据不丢失。