- 博客(174)
- 收藏
- 关注
RSS订阅原创 【leetcode】排序数组：快速排序、堆排序、归并排序
i+2）的值比当前位置的值大，则将当前位置与子节点位置的值交换，然后对子节点继续做heapify操作。2、从后先前遍历元素：先交换第一个位置（heapify操作后肯定是最大值）和最后一个位置的值，然后对第一个位置做heapify操作，操作完成后继续遍历。2、左半部分和右半部分有序后，新建一个相同长度的新数组，利用2个指针，依次将较小值赋值给新数组。1、找到开始下标和末尾下标的中点，将数组一分为2，继续递归进行排序。1、从后向前遍历元素，构建最大堆：当前位置（i）的左子节点(2。i+1)或者右子节点（2。
2025-12-25 16:27:28
222
原创 【leetcode】前 K 个高频元素
2、父节点位置：(i - 1) / 2、左子节点位置：2 * i + 1、右子节点位置：2 * i + 2。其中位置为0的节点就是堆顶节点。桶排序：将频率作为数组下标，对于出现频率不同的数字集合，存入对应的数组下标。堆大小不小于容量且满足条件，则替换位置0的节点，并将节点向堆下方调整。堆大小小于容量，数组中插入节点，并将节点向堆上方调整；利用优先级队列：PriorityQueue。1、通过数组保存堆数据。
2025-12-09 16:27:51
423
原创 【中间件面试题】Mysql、Redis、MQ、ES、计算机网络
范式（）是数据库设计时遵循的一种规范，不同的规范遵循不同的范式。范式可以避免数据冗余，减少数据库的空间，减轻维护数据完整性的麻烦。属性不可分割。即每个属性都是不可分割的原子项。联合主键不能存在部分依赖。满足第一范式，并且不存在部分依赖，即非主属性必须完全依赖于主属性。(主属性即主键，完全依赖是针对于联合主键的情况，非主键列不能只依赖于联合主键的一部分)。非主键字段不能存在传递依赖。满足第二范式，并且不能存在传递依赖。即非主属性不能与非主属性之间有依赖关系，非主属性必须直接依赖于主属性。
2025-12-09 09:18:18
898
原创 编程题－算法－中等－leetcode－数组中的第K个最大元素
使用该方法，会存在超时，主要问题是只移动了一边的下标值，针对有很多重复值的情况的表现会很差。即可能出现i直接移动到了right-1的位置，这样partition的值就是right-1。方法二的快排就是左指针i和右指针j都同时向中间移动，这样得到的partition的下标就更靠近中间，所以比方法一的快排用时要显著降低：2427ms–>5ms。该题是高频题，并且某些公司会指定使用堆排序来做这道题，所以堆排序的方法也需要掌握。
2025-12-09 09:16:08
263
原创 【方案设计】订单到期关闭如何实现
在电商场景中，创建了一个支付单之后，会通过支付工具进行支付，比如微信支付、支付宝、银行卡等，那么在特殊场景中，会出现，用户先通过微信支付尝试支付，因为网络延迟导致一直未支付成功，后面用户又再用支付宝支付成功了，可是过了一会，微信支付那面又回调通知支付成功了，这种该怎么处理呢？有了延迟消息，我们就可以在订单创建好之后，发送一个延迟消息，比如20分钟取消订单，那就发一个延迟20分钟的延迟消息，然后在20分钟之后，消息就会被消费者消费，消费者在接收到消息之后，去关单就行了。没抢到锁的就失败，下次重试。
2025-12-09 09:15:17
762
原创 【方案设计】如何实现快到期的会员的消息提醒？
可以设置一个key，记录一次消息推送，比如 user_id:message_type，然后设置24小时的超时时间，每一次在发送通知前，先检查这个key是否存在，如果不存在再发送，发送后把这个key设置上值和超时时间。这里还可以进一步优化，因为上面的SQL中，查询用了like "%0"这个是没办法走索引的，我们可以用like优化的方式，让能用到索引，这样就可以吧user_id和expire_time建一个联合索引，进一步提升查询性能。首先可以明确的是，百万级会员，这个量级不算大！好的办法就是异步推送。
2025-12-09 09:15:01
636
原创 【方案设计】Redis应用场景、朋友圈点赞功能、排行榜、滑动窗口
比如如果要做一个全国的排行榜，那么不需要把全国的数据都放在一个 ZSET 中，我只需要按照省份，把不同的省份的数据单独放到一个 ZSET 中，排出每个省的排行榜，然后需要查询全国的排行榜的时候，在进行一次跨 ZSET 的排序就行了。作为一个排行榜，需要实时、高效的更新排行榜的数据，那么，如何处理用户分数的实时更新和排名计算，同时保证系统的性能和实时性，是一个至关重要的问题。：如果在 5 分钟内的请求次数没有超过限制，脚本会将当前请求的时间戳添加到 Redis 的有序集合中，并返回 1，表示允许请求。
2025-12-09 09:14:48
776
原创 【方案设计】缓存相关场景
首先我们需要有机制可以发现 Redis 挂了，最常见的就是加监控了，一般对于 Redis 自己可以做监控，我们在业务中也可以基于 Redis 调用的成功率做一些监控，当发现长时间不可用，或者超时之后，就可以认为是 Redis 挂了，就需要考虑应急机制了。在启动过程中预热有一个问题，那就是一旦启动之后，如果需要预热新的数据，或者需要修改数据，就不支持了，那么，在应用的运行过程中，我们也是可以通过定时任务来实现缓存的更新预热的。Redis挂了，如果有一个备用的能顶上，那也是可以的。这样可以简化缓存预热的逻辑。
2025-12-09 09:14:32
586
原创 【方案设计】数据库相关场景
在做了数据归档之后（一般是先分表之后然后再归档），针对最近30天的数据，可以按照买家 ID进行分表，这么大的量 ，建议分成64张表，这样平均下来，单张表就大概有1000万 * 30 / 32不到一千万条数据了。但是，这么做也会带来一定的数据一致性的问题，那就是当users表中的用户改了名字，就会导致orders表中的用户名不一致，这时候就需要考虑同时修改，但是如果订单量很大，改起来是成本很高的。但是前面说了，数据库唯一性约束用于兜底，该有的分布式锁还是有的，所以并发问题倒也还好。
2025-12-09 09:14:19
686
原创 【方案设计】服务器配置相关场景
但是，以上这个计算完全理想化了，完全忽略了CPU、内存、Load等硬件的情况。因为随着并发量的升高，应用的CPU、内存、磁盘等等各种硬件配置的使用情况也是在不断攀升的。最理想的情况是需要3台机器，但是实际情况的话基本上会比这个要多一些，所以大致预估就是按照他的2-3倍来算的话，就是6-9台机器。要估算需要多少台机器来支持一个接口的QPS和RT，需要考虑多个因素，包括机器的性能、并发连接数、负载均衡、缓存等。所以实际在预估的时候，需要在单机上进行压测，根据压测结果来预估需要多少台机器。
2025-12-09 09:13:59
574
原创 【方案设计】设计一个秒杀系统，你会考虑哪些问题？
想要回答好这个问题，首先需要学会做问题的拆解，所谓的定义问题。作为一个5年工作经验以上的人，尤其是偏架构方向的技术人员，要先学会如何定义问题，然后才是解决问题。如果定义问题都做不好，所谓的解决的也都是伪问题。没意义了秒杀系统，我们需要先拆解一下会遇到哪些问题，面试官在问这个问题的时候，其实在问的到底是什么问题？高并发瞬时流量热点数据数据量大库存的正确扣减黄牛抢购重复下单对普通交易的影响。
2025-12-08 11:17:32
618
原创 【方案设计】如何做平滑的数据迁移?
通过上面的流程图，可以发现，双写是几乎伴随着整个迁移的完整生命周期的，但是实际上，在第一次双写读旧（增量数据迁移） 和双写读新（增量数据迁移）的两个节点上，双写是不一样的，因为第一个阶段我们要保证旧库成功，新库可以失败（因为读发生在旧库上，要保证写入成功，否则会读不到数据）。这里需要我们做一个逻辑，那就是在update/delete的时候，判断一下这个数据是增量的还是存量的，其实就是判断新表中是否有这个数据，如果有，就需要做双写更新，如果没有，就说明这是个存量数据，只更新旧表就行了。
2025-12-08 11:16:48
801
原创 【方案设计】分布式锁相关场景
之后，事务才会提交。首先，代码中通过@Transactional在order方法上增加了一个事务，事务的范围是整个方法，也就是方法全部执行完，事务才会提交。查询数据也查不到，因为这时候之前的那个事务可能还没提交，未提交的数据，新的事务是看不到的。那么就会出现一个问题，锁已经释放了，但是事务还没提交。想要解决这个问题，就是减小事务的粒度，或者增大锁的粒度，不要在事务提交前就把锁释放掉。解决接口幂等问题，最常用的方式是：一锁、二判、三更新。以上代码，其实是有可能出现脏数据的。执行更新操作，导致数据重复。
2025-12-08 11:16:14
165
原创 【方案设计】和外部机构交互如何防止被外部服务不可用而拖垮？
而运费险投保如果稍微晚一会，在小时级别的话，理论上对业务是无损的，因为一般不太可能几个小时内就发货，收货，退货。所以，我们就可以异步的和外部的保险公司进行交互，通过定时任务或者延迟消息的方式，和保司交互，这样可以起到削峰填谷的作用，并且这个链路可以不断重试，即使失败了，也不会影响到正常的下单主流程。很多时候，我们自己的可用性可以有一些保障的，但是，外部机构的可用性是没办法保证的，比如双十一大促期间，支付方式除了支付宝之外，还可能用银行卡支付，但是很难保证银联系统可以抗这么高的并发。这样做对业务是有损的。
2025-12-08 11:14:59
474
原创 【设计模式】设计模式原则、单例模式、工厂模式、模板模式、策略模式
设计模式是在软件开发过程中经常遇到的问题的通用解决方案。它们是经过无数的验证和经验积累的最佳实践。首先，设计模式是一些前人经验的一些总结，所以，当遇到相似的问题的时候，我们可以直接借鉴好的设计模式来实现，这样可以大大降低我们的试错成本和迭代成本。可以大大提升我们的开发速度。不要认为只有23种，只要是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结都是软件设计模式的。比如说MVC而且，设计模式都是遵守了很多设计原则的，这些原则可以帮助我们大大提升代码的可重用性、可维护性和可扩展性等。
2025-12-08 11:11:56
977
原创 【操作系统】同步阻塞IO、同步非阻塞IO、IO复用模型、异步IO
在计算机中，内核是操作系统的核心，负责管理和控制计算机硬件资源，提供各种系统服务。内核态是操作系统运行在特权模式下的状态，此时操作系统具有最高的权限，可以访问所有的硬件资源和底层系统资源，如处理器、内存、I/O等。在内核态下，操作系统可以执行所有的指令，而且不受访问权限的限制。内核态下的程序通常是操作系统内核代码或者设备驱动程序等，它们可以直接访问硬件资源和系统资源，以实现系统的功能和服务。用户态是指应用程序运行在非特权模式下的状态，此时应用程序只能访问被授权的资源，不能直接操作硬件资源和底层系统资源。
2025-12-08 11:10:21
841
原创 【计算机网络】OSI七层模型、TCP协议、HTTP协议
物理层（Physical Layer）：主要规定传输介质的传输方式，包括电信号、电压、光脉冲等。该层的主要协议是物理媒介相关协议，如RS232、V.35、以太网等。数据链路层（Data Link Layer）：在物理层上建立数据链路，对数据进行分帧、差错校验等处理，确保数据可靠地传输。该层的主要协议有点对点协议PPP（Point-to-Point Protocol）、高级数据链路控制协议HDLC（High-Level Data Link Control）、以太网协议等。
2025-12-08 11:05:47
1050
原创 【Zookeeper】数据结构、集群原理、选举机制
脑裂是在分布式系统中经常出现的问题之一，它指的是由于网络或节点故障等原因，导致一个分布式系统被分为多个独立的子系统，每个子系统独立运行，无法相互通信，同时认为自己是整个系统的主节点，这就会导致整个系统失去一致性和可用性。可以通过设置合适的选举超时时间、设置合适的节点数量等方式来减少脑裂的可能性。同时，可以使用ZooKeeper提供的Watch机制来监听节点状态的变化，及时发现并处理异常情况，从而避免脑裂的发生。Zookeeper集群中的脑裂出现的原因通常有以下2种情况：网络分区。
2025-12-08 11:01:04
883
原创 Mysql高级篇学习总结15：覆盖索引、索引下推
如果索引列＋主键包含了SELECT语句中的所有字段，那么使用二级索引后，可以省下了回表操作的话，这种情况就是覆盖索引。
2025-12-08 10:52:30
823
原创 【ElasticSearch】ES架构、倒排索引、深分页问题
在Elasticsearch中进行分页查询通常使用from和size参数。当我们对Elasticsearch发起一个带有分页参数的查询（如使用from和size参数）时，ES需要遍历所有匹配的文档直到达到指定的起始点（from），然后返回从这一点开始的size个文档。"query": {ES的检索机制决定了，当进行分页查询时，Elasticsearch需要先找到并处理所有位于当前页之前的记录。
2025-10-14 10:23:07
622
原创 【注册中心】Nacos
Nacos是一个基于云原生架构的动态服务发现、配置管理和服务治理平台。支持多种编程语言和多种部署方式，并且与Spring Cloud等主流的微服务框架深度集成。配置管理：可以将应用程序的配置信息存储在Nacos的配置中心，通过Nacos实现动态配置管理和灰度发布，从而实现应用程序的动态调整和部署。服务发现及注册：可以将服务注册到Nacos注册中心，并通过Nacos实现服务的自动发现和负载均衡，从而实现服务的高可用和弹性伸缩。
2025-10-14 10:16:12
596
原创 【RabbitMQ】架构原理、消息丢失、重复消费、顺序消费、事务消息
想要保证发送者一定能把消息发送给RabbitMQ，一种是通过confirm机制，另外一种就是通过事务机制。RabbitMQ的事务机制，允许生产者将一组操作打包成一个原子事务单元，要么全部执行成功，要么全部失败。事务提供了一种确保消息完整性的方法，但需要谨慎使用，因为它们对性能有一定的影响。因为事务机制是同步的，提交一个事务之后会阻塞在那儿，但是 confirm机制是异步的，发送一个消息之后就可以发送下一个消息，RabbitMQ 接收了之后会异步回调confirm接口通知这个消息接收到了。
2025-10-14 09:55:47
899
原创 【RocketMQ】架构原理、消息丢失、重复消费、顺序消费、事务消息
首先在生产者端，消息的发送分为同步、异步两种和单向发送（单向发送不保证成功，不建议使用），在同步发送消息的情况下，消息的发送会同步阻塞等待Broker返回结果，在Broker确认收到消息之后，生产者才会拿到SendResult。那就可能会导致没有人知道这个消息失败了，就导致不会重试了。不管是因为什么情况了，是真的消费失败了，还是出现了异常了，还是明明消费成功了，但是你错误的返回了失败等等情况，只要你给RocketMQ返回的是 RECONSUME_LATER ，那么消息就会重投，有重投就会有重复消费。
2025-10-14 09:55:32
914
原创 【Kafka】架构原理、消息丢失、重复消费、顺序消费、事务消息
当我们使用Kafka发送消息时，一般有两种方式，分别是同步发送（producer.send(msg).get() ）及异步发送（producer.send(msg, callback)）。同步发送的时候，可以在发送消息后，通过get方法等待消息结果：producer.send(record).get();，这种情况能够准确的拿到消息最终的发送结果，要么是成功，要么是失败。而异步发送，是采用了callback的方式进行回调的，可以大大的提升消息的吞吐量，也可以根据回调来判断消息是否发送成功。
2025-10-12 16:43:03
982
原创 【Redis】用Redis实现分布式锁、乐观锁
RedLock是Redis的作者提出的一个多节点分布式锁算法，旨在解决使用单节点Redis分布式锁可能存在的单点故障问题。Redis的单点故障问题：1、在使用单节点Redis实现分布式锁时，如果这个Redis实例挂掉，那么所有使用这个实例的客户端都会出现无法获取锁的情况。
2025-10-12 16:41:51
827
原创 【Dubbo】Rpc与HTTP的区别、Dubbo调用过程
RPC 是Remote Procedure Call的缩写，译为远程过程调用。要想实现RPC通常需要包含传输协议和序列化协议的实现。而熟知的HTTP，他的中文名叫超文本传输协议，所以他就是一种传输协议。所以，我们可以认为RPC和HTTP并不是同一个维度的两个概念。只不过他们都是可以作为远程调用的，所以经常拿来对比。RPC的具体实现上，可以像HTTP一样，基于TCP协议来实现，也可以直接基于HTTP协议实现。RPC主要用于公司内部服务之间的互相调用，所以他性能消耗低，传输效率高，服务治理方便。
2025-09-25 11:27:03
1157
原创 【Redis】热Key/大Key问题、缓存击穿、缓存穿透、缓存雪崩、缓存与数据库一致性问题
当使用Redis作为存储时，如果发生一些特殊情况，比如明星官宣的突发事件，世界杯等重大活动，双十一的活动秒杀等等，就会出现特别大的流量，并且会导致某些热词、商品等被频繁的查询和访问。如果在同一个时间点上，Redis中的同一个key被大量访问，就会导致流量过于集中，使得很多物理资源无法支撑，如网络带宽、物理存储空间、数据库连接等。这也是为什么某某明星官宣之后，微博上面就会出现宕机的情况。有时候这种宕机发生后，其他功能都是可以使用的，只是和这个热点有关的内容会无法访问，这其实就和热点数据有关系了。
2025-09-25 10:18:55
1246
原创 【Redis】Redis为什么这么快、Redis数据类型
Sorted Set 能支持范围查询，这是因为它的核心数据结构设计采用了跳表，而它又能O(1)的复杂度获取元素权重，这是因为它同时采用了哈希表进行索引。dict *dict;} zset;以上是zset的数据结构，其中包含了两个成员，分别是哈希表dict和跳表zsl。dict存储 member->score 之间的映射关系，所以 ZSCORE 的时间复杂度为 O(1)。skiplist 是一个「有序链表 + 多层索引」的结构，查询元素的复杂度是 O(logN)，所以他的查询效率很高。
2025-09-25 10:16:53
758
原创 【Redis】集群模式、持久化机制、事务机制、过期策略
Redis有三种主要的集群模式，用于在分布式环境中实现高可用性和数据复制。这些集群模式分别是：主从复制（Master-Slave Replication）、哨兵模式（Sentinel）和Redis Cluster模式。Redis 的 Pipeline 机制是一种用于优化网络延迟的技术，主要用于在单个请求/响应周期内执行多个命令。在没有 Pipeline 的情况下，每执行一个 Redis 命令，客户端都需要等待服务器响应之后才能发送下一个命令。这种往返通信尤其在网络延迟较高的环境中会显著影响性能。
2025-09-25 10:15:48
969
原创 【分布式】分布式ID生成方案、接口幂等、一致性哈希
哈希算法大家都不陌生，经常被用在负载均衡、分库分表等场景中，比如说我们在做分库分表的时候，最开始我们根据业务预估，把数据库分成了128张表，这时候要插入或者查询一条记录的时候，我们就会先把分表键，如buyer_id进行hash运算，然后再对128取模，得到0-127之间的数字，这样就可以唯一定位到一个分表。但是随着业务得突飞猛进，128张表，已经不够用了，这时候就需要重新分表，比如增加一张新的表。这时候如果采用hash或者取模的方式，就会导致128+1张表的数据都需要重新分配，成本巨高。
2025-09-23 10:57:36
1204
原创 【分布式】分布式事务方案：两阶段、TCC、SEATA
所谓一致性，是指数据在多个副本之间是否能够保持一致的特性。在聊一致性的时候，其实要搞清楚一致性模型。（概念挺多，但是没办法，这玩意它本身就是理论。想结合代码、示例都做不到，甚至想着画个图都不知道该如何下手）分布式系统中的一致性模型是一组管理分布式系统行为的规则。它决定了在分布式系统中如何访问和更新数据，以及如何将这些更新提供给客户端。面对网络延迟和局部故障等分布式计算难题，分布式系统的一致性模型对保证系统的一致性和可靠性起着关键作用。
2025-09-23 10:56:26
1158
原创 【微服务】微服务如何拆分、如何解决循环依赖
微服务（Microservices）是一种软件架构风格，用于构建复杂的应用程序。它将一个大型的应用程序拆分成一组小型、独立的服务单元，每个服务单元都可以独立部署、运行和扩展。每个微服务都专注于执行一个特定的业务功能，并通过轻量级的通信机制（如HTTP、RPC、MQ等）来相互调用。微服务的目的是有效的拆分应用，实现敏捷开发和部署。比如把一个原来中心化的商城服务，拆分成产品服务、订单服务及用户服务，每一个服务把功能内聚，系统间通过远程调用解耦。实现高内聚低耦合。并且每一个服务都可以独立的提供子服务。
2025-09-20 16:13:18
1003
原创 【Tomcat】基础总结：类加载机制
Tomcat的类加载机制，在默认情况下，是先把当前要加载的类委托给BootstrapClassLoader尝试加载，为了避免JRE中的核心类被我们应用自己的类给覆盖（如String等），Bootstrap如果无法加载，那么就由WebAppClassLoader尝试加载，如果无法加载，那么再委托通过双亲委派的方式向上委派给Common、System等类加载进行加载，即顺序为：Bootstrap->WebApp->System->Common。启动类加载器是JVM的一部分，负责加载JVM运行所需的基础类。
2025-09-20 15:47:09
817
原创 【Mybatis】基础总结：缓存机制、如何实现分页
在Hibernate当中，开发者只需要定义好数据库的表字段和Java DO的映射关系和规则即可，Hibernate会开放出来接口自动去处理数据库表的CURD，并按照规定好的规则映射到DO对象中，这个过程中操作者是完全不需要感知Sql逻辑的。二级缓存的使用需要注意缓存的更新和失效机制，以及并发操作的问题。在同一个会话中，Mybatis会将执行过的SQL语句的结果缓存到内存中，下次再执行相同的SQL语句时，会先查看缓存中是否存在该结果，如果存在则直接返回缓存中的结果，不再执行SQL语句。增加开发者的开发效率。
2025-09-20 15:46:13
751
原创 【Mysql】深分页问题、页分裂问题、加密/解密、执行计划
MySQL的数据是存储在磁盘上面的（Memory引擎除外），但是如果每次数据的查询和修改都直接和磁盘交互的话，性能是很差的。于是，为了提升读写性能，Innodb引擎就引入了一个中间层，就是buffer pool。buffer是在内存上的一块连续空间，他主要的用途就是用来缓存数据页的，每个数据页的大小是16KB。
2025-09-20 15:45:38
937
原创 【Mysql】count(1)/count(*) /count(列名) 的区别、自增主键原理、exists/in的区别
那么，不管是我们自己定义的自增主键，还是row_id的这个主键，都是一个固定类型的，一般都是bigint unsigned，那么既然有固定类型，就有取值范围。但是，MySQL在使用的时候，还有一种做法，那就是读写分离，即在主库上操作写，在从读库上进行读，这时候主库和从库都是对外提供服务的。当然，前提是单库的情况下，如果你说的是分库分表的情况下，那就另当别论了。日常使用的MySQL，虽然也是有多个节点的，但是大多数情况下都是主备的，即只有一个主节点对外提供服务，当主节点挂了之后，备节点顶上来。
2025-09-20 15:44:19
696
原创 【Mysql】事务隔离级别、索引原理、/redolog/undolog/binlog区别、主从复制原理
【数据库三大范式和反范式】范式（）是数据库设计时遵循的一种规范，不同的规范遵循不同的范式。范式可以避免数据冗余，减少数据库的空间，减轻维护数据完整性的麻烦。属性不可分割。即每个属性都是不可分割的原子项。联合主键不能存在部分依赖。满足第一范式，并且不存在部分依赖，即非主属性必须完全依赖于主属性。(主属性即主键，完全依赖是针对于联合主键的情况，非主键列不能只依赖于联合主键的一部分)。非主键字段不能存在传递依赖。满足第二范式，并且不能存在传递依赖。
2025-09-20 15:36:01
1119
原创 【Spring】SpringBoot原理
SpringApplication.run(Application.class, args)方法的实现细节如下：一个是new SpringApplication的初始化过程，一个是SpringApplication.run的启动过程。这个过程确保了在应用上下文被创建和启动之前，所有关键的设置都已就绪，包括环境设置、初始化器和监听器的配置，以及主应用类的识别。这一步，是Spring启动的核心步骤了，这一步骤包括了实例化所有的 Bean、设置它们之间的依赖关系以及执行其他的初始化任务。
2025-09-20 15:32:27
621
原创 【Spring】Spring Event事件驱动
在上面的示例中，UserRegistrationEvent 事件在用户注册成功后发布，然后 UserRegistrationEventListener 中的 handleUserRegistrationEvent 方法在事务成功提交后触发，发送欢迎邮件。Spring框架中的事件机制建立在观察者模式的基础上，允许应用程序中的组件注册监听器来监听特定类型的事件，并在事件发生时执行相应的操作。事件监听器将在事务尚未提交时执行，这意味着它可以在事务内部进行回滚操作，如果事件监听器抛出异常，将导致事务回滚。
2025-09-20 15:31:32
737
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人