Spring核心是IoC和AOP，IoC通过DI由容器实现，容器分BeanFactory（延迟、轻量）和ApplicationContext（完整、预实例化）。Bean是POJO，由容器管理，可用@Component、@Service等注解声明，@Autowired/@Resource实现注入，@Scope定义单例、prototype、request、session等作用域，@PostConstruct/@PreDestroy控制生命周期。循环依赖通过单例的三级缓存（singletonFactories、earlySingletonObjects、singletonObjects）解决。@Autowired按类型注入，@Resource默认按名称注入。
Spring MVC 基于 MVC 模式，将系统划分为 Model（数据）、View（界面）和 Controller（业务逻辑）三层，降低耦合便于维护。DAO 层负责统一的数据访问，可使用 Spring JDBC、Hibernate、MyBatis 等实现。请求经由 DispatcherServlet、HandlerMapping、HandlerAdapter 处理，返回 ModelAndView，由 ViewResolver 解析视图并渲染，支持 HTML、JSON、PDF 等多种媒体。常用注解包括 @RequestMapping、@RequestParam、@RequestBody、@PathVariable 等，用于映射路径、绑定参数和处理请求体。拦截器实现 HandlerInterceptor，提供 preHandle、postHandle、afterCompletion 三阶段，可在 WebMvcConfigurer 中注册；对 Controller 用拦截器，对所有请求用 Filter，针对 Bean 用 Spring AOP 进行拦截。
本文系统阐述了 MyBatis 与 JPA 的核心差异：映射方式、可移植性、日志与 SQL 优化等；说明 MyBatis 支持的参数类型、实现一对多关联的两种 XML 配置（嵌套查询、嵌套结果），并比较 # （预编译防注入）与 $ （直接拼接、用于动态列）用法及适用场景。进一步介绍了 XML 与 Mapper 接口的 namespace 绑定、分页实现方式及其性能、以及一级、二级缓存机制。随后简要对比了 cookie 与 session 的存储位置、容量、安全性和适用场景，解释了 session 工作原理。最后覆盖了 GET/POST 区别、400 错误含义、请求乱码处理、Spring Boot 定时任务实现、日志 AOP 设计以及 Spring Boot JPA 的概念与实现。
Redis是一款基于内存的键值NoSQL，常用于缓存、计数、排行榜、分布式锁和消息队列等。支持字符串、哈希、列表、集合、有序集合等核心数据结构，5.0 新增 Streams。单线程通过 IO 多路复用和内存操作实现高吞吐，持久化提供 RDB、AOF 与混合模式；过期采用惰性+定时扫描，淘汰策略包括 noeviction、volatile‑lru、allkeys‑lfu 等。高可用可通过 Sentinel 实现自动故障转移，或使用 Cluster 进行分片。文中还说明了 setnx/SET NX 实现分布式锁、watch 乐观锁以及主从同步机制。
本文系统阐述了Redis的关键特性与实践。首先介绍Redis Cluster 的优势在于突破单机内存、并发与流量瓶颈，实现负载均衡，但批量操作、事务、多库及多层复制受限。随后解析hash、zset 两大数据结构的底层实现：当键值数量少且长度短时采用压缩列表（ziplist），否则使用哈希表（dict）或跳跃表（skiplist），并说明 dict 的渐进式 rehash 机制。最后给出 Redis 在分布式场景下的典型应用——基于键值存储的 Session 共享以及分布式锁的实现思路，强调利用 setnx+expire 等原子指令保证安全可靠。
消息队列用于解耦、异步、削峰；生产者‑消费者通过共享队列实现，可用wait/notify、Lock或BlockingQueue。顺序消费通过同键落在同一分区或队列保证。防止丢失依赖持久化、ACK/confirm、复制和手动提交offset；防重复通过唯一ID或幂等。失败时采用死信队列重试。推模式适实时广播，拉模式适按需获取。RabbitMQ强调可靠性实时性，Kafka强调高吞吐。
CAP 原则指出分布式系统只能同时满足一致性、可用性、分区容错三者中的两项。高并发指大流量场景，需要在架构、编码、产品层面进行整体设计，目标是实现高性能、高可用和高扩展，并通过响应时间、TP99、可用率（3~4 个 9）和线性扩容等指标衡量。常用的实践包括纵向/横向扩展、分层架构、缓存、限流、异步化、容错切换、降级、监控等。分布式存储可采用中心化（HDFS）或无中心（Ceph、Swift）架构，实现数据分片与一致性哈希。分布式事务常用 2PC 与 TCC 两阶段方案，分别在一致性、单点故障和并发性能上各有优劣。
本文围绕分布式系统的最终一致性展开，首先介绍了Open Group 的 DTS 模型及 JEE 中的 TX、XA 协议，并详细说明了两阶段提交、三阶段提交以及阿里提出的 TCC 方案的流程、优缺点。随后提出在高并发场景下实现最终一致性的实用模式：查询、补偿、异步确保、定期校对、可靠消息以及缓存一致性，并给出相应的实现要点。接着讨论了分布式单点故障，分别阐述了无状态服务的冗余方案和有状态服务的主备、选举（ZooKeeper、Paxos、Raft）机制。最后简要对比了 HTTP 与 RPC 在协议、性能、负载均衡和服务治理等方面的区别，指出 RPC 更适合内部高效调用。
本文系统介绍了网络分层模型与关键协议。先阐述OSI七层及其功能，再对比简化的五层TCP/IP模型。说明客户端通过URL确定协议，指出TCP属传输层、HTTP/FTP属应用层。详细解析TCP报文结构、流量与拥塞控制，概述HTTP特性与常用方法、FTP工作方式及状态管理。介绍传输层的复用/分用、端口及流量、拥塞控制，列举常见应用层协议。最后说明TCP/IP四层结构的开放、硬件无关优势，并解释ARP的工作原理和缓存机制。
TCP四次挥手过程及原因：客户端FIN→服务器ACK→服务器FIN→客户端ACK，分别关闭双向数据通道，最后ACK确保对方已收到。TCP粘包/拆包源于流式无边界传输，可通过包头+长度或分隔符在应用层解决；Nagle算法可导致粘包，关闭TCP_NODELAY可缓解。TCP与UDP对比：TCP面向连接、可靠、具拥塞控制，适用于对可靠性要求高的场景；UDP无连接、快速、无保证，适合实时传输。UDP实现可靠性需在应用层加入超时重传和序号确认。TCP报文序号字段占4字节，缓冲区用于存储待发送和接收的数据，实现流控和重传。
