架构设计（高可用）

---

架构设计（高可用）

                

                     

                               

cap 原理

        

cap原理：分布式系统的三个特性(一致性、可用性、分区容错性)不能同时满足

                    

一致性(consistency)：分布式系统中数据在多个节点冗余存储，从任意节点读取数据，总能读取最新的数据
可用性(avaliable)：分布式系统在任何时刻都能正常响应
分区容错性(partition)：发生网络分区(如网络故障、丢包等)时，系统仍可以正常工作                     

             

分布式系统中，网络分区不可避免，分区容错性需要满足，要在一致性、可用性之间做出选择

ca：同时满足一致性、可用性，单节点部署时不存在网络分区，如关系型数据库
cp：同时满足一致性、分区容错性，故障期间不可用，如redis集群、mongoDB集群
ap：满足可用性、分区容错性，从不同节点可能会读到不一致的数据，如dynamoDB集群

              

base理论：牺牲部分一致性，保证系统可用，但最终会保持一致

基本可用：系统出现故障时，允许牺牲部分可用性（如响应时间延长、服务降级等）
软状态：在可容忍的一段时间内，允许系统的不同节点数据不一致，系统正常对外服务
最终一致性：经过一段时间数据同步完成后，不同节点之间的数据保持一致

               

                 

                               

可用性标准

     

可用性计算公式

# 故障时间计算
可用性 = 平均正常工作时间/(平均正常工作时间时间+平均故障时间)

# 请求数计算：故障时间难于统计，一般用请求数计算可用性
可用性 = 正常请求数/(增长请求数+异常请求数)

             

可用性分级：关键业务、核心业务的可用性一般要达到极高可用性（99.999%及以上）

                    

            

                  

                               

高可用实现

   

冗余部署

# 服务冗余
服务器数量按照满足最小性能要求数量的1.5倍部署，
如果按照最小数量部署，剩余的服务器可能会超负荷运行，容易故障
冗余部署后，可将流量切换到备份的服务器，不使服务器超负荷运行

# 数据冗余备份
数据库如mysql使用双主部署，避免出现单点故障，导致服务不可用

         

限流降级

# 服务降级
远程服务调用出现故障，需要进行服务降级，避免一个服务故障导致其他服务不可用

# 服务限流
需要对服务的最大流量限制，避免超负荷运行

# 线程隔离
与主业务无关的逻辑(如日志等)单独处理，避免出错后对主业务造成影响