.负载均衡概念
.缓存
.缓存的作用
.memcached
.memcached特点
待完善：四层负载均衡和七层负载均衡
.负载均衡分发请求的类型
什么是负载均衡
通俗一点来讲：在高并发，大数据环境下给服务器减压的，分为硬件和软件。其中：
1，硬件方面：硬件负载均衡就是多台服务器以对称的方式组成服务器集合，把压力平均分配给每台服务器，比如使用DNS负载均衡(后续详解)是最有效最简单的方法！
其中横向负载均衡和纵向负载均衡，横向扩展通过服务器群集，多台服务器技术来实现，横向扩展的好处是，有了更多的机器，如果某台机器挂掉无法工作了，仍然可以使用其他机器来处理负载；纵向扩展通过扩展服务器硬件资源，例如CPU、内存、硬盘、网卡等，但是纵向扩展一般费用比较昂贵！
2，软件方面可以利用缓存技术
首先缓存是什么？缓存的作用？
缓存是一种以空间换取时间的技术，也就是把你想要得到的数据，存放在内存中一段时间，在你设置的时间之内服务器不会去读取数据库的记录，而是通过缓存直接读取你存放在内存中的数据。
缓存的优点：缓存是网站性能优化不可缺少的数据处理机制，他能有效缓解数据库压力，就像我们目前正在做的抢购活动，同一时间网站的访问量非常高，如果不使用缓存的数据，客户点击一次就查询一次数据库，这样的设计造成服务器压力可想而知，如果我们使用了缓存技术，设置要缓存的时间，在这段时间内客户点击N次和点击一次是完全一样的，因为都是读取缓存中的数据。
常用缓存技术
平时开发中用到的缓存技术：页面缓存、数据缓存、控件缓存、配置文件设置缓存
页面缓存
- 页面缓存，<%@ OutputCache Duration="10" VaryByParam="none" %> 这条指令标签为该页面添加缓存，Duration这个参数指定页面缓存时间为10秒，VaryByParam这个指定页面参数，如下图：
- 数据缓存
Cache["要缓存的值"] = "数据"; Response.Write(Cache["要缓存的值"]);
- 控件缓存 ，一些常用的数据源控件ObjectDataSource，有一个属性CacheDuration
<asp:ObjectDataSource ID="ObjectDataSource1" runat="server" EnableCaching="True" CacheDuration="10" CacheExpirationPolicy="Absolute"> </asp:ObjectDataSource>
给控件设置缓存：例如给一个TextBox控件设置缓存：如下图
- 配置文件缓存
webConfig中的配置
<system.web>
<caching>
<outputCacheSettings>
<outputCacheProfiles>
<addname="cache" duration="60"/>
</outputCacheProfiles>
</outputCacheSettings>
</caching>
</system.web>
然后在页面中设置
<%@ OutputCache CacheProfile="cache" VaryByParam="none" %>
Memcached是由Danga Interactive开发的，高性能的，分布式的内存对象缓存系统，用于在动态应用中减少数据库负载，提升访问速度。
Memcached的特点
Memcached的缓存是一种分布式的，可以让不同主机上的多个用户同时访问，因此解决了共享内存只能单机应用的局限，更不会出现使用数据库做类似事情的时候，磁盘开销和阻塞的发生。
曾经见到知乎上有人问“为什么像facebook这类的网站需要上千个工程师维护？”，下面的回答多种多样，但总结起来就是：一个高性能的web系统需要从无数个角度去考虑他，大到服务器的布局，小到软件中某个文件
的实现，甚至于某个循环内的运算如果出现不严谨都可能导致全盘崩溃
上面提到web性能优化需要多个角度去考虑，我们无法考虑到所有的优化细节，但可以从我们已知的层面去优化，我们就先从网络层面说起。
①网络请求路径:
------------------------------------------------------------------------------------------------------------------------|
（客户端输入URL定位符）→（DNS服务器寻找映射）→（进入服务器，处理数据）→（返回数据至客户端）
在这个用例中我们可以很清晰的看出网络请求到返回的过程，虽然非常抽象，但足够我们以他为基础来进行优化了。
------------------------------------------------------------------------------------------------------------------------|
1）负载均衡
BOSS一次给了小明好多项任务，小明发现怎么安排时间也做不完，于是乎他盯上了在旁边偷偷看电影的小强，小强突然觉得背后有一股凉气，一回头小明一脸坏笑看着他，“这几个任务交给你，晚上请你吃饭，要不然...嘿嘿嘿”，小强虽然不情愿，但是在小明的请求（要挟）下，只能服从。第二天，小明顺利的完成了任务，给小强买了袋辣条。
在计算机上负载均衡也类似如此，我们的大BOSS客户端将请求发送至服务器，然而一台服务器是无法承受很高的并发量的，我们就会将请求转发到其他服务器，当然真正的负载均衡架构并不是由一台server转发的另一台server，而在客户端与服务器端中间加入了一个负责分配请求的负载均衡硬件（软件）。
DNS
名词：DNS是客户端发送请求中一个非常重要的中转，他的作用是将用户请求的URL映射为具体的IP地址，全世界有13台根服务器，但通常为我们进行域名解析的并不是根服务器，而是直接访问我们的 LDNS（Local DNS Server），通常由网络运营商维护。
最早的负载均衡就是利用搭建本地DNS服务器实现的，实现方式简单易懂，为同一个主机名分配多个映射 ，可采用轮循，随机等方式分配请求。看上去没什么问题，但是在使用过程中会发现，如果其中一个地址down机，我们是无法及时发现的，如果有用户被分配到这个主机就会出现访问失败的状况，同时我们也无法判断每个server的负载，可能会出现，某个server几乎闲置，另外一个server负载压力极高的情况。
↗（进入服务器1，处理数据）↘
（客户端输入URL定位符）→（DNS服务器寻找映射）→（DNS分配请求） （返回数据至客户端）
↘（进入服务器2，处理数据）↗
硬件设备
名词：负载均衡器（Load Balancer），负载均衡器通常作为独立的硬件置于客户端与服务器之间。
负载均衡设备拥有非常好的负载均衡性能，他拥有众多的负载均衡策略（权重，动态比率，最快模式，最小连接数等），可以保证以相对较优的方式分配请求，不过好的东西总是有代价的，那就是价格，一台负载均衡器的售价往往高达十几万甚至几十万，许多企业并不愿意为它买单。
反向代理
名词：Nginx。高性能，轻量级，已经成了人们对Nginx的第一印象，Nginx可作为HTTP服务器，在处理高并发请求的时候拥有比现在主流的Apache服务器更高的性能，同时Nginx也是一个优秀的反向代理服务器。
第一次听到“反向代理”，可能有些陌生，但如果了解与之对应的正向代理就很好理解了，正向代理通常由客户端主动链接，比如我们的科学上网方式就是使用正向代理，以达到间接访问网站的目的，而反向代理在服务器端，无需主动链接，当我们访问拥有反向代理的网站时，实际访问的是其反向代理服务器，而非真正的服务器，当请求到达反向代理服务器时，反向代理服务器再将请求转发至服务器。反向代理是实现负载均衡的主流手段之一，通常使用Nginx等服务器搭建，Nginx同样拥有众多的分配策略，以保证平均分配压力。
↗（进入服务器1，处理数据）↘
（客户端输入URL定位符）→（DNS服务器寻找映射）→（反向代理服务器） （返回数据至客户端）
↘（进入服务器2，处理数据）↗
Nginx反向代理： BIGIP（硬件）负载均衡：
2）CDN
视频总在缓冲，图片各种加载不出来，几年前是再正常不过的事了，在当时大家也没觉得是回事，但把这种情况放在现在，我想人们绝对直接就小红叉了吧，那么我们如何避免这样的情况呢？这就是我要说的，内容分发网络（Content Delivery Network），简称：CDN。
CDN简单的来说就是存储一些静态文件的一台或多台服务器，通过复制，缓存等方式，将文件保存其中。
1.哪些是静态文件？
css，html，图片，媒体都属于静态文件，也就是说用户发送的请求不会影响静态文件的内容，而jsp，php等文件就不属于静态文件，因为他们的内容会因我们的请求而发生改变。
2.CDN如何实现加速？
通常情况下，我们所要的数据都是从主服务器中获取，但假如我们的主服务器在南方，而访问用户在北方，那么访问速度就会相对变慢，变慢的原因有很多，例如传输距离，运营商，带宽等等因素，而使用CDN技术的话，我们会将CDN节点分布在各地，当用户发送请求到达服务器时，服务器会根据用户的区域信息，为用户分配最近的CDN服务器。
3.CDN数据从哪里来？
复制，缓存，CDN服务器可以在用户请求后缓存文件，也可以主动抓取主服务器内容。
分布在各地的CDNS：
在大型Web应用系统中，由于请求的数据量过大以及并发的因素，导致Web系统会出现宕机的现象，解决这一类问题的方法我个人觉得主要在以下几个方面：
1.IIS 负载均衡。
2.数据库 负载均衡。
3.系统架构优化，比如报表服务器和应用服务器分开等
负载均衡 （Load Balancing） 负载均衡建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
大型网站负载均衡的利器
- 全局负载均衡系统（GSLB）
- 内容缓存系统（CDN）
- 服务器负载均衡系统（SLB）
DNS域名解析的基本过程
最初的负载均衡解决方案（DNS轮询）
优点
- 基本上无成本，因为往往域名注册商的这种解析都是免费的；
- 部署方便，除了网络拓扑的简单扩增，新增的Web服务器只要增加一个公网IP即可
缺点
- 健康检查，如果某台服务器宕机，DNS服务器是无法知晓的，仍旧会将访问分配到此服务器。修改DNS记录全部生效起码要3-4小时，甚至更久；
- 分配不均，如果几台Web服务器之间的配置不同，能够承受的压力也就不同，但是DNS解析分配的访问却是均匀分配的。用户群的分配不均衡导致DNS解析的不均衡。
- 会话保持，如果是需要身份验证的网站，在不修改软件构架的情况下，这点是比较致命的，因为DNS解析无法将验证用户的访问持久分配到同一服务器。虽然有一定的本地DNS缓存，但是很难保证在用户访问期间，本地DNS不过期，而重新查询服务器并指向新的服务器，那么原服务器保存的用户信息是无法被带到新服务器的，而且可能要求被重新认证身份，来回切换时间长了各台服务器都保存有用户不同的信息，对服务器资源也是一种浪费。
全局负载均衡系统（GSLB）
优势
- 数据中心冗余备份
- 多站点流量优化
- 确保用户体验
全局负载均衡系统（GSLB）的原理
DNS检查工具网上有很多，感兴趣的可以搜索一下。
内容缓存系统（CDN）
- 内容缓存系统（CDN）之静态加速
- 内容缓存系统（CDN）之动态加速
动态加速的特点
- 智能路由
- 传输控制协议（TCP）优化
- HTTP预载
服务器负载均衡系统
应用背景
- 访问流量快速增长
- 业务量不断提高
用户需求
- 希望获得7×24的不间断可用性及较快的系统反应时间
负载均衡必须满足性能、扩展、可靠性
服务器负载均衡系统三种接入方式
|
部署方式 |
特点 |
优点 |
缺点 |
|
串联路由模式 |
比较常见的部署方式 |
|
|
|
单臂模式 |
最常见的部署方式 |
|
|
|
DSR |
服务器回程报文不通过负载均衡设备，直接返回给客户端； 延迟短，适合流媒体等对延时要求较高应用 |
|
|
服务器负载均衡系统的常见调度算法
- 轮询（Round Robin）
- 加权轮询（Weighted Round Robin）
- 最少连接（Least Connections）
- 加权最少连接（Weighted Least Connections）
健康性检查
健康性检查算法的目的：通过某种探针机制，检查服务器群中真实服务器的健康情况，避免把客户端的请求分发给出现故障的服务器，以提高业务的HA能力。
目前常用的健康性检查算法：
- Ping（ICMP）
- TCP
- HTTP
- FTP
系统加速
优化功能-SSL加速
优化功能-HTTP压缩
HTTP压缩是在Web服务器和浏览器间传输压缩文本内容的方法。F5 HTTP压缩技术通过具有智能压缩能力的 BIG-IP 系统可缩短应用交付时间并优化带宽。HTTP压缩采用通用的压缩算法压缩HTML、JavaScript或CSS文件。压缩的最大好处就是降低了网络传输的数据量，从而提高客户端浏览器的访问速度。
优化功能-连接复用
优化功能-TCP缓存
会话保持
会话保持-客户端源IP会话保持
源IP地址会话保持就是将同一个源IP地址的连接或者请求认为是同一个用户，根据会话保持策略，在会话保持有效期内，将这些发自同一个源IP地址的连接/请求都转发到同一台服务器。
会话保持-Cookie会话保持
当采用基于源地址的会话保持无法做到负载均分时，例如客户端发起连接请求的源IP地址相对固定，发生此类问题通常可采用基于应用层的会话保持方式，Cookie通常是存在于HTTP头中，现如今基于HTTP的应用被广泛使用，因此基于Cookie的会话保持越来越多的出现在服务器负载均衡解决方案中。
局限性：
对于非HTTP协议，或者客户端禁用Cookie，无效。
会话保持-URL哈希（Hash）会话保持
哈希会话保持的一个基本概念就是按照某个Hash因子，根据此因子以及后台存在多少台服务器计算得到的结果来选择将请求分配到那台服务器。哈希会话保持的特点是在后台服务器的健康状态不发生改变的时候，每个特定的Hash因子被分配到的服务器是固定的。其最大的优势是哈希会话保持可以没有会话保持表，而仅仅是根据计算的结果来确定被分配到那台服务器，尤其在一些会话保持表查询的开销已经远远大于Hash计算开销的情况下，采用Hash会话保持可以提高系统的处理能力和响应速度。
URL哈希会话保持通常针对后台采用Cache服务器的应用场景，针对URL进行Hash计算，将同一个URL的请求分配到同一台Cache服务器，这样，对后台的Cache服务器群来说，每台Cache服务器上存放的内容都是不一样的，提高Cache服务器的利用率。
故障案例分析
Q&A案例分析（1）-循环跳转
故障现象：
Web服务端对用户访问的URL进行判断，对于非https的请求，重定向到http站点，结果导致用户一直302跳转。
原因分析：
采用了负载均衡SSL加速功能，在服务端看到所有的用户请求都来自于http。
解决方案：
全站启用SSL加速。
Q&A案例分析（2）-用户Session丢失
故障现象：
用户在http站点上提交数据到同域名的https站点，web程序抛出session丢失的异常，用户提交数据失败。
原因分析：
http和https在负载均衡设备上被认为是2个独立的服务，产生2个独立的TCP链接，会命中不同的真实服务器，导致session丢失。
解决方案：
在负载均衡设备上启用基于真实服务器的会话保持。
Q&A案例分析（3）-客户端源IP取不到
故障现象：
服务端获取不到用户外网的IP地址，看到的都是大量来自于内网特定网段的IP地址。
原因分析：
负载均衡设备启用了用户源地址转换（SNAT）模式，修改了TCP报文中的用户源IP。
解决方案：
负载均衡设备会用用户的外网IP改写x-forwarded-for值，服务端通过获取http协议中request header头的x-forwarded-for值作为用户源IP。IIS日志通过安装插件形式显示用户源IP。
服务器负载均衡设备选型
硬件设备：F5、 Citrix 、Redware 、A10
软件：LVS、Nginx、Haproxy、zen loadbalance
4/7层吞吐量(单位bps)
4/7层新建连接数（单位CPS）
并发连接数
功能模块性能指标（ssl加速、 HTTP压缩、内存Cache）
1）如果确认负载均衡设备对所有应用的处理都是最简单的4层处理，那么理论上选择的负载均衡设备的4层性能稍高于实际性能需求即可。
2）如果确认负载均衡设备对所有应用的处理都是简单的7层处理，那么理论上选择的负载均衡设备的7层性能稍高于实际性能需求即可。
3）如果负载均衡设备处理的应用既有4层的也有7层的，建议按照7层应用的性能来考虑负载均衡设备。
4）如果确认自己的应用经过负载均衡处理时，需要复杂的4层或者7层处理，例如需要根据客户端的地址做策略性分发，需要根据tcp的内容做处理，需要根据HTTP头或者HTTP报文做处理，那么建议选择的负载均衡设备4/7层性能为真实性能需求的两倍。
5）如果负载均衡设备有混合的复杂流量处理并且还开启了一些功能模块，那么建议选择的负载均衡设备4/7层性能为真实性能需求的3倍。
6）考虑到设备需要轻载运行才能更加稳定，所以有可能的话在以上基础上再增加30%的性能。
7）如果还要满足未来几年的发展需求，在以上基础上还要留出未来发展所需要增加的性能。
8）不同负载均衡设备厂家由于不同的架构，使得某些设备在复杂环境下可能也表现的比较优秀，这个客户可以对比判断，但总体来说，以上建议适合于所有厂家的设备。
负载均衡器分发请求的类型
所有的请求首先全部到达Load balancer，再由它转发到具体的Web服务器，转发的方式分为以下几种：
- 轮转调度(Round-robin):最简单的方式，这种方式基本上不能算是负载均衡。第一个请求给web1，下一个给web2，再下一个给web3... 不会考虑某 一个服务器是不是负荷太重等等。
- 基于权重的分配(Weight-based): 可以配置每一台服务器处理请求数据的比例，特别适合那种有某台服务器配置不一样的场景。比如说某台服务器配置特别好，那我们可以让它多处理一些请求。
- 随机（Random): 随机分配。
- 粘性session（Sticky Session): Load balancer会跟踪请求，确保同一个session id的请求都交给同一样服务器。
- 最空闲优先（Least current request）：将最新的请求转发给当前处理请求数量最小的那个服务器。
- 响应时间优先(Response time)：哪台服务器当前响应时间最短就给哪台。
- 用户或URL参数选择(User or URL information)：部分负载均衡器还提供根据一些参数来决定哪台服务器来处理，比如说根据用户信息，地址位置，URL参数，cookie信息等 。
我们还可以根据负载均衡器所使用的技术将它们分为以下几类：
- 反向代理：负载均衡器作为一个代理，同时维持着两个TCP请求，从客户端接收请求，然后将请求转发给相应的Web 服务器,等Web返回Response的时候是返回给了代理服务器，然后再由代理服务器转交给真正的客户端。这样就会导致有一些功能不可用，比如在WEB服务器环境查看请求的来源IP实际上成了我们代理服务器的IP等。
- 透明反向代理：和上面的代理服务器一样，只不过WEB服务器从Request中获取到的信息是真正客户端的信息，就是好像没有使用代理一样的。
- 直接服务器返回：通过更改WEB服务器的MAC 地址来实现分发请求，在这种方式下，WEB服务器不会像上面使用代理服务器一样，请求处理完之后是直接返回给客户端的，所有相对于反向代理来说这种方式的性能会更快一些。
- NAT 负载均衡：NAT(Network Address Translation网络地址转换)，将网络包（可以理解成TCP包）中的目标IP地址变成实现要处理这个请求的WEB服务器的地址。
- Microsoft 网络负载均衡：Windows 自带的负载均衡组件，一会我们就用它来做测试。
参考文档地址：
http://www.cnblogs.com/xiao-yang/p/3818622.html
http://www.cnblogs.com/mokafamily/p/4402366.html
http://www.cnblogs.com/allen0118/p/4294066.html
http://www.cnblogs.com/and/p/3366400.html