独立服务器上的 Redis 与 Memcached 对比：如何选择缓存
Redis 与 Memcached 都是内存缓存系统，但两者在数据结构、持久化能力和运营控制方面取向不同。在独立服务器上选择哪种缓存，会影响内存规划、失效处理、故障恢复，以及应用程序需要承担多少缓存逻辑。
最合适的缓存不一定是在合成基准测试中速度最高的一种。团队应先了解要存储的数据、应用程序如何读取及让数据失效、缓存未命中时的影响，以及独立服务器可以提供的资源。Redis 通常功能更完整；Memcached 则适合简单且可以重新生成的临时对象。
Redis 与 Memcached 的设计定位
缓存位于应用程序与较慢的数据来源（例如数据库或 API）之间。Redis 提供多种数据类型、可选的持久化及复制功能，按设计可以支持的不只是普通对象缓存。Memcached 是轻量的键值缓存，主要围绕短期数据、过期时间和淘汰机制运行；它通常被视为可以丢弃的缓存，而不是数据来源。
如需了解更广泛的缓存层，Dataplugs 的善用 Cache 内容缓存：提升网站加载速度文章说明对象缓存如何配合 CDN 及源服务器性能工作。
- Redis 可以存储字符串、列表、集合、有序集合、哈希及其他数据结构
- Redis 适合计数器、速率限制、工作队列、会话及经过审慎设计的协调流程
- Memcached 以键值存储不透明的数据，序列化及缓存未命中处理由应用程序负责
- 两者都可以减少重复的数据库工作，但除非有明确的恢复设计，否则不应视为可以取代持久数据
- 缓存未命中、数据被淘汰或服务重启时，应用程序必须有清晰的处理方式
Redis 更适合的情况
当缓存需要更丰富的操作，或团队可能需要持久化、副本及受控数据迁移时，Redis 通常更合适。它的数据结构可以把部分操作留在数据层完成，减少重复读取及应用程序自行维护的工作。不过，这种灵活性也代表更多设置、内存考虑及更大的运营范围。
如果 Redis 或 Memcached 是服务器调优方案的一部分，Dataplugs 的如何自定义您的洛杉矶独立服务器以获得最佳性能文章说明如何按应用程序工作负载配合 CPU、内存、存储及网络选项。
- 当应用程序需要的不只是每个键值对应一个不透明对象时，使用 Redis
- 当服务设计包括持久化或以副本恢复时，使用 Redis
- 对需要原生操作的计数器、排行榜、速率限制或类似队列的流程，使用 Redis
- 为复制缓冲区、持久化工作、内存碎片及故障切换预留内存
- 记录哪些 Redis 数据需要恢复，以及哪些数据可以在淘汰后重新生成
Memcached 更适合的情况
当应用程序只需要一个快速、分布式的序列化对象缓存，并且每个值都可以从持久数据来源重新生成时，Memcached 可以是一个合适的选择。它刻意保持简单，让缓存所有权及失效规则更容易理解，适合页面片段、数据库查询结果及短期会话数据。
如果网站流量会突然上升，Dataplugs 的优化资源分配以应对季节性网站流量高峰文章把缓存规划与 CPU、内存、存储、带宽及源服务器容量的测量联系起来。
- 当数据彼此独立、可以替换而且容易序列化时，使用 Memcached
- 当应用程序已有可靠的数据库或 API 作为后备时，使用 Memcached
- 在各个应用程序实例之间，保持项目大小、过期时间及命名空间规则一致
- 为服务重启、数据淘汰或节点更换后的冷缓存情况做好准备
- 如果丢失数据会使业务记录不一致，不要把该状态放在 Memcached
提示：如果数据可以丢弃，应先测量缓存未命中的成本，再决定是否需要持久化。如果缓存承载应用程序状态或协调工作流程，就应把 Redis 设置、备份及故障切换视为应用程序架构的一部分。
独立服务器上的 Redis 与 Memcached 资源规划
独立服务器可以为缓存提供较可预测的 CPU、内存、存储及网络资源，但如果架构没有分开角色，缓存仍会与应用程序及数据库竞争。Redis 支持更丰富的数据结构及可选持久化功能，按使用方式可能需要更多内存。Memcached 的内存模型较简单，但仍要计算 slab 分配、项目额外开支及预期工作集。
- 应使用命中率、未命中率、项目大小、淘汰率、命令延迟及高峰连接数规划服务。当 Redis 启用持久化、快照、日志或恢复副本时，NVMe 存储尤其值得考虑；对于临时性 Memcached 层，RAM 及网络表现通常比本地磁盘速度更重要。
- 按工作集加上内存碎片、缓冲区及故障切换余量规划 RAM
- 把缓存内存与数据库及应用程序进程所需的内存分开计算
- 以 CPU 及网络数据找出序列化、压缩或连接瓶颈
- 设置明确的内存上限及淘汰策略，不要让进程不受控制地占用主机资源
使用与正式流量相同的并发量及项目大小分布测试缓存
持久化、复制及故障规划
Redis 可以使用 RDB 快照、AOF 日志、不使用持久化，或按需要组合使用，取决于数据是否可以重新生成，以及重启后恢复的重要程度。Redis 复制一般是异步的，因此副本可能落后于主节点。恢复计划需要定义可接受的数据丢失、提升权限，以及客户端如何找到新的端点。
Memcached 通常在节点故障后，从数据库或其他来源重新建立。对于缓存来说这完全可以合理，但应用程序必须能够处理冷启动，并避免大量请求同时重新生成相同对象而形成惊群效应。请求合并、分阶段预热及有上限的重试都有助保护源服务。
- 先定义缓存是加速层、会话存储，还是有状态服务
- 在选择持久化或副本前，先订立恢复点及恢复时间目标
- 测试节点丢失、重启、整个缓存预热、故障切换及过期客户端连接
- 以请求合并、速率限制或后台刷新保护数据库免受缓存惊群影响
- 把备份及恢复副本放在故障节点以外，并测试还原流程
安全、监测及部署
Redis 及 Memcached 都不应直接暴露到公开互联网。应把服务绑定到私有接口、限制防火墙规则、按支持情况使用身份验证及加密，并把管理访问与应用程序流量分开。独立服务器提供设置这些边界的控制权，但仍需要由运营人员正确设置及维护。
监测应把缓存行为与业务及源系统的影响联系起来。高命中率未必代表数据没有过期、键值分布没有倾斜或网络没有饱和；低命中率也可能由 TTL 不合适、键值构建不一致或工作集超出内存造成。除了平均缓存响应时间，也应追踪淘汰原因及未命中的延迟。
- 追踪命中率、未命中率、淘汰、内存碎片、项目大小及命令延迟
- 监测源数据库负载，避免缓存重启变成一次非预期的数据库压力测试
- 为不同应用程序或环境使用独立命名空间及所有权规则
- 以可恢复方式推出设置变更，并准备排空或预热缓存的方法
- 记录缓存层的补丁、访问控制、告警负责人及事故处理流程
总结
当需要更丰富的数据结构、持久化、复制或原生协调功能，而且可以承担额外运营复杂度时，Redis 通常是更好的选择。当需求是简单、可丢弃的对象缓存，并且重视低开销、直接的失效处理及容易重新建立时，Memcached 往往更合适。在独立服务器上，选择应与内存上限、存储需求、网络设计、监测及恢复流程一并决定。
如需为缓存节点及应用程序服务器规划可预测的单租户资源，Dataplugs 的独立服务器方案提供可配置 CPU、内存、存储及网络选项。
如需了解更多，请访问 Dataplugs 或联系 sales@dataplugs.com。