分布式架构和Redis面试题

kevindanglu

已于 2025-03-13 21:38:02 修改

阅读量658

点赞数 25

分类专栏： Redis 分布式面试文章标签：分布式架构 redis

于 2025-03-12 15:18:43 首次发布

本文链接：https://blog.youkuaiyun.com/u011911672/article/details/146202536

版权

面试同时被 3 个专栏收录

5 篇文章

订阅专栏

Redis

1 篇文章

订阅专栏

分布式

1 篇文章

订阅专栏

Redis在分布式架构中应该怎么设置高可用或者集群方式

分布式架构设计中的常见挑战

1. 网络通信与不可靠性

挑战：网络延迟、丢包、分区（如脑裂问题）可能导致服务调用失败或数据不一致。
应对策略：
- 超时与重试机制：设置合理的超时时间（如Hystrix、Resilience4j），结合退避策略（如指数退避）避免雪崩。
- 异步通信：使用消息队列（如Kafka、RocketMQ）解耦服务，确保最终一致性。
- 健康检查与服务熔断：通过熔断器（如Hystrix）隔离故障节点，防止级联故障。

2. 数据一致性与事务管理

挑战：分布式事务的ACID难以保证，CAP定理下需权衡一致性与可用性。
应对方案：
- 强一致性：使用分布式事务框架（如Seata）实现两阶段提交（2PC），但性能较低。
- 最终一致性：通过TCC（Try-Confirm-Cancel）模式、Saga模式或事件溯源（Event Sourcing）补偿事务。
- 数据库中间件：利用ShardingSphere分库分表，结合柔性事务（如BASE理论）。

3. 服务发现与负载均衡

挑战：动态扩缩容时如何自动发现服务实例并合理分配流量。
解决方案：
- 服务注册中心：集成Eureka、Consul、Nacos等实现服务注册与发现。
- 客户端负载均衡：通过Ribbon或Spring Cloud LoadBalancer选择策略（轮询、加权、最少连接）。
- 服务网格：采用Istio或Linkerd，通过Sidecar代理透明化管理流量。

4. 容错与高可用

挑战：节点故障、资源竞争或依赖服务宕机导致系统不可用。
容错设计：
- 冗余部署：多副本（如Kubernetes Pod副本）和跨机房容灾。
- 降级与限流：使用Sentinel或Resilience4j实现流量控制、熔断降级。
- 幂等性设计：保证接口重复调用结果一致（如唯一ID+数据库去重）。

5. 系统性能与扩展性

挑战：高并发下响应延迟、资源竞争（如数据库连接池瓶颈）。
优化手段：
- 缓存策略：本地缓存（Caffeine）、分布式缓存（Redis）减少DB压力。
- 异步处理：线程池（如CompletableFuture）、反应式编程（WebFlux）提升吞吐量。
- 水平扩展：无状态服务设计，通过Kubernetes自动扩缩容。

6. 分布式追踪与监控

挑战：跨服务调用链路复杂，问题定位困难。
工具链：
- 链路追踪：集成SkyWalking、Zipkin或OpenTelemetry，可视化调用链路。
- 日志聚合：ELK（Elasticsearch+Logstash+Kibana）或Loki+Prometheus+Grafana。
- 指标监控：Micrometer对接Prometheus，监控JVM、HTTP请求等指标。

7. 配置管理与安全

挑战：多环境配置动态更新、服务间通信安全。
方案：
- 配置中心：使用Spring Cloud Config、Nacos或Apollo实现配置动态下发。
- 安全通信：TLS/SSL加密、OAuth2/JWT鉴权（Spring Security），服务间mTLS双向认证。
- 密钥管理：集成Vault或KMS保护敏感信息。

8. 部署与运维复杂度

挑战：多环境发布、灰度发布、回滚策略。
DevOps实践：
- 容器化：Docker镜像打包，Kubernetes编排管理（如滚动更新、蓝绿部署）。
- CI/CD流水线：Jenkins、GitLab CI自动化构建与测试。
- 混沌工程：模拟故障（如ChaosBlade）验证系统健壮性。

9. 数据分区与分片

挑战：数据分布不均导致热点问题，跨分片查询效率低。
设计要点：
- 分片策略：范围分片（如按时间）、哈希分片（一致性哈希）或混合策略。
- 全局索引：通过二级索引（如Elasticsearch）加速查询。
- 数据迁移：在线扩容时保证数据平滑迁移（如Vitess）。

10. 团队协作与技能要求

挑战：分布式系统开发需要团队具备微服务、云原生等综合能力。
应对：
- 标准化框架：统一技术栈（如Spring Cloud Alibaba、Quarkus）。
- 文档与知识库：维护架构设计文档、故障处理手册。
- 培训与演练：定期技术分享、故障复盘。

总结

Java分布式架构设计需在可靠性、性能、一致性之间寻求平衡，结合成熟中间件（如Spring Cloud生态、Apache项目）和云原生技术（Kubernetes、Service Mesh），同时重视可观测性与自动化运维。通过分层设计（如DDD领域驱动）、模块化拆分（微服务粒度）及持续迭代优化，逐步构建高可用的分布式系统。

Redis在你们项目中的应用场景

缓存热门数据

股票信息：对于热门股票的基本信息，如股票代码、名称、当前价格、涨跌幅等，它们会被频繁访问。把这些数据存于 Redis 中，能够显著减少对数据库的查询次数，提升响应速度。举例来说，当众多用户同时查询某只热门股票的信息时，可直接从 Redis 里获取，避免了数据库的高并发查询压力。
重大财经新闻信息

排行榜和统计数据

涨幅榜、跌幅榜：证券投资网站通常会展示涨幅榜、跌幅榜等排行榜数据。可以将这些数据存储在 Redis 的有序集合（Sorted Set）中，按照涨幅或跌幅对股票进行排序。当需要展示排行榜时，直接从 Redis 中获取排名靠前的股票信息，提高数据查询和展示的效率。
成交量统计：统计每只股票的成交量是证券投资分析的重要指标之一。使用 Redis 的计数器功能，可以实时记录每只股票的成交量，并定期将数据持久化到数据库中。这样，在需要查询成交量统计数据时，可以快速从 Redis 中获取最新的统计结果。

缓存：这是 Redis 最常见的使用场景之一。通过将频繁访问的数据存储在 Redis 中，可以显著减少数据库的负载并提高应用的响应速度。例如，网页内容、查询结果等都可以被缓存起来。
会话存储：在分布式Web应用中，使用 Redis 来集中存储用户的会话信息是一个不错的选择。这使得用户可以在不同服务器间无缝切换而不会丢失会话状态。
实时分析：由于 Redis 支持快速读写操作，因此非常适合用于实时分析场景，比如记录网站的点击数、在线用户数量、用户行为统计等。
排行榜/计数器：利用 Redis 的有序集合特性，可以轻松实现排行榜功能。同时，也可以用来实现各种计数器应用，如社交网络中的点赞数、评论数等。
消息队列：Redis 提供了发布/订阅模式以及阻塞队列的功能，使其能够作为轻量级的消息队列系统来使用，适用于异步任务处理等场景。
地理位置应用：Redis 支持地理空间(GEO)数据类型，可以用来存储地理位置信息，并进行距离计算、查找附近位置等操作，非常适合基于位置的服务(LBS)应用。
分布式锁：在分布式环境中，Redis 可以用作分布式锁服务，确保多个节点之间对共享资源的安全访问。
限流：通过 Redis 实现限流算法（如令牌桶算法或漏桶算法），可以帮助保护应用免受突发流量的影响，保证系统的稳定性。

Redis的Key过期策略有哪些

定时过期

原理：为每个设置了过期时间的键都创建一个定时器，当键的过期时间到达时，立即执行对该键的删除操作。
优点：可以保证过期键会在过期时间一到就被马上删除，内存释放及时，能节省内存空间。
缺点：会占用大量的 CPU 资源。因为要为每个设置了过期时间的键都创建定时器，当过期键较多时，定时器的维护和执行会消耗大量的 CPU，影响 Redis 的整体性能，尤其是在高并发场景下，这种影响会更加明显。
适用场景：适用于对内存要求极高，且过期键数量较少的场景。

惰性过期

原理：不主动删除过期键，而是在访问某个键时，才检查该键是否过期。如果过期则删除该键并返回空结果；若未过期则正常返回键的值。
优点：对 CPU 资源友好，不会在过期键的删除上主动消耗 CPU，只有在真正访问到过期键时才会进行处理。
缺点：会造成一定的内存浪费。因为即使键已经过期，但如果一直没有被访问，就不会被删除，这些过期键会一直占用内存空间。
适用场景：适用于对内存使用要求不是特别严格，且对 CPU 性能较为敏感的场景。

定期过期

原理：Redis 每隔一段时间（默认是 100ms）就从设置了过期时间的键中随机抽取一部分，检查这些键是否过期，并删除其中过期的键。抽取的频率和数量可以通过配置参数进行调整。
优点：是定时过期和惰性过期的一种折中方案，在一定程度上平衡了 CPU 资源和内存空间的使用。既不会像定时过期那样大量占用 CPU 资源，也不会像惰性过期那样造成过多的内存浪费。
缺点：如果过期键分布不均匀，可能会导致部分过期键在较长时间内无法被删除，仍然会占用一定的内存。而且定期过期的时间间隔和抽取数量的配置需要根据实际情况进行调整，如果配置不当，可能会偏向于定时过期（CPU 消耗大）或惰性过期（内存浪费多）。
适用场景：这是 Redis 默认的过期策略，适用于大多数场景。通过合理调整定期检查的频率和抽取的键数量，可以在 CPU 资源和内存空间之间取得较好的平衡。

Redis的内存满了有几种解决办法

通常来讲Redis 内存不足有这么几种处理方式：

配置Redis的maxmemory和淘汰策略：
- 设置 maxmemory 参数来限制 Redis 使用的最大内存量。
- 配置合适的键淘汰策略（通过 maxmemory-policy），例如：
  - volatile-lru：尝试移除最少使用的键，但仅限于设置了过期时间的键。
  - allkeys-lru：移除最少使用的键，不限制是否设置了过期时间。
  - volatile-ttl：尝试移除最近将要过期的键。
  - volatile-random：随机移除设置了过期时间的键。
  - allkeys-random：随机移除任何键。
  - noeviction：不进行驱逐（默认值），当内存使用达到最大限制时，写操作会返回错误。
数据持久化与恢复：
定期执行 RDB 快照或 AOF 日志记录，以便在必要时可以从磁盘恢复数据，同时也可以考虑删除一些旧的快照以释放空间。
优化现有数据结构：
- 压缩值数据：使用 Snappy、LZ4 压缩算法处理大文本（需客户端编解码）。
- 选择高效数据结构：
  - 用 Hash 替代多个 String（例如存储用户属性）。
  - 用 ZSET (ziplist编码) 替代多个 String + SORT。
  - 小数据集合启用 list-max-ziplist-entries 等配置，使用 ziplist 编码。
- 避免大Key：单 Key 大小超过 10KB 需拆分（如 HSCAN 分片存储）。
设置合理过期时间

强制数据生命周期：为临时数据（如会话、缓存）设置 TTL，避免无效数据堆积。

       SET session:token123 "{userid: 1001}" EX 3600  # 1小时后自动过期

动态调整过期时间：高频访问的数据可通过 EXPIRE 续期，冷数据自动淘汰。

5. 数据分级存储（冷热分离）

冷数据归档：
- 将低频访问数据迁移到磁盘数据库（如 MySQL）或低成本存储（如 S3）。
- 使用 SCAN + TTL 扫描识别冷数据（如最后访问时间超过30天）。
热数据保留：
高频数据保留在 Redis，通过定时任务同步冷热数据。

6. 增加内存：如果可能的话，可以通过升级服务器硬件来增加可用内

7. 使用Redis集群进行横向扩展

当单个实例无法满足需求时，可以考虑使用 Redis 集群，分散数据到多个节点上，以此扩大总的可用内存。

8. 清理不必要的数据：

定期检查并删除不再需要的数据，特别是那些已经过期的数据。可以通过设置合理的 TTL（Time To Live）来自动清除不需要的键。

9. 外部存储结合使用：

对于一些对响应时间要求不是特别高的数据，可以考虑将其存储到外部存储系统中，如关系型数据库或其他NoSQL数据库，并在需要时从这些系统中读取数据。

缓存与数据库数据不一致的典型场景分析

1. 缓存穿透导致的读写问题

场景描述：缓存穿透是指用户频繁请求一个数据库中不存在的数据，因为缓存中没有命中，而数据库查询返回的结果为空，缓存也没有存储该空值，导致每次请求都会打到数据库，给数据库带来巨大的压力。

解决方案：

缓存空结果：如果查询数据库没有结果，将空值也存入缓存，并设置较短的过期时间，避免短时间内再次查询相同的无效数据。
使用布隆过滤器：将所有合法的查询键放入布隆过滤器，当用户请求时，先通过布隆过滤器判断该数据是否可能存在，避免无效查询打到数据库。

2. 缓存击穿导致的数据不一致

场景描述：缓存击穿是指某个热点数据由于设置了过期时间，当缓存失效的瞬间，多个请求同时请求该数据，导致这些请求直接访问数据库，并且可能导致数据库压力过大。

解决方案：

互斥锁机制：通过分布式锁，确保同一时刻只有一个请求可以查询数据库并更新缓存，其他请求等待缓存更新完成后再读取缓存。
热点数据设置永不过期：对于高频访问的数据，可以设置其缓存永不过期，避免缓存失效的瞬间导致的击穿问题。

3. 缓存雪崩导致的缓存与数据库不一致

场景描述：缓存雪崩是指在某一时刻，缓存中的大量数据同时失效，导致大量请求直接打到数据库，可能导致数据库负载骤增甚至宕机。

解决方案：

设置不同的过期时间：为不同的缓存数据设置随机的过期时间，避免大量缓存同时失效。
双重缓存机制：使用本地缓存与 Redis 结合的方式，当 Redis 缓存失效时，可以从本地缓存中读取数据，减少对数据库的直接访问。

如何确保redis和数据库中的数据一致

1. Cache-Aside（旁路缓存）模式

这是最常见的缓存策略，也称为 Lazy Loading（惰性加载），缓存不自动更新，而是在读取时按需更新。

原理：
- 读取时，先查询缓存，如果缓存命中则直接返回数据。
- 如果缓存未命中，查询数据库，返回结果并将结果写入缓存。
- 写入时，先更新数据库，再删除缓存中的旧数据。

2. Read/Write-Through（直读/写模式）

流程：
- 所有写操作先更新缓存，再由缓存层同步写入数据库。
- 读操作直接读缓存（缓存即权威数据源）。
架构依赖：需封装统一的缓存代理层（如中间件）。
适用场景：写入量较低、强一致性要求的场景（如账户余额）。
缺点：写入性能较低（需双写），缓存故障会导致数据丢失。

3. Write-Behind（异步回写）

流程：
- 写操作先更新缓存，数据异步批量写入数据库（如通过队列）。
优点：写入性能高，适合写密集场景（如日志、点击量统计）。
风险：
- 数据丢失风险（缓存宕机时未持久化的数据会丢失）。
- 需结合WAL（Write-Ahead Log）或可靠消息队列（如Kafka）保证最终一致性。

4. 双删延迟策略（Double Delete）

优化场景：针对 Cache-Aside 模式的并发脏读问题。
流程：
1. 先删除缓存。
2. 更新数据库。
3. 延迟再次删除缓存（如通过消息队列延迟1秒）。
目的：清除在“更新数据库”期间可能被其他线程回填的旧数据。

5. 基于数据库日志的最终一致性

原理：通过监听数据库的变更日志（如MySQL Binlog、PostgreSQL WAL），实时同步到Redis。
工具链：
- Canal：解析MySQL Binlog，发送到消息队列（如RocketMQ）。
- Debezium：通用CDC（Change Data Capture）工具，支持Kafka Connect。
流程：
1. 数据库更新 → 2. Binlog 解析 → 3. 消息队列 → 4. 消费者更新Redis。
优点：解耦业务代码，保证最终一致性。
缺点：同步延迟（毫秒到秒级），不适用于强一致性场景。

6. 分布式事务（强一致性）

适用场景：金融交易等强一致性要求极高的场景。
方案：
- 2PC（两阶段提交）：通过事务协调器（如Seata）管理Redis和数据库的提交/回滚。
- Redis事务+数据库事务：
- 缺点：性能损耗大，Redis事务不支持回滚（仅取消命令队列）。

7. 版本号/时间戳控制

原理：为数据添加版本号或时间戳，更新时校验一致性。
实现：
- 数据库和缓存中存储数据的版本号。
- 更新时检查缓存中的版本号是否与数据库一致。

适用场景：高并发修改场景（如库存扣减）。

8. 补偿机制（自动修复）

原理：通过定时任务或监控工具检测不一致数据并修复。
实现：
1. 定时扫描：对比数据库和 Redis 的 Key，发现不一致时触发更新。
2. 消息队列重试：将失败的操作记录到死信队列，定期重试。
3. 缺点：修复延迟，仅适用于最终一致性场景。

策略选择建议

场景	推荐方案	一致性级别
读多写少（如商品详情）	Cache-Aside + 双删延迟	最终一致性
写多读少（如点击计数）	Write-Behind + 异步队列	最终一致性
金融交易（如支付）	分布式事务（2PC/Seata）	强一致性
高并发修改（如库存）	版本号控制 + 补偿机制	乐观锁最终一致性

关键注意事项

避免过度设计：根据业务需求选择一致性级别（非所有场景都需要强一致）。
监控与告警：
- 监控缓存命中率、同步延迟。
- 设置缓存与数据库差异的阈值告警。
降级方案：
- 缓存故障时，直接透传到数据库并限流。
压测验证：模拟高并发场景，测试策略的有效性。

通过组合以上策略（如 Cache-Aside + Binlog 监听 + 补偿任务），可在性能与一致性之间取得平衡。

Redis在分布式架构中应该怎么设置高可用或者集群方式

主从复制：一个主，一个或多个从，从节点在主节点复制数据。主节点负责写，从节点负责读。可以更好的分担主节点的压力，但是如果主节点宕机了，会导致部分数据不同步。
哨兵模式(重点)：也是一种主从模式，哨兵定时去查询主机，如果主机太长时间没有相应，多个哨兵就投票选出新的主机。提高了可用性，但是在选举新的主节点期间，还是不能工作。
Cluster集群模式：采用多主多从(一般都是三主三从)，按照规则进行分片，每台redis节点储存的数据不一样，解决了单机储存的问题。还提供了复制和故障转移功能。配置比较麻烦。