前段时间读了《大型技术架构》一书，现把书中的要点记录下来。
- 网站架构模式：分层（单一职责，MVC分层，控制层-服务层-数据层），分割（不同功能与服务分割），分布式（服务调用需要通过网络，带来了网络问题；分布式数据一致性问题），集群，缓存，异步，冗余（冷备份，热备份），自动化，安全。
- 常用的分布式方案：分布式应用与服务；分布式静态资源（动静分离JS,CSS,图片等，减轻应用服务器的负载压力）；分布式数据与存储（读写分离；分库分表；缓存优化；传统数据库分布式部署；使用NoSQL）；分布式计算。
- 缓存：CDN（内容分发，部署在离用户最近的网络服务商），反向代理（部署在网站的数据中心），本地缓存（缓存在本机内存中，但是不适合大量的数据），分布式缓存（分布式缓存集群）。热点数据缓存，注意缓存的时间，避免出现数据脏读，影响数据一致性。
- 异步：单一服务器可以通过多线程共享内存队列的方式实现；分布式系统中可以通过分布式消息队列实现。典型的模型就是生产者-消费者模式，两者之间不存在直接调用，只是保持数据结构不变。作用：提高网站可用性；加快网站响应速度；消除并发访问高峰。
- 性能问题，网站响应速度慢，优化措施：通过浏览器缓存，页面压缩等；使用CDN，动静分离，部署反向代理服务器，缓存热点文件；使用本地缓存与分布式缓存；使用消息队列，异步处理请求；代码层面使用多线程，内存管理等进行优化；数据库方面使用索引，缓存，优化SQL，读写分离等。
- 可用性：网站高可用的主要手段就是冗余，通过负载均衡服务器统一一个集群对外提供服务，有效的负载均衡策略；数据服务器进行实时备份，宕机时进行数据转移并恢复。
- 网站可扩展性的主要手段是事件驱动架构和分布式服务。事件驱动通常将请求构造成消息发布到消息队列之中，消息处理者通过消息队列中获取消息进行处理。分布式服务是将业务与基础服务分离开来。
- 性能优化策略：首先要进行性能数据的搜集，然后针对性能报告进行性能分析，检查请求处理的各个环节的日志信息，分析是哪个环节响应时间较长，检查监控数据，分析影响性能的是硬件设施（内存，磁盘，CPU，网络）还是代码问题还是架构设计不合理，亦或是系统资源不足等。找到问题的原因后再针对不同的问题进行相应的优化。
- 浏览器访问优化：减少http请求（合并CSS,JS文件，图片等），http协议是无状态的应用层协议，意味着每次http请求都需要建立通信链路，进行数据传输。使用浏览器缓存（设置http的头字段）。启用压缩（对html，css，js文件进行GZIP压缩）
- 网站优化第一定律：优先考虑使用缓存优化性能。
- 缓存的基本原理：缓存指的是将数据存储在相对较高访问速度的存储介质中，减少数据访问的时间。缓存的本质是一个内存Hash表，数据缓存以一对Key,Value的形式存储在内存Hash表中。Hash表数据读写的时间复杂度为O（1）。缓存中主要用来存放读写比较高，很少变化的数据，应用程序先读写缓存，缓存中没有或者数据失效再去数据库中查询，并将查询到的数据写入缓存。缓存要考虑数据一致性问题与脏读。可以设置策略是数据更新后马上更新缓存。缓存雪崩问题通过分布式缓存解决。
- 分布式缓存：缓存部署在多个服务器组成的集群上。两种缓存架构方式：JBoss Cache为代表的需要更新同步的分布式缓存；以Memcached为代表的不互相通信的分布式缓存。
- JBoss Cache的分布式缓存在集群中的所有服务器上都保存相同的缓存数据，当某台服务器缓存更新时，会通知集群中所有的机器进行缓存更新或清除缓存。一般会将JBoss Cache与应用程序部署在同一服务器上。
- Memcached采用的是集中式的缓存管理，缓存与应用分离部署，缓存系统部署在专门的集群上，应用程序通过一致性hash等路由算法选择缓存服务器远程访问缓存数据，缓存服务器之间不通信。这样缓存集群可以很简单的实现扩容，具备良好的可伸缩性。采用的是TCP协议（UDP也支持）通信，序列化协议是通过基于文本的自定义协议。服务端和客户端，采用memcached协议交互。
- ①负载均衡+session复制，将session同步至每个应用服务器，保证服务的状态。②session绑定，利用负载均衡的源地址hash算法实现将来源于同一IP的请求始终分发到同一台应用服务器上。③利用浏览器的cookie记录下session以及sessionID，将session以及sessionID发送给负载均衡器，负载均衡服务器根据sessionID将请求转发至相应的应用服务器。④设置专门的session服务器统一管理session，应用程序每次读写session都通过session服务器。
- 负载均衡算法：轮询：请求依次分发到每台应用服务器上；加权轮询：根据应用服务器的性能进行加权重新分配；随机；最少连接：记录每个应用服务器正在处理的请求连接数，将新的请求分配到连接数最少的服务器上；源地址散列。
- 网络IO的实现：BIO;NIO;AIO。
- BIO采用阻塞的方式实现，也就是说一个Socket套接字需要使用一个线程来处理。支持并发的连接，需要更多的线程来完成这个工作。
- NIO基于事件驱动思想，采用的是Reactor模式。可以在一个线程中处理多个套接字Socket相关的工作。Reactor会管理所有的handler，并把出现的事件交给相应的handler去处理。
- AIO就是异步IO。采用Proactor模式，AIO与NIO的区别：AIO在读写操作时，只需要调用相应的read/write方法，并且需要传入CompletionHandler；在完成动作后会调用CompletionHandler。而NIO的通知是发生在动作之前，是在可写可读的时候，selector发现这些事件后调用handler处理。
- 控制器的变化：使用硬件负载均衡——》使用软件负载均衡（LVS）（透明代理，请求发送发和处理方都不需要知道对方，但是存在不足：增加网络的开销，比如流量和延时；代理出现问题则所有请求都会受到影响）——》采用名称服务直连方式请求调用（名称服务器是通过跟请求处理的机器交互来获取这些机器的地址）——》采用规则服务器控制路由的请求直连调用（规则服务器本身并不和请求处理的机器进行交互，只负责把规则提供给请求发起的机器）——》master+worker的方式（存在一个master来管理worker）
- 运算器的变化：DNS调度——》DNS+负载均衡调度（DNS返回的永远都是负载均衡设备的地址）
- 存储器的变化：单机的Key-Value服务——》使用代理服务器的多机Key-Value服务——》使用名称服务的Key-Value服务——》使用规则服务器的Key-Value服务——》通过Master的Key-Value服务
- 分布式系统的难点：①缺乏全局时钟；②面对故障独立性；③处理单点故障；④事务的挑战
- 数据库读写分离：两个问题：数据复制问题（使用数据库本身提供的数据复制机制，但还是存在复制延时的数据不一致性问题）；应用对于数据源的选择问题（写操作要走主库，事务中的读操作也要走主库）
- 搜索引擎技术解决大型网站站内搜索时的某些场景下的读的问题，提供了更好的查询效率，站内搜索结构和使用读库非常相似，只是多了自己建立数据索引的步骤。
- 缓存：数据缓存（全数据缓存（数据库的数据发生变化后会把数据写入到缓存中，保证数据不会读取失效）；热数据缓存（应用访问缓存，如果数据不存在则去数据库里读取并把数据加入到缓存中））；页面缓存（ESI规范）
- 缓存的一个关键指标缓存命中率，如果缓存命中率比较低的话就意味着有不少请求要回到数据库中查询。还要考虑缓存服务器的扩容与缩容（一致性hash）以及缓存数据更新（定时失效，数据变更时失效，数据变更时更新）。
- 数据库拆分：专库专用，数据垂直拆分（不同业务数据拆分到不同的数据库中）；数据的水平拆分（把同一个表的数据拆分到不同的数据库中）。
- 服务化：把应用分为三层，处于最上端的是Web系统，用于完成不同的业务功能；处于中间的是一些服务中心，不同的服务中心提供不同的业务服务，处于下层的则是业务的数据库同时引入了远程调用，共享代码不再散落在各个应用中而是放到了各个服务中心上。数据交互工作由业务服务中心完成。
- 远程过程调用和对象访问中间件（主要解决分布式环境下应用互相访问的问题）；消息中间件（解决应用之间的消息传递，解耦以及异步问题）；数据访问中间件（主要解决应用访问数据库的共性问题）
- 静态代理与动态代理？静态代理为每一个被代理的对象构造对应的代理类。动态代理是动态地生成具体委托类的代理实现对象，通过Proxy.newProxyInstance来创建代理方法可以为不同的委托类都创建代理类。方法调用使用invoke。
- 服务化使得原来的一些本地调用变为了远程调用。远程调用：获取可用服务地址列表->确定要调用服务的目标机器->建立连接->请求序列化->发送请求->接受结果->解析结果
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于