学习学习学习

微服务相关1. 什么是微服务它的核心思想是什么微服务一种架构风格将一个庞大的单体应用拆分成多个小型、独立、可部署的服务每个服务聚焦一个具体的业务模块服务之间通过轻量级通信协议如 HTTP、RPC交互独立开发、独立部署、独立维护。核心思想拆分巨石应用实现高内聚、低耦合 —— 每个服务只负责自己的业务不依赖其他服务的内部实现降低开发、测试、部署的复杂度提升系统的可扩展性和容错性2. 微服务和单体架构的区别是什么单体架构所有业务模块如用户、订单、商品都打包在一个应用中部署在一个服务器上开发简单、部署方便但耦合度高、扩展性差一个模块故障可能导致整个应用崩溃。微服务架构拆分多个独立服务每个服务对应一个业务模块单独部署、单独扩容耦合度低、扩展性强一个服务故障不影响其他服务但开发、部署、运维复杂度提升。核心区别是否拆分服务、耦合度高低、扩展性强弱、运维复杂度。对比维度单体架构微服务架构架构特点所有模块集中在一个应用内按业务拆分为多个独立服务耦合度高耦合模块间依赖强低耦合服务间通过轻量协议通信扩展性整体扩容难以针对模块单独扩展可针对单个服务独立扩容部署方式单次部署整个应用各服务可独立部署、上线故障影响一个模块故障可能导致整体宕机单个服务故障不影响其他服务开发运维开发简单运维成本低开发、部署、运维复杂度高需配套工具微服务更适合业务快速迭代、高并发的场景单体更适合业务简单、快速上线的小型项目3.微服务的优势和缺点是什么优势低耦合服务独立互不依赖内部实现修改一个服务不影响其他服务。高扩展性单个服务可根据业务需求独立扩容如订单服务高峰期单独加机器。容错性强一个服务故障不会导致整个系统崩溃可通过降级、熔断避免连锁反应。开发高效多团队并行开发每个团队负责一个服务提升开发效率。缺点运维复杂多个服务独立部署、监控、维护需要额外的运维工具和成本。分布式问题服务之间通信存在网络延迟、超时、分布式事务等问题。调试困难跨服务问题排查复杂需要追踪整个调用链路。4.微服务核心组件微服务架构中常用的核心组件有哪些各自作用是什么服务注册与发现核心组件Eureka、Consul、Nacos常用 Nacos易部署、功能全。作用服务启动时自动注册到注册中心其他服务通过注册中心获取服务地址无需手动配置服务地址解决 “服务地址动态变化” 问题。组件类别常用组件核心作用服务注册与发现Eureka、Consul、ZooKeeper、Nacos管理所有服务的实例地址实现服务自动注册、健康检查和动态发现解决服务地址变化问题配置中心Spring Cloud Config、Nacos集中管理所有服务的配置支持配置动态刷新避免配置文件分散和修改重启服务的问题服务网关Zuul、Spring Cloud Gateway作为系统统一入口实现路由转发、权限校验、限流、日志统计隔离内外网简化客户端调用服务调用 / 通信RestTemplate、OpenFeign、Dubbo、实现服务之间的远程调用支持负载均衡简化跨服务接口调用代码编写熔断与限流Hystrix、Sentinel防止服务雪崩当某个服务故障时快速熔断降级保护上游服务提升系统容错能力链路追踪Zipkin、pinpoint追踪跨服务调用的完整链路记录请求耗时、调用关系快速定位分布式系统中的性能瓶颈和故障API 网关核心组件Gateway、Zuul常用 Gateway基于 Spring Boot性能好。作用统一入口所有客户端请求都经过网关实现路由转发、权限校验、限流、熔断、日志监控等功能简化客户端调用。服务通信核心方式HTTP 协议RESTful API简单易懂跨语言、RPC 协议Dubbo、FeignSpring Cloud LoadBalancerFeign 基于 HTTPDubbo 基于 RPC性能高适合 Java 内部服务通信。作用实现不同微服务之间的数据交互和调用。配置中心Nacos、Nacos兼顾注册中心和配置中心。作用集中管理所有微服务的配置如数据库地址、端口、参数支持配置动态刷新无需重启服务即可更新配置。什么是服务注册与发现Nacos 的核心作用是什么服务注册微服务启动时将自己的服务名称、IP 地址、端口等信息注册到注册中心如 Nacos注册中心维护一个服务列表。服务发现当服务 A 需要调用服务 B 时先从注册中心查询服务 B 的地址再通过该地址调用服务 B无需手动配置服务 B 的地址。Nacos 核心作用① 服务注册与发现核心② 配置中心集中管理配置动态刷新③ 服务健康监测检测服务是否可用剔除故障服务。API 网关的核心功能有哪些路由转发将客户端请求根据请求路径转发到对应的微服务如/api/user转发到用户服务/api/order转发到订单服务。权限校验统一拦截所有请求校验用户 Token、权限拒绝非法请求无需每个服务单独实现权限校验。限流熔断限制客户端请求频率避免服务被高并发压垮当目标服务故障时熔断调用返回默认数据避免连锁故障。日志监控记录所有请求的详细信息请求路径、响应时间、状态码便于问题排查和性能分析微服务服务治理什么是服务熔断、服务降级两者的区别是什么服务熔断当一个服务出现频繁故障、超时为了避免影响其他服务暂时 “断开” 对该服务的调用返回默认数据或提示等待服务恢复后再重新调用类似电路熔断防止故障扩散。核心目的防止故障连锁反应保护整个微服务系统。服务降级当系统处于高并发、资源紧张时暂时关闭一些非核心服务的功能如积分兑换、历史订单查询优先保证核心服务如支付、下单正常运行降低系统负载。核心目的保证核心服务可用牺牲非核心功能。区别熔断是 “被动触发”服务故障导致降级是 “主动触发”高并发、资源紧张导致。什么是负载均衡微服务中如何实现负载均衡负载均衡当一个服务部署多个实例如订单服务部署 3 台机器客户端请求会均匀分配到各个实例避免单个实例压力过大提升服务的可用性和并发能力。微服务中实现方式常用 2 种客户端负载均衡FeignSpring Cloud LoadBalancerSpring Cloud 官方推荐替代 Ribbon客户端调用服务时从注册中心获取服务实例列表自己决定调用哪个实例如轮询、随机。服务端负载均衡API 网关如 Spring Cloud Gateway所有请求经过网关由网关将请求分配到不同的服务实例。微服务中的分布式事务问题是什么如何解决分布式事务问题多个微服务之间的事务操作无法保证原子性如用户下单订单服务创建订单库存服务扣减库存支付服务扣减余额若其中一个服务失败其他服务已执行的操作无法回滚导致数据不一致。解决方法最终一致性方案主流基于消息队列如 RabbitMQ、RocketMQ实现采用 “本地事务 消息通知” 的方式确保所有服务最终执行成功如订单创建成功后发送消息通知库存和支付服务失败则重试。简化方案使用 Seata 框架阿里开源封装了分布式事务的实现只需简单配置即可实现分布式事务的原子性什么是服务链路追踪常用组件是什么服务链路追踪当一个客户端请求经过多个微服务如请求下单→订单服务→库存服务→支付服务追踪整个请求的调用链路记录每个服务的调用时间、状态便于排查跨服务的问题如请求超时定位是哪个服务耗时过长。常用组件SleuthZipkinSpring Cloud 常用Sleuth 负责生成追踪 ID标记调用链路Zipkin 负责收集追踪数据可视化展示调用链路。5.微服务高频框架Spring Cloud/Spring BootSpring Boot 和 Spring Cloud 的关系是什么Spring Boot一款快速开发框架简化 Spring 应用的配置和部署可快速创建独立的 Spring 应用是微服务开发的基础每个微服务都是一个 Spring Boot 应用。Spring Cloud基于 Spring Boot提供了微服务架构所需的核心组件服务注册发现、网关、Spring Cloud LoadBalancer 负载均衡等是一套微服务解决方案用于整合多个 Spring Boot 应用构建完整的微服务系统。关系Spring Boot 是基础Spring Cloud 是在 Spring Boot 之上的微服务整合框架没有 Spring Boot 就没有 Spring CloudSpring Cloud 依赖 Spring Boot 实现微服务的开发和部署Spring Boot是一个快速开发单体应用的脚手架通过自动配置简化了 Spring 应用的搭建和开发让你可以快速创建独立运行的 Java 应用。Spring Cloud是一套基于 Spring Boot 实现的微服务治理框架提供了服务注册与发现、配置中心、网关、负载均衡、熔断限流等微服务所需的组件和解决方案。两者关系Spring Cloud 依赖 Spring Boot它的所有组件都是基于 Spring Boot 开发的Spring Boot 是 Spring Cloud 的基础Spring Cloud 是 Spring Boot 在微服务场景下的扩展。简单来说Spring Boot 用于开发单个微服务Spring Cloud 用于管理多个微服务。Spring Cloud 常用组件有哪些服务注册与发现Nacos/EurekaNacos 更常用兼容 Eureka支持配置中心。API 网关Spring Cloud Gateway替代 Zuul性能更好基于 Netty。服务通信Feign基于 HTTP声明式调用简化服务调用、Dubbo基于 RPC性能高。负载均衡Spring Cloud LoadBalancerSpring Cloud 官方推荐替代 Ribbon配合 Feign 使用实现客户端负载均衡。熔断降级Sentinel阿里开源替代 Hystrix实现熔断、降级、限流。配置中心NacosNacos 兼顾注册中心部署简单。Feign 和 Dubbo 的区别是什么通信协议Feign 基于 HTTP 协议RESTful API跨语言、简单易懂Dubbo 基于 RPC 协议性能更高仅适用于 Java 语言。开发复杂度Feign 是声明式调用只需编写接口和注解开发简单Dubbo 需要配置服务接口、注册中心开发略复杂。适用场景Feign 适合跨语言、服务之间通信频率不高的场景Dubbo 适合 Java 内部服务、高并发、高性能要求的场景。对比维度FeignDubbo通信协议HTTPRESTfulRPC跨语言支持支持仅 Java性能一般高开发方式声明式接口 注解简单需配置服务接口、注册中心略复杂适用场景跨语言调用、通信频率不高Java 内部服务、高并发高性能场景微服务拆分的原则是什么单一职责原则每个服务只负责一个核心业务模块如用户服务只处理用户相关操作订单服务只处理订单相关操作。高内聚、低耦合服务内部功能紧密相关服务之间尽量减少依赖仅通过接口交互。避免过度拆分拆分过细会导致服务数量过多运维、通信成本增加如不要把 “用户查询” 和 “用户修改” 拆分成两个服务。按业务域拆分以业务领域为边界DDD 领域驱动设计思想比如电商系统可拆分为用户域、订单域、支付域、商品域等每个服务对应一个独立的业务域。避免过度拆分拆分粒度要适中过细的拆分会导致服务间调用链路过长、运维复杂度陡增反而得不偿失。数据独立自治每个微服务应拥有自己独立的数据库避免跨服务直接访问数据库保证数据的内聚性和一致性。面向接口而非实现服务间仅通过公开接口交互隐藏内部实现细节避免服务间的强依赖。微服务中服务之间为什么不能直接调用要通过 API 网关统一入口客户端无需记住多个服务的地址只需调用网关地址由网关转发简化调用。统一管控所有请求都经过网关可统一实现权限校验、限流、熔断、日志监控无需每个服务单独实现降低开发成本。隐藏服务细节客户端无需知道服务的部署地址、实例数量服务升级、扩容时客户端无需修改任何配置。Nacos 和 Eureka 的区别是什么功能Nacos 支持服务注册发现、配置中心、服务健康监测功能更全面Eureka 仅支持服务注册发现。可用性Nacos 支持 AP/CP 模式切换默认 AP保证可用性Eureka 仅支持 AP 模式注重可用性。部署Nacos 部署简单支持单机、集群模式Eureka 需要单独部署集群配置较复杂。现状Eureka 已停止更新Nacos 是 Spring Cloud Alibaba 推荐组件目前更常用。对比维度NacosEureka核心功能服务注册发现 配置中心 健康监测仅服务注册发现一致性模式支持 AP/CP 切换仅支持 AP部署复杂度简单支持一键启动较复杂需手动配置集群社区活跃度活跃持续更新维护已停止更新Spring Cloud 支持Spring Cloud Alibaba 推荐组件Spring Cloud 早期默认组件微服务中的 “雪崩效应” 是什么如何避免雪崩效应一个核心服务故障导致依赖该服务的其他服务也相继故障最终导致整个微服务系统崩溃如支付服务故障导致订单、库存、用户服务都无法正常运行。避免方法熔断给服务添加熔断机制如 Sentinel故障时断开调用避免故障扩散。降级高并发时降级非核心服务保证核心服务可用。限流通过 API 网关或 Sentinel 限制客户端请求频率避免服务被高并发压垮。服务集群核心服务部署多个实例配合 Spring Cloud LoadBalancer 实现负载均衡避免单点故障。服务熔断当依赖的服务故障率达到阈值时快速熔断直接返回降级结果避免持续等待造成线程资源耗尽。服务降级高并发或故障时暂时关闭非核心功能优先保证核心服务可用。限流控制限制请求频率防止超出系统承载能力避免服务被压垮。超时与重试机制设置合理的调用超时时间避免线程被长时间占用同时限制重试次数防止请求风暴。异步调用使用消息队列进行解耦避免同步调用链路过长导致的级联故障。资源隔离不同服务的调用使用独立的线程池避免单个服务故障拖垮整个应用。Java 锁解决多线程并发安全问题的核心机制用来控制多个线程同时访问共享资源时的冲突避免数据错乱、线程安全问题。作用修饰方法、代码块保证同一时间只有一个线程执行。Java 分布式锁作用修饰方法、代码块保证同一时间只有一个线程执行。分布式锁是解决分布式系统中多服务 / 多进程并发安全的核心方案解决同一个服务部署在多台机器上同时操作共享资源如扣库存、生成订单导致的数据错乱问题。和本地锁synchronized/Lock最大区别本地锁只锁当前 JVM 进程分布式环境无效分布式锁锁整个集群 / 全局跨机器、跨服务生效1. 为什么本地锁synchronized/ReentrantLock不能用于分布式场景答案本地锁作用域仅限单个 JVM 进程分布式系统中服务部署在多台机器 / 多个进程不同进程的锁相互隔离无法实现全局互斥因此失效。2. 分布式锁需要满足哪些核心特性互斥性同一时刻仅一个客户端持有锁防死锁锁必须设置过期时间客户端宕机也能自动释放安全性只能释放自己持有的锁防止误删高可用加锁、解锁操作不能因中间件故障大面积失效高性能加解锁开销小支撑高并发可选支持可重入、阻塞等待、锁续期。3. 主流分布式锁实现方案有哪些各自优缺点答案Redis 分布式锁优点性能高、实现简单、社区成熟适配绝大多数业务缺点主从异步复制可能短暂丢锁强一致性弱于 Zookeeper。Zookeeper 分布式锁优点基于临时节点 监听机制强一致性、天然防死锁、无需手动续期缺点性能偏低集群部署重高并发场景不占优。MySQL 分布式锁优点零额外组件实现最简单缺点性能差、数据库压力大、容易出现死锁仅适用于低并发简单场景。4.手写 Redis 分布式锁为什么要用SET key value NX PX一条命令分开写行不行答案 不行。setexpire是两条命令不具备原子性。 如果执行完set后服务宕机锁永远无法过期引发死锁。SET NX PX是 Redis 原子命令加锁 设置过期一步完成彻底规避该问题。NXkey 不存在才设置保证互斥PX毫秒级过期防死锁。性能指标一、系统性能核心指标1. QPSQueries Per Second每秒查询率定义每秒服务器可响应的查询请求数偏向读请求。适用列表查询、页面访问、纯查询接口。特点单次逻辑简单、耗时短。2. TPSTransactions Per Second每秒事务数定义每秒完成的完整业务事务数偏向写请求。事务一次完整业务流程包含多次读写、接口调用、数据变更。适用下单、支付、数据提交、增删改业务。特点链路长、资源消耗大同场景下 TPS 通常低于 QPS。3. 吞吐量广义概念分两类请求吞吐量统计每秒总请求数和 QPS 口径接近数据吞吐量单位时间传输数据大小 (KB/s、MB/s)多用于文件、流媒体。配套监控指标响应时间 RT、并发数、错误率、CPU / 内存 / 磁盘 IO / 网络 IO、数据库连接数。吞吐量 单位时间里系统成功处理 / 通过的数据、任务、产品总量简单一句话单位时间能干完多少活。1. 网络 / 通信最常用指每秒成功传输的数据量单位bps、MB/s、Gbps例宽带吞吐量 100MB/s 每秒实际传 100 兆数据≠带宽标称受损耗影响2. 计算机 / 服务器 / 接口单位时间处理请求数常用TPS每秒事务数、QPS每秒查询数例接口吞吐量 5000QPS 接口一秒能正常扛 5000 次访问3. 生产 / 物流 / 工厂单位时间产出成品 / 转运货物数量例流水线日吞吐量 5000 件 一天生产 5000 个产品4. 硬盘 / 存储每秒读写数据大小MB/s固态硬盘吞吐量 5000MB/s一秒读写 5000 兆数据缓存三大问题缓存穿透、缓存击穿、缓存雪崩整体场景请求优先查询缓存缓存无数据再查询数据库。一缓存穿透定义查询缓存、数据库都不存在的数据无效请求全部直达数据库。成因恶意请求非法参数、业务查询无结果数据。解决方案空值缓存查询为空时缓存空数据设置较短过期时间参数校验网关 / 接口拦截非法 ID、格式异常请求布隆过滤器前置过滤非法 Key海量数据场景优选限流对异常 IP、高频无效请求做流量限制。二缓存击穿定义单个热点 Key过期瞬时大量并发请求直接打到数据库。成因秒杀、爆款、首页等高访问热点数据统一过期。解决方案分布式互斥锁仅一个请求查询数据库并更新缓存其余请求等待热点 Key 永不过期代码异步定时刷新数据规避过期问题逻辑过期存储逻辑过期时间过期后异步更新缓存旧数据正常返回。三缓存雪崩定义大批量缓存 Key 同时失效 或 Redis 整体宕机海量请求压垮数据库。成因Key 过期时间集中、Redis 集群故障、服务资源耗尽。解决方案过期时间加随机值打散批量失效Redis 做集群 哨兵实现高可用避免单点故障多级缓存本地缓存 分布式缓存层层兜底限流、熔断、降级缓存异常时拒绝流量返回兜底数据线程池隔离隔离缓存、数据库请求防止故障扩散。快速区分口诀穿透查不存在的数据 → 无效请求打 DB击穿单个热点 Key 失效 → 高并发单点打 DB雪崩批量 Key 失效 / 缓存宕机 → 全量流量打 DB谈谈你对线程的理解线程是 CPU 调度和执行的最小单位一个进程里可以有多个线程它们共享进程内存同时执行不同任务从而提高程序效率和响应速度。进程一个正在运行的程序比如一个 Java 应用线程程序里真正干活的 “执行小路”进程 vs 线程进程有独立内存空间相互隔离线程共享进程内存堆、方法区只私有栈、程序计数器进程切换开销大线程切换开销小多进程是 “多个程序同时跑”多线程是 “一个程序里多段代码同时跑”。线程的生命周期新建Newnew Thread ()还没 start就绪Runnable调用 start ()等待 CPU 时间片运行Running获得 CPU执行 run ()阻塞Blocked等待锁、IO、sleep 等等待Waitingwait()、join()、LockSupport.park()终止Terminatedrun 执行完毕或异常退出线程从新建start()后进入就绪抢到 CPU 时间片进入运行遇到同步锁、sleep/wait/park等操作进入阻塞 / 等待任务执行完毕或异常退出后线程终止。Java 创建线程的 4 种方式详解继承Thread类实现Runnable接口无返回值实现Callable接口有返回值、可抛出受检异常使用线程池ThreadPoolExecutor/Executors✅企业主流start()和run()区别start()真正创建操作系统线程、进入就绪直接调用run()只是普通方法调用不会新开线程。线程池是项目开发首选前三种多用于临时简单测试场景。线程常用方法start()启动线程进入就绪态run()承载业务逻辑sleep(long)线程休眠不释放锁wait()进入等待释放锁依靠notify/notifyAll唤醒notify()/notifyAll()唤醒处于等待的线程join()线程插队执行等待目标线程执行完毕后当前线程再继续yield()让出 CPU 使用权线程退回就绪态多线程带来的问题与解决多线程核心问题原子性、可见性、有序性缺失 → 引发线程不安全、数据错乱解决方案synchronized内置同步锁可保证原子性、可见性、有序性Lock以ReentrantLock为代表锁操作更灵活volatile保证可见性、禁止指令重排无法保证原子性ThreadLocal变量线程私有化规避多线程共享竞争线程安全集合ConcurrentHashMap、CopyOnWriteArrayList等一、手动创建线程弊端频繁创建销毁开销大线程不可控容易 OOM二、线程池优势复用线程控制并发数量统一管理、配置拒绝策略三、线程池核心参数核心线程数、最大线程数、阻塞队列、空闲存活时间、线程工厂、拒绝策略总结线程是 CPU 调度最小单位共享进程内存提升并发效率。线程生命周期新建→就绪→运行→阻塞 / 等待→终止。创建线程 4 种方式继承 Thread、实现 Runnable、实现 Callable、使用线程池。开启线程必须调用start()直接调用run()只是普通方法执行。多线程安全根源原子性、可见性、有序性问题。解决方案synchronized、Lock、volatile、ThreadLocal、线程安全集合。项目开发优先使用线程池规避频繁创建线程带来的性能隐患。SpringSpring 是轻量级 Java 开源分层框架核心目标解耦、简化开发。两大核心IOC控制反转、AOP面向切面编程。解耦IOC 容器管理对象不用手动 new 对象AOP统一处理日志、事务、权限等通用功能事务管理声明式事务简化事务开发1. 什么是 IOC控制反转把对象的创建、依赖管理交给 Spring 容器不再由开发者手动控制。传统开发程序员new对象 → 程序员控制IOCSpring 容器创建、管理对象 → 控制权反转给容器2. 什么是 DI依赖注入IOC 的实现方式容器自动为 Bean 注入依赖对象不用手动赋值。简单说容器帮你把需要的对象 “送” 进来3. IOC 和 DI 关系IOC 是思想 / 设计模式DI 是实现 IOC 的具体手段。4. Bean 的三种注入方式构造器注入推荐Spring 官方推荐setter 方法注入最常用字段 / 注解注入Autowired开发最常用5. BeanFactory 和 ApplicationContext 区别BeanFactorySpring 底层 IOC 容器延迟加载使用时才创建 Bean功能少。ApplicationContextBeanFactory 子类立即加载容器启动就创建单例 Bean多了国际化、事件发布、资源加载等企业级功能。 日常开发几乎都用 ApplicationContext。6. Bean 的作用域5 种必背singleton默认单例整个容器仅一个 Beanprototype多例每次获取都新建对象request一次请求一个 Beansession一次会话一个 Beanapplication整个 Web 应用一个 Bean7. Bean 生命周期实例化 → 属性填充 → 初始化 → 销毁完整步骤容器启动实例化 Bean构造方法依赖注入setter / 注解赋值执行BeanPostProcessor前置处理执行PostConstruct/init-method初始化方法执行BeanPostProcessor后置处理Bean 就绪正常使用容器关闭执行PreDestroy/destroy-method销毁方法Bean 生命周期 实例化→填充属性→初始化afterPropertiesSet、init-method→使用→销毁 (destroy)IOC概念对象创建、依赖交给 Spring 容器管理不再 new反转控制权。AOP概念横向抽取公共代码日志、事务、权限不改动原业务代码增强功能。1. 什么是 AOP面向切面编程在不修改原有业务代码的前提下对方法进行增强。 作用统一抽离通用逻辑日志、事务、权限、监控、限流解耦业务与通用功能。2. AOP 核心术语切面 Aspect通用功能类日志类、事务类连接点 JoinPoint可以被增强的所有方法切入点 Pointcut真正要被增强的方法过滤后的连接点通知 Advice切面里的具体增强逻辑目标对象 Target被增强的原始对象代理对象 ProxyAOP 生成的代理对象对外提供访问3. 五种通知类型前置通知 Before方法执行前后置通知 AfterReturning方法正常执行后异常不执行异常通知 AfterThrowing方法抛出异常时最终通知 After无论正常 / 异常最后一定执行环绕通知 Around包裹目标方法可控制方法执行最强Spring AOP 两种动态代理JDK 动态代理要求目标类必须实现接口基于接口代理CGLIB 代理目标类无需接口通过继承子类实现代理Spring 默认规则有接口用 JDK无接口用 CGLIBSpringBoot 2.x 默认强制使用 CGLIB。五大通知前置、后置、异常、最终、环绕通知。动态代理目标类实现接口JDK 动态代理没实现接口CGLIB 字节码代理Autowired 和 Resource 区别AutowiredSpring 注解默认按类型注入配合 Qualifier 按名称ResourceJSR 规范默认先按名称、再按类型事务Spring 声明式事务1. Spring 事务分类编程式事务硬编码写事务逻辑繁琐少用声明式事务基于 AOP注解Transactional开发主流2. 事务四大特性 ACID原子性、一致性、隔离性、持久性基础数据库知识3. 事务隔离级别5 种对应数据库隔离级别解决脏读、不可重复读、幻读DEFAULT使用数据库默认隔离级别常用READ_UNCOMMITTED读未提交最低READ_COMMITTED读已提交MySQL 默认REPEATABLE_READ可重复读SERIALIZABLE串行化最高性能最差)4. 事务传播行为7 种重点记常用控制多方法调用时事务如何传递REQUIRED默认有事务就加入没就新建最常用REQUIRES_NEW新建独立事务不受外层事务影响SUPPORTS有事务就用没有就非事务运行NOT_SUPPORTED始终以非事务运行MANDATORY必须在事务内运行否则报错NEVER禁止在事务内运行NESTED嵌套事务有独立保存点事务失效场景方法非 publicTransactional失效内部调用同类方法 this.xxx ()不走 AOP 代理数据库引擎不支持事务如 MyISAM异常类型不对默认只回滚 RuntimeException / Error普通 Checked 异常不回滚手动捕获异常且不抛出事务无法感知异常常用注解Component / Controller / Service / RepositoryBean 注册Autowired自动注入按类型Qualifier配合 Autowired按名称注入ResourceJSR 注解默认按名称Value读取配置文件Configuration / Bean注解配置类、注册 BeanSpring 单例 Bean 线程安全问题Spring Bean 默认单例本身不是线程安全。原因多个线程共享同一个对象实例。解决尽量不要在 Bean 中定义成员变量必要时使用 ThreadLocal。介绍 SpringSpring 是轻量级 Java 开发框架核心是 IOC 和 AOP。IOC 容器负责对象创建与依赖注入AOP 实现切面增强统一处理日志、事务等通用逻辑。同时提供强大的声明式事务、框架整合能力大幅简化 Java 开发。IOC 一句话控制反转就是将对象的创建和依赖管理交给 Spring 容器依赖注入是容器自动为 Bean 装配依赖彻底解耦。AOP 一句话AOP 基于动态代理在不修改原代码的前提下对方法增强常用于事务、日志、权限统一处理。Transactional 失效场景1. 方法不是 publicTransactional基于 AOP 代理非 public (private/protected) 不会生成代理事务失效。2.同类中内部调用原因this调用不走代理对象不会切入事务。 解决从容器拿本类代理对象再调用。3. 异常被 try-catch 吃掉没有抛出异常4. 指定了异常抛出类型不匹配5.数据库引擎不支持事务【表引擎是MyISAM不支持事务换成 InnoDB。】6.传播行为导致不开启事务例如Transactional(propagation Propagation.SUPPORTS)外层无事务当前方法以非事务运行出错不回滚。Transactional 失效口诀私类自捕引擎错传播配置不生效逐句释义私方法非 public无法 AOP 代理类同类 this 内部调用没走代理自捕异常 try-catch 捕获未向外抛出引擎数据表 MyISAM 引擎不支持事务错rollbackFor 指定异常和抛出异常不一致传播传播属性配置不当SUPPORTS 等无事务运行开发规范一句话统一注解Transactional(rollbackFor Exception.class)SpringMVC 执行流程口诀请映适控视:请求→映射→适配→控制器→视图解析完整 5 步流程DispatcherServlet 接收请求前端控制器入口处理器映射器 HandlerMapping根据 URL 找到对应 Controller处理器适配器 HandlerAdapter执行 Controller 方法Controller执行业务返回 ModelAndView视图解析器 ViewResolver解析视图地址渲染页面返回浏览器总结:请求经过 DispatcherServlet由映射找控制器、适配器执行控制器返回数据视图视图解析后响应页面。整体流程6 步标准流程请求到达客户端发起请求请求先被DispatcherServlet中央调度器 / 前端控制器拦截它是整个流程入口。查找处理器DispatcherServlet 调用HandlerMapping处理器映射器根据请求 URL 找到对应的HandlerController / 处理器并返回处理器执行链。执行处理器DispatcherServlet 把 Handler 交给HandlerAdapter处理器适配器由适配器调用目标 Controller 的对应方法。业务处理Controller 执行业务逻辑封装数据到Model并返回逻辑视图名如login。解析视图DispatcherServlet 调用ViewResolver视图解析器把逻辑视图名拼接成真实物理视图路径如/WEB-INF/jsp/login.jsp并创建视图对象。渲染响应视图使用 Model 数据渲染页面最终把响应结果返回给客户端。客户端请求 → DispatcherServlet → HandlerMapping → Handler → HandlerAdapter → Controller(处理业务返回视图名) → ViewResolver → 视图渲染 → 响应客户端DispatcherServlet总调度接收所有请求、分发任务核心入口HandlerMappingURL → 找到对应 ControllerHandlerAdapter适配不同类型处理器统一调用规则Controller接收参数、处理业务、封装数据、返回视图名ViewResolver拼接视图路径解析视图View渲染页面生成最终响应现代开发前后端分离Controller 返回JSON 数据不再走视图解析器流程到第 4 步直接返回响应。数据库三大范式1. 第一范式1NF列不可再分属性不可再分规则每一列都是原子值不能再拆分。2. 第二范式2NF消除部分依赖前提必须先满足 1NF规则非主键字段必须完全依赖整个主键不能只依赖主键一部分。3. 第三范式3NF消除传递依赖前提必须先满足 2NF规则非主键字段不能间接依赖主键不能传递依赖。也就是非主键字段不能互相依赖补充实际开发不一定要严格遵循 3NF高并发场景常会反范式适当冗余减少联表查询提升性能。