高并发大流量设计思路

Created at 2019-06-10 Updated at 2020-07-29 Category 系统设计 Tag 高并发 views

大型网站架构演化发展历程

  • 应用服务和数据服务分离
  • 使用缓存改善网站性能
  • 使用应用服务器集群改善网站的并发处理能力
  • 数据库读写分离
  • 使用反向代理和 CDN 加速网站响应
  • 使用分布式文件系统和分布式数据库系统
  • 使用 NoSQL 和搜索引擎
  • 业务拆分
  • 分布式服务

高并发系统设计的三大目标

高性能

性能的度量指标

  • 平均值：把这段时间所有请求的响应时间数据相加，再除以总请求数。
  • 最大值：这段时间内所有请求响应时间最长的值。
  • 分位值：

高并发下的优化

  • 提高系统的处理核心数
  • 减少单次任务的响应时间

高可用

可用性的度量

  • MTBF：平均故障间隔
  • MTTR：故障的平均恢复时间
    Availability=MTBF/(MTBF+MTTR)

系统设计

  • 故障转移
  • 超时控制
  • 降级
  • 限流

系统运维

  • 灰度发布
  • 故障演练

可扩展

  • 并发：在某个时间点，有多个访问同时到来
  • 高并发：如果一个系统日PV在千万以上，有可能是一个高并发系统
  • QPS：每秒钟请求或者查询的数量，在互联网领域，指每秒请求数（HTTP请求）
  • 吞吐量：单位时间内处理的请求数量（通常由QPS并发数决定）
  • 响应时间：从请求发出到响应花费的时间
  • PV：综合浏览量（Page View），一个访客在24小时内访问的页面数量，同一个人浏览你的网站同一页面，只记作一次PV
  • UV：独立访客（Unique Visitor），一定时间范围内相同访客多次访问网站，只计算为1个独立访客
  • 带宽：峰值流量和页面平均大小
  • 日网站带宽=PV/统计时间（换算到秒）* 平均页面大小（单位kb）* 8 峰值一般是平均值的倍数
  • 峰值QPS=（总PV数 * 80%）/（6个小时秒数 * 20%）
  • 压力测试 测试能承受的最大并发 最大承受的QPS值
  • 常用性能测试工具
  • apache benchmark
    • yum -y install http-tools
    • ab -c100 -n 5000 待测试网站 并发请求100次 总共请求5000次
    • 测试机器与被测试机器分开
  • QPS达到100时，数据库缓存，数据库负载均衡 达到800，CDN加速，负载均衡 1000，静态html缓存 2000 业务分离，分布式存储
  • 流量优化 防盗链处理
  • 前端优化：减少http请求 添加异步请求 启用浏览器缓存和文件压缩 CDN加速 动静分离，静态资源独立部署 独立图片服务器 反向代理
  • 服务端优化：页面静态化 并发处理 队列处理 负载均衡 业务拆分
  • 数据库优化：数据库缓存 分库分表 分区 读写分离 负载均衡
  • web服务器优化：负载均衡

网站架构模式

分层

  • 应用层
  • 服务层
  • 数据层

分割

分布式

  • 分布式应用和服务
  • 分布式静态资源
  • 分布式数据和存储
  • 分布式计算

集群

缓存

  • CDN
  • 反向代理
  • 本地缓存
  • 分布式缓存

异步

  • 提高系统可用性
  • 加快网站响应速度
  • 消除并发访问高峰

冗余

自动化

架构在新浪微博的应用

早期架构中，微博发布使用同步推模式，当粉丝多的时候，会引起大量的数据库写操作，超出数据库负载，系统性能急剧下降。后来改用 异步 推拉结合模式，用户发表微博后系统将微博写入消息队列后立即返回，消息队列消费者任务将微博推送给左右当前在线粉丝的订阅列表中，非在线用户登陆后再根据关注粉丝列表拉取微博订阅列表

大型网站核心架构要素

性能

可用性

伸缩性

扩展性

安全性

高性能

  • 响应时间
  • 并发数
  • 吞吐量
  • 性能计数器

Web 前端性能优化

一般 Web 前端指网站业务逻辑之前的部分，包括浏览器加载、网站视图模型、图片服务、CDN 服务等，主要优化手段有优化浏览器访问、使用反向代理、CDN 等。

浏览器访问优化

  • 减少 http 请求：合并 css，js，图片。
  • 使用浏览器缓存：通过设置 HTTP头中 Cache-Control 和 Expires 的属性，可设定浏览器缓存。
  • 启用压缩：对 HTML、CSS、JavaScript 文件启用 GZip 压缩可达到较好的效果。
  • CSS放页面最上面，JavaScript 放页面最下面。
  • 减少 Cookie 传输

CDN 加速

CDN（内容分发网络）的本质仍然是一个缓存，并且将数据缓存在离用户最近的地方，是用户以最快速度获取数据，即所谓网络访问第一跳。CDN 能够缓存的一般是静态资源。

反向代理

传统代理服务器位于浏览器一侧，代理浏览器将 HTTP 请求发到互联网上，而反向代理服务器位于网络机房一侧，代理网站 Web 服务器接收 HTTP 请求。

反向代理的作用：

  • 保护网站安全
  • 配置缓存加速 Web 请求
  • 负载均衡

应用服务器性能优化

应用服务器就是处理网站业务的服务器，网站的业务代码都部署在这里。优化手段主要有缓存、集群、异步等。

分布式缓存

当网站遇到性能瓶颈时，第一个想到的解决方案就是使用缓存。缓存即存在于浏览器，也存在于应用服务器和数据库服务器；既可以对数据缓存，也可以对文件缓存，还可以对页面片段缓存。

网站优化第一定律：优先考虑使用缓存优化性能。

异步操作

使用消息队列将调用异步化，可改善网站的的性能和扩展性。

在不使用消息队列的情况下，用户的请求数据直接写入数据库，在高并发的情况下，会对数据库造成巨大的压力，同时也使得响应延迟加剧。在使用消息队列后，用户请求的数据发送给消息队列后立即返回，再用消息队列的消费者进程从消息队列中获取数据，异步写入数据库。

使用集群

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

代码优化

  • 多线程
  • 资源复用：单例模式、对象池

高可用

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

负载均衡

负载均衡会把用户发送的访问请求分发到任意一台服务器上处理，当其中一台服务器宕机时，负载均衡服务器通过心跳检测机制发现该服务失去响应，就是把它从服务器列表中删除，而将请求发送到其他服务器上。

集群的 Session 管理

应用层服务器的高可用架构设计主要基于服务无状态这一特性，但是事实上，业务总是有状态的。Web 应用中将这些多次请求修改使用的上下文对象称作会话（Session），单机情况下，Session 可由部署在服务器上的 Web 容器。在使用负载均衡的集群环境中，要保证每次请求能够获得正确的 Session 比单机时要复杂的多。以下是几种 Session 管理手段。

Session 复制

应用服务器开启 Web 容器的 Session 复制功能，在集群中的几台服务器之间同步 Session 对象，使得每台服务器上都保存所有用户的 Session 信息。

这种方式需要大量的通信进行 Session 复制，占用服务器和网络大量资源，而且由于所有用户的 Session 信息在每台服务器上都有备份，在大量用户访问的情况下，甚至会出现服务器内存不够的情况。

Session 绑定

Session 绑定可以利用负载均衡的源地址 Hash 算法实现，负载均衡服务器总是将来源于同一 IP 的请求分发到同一台服务器上。（也可以根据 Cookie 信息将同一个用户的请求总是分发到同一台服务器上，这时负载均衡服务器必须工作在 HTTP 协议层上。这种方法又叫会话黏滞）。

这种方法不符合对系统高可用的需求，一旦一台服务器宕机，就无法完成业务处理。

将 Session 记录在客户端，每次请求服务器的时候，将 Session 放在请求中发送给服务器，服务器处理完请求后再将修改过的 Session 响应给客户端。

利用 Cookie 记录 Session 也有一些缺点，比如受 Cookie 大小限制，每次请求响应都要传输 Cookie，影响性能。如果用户关闭 Cookie，访问就会不正常。

Session 服务器

利用独立部署的 Session 服务器（集群）统一管理 Session，应用服务器每次读写 Session 时，都访问 Session 服务器。

这种解决方案事实上是将应用服务器的状态分离，分为无状态的应用服务器和有状态的 Session 服务器，然后针对这两种服务器的不同特性分别设计其架构。

对于有状态的 Session 服务器，一种比较简单的方法是利用分布式缓存，数据库等，在这些产品的基础上进行包装，使其符合 Session 的存储和访问要求。

高可用的服务

分级管理

运维上将服务进行分级管理，核心应用和服务优先使用更好的硬件。

服务部署上进行必要的隔离，避免故障的连锁反应。低优先级的服务通过启动不同的线程或者部署在不同的虚拟机上进行隔离，而高优先级的服务则需要部署在不同的物理机上，核心服务和数据甚至需要部署在不同地域的数据中心。

超时设置

在应用程序中设置服务调用超时时间，一旦超时，同i性能框架就抛出异常，应用程序根据服务调度策略，可选择重试或将请求转移到提供相同服务的其他服务器上。

异步调用

通过消息队列等异步方式完成，避免一个服务失败导致整个应用请求失败的情况。

服务降级

在网站访问高峰期，服务可能因为大量的并发调用而性能下降，严重时可能会导致服务宕机。为了保证核心应用和功能的正常运行，需要对服务进行降级。降级有两种手段：拒绝服务及关闭服务。

  • 拒绝服务：拒绝低优先级应用的调用，减少服务调用并发数，确保核心应用正常使用。或者随即拒绝部分请求应用，节约资源，让另一部分请求得以成功。
  • 关闭服务：关闭部分不重要的服务，以节约系统开销，为重要的服务和功能让出资源。

幂等性设计

应用调用服务失败后，会将调用请求重新发送到其他服务器，但是这个失败可能是虚假的失败。比如服务已经处理成功，但因为网络故障应用没有收到响应，这时应用重新提交请求就导致服务重复调用。

服务重复调用是无法避免的，因此必须在服务处保证服务重复调用和调用一次产生的结果相同，即服务具有幂等性。

高可用的数据

保证数据存储高可用的手段主要是数据备份和失效状态转移机制。

CAP 原理

CAP 原理认为，一个提供数据服务的存储系统无法同时满足一致性（Consistency）、数据可用性（Availability）、分区容错性（Partition Tolerance）。

  • 一致性：所用应用程序都能访问得到相同的数据
  • 可用性：任何时候，任何应用程序都可以读写访问
  • 分区容错性：系统可以跨网络分区线性伸缩

为了保证数据的高可用，网站通常会牺牲数据一致性。

数据一致性又可分为：强一致、用户一致、最终一致。

数据备份

  • 冷备
  • 异步热备
  • 同步热备

失效转移

失效转移操作由三部分组成：

  • 失效确认：系统确认一台服务器是否宕机的手段有两种：心跳检测和应用程序访问失败报告。对于应用程序访问失败报告，控制中心还需要再一次发送心跳检测进确认，以免错误判断服务器宕机。
  • 访问转移：将数据读写访问重新路由到其他服务器上。
  • 数据恢复

伸缩性

负载均衡不但可以实现网站的伸缩性，同时还可以改善网站的可用性。

负载均衡的实现技术

HTTP 重定向

HTTP 重定向服务器就是一台普通的应用服务器，其唯一功能就是根据用户的 HTTP 请求计算一台真是的 Web 服务器地址，并将该 Web 服务器地址写入 HTTP 重定向响应（ 302）中返回给用户浏览器。

  • 优点：实现比较简单
  • 缺点：是浏览器需要请求两次服务器才能完成一次访问，性能较差。

DNS 域名解析

在 DNS 服务器中配置多个 A 记录，每次域名解析请求都会根据负载均衡算法计算一个不同的 IP 地址返回。这样 A 记录中配置的多个服务器就会构成一个集群，并实现负载均衡。

  • 优点：是将负载均衡的工作转交给 DNS，同时许多 NDS 还支持基于地理位置的域名解析，会将域名解析成距离用户地理最近的一个服务器，加快用户访问速度。
  • 缺点：DNS 是多级解析，每一级 DNS 都可能缓存 A 记录，当下线某台服务器修改了 A 记录后，使其生效也需要较长时间，这段时间 DNS 依然会将域名解析到已经下线的服务器，导致用户访问失败。

反向代理

反向代理服务器将请求根据负载均衡算法转发到不同 Web 服务器上。Web 服务器处理完成的响应也需要反向代理服务器返回给用户，由于 Web 服务器不直接对外提供访问，因此需不要使用外部 IP 地址，而反向代理服务器需要配置内外网 IP。

反向代理服务器转发请求在 HTTP 协议层面，因此也叫应用层负载均衡。

  • 优点：和反向代理服务器功能集成在一起，部署简单。
  • 缺点：反向代理服务器是所有请求和相应的中转站，其性能可能会成为瓶颈。

IP 负载均衡

在网络层通过修改请求目标地址进行负载均衡。

  • 优点：在内核进程内完成数据分发，较反向代理有更好的处理性能。
  • 缺点：集群的最大响应数据吞吐量受限于负载均衡服务器网卡带宽。

直接路由

是指在通信协议的数据链路层修改 mac 地址进行负载均衡，这种传输方式又称三角传输模式。实际请求的正是物理服务器 IP 和数据请求目的 IP 一致，不需要通过负载均衡服务器进行地址转换。

这种三角传输模式的链路层负载均衡是目前大型网站使用最广的一种负载均衡手段。在 Linux 平台上最好的链路层负载均衡开源产品是 LVS（Linux Virtual Server）。

  • 优点：避免负载均衡服务器网卡带宽称为瓶颈。

负载均衡算法

轮询（ Round Robin，RR）

所有请求被依次分发到每台应用服务器上，即每台服务器需要处理的请求数目都相同，适合于所有服务器硬件都相同的场景。

随机（ Random）

请求被随机分配到各个应用服务器。如果应用服务器硬件配置不同，也可以使用加权随机算法。

最少连接（ Least Connections）

记录每个应用服务器正在处理的连接数，将新的请求分发到最少链接的服务器上。最少连接算法也可以实现加权最少连接。

源地址散列（ Source Hashing）

根据请求来源的 IP 地址进行 Hash 计算，得到应用服务器。这样来自同一个 IP 渎职的请求总在同一个服务器上处理，该请求的上下文信息可以存储在这台服务器上，在一个绘画周期重复使用，从而实现会话粘滞。

网站的安全架构

XSS（跨站脚本攻击）

黑客通过篡改网页，注入恶意 HTML 脚本，在用户浏览网页时，控制用户浏览器进行恶意操作的一种方式。

常见的 XSS 攻击类型有两种。

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

防范手段

  • 过滤特殊字符
  • HttpOnly

危害

  • 窃取用户的 Cookie
  • 伪造虚假的输入表单片区个人信息
  • 显示伪造的文章或者图片

防范手段

  • 过滤特殊字符
  • HttpOnly：防止窃取 Cookie

CSRF （跨站请求伪造）

防范手段

  • 检查 Refer 首部字段
  • 添加校验 Token
  • 输入验证码

SQL 注入

防范手段

  • 使用参数化查询 preparedStatement
  • 单引号转换

拒绝服务攻击（洪水攻击）

其目的在于使目标电脑的网络或系统资源耗尽，使服务暂时中断或停止，导致其正常用户无法访问。

分布式拒绝服务攻击（distributed denial-of-service attack，DDoS），指攻击者使用两个或以上被攻陷的电脑作为“僵尸”向特定的目标发动“拒绝服务”式攻击。

防范手段

  • 防火墙：防火墙可以设置规则，例如允许或拒绝特定通讯协议，端口或IP地址。当攻击从少数不正常的IP地址发出时，可以简单的使用拒绝规则阻止一切从攻击源IP发出的通信。

对于大流量的网站,您采用什么样的方法来解决访问量问题?

优化程序，优化数据库，如果程序和数据库已经最优化，使用以下解决方法：

  1. 确定当前服务器设备是否满足流量需求。
  2. 使用Memcache缓存技术，把动态内容缓存到文件中，动态网页直接调用这些文件，而不必再访问数据库。
  3. 禁止外部盗链，图片和文件外部盗链会给服务器带来大量的负载压力，可以通过refer来禁止外部盗链，或者使用apache来配置禁止盗链。
  4. 控制大文件的下载，大文件的下载对于非SCSI硬盘来说会占用大量的资源，导致服务器的响应能力下降。
  5. 使用不同的主机分流主要流量，使服务器均衡负载。
  6. 使用流量统计软件统计分析网站流量，可以知道哪些地方耗费了大量的流量，哪些页面需要再进行优化。

系统如何支持高并发

  1. 系统集群化部署
  2. 数据库分库分表 + 读写分离
  3. 缓存集群的引入
  4. 引入消息中间件集群

web资源防盗链

  • 概念：在自己的页面上战视一些并不在自己服务器上的内容
  • 工作原理：
    1. 通过Referer或者签名，检测目标网页访问的来源网页，如果是资源文件，则可以追踪到显示他的网址，一旦检测到来源不是本站即进行阻止或返回指定的页面
    2. 通过计算签名的方式，判断请求是否合法，如果合法则显示，否则返回错误信息
  • Refer方法：Nginx模块ngx_http_refer_module用于阻挡来源非法的域名请求，Nginx指令valid_referers 全局变量$invaild_referer

减少http请求

  • 图片地图：将 5 个图片合并为一张图片，然后以位置定位超链接。把 HTTP 请求减少为一个
  • CSS Sprites：CSS 精灵，通过合并图片，指定 css 的 background-image 和 background-position 来显示元素
  • 合并脚本和样式表
  • 图片使用 Base64编码

浏览器缓存

缓存分类

浏览器缓存 200(from cache) 和 304

  • 200 from cache：本地缓存（强制缓存），最快速，最省流量，因为根本没有向服务器发送请求。
    相关 Header
    • Pragma：HTTP 1.0 时代的遗留产物，该字段被设置为 no-cacche 时，会告知浏览器禁用本地缓存
    • Expires：HTTP 1.0 时代来启用本地缓存的字段，值是一个格林威治时间，告诉浏览器缓存实现的时刻，如果还没到该时刻，则缓存有效，浏览器与服务器时间无法保持一致，如果时间差距大，就会影响缓存结果。
    • Cache-Control：HTTP 1.1 针对 Expires 时间不一致的解决方案，告知的是过期时间间隔，不是时刻。
      • no-store：禁止浏览器缓存相应
      • no-cache：不允许直接使用本地缓存，先发起请求和服务器协商
      • max-age=delta-seconds：告知浏览器该响应本地缓存有效的最长期限，以秒为单位，如果和 Last-Modified 一起使用，优先级较高
    • 优先级：Pragma > Cache-Control > Expires
  • 304 Not Modified：协商缓存，浏览器在本地缓存没有命中的情况下请求头中发送一定的校验数据到服务端，如果服务端数据没有改变浏览器从本地缓存响应，返回 304。只返回一些响应头信息，不发送相应实体
    相关 Header
    • Last-Modified（响应头）：通知浏览器资源的最后修改时间
    • If-Modified-Since（请求头）：得到资源的最后修改时间后，会将这个信息通过 If-Modified-Since（里面的值就是 Last-Modified） 提交到服务器做检查，如果没有修改，返回 304。
    • ETag：HTTP 1.1 推出，文件的指纹标识符，如果文件内容修改，值会改变。
    • If-None-Match：本地缓存失效，会携带 ETag 的值去请求服务端，服务端判断该资源是否改变，如果没有改变，直接使用本地缓存，返回 304。

缓存策略的选择

本地缓存

  • 不变的图像：如 Logo
  • js，css 静态文件
  • 可下载的内容，媒体文件

协商缓存

  • HTML 文件
  • 经常替换的图片
  • 经常修改的 js，css：可以加入文件的签名来拒绝缓存，index.css?签名

不建议缓存的数据

  • 用户隐私等敏感信息
  • 经常改变的 api 数据接口

Nginx 配置写法

gzip on|off; #是否开启gzip
gzip_buffers 32 4K| 16 8K #缓冲(压缩在内存中缓冲几块? 每块多大?)
gzip_comp_level [1-9] #推荐6 压缩级别(级别越高,压的越小,越浪费CPU计算资源)
gzip_types text/plain application/xml # 对哪些类型的文件用压缩 如txt,xml,html ,css
}

前端代码和资源压缩

  • js 代码压缩工具：UglifyJS，YUI Compressor，Closure
  • css 压缩工具：YUI Compressor，CSS Compressor
  • 使用 Gzip 压缩
  • 图片压缩：tinypng，JpegMini，ImageOptim
    gzip on|off;
gzip_buffers 32 4k|16 8k;//缓冲（在内存中缓冲几块？每块多大）

web服务器的负载均衡

  • 七层负载均衡的实现

    • 功能强大，性能卓越，运行稳定
    • 配置简单灵活
    • 能够自动剔除工作不正常的后端服务器
    • 上传文件使用异步模式
    • 指出多种分配策略，可以分配权重，分配方式灵活

  • 四层负载均衡的实现

  • Nginx的负载均衡

    • 内置策略：IP Hash、加权轮询
    • 扩展策略：fair策略，通用hash、一致性hash

    CDN 加速

    CDN 的全称是 Content Delivery Network，即内容分发网络。在网络各处放置节点服务器所构成的在现有的互联网基础上的一层只能虚拟网络。

CDN 系统能够实时地根据网络流量和个节点的连接，负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。

优势

  • 本地 Cache 加速，提高了企业站点（尤其含有大量图片和静态页面站点）的访问速度
  • 跨运营商的网络加速，保证不同网络的用户都得到良好的访问质量
  • 远程访问用户根据 DNS 负载均衡技术自动选择 Cache 服务器
  • 自动生成服务器的远程 Mirror（镜像）cache 服务器，减轻远程访问的带宽，分担网络流量， 减轻原站点 WEB 服务器负载
  • 广泛分布的 CDN 节点加上节点之间的智能冗余机制，可以有效地预防黑客入侵

场景

  • 站点或者应用中大量静态资源加速分发
  • 大文件下载
  • 直播网站

CDN 的实现

  • 使用现成的
  • 用 LVS 做 4 层负载均衡
  • 可用 Nginx，Varnish，Squid，Apache TrafficServer做 7 层负载均衡
  • 使用 squid 做反向代理，或者 Nginx 等做反向代理

建立独立的图片服务器

必要性

  • 分担 Web 服务器的 I/O 负载，将耗费资源的图片服务分离出来，题搞服务器的性能和稳定性
  • 能够专门对图片服务器进行优化，为图片服务设置有针对性的缓存方案每减少带宽成本，提高访问速度
  • 提高网站的可扩展性，通过增加图片服务器，提高图片吞吐力

采用独立域名

  • 同一域名下浏览器的并发链接数有限制，突破浏览器并发限制
  • 由于 cookie 的原因，对缓存不利，大部分 web cache都只缓存不带 cookie 的请求，导致每次的图片请求都不能命中 cache

如何进行图片上传和同步

  • NFS 共享方式
  • 利用 FTP 同步

动态语言静态化

将现有 PHP 等动态语言的逻辑代码生成为静态 HTML 文件，用户访问动态脚本重定向到静态 HTML 文件的过程。
动态脚本通常会做逻辑和数据查询，访问量越大，服务器压力越大，CPU 负载过高，数据库服务器压力大。

实现方式

  • 使用模板引擎
  • 使用 ob 系列函数
    • ob_start()：打开输出控制缓冲
    • ob_get_contents()：返回输出缓冲区的内容
    • ob_clean()：清空输出缓冲区
    • ob_end_flush()：冲刷出输出缓冲区内容并关闭缓冲

动态语言层的并发处理

  • 就绪状态：线程具备运行的所有条件，逻辑上可以运行，在等待处理机
  • 运行状态：线程占有处理机正在运行
  • 阻塞状态：线程在等待一个事件（如某个信号量），逻辑上不可执行

协程

协程是一种用户态的轻量级线程，写成的调度完全由用户控制。协程拥有自己的寄存器上下文和栈。协程调度切换时，将寄存器上下文和栈保存到其他地方，再切回来的时候，恢复先前保存的寄存器上下文和栈，直接操作栈则基本没有内核切换的开销，可以不加锁的访问全局变量，所以上下文的切换非常快。

线程和进程的区别

  1. 线程是进程内的一个执行单元，进程内至少有一个线程，他们共享进程的地址空间，而进程有自己独立的地址空间
  2. 进程是资源分配的基本单位，同一个进程内的线程共享进程的资源
  3. 线程是处理器调度的基本单位

线程与协程的区别

  1. 一个线程可以有多个协程，一个进程也可以单独拥有多个线程
  2. 线程进程都是同步机制，而协程是异步
  3. 协程能保留上一次调用时的状态，每次过程重入时，就相当于进入上一次调用的状态

数据库缓存层优化

MySQL 数据层优化

参考文章

Table of Content

  1. 大型网站架构演化发展历程
  • 高并发系统设计的三大目标
    1. 高性能
      1. 性能的度量指标
      2. 高并发下的优化
    2. 高可用
      1. 可用性的度量
      2. 系统设计
      3. 系统运维
    3. 可扩展
  • 网站架构模式
    1. 分层
    2. 分割
    3. 分布式
    4. 集群
    5. 缓存
    6. 异步
    7. 冗余
    8. 自动化
    9. 架构在新浪微博的应用
  • 大型网站核心架构要素
    1. 性能
    2. 可用性
    3. 伸缩性
    4. 扩展性
    5. 安全性
  • 高性能
    1. Web 前端性能优化
      1. 浏览器访问优化
      2. CDN 加速
      3. 反向代理
    2. 应用服务器性能优化
      1. 分布式缓存
      2. 异步操作
      3. 使用集群
      4. 代码优化
  • 高可用
    1. 负载均衡
    2. 集群的 Session 管理
      1. Session 复制
      2. Session 绑定
      3. 利用 Cookie 记录 Session
      4. Session 服务器
    3. 高可用的服务
      1. 分级管理
      2. 超时设置
      3. 异步调用
      4. 服务降级
      5. 幂等性设计
    4. 高可用的数据
      1. CAP 原理
      2. 数据备份
      3. 失效转移
  • 伸缩性
    1. 负载均衡的实现技术
      1. HTTP 重定向
      2. DNS 域名解析
      3. 反向代理
      4. IP 负载均衡
      5. 直接路由
    2. 负载均衡算法
      1. 轮询（ Round Robin，RR）
      2. 随机（ Random）
      3. 最少连接（ Least Connections）
      4. 源地址散列（ Source Hashing）
  • 网站的安全架构
    1. XSS（跨站脚本攻击）
      1. 防范手段
      2. 危害
      3. 防范手段
    2. CSRF （跨站请求伪造）
      1. 防范手段
    3. SQL 注入
      1. 防范手段
    4. 拒绝服务攻击（洪水攻击）
      1. 防范手段
  • 对于大流量的网站,您采用什么样的方法来解决访问量问题?
    1. 系统如何支持高并发
    2. web资源防盗链
    3. 减少http请求
    4. 浏览器缓存
      1. 缓存分类
      2. 缓存策略的选择
        1. 本地缓存
        2. 协商缓存
        3. 不建议缓存的数据
      3. Nginx 配置写法
    5. 前端代码和资源压缩
    6. web服务器的负载均衡
    7. CDN 加速
      1. 优势
      2. 场景
      3. CDN 的实现
    8. 建立独立的图片服务器
      1. 必要性
      2. 采用独立域名
    9. 如何进行图片上传和同步
    10. 动态语言静态化
      1. 实现方式
    11. 动态语言层的并发处理
      1. 协程
      2. 线程和进程的区别
      3. 线程与协程的区别
    12. 数据库缓存层优化
    13. MySQL 数据层优化
  • 参考文章
    • Site by Cellophane using Hexo & Random

    Hide