分布式缓存的详细设计
让我们了解分布式缓存的详细设计。
本课将找出分布式缓存高级设计的一些缺点，并改进设计以弥补这些不足。让我们开始吧。
查找并删除限制
在开始详细设计之前，我们需要了解并克服一些挑战：
- 缓存客户端无法感知缓存服务器的添加或失效。
- 该解决方案会遇到单点故障 (SPOF) 问题，因为我们为每组缓存数据设置了一个缓存服务器。不仅如此，如果任何一个缓存服务器上的某些数据被频繁访问（一般称为热键问题），那么我们的性能也会变慢。
- 我们的解决方案也没有突出缓存服务器的内部结构。也就是说，它会使用什么样的数据结构来存储，它会使用什么样的驱逐策略？
维护缓存服务器列表
让我们从解决第一个问题开始。我们将采取渐进的步骤来寻求最佳解决方案。让我们看看下面的幻灯片，以了解下面描述的每个解决方案：
方案一: 在每个服务器维护一个缓存客户端可以使用的配置文件
方案二: 在集中位置维护配置文件
方案三: 使用配置服务监视缓存服务器并保持缓存客户端更新
- 解决方案 1：可以在缓存客户端所在的每个服务主机中设置一个配置文件。配置文件将包含缓存客户端有效利用缓存服务器所需的更新后的运行状况和元数据。配置服务的每个副本都可以通过任何 DevOps 工具的推送服务进行更新。这种策略的主要问题是配置文件必须通过一些 DevOps 工具手动更新和部署。
- 解决方案 2：我们可以将配置文件存储在一个集中位置，缓存客户端可以使用该位置来获取有关缓存服务器的更新信息。这解决了部署问题，但我们仍然需要手动更新配置文件并监控每个服务器的健康状况。
- 解决方案 3：一种自动处理该问题的方法是使用持续监控缓存服务器健康状况的配置服务。除此之外，当一个新的缓存服务器被添加到集群时，缓存客户端将得到通知。当我们使用这种策略时，如果出现故障或添加新节点，则不需要人为干预或监控。最后，缓存客户端从配置服务中获取缓存服务器列表。
相关信息
配置服务的运营成本最高。同时，这是一个复杂的解决方案。但是，它是我们提供的所有解决方案中最强大的。
提高可用性
第二个问题与缓存服务器出现故障时缓存不可用有关。一个简单的解决方案是添加副本节点。我们可以从在缓存分片中添加一个主节点和两个备份节点开始。对于副本，总是存在不一致的可能性。如果我们的副本非常接近，则同步执行写入副本以避免分片副本之间的不一致。在分片之间划分缓存数据至关重要，这样既不会出现不可用问题，也不会浪费任何硬件。
该解决方案有两个主要优点：
- 在发生故障时提高了可用性。
- 热分片可以有多个节点（主要-次要）用于读取。
这样的解决方案不仅会提高可用性，还会增加性能。
缓存服务器的内部结构
每个缓存客户端应该使用三种机制来存储和从缓存服务器中逐出条目：
- 哈希映射：缓存服务器使用哈希映射来存储或定位缓存服务器 RAM 中的不同条目。下图显示映射包含指向每个缓存值的指针。
- 双向链表：如果我们必须从缓存中逐出数据，我们需要一个链表，以便我们可以根据访问频率对条目进行排序。下图描述了如何使用双向链表连接条目。
- 驱逐政策：驱逐政策取决于应用程序要求。在这里，我们假设最近最少使用 (LRU) 驱逐策略。
下面提供了分片集群以及节点数据结构的描述：
提示
从上面的解释中可以明显看出我们不提供deleteAPI。这是因为驱逐（通过驱逐算法）和删除（通过 TTL 的过期条目）是在缓存服务器本地完成的。delete然而，可能会出现需要 API 的情况。例如，当我们从数据库中删除一个最近添加的条目时，为了一致性，它应该导致从缓存中删除项目。
详细设计
在解决了之前突出显示的三个问题中的每一个之后，我们现在准备好正式确定详细设计。看下面的详细设计：
让我们将建议的详细设计总结为几点：
- 客户端的请求通过缓存客户端所在的负载均衡器到达服务主机。
- 每个缓存客户端使用一致的哈希来标识缓存服务器。接下来，缓存客户端将请求转发给维护特定分片的缓存服务器。
- 每个缓存服务器都有主服务器和副本服务器。在内部，每个服务器都使用相同的机制来存储和清除缓存条目。
- 配置服务确保所有客户端看到缓存服务器的更新且一致的视图。
- 监控服务还可用于记录和报告缓存服务的不同指标。
提示
设计的一个重要方面是缓存条目是从 RAM 中存储和检索的。在上一课中，我们讨论了 RAM 是否适合设计缓存系统。
警告
问题
虽然一致性哈希是一个不错的选择，但它可能会导致数据分布不均，并且某些服务器可能会过载。我们如何解决这个问题？
答案
随着时间的推移，已经提出了许多一致的散列算法风格。我们可以使用一种这样的风格（在这里使用）来均匀分布负载，甚至在不同的缓存服务器上制作相同数据的多个副本。每个缓存服务器内部都可以有虚拟服务器，一台机器中虚拟服务器的数量取决于机器的能力。这样可以更好地控制缓存服务器上的负载量。同时，它提高了可用性。