Java高级 / 架构师 场景方案 面试题（一）

1.十万订单每秒热点数据架构如何优化？

优化的好处是：提高系统的吞吐量、响应速度和稳定性。以下是一些建议的优化方法：

水平扩展：

• 数据库分片：将数据库分成多个分片，每个分片存储一部分数据。这样可以分散数据库的读写压力，提高并发处理能力。
• 读写分离：将数据库的读操作和写操作分离到不同的服务器上，以提高并发性能。
• 负载均衡：使用负载均衡器（如Nginx、HAProxy等）来分散客户端的请求，使其均匀分布在多个服务器上。

缓存优化：

• 使用缓存系统：如Redis、Memcached等，将热点数据缓存在内存中，减少对数据库的访问压力。
• 缓存击穿与预热：避免缓存失效时的请求直接打到数据库上，可以通过设置缓存预热和缓存击穿防护策略来优化。
• 缓存降级：在缓存不可用时，可以设计降级策略，如返回默认值、使用备份数据源等。

数据库优化：

• 索引优化：为数据库表的关键字段建立索引，提高查询速度。
• 查询优化：避免使用复杂的SQL查询，减少数据库的压力。
• 数据库连接池：使用数据库连接池来复用数据库连接，提高数据库访问效率。

业务逻辑优化：

• 异步处理：将耗时较长的业务逻辑异步处理，如发送短信、邮件等，避免阻塞主线程。
• 限流与降级：在流量过大或系统压力过高时，通过限流策略保护核心资源，并通过降级策略保证系统的基本可用性。
• 分布式事务：在分布式系统中，采用合适的分布式事务解决方案，如TCC、Saga等，保证数据的一致性。

系统监控与告警：

• 监控系统：部署监控系统，实时监控系统的性能指标，如QPS、响应时间、错误率等。
• 告警系统：设置告警阈值，当系统性能指标达到阈值时，及时发送告警通知，以便快速响应和处理问题。

硬件与网络优化：

• 高性能硬件：选择高性能的服务器、存储和网络设备，提高系统的处理能力。
• 网络优化：优化网络架构，减少网络延迟和丢包率，提高数据传输效率。

注意：以上这些优化方法并不是孤立的，它们应该相互配合，形成一个完整的优化方案。同时，还需要根据具体的业务场景和需求，灵活调整和优化方案。

2.Redis集群崩溃时如何保证秒杀系统高可用

在Redis集群崩溃时，要保证秒杀系统的高可用性，可以采取以下几种策略：

主从复制：

• 将Redis数据设置为主从复制模式，其中一个Redis实例作为主节点，其他实例作为从节点。主节点的数据会同步到从节点，当主节点出现故障时，从节点可以接管服务，确保数据不丢失。在主从配置中，需要确保从节点的配置正确指向主节点。

使用Redis哨兵进行自动故障转移：

• Redis哨兵是一个监控Redis集群的组件，它可以检测主节点的状态。当主节点宕机时，哨兵可以自动将从节点切换成主节点，从而保证系统的可用性。哨兵的配置需要指定监控的主节点，并设置相应的故障转移策略。

设置Redis持久化机制：

• Redis支持两种持久化方式：RDB快照和AOF日志。通过配置适当的持久化策略，可以确保即使Redis宕机，也不会丢失太多数据。这样，在重启Redis后，可以尽快恢复数据，减少系统不可用时间。

配置Redis集群：

• 使用Redis集群可以将数据分布到多个节点上，从而提高系统的可用性和吞吐量。如果某个节点宕机，其他节点仍然可以正常工作，避免了单点故障的问题。在集群配置中，需要确保每个节点的配置正确，并且集群的槽位分配合理。

监控Redis运行状态：

• 定期检查Redis的运行状态，如CPU、内存、网络等指标，发现异常情况及时处理。通过监控可以及时发现系统瓶颈和潜在问题，从而采取相应的措施预防系统崩溃。

注意：虽然上述策略可以提高系统的可用性，但并不能完全避免Redis集群崩溃。在实际应用中，还需要结合业务需求和技术架构，采取其他措施来确保秒杀系统的高可用性，如使用负载均衡、限流降级等策略来分散请求压力，以及备份和恢复策略来保障数据的完整性。 

3.Redis主从切换导致库存同步异常以及超卖问题

Redis主从切换可能导致库存同步异常以及超卖问题，这主要是因为主从数据不一致和读取过期数据。以下是一些可能导致这些问题的原因和相应的解决方法：

主从数据不一致

主从数据不一致是指在主从切换过程中，从库中的数据与主库中的数据不一致。这可能是由于主从库间的命令复制是异步进行的，以及网络延迟或从库处理其他高复杂度命令导致的。

解决方法：

• 优化网络连接：尽量保证主从库间的网络连接状况良好，避免网络延迟导致的数据不一致。
• 监控复制进度：开发一个外部程序来监控主从库间的复制进度，确保从库能够及时同步主库的数据。

读取过期数据

在使用Redis主从集群时，有时可能会读到过期数据，这也会导致库存同步异常和超卖问题。

解决方法：

• 设置合理的过期时间：根据实际情况设置合理的数据过期时间，避免数据过早过期。
• 使用持久化机制：配置Redis的持久化机制，确保数据在宕机后能够恢复。

超卖问题

超卖问题是指在高并发场景下，由于库存数量更新不及时或并发控制不当，导致实际卖出的商品数量超过了库存数量。

解决方法：

• 使用乐观锁或悲观锁：在更新库存数量时，使用乐观锁或悲观锁来确保并发更新的正确性。
• 分布式锁：使用分布式锁来控制对库存数量的并发访问，确保只有一个线程能够更新库存数量。
• 预扣库存：在用户下单时先预扣库存，确保库存数量足够后再进行实际的扣减操作。

 综上所述，要解决Redis主从切换导致的库存同步异常和超卖问题，需要从多个方面入手，包括优化网络连接、监控复制进度、设置合理的过期时间、使用持久化机制、使用乐观锁或悲观锁、分布式锁以及预扣库存等。这些措施可以有效提高系统的可用性和并发处理能力，避免数据不一致和超卖问题的发生。

4.秒杀链路中 Redis与 MQ如何保证事务一致性

在秒杀链路中，使用Redis和消息队列（MQ）可以协同工作以保证事务的一致性和可靠性。以下是如何结合Redis和MQ来确保秒杀活动中的事务性：

Redis 的应用

1.库存预扣与释放：

• 利用Redis的原子操作（如INCR、DECR）来确保库存扣减的原子性。
• 当用户发起秒杀请求时，先尝试在Redis中预扣库存。如果预扣成功，则继续后续操作；如果失败，则直接返回秒杀失败。
• 在订单生成后，确保库存的释放，以便其他用户可以继续秒杀。

2. 分布式锁：

• 使用Redis的SETNX或REDLOCK算法来实现分布式锁，确保在并发环境下只有一个服务节点能够处理订单生成。

 3.数据持久化：

• 配置Redis的持久化机制（如RDB、AOF），确保即使Redis重启，数据也不会丢失。

4.2 MQ 的应用

1.消息队列保证最终一致性：

• 使用MQ（如RocketMQ、Kafka等）来确保在多个服务节点间的事务一致性。
• 当Redis预扣库存成功后，将预扣库存的消息发送到MQ。
• 消费者服务订阅MQ的消息，并在接收到消息后执行订单生成等后续操作。

 2.补偿机制：

• 如果订单生成失败，MQ的消费者服务可以检测到失败，并触发补偿机制。
• 补偿机制可以是一个定时任务，定期检查订单生成失败的情况，并尝试重新生成订单。
• 同时，可以通过MQ的消息重试机制，确保消息在失败时被重新投递，直到处理成功。

3.事务消息：

• 利用MQ的事务消息功能，确保消息的生产和消费都是事务性的。
• 在Redis预扣库存成功后，发送一个事务消息到MQ。
• 如果订单生成失败，MQ可以回滚该事务消息，确保库存不会被错误扣减。

4.3 二者结合使用

1.两阶段提交：

• 结合Redis的分布式锁和MQ的事务消息，可以实现两阶段提交协议。
• 第一阶段：在Redis中预扣库存并获取分布式锁。
• 第二阶段：如果预扣成功并且获得锁，则发送事务消息到MQ进行订单生成；否则，释放锁并回滚Redis中的预扣操作。

 2.监控与告警：

• 监控Redis和MQ的状态和性能指标，确保系统的稳定性和可用性。
• 设置告警阈值，当出现异常情况时及时通知运维人员进行处理。

 综上所述，通过结合Redis和MQ的特性和机制，可以确保秒杀活动中的事务性和一致性。在实际应用中，需要根据业务需求和系统架构选择合适的方案，并进行充分的测试和优化。

5.线上 MQ百万秒杀订单积压如何优化

线上 MQ（消息队列）在百万秒杀订单场景下出现积压，可能是由于多个因素导致的，包括但不限于生产者发送速度过快、消费者处理速度不足、网络延迟、MQ集群性能瓶颈等。针对这些问题，可以采取以下优化措施：

调整生产者发送策略：

• 限流：通过控制生产者的发送速率，避免短时间内产生大量消息导致MQ积压。
• 批量发送：适当增大批量发送的消息数量，减少网络传输次数，提高MQ的吞吐量。
• 优化消息结构：减少消息中的冗余数据，降低消息大小，提高处理速度。

优化消费者处理逻辑：

• 并行处理：增加消费者数量，实现并行处理，提高消息消费速度。
• 异步处理：将消息处理逻辑设计为异步操作，避免处理耗时任务影响消费速度。
• 优化业务逻辑：简化业务逻辑，减少处理时间，提高消费速度。

调整MQ集群配置：

• 扩容MQ集群：增加MQ节点数量，提高集群的吞吐量和处理能力。
• 优化网络配置：优化MQ集群的网络配置，减少网络延迟，提高消息传输速度。
• 调整队列深度：根据业务需求调整队列深度，避免队列溢出导致消息丢失。

引入负载均衡和容错机制：

• 负载均衡：通过负载均衡算法分配消息到不同的消费者，确保消息均匀分布，避免单点压力过大。
• 容错处理：实现消息重试机制，当消息处理失败时自动重试，提高消息的可靠性。

监控和预警：

• 监控MQ集群状态：实时监控MQ集群的负载、吞吐量、延迟等指标，确保集群稳定运行。
• 设置预警阈值：当监控指标超过阈值时，及时触发预警通知，以便快速响应和处理问题。

其他优化手段：

• 消息压缩：对消息进行压缩，减少存储和传输的开销。
• 死信队列：设置死信队列，处理无法被正常消费的消息，避免消息丢失。
• 消息过滤：在消费者端设置消息过滤规则，只处理符合条件的消息，减少不必要的处理开销。

综上所述，针对线上MQ百万秒杀订单积压的问题，可以从生产者、消费者、MQ集群等多个方面进行优化。通过合理的配置和优化手段，可以有效提高MQ的吞吐量和处理速度，确保秒杀活动的顺利进行。

6.如何用 Redis高效实现 12306的复杂售票业务

12306的售票业务是一个典型的高并发、大数据量的场景，其中涉及到的问题包括票数的实时更新、并发控制、数据持久化、负载均衡等。Redis作为一种高性能的内存数据库，可以在其中发挥重要作用，但单纯依赖Redis并不能完全解决12306的复杂售票业务，还需要结合其他技术和手段。

以下是一个简化的方案，描述如何用Redis高效实现12306的复杂售票业务：

数据模型设计：

• 使用Redis的哈希结构存储票的信息，如车次、出发地、目的地、余票数量等。
• 为每个车次创建一个唯一的key，value中存储该车次的详细信息，包括余票数量。

实时更新票数：

• 当有用户购票时，通过Redis的原子操作（如DECR）减少对应车次的余票数量。
• 使用Redis的事务功能或Lua脚本来确保操作的原子性，避免并发购票导致的数据不一致。

并发控制：

• 使用Redis的分布式锁来控制并发购票操作，确保同一时间只有一个用户能够购买同一张票。
• 当用户尝试购买已售罄的票时，应快速返回错误信息，避免浪费系统资源。

数据持久化：

• 虽然Redis主要存储在内存中，但可以通过配置RDB或AOF持久化策略，将数据定期写入磁盘，确保数据的安全性。
• 在系统重启后，可以从持久化文件中恢复数据，继续提供服务。

负载均衡：

• 在多个Redis节点之间实现负载均衡，提高系统的吞吐量和可用性。
• 可以使用Redis集群或代理工具（如Twemproxy）来实现负载均衡。

结合其他技术：

• Redis虽然提供了高性能的读写能力，但不适合存储大量数据。因此，可以结合使用关系型数据库（如MySQL）来存储历史数据和备份数据。
• 在购票高峰期，可以通过引入消息队列（如Kafka）来削峰填谷，减轻Redis的负载压力。
• 使用CDN和反向代理等技术，优化用户访问速度，提高系统稳定性。

安全性与合规性：

• 确保系统符合相关法律法规和行业标准，如个人信息保护、数据安全等。
• 对敏感数据进行加密存储和传输，确保数据的安全性。

注意：以上方案仅是一个简化的实现思路，实际的12306售票业务要复杂得多，需要考虑更多细节和技术挑战。因此，在实际应用中，还需要结合具体的业务需求和系统架构进行优化和改进。

7.新浪微博突发事件如何做好 Redis缓存的高可用性

可从以下几个方面回答：

服务化转型：

• 将Redis进行服务化转型，形成RedisService，使用Redis集群来服务不同的业务场景需求。每个业务都有独立的资源，互不干扰。这种多级缓存服务可以解决高访问、高并发性和高可用性问题。基于该系统，可以自动监控微博的流量，并支持自动伸缩，快速度过高峰并在高峰后回收机器，实现资源的充分利用。

解决Redis容量过大：

• 针对Redis容量过大的问题，可以考虑将内存中的部分数据放入磁盘。例如，微博可以区分热数据和冷数据。热数据保存在Redis中，而冷数据则可以通过如RocksDB等技术写入底层硬盘。这样，冷数据可以从Redis迁移到RocksDB并存储在硬盘上，节省Redis实例的内存来保存热数据。

负载均衡和容错处理：

• 在Redis集群中，需要实现负载均衡机制，以确保各个节点的负载均衡，避免单点压力过大。同时，引入容错处理机制，如使用主从复制、哨兵模式或Redis集群等方式，确保在部分节点故障时，系统仍然可以正常运行。

数据持久化和备份：

• 为了保障数据的安全性，需要配置Redis的持久化策略，如RDB或AOF，将数据定期写入磁盘。同时，定期进行数据备份，以防止数据丢失。

监控和预警：

实时监控Redis集群的状态和性能指标，如内存使用情况、连接数、QPS等。当监控指标超过阈值时，及时触发预警通知，以便快速响应和处理问题。

结合其他技术：

除了Redis，还可以结合其他技术来提高系统的可用性和性能。例如，使用消息队列来处理异步任务，减轻Redis的负载压力；使用负载均衡技术来分发请求，避免单点故障等。

综上所述，新浪微博在突发事件中保障Redis缓存的高可用性需要从多个方面入手，包括服务化转型、解决Redis容量过大、负载均衡和容错处理、数据持久化和备份、监控和预警以及结合其他技术等。这些措施共同构成了一个完整的Redis高可用性保障方案。

8.高并发场景缓存穿透&失效&雪崩如何解决

缓存穿透：

• 使用布隆过滤器：在查询数据库之前，先使用布隆过滤器判断请求的数据是否存在。如果不存在，则直接返回空结果，避免对数据库的查询。
• 缓存空值：对于查询结果为空的数据，也将其缓存起来，并设置较短的过期时间。这样，在后续的请求中，可以直接从缓存中获取空结果，而不需要再次查询数据库。
• 限制访问频率：对于频繁访问不存在的数据的请求，可以通过限制访问频率或添加验证码等方式进行防护。

缓存失效：

• 设置合理的过期时间：根据数据的更新频率和访问频率，设置合理的缓存过期时间，避免缓存过早失效导致频繁的数据库查询。
• 使用互斥锁：在更新缓存时，使用互斥锁保证同一时间只有一个线程能够更新缓存，避免多个线程同时更新导致缓存失效。
• 双写策略：在更新数据库的同时，也更新缓存。这样可以保证在缓存失效后，能够立即从数据库中获取最新的数据并更新缓存。

缓存雪崩：

• 设置不同的过期时间：避免大量的缓存同时失效，可以将缓存的过期时间设置为不同的值，使得缓存的失效时间分布均匀。
• 使用限流策略：在缓存失效期间，通过限流策略限制对数据库的访问频率，避免数据库压力过大导致系统崩溃。
• 备份缓存：在缓存失效前，将部分缓存数据备份到其他存储介质（如磁盘）中，以便在缓存失效后能够迅速恢复数据。

9.Redis集群架构如何抗住12306与双11的洪峰流量

水平扩展：

• 通过增加Redis节点的数量来扩展集群的容量和性能。可以根据业务需求，在集群中增加更多的主节点或从节点，以提高系统的吞吐量和并发处理能力。

数据分片：

• 将数据分片存储在不同的节点上，以提高数据的并发访问能力和系统的可扩展性。可以根据业务特点，选择合适的分片策略，如按照用户ID、订单ID等进行分片。

读写分离：

• 将读操作和写操作分离到不同的节点上，以提高系统的并发处理能力。可以配置主节点负责写操作，从节点负责读操作，通过主从同步机制保证数据的一致性。

使用集群模式：

• Redis提供了集群模式，可以在多个节点之间实现数据的自动分片、故障转移和负载均衡等功能。通过配置Redis集群，可以提高系统的可用性和容错能力。

优化数据结构：

• 针对不同的业务场景，选择合适的数据结构来存储数据，以提高数据的访问效率和系统的性能。例如，对于需要频繁访问的数据，可以使用哈希结构或列表结构来存储。

缓存预热：

• 在系统上线前，提前将热点数据加载到Redis缓存中，以减少在洪峰流量期间对数据库的访问压力。可以通过分析历史数据或使用预测算法来确定热点数据。

限流与降级：

• 在流量峰值期间，通过限流策略控制对Redis的访问频率，避免对系统造成过大的压力。同时，可以设计合理的降级策略，保证在极端情况下系统的可用性和稳定性。

监控与告警：

实时监控Redis集群的状态和性能指标，如内存使用情况、连接数、QPS等。当监控指标超过阈值时，及时触发告警通知，以便快速响应和处理问题。

10.Redis缓存与数据库双写不一致如何解决

先更新数据库，再删除缓存：

• 这是一种常见的解决方案。当需要更新数据时，先更新数据库，然后再删除缓存中的对应项。这样做可以确保在读取数据时，如果缓存中没有数据，则去数据库中查询最新的数据并放入缓存。这种方案的缺点是，如果更新数据库成功但删除缓存失败，那么在缓存失效期间，如果有读请求到来，它将会去数据库中读取旧值，并将其放入缓存，导致缓存中的数据不一致。

延迟删除缓存：

• 在更新数据库之后，不是立即删除缓存，而是等待一段时间（例如几秒钟）再删除。这样做可以减少缓存与数据库之间数据不一致的概率，因为在这段时间内，读请求可能已经从数据库中读取到了最新的数据并放入了缓存。但是，这种方案并不能完全避免不一致的问题，因为仍然存在读请求在缓存失效期间读取到旧值的可能性。

使用分布式锁：

• 在进行数据库和缓存更新时，可以使用分布式锁来保证同一时间只有一个线程可以更新缓存，从而避免数据不一致的问题。这种方法可以保证数据的一致性，但是会增加系统的复杂性和性能开销。

使用消息队列实现异步更新：

• 当需要更新数据时，先将更新请求发送到消息队列中，然后由后台线程异步地从队列中取出请求进行数据库和缓存的更新。这样做可以将更新操作异步化，减少了更新操作对系统性能的影响，并且可以通过控制队列的消费速度来平衡数据库的读写压力。但是，这种方法需要引入消息队列组件，增加了系统的复杂性和维护成本。

设置合理的缓存过期时间：

• 为了避免缓存与数据库之间的数据不一致，可以设置一个合理的缓存过期时间，使得缓存中的数据在一段时间后自动失效。这样，即使缓存中的数据与数据库中的数据不一致，也会在一段时间后自动更新为最新的数据。但是，这种方法并不能完全避免不一致的问题，因为在缓存过期之前，读请求仍然可能读取到旧值。