目前，我正在运行一个包含 4 个专用 memcached 服务器的生产环境，每个服务器都有 48Gb 的 RAM（其中 42 个专用于 memcache）。目前它们运行良好，但流量和内容正在增长，明年肯定也会增长。
您对进一步扩展 memcached 的策略有何看法？到目前为止，您做得如何：
您是否会向这些设备添加更多 RAM，直到其容量达到最大 - 从而有效地将相同数量的设备中的缓存池加倍？或者您是否会通过添加更多具有相同 RAM 数量的相同设备来进行水平扩展。
当前的盒子肯定可以处理更多 RAM，因为它们的 CPU 负载相当低，唯一的瓶颈是内存，但我想知道分配缓存是否是一种更好的策略，使事情更加冗余，并最大限度地减少丢失一个盒子对缓存的影响（丢失 48Gb 缓存而不是丢失 96Gb）。您将如何（或让您）处理这个决定。
答案1
我非常想知道您正在移动的是什么，它会消耗超过 100 GB 的内存，但又不会超出您的 NIC 的最大容量。
Memcache 在机器之间的扩展相当线性，因此您需要问的问题是：
- 我的系统总线目前是否已饱和？
- 这可能与 CPU 使用率无关——DMA 传输不会显示这种情况
- 与增加内存容量的新盒子相比，高密度内存有多贵？
- 机架空间、电力消耗等的全部成本。
- 您是否发现 1% 的时间内丢失 25% 的缓存和 2% 的时间内丢失 12.5% 的缓存之间存在根本区别？（随机选择的故障率）。
扩展取决于 10% 的直觉、70% 的测量和调整以及 20% 的回头尝试其他方法。
不断加载它们，直到它们耗尽最薄弱的环节或不再具有成本效益。它们可能已经存在，也可能尚未存在。
答案2
当我这样做时，点箱大小（机架空间成本）、高密度芯片费用和故障场景处理之间通常会达到收支平衡。这几乎总是导致配置低于最大内存密度（并且通常不是最快的芯片），正如您所提到的，这可以改善节点故障的影响，并且通常使它们更具成本效益。做出此选择时需要考虑的一些成本/事项：
- 节点成本（cpu/mem/etc）
- 机架空间成本
- 管理费用/成本
- 失败场景（您想做 N+1 吗？）
随着集群的扩大（通常是在集群非常小的时候），我也对盒子进行了升级以达到最大容量，因为在扩展时购买更多的内存在短期内可能会便宜得多，从而让您有更多时间做出更大的架构决策。