以访问web为例。
假定一台主机，它的内存为4G，2个cpu，如果服务器接收1000个静态请求（每个请求占用2M空间），50个动态请求（每个请求占用10M空间），则所占用的空间差不多达到服务器的内存上限，此时服务器处理请求的速度会变很慢，很难满足客户的需求。
解决方法：scale on（向上扩展），扩大内存和CPU，通过调用一台性能好的主机来处理请求。缺陷：只能在一定的范围内使用，而且价格难以接受。
scale out（向外扩展），加服务器。也就是所讲到的负载均衡。
LB：负载均衡集群
图示为请求访问前端服务器，前端服务器将请求分发给后台的3台服务器上进行处理。
3台服务器，用户请求可能只有一种，该怎么实现将用户请求分到3台服务器上？
通过DNS A记录，不同的解析返回不同的返回值（负载均衡）。前端服务器通过某种调度算法将请求发送给后台服务器。(RR:轮调，请求第一次给1，第二次给2，第三次给3，以此类推)，假设1的性能是2和3的两倍，为了考虑公平和效率，能者多劳，所以用（WRR：加权轮调算法，第1台服务器设置 weight 2 ，其它两台设置 weight 1。）
如果用户发一个帖到1服务器上，第二次访问的时候请求被分发到2服务器上，帖子就不能被看到，为了解决以上出现的问题，可以将用户发到1服务器上的帖保存到数据库上，这样当再次访问请求被分发到2服务器上是，通过检索数据库从而获得数据，这样能够让请求无论到达哪个服务器上都能检索信息。
注：上传的附件保存到哪？比如上传图片，图片本身不能保存到数据库上，可以将上传的附件保存到另一个设备（nfs）上，数据库保存附件的链接，如果请求要访问附件，可以访问数据库所保存的链接获得所需的附件。页面文件不应该放在nfs服务器上，应该放在本地。如果需要更新页面，通过rsync服务将第1台主机上的文件目录作为更新目录，在1更新后通知2和3，让它们将文件复制过去，这就不会造成页面的不同步为了。工作原理图如下：
HA：高可用集群
如果只有一个前端服务器，万一前端服务器挂了，整个集群就挂了，这显然并不合理。
再加一个前端服务器，一个作为primary，一个作为secondary，主的挂了以后，secondary工作。这就是所说的高可用集群（HA）。
两个前端服务器之间通过心跳检测判断是否在工作，如果secondary检测不到primary心跳，将认为primary已经死了，将资源抢夺过来进行调度。
heartbeat：每隔一秒或者半秒传递一次，能收到心跳，证明还活着。
HA和LB的区别：
LB有一定的高可用能力，但不是高可用集群，因为后台服务器没有heartbeat检测；LB是以提高服务的并发处理能力为着眼点，HA是以提升服务的始终在线能力为着眼点。
如果第3台主机挂了，调度器重新将请求分发给1和2，所以不会因为1台主机挂了而无法工作。
怎样让前端服务器知道后端服务器挂了，将不给它发送请求？
前端服务器对后端服务器有heartbeat check（健康检查）。
怎么去衡量可用性?在线时间/（在线时间+故障时间），一般我们使用的主机为99%。
nfs，共享存储设备，存储前端机共享的内容，并发能力有限。
第一个图，DAS存储方式，第一个服务器写入的时候，nfs通过锁告知第二个服务器，并拒绝第二个服务器写入，防止存储设备坏掉。
第二个图，NAS存储方式，一台服务器一个进程，同时向raid设备写入，先是在各自服务器上的内存写，再合并到共享设备，加入第一个服务器写入2行，第二个服务器删除10行，合并后会造成数据丢失。这样显然不好，需要通过fence机制进行管理。
当Vip访问集群时，集群中的一个节点将获取Vip，并与它进行通信，当为Vip服务的节点死机了，另外一个节点将获取Vip，继续为它服务，数据不会丢失。这样的弊端在于如果集群中的一个节点通信失效，那么集群中另外一个节点必须保证将已经失效的节点与正在访问的共享资源隔离开，才能重新获取Vip，出问题的集群节点本身没有这个功能，因为该集群在此时可能已经失去响应，处于半死不活状态，需要借助恐怖分子将它一枪爆头，死要死彻底，这就是通过fence机制来完成的。
两台主机间通过heartbeat检测是否还活着。