本文详细介绍了Spring框架的核心机制。其核心是IoC（控制反转）和AOP（面向切面编程），其中IoC通过DI（依赖注入）实现，旨在降低对象间的耦合度。Spring提供了BeanFactory和ApplicationContext两种容器来管理Bean，通过注解或XML配置实现Bean的创建、作用域管理及生命周期控制。此外，文章深入探讨了Spring利用“三级缓存”机制解决单例模式下setter循环依赖的问题，并对比了@Autowired与@Resource等常用注解的区别。

Spring MVC 是一种常用的软件设计模式，将应用分为模型（Model）、视图（View）和控制器（Controller）三层，降低耦合度，方便维护。在 Spring 框架中，数据访问通常通过 DAO 层实现，可以使用 Spring JDBC、Hibernate 等技术，并提供统一的编程模式。 Spring MVC 的执行流程始于客户端 HTTP 请求，DispatcherServlet 接收请求并根据 HandlerMapping 找到合适的处理器（Handler），通过 HandlerAdapter 适配并调用 Handler。Handler 返回 ModelAndView，DispatcherServlet 通过 ViewResolver 解析视图，最终渲染并返回响应。 Spring MVC 提供了多种注解，如 `@RequestMapping` 用于请求映射，`@RequestParam` 用于接收参数，`@RequestBody` 用于处理请求体，`@PathVariable` 用于绑定 URL 占位符。 拦截器通过实现 HandlerInterceptor 接口，在处理器执行前后增强功能，包括 preHandle、postHandle 和 afterCompletion 方法。请求拦截可以通过 Spring MVC 拦截器（针对 Controller）、Filter（针对所有请求）或 Spring AOP（针对其他 Bean）实现。

MyBatis与JPA在ORM映射、可移植性、日志系统及SQL优化方面存在显著差异：MyBatis为半自动ORM，需手写SQL，耦合性较高但优化灵活，日志功能较弱；JPA为全自动ORM，支持HQL，对象与数据库解耦好，日志系统健全但复杂SQL处理能力有限。MyBatis支持简单类型、集合及JavaBean作为输入输出参数，通过属性名映射。实现一对多关联查询可使用嵌套查询（通过collection标签调用子查询）或嵌套结果（联表查询后映射子集合）。$与#的区别在于#使用预编译防注入且高效，$直接拼接参数用于动态列名等特殊场景，虽不安全但必要。MyBatis XML与Mapper接口通过namespace属性绑定。自定义分页效率高于插件分页，因可针对大数据偏移优化。MyBatis缓存分两级：一级为SqlSession级默认启用，二级为SqlSessionFactory级需手动开启，基于LRU策略，缓存SELECT结果并在增删改时刷新。cookie与session在存储位置、容量、安全性、生命周期等方面不同，session依赖cookie传递SESSIONID实现状态跟踪。GET请求幂等、参数暴露于URL且长度受限，适用于非敏感数据获取；POST非幂等、参数在请求体无长度限制，适合创建资源或传输敏感数据。400错误表示请求参数语义错误。乱码问题可通过统一客户端与服务端编码解决，GET需配置

Redis Cluster在3.0提供分布式能力，能突破单机内存、并发与流量瓶颈，实现负载均衡，但限制批量/事务操作只能在同slot键上，单库、单层复制等也受限。Hash在键值对≤512且长度<64 B时采用压缩列表（ziplist），否则使用字典（hashtable），并通过渐进式 REHASH 动态扩容/收缩。Zset 同样在元素≤128且长度<64 B时使用 ziplist，否则采用由字典和跳跃表（skiplist）组合的 zset 结构，兼顾按成员和按分值的高效访问。利用 Redis 的高性能键值存储，可实现跨节点的分布式 Session（将 SessionID 存于 Redis）以及分布式锁（基于 SETNX/SET‑EX 并配合超时、唯一标识和 Lua 脚本保证原子性），解决多服务器环境下的状态共享和并发竞争问题。

消息队列（MQ）在软件解耦、异步处理和削峰填谷方面发挥着重要作用。通过MQ，系统模块不再直接依赖彼此，提高可扩展性；异步机制允许应用非立即处理消息，提升响应速度；削峰能力则能应对突发流量，保证系统稳定性，尤其适用于电商秒杀等场景。 常见的MQ模式包括生产者-消费者模式，生产者将数据放入共享数据区，消费者从中获取，实现解耦。为保证消息顺序消费，不同MQ产品有不同方案，如RabbitMQ通过多队列，Kafka通过partition和key，RocketMQ通过指定MessageQueue。 可靠性方面，MQ通过持久化、确认机制（如RabbitMQ的confirm和Kafka的acks）来避免消息丢失。为防止重复消费，通常结合幂等性设计，确保多次处理结果一致。当消息处理失败时，可利用死信队列进行重试或告警。 RabbitMQ和Kafka的区别在于应用场景和架构：RabbitMQ更适用于对可靠性要求高的实时消息传递，而Kafka则擅长处理大数据量、高吞吐量的流式数据。选择哪种MQ取决于具体业务需求。