架构 高可用

负载均衡：心跳检测，自动转移

 

解决负载均衡后的session问题：

ip哈希，或根据cookie来转发。不满足高可用。

session服务器，利用分布式缓存、数据库等。引入了网络开销

session replication，即在服务器间同步session。同步开销、存储开销都很大

把session记录到cookie里。缺点：大小有限制，影响性能、不安全。

 

 

 

服务高可用：

应用程序设置调用服务的超时时间

异步调用，防止某个服务失败导致整个流程都失败

服务降级，高峰期拒绝或关闭某些不重要的服务，或随机拒绝部分请求

幂等性，服务被重复调用，产生的结果和被调用一次相同

 

 

 

关于缓存服务器，有两种观点，一种认为应该保证高可用，

另一种认为单机宕机，影响不大，应将整个网站的缓存都放在同一个大集群里，

而不是各个应用使用自己的小集群。

 

 

CAP原理、强一致/用户一致/最终一致

 

 

备份：

冷备：定期复制到存储介质上。优点是简单、廉价，

缺点是不满足数据最终一致，也不保证数据可用性

异步热备：应用程序收到数据服务系统的写成功响应时，只写成功了一份，

会异步地写入其他副本，但可能失败。

存储服务器分为主从，应用程序向主写入后立即返回

同步热备：多份数据副本的写入操作都成功，才返回成功响应。

应用程序收到失败响应时，可能部分或全部副本都写成功了。

实现的时候，应用程序客户端并发向多个存储服务器写入，

所有存储服务器都返回成功后，再通知应用程序写成功了。

不分主从

 

 

失效转移：宕机后，请求被路由给其他服务器

失效确认：1，心跳检测。2，应用程序访问失败报告

访问转移：1，对于对等存储服务器，应用程序根据配置，直接切换到对等服务器上。

2，非对等存储服务器，要重新计算路由

数据恢复：宕机后，数据存储的副本减少，要增加数据的副本。

 

 

 

 

发布：每次关闭负载均衡到部分服务器的路由

灰度发布：每天发布一部分服务器，观察运行状况，如果有问题，只需要回滚已发布的部分服务器。

也可在部分服务器上发布新版本，收集用户体验报告，比较用户对两个版本的满意度，

以确定最终的发布版本。这种手段也被称作AB测试。