线上服务突然CPU飙升到100%，但GC次数正常，如何快速定位？

• 核心排查思路（黄金5分钟） ：
  1. top -H -p <pid> 查看进程中哪个线程（LWP） 消耗CPU最高，记录线程ID（十进制）。
  2. printf "%x\n" <线程ID> 转换为十六进制。
  3. jstack <pid> | grep -A 20 <十六进制线程ID> 查看该线程栈。
  4. 根因分析（四种常见情况） ：
     • 死循环/空轮询：如 while(true) 未设置休眠，多见于Netty的NioEventLoop bug或业务自旋锁。
     • 频繁Full GC（但你说GC正常，排除）。
     • 正则表达式回溯：如 (a+)+b 匹配超长字符串，导致CPU飙高，通过jstack定位到Pattern匹配行。
     • 序列化/反序列化：如Jackson解析超大JSON，占用大量CPU计算。
• 补充工具：arthas 的 thread -n 3 一键抓取最忙的3个线程，比手动jstack效率高10倍。

系统频繁发生FGC，但堆内存（Heap）占用很低，可能是什么原因？

面试官陷阱：绝大多数人只会看堆内存，忽视了非堆内存（Metaspace/DirectBuffer）。

• 根因排查清单：
  1. Metaspace（元空间）膨胀：大量动态生成类（CGLIB代理、Groovy脚本、JSP编译）导致Metaspace阈值触发FGC。使用 jstat -gc <pid> 查看 MC（当前Metaspace容量）和 MU（已使用），若接近 MaxMetaspaceSize 则确证。
  2. Direct Memory（直接内存）泄漏：NIO（Netty）使用 ByteBuffer.allocateDirect 未释放，虽然不在Heap内，但FGC会尝试回收DirectMemory。使用 jcmd <pid> VM.native_memory 查看。
  3. System.gc() 显式调用：某些框架（RMI、NIO）会主动触发FGC，加 -XX:+DisableExplicitGC 屏蔽（但谨慎）。
  4. 堆外内存不足：-XX:MaxDirectMemorySize 设置过小。

线上数据库连接池突然爆满（Active Connections飙高），应用无响应，如何排查？

• 排查步骤：
  1. 先摘流量（网关切流或K8s删Pod），防止故障蔓延。
  2. jstack 导出线程栈，搜索 getConnection 或 datasource 关键字，看哪些线程在等待获取连接。
  3. 检查慢SQL：是否在事务中调用了第三方RPC接口（如HTTP超时），导致数据库连接一直不释放。
  4. 检查连接池配置：
     • maxActive 是否合理（通常50~100）。
     • maxWait 是否配置（若为-1无限等待，线程全部阻塞）。
     • 是否忘了在finally中关闭Connection（虽然Druid/Hikari有泄露检测，需开启 leakDetectionThreshold）。
• 紧急止损：重启应用（瞬时释放连接），然后临时调大 maxActive，事后优化慢SQL或拆分长事务。

高并发与分布式架构类

设计一个“百万级QPS”的签到/点赞计数器，如何保证数据绝对不丢且延迟小于5ms？

• 方案设计（多级缓存 + 异步刷盘） ：
  1. L1（本地内存） ：每个JVM实例内使用 ConcurrentHashMap + 定时聚合（如每1秒）。写请求直接操作内存中的原子变量（LongAdder），响应在微秒级。
  2. L2（Redis） ：本地聚合后的增量数据，使用Lua脚本原子累加到Redis（INCRBY）。
  3. 异步落库：Redis中的计数器值，通过定时任务（每5秒）或MQ 异步写入DB（或HBase）。
• 防丢机制：
  • 本地内存聚合时，记录批次ID（BatchId）。若JVM突然宕机，重启后对比Redis中的最新值，未落库的批次从Redis反查补偿（依赖Redis AOF持久化）。
  • 使用双缓冲队列（一个写，一个刷），刷盘时交换指针，避免加锁。

RocketMQ/Kafka消费时，因下游DB抖动导致消费积压，且已有大量消息在队列中，如何快速恢复？

• 止损三步走：
  1. 临时扩容消费者实例（前提是Topic的分区数 > 消费者数）。若分区数固定无法扩容，启动临时应急消费者，只做消息ack，将消息转发至新的临时Topic，用更多的分区数并行处理。
  2. 开启批量处理：消费者改为拉取一批消息（如一次拉取1000条），使用批量SQL（如Batch Insert/Update），极大减少DB交互次数。
  3. 降级非核心逻辑：如发送短信、写入日志ES等操作暂时关闭或设置为异步丢弃。
• 事后根治：分析下游DB慢的原因（索引缺失/锁竞争），增加DB从库读写分离。

分布式锁（Redis）在极端情况下（主从切换）失效，导致超卖，如何兜底？

• 问题复现：线程A在Master获取锁（SET key value NX EX 30），Master宕机未同步到Slave，Slave升级为Master，线程B获取到了相同的锁，导致超卖。
• 兜底方案（DB层面最终防御） ：
  1. 数据库乐观锁是最后一道防线。扣库存SQL必须加条件：UPDATE inventory SET amount = amount - #{buyNum} WHERE product_id = #{id} AND amount >= #{buyNum}。
  2. 若影响行数为0，抛异常回滚业务，人工补偿或触发重试。
• 关于RedLock的讨论（加分项） ：
  • 面试官若问及RedLock（红锁），需指出Martin Kleppmann的批判：红锁强依赖系统时钟同步（NTP） ，且跨机房网络延迟会导致活锁。在大厂实践中，绝大多数场景下单Redis主从 + DB乐观锁 已足够，引入RedLock成本远大于收益。

数据库与缓存一致性类

缓存（Redis）和数据库（MySQL）双写一致性，如何保证？延迟双删策略存在什么缺陷？

• 经典方案：Cache-Aside（旁路缓存） 模式 + 延迟双删。
  • 写操作：更新DB → 删除Redis缓存（等待500ms后再次删除，防止并发读将旧数据写回）。
• 延迟双删缺陷：
  • 第二次删除延迟时间难以预估（业务SQL执行时间飘忽不定），若时间太短，第二次删除来不及，脏数据依然存在。
  • 若第二次删除失败（Redis超时），没有任何补偿机制。
• 终极方案（大厂主流） ：
  • 订阅 Canal（MySQL Binlog增量解析），将变更事件发送至MQ，消费者异步删除/更新Redis。
  • 优点：解耦、保证最终一致性，且不会污染业务主流程（主流程只管更新DB和发送MQ即可）。
  • 注意：缓存读取逻辑需容忍短暂不一致（如设置过期时间兜底，例如5分钟自动失效）。

分库分表后，如何生成全局唯一的分布式ID？雪花算法（Snowflake）遇到时钟回拨怎么办？

• 常见方案：雪花算法（64位：符号位1 + 时间戳41 + 机器ID10 + 序列号12）。
• 时钟回拨处理（重点） ：
  1. 记录上次生成ID的时间戳（lastTimestamp） 。若当前时间 < lastTimestamp，判定为时钟回拨。
  2. 保守策略：抛出异常，通知运维人工校准时钟（大厂标准做法）。
  3. 等待策略：Thread.sleep(差值)，等待时钟追上（仅适用于回拨毫秒级，若回拨数秒则不可行）。
  4. 备用方案：使用ZooKeeper持久化序列号或数据库号段模式（Leaf-segment） 作为兜底。
• 面试加分：美团的 Leaf 方案（号段双Buffer），每次获取一个号段（如1000-2000），用完再取，不依赖时钟，性能极高且绝对不重复。

微服务治理类

线上Feign调用频繁超时，如何快速定位是网络问题、服务端处理慢还是GC问题？

• 分层排查法（网络 → 服务端 → JVM） ：
  1. 网络层：在调用方执行 telnet <ip> <port> 或 ping，确认网络连通性。使用 tcpdump 抓包分析SYN重传。
  2. 服务端线程池：查看服务端 jstack，是否有大量线程在 WAITING（如数据库连接池耗尽）。
  3. 服务端GC：jstat -gcutil 查看GC频率，若FGC频繁，STW导致响应变慢。
  4. RPC层监控：查看Skywalking/Zipkin的Trace，定位具体哪一步耗时最长（如下游调下游）。
• 临时止损：调大Feign的超时时间（connectTimeout / readTimeout），开启Feign重试（注意幂等性），或快速熔断返回降级数据。

Spring Cloud Gateway网关通过Sentinel限流，如何做到“根据用户等级（VIP/普通）”差异化限流？

• 核心思路：使用Sentinel的热点参数限流（ParamFlow） 。
  1. 自定义 RequestOriginParser 解析请求头中的 userId，查询用户等级（VIP/普通）。
  2. 将用户等级作为参数传递给Sentinel（SphU.entry("resourceName", EntryType.IN, 1, userLevel)）。
  3. 配置热点规则：对参数 userLevel 分别设置阈值，VIP用户QPS=1000，普通用户QPS=100。
• 进阶：若用户量极大，本地缓存用户等级（Caffeine），每5分钟同步一次，避免每次限流都查DB/Redis造成性能损耗。

Spring Boot 3.x 使用AOT编译和GraalVM原生镜像后，哪些功能会受限？

*这是2025-2026年的新兴热点。*

• 受限功能：
  1. 动态代理（CGLIB/JDK Proxy） ：GraalVM静态编译时无法提前确定代理类，需在 reflect-config.json 中预声明。
  2. 反射/内省：所有反射调用必须在编译时注册（如Jackson序列化、MyBatis实体类）。
  3. Resource文件加载：ClassPathResource 需显式在 resource-config.json 中配置。
• 解决方案：Spring Boot 3.x提供了 @Hint 注解和 AOT Agent（运行测试时捕获动态调用），生成配置文件。迁移成本较高，适合云原生Serverless场景（启动毫秒级），传统微服务慎用。

设计一个秒杀系统的库存扣减方案。

• 架构分层：
  1. 流量削峰：前端秒杀按钮置灰 + 验证码（防止脚本刷）；网关层限流（令牌桶，如 Sentinel）。
  2. 库存预扣（Redis）：
     • 使用 Lua 脚本 保证原子性：if (redis.call('get', key) > 0) then redis.call('decr', key) return 1 else return 0 end。
     • 此处为预扣（逻辑库存），不直接操作 DB，响应毫秒级。
  3. 异步落库：
     • 预扣成功后，生成订单消息发送至 RocketMQ/Kafka，返回客户端“排队中”。
     • 消费者拉取消息，执行 DB 扣减真实库存（使用 乐观锁：update inventory set amount=amount-? where id=? and amount>=?，若影响行数为0则记录失败）。
  4. 防超卖兜底：
     • Redis 扣减失败直接返回“已售罄”。
     • 数据库扣减失败触发 补偿回滚（将 Redis 库存 +1），通过消息重试或定时任务保证最终一致性。

分库分表后如何实现分页查询？

• 挑战：limit 10, 10 在分库分表下需要每个分片都查询 20 条数据，然后归并排序取第 10~20 条，数据量越大性能越差（ShardingSphere 默认支持但伴随性能瓶颈）。
• 解决方案：
  1. 禁止跳页（游标滚动）：业务上改为“上一页/下一页”，使用 where id > lastId order by id limit 10。每条 SQL 在各分片查询，归并取最小 10 条即可，性能极高，适合瀑布流。
  2. ES 宽表冗余：将需要分页展示的字段同步到 ElasticSearch，依靠 ES 的分布式分页（from/size 或 search_after）完成。
  3. 二次查询法（ShardingSphere 默认优化）：先查询到目标数据的主键 ID（例如 limit 1000,10，实际每条 SQL 只查 ID），再根据 ID 回表查询完整数据。
  4. 数仓/汇总库：将分表数据按小时同步到一个只读的汇总库（单库），在该库进行分页（适合报表类慢查询）。

突发流量导致订单接口超时，如何10分钟内止损？

止损黄金十分钟（止血 > 排查）：

1. 扩容：快速增加 Pod 实例（K8s HPA 或手动调整副本数），或临时增加物理机/容器资源。
2. 限流与熔断：
   • 在网关（如 Sentinel / Hystrix）配置快速失败（QPS 限流，超出返回友好提示“系统繁忙”）。
   • 开启熔断（错误率 > 50% 自动熔断，走 fallback 兜底返回缓存数据）。
3. 降级：非核心逻辑（如发送短信、更新积分）改为异步 MQ 处理，或直接关闭这些功能。
4. 慢查询定位：
   • 连接 APM（Skywalking/Pinpoint）查看 Trace 链路，定位慢 SQL 或第三方 RPC 调用。
   • 若发现慢 SQL，快速执行 执行计划优化（加索引）或 限流 SQL（SQL 网关层拦截）。
5. JVM 紧急处理：若 CPU 飙升，jstack 查看是否大量 GC；若内存高，考虑 jmap 导出并调整 -Xmx 参数重启（临时方案）。
6. 消息队列解压：若下游处理慢，将请求直接投入 MQ 排队，立即返回“处理中”，异步通知结果。

如何设计一个日500万次搜索的商品检索系统？

*注：500万次/天 ≈ 58 QPS，高峰期（10倍）约 580 QPS，属于中等规模。*

• 技术选型：Elasticsearch 集群（倒排索引 + 分词器，如 IK）。
• 架构设计：
  1. 索引拆分：按商品类目或时间分索引（index-{date}），便于冷热数据分离。
  2. 分片策略：设置合理的 number_of_shards（约 数据总量 / 单分片建议大小(10~50GB)），副本数至少 1 个（保证高可用）。
  3. 写入链路：商品变更通过 Canal 监听 MySQL Binlog → 发送至 MQ → 消费者增量更新 ES（保证最终一致性）。
  4. 查询链路：
     • L1 本地缓存（Caffeine）：缓存高热度搜索词（Top 1000 关键词）的返回结果，TTL 5min。
     • L2 Redis 缓存：缓存次热词，TTL 1min。
     • L3 ES 查询：使用 bool 组合查询 + function_score 按销量/评分自定义相关度。
  5. 性能优化：
     • 禁用 * 通配符查询，使用精确字段（keyword）聚合。
     • 开启 routing 路由，确保相同类目的商品落在同一分片，减少跨分片查询。
     • 配置 refresh_interval 调大（如 30s），降低写入压力。

zookeeper 是什么？

zookeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 google chubby 的开源实现，是 hadoop 和 hbase 的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

zookeeper 都有哪些功能？

• 集群管理：监控节点存活状态、运行请求等。
• 主节点选举：主节点挂掉了之后可以从备用的节点开始新一轮选主，主节点选举说的就是这个选举的过程，使用 zookeeper 可以协助完成这个过程。
• 分布式锁：zookeeper 提供两种锁：独占锁、共享锁。独占锁即一次只能有一个线程使用资源，共享锁是读锁共享，读写互斥，即可以有多线线程同时读同一个资源，如果要使用写锁也只能有一个线程使用。zookeeper可以对分布式锁进行控制。
• 命名服务：在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。

zookeeper 有几种部署模式？

zookeeper 有三种部署模式：

• 单机部署：一台集群上运行；
• 集群部署：多台集群运行；
• 伪集群部署：一台集群启动多个 zookeeper 实例运行。

zookeeper 怎么保证主从节点的状态同步？

zookeeper 的核心是原子广播，这个机制保证了各个 server 之间的同步。实现这个机制的协议叫做 zab 协议。zab 协议有两种模式，分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，zab 就进入了恢复模式，当领导者被选举出来，且大多数 server 完成了和 leader 的状态同步以后，恢复模式就结束了。状态同步保证了 leader 和 server 具有相同的系统状态。

集群中为什么要有主节点？

在分布式环境中，有些业务逻辑只需要集群中的某一台机器进行执行，其他的机器可以共享这个结果，这样可以大大减少重复计算，提高性能，所以就需要主节点。

集群中有 3 台服务器，其中一个节点宕机，这个时候 zookeeper 还可以使用吗？

可以继续使用，单数服务器只要没超过一半的服务器宕机就可以继续使用。

说一下 zookeeper 的通知机制？

客户端端会对某个 znode 建立一个 watcher 事件，当该 znode 发生变化时，这些客户端会收到 zookeeper 的通知，然后客户端可以根据 znode 变化来做出业务上的改变。

Elasticsearch

解释一下Elasticsearch中的text和keyword字段类型的区别。

• text：该类型会进行分词处理，将长文本拆分为多个词项，然后建立倒排索引。它主要用于全文检索场景，例如搜索文章内容、商品描述等。
• keyword：该类型不会进行分词，会将整个字段内容作为一个完整的词项存入倒排索引。它主要用于精确匹配、聚合（Aggregation）和排序，例如订单状态、用户ID、邮箱地址等。实际应用中，常用multi-fields特性为一个字段同时定义text和keyword类型，以应对不同场景。

Elasticsearch是如何实现Master选举的？如何处理脑裂问题？

• 选举流程：ES的ZenDiscovery模块负责选主。当一个节点发现集群中不存在活跃主节点时，它会发起选举。所有具备主节点资格（node.master: true）的节点会对所有已知的有资格的节点进行排序（通常按节点ID），并倾向于选举自己知道的第一个节点。如果一个节点获得了超过半数（discovery.zen.minimum_master_nodes配置的值）的选票，且该节点也选举了自己，那么它就成为新的主节点。
• 脑裂预防：脑裂是指集群中出现多个主节点的现象。核心解决方法是正确配置 discovery.zen.minimum_master_nodes，其值应设置为有资格成为主节点的节点数 n/2 + 1（即超过半数）。这样，任何时刻最多只有一个分区拥有足够的节点数来选举出主节点，从而避免脑裂。

Elasticsearch有哪些不同的查询类型？请举例说明。

• 精确查询：如term、terms、range查询，不对查询词进行分析，用于精确匹配条件。
• 全文检索：如match、match_phrase、multi_match查询，会对查询文本进行分析（分词），然后去倒排索引中查找。
• 复合查询：如bool查询，通过must、should、filter、must_not等子句组合多个查询条件。其中filter子句不计算相关性得分，且结果可被缓存，性能更好。
• 聚合分析：如terms（分组统计）、avg（平均值）、date_histogram（时间直方图）等，用于数据分析。

RabbitMQ 的使用场景有哪些？

• 抢购活动，削峰填谷，防止系统崩塌。
• 延迟信息处理，比如 10 分钟之后给下单未付款的用户发送邮件提醒。
• 解耦系统，对于新增的功能可以单独写模块扩展，比如用户确认评价之后，新增了给用户返积分的功能，这个时候不用在业务代码里添加新增积分的功能，只需要把新增积分的接口订阅确认评价的消息队列即可，后面再添加任何功能只需要订阅对应的消息队列即可。

RabbitMQ 有哪些重要的角色？

RabbitMQ 中重要的角色有：生产者、消费者和代理：

• 生产者：消息的创建者，负责创建和推送数据到消息服务器；
• 消费者：消息的接收方，用于处理数据和确认消息；
• 代理：就是 RabbitMQ 本身，用于扮演“快递”的角色，本身不生产消息，只是扮演“快递”的角色。

RabbitMQ 有哪些重要的组件？

• ConnectionFactory（连接管理器）：应用程序与Rabbit之间建立连接的管理器，程序代码中使用。
• Channel（信道）：消息推送使用的通道。
• Exchange（交换器）：用于接受、分配消息。
• Queue（队列）：用于存储生产者的消息。
• RoutingKey（路由键）：用于把生成者的数据分配到交换器上。
• BindingKey（绑定键）：用于把交换器的消息绑定到队列上。

RabbitMQ 中 vhost 的作用是什么？

vhost：每个 RabbitMQ 都能创建很多 vhost，我们称之为虚拟主机，每个虚拟主机其实都是 mini 版的RabbitMQ，它拥有自己的队列，交换器和绑定，拥有自己的权限机制。

RabbitMQ 的消息是怎么发送的？

首先客户端必须连接到 RabbitMQ 服务器才能发布和消费消息，客户端和 rabbit server 之间会创建一个 tcp 连接，一旦 tcp 打开并通过了认证（认证就是你发送给 rabbit 服务器的用户名和密码），你的客户端和 RabbitMQ 就创建了一条 amqp 信道（channel），信道是创建在“真实” tcp 上的虚拟连接，amqp 命令都是通过信道发送出去的，每个信道都会有一个唯一的 id，不论是发布消息，订阅队列都是通过这个信道完成的。

RabbitMQ 怎么保证消息的稳定性？

• 提供了事务的功能。
• 通过将 channel 设置为 confirm（确认）模式。

RabbitMQ 怎么避免消息丢失？

• 把消息持久化磁盘，保证服务器重启消息不丢失。
• 每个集群中至少有一个物理磁盘，保证消息落入磁盘。

要保证消息持久化成功的条件有哪些？

• 声明队列必须设置持久化 durable 设置为 true.
• 消息推送投递模式必须设置持久化，deliveryMode 设置为 2（持久）。
• 消息已经到达持久化交换器。
• 消息已经到达持久化队列。

以上四个条件都满足才能保证消息持久化成功。

RabbitMQ 持久化有什么缺点？

持久化的缺地就是降低了服务器的吞吐量，因为使用的是磁盘而非内存存储，从而降低了吞吐量。可尽量使用 ssd 硬盘来缓解吞吐量的问题。

RabbitMQ 有几种广播类型？

• direct（默认方式）：最基础最简单的模式，发送方把消息发送给订阅方，如果有多个订阅者，默认采取轮询的方式进行消息发送。
• headers：与 direct 类似，只是性能很差，此类型几乎用不到。
• fanout：分发模式，把消费分发给所有订阅者。
• topic：匹配订阅模式，使用正则匹配到消息队列，能匹配到的都能接收到。

RabbitMQ 怎么实现延迟消息队列？

延迟队列的实现有两种方式：

• 通过消息过期后进入死信交换器，再由交换器转发到延迟消费队列，实现延迟功能；
• 使用 RabbitMQ-delayed-message-exchange 插件实现延迟功能。

RabbitMQ 集群有什么用？

集群主要有以下两个用途：

• 高可用：某个服务器出现问题，整个 RabbitMQ 还可以继续使用；
• 高容量：集群可以承载更多的消息量。

RabbitMQ 节点的类型有哪些？

• 磁盘节点：消息会存储到磁盘。
• 内存节点：消息都存储在内存中，重启服务器消息丢失，性能高于磁盘类型。

RabbitMQ 集群搭建需要注意哪些问题？

• 各节点之间使用“–link”连接，此属性不能忽略。
• 各节点使用的 erlang cookie 值必须相同，此值相当于“秘钥”的功能，用于各节点的认证。
• 整个集群中必须包含一个磁盘节点。

RabbitMQ 每个节点是其他节点的完整拷贝吗？为什么？

不是，原因有以下两个：

• 存储空间的考虑：如果每个节点都拥有所有队列的完全拷贝，这样新增节点不但没有新增存储空间，反而增加了更多的冗余数据；
• 性能的考虑：如果每条消息都需要完整拷贝到每一个集群节点，那新增节点并没有提升处理消息的能力，最多是保持和单节点相同的性能甚至是更糟。

RabbitMQ 集群中唯一一个磁盘节点崩溃了会发生什么情况？

如果唯一磁盘的磁盘节点崩溃了，不能进行以下操作：

• 不能创建队列
• 不能创建交换器
• 不能创建绑定
• 不能添加用户
• 不能更改权限
• 不能添加和删除集群节点

唯一磁盘节点崩溃了，集群是可以保持运行的，但你不能更改任何东西。

RabbitMQ 对集群节点停止顺序有要求吗？

RabbitMQ 对集群的停止的顺序是有要求的，应该先关闭内存节点，最后再关闭磁盘节点。如果顺序恰好相反的话，可能会造成消息的丢失。

如何保证消息不丢失（可靠性）？

保证消息的可靠传输需要从三个环节入手：

• 生产者 -> RabbitMQ：开启发布确认（Publisher Confirm）机制。生产者发送消息后，RabbitMQ 会异步返回一个 ack（成功）或 nack（失败），生产者可根据结果重试。
• RabbitMQ 自身：开启持久化。
  1. 队列持久化：创建队列时设置 durable = true。
  2. 消息持久化：发送消息时设置 deliveryMode = 2。
• RabbitMQ -> 消费者：关闭自动 ack，改为手动确认（Manual Ack）。消费者处理完业务逻辑后再手动确认，防止消费者宕机导致消息丢失。

如何解决消息的重复消费问题（保证幂等性）？

消息重复通常是因为网络波动，消费者已消费但确认 (ack) 未送达 Broker，导致消息被重新投递。

• 核心思路：保证幂等性，即同一条消息执行多次与执行一次的效果相同。
• 解决方案：消息体中带一个全局唯一的业务 ID（如订单号、支付 ID）。
  • 方案一（数据库）：利用数据库主键唯一约束去重。消费前先根据业务 ID 查询，若记录已存在则直接返回。
  • 方案二（Redis）：用业务 ID 作为 Redis 的 key，通过 setNx 操作来判断是否处理过。

什么是死信队列（DLX）？它有什么用？

死信队列是一种消息补偿机制。当消息成为死信时，会被重新发送到指定的交换机（称为死信交换机 DLX），进而进入绑定的死信队列。

• 消息成为死信的条件：
  1. 消息被消费者拒绝且未重新入队（basic.reject 或 basic.nack 且 requeue = false）。
  2. 消息TTL（存活时间） 过期。
  3. 队列达到最大长度，无法再添加消息。
• 作用：可以监听死信队列，对失败的消息进行延迟处理、异常监控或人工干预。

如何实现延迟队列？

RabbitMQ 本身没有直接提供延迟队列，通常通过死信队列 + TTL 机制模拟：

1. 创建一个队列，不设置消费者，并为其消息设置 TTL。
2. 为该队列指定死信交换机（DLX）。
3. 消息超时无人消费后，自动转发到死信交换机，再路由到绑定的死信队列。
4. 消费者监听死信队列即可获取到“延迟”的消息。

如何处理消息堆积？

• 临时扩容：增加消费者数量（前提是队列能支撑并行消费），或为消费者开启多线程处理。
• 队列优化：对于大量消息积压，可以使用 RabbitMQ 的惰性队列，它会将消息直接存入磁盘，减少内存压力，但吞吐量会下降。
• 紧急修复：如果消费者程序有 Bug，先暂停消费者，修复 Bug 后，再启动消费能力更强的程序来追赶进度。

Kafka

kafka 可以脱离 zookeeper 单独使用吗？为什么？

kafka 不能脱离 zookeeper 单独使用，因为 kafka 使用 zookeeper 管理和协调 kafka 的节点服务器。

kafka 有几种数据保留的策略？

kafka 有两种数据保存策略：按照过期时间保留和按照存储的消息大小保留。

kafka 同时设置了 7 天和 10G 清除数据，到第五天的时候消息达到了 10G，这个时候 kafka 将如何处理？

这个时候 kafka 会执行数据清除工作，时间和大小不论那个满足条件，都会清空数据。

什么情况会导致 kafka 运行变慢？

• cpu 性能瓶颈
• 磁盘读写瓶颈
• 网络瓶颈

使用 kafka 集群需要注意什么？

• 集群的数量不是越多越好，最好不要超过 7 个，因为节点越多，消息复制需要的时间就越长，整个群组的吞吐量就越低。
• 集群数量最好是单数，因为超过一半故障集群就不能用了，设置为单数容错率更高。

• 第一范式：强调的是列的原子性，即数据库表的每一列都是不可分割的原子数据项。
• 第二范式：要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性。
• 第三范式：任何非主属性不依赖于其它非主属性。

一张自增表里面总共有 7 条数据，删除了最后 2 条数据，重启 MySQL 数据库，又插入了一条数据，此时 id 是几？

• 表类型如果是 MyISAM ，那 id 就是 8。
• 表类型如果是 InnoDB，那 id 就是 6。

InnoDB 表只会把自增主键的最大 id 记录在内存中，所以重启之后会导致最大 id 丢失。

如何获取当前数据库版本？

使用 select version() 获取当前 MySQL 数据库版本。

说一下 ACID 是什么？

• Atomicity（原子性）：一个事务（transaction）中的所有操作，或者全部完成，或者全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。即，事务不可分割、不可约简。
• Consistency（一致性）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设约束、触发器、级联回滚等。
• Isolation（隔离性）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。
• Durability（持久性）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

char 和 varchar 的区别是什么？

• 「char(n)」 ：固定长度类型，比如订阅 char(10)，当你输入”abc”三个字符的时候，它们占的空间还是 10 个字节，其他 7 个是空字节。
  • chat 优点：效率高；缺点：占用空间；适用场景：存储密码的 md5 值，固定长度的，使用 char 非常合适。
• 「varchar(n)」 ：可变长度，存储的值是每个值占用的字节再加上一个用来记录其长度的字节的长度。

所以，从空间上考虑 varcahr 比较合适；从效率上考虑 char 比较合适，二者使用需要权衡。

float 和 double 的区别是什么？

• float 最多可以存储 8 位的十进制数，并在内存中占 4 字节。
• double 最可可以存储 16 位的十进制数，并在内存中占 8 字节。

MySQL 的内连接、左连接、右连接有什么区别？

内连接关键字：inner join；左连接：left join；右连接：right join。

内连接是把匹配的关联数据显示出来；左连接是左边的表全部显示出来，右边的表显示出符合条件的数据；右连接正好相反。

MySQL 索引是怎么实现的？

索引是满足某种特定查找算法的数据结构，而这些数据结构会以某种方式指向数据，从而实现高效查找数据。

具体来说 MySQL 中的索引，不同的数据引擎实现有所不同，但目前主流的数据库引擎的索引都是 B+ 树实现的，B+ 树的搜索效率，可以到达二分法的性能，找到数据区域之后就找到了完整的数据结构了，所有索引的性能也是更好的。

怎么验证 MySQL 的索引是否满足需求？

使用 explain 查看 SQL 是如何执行查询语句的，从而分析你的索引是否满足需求。

explain 语法：explain select * from table where type=1。

说一下数据库的事务隔离？

MySQL 的事务隔离是在 MySQL. ini 配置文件里添加的，在文件的最后添加：

❝transaction-isolation = REPEATABLE-READ ❞

可用的配置值：READ-UNCOMMITTED、READ-COMMITTED、REPEATABLE-READ、SERIALIZABLE。

• READ-UNCOMMITTED：未提交读，最低隔离级别、事务未提交前，就可被其他事务读取（会出现幻读、脏读、不可重复读）。
• READ-COMMITTED：提交读，一个事务提交后才能被其他事务读取到（会造成幻读、不可重复读）。
• REPEATABLE-READ：可重复读，默认级别，保证多次读取同一个数据时，其值都和事务开始时候的内容是一致，禁止读取到别的事务未提交的数据（会造成幻读）。
• SERIALIZABLE：序列化，代价最高最可靠的隔离级别，该隔离级别能防止脏读、不可重复读、幻读。

• 「脏读」 ：表示一个事务能够读取另一个事务中还未提交的数据。比如，某个事务尝试插入记录 A，此时该事务还未提交，然后另一个事务尝试读取到了记录 A。
• 「不可重复读」 ：是指在一个事务内，多次读同一数据。
• 「幻读」 ：指同一个事务内多次查询返回的结果集不一样。比如同一个事务 A 第一次查询时候有 n 条记录，但是第二次同等条件下查询却有 n+1 条记录，这就好像产生了幻觉。发生幻读的原因也是另外一个事务新增或者删除或者修改了第一个事务结果集里面的数据，同一个记录的数据内容被修改了，所有数据行的记录就变多或者变少了。

说一下 MySQL 常用的引擎？

• InnoDB 引擎：mysql 5.1 后默认的数据库引擎，提供了对数据库 acid 事务的支持，并且还提供了行级锁和外键的约束，它的设计的目标就是处理大数据容量的数据库系统。MySQL 运行的时候，InnoDB 会在内存中建立缓冲池，用于缓冲数据和索引。但是该引擎是不支持全文搜索，同时启动也比较的慢，它是不会保存表的行数的，所以当进行 select count(*) from table 指令的时候，需要进行扫描全表。由于锁的粒度小，写操作是不会锁定全表的,所以在并发度较高的场景下使用会提升效率的。
• MyIASM 引擎：不提供事务的支持，也不支持行级锁和外键。因此当执行插入和更新语句时，即执行写操作的时候需要锁定这个表，所以会导致效率会降低。不过和 InnoDB 不同的是，MyIASM 引擎是保存了表的行数，于是当进行 select count(*) from table 语句时，可以直接的读取已经保存的值而不需要进行扫描全表。所以，如果表的读操作远远多于写操作时，并且不需要事务的支持的，可以将 MyIASM 作为数据库引擎的首选。

说一下 MySQL 的行锁和表锁？

MyISAM 只支持表锁，InnoDB 支持表锁和行锁，默认为行锁。

• 表级锁：开销小，加锁快，不会出现死锁。锁定粒度大，发生锁冲突的概率最高，并发量最低。
• 行级锁：开销大，加锁慢，会出现死锁。锁力度小，发生锁冲突的概率小，并发度最高。

说一下乐观锁和悲观锁？

• 乐观锁：每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在提交更新的时候会判断一下在此期间别人有没有去更新这个数据。
• 悲观锁：每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻止，直到这个锁被释放。

数据库的乐观锁需要自己实现，在表里面添加一个 version 字段，每次修改成功值加 1，这样每次修改的时候先对比一下，自己拥有的 version 和数据库现在的 version 是否一致，如果不一致就不修改，这样就实现了乐观锁。

MySQL 问题排查都有哪些手段？

• 使用 show processlist 命令查看当前所有连接信息。
• 使用 explain 命令查询 SQL 语句执行计划。
• 开启慢查询日志，查看慢查询的 SQL。

如何做 MySQL 的性能优化？

• 为搜索字段创建索引。
• 避免使用 select *，列出需要查询的字段。
• 垂直分割分表。
• 选择正确的存储引擎。

B+树和B树的区别

• B树：所有节点都存数据，查找速度快（可能提前结束），但范围查询麻烦。
• B+树：只有叶子节点存数据，内部节点只存键，且叶子节点有链表连接。牺牲了“可能提前找到”的微小概率，换来了更稳定的查找性能和极致的范围查询能力，因此成为现代数据库索引的默认选择。

MySQL默认的事务隔离级别是？

MySQL默认的事务隔离级别是 可重复读（REPEATABLE READ）。

什么是事务？

事务是一组不可分割的数据库操作单元，这些操作要么全部成功执行，要么全部失败回滚，确保数据库从一种一致状态转换到另一种一致状态。

事务有哪几个特性？

事务具有ACID特性：

• 原子性（Atomicity）：事务中的操作要么全部完成，要么全部不执行。
• 一致性（Consistency）：事务执行前后，数据库完整性约束没有被破坏。
• 隔离性（Isolation）：多个事务并发执行时，相互隔离，互不干扰。
• 持久性（Durability）：事务一旦提交，对数据库的改变是永久性的。

Hibernate

为什么要使用 hibernate？

• hibernate 是对 jdbc 的封装，大大简化了数据访问层的繁琐的重复性代码。
• hibernate 是一个优秀的 ORM 实现，很多程度上简化了 DAO 层的编码功能。
• 可以很方便的进行数据库的移植工作。
• 提供了缓存机制，是程序执行更改的高效。

什么是 ORM 框架？

ORM（Object Relation Mapping）对象关系映射，是把数据库中的关系数据映射成为程序中的对象。

使用 ORM 的优点：提高了开发效率降低了开发成本、开发更简单更对象化、可移植更强。

hibernate 中如何在控制台查看打印的 SQL 语句？

在 Config 里面把 hibernate. show_SQL 设置为 true 就可以。但不建议开启，开启之后会降低程序的运行效率。

hibernate 有几种查询方式？

三种：hql、原生 SQL、条件查询 Criteria。

hibernate 实体类可以被定义为 final 吗？

实体类可以定义为 final 类，但这样的话就不能使用 hibernate 代理模式下的延迟关联提供性能了，所以不建议定义实体类为 final。

在 hibernate 中使用 Integer 和 int 做映射有什么区别？

Integer 类型为对象，它的值允许为 null，而 int 属于基础数据类型，值不能为 null。

hibernate 是如何工作的？

• 读取并解析配置文件。
• 读取并解析映射文件，创建 SessionFactory。
• 打开 Session。
• 创建事务。
• 进行持久化操作。
• 提交事务。
• 关闭 Session。
• 关闭 SessionFactory。

get()和 load()的区别？

• 数据查询时，没有 OID 指定的对象，get() 返回 null；load() 返回一个代理对象。
• load()支持延迟加载；get() 不支持延迟加载。

说一下 hibernate 的缓存机制？

hibernate 常用的缓存有一级缓存和二级缓存：

一级缓存：也叫 Session 缓存，只在 Session 作用范围内有效，不需要用户干涉，由 hibernate 自身维护，可以通过：evict(object)清除 object 的缓存；clear()清除一级缓存中的所有缓存；flush()刷出缓存；

二级缓存：应用级别的缓存，在所有 Session 中都有效，支持配置第三方的缓存，如：EhCache。

hibernate 对象有哪些状态？

• 临时/瞬时状态：直接 new 出来的对象，该对象还没被持久化（没保存在数据库中），不受 Session 管理。
• 持久化状态：当调用 Session 的 save/saveOrupdate/get/load/list 等方法的时候，对象就是持久化状态。
• 游离状态：Session 关闭之后对象就是游离状态。

在 hibernate 中 getCurrentSession 和 openSession 的区别是什么？

• getCurrentSession 会绑定当前线程，而 openSession 则不会。
• getCurrentSession 事务是 Spring 控制的，并且不需要手动关闭，而 openSession 需要我们自己手动开启和提交事务。

hibernate 实体类必须要有无参构造函数吗？为什么？

hibernate 中每个实体类必须提供一个无参构造函数，因为 hibernate 框架要使用 reflection api，通过调用 ClassnewInstance() 来创建实体类的实例，如果没有无参的构造函数就会抛出异常。

MyBatis

MyBatis 中 #{}和 ${}的区别是什么？

\#{}是预编译处理，${}是字符替换。在使用 #{}时，MyBatis 会将 SQL 中的 #{}替换成“?”，配合 PreparedStatement 的 set 方法赋值，这样可以有效的防止 SQL 注入，保证程序的运行安全。

MyBatis 有几种分页方式？

分页方式：逻辑分页和物理分页。

「逻辑分页：」 使用 MyBatis 自带的 RowBounds 进行分页，它是一次性查询很多数据，然后在数据中再进行检索。

「物理分页：」 自己手写 SQL 分页或使用分页插件 PageHelper，去数据库查询指定条数的分页数据的形式。

RowBounds 是一次性查询全部结果吗？为什么？

RowBounds 表面是在“所有”数据中检索数据，其实并非是一次性查询出所有数据，因为 MyBatis 是对 jdbc 的封装，在 jdbc 驱动中有一个 Fetch Size 的配置，它规定了每次最多从数据库查询多少条数据，假如你要查询更多数据，它会在你执行 next()的时候，去查询更多的数据。就好比你去自动取款机取 10000 元，但取款机每次最多能取 2500 元，所以你要取 4 次才能把钱取完。只是对于 jdbc 来说，当你调用 next()的时候会自动帮你完成查询工作。这样做的好处可以有效的防止内存溢出。

MyBatis 逻辑分页和物理分页的区别是什么？

• 逻辑分页是一次性查询很多数据，然后再在结果中检索分页的数据。这样做弊端是需要消耗大量的内存、有内存溢出的风险、对数据库压力较大。
• 物理分页是从数据库查询指定条数的数据，弥补了一次性全部查出的所有数据的种种缺点，比如需要大量的内存，对数据库查询压力较大等问题。

MyBatis 是否支持延迟加载？延迟加载的原理是什么？

MyBatis 支持延迟加载，设置 lazyLoadingEnabled=true 即可。

延迟加载的原理的是调用的时候触发加载，而不是在初始化的时候就加载信息。比如调用 a. getB(). getName()，这个时候发现 a. getB() 的值为 null，此时会单独触发事先保存好的关联 B 对象的 SQL，先查询出来 B，然后再调用 a. setB(b)，而这时候再调用 a. getB(). getName() 就有值了，这就是延迟加载的基本原理。

说一下 MyBatis 的一级缓存和二级缓存？

• 一级缓存：基于 PerpetualCache 的 HashMap 本地缓存，它的声明周期是和 SQLSession 一致的，有多个 SQLSession 或者分布式的环境中数据库操作，可能会出现脏数据。当 Session flush 或 close 之后，该 Session 中的所有 Cache 就将清空，默认一级缓存是开启的。
• 二级缓存：也是基于 PerpetualCache 的 HashMap 本地缓存，不同在于其存储作用域为 Mapper 级别的，如果多个SQLSession之间需要共享缓存，则需要使用到二级缓存，并且二级缓存可自定义存储源，如 Ehcache。默认不打开二级缓存，要开启二级缓存，使用二级缓存属性类需要实现 Serializable 序列化接口(可用来保存对象的状态)。

开启二级缓存数据查询流程：二级缓存 -> 一级缓存 -> 数据库。

缓存更新机制：当某一个作用域(一级缓存 Session/二级缓存 Mapper)进行了C/U/D 操作后，默认该作用域下所有 select 中的缓存将被 clear。

MyBatis 和 hibernate 的区别有哪些？

• 灵活性：MyBatis 更加灵活，自己可以写 SQL 语句，使用起来比较方便。
• 可移植性：MyBatis 有很多自己写的 SQL，因为每个数据库的 SQL 可以不相同，所以可移植性比较差。
• 学习和使用门槛：MyBatis 入门比较简单，使用门槛也更低。
• 二级缓存：hibernate 拥有更好的二级缓存，它的二级缓存可以自行更换为第三方的二级缓存。

MyBatis 有哪些执行器（Executor）？

MyBatis 有三种基本的Executor执行器：

• SimpleExecutor：每执行一次 update 或 select 就开启一个 Statement 对象，用完立刻关闭 Statement 对象；
• ReuseExecutor：执行 update 或 select，以 SQL 作为 key 查找 Statement 对象，存在就使用，不存在就创建，用完后不关闭 Statement 对象，而是放置于 Map 内供下一次使用。简言之，就是重复使用 Statement 对象；
• BatchExecutor：执行 update（没有 select，jdbc 批处理不支持 select），将所有 SQL 都添加到批处理中（addBatch()），等待统一执行（executeBatch()），它缓存了多个 Statement 对象，每个 Statement 对象都是 addBatch()完毕后，等待逐一执行 executeBatch()批处理，与 jdbc 批处理相同。

MyBatis 分页插件的实现原理是什么？

分页插件的基本原理是使用 MyBatis 提供的插件接口，实现自定义插件，在插件的拦截方法内拦截待执行的 SQL，然后重写 SQL，根据 dialect 方言，添加对应的物理分页语句和物理分页参数。

MyBatis 如何编写一个自定义插件？

「自定义插件实现原理」

MyBatis 自定义插件针对 MyBatis 四大对象（Executor、StatementHandler、ParameterHandler、ResultSetHandler）进行拦截：

• Executor：拦截内部执行器，它负责调用 StatementHandler 操作数据库，并把结果集通过 ResultSetHandler 进行自动映射，另外它还处理了二级缓存的操作；
• StatementHandler：拦截 SQL 语法构建的处理，它是 MyBatis 直接和数据库执行 SQL 脚本的对象，另外它也实现了 MyBatis 的一级缓存；
• ParameterHandler：拦截参数的处理；
• ResultSetHandler：拦截结果集的处理。

「自定义插件实现关键」

MyBatis 插件要实现 Interceptor 接口，接口包含的方法，如下：

代码语言：javascript

代码运行次数：0

运行

AI代码解释

public interface Interceptor{   
   Object intercept(Invocation invocation)throws Throwable;       
   Object plugin(Object target);    
   void setProperties(Properties properties);
}

• setProperties 方法是在 MyBatis 进行配置插件的时候可以配置自定义相关属性，即：接口实现对象的参数配置；
• plugin 方法是插件用于封装目标对象的，通过该方法我们可以返回目标对象本身，也可以返回一个它的代理，可以决定是否要进行拦截进而决定要返回一个什么样的目标对象，官方提供了示例：return Plugin. wrap(target, this)；
• intercept 方法就是要进行拦截的时候要执行的方法。

「自定义插件实现示例」

官方插件实现：

@Intercepts({@Signature(type = Executor. class, method= "query",
        args = {MappedStatement. class, Object. class, RowBounds. class, ResultHandler. class})})
public class TestInterceptorimplementsInterceptor{
   public Object intercept(Invocation invocation)throws Throwable {
     Object target = invocation. getTarget(); //被代理对象
     Method method = invocation. getMethod(); //代理方法
     Object[] args = invocation. getArgs(); //方法参数
     // do something . . . . . .  方法拦截前执行代码块
     Object result = invocation. proceed();
     // do something . . . . . . . 方法拦截后执行代码块
     return result;
   }
   public Object plugin(Object target){
     return Plugin. wrap(target, this);
   }
}

为什么要使用 spring？

• spring 提供 ioc 技术，容器会帮你管理依赖的对象，从而不需要自己创建和管理依赖对象了，更轻松的实现了程序的解耦。
• spring 提供了事务支持，使得事务操作变的更加方便。
• spring 提供了面向切片编程，这样可以更方便的处理某一类的问题。
• 更方便的框架集成，spring 可以很方便的集成其他框架，比如 MyBatis、hibernate 等。

解释一下AOP?意义是什么?实现机制是什么

1. 什么是AOP–面向切面编程
   • 用于将与业务无关的，但却对多个对象产生影响的公共行为和逻辑，使用动态代理的方式封装为一个统一的可重用的模块，这个模块被命名为“切面”（Aspect），具有无侵入性的特点,可以减少重复代码.如用于鉴权、日志、事务、运行监控等
2. 实现机制
   • Spring AOP基于动态代理实现.使用JDK动态代理或CGLIB.JDK动态代理支持接口的代理,不支持类的代理,当无法使用JDK动态代理时,Spring AOP才会使用CGLIB

静态代理和动态代理的区别是什么

代理主要分为静态代理和动态代理。静态代理的代表为AspectJ；动态代理的代表为Spring AOP

生成代理对象的时机不同

1. 静态代理：由程序员主动创建或由特定工具自动生成源代码，再对其编译,在程序运行前代理类的.class文件就已经存在了。
2. 动态代理：在程序运行时用反射机制在内存中临时生成代理对象,该代理对象包含了目标对象的全部方法，并且在特定的切点做了增强处理，并回调原对象的方法

AspectJ的静态代理具有更好的性能，但AspectJ需要特定的编译器进行处理，而Spring AOP则无需特定的编译器处理

解释一下 ioc？

ioc：Inversionof Control（中文：控制反转）是 spring 的核心，对于 spring 框架来说，就是由 spring 来负责控制对象的生命周期和对象间的关系。

简单来说，控制指的是当前对象对内部成员的控制权；控制反转指的是，这种控制权不由当前对象管理了，由其他（类,第三方容器）来管理。

spring 有哪些主要模块？

• spring core：框架的最基础部分，提供 ioc 和依赖注入特性。
• spring context：构建于 core 封装包基础上的 context 封装包，提供了一种框架式的对象访问方法。
• spring dao：Data Access Object 提供了JDBC的抽象层。
• spring aop：提供了面向切面的编程实现，让你可以自定义拦截器、切点等。
• spring Web：提供了针对 Web 开发的集成特性，例如文件上传，利用 servlet listeners 进行 ioc 容器初始化和针对 Web 的 ApplicationContext。
• spring Web mvc：spring 中的 mvc 封装包提供了 Web 应用的 Model-View-Controller（MVC）的实现。

spring 常用的注入方式有哪些？

• setter 属性注入
• 构造方法注入
• 注解方式注入

spring 中的 bean 是线程安全的吗？

spring 中的 bean 默认是单例模式，spring 框架并没有对单例 bean 进行多线程的封装处理。

实际上大部分时候 spring bean 无状态的（比如 dao 类），所有某种程度上来说 bean 也是安全的，但如果 bean 有状态的话（比如 view model 对象），那就要开发者自己去保证线程安全了，最简单的就是改变 bean 的作用域，把“singleton”变更为“prototype”，这样请求 bean 相当于 new Bean()了，所以就可以保证线程安全了。

• 有状态就是有数据存储功能。
• 无状态就是不会保存数据。

spring 支持几种 bean 的作用域？

spring 支持 5 种作用域，如下：

• singleton：spring ioc 容器中只存在一个 bean 实例，bean 以单例模式存在，是系统默认值；
• prototype：每次从容器调用 bean 时都会创建一个新的示例，既每次 getBean()相当于执行 new Bean()操作；
• Web 环境下的作用域：
• request：每次 http 请求都会创建一个 bean；
• session：同一个 http session 共享一个 bean 实例；
• global-session：用于 portlet 容器，因为每个 portlet 有单独的 session，globalsession 提供一个全局性的 http session。

「注意：」 使用 prototype 作用域需要慎重的思考，因为频繁创建和销毁 bean 会带来很大的性能开销。

spring 自动装配 bean 有哪些方式？

• no：默认值，表示没有自动装配，应使用显式 bean 引用进行装配。
• byName：它根据 bean 的名称注入对象依赖项。
• byType：它根据类型注入对象依赖项。
• 构造函数：通过构造函数来注入依赖项，需要设置大量的参数。
• autodetect：容器首先通过构造函数使用 autowire 装配，如果不能，则通过 byType 自动装配。

spring 事务实现方式有哪些？

• 声明式事务：声明式事务也有两种实现方式，基于 xml 配置文件的方式和注解方式（在类上添加 @Transaction 注解）。
• 编码方式：提供编码的形式管理和维护事务。

spring 的事务隔离？

spring 有五大隔离级别，默认值为 ISOLATION_DEFAULT（使用数据库的设置），其他四个隔离级别和数据库的隔离级别一致：

• ISOLATION_DEFAULT：用底层数据库的设置隔离级别，数据库设置的是什么我就用什么；
• ISOLATIONREADUNCOMMITTED：未提交读，最低隔离级别、事务未提交前，就可被其他事务读取（会出现幻读、脏读、不可重复读）；
• ISOLATIONREADCOMMITTED：提交读，一个事务提交后才能被其他事务读取到（会造成幻读、不可重复读），SQL server 的默认级别；
• ISOLATIONREPEATABLEREAD：可重复读，保证多次读取同一个数据时，其值都和事务开始时候的内容是一致，禁止读取到别的事务未提交的数据（会造成幻读），MySQL 的默认级别；
• ISOLATION_SERIALIZABLE：序列化，代价最高最可靠的隔离级别，该隔离级别能防止脏读、不可重复读、幻读。

• 「脏读」 ：表示一个事务能够读取另一个事务中还未提交的数据。比如，某个事务尝试插入记录 A，此时该事务还未提交，然后另一个事务尝试读取到了记录 A。
• 「不可重复读」 ：是指在一个事务内，多次读同一数据。
• 「幻读」 ：指同一个事务内多次查询返回的结果集不一样。比如同一个事务 A 第一次查询时候有 n 条记录，但是第二次同等条件下查询却有 n+1 条记录，这就好像产生了幻觉。发生幻读的原因也是另外一个事务新增或者删除或者修改了第一个事务结果集里面的数据，同一个记录的数据内容被修改了，所有数据行的记录就变多或者变少了。

spring事务的传播方式

事务传播行为（Propagation）

决定调用另一个带事务的方法时，是加入当前事务还是新建事务。

常见误区：REQUIRES_NEW 会让内部事务与外部事务完全独立，内部回滚不影响外部，外部回滚也不影响已提交的内部事务。

spring mvc 运行流程？

• spring mvc 先将请求发送给 DispatcherServlet。
• DispatcherServlet 查询一个或多个 HandlerMapping，找到处理请求的 Controller。
• DispatcherServlet 再把请求提交到对应的 Controller。
• Controller 进行业务逻辑处理后，会返回一个ModelAndView。
• Dispathcher 查询一个或多个 ViewResolver 视图解析器，找到 ModelAndView 对象指定的视图对象。
• 视图对象负责渲染返回给客户端。

spring mvc 有哪些组件？

• 前置控制器 DispatcherServlet。
• 映射控制器 HandlerMapping。
• 处理器 Controller。
• 模型和视图 ModelAndView。
• 视图解析器 ViewResolver。

@RequestMapping 的作用是什么？

将 http 请求映射到相应的类/方法上。

@Autowired 的作用是什么？

@Autowired 它可以对类成员变量、方法及构造函数进行标注，完成自动装配的工作，通过@Autowired 的使用来消除 set/get 方法。

@Autowired和@Resource注解的区别

@Autowired与@Resource都可以用来装配bean，都可以写在属性或set方法上,@Autowired还可以写在构造方法上,@Resource不可以

1、@Autowired

由Spring提供，只按照类型自动注入

2、@Resource

由J2EE提供，默认按照名称自动注入

@Resource有两个属性：name和type

@Resource装配顺序：

1. 如果同时指定了name和type，则从Spring上下文中找到唯一匹配的bean进行装配，找不到则抛出异常
2. 如果指定了name，则从Spring上下文中查找名称匹配的bean进行装配，找不到则抛出异常
3. 如果指定了type，则从Spring上下文中找到类型匹配的bean进行装配，找不到或找到多个，都抛出异常

Spring Boot/Spring Cloud

什么是 spring boot？

spring boot 是为 spring 服务的，是用来简化新 spring 应用的初始搭建以及开发过程的。

为什么要用 spring boot？

• 配置简单
• 独立运行
• 自动装配
• 无代码生成和 xml 配置
• 提供应用监控
• 易上手
• 提升开发效率

spring boot 核心配置文件是什么？

spring boot 核心的两个配置文件：

• bootstrap (. yml 或者 . properties)：boostrap 由父 ApplicationContext 加载的，比 applicaton 优先加载，且 boostrap 里面的属性不能被覆盖；
• application (. yml 或者 . properties)：用于 spring boot 项目的自动化配置。

spring boot 配置文件有哪几种类型？它们有什么区别？

配置文件有 . properties 格式和 . yml 格式，它们主要的区别是书法风格不同。

. properties 配置如下：

spring.RabbitMQ.port=5672

. yml 配置如下：

spring:
    RabbitMQ:
        port: 5672

yml 格式不支持 @PropertySource 注解导入。

spring boot 有哪些方式可以实现热部署？

• 使用 devtools 启动热部署，添加 devtools 库，在配置文件中把 spring. devtools. restart. enabled 设置为 true；
• 使用 Intellij Idea 编辑器，勾上自动编译或手动重新编译。

jpa 和 hibernate 有什么区别？

jpa 全称 Java Persistence API，是 Java 持久化接口规范，hibernate 属于 jpa 的具体实现。

什么是 spring cloud？

spring cloud 是一系列框架的有序集合。它利用 spring boot 的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用 spring boot 的开发风格做到一键启动和部署。

spring cloud 断路器的作用是什么？

在分布式架构中，断路器模式的作用也是类似的，当某个服务单元发生故障（类似用电器发生短路）之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个错误响应，而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延。

spring cloud 的核心组件有哪些？

• Eureka：服务注册于发现。
• Feign：基于动态代理机制，根据注解和选择的机器，拼接请求 url 地址，发起请求。
• Ribbon：实现负载均衡，从一个服务的多台机器中选择一台。
• Hystrix：提供线程池，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题。
• Zuul：网关管理，由 Zuul 网关转发请求给对应的服务。

Spring循环依赖怎么解决的？

Spring通过三级缓存解决单例Bean的循环依赖（主要是构造器注入无法解决）：

• 一级缓存：singletonObjects，存放完全初始化好的Bean。
• 二级缓存：earlySingletonObjects，存放提前暴露的早期对象（尚未填充属性）。
• 三级缓存：singletonFactories，存放Bean工厂，用于生成早期对象的引用。
• 过程：A依赖B，B依赖A。创建A时，将A的工厂放入三级缓存，然后填充属性时发现依赖B，去创建B；B创建时依赖A，从三级缓存获取A的工厂生成早期A（放入二级缓存），B完成注入后创建完毕，然后A从二级缓存拿到B的引用，完成后续初始化。最终A放入一级缓存。

详细说明：

Spring 框架为了解决单例作用域下的循环依赖问题，设计了一套基于 三级缓存 的机制。下面将详细解释其原理、步骤以及为什么需要三级缓存。

1. 什么是循环依赖

循环依赖是指两个或多个 Bean 之间互相持有对方的引用，形成一个闭环。例如：

• A 依赖 B，B 依赖 A（最简单的循环依赖）。
• A 依赖 B，B 依赖 C，C 依赖 A（更复杂的循环）。

在创建 Bean 时，如果容器无法打破这个环，就会陷入无限递归，最终导致 BeanCurrentlyInCreationException。

2. Spring 能解决哪些循环依赖

Spring 仅能解决 以下条件的循环依赖：

• Bean 的作用域是 单例（singleton）
• 依赖注入的方式为 setter 注入 或 字段注入（@Autowired）
  （因为这两种方式可以在对象实例化后，再设置属性）
• 不能解决 构造函数注入 的循环依赖（因为构造函数必须在实例化时完成所有参数的注入，此时对象尚未创建，无法提前暴露）。

3. 三级缓存的内部结构

Spring 容器内部维护了三个缓存，用于存放不同阶段的 Bean 实例：

这三个缓存对应 Spring 的 DefaultSingletonBeanRegistry 类中的三个成员变量：

// 一级
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);          
// 二级
private final Map<String, Object> earlySingletonObjects = new ConcurrentHashMap<>(16);     
// 三级
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);        

4. 解决循环依赖的流程（以 A 依赖 B，B 依赖 A 为例）

假设两个 Bean 都是通过 setter 注入，且作用域为单例。

至此，循环依赖被完美解决，两个 Bean 都已完成创建并存于一级缓存。

5. 为什么需要三级缓存，而不是两级？

6. 哪些循环依赖 Spring 无法解决？

• 构造函数注入：因为构造函数必须在实例化时完成，无法提前暴露对象，无法打破循环。
• 非单例作用域（prototype）：Spring 不缓存 prototype 的 Bean，每次请求都新建，因此无法提前暴露，也无法解决循环依赖。
• 多例混合：比如 singleton 依赖 prototype，但反过来则无法解决。

对于构造函数注入的循环依赖，可以改用 setter 注入，或者使用 @Lazy 注解延迟加载其中一个依赖。

7. 源码简要追溯

主要逻辑集中在 AbstractBeanFactory.doGetBean() 和 DefaultSingletonBeanRegistry.getSingleton() 方法中。

getSingleton(String beanName, boolean allowEarlyReference) 方法体现了三级缓存的查找顺序：

protected Object getSingleton(String beanName, boolean allowEarlyReference) {
    Object singletonObject = this.singletonObjects.get(beanName);
    if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
        synchronized (this.singletonObjects) {
            singletonObject = this.earlySingletonObjects.get(beanName);
            if (singletonObject == null && allowEarlyReference) {
                ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
                if (singletonFactory != null) {
                    singletonObject = singletonFactory.getObject();
                    this.earlySingletonObjects.put(beanName, singletonObject);
                    this.singletonFactories.remove(beanName);
                }
            }
        }
    }
    return singletonObject;
}

当创建一个 Bean 时，在 doCreateBean 中实例化后，会调用 addSingletonFactory 将工厂放入三级缓存。

总结

Spring 通过 三级缓存 巧妙地解决了单例 setter 注入的循环依赖问题：

• 一级缓存存放完整 Bean。
• 二级缓存存放提前暴露的 Bean（半成品）。
• 三级缓存存放生产 Bean 的工厂，用于在必要时提前生成代理对象，避免 AOP 失效。

这种设计既保证了循环依赖的解决，又兼顾了 AOP 等增强功能的正确性。

@Lazy延迟加载

@Lazy 是 Spring 提供的一个灵活控制 Bean 生命周期的注解，主要用途包括：

• 性能优化：延迟非必要 Bean 的初始化，加快启动速度。
• 打破循环依赖：特别是解决构造器注入导致的循环依赖。
• 按需加载：让资源消耗较大的 Bean 在真正需要时才创建。

工作原理

Spring 容器在启动时，对于延迟加载的 Bean，并不会立即调用其构造方法和初始化逻辑，而是：

• 对于 @Lazy 标注的类或 @Bean 方法：容器会将这些 Bean 的创建推迟到第一次调用 getBean() 获取它们时。但在容器启动阶段，它们会被记录下来，但不会实例化。
• 对于注入点上使用 @Lazy：Spring 会生成一个代理对象（基于 CGLIB 或 JDK 动态代理）并注入到目标 Bean 中。该代理对象会拦截所有方法调用，在首次调用时触发目标 Bean 的创建和初始化，然后将调用委派给真实的 Bean 实例。

正是通过这种代理机制，@Lazy 才能在不破坏依赖关系的情况下实现延迟加载。

CGLIB 与 JDK 动态代理

• JDK 动态代理 是 Java 原生提供的，基于接口的代理，适合接口设计良好的场景。
• CGLIB 代理 通过生成子类实现代理，更加灵活，适合没有接口的类或需要更细粒度控制的场景。
• Spring 根据目标类是否有接口自动选择，也允许强制使用 CGLIB。
• 在实际开发中，如果使用 Spring Boot 2.x，默认 CGLIB 模式可以避免接口定义，使代码更简洁。

SpringBoot 的核心注解是哪个？

核心注解是 @SpringBootApplication 。通常标注在项目的主启动类上。

SpringBootApplication注解包含哪几个注解？

它是一个组合注解，主要包含以下三个核心注解 ：

1. @SpringBootConfiguration：继承自 @Configuration，表示该类是一个配置类。
2. @EnableAutoConfiguration：开启自动配置功能。
3. @ComponentScan：启用组件扫描，默认扫描主启动类所在包及其子包。

SpringBoot最核心的注解有哪些？

除了上面的 @SpringBootApplication 组合注解外，还有：

• @EnableAutoConfiguration：自动配置的核心。
• @Conditional 系列注解：如 @ConditionalOnClass、@ConditionalOnMissingBean，用于控制自动配置在满足特定条件时才生效 。
• @ConfigurationProperties：用于将配置文件（如 application.yml）中的属性绑定到 Java Bean 上 。

SpringBoot自动配置原理是什么？

原理主要基于 @EnableAutoConfiguration 注解 。它会通过 SpringFactoriesLoader 机制，从 classpath 下所有 JAR 包中的 META-INF/spring.factories 文件里，加载 EnableAutoConfiguration 键对应的自动配置类（如 XxxAutoConfiguration）。这些配置类上通常标有 @Conditional 条件注解，只有满足特定条件（如存在相关类、配置了相关属性）时，这些自动配置类才会生效，实例化相应的 Bean。

SpringBoot开启自动配置的原理是什么？

只需要在配置类上使用 @EnableAutoConfiguration 注解即可。由于 @SpringBootApplication 已经组合了该注解，所以只要在启动类上标记 @SpringBootApplication，就相当于开启了自动配置 。

SpringBoot自动配置的类型在哪注册？

自动配置类（类型）的注册信息存放在所有 JAR 包中的 META-INF/spring.factories 文件中 。Spring Boot 启动时会扫描该文件，获取所有注册的自动配置类的全限定名。

SpringBoot自动配置报告怎么查看？

开启 debug 模式。在配置文件（application.properties 或 application.yml）中设置 debug: true。启动应用后，控制台会打印 Positive matches（生效的自动配置）和 Negative matches（未生效的自动配置）报告，方便开发者了解哪些自动配置类被应用了。

SpringBoot怎么排除某些自动配置？

有多种方式可以排除自动配置类 ：

1. 在 @SpringBootApplication 或 @EnableAutoConfiguration 注解中使用 exclude 属性：@SpringBootApplication(exclude = {DataSourceAutoConfiguration.class})
2. 在配置文件中使用 spring.autoconfigure.exclude 属性：spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration

SpringBoot怎么开启和关闭自动配置？

• 开启：使用 @EnableAutoConfiguration 注解（通常通过 @SpringBootApplication 间接使用）。
• 关闭：一般不建议完全关闭自动配置。如果想禁用特定的自动配置，可以使用排除（exclude）机制。如果不想使用整个 Spring Boot 的自动配置特性，可以不使用 @EnableAutoConfiguration 注解，但这会丧失 Spring Boot 的核心优势。

SpringBoot的目录结构是怎样的？

一个典型的 Spring Boot 项目目录结构遵循一定的约定 ：

com.example.project
├── Application.java (主启动类，位于根包下)
├── domain/ (或 model) - 实体类
├── repository/ (或 dao) - 数据访问层
├── service/ - 业务逻辑层
│   └── impl/ - 业务实现类
└── web/ (或 controller) - 控制器层

此外，资源文件位于 src/main/resources 目录下，包含：

• application.properties 或 application.yml：配置文件。
• static/：存放静态资源（如 CSS, JS, 图片）。
• templates/：存放模板文件（如 Thymeleaf）。

SpringBoot中的Starters是什么？

Starters 是一组方便的依赖描述符 。它相当于一个“一站式”的依赖集合。例如，引入 spring-boot-starter-web 依赖，它就会自动传递引入构建 Web 应用所需的所有依赖（如 Spring MVC、内嵌 Tomcat、Jackson 等），避免了开发者手动寻找和配置一个个兼容版本的依赖，极大地简化了项目的依赖管理 。

IOC容器与Bean生命周期

Spring的三级缓存是如何解决循环依赖的？为什么二级缓存不够？

• 三级缓存定义：
  • 一级缓存 singletonObjects：存放完全初始化的单例Bean（成品池）
  • 二级缓存 earlySingletonObjects：存放提前暴露的Bean实例（半成品，属性未完全填充）
  • 三级缓存 singletonFactories：存放 ObjectFactory 工厂，用于生成Bean的早期引用
• 解决流程（以A依赖B、B依赖A为例） ：
  1. 实例化A，将A的ObjectFactory放入三级缓存
  2. 填充A属性时发现需要B，去获取B
  3. 实例化B，填充B属性时发现需要A，从三级缓存取出A的ObjectFactory生成A的引用放入二级缓存
  4. B完成初始化放入一级缓存
  5. A获取B引用完成初始化
• 为什么必须三级缓存：
  • 二级缓存不行，因为Spring需要在“提前暴露Bean”时兼容AOP代理的创建时机。若只有二级缓存，代理对象无法在实例化后、依赖注入前被正确创建。三级缓存的ObjectFactory允许在获取早期引用时动态决定返回原始对象还是代理对象。
• 无法解决的循环依赖：
  • 构造器注入的循环依赖（实例化阶段即死锁）
  • prototype作用域的循环依赖（每次getBean都创建新实例，无限递归导致OOM）

请完整描述Spring Bean的生命周期，并列举核心扩展点。

• 四大核心阶段（非死记硬背的10步）：

• 面试加分扩展点：
  • BeanFactoryPostProcessor：在Bean定义加载后、实例化前执行，可修改BeanDefinition（如修改作用域、属性值）
  • BeanPostProcessor：在Bean初始化前后执行，Spring AOP就是通过它创建代理对象的
  • Aware接口：BeanNameAware、BeanFactoryAware、ApplicationContextAware等，让Bean感知容器

BeanFactory和FactoryBean的区别是什么？

• BeanFactory：Spring IOC容器的根接口，负责管理和提供Bean实例，采用懒加载策略
• FactoryBean：是一个特殊的Bean，用于自定义复杂对象的创建逻辑
• 关键区别：
  • 通过 getBean("beanName") 获取的是 FactoryBean生产的对象，而非FactoryBean本身
  • 若要获取FactoryBean实例本身，需使用 &beanName 前缀
  • 典型应用：MyBatis的 SqlSessionFactoryBean、Spring的 ProxyFactoryBean

AOP面向切面编程

Spring AOP的底层实现原理是什么？JDK动态代理和CGLIB如何选择？

Spring AOP基于动态代理在运行时生成代理对象，将切面逻辑织入。代理创建需要三个核心信息：拦截器数组、目标对象接口数组、目标对象。

• Spring选择逻辑：DefaultAopProxyFactory 根据目标类是否实现接口决定
• AOP与AspectJ的区别：Spring AOP是运行时增强（仅方法级），AspectJ是编译时/类加载时增强（支持字段、构造器等更细粒度）

多个切面是如何形成责任链的？

Spring AOP通过 Advisor（通知器） 将Advice和Pointcut封装，多个切面按 @Order 排序后，通过责任链模式（ReflectiveMethodInvocation）依次执行。环绕通知（@Around）通过 ProceedingJoinPoint.proceed() 控制是否继续执行下一个拦截器或目标方法。

为什么类内部方法调用时AOP不生效？

根本原因：内部调用绕过了代理对象。Spring AOP基于代理，只有通过代理对象调用方法时切面才生效。

解决方案：

1. 将方法拆分到独立的Bean中
2. 通过 ApplicationContext.getBean() 获取代理对象再调用
3. 使用 AopContext.currentProxy() 获取当前代理
4. 使用AspectJ的编译时织入（<mode>aspectj</mode>）

事务管理

@Transactional在哪些情况下会失效？请列举全部场景。

Spring事务的传播机制有哪些？REQUIRED和REQUIRES_NEW的区别？

Spring定义了7种传播行为：

核心区别：

• REQUIRED：内外方法共享同一个事务，内方法异常会导致全部回滚
• REQUIRES_NEW：内外方法各自独立事务，内方法异常不影响外方法（但需注意：内方法异常必须被外方法catch，否则异常传播出去仍会导致外方法回滚）

Spring事务的底层原理是什么？

声明式事务的本质是AOP。核心执行链路：

1. TransactionInterceptor 拦截事务方法（AOP环绕通知）
2. 通过 PlatformTransactionManager 获取事务：
   • getTransaction()：根据传播行为决定新建/加入事务
   • 常见实现：DataSourceTransactionManager（JDBC/MyBatis）、JpaTransactionManager（JPA/Hibernate）
3. 执行目标方法
4. 异常时 rollback()，正常时 commit()

Spring事务本质是数据库事务的封装，依赖数据库的 redo log 和 undo log 实现提交与回滚。Spring只提供统一管理接口，具体由数据库实现。

Spring Boot与自动装配

Spring Boot的自动装配原理是什么？

核心入口是 @SpringBootApplication，它是一个三合一注解：

• @SpringBootConfiguration：标识配置类
• @ComponentScan：扫描启动类所在包及其子包
• @EnableAutoConfiguration：核心，负责加载自动配置类

执行流程：

1. @EnableAutoConfiguration 通过 @Import 导入 AutoConfigurationImportSelector
2. AutoConfigurationImportSelector.selectImports() 加载候选配置类

配置文件加载（版本差异） ：

• Spring Boot 2.x：读取 META-INF/spring.factories
• Spring Boot 3.x：读取 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports（纯文本行，启动更快）

条件过滤：加载的配置类通过 @Conditional系列注解 按需生效。例如 RedisAutoConfiguration 上有 @ConditionalOnClass(RedisOperations.class)，只有引入Redis依赖时才会生效。

@Conditional系列注解有哪些？各自的作用是什么？

@Conditional是条件装配的元注解，满足条件才注入Bean。

Spring扩展机制与进阶

Spring的事件监听机制是如何实现的？

基于观察者模式，三个核心角色：

• 事件：继承 ApplicationEvent
• 事件发布者：ApplicationEventPublisher.publishEvent()
• 事件监听器：实现 ApplicationListener 接口 或使用 @EventListener 注解

注意：默认是同步单线程执行。若需异步，需配置 @Async + 线程池。

Spring中Bean的作用域有哪些？

Spring MVC的请求处理流程是怎样的？

1. 客户端发起HTTP请求
2. DispatcherServlet（前端控制器） 接收请求
3. HandlerMapping 根据请求URL找到对应的Controller和方法
4. HandlerAdapter 执行Controller方法
5. Controller返回ModelAndView（或JSON数据）
6. ViewResolver 解析视图并渲染响应

核心九大组件包括：HandlerMapping、HandlerAdapter、ViewResolver、HandlerExceptionResolver 等。

在 Ubuntu 24.04 桌面版中，出于系统安全考虑，root 用户是被默认禁止直接登录图形界面的。如果你确实需要以 root 身份操作桌面，可以按照以下步骤进行配置。

重要提示：启用 root 账户登录会带来极大的安全风险。root 拥有系统的最高权限，任何误操作（如误删系统文件）都可能导致系统崩溃或数据丢失。建议仅在必要时（如系统维护、特定测试）开启，用完即关。

操作步骤

第一步：为 root 用户设置密码

首先，你需要为 root 账户激活一个密码。打开终端，执行以下命令：

sudo passwd root

系统会提示你输入并确认新的 root 密码。输入密码时屏幕不会有任何显示，这是正常的。

第二步：修改 GDM 配置文件

GDM (GNOME Display Manager) 是 Ubuntu 的登录管理器，需要修改其配置以允许 root 登录。

1. 使用 nano 编辑器打开配置文件（你也可以用 vim 或 gedit 替代 nano）：
   sudo nano /etc/gdm3/custom.conf
2. 在文件中找到 [security] 这一行。如果找不到，可以手动在文件末尾添加。在 [security] 下方添加一行，内容如下：
   [security]
AllowRoot=true
3. 按 Ctrl+O 保存文件，然后按 Ctrl+X 退出编辑器。

第三步：修改 PAM 认证配置

PAM (Pluggable Authentication Modules) 是系统的认证模块，它里面有一条规则明确禁止 root 登录图形界面，我们需要把它注释掉。

1. 编辑第一个 PAM 文件：
   sudo nano /etc/pam.d/gdm-password
   找到下面这一行，并在行首添加一个 # 号将其注释掉：
   # auth required pam_succeed_if.so user != root quiet_success
   保存并退出 (Ctrl+O, Ctrl+X)。
2. 用同样的方法编辑第二个 PAM 文件：
   sudo nano /etc/pam.d/gdm-autologin
   同样找到并注释掉这一行：
   # auth required pam_succeed_if.so user != root quiet_success
   保存并退出。

第四步：（可选）修复 root 用户的环境配置文件

首次以 root 登录时，可能会遇到一个关于 /.profile 文件的错误提示。为了避免这个问题，可以提前修复它。

1. 编辑 root 目录下的 .profile 文件：
   sudo nano /root/.profile
2. 找到文件的最后一行，通常是：
   mesg n 2> /dev/null || true
3. 将其修改为：
   tty -s && mesg n || true
   保存并退出。

第五步：重启系统

所有配置完成后，需要重启系统以使更改生效：

sudo reboot

第六步：以 root 身份登录

系统重启后，在登录界面，你会发现列表中没有 root 用户。此时，需要点击 “未列出？” 或者 “Other” 选项。

在弹出的输入框中，用户名输入 root，密码输入你在第一步设置的密码，即可登录到 GNOME 桌面。

完成后的小建议
完成你的工作后，为了系统安全，建议你按照操作步骤的反向操作，将配置改回去（即注释掉 AllowRoot=true，并恢复 PAM 文件中被注释的行），然后重启系统，恢复使用普通用户。

脚本执行

上述文件包含

enable-root-login.sh 是开启root权限的一键脚本
disable-root-login.sh 是关闭root登陆权限的一键脚本

1. 赋予执行权限：

chmod +x enable-root-login.sh
或者
chmod +x disable-root-login.sh

2.用 sudo 执行：

sudo ./enable-root-login.sh
或者
sudo ./disable-root-login.sh

脚本执行成功后

点击”未列出?”，就可以使用root用户，用执行命令行所填的密码来登录ubuntu桌面版系统了

https://accounts.feishu.cn/accounts/page/login?app_id=7&no_trap=1&redirect_uri=https%3A%2F%2Fopen.feishu.cn%2Fapp

扫描二维码登录自己的飞书账号

进入后点击“创建企业自建应用”

点击机器人下面的“+添加”

配置权限管理

批量导入权限，将下面json粘贴进框里

{
  "scopes": {
    "tenant": [
      "im:message",
      "im:message.group_at_msg:readonly",
      "im:message.p2p_msg:readonly",
      "im:message:send_as_bot",
      "im:resource",
      "contact:user.employee_id:readonly"
    ],
    "user": []
  }
}

申请开通权限

配置完成后，将app id，和app secret复制下来

在OpenClaw的配置步骤中将上图的对应配置贴入

配置完OpenClaw后，执行openclaw gateway启动OpenClaw

返回飞书页面，进入下图菜单，点击红框按钮，配置事件与回调

选择“消息与群组”，勾选“接受消息”

完成后点击红框中的“创建版本”

填写版本号和更新说明

发布版本后，飞书消息列表“开发者小助手”提示应用审批通过，点击“打开应用”

第一次对话，“弹出以下”聊天信息

将消息最后一行复制，贴入命令行窗口，执行

命令执行成功后，执行命令 openclaw gateway restart 重启OpenClaw

重启成功后机器人就可以正常对话聊天

本文为Linux环境安装，Windows环境博主未作尝试，见谅！

在Windows中使用虚拟机安装，建议内存>32G，且系统在Windows10以上，需要开启Windows系统自带的Hyper-v虚拟机程序，本文对如何使用Hyper-v不再多做赘述。

出于安全考虑和第一次尝鲜，博主的OpenClaw是安装在Windows系统下Hyper-v虚拟机中，部署的是ubuntu-24.04.1-desktop-amd64操作系统。
Ubuntu虚拟机要求：建议 2核CPU、4GB内存以上，40GB可用磁盘空间（可视情况扩展）
博主使用的是：10核CPU、8GB动态内存，120GB可用磁盘空间

关键字：
OpenClaw 2026.3.8、Windows、Hyper-v虚拟机、ubuntu-24.04.1-desktop、
Linux、minimax 2.5、飞书（feishu）

以下是博主踩坑后总结的安装流程

安装前准备工作：

申请大模型api：根据自己的喜好选择。（博主使用的是minimax2.5 模型试用）

飞书的聊天机器人配置

获取Ubuntu的最高root权限：（因为龙虾可能需要很高的操作权限，所以安置在root下）
命令行登录后 使用
sudo -i
输入登录用户密码后，进入root用户权限

创建root用户：https://blog.lhyshome.com/2026/03/11/377/

更新系统与安装基础工具：
打开终端，逐行执行以下命令，确保系统包是最新的，并安装 curl 和 wget 等必要工具。
apt update && sudo apt upgrade -y
apt install -y curl wget git python3 build-essential

安装 Node.js：
OpenClaw 的核心依赖是 Node.js，必须安装 22.x 或更高版本。通过官方源安装是最稳定的方法。
# 添加 NodeSource 22.x 仓库
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
# 安装 Node.js 和 npm
apt install -y nodejs
# 验证安装版本
node --version # 应输出 v22.x.x

（可选）国内环境优化：
如果你在境内，执行以下命令将 npm 镜像源切换到淘宝源，可以大幅提升下载速度和成功率。
npm config set registry https://registry.npmmirror.com

安装OpenClaw：

官方一键安装脚本（最推荐）这个脚本会自动完成Node.js检测、CLI安装，并立即启动配置向导。

curl -fsSL https://openclaw.ai/install.sh | bash

配置OpenClaw：（以下是博主的配置，可以参考）

安装完成后命令行自动进入配置安装，后续也可以使用 openclaw onboard 命令进行配置

点击链接，进入页面后选择授权

此处注意和飞书中的先后次序（可以参考：https://blog.lhyshome.com/2026/03/11/416/），要是配置错误页没关系，可以重复执行openclaw onboard 命令进行配置

在安装了OpenClaw的服务器上打开红框中的地址即可访问OpenClaw的webUI页面

执行命令：openclaw gateway

频道中显示飞书

代理中显示minimax，则执行成功

至此安装配置完成

安装技能（skills）

https://clawhub.ai/skills?sort=downloads

进入这个链接，里面为技能库，可以在这里挑选自己所需要的技能

例如：

iStoreOS的openclash，运行模式选择“TUN”或者“混合”时，提示：警告：TUN 接口启动失败，尝试重启内核…，导致openclash一直重启，内网以旁路由为网关的虚拟机和服务，访问互联网和外网都出现了无法打开的情况。

访问各大大模型无果后，百度搜索关键字，发现github上已有相关问题处理

地址为：https://github.com/vernesong/OpenClash/issues/4492

使用如上图方法处理成功。

处理步骤

执行 “ip link show”命令，如下图发现error

在系统->杂项设置 中，将镜像服务器选择如下图所示。（如果不选，则影响opkg update执行）

选择镜像源后依次执行

opkg update

opkg install –force-reinstall ip-full

如上两图，控制台中未见明确error相关字眼为成功

重新执行“ip link show”命令，如下图为成功

重启openclash后日志显示成功，测试成功

Redis 是一个使用 C 语言开发的高速缓存数据库。

Redis 使用场景：

• 记录帖子点赞数、点击数、评论数；
• 缓存近期热帖；
• 缓存文章详情信息；
• 记录用户会话信息。

Redis 有哪些功能？

• 数据缓存功能
• 分布式锁的功能
• 支持数据持久化
• 支持事务
• 支持消息队列

Redis 和 memcache 有什么区别？

• 存储方式不同：memcache 把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小；Redis 有部份存在硬盘上，这样能保证数据的持久性。
• 数据支持类型：memcache 对数据类型支持相对简单；Redis 有复杂的数据类型。
• 使用底层模型不同：它们之间底层实现方式，以及与客户端之间通信的应用协议不一样，Redis 自己构建了 vm 机制，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。
• value 值大小不同：Redis 最大可以达到 512mb；memcache 只有 1mb。

Redis 为什么是单线程的？

因为 cpu 不是 Redis 的瓶颈，Redis 的瓶颈最有可能是机器内存或者网络带宽。既然单线程容易实现，而且 cpu 又不会成为瓶颈，那就顺理成章地采用单线程的方案了。

关于 Redis 的性能，官方网站也有，普通笔记本轻松处理每秒几十万的请求。

而且单线程并不代表就慢 nginx 和 nodejs 也都是高性能单线程的代表。

什么是缓存穿透？怎么解决？

缓存穿透：指查询一个一定不存在的数据，由于缓存是不命中时需要从数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，造成缓存穿透。

解决方案：最简单粗暴的方法如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们就把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

Redis 支持的数据类型有哪些？

Redis 支持的数据类型：string（字符串）、list（列表）、hash（字典）、set（集合）、zset（有序集合）。

Redis 支持的 Java 客户端都有哪些？

支持的 Java 客户端有 Redisson、jedis、lettuce 等。

jedis 和 Redisson 有哪些区别？

• jedis：提供了比较全面的 Redis 命令的支持。
• Redisson：实现了分布式和可扩展的 Java 数据结构，与 jedis 相比 Redisson 的功能相对简单，不支持排序、事务、管道、分区等 Redis 特性。

怎么保证缓存和数据库数据的一致性？

• 合理设置缓存的过期时间。
• 新增、更改、删除数据库操作时同步更新 Redis，可以使用事物机制来保证数据的一致性。

Redis 持久化有几种方式？

Redis 的持久化有两种方式，或者说有两种策略：

• RDB（Redis Database）：指定的时间间隔能对你的数据进行快照存储。
• AOF（Append Only File）：每一个收到的写命令都通过write函数追加到文件中。

Redis 怎么实现分布式锁？

Redis 分布式锁其实就是在系统里面占一个“坑”，其他程序也要占“坑”的时候，占用成功了就可以继续执行，失败了就只能放弃或稍后重试。

占坑一般使用 setnx(set if not exists)指令，只允许被一个程序占有，使用完调用 del 释放锁。

Redis 分布式锁有什么缺陷？

Redis 分布式锁不能解决超时的问题，分布式锁有一个超时时间，程序的执行如果超出了锁的超时时间就会出现问题。

Redis 如何做内存优化？

尽量使用 Redis 的散列表，把相关的信息放到散列表里面存储，而不是把每个字段单独存储，这样可以有效的减少内存使用。比如将 Web 系统的用户对象，应该放到散列表里面再整体存储到 Redis，而不是把用户的姓名、年龄、密码、邮箱等字段分别设置 key 进行存储。

Redis 淘汰策略有哪些？

• volatile-lru：从已设置过期时间的数据集（server. db[i]. expires）中挑选最近最少使用的数据淘汰。
• volatile-ttl：从已设置过期时间的数据集（server. db[i]. expires）中挑选将要过期的数据淘汰。
• volatile-random：从已设置过期时间的数据集（server. db[i]. expires）中任意选择数据淘汰。
• allkeys-lru：从数据集（server. db[i]. dict）中挑选最近最少使用的数据淘汰。
• allkeys-random：从数据集（server. db[i]. dict）中任意选择数据淘汰。
• no-enviction（驱逐）：禁止驱逐数据。

Redis 常见的性能问题有哪些？该如何解决？

• 主服务器写内存快照，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以主服务器最好不要写内存快照。
• Redis 主从复制的性能问题，为了主从复制的速度和连接的稳定性，主从库最好在同一个局域网内。

什么是Redis

• Redis(Remote Dictionary Server) 是一个使用 C 语言编写的，开源的（BSD许 可）高性能非关系型（NoSQL）的键值对数据库。
• Redis 可以存储键和五种不同类型的值之间的映射。键的类型只能为字符串，值 支持五种数据类型：字符串、列表、集合、散列表、有序集合。
• 与传统数据库不同的是 Redis 的数据是存在内存中的，所以读写速度非常快， 因此 redis 被广泛应用于缓存方向，每秒可以处理超过 10万次读写操作，是已知性能快的Key-Value DB。
• 另外，Redis 也经常用来做分布式 锁。除此之 外，Redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。

Redis有哪些优缺点

• 优点
  • 读写性能优异， Redis能读的速度是110000次/s，写的速度是81000次/s。
  • 支持数据持久化，支持AOF和RDB两种持久化方式。
  • AOF：写日志的方式，记录每次对服务器写的操作, 当服务器重启的时候会重新执行这些命令来恢复原始的数据。例如 Mysql binlog，Hbase HLog。
  • RDB：这是一种快照的方式，它将 Redis 某时间点的数据都进行快照存储。比如 Mysql Dump 也是这种方式。
  • 支持事务，Redis的所有操作都是原子性的，同时Redis还支持对几个操作合并 后的原子性执行。
  • 数据结构丰富，除了支持string类型的value外还支持hash、set、zset、list等 数据结构。
  • 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。
• 缺点
  • 数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis 适合的场景主要局限在较小数据量的高性能操作和运算上。
  • Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求 失败，需要等待机器重启或者手动切换前端的IP才能恢复。
  • 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一 致的问题，降低了系统的可用性。
  • Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避 免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。

为什么要用 Redis/缓存

主要从“高性能”和“高并发”这两点来看待这个问题。

高性能：
假如用户第一次访问数据库中的某些数据。这个过程会比较慢，因为是从硬盘上 读取的。将该用户访问的数据存在数缓存中，这样下一次再访问这些数据的时候 就可以直接从缓存中获取了。操作缓存就是直接操作内存，所以速度相当快。如 果数据库中的对应数据改变的之后，同步改变缓存中相应的数据即可！

高并发：
直接操作缓存能够承受的请求是远远大于直接访问数据库的，所以我们可以考虑 把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接到缓存这 里而不用经过数据库。

为什么要用Redis 而不用 map/guava 做缓存?

缓存分为本地缓存和分布式缓存。以 Java 为例，使用自带的 map 或者 guava 实现的是本地缓存，主要的特点是轻量以及快速，生命周期随着 jvm 的销毁 而结束，并且在多实例的情况下，每个实例都需要各自保存一份缓存，缓存不具有一致性。
使用 redis 或 memcached 之类的称为分布式缓存，在多实例的情况下，各实 例共用一份缓存数据，缓存具有一致性。缺点是需要保持 redis 或 memcached 服务的高可用，整个程序架构上较为复杂。

Redis为什么这么快

完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存 中，类似于 HashMap，HashMap 的优势就是查找和操作的时间复杂度都是 O(1)；
数据结构简单，对数据操作也简单，Redis 中的数据结构是专门进行设计 的；
采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
使用多路 I/O 复用模型，非阻塞 IO；
使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了 VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；

Redis有哪些数据类型

Redis主要有5种数据类型，包括String，List，Set，Zset，Hash，满足大部分 的使用要求 数据类型 可以存储 的值 操作 应用场景

Redis的应用场景

7.1 总结一
计数器
可以对 String 进行自增自减运算，从而实现计数器功能。Redis 这种内存型数 据库的读写性能非常高，很适合存储频繁读写的计数量。
缓存
将热点数据放到内存中，设置内存的大使用量以及淘汰策略来保证缓存的命中率。
会话缓存
可以使用 Redis 来统一存储多台应用服务器的会话信息。当应用服务器不再存 储用户的会话信息，也就不再具有状态，一个用户可以请求任意一个应用服务 器，从而更容易实现高可用性以及可伸缩性。
全页缓存（FPC）
除基本的会话token之外，Redis还提供很简便的FPC平台。以Magento为例， Magento提供一个插件来使用Redis作为全页缓存后端。此外，对WordPress的用户来说，Pantheon有一个非常好的插件 wp-redis，这个插件能帮助你以快速度加载你曾浏览过的页面。
查找表
例如 DNS 记录就很适合使用 Redis 进行存储。查找表和缓存类似，也是利用了 Redis 快速的查找特性。但是查找表的内容不能失效，而缓存的内容可以失效， 因为缓存不作为可靠的数据来源。
消息队列(发布/订阅功能)
List 是一个双向链表，可以通过 lpush 和 rpop 写入和读取消息。不过好使用Kafka、RabbitMQ等消息中间件。
分布式锁实现
在分布式场景下，无法使用单机环境下的锁来对多个节点上的进程进行同步。可 以使用 Redis 自带的 SETNX 命令实现分布式锁，除此之外，还可以使用官方提 供的 RedLock 分布式锁实现。
其它
Set 可以实现交集、并集等操作，从而实现共同好友等功能。ZSet 可以实现有 序性操作，从而实现排行榜等功能。

7.2 总结二
Redis相比其他缓存，有一个非常大的优势，就是支持多种数据类型。
数据类型说明string字符串，简单的k-v存储hashhash格式，value为field和 value，适合ID-Detail这样的场景。list简单的list，顺序列表，支持首位或者末 尾插入数据set无序list，查找速度快，适合交集、并集、差集处理sorted set有 序的set
其实，通过上面的数据类型的特性，基本就能想到合适的应用场景了。

• string：适合简单的k-v存储，类似于memcached的存储结构，短信验证 码，配置信息等，就用这种类型来存储。
• hash：一般key为ID或者唯一标示，value对应的就是详情了。如商品详情， 个人信息详情，新闻详情等。
• list：因为list是有序的，比较适合存储一些有序且数据相对固定的数据。如省 市区表、字典表等。因为list是有序的，适合根据写入的时间来排序，如：新的***，消息队列等。
• set：可以简单的理解为ID-List的模式，如微博中一个人有哪些好友，set 牛的地方在于，可以对两个set提供交集、并集、差集操作。例如：查找两个人 共同的好友等。
• Sorted Set：是set的增强版本，增加了一个score参数，自动会根据score的 值进行排序。比较适合类似于top 10等不根据插入的时间来排序的数据。 如上所述，虽然Redis不像关系数据库那么复杂的数据结构，但是，也能适合很 多场景，比一般的缓存数据结构要多。了解每种数据结构适合的业务场景，不仅 有利于提升开发效率，也能有效利用Redis的性能。

Redis 的持久化机制是什么？各自的优缺点

持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。
Redis 提供两种持久化机制 RDB（默认） 和 AOF 机制:
RDB：是Redis DataBase缩写快照
RDB是Redis默认的持久化方式。按照一定的时间将内存的数据以快照的形式保存到硬盘中，对应产生的数据文件为dump.rdb。通过配置文件中的save参数来定义快照的周期。

优点：

1. 只有一个文件dump.rdb，方便持久化。
2. 容灾性好，一个文件可以保存到安全的磁盘。
3. 性能大化，fork子进程来完成写操作，让主进程继续处理命令，所以是 IO 大化。使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 redis 的高性能
4. 相对于数据集大时，比 AOF 的启动效率更高。

缺点：

1. 数据安全性低。RDB是间隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失。所以这种方式更适合数据要求不那么严谨的时候。
2. AOF（Append-only file)持久化方式： 是指所有的命令行记录以 redis 命 令请 求协议的格式完全持久化存储)保存为 aof 文件。

AOF：持久化

AOF持久化(即Append Only File持久化)，则是将Redis执行的每次写命令记录到单独的日志文件中，当重启Redis会重新将持久化的日志中文件恢复数据。 当两种方式同时开启时，数据恢复Redis会优先选择AOF恢复。

优点：

1. 数据安全，aof 持久化可以配置 appendfsync 属性，有 always，每进行一 次命令操作就记录到 aof 文件中一次。
2. 通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-checkaof 工具解决数据一致性问题。
3. AOF 机制的 rewrite 模式。AOF 文件没被 rewrite 之前（文件过大时会对命 令 进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）。

缺点：

1. AOF 文件比 RDB 文件大，且恢复速度慢。
2. 数据集大的时候，比 rdb 启动效率低。

优缺点是什么？

1. AOF文件比RDB更新频率高，优先使用AOF还原数据。
2. AOF比RDB更安全也更大
3. RDB性能比AOF好
4. 如果两个都配了优先加载AOF

如何选择合适的持久化方式

• 一般来说， 如果想达到足以媲美PostgreSQL的数据安全性，你应该 同时使用两种持久化功能。在这种情况下，当 Redis 重启的时候会优先载 入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集 要比RDB文件保存的数据集要完整。
• 如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用RDB持久化。
• 有很多用户都只使用AOF持久化，但并不推荐这种方式，因为定时生 成RDB快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据 集的速度也要比AOF恢复的速度要快，除此之外，使用RDB还可以避免 AOF程序的bug。
• 如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式。

Redis的过期键的删除策略（持久化）

我们都知道，Redis是key-value数据库，我们可以设置Redis中缓存的key的过期时间。Redis的过期策略就是指当Redis中缓存的key过期了，Redis如何处理。
过期策略通常有以下三种：

• 定时过期：每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。
• 惰性过期：只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。
• 定期过期：每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到优的平衡效果。
  (expires字典会保存所有设置了过期时间的key的过期时间数据，其中，key是指向键空间中的某个键的指针，value是该键的毫秒精度的UNIX时间戳表示的过期时间。键空间是指该Redis集群中保存的所有键。)

Redis中同时使用了惰性过期和定期过期两种过期策略。

我们知道通过expire来设置key 的过期时间，那么对过期的数据怎么处理呢?（针对持久化的数据）

除了缓存服务器自带的缓存失效策略之外（Redis默认的有6中策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种：

1. 定时去清理过期的缓存；
2. 当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。

两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，大家可以根据自己的应用场景来权衡。

redis内存淘汰策略是什么

redis之所以快，因为他是依赖于内存的，但内存大小非常有限，如果超过就会报错。
所以当redis内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。

Redis的内存淘汰策略有哪些

Redis的内存淘汰策略是指在Redis用于缓存的内存不足时，怎么处理需要新写入且需要申请额外空间的数据。
对全局的键空间选择性移除
当内存不足以容纳新写入数据时，有一下几种方式操作：

• noeviction：，新写入操作会报错。
• allkeys-lru：在键空间中，移除最近最少使用的key。（这个是最常用的）
• allkeys-random：在键空间中，随机移除某个key。

对设置过期时间的键空间选择性移除

• volatile-lru：在设置了过期时间的键空间中，移除最近最少使用的key。
• volatile-random：在设置了过期时间的键空间中，随机移除某个key。
• volatile-ttl：在设置了过期时间的键空间中，有更早过期时间的key优先移除。

总结

Redis的内存淘汰策略的选取并不会影响过期的key的处理。
内存淘汰策略用于处理内存不足时的需要申请额外空间的数据（针对于内存）
过期策略用于处理过期的缓存数据（针对于数据库）

Redis的内存用完了会发生什么？

如果达到设置的上限，Redis的写命令会返回错误信息（但是读命令还可以正常返回）或者你可以配置内存淘汰机制，当Redis达到内存上限时会冲刷掉旧的内容。

Redis如何做内存优化？

可以好好利用Hash,list,sorted set,set等集合类型数据，因为通常情况下很多小的Key-Value可以用更紧凑的方式存放到一起。尽可能使用散列表（hashes），散列表（是说散列表里面存储的数少）使用的内存非常小，所以你应该尽可能的将你的数据模型抽象到一个散列表里面（一个对象里面）。

例如：你的web系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key，而是应该把这个用户的所有信息存储到一张散列表里面线程模型。

什么是事务？

事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

Redis事务的概念

Redis 事务的本质是通过MULTI、EXEC、WATCH等一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端 提交的命令请求不会插入到事务执行命令序列中。

总结说：redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。

事务的基本操作

开启事务

multi
AI生成项目
shell
1
作用：设定事务的开启位置，此指令执行后，后续的所有指令均加入到事务中

执行事务

exec
AI生成项目
shell
1
作用：设定事务的结束位置，同时执行事务。与multi成对出现，成对使用

注意：加入事务的命令暂时进入到任务队列中，并没有立即执行，只有执行exec命令才开始执行

但是你在命令入队列的时候，发现你有些命令指令输入错误，你不想执行了，这个时候，你不想提交事务了

取消事务

discard
AI生成项目
shell
1
作用：终止当前事务的定义，发生在multi之后，exec之前

总结：遇到multi指令，创建队列，遇到discard指令销毁队列

事务执行过程中，如果服务端收到有EXEC、DISCARD、WATCH、MULTI之外的请求，将会把请求放入队列中排队(需要研究)

Redis事务相关命令

Redis事务功能是通过MULTI、EXEC、DISCARD和WATCH 四个原语实现的

Redis会将一个事务中的所有命令序列化，然后按顺序执行。

redis 不支持回滚，“Redis 在事务失败时不进行回滚，而是继续执行余下的命令”， 所以 Redis 的内部可以保持简单且快速。

如果在一个事务中的命令出现错误，那么所有的命令都不会执行；

如果在一个事务中出现运行错误，那么正确的命令会被执行。

WATCH命令是一个乐观锁，可以为 Redis 事务提供 check-and-set （CAS）行为。 可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行，监控一直持续到EXEC命令。

MULTI命令用于开启一个事务，它总是返回OK。 MULTI执行之后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列中，当EXEC命令被调用时，所有队列中的命令才会被执行。

EXEC：执行所有事务块内的命令。返回事务块内所有命令的返回值，按命令执行的先后顺序排列。 当操作被打断时，返回空值 nil 。

通过调用DISCARD，客户端可以清空事务队列，并放弃执行事务， 并且客户端会从事务状态中退出。

UNWATCH命令可以取消watch对所有key的监控。

Redis事务支持隔离性吗

Redis 是单进程程序，并且它保证在执行事务时，不会对事务进行中断，事务可以运行直到执行完所有事务队列中的命令为止。因此，Redis 的事务是总是带有隔离性的。

Redis事务保证原子性吗，支持回滚吗

Redis中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行。

Redis事务其他实现

基于Lua脚本，Redis可以保证脚本内的命令一次性、按顺序地执行，其同时也不提供事务运行错误的回滚，执行过程中如果部分命令运行错误，剩下的命令还是会继续运行完

基于中间标记变量，通过另外的标记变量来标识事务是否执行完成，读取数据时先读取该标记变量判断是否事务执行完成。但这样会需要额外写代码实现，比较繁琐集群方案哨兵模式

哨兵的介绍

sentinel，中文名是哨兵。哨兵是 redis 集群机构中非常重要的一个组件，主要有以下功能：

• 集群监控：负责监控 redis master 和 slave 进程是否正常工作。
• 消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
• 故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。
• 配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。

哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。
故障转移时，判断一个 master node 是否宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题。
即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了。

哨兵的核心知识

• 哨兵至少需要 3 个实例，来保证自己的健壮性。
• 哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。
• 对于哨兵 + redis 主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。

官方Redis Cluster 方案(服务端路由查询)

redis 集群模式的工作原理能说一下么？在集群模式下，redis 的 key 是如何寻址的？分布式寻址都有哪些算法？了解一致性 hash 算法吗？简介

Redis Cluster是一种服务端Sharding技术，3.0版本开始正式提供。Redis Cluster并没有使用一致性hash，而是采用slot(槽)的概念，一共分成16384个槽。将请求发送到任意节点，接收到请求的节点会将查询请求发送到正确的节点上执行。16384个槽数默认值是固定的。

方案说明

1. 通过哈希的方式，将数据分片，每个节点均分存储一定哈希槽(哈希值) 区间的数据，默认分配了16384 个槽位
2. 每份数据分片会存储在多个互为主从的多节点上
3. 数据写入先写主节点，再同步到从节点(支持配置为阻塞同步)
4. 同一分片多个节点间的数据不保持一致性
5. 读取数据时，当客户端操作的key没有分配在该节点上时，redis会返回转向指令，指向正确的节点
6. 扩容时需要把旧节点的数据迁移一部分到新节点

在 redis cluster 架构下，每个 redis 要放开两个端口号，一个用来对外供客户端连接，另一个用来节点间互相通信。

比如一个是 6379，另外一个就是 加1w 的端口号，比如 16379。

16379 端口号是用来进行节点间通信的，也就是 cluster bus 的东西，cluster bus 的通信，用来进行故障检测、配置更新、故障转移授权。cluster bus 用了另外一种二进制的协议，gossip 协议，用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间。

节点间的内部通信机制

基本通信原理

集群元数据的维护有两种方式：集中式、Gossip 协议。redis cluster 节点间采用 gossip 协议进行通信。

Redis主从架构

单机的 redis，能够承载的 QPS 大概就在上万到几万不等。对于缓存来说，一般都是用来支撑读高并发的。因此架构做成主从(master-slave)架构，一主多从，主负责写，并且将数据复制到其它的 slave 节点，从节点负责读。所有的读请求全部走从节点。这样也可以很轻松实现水平扩容

redis 采用异步方式复制数据到 slave 节点，不过 redis2.8 开始，slave node 会周期性地确认自己每次复制的数据量；

一个 master node 是可以配置多个 slave node 的； slave node 也可以连接其他的 slave node；

slave node 做复制的时候，不会（阻碍）block master node 的正常工作；

slave node 在做复制的时候，也不会 block 对自己的查询操作，它会用旧的数据集来提供服务；但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务了；

slave node 主要用来进行横向扩容，做读写分离，扩容的 slave node 可以提高读的吞吐量。

注意：如果采用了主从架构，那么建议必须开启 master node 的持久化，不建议用 slave node 作为 master node 的数据热备，因为那样的话，如果你关掉 master 的持久化，可能在 master 宕机重启的时候数据是空的，然后可能一经过复制， slave node 的数据也丢了。

另外，master 的各种备份方案，也需要做。万一本地的所有文件丢失了，从备份中挑选一份 rdb 去恢复 master，这样才能确保启动的时候，是有数据的，即使采用了后续讲解的高可用机制，slave node 可以自动接管 master node，但也可能 sentinel 还没检测到 master failure，master node 就自动重启了，还是可能导致上面所有的 slave node 数据被清空。

redis 主从复制的核心原理当启动一个 slave node 的时候，它会发送一个 PSYNC 命令给 master node。

如果这是 slave node 初次连接到 master node，那么会触发一次 full resynchronization 全量复制。此时 master 会启动一个后台线程，开始生成一份 RDB 快照文件，同时还会将从客户端 client 新收到的所有写命令缓存在内存中。RDB 文件生成完毕后， master 会将这个 RDB 发送给 slave，slave 会先写入本地磁盘，然后再从本地磁盘加载到内存中，接着 master 会将内存中缓存的写命令发送到 slave，slave 也会同步这些数据。

slave node 如果跟 master node 有网络故障，断开了连接，会自动重连，连接之后 master node 仅会复制给 slave 部分缺少的数据。

1. 当从库和主库建立MS关系后，会向主数据库发送SYNC命令
2. 主库接收到SYNC命令后会开始在后台保存快照(RDB持久化过程)，并将期间接收到的写命令存起来（都是主节点在做）
3. 当快照完成后，主Redis会将快照文件和所有缓存的写命令发送给从Redis
4. 从Redis接收到后，会载入快照文件并且执行收到的缓存的命令
5. 之后，主Redis每当接收到写命令时就会将命令发送从Redis，从而保证数据的一致

缺点

所有的slave节点数据的复制和同步都由master节点来处理，会照成master节点压力太大，使用主从从结构来解决

Redis集群的主从复制模型是怎样的？

为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型，每个节点都会有N-1个复制品生产环境中的 redis 是怎么部署的？

redis cluster，10 台机器，5 台机器部署了 redis 主实例，另外 5 台机器部署了 redis 的从实例，每个主实例挂了一个从实例，5 个节点对外提供读写服务，每个节点的读写高峰qps可能可以达到每秒 5 万，5 台机器最多是 25 万读写请求/s。

机器是什么配置？32G 内存+ 8 核 CPU + 1T 磁盘，但是分配给 redis 进程的是10g内存，一般线上生产环境，redis 的内存尽量不要超过 10g，超过 10g 可能会有问题。

5 台机器对外提供读写，一共有 50g 内存。

因为每个主实例都挂了一个从实例，所以是高可用的，任何一个主实例宕机，都会自动故障迁移，redis 从实例会自动变成主实例继续提供读写服务。

你往内存里写的是什么数据？每条数据的大小是多少？商品数据，每条数据是 10kb。100 条数据是 1mb，10 万条数据是 1g。常驻内存的是 200 万条商品数据，占用内存是 20g，仅仅不到总内存的 50%。目前高峰期每秒就是 3500 左右的请求量。

其实大型的公司，会有基础架构的 team 负责缓存集群的运维。

说说Redis哈希槽的概念？

Redis集群没有使用一致性hash,而是引入了哈希槽的概念，Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。

Redis 的哈希槽（Hash Slot）是 Redis 集群中的一个概念，用于将数据分布到不同的节点上。Redis 集群中使用哈希槽来实现数据的分片和负载均衡，将大量的数据分散到多个节点上，以提高系统的可扩展性和性能。

具体来说，Redis 会将所有的哈希槽均分到不同的节点上，每个节点负责处理一部分哈希槽的数据。

例如：一个 Redis 集群有 3 个节点，每个节点负责处理 16384 个哈希槽，那么每个节点负责处理的哈希槽范围为：
第一个节点：0-5460
第二个节点：5461-10922
第三个节点：10923-16383
当客户端需要访问某个键值对时，Redis 集群会根据键名计算出哈希值，并将该哈希值映射到一个哈希槽上。然后，Redis 集群会根据哈希槽的分布情况，将该键值对传递到对应的节点上进行处理。

在 Redis 集群中，哈希槽的默认数量是固定的，且不可更改。默认情况下，Redis 集群中有 16384 个哈希槽，可以通过 cluster slots 命令来设置哈希槽数量。当某个节点失效或者新增节点时，Redis 集群会重新计算哈希槽的分布情况，将负载均衡到其他节点上。
在 Redis 集群中，哈希槽的分布情况是通过哈希函数计算得出的。Redis 默认使用的哈希函数是 MurmurHash2，该函数可以将任意长度的数据映射成一个 32 位的二进制数，并保证均匀分布。除了 MurmurHash2，Redis 还支持其他的哈希函数，例如 CRC16 和 CRC32 等。
总的来说，Redis 的哈希槽是 Redis 集群中的一个重要概念，用于将数据分布到不同的节点上。Redis 集群通过哈希槽的分配和负载均衡，实现了高可用性、可扩展性和高性能的分布式存储服务。

Redis集群会有写操作丢失吗？为什么？

Redis并不能保证数据的强一致性，这意味这在实际中集群在特定的条件下可能会丢失写操作。

Redis集群之间是如何复制的？

异步复制

Redis集群最大节点个数是多少？

16384个，因为哈希槽最多16384个

Redis集群如何选择数据库？

Redis集群目前无法做数据库选择，默认在0数据库。

Redis是单线程的，如何提高多核CPU的利用率？

可以在同一个服务器部署多个Redis的实例，并把他们当作不同的服务器来使用，在某些时候，无论如何一个服务器是不够的， 所以，如果你想使用多个CPU，你可以考虑一下分片（shard）。

为什么要做Redis分区？

分区可以让Redis管理更大的内存，Redis将可以使用所有机器的内存。如果没有分区，你最多只能使用一台机器的内存。分区使Redis的计算能力通过简单地增加计算机得到成倍提升，Redis的网络带宽也会随着计算机和网卡的增加而成倍增长。

你知道有哪些Redis分区实现方案？

• 客户端分区就是在客户端就已经决定数据会被存储到哪个redis节点或者从哪个 redis节点读取。大多数客户端已经实现了客户端分区。
• 代理分区意味着客户端将请求发送给代理，然后代理决定去哪个节点写数据或者读数据。代理根据分区规则决定请求哪些Redis实例，然后根据Redis的响应结果返回给客户端。redis和memcached的一种代理实现就是Twemproxy
• 查询路由(Query routing) 的意思是客户端随机地请求任意一个redis实例，然后由Redis将请求转发给正确的Redis节点。Redis Cluster（redis集群）实现了一种混合形式的查询路由，但并不是直接将请求从一个redis节点转发到另一个redis节点，而是在客户端的帮助下直接redirected到正确的redis节点。

Redis分区有什么缺点？

• 涉及多个key的操作通常不会被支持。例如你不能对两个集合求交集，因为他们可能被存储到不同的Redis实例（实际上这种情况也有办法，但是不能直接使用交集指令）。
• 同时操作多个key,则不能使用Redis事务。
• 分区使用的粒度是key，不能使用一个非常长的排序key存储一个数据集（The partitioning granularity is the key, so it is not possible to shard a dataset with a single huge key like a very big sorted set）
• 当使用分区的时候，数据处理会非常复杂，例如为了备份你必须从不同的Redis实例和主机同时收集RDB / AOF文件。
• 分区时动态扩容或缩容可能非常复杂。Redis集群在运行时增加或者删除Redis节点，能做到最大程度对用户透明地数据再平衡，但其他一些客户端分区或者代理分区方法则不支持这种特性。然而，有一种预分片的技术也可以较好的解决这个问题。

Redis实现分布式锁

具体实现可参考：基于redis实现分布式锁

Redis为单进程单线程模式，采用队列模式将并发访问变成串行访问，且多客户端对Redis的连接并不存在竞争关系Redis中可以使用SETNX命令实现分布式锁。

当且仅当 key 不存在，将 key 的值设为 value。 若给定的 key 已经存在，则SETNX 不做任何动作

SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写。

返回值：设置成功，返回 1 。设置失败，返回 0 。

使用SETNX完成同步锁的流程及事项如下(img)：使用SETNX命令获取锁，若返回0（key已存在，锁已存在）则获取失败，反之获取成功为了防止获取锁后程序出现异常，导致其他线程/进程调用SETNX命令总是返回0而进入死锁状态，需要为该key设置一个“合理”的过期时间释放锁，使用DEL命令将锁数据删除

分布式Redis是前期做还是后期规模上来了再做好？为什么？

既然Redis是如此的轻量（单实例只使用1M内存），为防止以后的扩容， 好的办法就是一开始就启动较多实例。即便你只有一台服务器，你也可以一开始就让Redis以分布式的方式运行，使用分区，在同一台服务器上启动多个实例。

一开始就多设置几个Redis实例，例如32或者64个实例，对大多数用户来说这操作起来可能比较麻烦，但是从长久来看做这点牺牲是值得的。

这样的话，当你的数据不断增长，需要更多的Redis服务器时，你需要做的就是仅仅将Redis实例从一台服务迁移到另外一台服务器而已（而不用考虑重新分区的问题）。一旦你添加了另一台服务器，你需要将你一半的Redis实例从第一台机器迁移到第二台机器。

缓存雪崩

缓存雪崩是指缓存同一时间大面积的失效，所以，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。

解决方案

1. 缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
2. 一般并发量不是特别多的时候，使用最多的解决方案是加锁排队。
3. 给每一个缓存数据增加相应的缓存标记，记录缓存的是否失效，如果缓存标记失效，则更新数据缓存。

缓存穿透

缓存穿透是指缓存和数据库中都没有的数据，导致所有的请求都落到数据库上，造成数据库短时间内承受大量请求而崩掉。

解决方案

1. 接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；
2. 从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击
3. 采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储系统的查询压力附加

Bitmap： 典型的就是哈希表缺点是，Bitmap对于每个元素只能记录1bit信息，如果还想完成额外的功能，恐怕只能靠牺牲更多的空间、时间来完成了。

布隆过滤器（推荐）

就是引入了k(k>1)k(k>1)个相互独立的哈希函数，保证在给定的空间、误判率下，完成元素判重的过程。

它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。

Bloom-Filter算法的核心思想就是利用多个不同的Hash函数来解决“冲突”。

Hash存在一个冲突（碰撞）的问题，用同一个Hash得到的两个URL的值有可能相同。为了减少冲突，我们可以多引入几个Hash，如果通过其中的一个Hash值我们得出某元素不在集合中，那么该元素肯定不在集合中。只有在所有的Hash函数告诉我们该元素在集合中时，才能确定该元素存在于集合中。这便是Bloom-Filter的基本思想。

Bloom-Filter一般用于在大数据量的集合中判定某元素是否存在。

缓存击穿

缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。

和缓存雪崩不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。

解决方案

1. 设置热点数据永远不过期。
2. 加互斥锁，互斥锁缓存预热

缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！解决方案

1. 直接写个缓存刷新页面，上线时手工操作一下；
2. 数据量不大，可以在项目启动的时候自动进行加载；
3. 定时刷新缓存；

缓存降级

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。

缓存降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。

在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：

1. 一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；
2. 警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；
3. 错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；
4. 严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

服务降级的目的，是为了防止Redis服务故障，导致数据库跟着一起发生雪崩问题。因此，对于不重要的缓存数据，可以采取服务降级策略，例如一个比较常见的做法就是，Redis出现问题，不去数据库查询，而是直接返回默认值给用户。

降级的方案有哪些？（*）

热点数据和冷数据

热点数据，缓存才有价值，对于冷数据而言，大部分数据可能还没有再次访问到就已经被挤出内存，不仅占用内存，而且价值不大。频繁修改的数据，看情况考虑使用缓存对于热点数据，比如我们的某IM产品，生日祝福模块，当天的寿星列表，缓存以后可能读取数十万次。再举个例子，某导航产品，我们将导航信息，缓存以后可能读取数百万次。
数据更新前至少读取两次，缓存才有意义。这个是最基本的策略，如果缓存还没有起作用就失效了，那就没有太大价值了。
那存不存在，修改频率很高，但是又不得不考虑缓存的场景呢？
有！比如，这个读取接口对数据库的压力很大，但是又是热点数据，这个时候就需要考虑通过缓存手段，减少数据库的压力，比如我们的某助手产品的，点赞数，收藏数，分享数等是非常典型的热点数据，但是又不断变化，此时就需要将数据同步保存到Redis缓存，减少数据库压力。

缓存热点key

缓存中的一个Key(比如一个促销商品)，在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

解决方案对缓存查询加锁，如果KEY不存在，就加锁，然后查DB入缓存，然后解锁；其他进程如果发现有锁就等待，然后等解锁后返回数据或者进入DB查询常用工具

Redis支持的Java客户端都有哪些？官方推荐用哪个？

Redisson、Jedis、lettuce等等，官方推荐使用Redisson。

Redis和Redisson有什么关系？

Redisson是一个高级的分布式协调Redis客服端，能帮助用户在分布式环境中轻松实现一些Java的对象 (Bloom filter, BitSet, Set, SetMultimap,ScoredSortedSet, SortedSet, Map, ConcurrentMap, List,ListMultimap,Queue, BlockingQueue, Deque, BlockingDeque, Semaphore, Lock,ReadWriteLock, AtomicLong, CountDownLatch, Publish / Subscribe,HyperLogLog)。

Jedis与Redisson对比有什么优缺点？

Jedis是Redis的Java实现的客户端，其API提供了比较全面的Redis命令的支持；Redisson实现了分布式和可扩展的Java数据结构，和Jedis相比，功能较为简单，不支持字符串操作，不支持排序、事务、管道、分区等Redis特性。

Redisson的宗旨是促进使用者对Redis的关注分离，从而让使用者能够将精力更集中地放在处理业务逻辑上。

Redis与Memcached的区别

两者都是非关系型内存键值数据库，现在公司一般都是用 Redis 来实现缓存，而且 Redis 自身也越来越强大了！Redis 与 Memcached 主要有以下不同：

(1) memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型

(2) redis的速度比memcached快很多

(3) redis可以持久化其数据

如何保证缓存与数据库双写时的数据一致性？
你只要用缓存，就可能会涉及到缓存与数据库双存储双写，你只要是双写，就一定会有数据一致性的问题，那么你如何解决一致性问题？一般来说，就是如果你的系统不是严格要求缓存+数据库必须一致性的话，缓存可以稍微的跟数据库偶尔有不一致的情况，最好不要做这个方案，读请求和写请求串行化，串到一个内存队列里去，这样就可以保证一定不会出现不一致的情况串行化之后，就会导致系统的吞吐量会大幅度的降低，用比正常情况下多几倍的机器去支撑线上的一个请求。

还有一种方式就是可能会暂时产生不一致的情况，但是发生的几率特别小，就是先更新数据库，然后再删除缓存。

Redis常见性能问题和解决方案？

• Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化。
• 如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。
• 为了主从复制的速度和连接的稳定性，Slave和Master 好在同一个局域网内。
• 尽量避免在压力较大的主库上增加从库
• Master调用BGREWRITEAOF重写AOF文件，AOF在重写的时候会占大量的CPU和内存资源，导致服务load过高，出现短暂服务暂停现象。
• 为了Master的稳定性，主从复制不要用图状结构，用单向链表结构更稳定，即主从关系为：Master<–Slave1<–Slave2<–Slave3…，这样的结构也方便解决单点故障问题，实现Slave对Master的替换，也即，如果Master挂了，可以立马启用Slave1做Master，其他不变。

Redis官方为什么不提供Windows版本？

因为目前Linux版本已经相当稳定，而且用户量很大，无需开发windows版本，反而会带来兼容性等问题。

一个字符串类型的值能存储最大容量是多少？

512M

Redis如何做大量数据插入？ Redis2.6开始redis-cli支持一种新的被称之为pipe mode的新模式用于执行大量数据插入工作。

假如Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如果将它们全部找出来？

使用keys指令可以扫出指定模式的key列表。

对方接着追问：如果这个redis正在给线上的业务提供服务，那使用keys指令会有什么问题？这个时候你要回答redis关键的一个特性：redis的单线程的。keys指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。

这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用keys指令长。

Redis如何实现延时队列

使用sortedset，使用时间戳做score, 消息内容作为key,调用zadd来生产消息，消费者使用zrangbyscore获取n秒之前的数据做轮询处理。