如何实现分布式系统的高可用性
提高系统可用性最简单的方法就是“加资源”，4C16G 变 8C32G，但是单体机器的资源毕竟有限，而分布式架构的实质，就是让多台机器，甚至是海量机器，合作完成一件事情，提高分布式系统的高可用性，可以从以下几个方面入手。
在分布式架构中单点意味着风险，一定要尽可能地避免单点故障。
01. 利用负载均衡，进行集群化部署
负载均衡可以将请求平均地分配给每一台服务器，能够利用多台机器的资源，更重要的是，当一台机器发生故障时，不会影响整个系统的使用；这里要注意要有一定的冗余，否则可能会导致一台机器发生故障，剩下的机器无法抗住压力导致整个系统的崩溃。
02. 横向扩容，弹性扩容缩容
上面也说到，集群环境下一台服务器的异常可能会导致整个系统的崩溃，如果能做到弹性扩容锁容的话，可以大大提高系统的高可用性；当流量增大的时候，增加几台服务器，当流量降下去，减少几台服务器，这一切都是自动完成的。
03. 灰度发布，快速回滚
尽管有测试人员进行测试，但是依然很难覆盖所有的使用场景，为了避免出现生产环境大范围的故障或BUG，所以我们一般会采用灰度发布，也就是让一部分用户可以用到这个新功能，验证无误后再扩大应用范围，直到所有的应用都更新完成，如果在验证的过程中发现问题，那么就快速回滚。
04. 垂直切分
横向伸缩，是将相同的应用部署多套，或者相同的数据存储多份，而垂直切分，是将一个大系统切分成多个小系统、微服务，数据分库分表，以前是一挂全部都挂，现在出现故障，可能只是部分业务功能不可用。
05. 对突发流量的容错能力
如果系统的用户量固定，并发量可估且平稳，那么一切都可控，但是应用如果是面向互联网用户的，那么对于未知的徒增流量就要有应对策略，常用的做法有限流、熔断、降级；限流只让部分流量进入系统，拒绝掉多余的流量保护系统；熔断就是保险丝，在发生短路的时候自动跳闸，保护系统；降级是当流量徒增，可以限制不重要的系统或服务的访问量，保护主要业务。
06. 系统监控和预警
分布式系统发生故障不可怕，错误定位困难和恢复时间长才可怕，所以分布式系统需要有完善的监控系统，在系统可能发生故障的时候，及时预警，在真正发生故障后，准确定位故障，方便运维人员修复。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
高可用性确实是分布式系统一项重要的指标，跟数据一致性，分区容错性组成了分布式系统的CAP原则，本文只针对高可用性分析如下：
高可用性：High Availability，保证分布式系统在较长的时间内能正常响应，持续可用，业界常用几个9的说法来说明高可用性，比如说5个9，就是99.999%，全年只能停机几十分钟而已！
毫无疑问，单点的系统是无论如何也不可能实现高可用的，因为受到单点故障，服务发布，网络延迟等原因，客户端总会接收不到响应，即服务不可用！
比如数据库常用的集群手段有：
1，主从复制，读写分离：不能做到高可用，如果主机挂了，整个系统的写功能就不能用了！
2，分库分表：不能做到高可用，分库分表是把所有的数据分布到了很多的分库中，其中一个分库挂了，这部分数据就没了！
3，双主互备：可以做到高可用，双主机数据一致，能动态切换主库，其中一台坏了，另一台可提供使用！
双主互备得到的集群虽然实现了高可用，由于双机数据一致，限制了整个集群的容量！
分布式服务的高可用更加的复杂，因为分布式系统对外是一个整体，换句话说分布式的高可用需要保证分布式系统中包括应用系统，数据库，缓存系统，消息组件等所有服务的高可用性！
高可用性的解决方法一般来说比较单一，包括数据冗余，故障熔断，服务转移！
数据冗余保证在任何时候最新的数据都不丢失，多份数据冗余也为后期的数据还原提供基础！
故障熔断，服务转移保证单个服务不可用时，使用熔断防止服务不可用影响别的服务，并使用最新的健康服务以替换！
针对应用系统的单点，一定要压测出最大的容纳能力，同时可以使用负载均衡的方式搭建集群，服务还应该设计为幂等的，防止数据一致性问题！
高可用性解决方案貌似除了堆机器，没有更好的办法，不知道大家有什么手段，写出来让大家学习学习！
高可用性的前提是：保证服务系统能够持续工作，实现高可用性一般有两种手段： 一种是通过第三方软件／组件保证系统的可用性；另一种是软件／组件自身己具备高可用的技术实现。
标签： #单机游戏balance下载
