面试题答案
一键面试1. 数据结构
- Memcached：
- 仅支持简单的 key - value 结构，结构单一。在社交平台场景中，对于复杂用户信息（如包含多种属性的用户对象）存储，若使用Memcached需将对象序列化为字符串存储，读取时再反序列化，操作不便且效率低。
- 对于消息缓存，若需按特定规则（如按用户ID、时间等）进行复杂检索，简单的 key - value 结构难以满足。
- Redis：
- 支持丰富的数据结构，如字符串（string）、哈希（hash）、列表（list）、集合（set）、有序集合（zset）等。在用户信息缓存中，可使用哈希结构将用户不同属性（如姓名、年龄、性别等）作为字段存储，方便读取和修改特定属性。
- 对于消息缓存，列表结构可实现消息队列功能，支持先进先出；有序集合可按消息时间戳等排序，便于按顺序获取消息。热点内容缓存可使用集合结构去重，保证热点内容不重复。
2. 读写性能
- Memcached：
- 读写性能极高，在简单 key - value 读写场景下，内存操作速度快，非常适合高并发的读多写少场景。在社交平台热点内容缓存读取场景中，由于内容相对固定，读操作频繁，Memcached能快速响应大量读请求。
- 但由于其不支持持久化（默认），重启后数据丢失，在需要数据持久化保障的场景（如重要用户信息、关键消息）适用性差。
- Redis：
- 读写性能也很出色，虽然在简单 key - value 读写上稍逊于Memcached，但由于其丰富的数据结构操作，实际应用场景下整体性能表现良好。
- 支持持久化（RDB和AOF），数据可靠性高。对于用户信息缓存，即使系统重启，数据依然存在。但持久化操作会在一定程度上影响性能，尤其是AOF的频繁写入日志。
3. 集群模式
- Memcached：
- 原生不支持集群，需要通过客户端实现分布式，如一致性哈希算法。这种方式在节点添加或删除时，数据迁移复杂，可能导致大量数据重新分布，影响系统稳定性。在社交平台大规模扩展时，管理难度较大。
- Redis：
- 从3.0版本开始支持集群模式（Redis Cluster），采用哈希槽（hash slot）方式管理数据分布，节点添加或删除时，数据迁移相对简单，能够自动完成部分数据的重新分布。更适合社交平台随着用户量和数据量增长的水平扩展需求。
4. 数据一致性
- Memcached：
- 本身不支持数据一致性保障机制，当涉及多副本缓存时，数据同步较难处理，可能出现数据不一致问题。在社交平台不同缓存节点存储相同用户信息副本时，更新操作可能导致部分节点数据未及时更新。
- Redis：
- 在单节点下能保证强一致性。在集群模式下，通过一定的同步策略（如异步复制），可实现最终一致性。虽然不能像单节点那样完全保证强一致性，但在大多数社交平台场景下，最终一致性是可接受的，并且Redis提供了一些机制（如Sentinel）来监控和保证数据可用性和一致性。
综合缓存方案设计建议
- 用户信息缓存：
- 主要使用Redis，利用其哈希结构存储用户详细信息，利用持久化保证数据可靠性。对于部分不重要且访问频繁的用户信息子集（如用户头像URL等），可考虑在Memcached中缓存，以提高读性能。
- 消息缓存：
- 使用Redis，利用其列表或有序集合结构实现消息的存储和按序读取等功能。同时利用持久化保证消息不丢失。对于实时性要求极高且允许少量消息丢失的场景（如一些不重要的推送消息），可结合Memcached的高性能读写优势，在Memcached中短暂缓存。
- 热点内容缓存：
- 优先使用Memcached，因其简单高效的 key - value 结构和极高的读性能，非常适合热点内容这种读多写少且对数据一致性要求不高的场景。同时，可定期将热点内容持久化到Redis中，以防Memcached重启导致数据丢失。在热点内容更新时，先更新Redis，再更新Memcached，以保证数据一致性。
通过这样的方案，结合Memcached和Redis的优势，满足社交平台不同业务场景下的缓存需求，提高系统整体性能和可靠性。