Caching and Load Balance

缓存Caching

缓存是在缓存中存储数据的过程。高速缓存是一个临时存储区域，其大小相对较小，具有更快的访问时间。每当应用程序必须读取数据时，它都应首先尝试从缓存中检索数据。 而当在缓存中找不到该数据时，它才应尝试从数据存储中获取数据。缓存可以改善延迟，并可以减少服务器和数据库上的负载。

缓存可以有不同的级别：

1. Client Caching 缓存可以位于客户端（本地），比如OS，浏览器，类似客户端的服务端例如反向代理等。
2. CDN Caching CDN(Content Delivery Network)也可以用作缓存，位于服务器和客户端之间，CDN常用来缓存静态文件例如HTML，CSS，JavaScript，图片和视频等。
3. Web Server Caching Web服务器也可以作缓存，返回responses而不必连接到app服务器。
4. Database Caching 数据库在默认配置中包含一定程度的缓存，这些配置针对常用的情况进行了优化。可以对这些配置进行调整，以提高特定用例的性能。
5. Application Caching 在应用程序中，缓存位于应用程序和数据存储之间。这些缓存基本上是内存中的键值存储，例如Memcached和Redis。 由于这些数据保存在RAM中，因此它比将数据存储在磁盘上的典型数据库快得多。这也需要主要关注的缓存类型。

在应用程序缓存中，有两种缓存数据的模式：

1. 缓存数据库查询：这是最常用的缓存模式。每当查询数据库时，都将结果数据集存储在缓存中。每个结果数据集都将查询的哈希版本作为缓存键。每次运行查询时，首先要检查cache-key是否已在缓存中。 如果需要查询的结果在缓存中，则从返回，否则再从数据库中获取结果，并将结果数据集存储在缓存中以供将来查询。 这种模式的主要问题是缓存失效。缓存复杂的查询结果时，很难使缓存的结果无效。当一条数据发生更改（例如，表行）时，需要使所有包含该行的缓存查询无效，以获得更新的查询。
2. 缓存对象：在对象缓存模式中，将数据存储为对象，就像在应用程序代码（类，实例等）中一样。类可以从数据库中组合一个数据集，然后可以将该类的实例或组合的数据集存储在缓存中。 可以缓存的对象的一些示例是sessions，完全渲染的网页，activity streams，用户图数据等等。

由于缓存数据存储在内存中，并且内存的大小比磁盘小很多多，所以为了更好地利用缓存，我们需要以优化的方式更新缓存，以便其存储更多相关数据并删除其他数据，也就是更新缓存。 高速缓存CPU Caching更新数据是一个难题，与何时更新高速缓存相关的其他复杂性也很高，所以应该选择不同的缓存更新策略。

缓存模式 Cache-Aside

这是应用程序中最常用的缓存更新策略。在此更新策略中，缓存位于一边，应用程序直接与缓存和数据库进行对话。也称为延迟加载。 应用程序逻辑先访问高速缓存，然后再访问数据库。它主要用于工作负载繁重的应用程序。

应用程序做的工作包括：

• 应用程序检查缓存中的数据
• 如果在缓存中找到了数据，则表示是命中缓存，这时候从缓存中读取数据并返回给客户端。
• 如果在缓存中找不到数据，则表示缓存未命中，应用程序将从数据库中读取数据，将数据副本存储在缓存中，然后将其返回给客户端。

这样做的好处：

• 应用程序即使在缓存失败后也可以工作，但是由于必须从数据存储中获取所有数据，因此性能会降低。
• 由于延迟加载，仅缓存了请求的数据，这避免了用未请求的数据填充缓存。

坏处：

• 每个cache miss次数通常为3次，可能会引起明显的延迟。
• 在备用缓存策略中，数据直接写入数据存储中，这会使缓存数据过时。可以通过使用TTL强制在TTL过期后更新数据或通过使用缓存更新策略来缓解这种情况。
• 将新节点添加到系统后，由于缓存将清空并且大多数查询将导致缓存丢失，因此会增加延迟。

通读Read-Through

Read-Through与Cache-Aside，非常相似，只是前者并非同时管理数据库和缓存，而是将数据库同步委托给缓存提供给应用程序。Read-Through与Cache-Aside相同点是都在第一次读取时延迟加载数据。

尽管Read-Through和Cache-Aside非常相似，但是它们有两个主要区别：

• 在Cache-Aside中，应用程序负责从数据库中获取数据并填充缓存。在Read-Through中，独立的库或缓存相关程序通常负责上述工作。
• 与Cache-Aside不同，Read-Through中的数据模型需要与数据库的数据模型相同。

Read-Through也最适合于繁重的工作负载，具有与Cache-Aside相似的优缺点。

Write-Behind

Write-Behind有时也称为回写式高速缓存策略，首先将数据写入高速缓存，然后将数据异步更新到数据库中，从而提高了写入性能。

Write-Behind策略中，应用程序的作用是：

• 添加/更新cache中的条目(entry)
• 异步将条目写入数据库，异步可以提高性能

Write-Behind策略通常用于写入任务中的应用程序。

优点：

• Write-Behind提升写操作的performance 缺点：
• 如果将数据写入数据库之前，缓存发生故障，则有可能造成数据丢失
• Write-Behind cache跟别的集中缓存实现策略比较，实现的困难比较大

Refresh-Ahead

Refresh-ahead缓存策略，它会在过期之前自动刷新任何最近访问的缓存。如果缓存可以准确地预测将来可能需要哪些项目，则采用Refresh-ahead可以减少延迟。

优点：

• 提前刷新可以大大降低延迟 缺点：
• 如果预测不准确会导致项目性能下降

负载均衡 Load Balance

Load Balancing

负载均衡是在多个服务器之间有效分配网络流量的过程。通过负载均衡，可提高响应速度并提高应用程序的可用性。随着应用程序变得越来越复杂，用户需求增长以及流量增加，负载均衡已成为一种必须品。

负载均衡是扩展应用程序服务器基础结构的最直接的方法。随着应用程序需求的增加，可以轻松地将新服务器添加到资源池，并且负载均衡器(Load Balancer)将立即开始向新服务器交换流量。

Load Balancer

负载均衡器Load Balancer是一种在服务器集群之间分配流量的设备或软件。负载均衡器充当“交通警察”，位于客户端和服务器之间，接受传入的网络和应用程序流量以及跨多个能够满足这些请求的后端服务器的路由请求。 通过在多个服务器之间平衡请求，负载均衡器可以减少单个服务器的负载，并防止任何一台应用程序服务器成为单点故障。

Load balancer特征：

• 如果单个服务器出现故障，负载均衡器将从服务器集群中删除该服务器，并将流量重定向到其余的联机服务器
• 将新服务器添加到服务器集群后，负载均衡器将自动开始向其发送请求
• 跨多个服务器有效地分配客户端请求或网络负载
• 通过仅向联机的服务器发送请求来确保高可用性和可靠性
• 提供根据需求添加或减少服务器的灵活性
• 可以添加到应用程序堆栈中的多个层级（应用程序服务器，数据库，缓存等）
• 可以在不中断现有连接的情况下动态地从组中添加或删除服务器

在将请求路由到多个服务器时，负载均衡器基于两个因素选择服务器：1）确保它们选择的服务器正在响应；2）根据运行状况良好的服务器集中的预配置算法选择一个服务器。

健康检查Health Checks

为了确保负载均衡器只将流量转发到正常运行的服务器，Health Checks会定期尝试连接到后端服务器，以确保服务器正在侦听。如果服务器无法通过Health Checks，则会自动将其从集群中删除，直到再次响应运行状况检查，流量才会转发到该服务器。

Load Balancing算法

Load Balancing算法包括：

1. Round Robin轮询 — 负载均衡器收到请求后，会将请求分配给列表中的第一台服务器，然后将该服务器移至列表的底部。
2. Least Connections最少的连接 — 新请求发送到的服务器，是与客户端的当前连接最少的。每个服务器的相对计算能力可以一定程度上确定在哪个服务器连接最少。
3. Least Response Time最短响应时间 — 将流量以定向到有最少的活动连接和最短的平均响应时间的服务器。
4. Least Bandwidth Method最小带宽方法 — 当前服务流量最少的服务器，以每秒兆位（Mbps）为单位。
5. IP Hash：客户端的IP用于确定哪个服务器接收到请求。

Session persistence/Sticky Session

Session持久性是某些商业负载平衡器的功能，它们将对特定Sessions的所有请求路由到为该Session第一个请求提供服务的同一台物理计算机上，以提高性能。 例如，当一台服务器在其缓存中存储用户请求的信息以提高性能时，下次同样的请求可以去同样的服务器，但如果换服务器将导致性能低下，这时候就可以用session持久化了。

Load Balancer功能

L4 Load Balancer：根据来自网络和传输层协议（例如IP地址和TCP端口）的数据引导流量。

L7 (Load balancing and Content Switching) Load Balancer：根据应用程序层数据和属性（例如HTTP header，URI，SSL session ID和HTML表单数据）做出路由决策。

GSLB (Global Server Load Balancing)：扩展了上面L4和L7功能，以便可应用于地理上分散的服务器集群。

硬件Load Balancer vs 软件Load Balancer

Hardware Load balancer运行装入计算机的专有软件，该计算机通常使用专用处理器进行优化。

• 难以扩展，因为随着负载的增加我们需要添加更多的硬件
• 由于购买和维护物理负载平衡器的高昂成本，因此非常昂贵。另外需要专业人员进行维护和安装。
• 物理硬件，安全性很高

Software Load Balancer通常在较便宜，它可以在公共或私有云中的任何位置安装和运行。

• 软件层面上运行而较便宜
• 只需运行负载均衡器实例，可轻松扩展
• 可以根据不断变化的需求进行灵活调整
• 可以在任何地方运行
• 一些基于智能软件的负载均衡器提供了可确定流量瓶颈的预测分析。

冗余Redundant load balancers

负载均衡器本身也可能成为单点故障。为了避免单点故障，可以在同一集群中的不同物理机上添加多个负载均衡器，如果主负载均衡器发生故障，则别的负载均衡器可以接管。