目录
1 大型网站架构演化
2 大型网站架构模式
3 大型网站核心架构要素
4 瞬时响应：网站的高性能架构
5 万无一失：网站的高可用架构
6 永无止境：网站的伸缩性架构
7 随需应变：网站的可扩展架构
8 固若金汤：网站的安全架构
参考资料
· 《大型网站技术架构-核心原理与案例分析》

1 大型网站架构演化

（1）初始阶段

只需一台服务器就绰绰有余。通常服务器操作系统使用Linux、应用程序使用PHP开发、然后部署再Apache上，数据库使用MySQL。典型的LAMP开发。

（2）应用服务和数据服务分离

• 背景：用户访问的增长，访问和存储空间导致很多问题，将应用和数据分离使得整个网站使用三台服务器：应用服务器、文件服务器和数据库服务器。
• 不同特性的服务器承担不同的服务角色。
  

（3）使用缓存改善网站性能

• 背景：二八定律：80%的业务访问集中再20%的数据上。
• 缓存分为：本地缓存和远程分布式缓存。前者受应用服务器内存和性能的限制，后者有更好的性能。
• 使用缓存将热点数据缓存

（4）使用应用服务器集群改善网站的并发处理能力

• 背景： 使用集群是网站解决高并发、海量数据问题的常用手段。
• 通过负载均衡调度器将用户请求分发到应用服务器集群中的任何一台服务器上，使得应用服务器的负载压力不在是瓶颈。

（5）数据库读写分离

• 背景：仍然有一部分读操作（未命中缓存）和全部写操作到达数据库，随着用户的增长，数据库业务负载压力过高而成为瓶颈。
• 主从热备、读写分离，从而改善数据库负载压力。

（6）使用反向代理和CDN加速网站响应

• 背景：随着用户规模的扩大，不同地区访问网站速度差别极大。为了提供更好的用户体验，留住用户，需要加速网站访问速度。
• 主要手段有两个，基本的原理都是缓存
  -CDN：部署在网络提供商的机房，使得用户在请求网站服务时，可以从距离子句最近的网络提供商机房获取数据。
  -反向代理：部署在网站的中心机房，用户请求首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就直接返回给用户。
• 优点：在加快用户访问速度的同时，也减轻后端服务器的负载压力。

（7）使用分布式文件系统和分布式数据库系统

• 背景： 数据库和文件系统不能满足持续增长的业务需求
• 分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常庞大的时候才使用。不到不得已时，网站更常用的数据库拆分手段是业务分库，将不同业务的数据库部署再不同的物理服务器上。

（8）使用NoSQL和搜素引擎

• 背景： 随着网站业务越来越复杂，对数据存储和检索的需求越来越复杂，网站需要采用一些非关系数据库技术如NOSQL和非数据库查询技术如搜索引擎。
  

（9）业务拆分

• 背景：业务场景日益复杂，需要将业务分成不同的产品线，不同产品线将网站拆分为不同的应用，每个应用单独部署和维护。
• 应用可以通过超链接、消息队列或者数据存储系统建立为完整的系统

（10）分布式服务

• 背景：业务拆分越来越小，应用系统的整体复杂度呈指数级增加，部署维护越来越困难。
• 将共同的业务提取出来，独立部署。应用系统通过分布式服务调用共同业务服务完成具体业务操作。

2 大型网站架构模式

2.1 什么是模式？

每一个模式描述了一个在外面周围不断重复发生的问题及该问题解决方案的核心，这样，你就能一次又一次地使用该方案而不必做重复工作。

2.2 分层

• 是企业应用系统中最常见的一种架构模式，将系统在横向维度上切分成几个部分，每个部分负责一部分相对单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。
• 常见的，MVC模式的分层
• 一些注意点：必须合理规划层次边界和接口，在开发过程中，严格遵循分层架构的约束，禁止跨层次的调用（应用层直接调用数据层）及逆向调用（数据层调用服务层，或者服务层调用应用层）。
• 意义：分层结构对网站支持高并发向分布式方向发展至关重要。

2.3 分割

• 在纵向方面对软件进行切分。

在应用层，将不同业务分割，如论坛、广告分割成不同的应用；
在每个应用可以进行更小粒度的分割，如首页、商品详情等模块。

2.4 分布式

• 将上述分层和分割后的不同模块部署在不同的服务器上，通过远程调用协同工作。分布式意味着可以使用更多的计算机完成同样的功能，计算机越多，CPU、内存、存储资源也就越多，能够处理的并发访问和数据量就越大，进而能够为更多用户提供服务。

• 带来的问题：
  通过网络进行机器通信，性能有影响
  数据一致性问题
  机器宕机概率增大
  。。。

• 常见的分布式方案：
  分布式应用和服务：服务模块分布式部署
  分布式静态资源：静态资源分布式部署，独立域名（动静分离）
  分布式数据和存储：海量数据的分布式存储
  分布式计算：目前网站普遍使用Hadoop及其MapReduce分布式计算框架进行此类批处理计算。
  分布式配置
  分布式锁
  分布式文件系统

2.5 集群

• 多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务
• 即使是访问量很小的分布式应用和服务，也至少要部署两台服务器构成一个小的集群，目的就是提高系统的可用性。

2.6 缓存

• 缓存就是将数据存放在距离计算最近的位置以加快处理速度
• 缓存是改善软件性能的第一手段，缓存无处不在
• 常见缓存方案：
  CDN：内容分发网络
  反向代理
  本地缓存：在应用服务器本地缓存着热点数据，在内存中，无需访问数据库
  分布式缓存：海量需要缓存的数据，单机不够，通过分布式缓存解决
• 使用缓存的前提条件：
  1. 数据访问热点不均衡，某些数据会被更频繁的访问，这些数据应该在缓存中
  2. 数据在某个时间段内有效，不会很快过期，否则缓存的数据就会因已经失效而产生脏读，影响结果的正确性。

2.7 异步

• 计算机软件发展的一个重要目标和驱动力是降低软件耦合性。
• 异步，即业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方式异步执行进行协作。
• 实现方式：
  单一服务器内：通过多线程共享内存队列的方式实现异步
  分布式系统中：分布式消息队列实现异步。
• 异步消息队列的特性：
  1. 典型的生产着消费者模式
  2. 提高系统的可用性：消费者宕机重启后继续处理消息队列中的数据
  3. 加快网站响应速度：前端不等待结果处理，直接返回给客户端
  4. 消除并发访问高峰

2.8 冗余

• 要想保证在服务器宕机的情况下网站依然可以继续服务，不丢失数据，就需要一定程度的服务器冗余运行，数据冗余备份，这样当某台服务器宕机时，可以将其上的服务和数据访问转移到其他机器上。
• 冷备份与热备份：数据库定期备份，存档保存，进行冷备份；为了保证在线业务高可用，需要进行主从分离，实时同步实现热备份。
• 全球范围内部署灾备数据中心。

2.9 自动化

• 在无人值守的情况下网站可以正常运行，一切都可以自动化是网站的理想状态。目前大型网站的自动化架构设计主要集中在发布运维方面。
• 发布网站过程中：发布过程自动化、自动化代码管理、自动化测试、自动化安全检测和自动化部署
• 网站运行过程中：自动化监控、自动化报警、自动化失效转移、自动化失效恢复、自动化降级、自动化分配资源。

2.10 安全

• 通过密码和手机校验码进行身份认证
• 登录、交易操作进行网络通信加密
• 防止机器人攻击网络，使用验证码进行识别
• 对XSS攻击和SQL注入进行编码转换
• 对垃圾信息、敏感信息过滤
• 交易过程的风险控制

3 大型网站核心架构要素

3.1 性能

3.1.1 衡量网站性能的指标

• 响应时间
• TPS
• 系统性能计数器
• .....

3.1.2 优化性能的手段

• 浏览器端，通过浏览器缓存、页面压缩、减少Cookie传输等改善
• CDN
• 服务端，使用本地缓存和分布式缓存
• 异步
• 集群
• 代码层面，使用多线程、改善内存管理等
• 数据库端，索引、缓存、SQL优化等
• NOSQL

3.2 可用性

• 用几个9来衡量，常见的是4个9的可用性，即99.99%
• 衡量一个系统架构设计是否满足可用的目标，就是假设系统中任何一台或者多台服务器宕机时，以及出现各种不可预期的问题时，系统整体是否依然可用。
• 网站高可用的主要手段：冗余

3.3 伸缩性

• 伸缩性是指：通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求。
• 分类：
  1. 应用服务器的伸缩性：服务器对等
  2. 缓存服务器的伸缩性：修改缓存裸路由算法
  3. 关系数据库的伸缩性：通过路由分区等手段将有多个数据库的服务器组成一个集群
  4. NOSQL产品的伸缩性：天生为海量数据而生，可以实现集群规模的线性伸缩

3.4 扩展性

• 扩展性是指：网站快速发展，功能不断扩展，如何设计网站的架构使其能够快速响应需求变化，是网站可扩展架构主要的目的
• 衡量网站架构扩展性好坏的主要标准就是：在网站增加新的业务产品时，是否可以实现对现有产品透明无影响。不需要任何改动或者很少改动既有业务功能就可以上线新产品。
• 主要手段：
  1. 事件驱动架构：利用消息队列实现
  2. 分布式服务：将业务和可复用服务分离开来，通过分布式服务框架调用。

3.5 安全性

• 衡量网站安全架构的标准就是：针对现存和潜在的各种攻击与窃密手段，是否有可靠的应对策略。

4 瞬时响应：网站的高性能架构

4.1 网站性能测试

4.1.1 性能测试指标

（1）响应时间

• 指应用执行一个操作需要的时间，包括从发出请求开始到收到最后响应数据所需要的时间。
• 响应时间测试方法：重复请求。比如一个请求操作重复执行一万次，测试一万次执行需要的总响应时间之和，然后除以一万，得到单次请求的响应时间。

（2）并发数

• 指系统能够同时处理请求的数目。
• 网站系统用户数 >= 网站在线用户数 >= 网站并发用户数
• 并发数测试方法：通过多线程模拟并发用户的办法来测试系统的并发处理能力。

（3）吞吐量

• 指单位时间内系统处理的请求数量，体现系统的整体处理能力。
• TPS（每秒事务数）、HPS（每秒HTTP请求数）和QPS（每秒查询数）。

（4）性能计数器

• 它是描述服务器或操作系统性能的一些数据指标。包括System Load、对象与线程数、内存使用、CPU使用、磁盘与网络I/O等指标。

4.1.2 性能测试方法

• 性能测试
• 负载测试
• 压力测试
• 稳定性测试

4.1.3 性能优化策略

（1）性能分析

• 检查请求处理的各个环节的日志，分析哪个环节响应时间不合理、超过预期；
• 然后检查监控数据，分析影响性能的主要因素是内存、磁盘、网络、还是CPU，是代码问题还是架构设计不合理，或者系统资源确实不足。

（2）性能优化

• Web前端性能优化
• 应用服务器性能优化
• 存储服务器性能优化

4.2 Web前端性能优化

4.2.1 浏览器访问优化

1. 减少HTTP请求
   合并CSS、合并JavaScript、合并图片。将浏览器一次访问需要的JavaScript、CSS合并成一个文件，这样浏览器就只需要一次请求
2. 使用浏览器缓存
   -设置浏览器缓存更新频率较低的静态资源，可以设置HTTP头中Cache-Control和Expires属性
   -使用浏览器缓存策略的网站在更新静态资源时，应采用逐量更新的方法，以免用户浏览器突然大量缓存失效，集中更新缓存，造成服务器负载骤增、网络堵塞的情况。
3. 启用压缩
   HTML、CSS、JavaScript文件启用GZip压缩，减少通信传输的数据量
4. CSS放在页面最上面、JavaScript放在页面最下面
   -浏览器会在下载完全部CSS之后才对整个页面进行渲染，因此最好的做法是将CSS放在页面最上面，让浏览器尽快下载CSS
   -浏览器在加载JavaScript后立即执行，有可能会阻塞整个页面，造成页面显示缓慢，因此JavaScript最好放在页面最下面
5. 减少Cookie传输

4.2.2 CND加速

CDN能够缓存的一般是静态资源，如图片、文件、CSS、Script脚本、静态网页等。

4.2.3 反向代理

来自互联网的访问请求，必须经过代理服务器，相当于在web服务器和可能的网络攻击之间建立了一个屏障。

也可以配置缓存功能加速Web请求

4.3 应用服务器性能优化

4.3.1 分布式缓存

1. 缓存原理
   缓存的本质是一个内存Hash表，网站应用中，数据缓存以一对Key、Value的形式存储在内存Hash表中。

2. 合理使用缓存
   频繁修改的数据，徒增系统负担。一般，数据的读写比在2:1以上，缓存才有意义
   没有热点的访问，如果系统的访问，不符合二八定律，则没有必要使用缓存
   数据不一致与脏读
   缓存可用性，使用集群改善。
   缓存预热，LRU算法执行uxuyao时间，可用在缓存系统启动时，就把热点数据加载好。
   缓存穿透

3. 分布式缓存架构
   -分布式缓存指部署再多个服务器组成的集群中，以集群方式提供缓存服务。应用程序通过一致性Hash等路由算法选择缓存服务器远程访问缓存数据。
   -架构方式有两种：JBoss Cache为代表的需要更新同步的分布式缓存；以Memcached为代表的不互相通信的分布式缓存。

4.3.2 异步操作

• 使用消息队列将调用异步化，可改善网站的扩展性，也可以改善网站系统的性能
• 在使用消息队列后，用户请求的数据发送给消息队列后立即返回，再由消息队列的消费者进程（通过情况下，该进程通常独立部署在专门的服务器集群上）从消息队列中获取数据，异步写入数据库。

4.3.3 使用集群

使用负载均衡技术为一个应用构建一个由多台服务器组成的服务器集群，将并发访问请求分发到多台服务器上处理，避免单一服务器因负载压力过大而响应缓慢，使用户请求具有更好的响应延迟特性。

4.3.4 代码优化

• 多线程

  1. 使用多线程的原因：IO阻塞与多CPU，更好的利用资源。
  2. 服务器上执行形同类型的任务，针对该任务可以启动的线程数：
     启动线程数=[任务执行时间/（任务执行时间 - IO等待时间）] * CPU 内核数

• 资源复用
  主要有两种模式：单例（Singleton）和对象池（Object Pool）

• 数据结构

• 垃圾回收
  再回顾一下GC步骤：

  1. 新建对象总是再Eden区中被创建，当Eden区空间已满，就出发一次Young GC，将还被使用的对象复制到From区，这样整个Eden区被清空
  2. 当Eden区再次用完，再触发一次Young GC，将Eden区和From区还在被使用的对象复制到To区，下一次Young GC将是Eden区和To区还被使用的对象复制到From区。
  3. 当多次Young GC后，如果超过某个阈值对象还未被释放，则将该对象复制到Old Generation。
  4. 如果Old Generation空间也已用完，那么就会触发Full GC，即全量回收。

4.4 存储性能优化

• 机械硬盘和固体硬盘
• B+树和LSM树

5 万无一失：网站的高可用架构

实现高可用架构的主要手段是：数据和服务的冗余备份及失效转移。

5.1 高可用的应用

应用层的一个显著的特点是应用的无状态性。所谓无状态的应用是指应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务实例（服务器）之间完全对等，请求提交到任意服务器，处理结果都是完全一样的。

• 通过负载均衡进行无状态服务的失效转移
  负载均衡服务器通过心跳检测机制发现该服务器失去响应，就会把它从服务器列表中删除，而将请求发送到其他服务器上。
• 应用服务器集群的Session管理
  集群环境下，Session管理主要有一下几种手段：
  1. Session复制
     服务器开启Web容器的Session复制功能，在集群中的几台服务器之间同步Session对象，使得每台服务器上都保存所有用户的Session信息。
  2. Session绑定（不符合高可用的要求）
     利用负载均衡的原地址Hash算法实现。负载均衡器总是将来源于同一IP的请求分发到同一台服务器上。
  3. 利用Cookie记录Session
  4. Session服务器
     利用独立部署的Session服务器（集群）统一管理Session，应用服务器每次读写Session时，都访问Session服务器。

5.2 高可用的服务

• 分级管理

  1. 核心应用和服务有限使用更好的硬件
  2. 服务部署上需要进行必要的隔离，避免故障的连锁反应。

• 超时设置

• 异步调用

  1. 应用对服务的调用通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败的情况。
  2. 当然，不是所有服务调用都可以异步调用，对于获取用户信息这类调用，采用异步方式会延长响应时间，得不偿失。对于那些必须确认服务调用成功才能继续下一步操作的应用，也不适合使用异步调用。

• 服务降级

• 幂等性设计

5.3 高可用的数据

不同于高可用的应用和服务，由于数据存储服务器上保存的数据不同，当某台服务器宕机的时候，数据访问请求不能任意切换到集群中其他的机器上。

根据CAP原理，为了保证数据的高可用，网站通常会牺牲另一个也很重要的指标：数据一致性。

• 数据备份
  数据热备分为两种：异步热备方式和同步热备方式

• 失效转移
  若数据服务器集群中任何一台服务器宕机，那么应用程序针对这台服务器的所有读写操作都需要重新路由到其他服务器，保证数据访问不会失败，这个过程叫做失效转移。

  1. 失效确认
     通过心跳检测和应用程序访问失败报告
  2. 访问转移
     确认宕机后，需要将数据读写访问重新路由到其他服务器上。
  3. 数据恢复
     从健康的服务器复制数据，将数据副本数目恢复到设定值

5.4 高可用网站的软件质量保证

（1）网站发布

发布过程中，每次关闭的服务器都是集群中的一小部分，并在发布完成后立即可以访问，因此整个发布过程不影响用户使用。
（2）自动化测试
大部分网站采用Web自动化测试技术，比较流行的测试工具是Selenium。
（3）预发布验证
网站发布时，先发布到预发布服务器上，开发和测试工程师进行预发布验证，执行一些典型的业务流程，确认系统没有问题后才正式发布。
（4）代码控制

• 有“主干开发、分支发布”和“分支开发，主干发布”两种
• 目前网站主要使用“分支开发，主干发布”。
  （5）自动化发布
• 很多网站选择周四作为发布日
• 采用“火车发布模型”，开发一个自动化发布的工具。
  （6）灰度发布
• 背景：服务器集群规模庞大，一旦发现故障，即使想要回滚，也需要很长时间才能完成。

• 灰度发布模式：将集群服务器分成若干份，每天只发布一部分服务器，观察运行稳定没有故障，第二天继续发布一部分服务器， 持续几天才能把整个集群全部发布完毕，期间如果发现问题，只需要回滚已发布的一部分服务器即可。

  
  

6 永无止境：网站的伸缩性架构

6.1 分类

• 不同功能进行物理分离实现伸缩（不同的服务器部署不同的服务，提供不同的功能）
  横向分离
  纵向分离
• 单一功能通过集群规模实现伸缩（集群内的多台服务器部署相同的服务，提供相同的功能）
  应用服务器集群伸缩性
  数据服务器集群伸缩：缓存数据服务器集群、存储数据服务器集群

6.2 应用服务器集群伸缩性

如果HTTP请求分发装置（负载均衡服务器）可以感知或者可以配置集群的服务器数量，可以及时发现集群中新上线或下线的服务器，并能向新上线的服务器分发请求，停止向已下线的服务器分发请求，那么就实现了应用服务器集群的伸缩性。

• HTTP重定向负载均衡
  HTTP重定向服务器，将其一台真实的Web服务器地址写入HTTP重定向响应中（响应状态码302）返回给用户浏览器。
  由于需要两次请求服务器才能完成一次访问，性能较差，使用这种方案不多
• DNS域名解析负载均衡
  每次域名解析请求都会根据负载均衡算法计算一个不同的IP地址返回。
  事实上，大型网站总是部分使用DNS域名解析，利用域名解析作为第一级负载均衡手段，即域名解析得到的一组服务器并不是实际提供Web服务的物理服务器，而是同样提供负载均衡服务的内部服务器，这组内部服务器再进行负载均衡。
• 反向代理负载均衡（应用层负载均衡）
• IP负载均衡
• 数据链路层负载均衡
  1. 是指在通信协议的数据链路层修改mac地址进行负载均衡。
  2. 又称为三角传输模式：负载均衡数据分发过程中不修改IP地址，只修改目的mac地址。由于实际处理请求的真实物理服务器IP和数据请求目的IP一致，不需要通过负载均衡服务器进行地址转换，可将响应数据包直接返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈。（直接路由方式DR）
  3. 这是目前大型网站使用最广的一种负载均衡手段。

6.3 分布式缓存集群的伸缩性

• 主要目标：必须让新上线的缓存服务器对整个分布式缓存集群影响最小，也就是说新加入缓存服务器后应使整个缓存服务器集群中已经缓存的数据尽可能还被访问到，这是分布式缓存集群伸缩性设计的最主要目标
• 一致性Hash算法
  1. 具体使用二叉查找树实现，Hash查找过程实际上是在二叉查找树中查找不小于查找数的最小数值。
  2. 通过虚拟节点解决负载不均衡的问题。

6.4 数据存储服务器集群的伸缩性

• 关系数据库集群的伸缩性设计

  1. 读写分离
  2. 数据分库：不同业务数据表部署在不同的数据库集群上

  数据库中间件，可以很好的支持数据分片。

  1. 应用程序通过JDBC驱动访问中间件集群，中间件服务器根据SQL和分库规则分解SQL，分发到MySQL集群不同的数据库实例上执行（每个MySQL实例都部署从节点，保证高可用）。
  2. 在做集群的伸缩时，数据库中间件可以使用负载均衡手段实现；而MySQL中存储这数据，必须要做数据迁移，将集群中原来机器中的数据迁移到新添加的机器中。

• NoSQL数据库的伸缩性设计
  HBase为可伸缩海量数据存储而设计，主要依赖其可分裂的HRegion及可伸缩的分布式文件系统HDFS实现。

7 随需应变：网站的可扩展架构

开发底耦合系统是软件设计的终极目标之一
模块分布式部署后，具体聚合方式主要有分布式消息队列和分布式服务

• 利用分布式消息队列降低系统耦合性

  1. 事件驱动架构（EDA）
     通过在低耦合的模块之间传输事件消息，以保持模块的松散耦合，并借助事件消息的通信完成模块间合作。典型的EDA架构就是操作系统中常见的生产者消费者模式，最常用的是分布式消息队列。
  2. 分布式消息队列
     -消息队列服务器将消息写入本地内存队列后立即返回成功响应给消息生产者。
     -伸缩性：将新服务器加入分布式消息队列集群中，通知生产者服务器更改消息队列服务器列表即可。
     -可用性：如果内存队列已满，会将消息写入磁盘。
     -为了避免消息队列服务器宕机造成消息丢失，会将消息成功发送到消息队列的消息存储在消息生产者服务器，等消息真正被消息消费者服务器处理后才删除消息。

• 利用分布式服务打造可复用的业务平台
  拆分服务，使用分布式服务框架构建其SOA（面向服务的体系架构）

• 可扩展的数据结构
  需要实现，无需修改表结构就可以新增字段
  许多NoSQL数据库使用的ColumnFamily（列簇）设计就是一个解决方案。

8 固若金汤：网站的安全架构

8.1 网站的攻击和防御

（1）XSS攻击

• 概念
  跨站点脚本攻击，指黑客通过篡改网页，注入恶意HTML脚本，在用户浏览网页时，控制用户浏览器进行恶意操作的一种攻击方式。

• 常见攻击类型

  1. 反射型，攻击者诱使用户点击一个嵌入恶意脚本的链接，达到攻击的目的
  2. 持久型，黑客提交含有恶意脚本的请求，保存在被攻击的Web站点的数据库中，用户浏览网页时，恶意脚本被包含在正常页面中，达到攻击目的

• 防御手段

  1. 消毒。对某些html危险字符转义，如">"转义为">"、"<"转义为"<"等。
  2. HttpOnly。浏览器机制页面JavaScript访问带有HttpOnly属性的Cookie。HttpOnly并不是直接对抗XSS攻击，而是防止XSS攻击窃取Cookie。

（2）注入攻击

• 主要有两种形式：SQL注入攻击和OS注入攻击。
• SQL注入原理：攻击者在HTTP请求中注入恶意SQL命令（http://www.a.com?user=frank';drop table users;--';），服务器用请求参数构造数据库SQL命令时，恶意SQL被一起构造，并在数据库执行。
• 防御SQL注入首先要避免被攻击者猜测到表名等数据库表结构信息，主要手段有：
  1. 消毒：通过正则匹配，过滤请求数据中可能注入的SQL
  2. 参数绑定：是最好的防SQL注入方法。ORM实现SQL预编译和参数绑定，攻击者的恶意SQL会被当做SQL的参数，而不是SQL命令执行。

（3）CSRF攻击

• 跨站点请求伪造。攻击者通过跨站请求，以合法用户的身份进行非法操作，如转账等。
• 其核心是利用了浏览器Cookie或者服务器Session策略，盗取用户身份。
• 主要防御手段
  1. 表单Token。在页面表单中增加一个随机数作为Token，每次响应页面的Token不相同，伪造的请求无法获取该值
  2. 验证码
  3. Referer check。检查HTTP请求头的Referer域，检查来源是否合法。（可以利用这个配置防盗链）

8.2 信息加密技术及密钥安全管理

一些信息加密技术：

• 单向散列加密

  1. 通过对不同输入长度的信息进行散列计算，得到固定长度的输出。这个散列计算过程是单向的。
  2. 为了加强安全性，还会给散列算法加盐（salt），salt相当于加密的密钥，增加破解的难度
  3. 常用单向散列算法：MD5、SHA

• 对称加密

• 非对称加密

密钥的安全管理：

• 密钥和算法放在一个独立的服务器上，应用系统调用这个服务，实现数据的加解密
• 将加解密算法防砸应用系统中，密钥则放在独立的服务器中，密钥还可以分片保存。

8.3 信息过滤与反垃圾

常用的信息过滤与反垃圾手段：

• 文本匹配
  常见的算法有：Trie树变种、多级Hash表。
• 分类算法
  常见的算法：贝叶斯分类算法
• 黑名单
  可以通过Hash表实现，但是当黑名单列表非常大时，Hash表需要占据极大的内存空间。
  当Hash表占内存过大时，在对过滤需求不完全精确的场景下，可用布隆过滤器代替Hash表。