系列文章是博主对沈剑的《架构师训练营》分享内容的个人笔记总结，原内容公众号“成为架构师”。
高可用的常用手段
可用，指的是系统对外能够提供服务，系统的可用时间 / 系统的总运行时间，所得的比值就是表征系统的可用的度量指标，用几个九来表示，99.99%就是四个九。
互联网架构实践中，实现高可用通常使用以下两种方式：
- 集群化（冗余）
- 故障自动转移
微服务的架构有很多层，每一层之间都要实现高可用
也就有了：端到反向代理、反向代理到站点、站点应用到微服务、微服务到缓存、微服务到读库、微服务到写库的多个层面高可用
端到反向代理的
自上而下，先来看端到反向代理
在前面章节反向代理的内容中已经提及，反向代理的高可用使用虚VIP + Keepalived的方式来实现的，keepalived机制会检测主nginx的存活状态，当其不可用时会用从nginx顶上，虚IP使其二者对外是一个整体，流量迁移对调用方是透明的。
但是当主nginx挂掉的时候，当时连接的流量还是会有影响，不过用户只要进行刷新操作就可以恢复了。
之前有一个预留问题，就是这种方案nginx的利用率只用50%，解决方案就是双主互备，两个nginx使用两个虚IP，nginx之间互为主从，使用DNS轮询来进行访问，如果其中一个挂了，两个虚IP会指向同一个nginx。
反向代理到站点
反向代理到站点的高可用是反向代理层，也就是nginx来实现的，它会探测站点的存活状态，不会将流量转发到不可用的站点。
站点应用到微服务
站点到微服务的高可用是借助站点端的连接池 来实现的，连接池也负责对服务进行探活等操作，如果其中有微服务节点挂了，那么连接池就会将流量迁移到其它可用的微服务上去。
整个过程是由连接池完成的，对客户端，也就是调用方是透明的。
服务到缓存
memcache缓存
memchache本身不支持集群，它的高可用是用缓存客户端的双读写来实现的。
redis缓存
redis天然支持集群，也就是经常说的哨兵机制，redis-sentinel负责监控主节点和从节点的状态，主节点自动地与从节点进行数据同步。
哨兵集群机制的自动故障转移是当主节点挂掉的时候，redis-sentinel会通知缓存客户端访问从节点，通知这一机制也是**“哨兵”**名字的由来了。
缓存分片
服务到缓存的高可用有其特殊性，因为缓存是为了加速数据的访问而存在的，它的高可用限度是不造成**缓存“雪崩”**即可。
缓存分片是将缓存数据分别存储在不同的缓存节点，每个节点只保存部分数据，通过一个cache proxy根据key来进行存取的选择。
如果其中一个分片挂了，那么流量会暂时打到数据库上，只要分片设计的粒度还是小的，那么这部分流量打到数据库，对于数据库也是完全可以接受的，对于整体架构也是可以接受的。
服务到读库
如果数据库做了读写分离，那么数据库的架构应该是主库负责写入，从库或者提供读服务。
读库的高可用是以靠连接池来实现的，也是对客户端透明
服务到写库
通常我们会说读写分离是一主多从，但是一主就无法实现主库的高可用。
学习nginx的高可用方式，数据库写库的高可用也是使用vip + keepalived的机智来实现的，同样的，它们也可以互备。
可以看到，在互联网架构中，高可用的实现方案在方法论上是互通的，其本质就是冗余 + 故障的自动转移。
上一篇回顾：【成为架构师3-2】服务化：微服务的粒度，究竟要细到什么程度
下一篇更精彩：持续更新中…