本文主要是介绍大型网站技术架构——读后摘要5，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
网站架构分层：
应用层，服务层，数据层。
各层怎么实现高可用：
应用层：主要负责具体的业务逻辑处理，多以集群的方式解决高可用的问题。
服务层：负责提供可以复用的服务，也是以集群的方式解决高可用问题。（原因大多应用层和服务层都是部署在一起）
数据层：负责数据的存储和访问。为了保障宕机导致数据丢失，多台服务器之间进行数据同步复制，将数据写到多台服务器上，实现数据冗余备份。
应用服务器的session管理：
单机情况（单个服务器）下，session可以交给服务器上的web容器管理。如果是集群session该如何管理呢？
1.session复制：
在服务器之间同步session。（这种方式适用于用户量小的情况，如果上亿用户，使用session复制实现同步将耗费大量的服务器资源）
2.session绑定：（很少用）
可以通过负载均衡原地址的hash算法实现将来源同一台ip的请求分发到同一台服务器上。（负载均衡的回话黏滞机制）
3.利用cookie记录session
4.session服务器：利用独立部署的session服务器统一管理session，应用服务器每次读写session时，都要访问session服务器。利用session服务器集成单点登录、用户服务等功能。
高可用的服务：
1.分级管理：核心应用和服务优先使用更好的硬件。
2.超时设置：如果服务器宕机或其他原因导致请求长时间得不到响应，设置请求超时，可以将请求转移到相同应用的服务器上，同时还节省应用程序的资源（长时间请求占用的资源）。
3.异步调用：避免一个服务失败导致整个服务失败；削峰等等
4.服务降级：当出现大并发量的情况时，可以将一些不重要的服务降级、甚至关闭。比如双十一（可以降低或者关闭评价和确认收货的功能给订单节省服务器资源）
5.幂等性设计：有的请求请求成功由于网络或者其他原因导致响应没有收到，服务层会再一次发送请求，如果是转账业务那么这样的机制是不成立的，所以牵扯像转账这类业务的时候应该附加特别的校验比如短信验证码，没请求一次发一个。
高可用的数据：
数据的安全主要是备份，高可用则用到失效转移，当这台机器的数据出现问题会转移到其他副本上。
数据的高可用：
高可用的数据具有数据持久性，数据可访问性，数据一致性
1.CAP原理：一个提供数据服务的存储系统无法满足数据一致性，数据可用性、分区耐受性这三个条件。
数据的备份：
冷备份：定期的备份数据（不好，因为备份时到宕机这段时间的数据将永久丢失）
热备份：异步热备方式和同步热备方式。
异步热备份：有主从存储服务器，当数据请求来了后，只访问主存储服务器，数据存入以及响应数据存储成功，然后异步将数据存储到从服务器中。
同步热备份：没有主从数据库之分，读写请求（并发）访问多个存储服务器，响应时间是最慢的一台服务器的响应时间。
失效转移：
1.失效确认：
判断服务器宕机的手段有两种：1.心跳监测2.应用程序访问失败报告。
2.访问转移
3.数据恢复
将数据复制到宕机的服务器上，保证集群服务器个数为系统的设定值。
网站运行监控：
对网站进行实时的监控，出了问题就不会像无头苍蝇到处乱转，可以通过监控高效快速使系统正常运转。
1.监控数据的采集
- 用户行为日志收集：通过服务器端日志收集和客户端浏览日志收集
- 服务器性能监控：如系统Load、内存占用、磁盘IO、网络IO等做出网络预警往返于未然。
- 运行数据报告。
2.监控管理
- 系统报警：服务器的一些性能都设置一些稳定的指标，当不在这段范围就报警，有专业人员处理。
- 失效转移：访问失败的时候失效转移；系统发生故障时监控系统也可以主动通知应用失效转移。
- 自动优雅降级：当系统部分功能出现并发访问高峰时，不用的功能可以自动降级甚至关闭。
这篇关于大型网站技术架构——读后摘要5的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
