面试题：复杂分布式系统下消息队列与多种中间件深度集成的架构设计

消息队列：选择 Kafka 或 RabbitMQ 作为消息队列。Kafka 适合高吞吐量场景，RabbitMQ 适合对可靠性要求极高、低延迟的场景。消息队列作为整个架构的核心枢纽，接收来自各个业务模块（如订单创建、商品更新等）产生的消息。
缓存（Redis）：用于存储热点数据，如商品详情、用户信息等。可以采用集群模式部署，以提高可用性和读写性能。
数据库（MySQL）：作为持久化存储，保存系统的核心业务数据。采用主从复制架构，主库负责写操作，从库负责读操作，提升读写性能和可用性。
搜索中间件（Elasticsearch）：用于全文搜索功能，存储商品信息、订单信息等数据的索引。采用多节点集群部署，提升搜索性能和可用性。

消息产生：业务模块（如用户下单）产生消息，发送到消息队列。
消息处理：
- 缓存更新：消息队列的消费者接收到消息，首先判断是否与缓存数据相关。如果相关，根据消息内容更新 Redis 缓存。例如，商品价格更新消息，消费者更新 Redis 中对应的商品价格。
- 数据库操作：接着，根据消息类型进行数据库操作。对于订单创建消息，在 MySQL 中插入订单记录。
- 搜索索引更新：最后，针对需要搜索的数据，更新 Elasticsearch 索引。比如，新商品上架消息，更新 Elasticsearch 中的商品索引，以便用户能搜索到。

消息队列：
- Kafka：通过多副本机制，每个分区有多个副本，其中一个为 leader，其余为 follower。leader 负责读写，follower 负责同步数据。当 leader 故障时，从 follower 中选举新的 leader，保证消息的正常生产和消费。
- RabbitMQ：采用镜像队列模式，将队列的元数据和消息复制到多个节点，保证即使某个节点故障，队列依然可用。
缓存（Redis）：使用 Redis Cluster，数据自动分片存储在多个节点上，每个节点有自己的主从副本。当某个主节点故障时，从节点会自动提升为主节点，保证缓存服务的可用性。
数据库（MySQL）：主从复制架构中，从库实时同步主库数据。当主库故障时，通过 MHA（Master High Availability）等工具，自动将某个从库提升为主库，保证数据库服务的连续性。
搜索中间件（Elasticsearch）：多节点集群部署，每个索引分片有多个副本，分布在不同节点上。当某个节点故障时，副本会自动承担故障节点的工作，保证搜索服务的可用性。

缓存与数据库一致性：
- 先更新数据库，再更新缓存：在消息处理时，先进行数据库操作，成功后再更新缓存。但可能存在数据库更新成功，缓存更新失败的情况，此时可以通过重试机制，多次尝试更新缓存。
- 设置缓存过期时间：即使缓存数据暂时不一致，通过设置合理的过期时间，保证最终一致性。
数据库与搜索中间件一致性：通过消息队列保证数据顺序性，先更新数据库，成功后再更新 Elasticsearch 索引。同时，建立重试机制，对于索引更新失败的情况进行重试。

消息丢失风险：
- 原因：消息队列故障、消费者处理失败未重试等。
- 应对策略：在消息队列中开启持久化机制，确保消息不丢失。消费者处理消息时，采用事务机制，保证消息处理的原子性，处理失败时进行重试。
缓存雪崩风险：
- 原因：大量缓存数据同时过期，导致大量请求直接访问数据库。
- 应对策略：设置随机的缓存过期时间，避免大量数据同时过期。采用二级缓存，一级缓存失效时，从二级缓存获取数据，减轻数据库压力。
数据库主从延迟风险：
- 原因：主库写操作频繁，从库同步延迟。
- 应对策略：监控主从延迟，当延迟过大时，调整主从复制参数，如增加从库数量、优化网络等。对于对数据一致性要求极高的业务，从主库读取数据。
Elasticsearch 索引不一致风险：
- 原因：网络故障、索引更新失败等。
- 应对策略：建立索引更新监控机制，及时发现索引不一致问题。采用重试机制和数据补偿机制，确保索引数据的一致性。

星途面试题库