本篇讲解高并发系统的流量清洗策略，鉴于高并发流量清洗的复杂性，一篇无法讲述完毕，后续将会补充，本篇将会讲述从入口处进行的流量清洗和简单的系统集群演变的面对高并发环境的策略

基于CDN的入口流量清洗

CDN简单介绍

• CDN的全称是 Content Delivery Network ，即内容分发网络。简单来说，CDN就是将资源架设在不同的地区，使得该地区的用户可以就近获取资源，提高访问速度，提高访问的稳定性

为什么需要CDN

• 在当今风云变幻的互联网时代，人们对于互联网访问速度不断提高，如果你网站的访问时间超过一定时间，那么用户就有可能不耐烦，从而放弃访问或者下载资源。这对于公司的发展是不利好的。

CDN的优势

• CDN节点解决了跨运营商和跨地域的访问问题，大大提高了访问速度
  1. 当一个用户访问的一个服务器时，两者之间的距离越远，访问的延迟就会越大
  2. 当一个用户跨运营商访问服务器的时候，延迟也会变大
• 大部分请求在CDN的边缘站点被解决，大大减少主站的访问压力，起到了分流，流量清洗的作用
  1. 阿里巴巴的淘宝网通过CDN技术可以分流走98%的访问，大大减少了主站的访问压力

CDN的运作原理

1. 用户从浏览器发起一个 访问请求 www.yin-jh.club ,此时，浏览器会从本地的host文件查询是否存在该域名和这个域名对应的ip地址
2. 如果无法找到，那么浏览器就会将这个请求发向DNS服务器
3. 网站的DNS域名解析器通过CNAME解析器给智能DNS负载均衡系统解析域名，把对用户响应速度最快的IP节点返回给用户
4. 用户就会向该节点发送请求

浅谈CDN的适用环境

• CDN边缘服务器上面需要放置一些静态的文件，放置一些变换程度不高的文件，如果文件的变换程度太高的话，那么就会有可能出现数据不一致问题或者系统不可用问题

基于LB的流量清洗

LB的简单介绍

LB是英文 Load Balance 的缩写，中文翻译其实应该是负载均衡，于我而言可以用来做负载均衡的就是 Nginx 和 LVS

从一个系统架构的变化发展来介绍基于LB的流量清洗

• 一开始，我们有一个仅仅需要一台服务器就可以运行的项目。

  

  1. 项目中所有的内容全部都会被放在这个服务器里面，这样的服务器最多支持qps达20左右
  2. 这种项目也并不需要什么LB

• 随着项目的用户扩张，20的qps显然无法支持，这个时候我们可以对项目做集群处理

  

  1. 这个时候就可以将项目直接复制 all in one ，然后在项目的前面配置一个 LB 来做负载均衡，此时，项目之间的session是通过最基础的方式共享的，当一个服务器上面session有创建的时候，就会将这个session通过 socket 连接复制到其他所有的服务器上
  2. 前台的 LB 可以是 Nginx 或者 LVS ，LVS 的区别在于有可能会出现流量倾斜问题，但是问题不大
  3. 这个时候集群的大小应该控制在个位数，如果超出个位数的话，基础的session共享策略就会成为集群并发的瓶颈，这个时候就应该使用另外一种 session 共享策略

• 因为基础session共享策略的问题，盲目地添加机器无法使项目整体效率提高

  

  1. 该方案和上一个方案的区别就在于 上一个方案的session共享策略是将session复制到其他所有机器上；该方案是将所有机器上的session都提取出来，单独保存
  2. 该方案可以维持数十台机器的集群，qps达到接近1000也可以，但是如果qps再提高就需要做优化了

• 项目的并发量再次提高，单纯集群就开始吃不消，需要进行简单的服务划分

  

  1. 将整个项目拆分成为 soa 架构，将单独的模块剥离开来，每一个模块有自己的集群

  2. 这样的架构存在一个问题需要解决：访问的集群没有想要的服务

     

     我们使用 qq.com 作为例子举例：

     我们直接从网站访问的接口来进行划分，将 qq.com 分为 download.qq.com 和 document.qq.com 这样我们就可以将qq网站的文件系统和下载系统划分开来，这样两个不同的url无法导向对方，就解决了这个问题

  • 项目的并发量持续提升，单个页面的访问量也激增

    1. 以淘宝为例

       

    2. 像这种大量的访问量全部怼到一个接口 ： item.html?id=XXXXXX 的并发情况，项目无法再根据 uri 来将内容分发到不同的机器，这个时候就有了新的解决方法

  • 解决单个资源访问量巨大的问题：页面静态化

    • 我们可以将页面给静态化，但是静态的页面却会出现一定问题，大量的页面会使得资源管理非常困难，而且大量的页面占有的空间资源也非常大，这个方案不好

    • 除了将页面直接静态化，我们还可以采取折中的方法，通过模板来动态生成页面，这样的感觉就非常像 thymeleaf 和 freemarker ，通过模板来生成页面，这些被生成的页面直接是被存储在内存中的，并不会落地到磁盘中，这样关于静态页面的资源管理相比第一个策略基本就没有了；但是这种通过 tomcat 的方法来生成页面的方法非常笨重

      

    • 想要通过 tomcat 来渲染模板，那么就要通过 tomcat 和 db 的 socket 连接，使得tomcat和数据库建立连接，这是一个非常耗费时间的事情；除此之外，还需要通过网络IO和磁盘读取IO，效率低，这个方案比前面的好，但是还是有缺陷

    • 我们可以不通过 tomcat 来进行页面的动态渲染，我们可以尝试使用 nginx+lua 的方式来动态渲染页面，这种方式可以极大提高效率，但是哪怕你提高了渲染效率，最重要的和数据库之间进行交互的大量效率低下的部分需要解决

解决单接口高并发的 Nginx 集群

浅谈 Nginx 集群

• 对于nginx集群来说，一般来说是没有必要的

• Nginx官方声称，nginx可以支持超过5w的并发，但是现实中这样使用的非常少，因为大部分公司的业务都没有达到5w，所以对于绝大部分企业来说，都用不到nginx集群，但是如果是像淘宝这样的超高并发企业的某些模块单独的nginx是无法支撑的，这就需要nginx集群了

Nginx 集群的架构

• 架构的初始版本

  

  1. 这个版本的架构里，nginx里面只会缓存热数据，这些热数据都是从后面的redis中取出来的
  2. 这个时候nginx中做缓存有可能会出现问题，不同的nginx中出现的热数据有可能会有重合

• 架构的简单演变

  

  1. 将请求的item的 id 做一致性hash计算，计算结果 % nginx数量
  2. 不同的id信息就被缓存在不同的nginx上，这样就可以让缓存不会出现重复现象，重复利用缓存

• 尝试对nginx做高可用

  

  1. 对nginx做高可用可以使用hash环的方式来进行高可用搭建

架构浅谈

• 这个架构就是京东在数年前单个机房内的架构
• 如果将这套架构分散到全国各地，全国各地的机房在通过专线连接，这样就可以搭建出支持亿级流量的架构