- 博客(480)
- 资源 (9)
- 收藏
- 关注
RSS订阅原创 常见系统质量属性及其实现策略
可靠性是指软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。性能属性是指软件系统的响应能力，即要经过多长时间才能对某个事件做出响应（RT），或者某段时间内系统所能处理的事件的个数（TPS或RPS）。如响应时间、吞吐量。可用性是指系统能够正常运行的时间比例，经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示，如故障间隔时间。可测试性是指软件发现故障并隔离、定位器故障的能力特性，以及在一定的时间和成本的前提下，进行测试设计、测试执行的能力。
2026-02-08 20:24:12
83
原创 23.11.MQTT协议
MQTT（Message Queuing Telemetry Transport）是一种基于发布/订阅（pub/sub）模式的轻量级消息传输协议。它设计时主要考虑到低带宽、高延迟或不可靠网络环境中，特别适用于物联网（IoT）设备间的通信。1）轻量级：MQTT的协议头非常小，适合带宽受限或资源有限的环境。2）实时性：适合需要实时、及时传输数据的应用场景。3）可靠性：支持三种消息传递质量（QoS）等级，能够保证消息的可靠传递。4）可扩展性：支持大规模设备的连接，可以灵活地扩展。
2025-12-19 22:57:40
645
原创 3.2.15.1.常见注解
RestController：是@Controller 和 @ResponseBody 的结合体，返回 JSON 数据时使用。@Component：标识一个类为 Spring 组件，使其能够被 Spring 容器自动扫描和管理。@RequestBody：表示一个方法参数应该绑定到 Web 请求体。@RequestParam：用于接收请求参数。@PointCut：定义切点，指定需要拦截的方法。@Controller：用于标注控制层组件。@Before：在方法执行之前执行。@After：在方法执行之后执行。
2025-12-17 21:37:07
357
原创 4.5.4.数据查询连接
在关系型数据库中，连接（Join）是 SQL 查询中最常用的操作之一，它用于在两个或多个表之间建立逻辑关系，将相关数据组合成一个结果集。理解连接机制对于优化查询性能、设计高效数据库结构非常重要。
2025-12-17 20:15:23
378
原创 4.1.17.8.高性能
按照一定的策略将一个表中的数据拆分到多个库中，例如，按照用户 id 的 hash 值将用户表拆分到不同的库中。哈希路由的优点是数据可以均匀分布，避免了数据倾斜，但范围查询时可能会涉及多个表，性能较差。范围路由的优点是实现简单，可以随着数据的增加平滑地扩充新的表。缺点是需要额外的配置表，维护成本较高。垂直拆分可以减轻查询业务的基本数据，不需要附带一些数据量大的字段的查询压力。配置路由是通过配置表来确定数据存储的表，适用于分片键不规律的场景。水平分表，将一个表的数据分散到多个表中，以减轻单表的查询压力。
2025-12-17 19:41:59
270
原创 4.2.20.Redis：Redis各数据类型的作用
Redis 中的字符串是最简单的数据类型，可以包含任何数据，如字符串、数字或二进制数据（例如图片或文件）。每个字符串的最大长度为512 MB。哈希是一种键值对的集合，适合存储对象或结构化数据，每个哈希内部有多个字段和值，类似于一个字典（Dictionary）。通过哈希，Redis 可以对多个字段执行高效的读取和更新操作。列表是一个有序的字符串集合，允许重复的元素。可以在列表的两端进行推入（LPUSH, RPUSH）和弹出（LPOP, RPOP）操作。
2025-12-17 11:06:51
597
原创 4.1.17.7.SQL优化
可以在业务的基建中加入对慢 SQL 的监控，常见的方案有字节码插桩、连接池扩展、ORM 框架过程，对服务运行中的慢SQL 进行监控和告警。在执行 JOIN 操作时，应尽量让行数较少的表（小表）驱动行数较多的表（大表），这样可以减少查询过程中需要处理的数据量。在某些情况下，通过在表中适当增加冗余字段来避免 JOIN 操作，可以提高查询效率，尤其是在高频查询的场景下。是指在创建索引时，只对列的前部分字符（而非整个列）进行索引，通常用于 字符串类型的字段，以节省空间并提高查询效率。
2025-12-16 22:09:48
801
原创 4.1.17.6.锁
临键锁就是记录锁(Record Locks)和间隙锁(Gap Locks)的结合，即除了锁住记录本身，还要再锁住索引之间的间隙。有了意向锁之后，要执行的事务 A 在申请行锁（写锁）之前，数据库会自动先给事务 A 申请表的意向排他锁。排他锁（X Lock），也叫写锁（write lock），排它锁是阻塞的，在一定时间内，只有一个请求能执行写入，并阻止其它锁读取正在写入的数据。意向锁的出现是为了支持 InnoDB 的多粒度锁，它解决的是表锁和行锁共存的问题。锁定粒度小，发生锁冲突的概率低，并发度高。
2025-12-16 21:16:20
528
原创 4.1.17.5.MySQL事务
MVCC 是多版本并发控制，主要用来解决数据库并发问题。在支持 MVCC 的数据库中，当多个用户同时访问数据时，每个用户都可以看到一个在某一时间点之前的数据库快照，并且能够无阻塞地执行查询和修改操作，而不会相互干扰。在传统的锁机制中，如果一个事务正在写数据，那么其他事务必须等待写事务完成才能读数据，MVCC 允许读操作访问数据的一个旧版本快照，同时写操作创建一个新的版本，这样读写操作就可以并行进行，不必等待对方完成。
2025-12-15 21:36:01
885
原创 4.1.17.4.MySQL索引
最常见的索引类型，一种将索引值按照一定的算法，存入一个树形的数据结构中（二叉树），每次查询都从树的根节点开始，一次遍历叶子节点，找到对应的值。在非聚簇索引中，索引和数据是分开存储的，索引中的键值指向数据的实际存储位置。的数据列只用辅助索引中就能够取得，不用去查主键索引，这时候使用的索引就叫做覆盖索引，避免了回表。树中，非叶子节点不存储数据，只存储键值，这意味着非叶子节点可以拥有更多的键，从而有更多的分叉。也就说，在进行查询时，如果没有遵循最左前缀，那么索引可能不会被利用，导致查询效率降低。
2025-12-15 20:35:20
640
原创 4.1.17.3.MySQL日志
MySQL日志是指 MySQL 数据库系统中记录的重要事件、查询、错误和性能信息的文件。日志是数据库管理和诊断的重要工具，能够帮助管理员监控、排查问题、优化性能、以及进行故障恢复。binlog是一种物理日志，会在磁盘上记录下数据库的所有修改操作，以便进行数据恢复和主从复制。当发生数据丢失时，binlog 可以将数据库恢复到特定的时间点。主服务器（master）上的二进制日志可以被从服务器（slave）读取，从而实现数据同步。默认没启动，要启动需要去配置文件配置参数。
2025-12-15 13:55:10
979
原创 4.1.17.2.存储引擎
存储引擎是数据库管理系统（DBMS）中负责数据存储、检索、管理的核心组件。不同的存储引擎实现了不同的存储方式、索引方式、锁机制以及事务管理等功能。对于MySQL 来说，存储引擎决定了表数据的存储结构、如何处理索引、事务管理等一系列操作。每种存储引擎都有不同的特性，适用于不同的应用场景。MySQL支持多种存储引擎，用户可以根据应用需求选择合适的引擎。MYSQL的存储引擎：①Innodb（5.5以后默认）②MyISAM（5.5之前）、③Memory（存储在内存）
2025-12-13 22:56:44
166
原创 4.1.17.1.MYSQL基础
语句的执行计划，这包括选择使用哪些索引，以及决定表之间的连接顺序等。缓存的维护和失效操作会引起严重的锁竞争，尤其是在 InnoDB 存储引擎下。应用层缓存更灵活，可缓存查询结果或业务对象，避免数据库内部复杂锁竞争。如果没有，进入下一步。的存储引擎是插件式的，不同的存储引擎在细节上面有很大不同。很多用户根本不使用查询缓存，或者使用不当。语法规则，确保引用的数据库、表和列都存在，并处理。第七步，客户端接收到查询结果，完成这次查询请求。①按指定列分组，并对每组数据执行聚合计算。以后已经干掉了），连接建立后，
2025-12-13 22:26:09
945
原创 23.10.WebService技术
WebService（网络服务） 是一种基于 Web 的分布式应用程序交互方式，它允许不同平台、不同语言的应用程序通过网络进行互操作。1）跨平台：支持 Java、.NET、Python 等多种语言。2）基于标准：主要依赖 HTTP、XML、SOAP、WSDL 等标准。3）可远程调用：客户端可以像调用本地函数一样调用远程服务。4）面向服务：服务提供者提供功能，服务消费者调用功能。
2025-12-13 19:27:22
473
原创 30.8.14.数据库与数据仓库
数据库是一个按照一定的数据模型（通常是关系型或非关系型）存储、管理和查询数据的系统，主要用于日常业务事务处理（1）数据存储与管理：持久化存储业务数据（如订单、用户信息、库存）。2）数据查询：提供灵活、快速的查询接口（SQL或NoSQL查询）。3）事务处理：保证数据一致性、完整性和原子性（ACID原则）。4）高并发支持：同时处理大量用户的请求而不出现冲突或延迟。
2025-12-11 18:30:14
735
原创 3.2.9.2.SpringBoot实现数据验证
注意：spring-boot-starter-validation 是必须的，否则 @Valid 或 @Validated 无法生效。在 Web 开发中，前端表单提交的数据通常需要在后端进行验证，以确保数据合法性和安全性。如果是前后端分离，推荐返回 JSON 错误，由前端统一处理。@NotBlank 字符串不能为 null 且去空格后长度 > 0。若有错误，可以返回给前端友好的提示信息。"password": "密码长度不能少于6位""username": "用户名不能为空",
2025-12-10 16:33:34
460
原创 27.3.12.缓存：如何选择缓存的读写策略
极端情况下，比如一个有三个节点 A、B、C 承担整体的访问，每个节点的访问量平均，A 故障后，B 将承担双倍的压力（A 和 B 的全部请求），当 B 承担不了流量 Crash 后，C 也将因为要承担原先三倍的流量而 Crash，这就造成了整体缓存系统的雪崩。比如说，我们部署了三个缓存节点组成一个缓存的集群，当有新的数据要写入时，我们先对这个缓存的 Key 做比如 crc32 等 Hash 算法生成 Hash 值，然后对 Hash 值取模，得出的结果就是要存入缓存节点的序号。
2025-12-08 22:48:05
604
原创 3.12.20.数据库加锁的实现代码
Java 实现数据库加锁通常是通过数据库管理系统（DBMS）提供的锁机制来进行的。Java 本身并不直接控制数据库的锁定，而是通过执行 SQL 语句来操作数据库，数据库会根据这些操作自动处理锁。
2025-12-07 09:35:28
625
原创 3.13.2.4.SpringCloud Gateway
Spring Cloud Gateway 是一个在 Spring Cloud 生态系统中用于微服务架构的 API 网关。它提供了路由、过滤、负载均衡、认证和授权等功能，旨在简化微服务间的请求路由与管理，且提供了一些高级特性，如限流、断路器、负载均衡等。1）路由请求：将请求从客户端路由到正确的服务。2）过滤：对请求和响应进行处理，支持前置和后置过滤器。3）负载均衡：集成了 Ribbon 或者其他负载均衡工具，能自动平衡请求。
2025-12-06 08:07:37
574
原创 3.13.3.15.Nacos实例
在 Spring Boot 项目中，已经通过 spring-cloud-starter-alibaba-nacos-discovery 实现了 Nacos 与 Spring Cloud 的服务注册与发现。通过 Nacos 进行服务注册时，我们需要在 application.yml/application.properties 配置 Nacos 服务地址以及服务名称等信息。当修改了 Nacos 中的配置，Nacos 会推送更新到所有已注册的服务实例，服务实例会自动刷新配置，无需重启。
2025-12-05 10:55:39
501
原创 3.13.3.14.Nacos
在现代微服务架构中，服务注册与发现、配置管理是至关重要的组件。Nacos（Dynamic Naming and Configuration Service）是一个开源的分布式服务注册与配置管理平台，提供了服务发现、配置管理、动态DNS等功能。它不仅支持Spring Cloud和Kubernetes等生态系统，还能够帮助开发人员和运维人员更好地管理微服务系统中的配置与服务状态。
2025-12-04 21:35:42
1027
原创 3.13.3.13.容错技术：Hystrix
Hystrix 是由 Netflix 开源的一款容错框架，旨在帮助开发者处理分布式系统中的服务容错问题，尤其是在微服务架构中，能够有效防止故障蔓延，保障系统的可用性。在断路器进入打开状态一段时间后，Hystrix 会尝试恢复服务，允许一定量的请求通过进行检查，如果恢复正常，则进入闭合状态；当请求的失败率超过设定阈值时，断路器进入打开状态，所有请求都直接被拒绝，防止进一步对目标服务造成压力。Hystrix允许设置超时时间，一旦请求超过该时间，Hystrix 会认为请求失败，在不同的服务调用中，
2025-12-03 17:58:26
828
原创 27.2.19.分布式：服务注册中心应该是AP还是CP
之所以不能满足CA，因为网络通信的不确定性可能会导致分区容错，也就是分区容错性必然是存在的，因此我们只能在一致性和可用性之间做选择。再回到注册中心（如图），服务注册中心的本质是为了提供服务地址的统一管理，以及提供一个服务动态感知的能力。所以，注册中心应该要保证高可用性，也就是无论什么情况下，应用都能正常从注册中心获取到目标服务的通信地址。，分区相当于对通信耗时的要求，系统如果不能在时限范围内达成数据一致，就意味着发生了分区的情况。，每次请求都能获得一个有效的访问，但不保证数据是最新的。
2025-12-03 09:43:55
190
原创 27.2.17.分布式：TCC中的悬挂问题
而悬挂问题，指的是TCC执行Try接口出现网络超时时候，使得TCC触发Cancel接口回滚，但可能在回滚之后，这个超时的Try接口才被真正执行，也就导致Cancel接口比Try接口先执行。所以，我们可以在Try接口里面，先判断Cancel接口有没有执行过，如果已经执行过，就不再执行。当所有事务参与者的try方法执行成功，就执行confirm方法完成真正逻辑的执行，很显然，这是一个最终一致性的实现方案，因此当Try执行成功，就必须确保Confirm执行成功。是实现业务的检查，预留必要的业务资源。
2025-12-03 09:21:01
167
原创 27.2.16.分布式：分布式事务解决方案
这是四个典型的事务操作，而且这些操作分别属于不同的数据库，最终期望的结果是希望这三个服务所对应的数据是一致的，很显然传统的事务无法解决这个问题！在传统架构下，这种问题出现的情况非常少，但是在分布式微服务架构中，分布式事务的问题变得更加突出。1）一种是基于XA协议实现的强一致性事务方案，比如Atomikos、Seata中的XA事务模型。以电商项目为例，假设我们要实现电商系统中的支付功能，它的实现流程如下（如图）。事务具有分布式特性，简单理解就是如何实现多个跨数据库的小事务组成的大事务的ACID特性。
2025-12-03 08:41:16
163
原创 27.2.15.分布式：CAP原理
CAP 定理，由计算机科学家 Eric Brewer 在 2000 年提出，是描述分布式系统中无法同时满足三大特性（一致性、可用性、分区容错性）的理论。
2025-12-03 08:15:42
305
原创 27.2.14.分布式：服务降级
熔断机制以后，如果后续再向故障节点发起请求的时候，这个请求不会发送到故障节点上，而是直接置为失败，这样就避免了请求堆积。在一个请求链路中，为了避免某个服务节点出现故障导致请求堆积，造成资源消耗是的服务崩溃的问题，一般会采取熔断策略。简单来说，就是当服务器压力增加的情况下，根据实际业务的需求和流量的情况，不对外提供部分服务的功能。因此，降级带来的结果是使得用户的体验下降，但是却保证了系统的稳定性和可用性。服务降级有两种方式，一种是主动降级，一种是基于特定情况的被动降级。比如返回一个“系统繁忙”之类的信息。
2025-12-02 21:29:17
325
原创 27.2.13.分布式：常用的分布式ID设计方案
另外，美团公司开源了一个全局唯一id生成系统leaf，它里面也用到了雪花算法去构建全局唯一id。并且在高性能和高可用方面，做了很多的优化，为美团内部业务提供了每天上亿次的调用。因此，在如果我们选择数据库的全局表，每获取一次id就需要更新数据库，性能上限比较明显，而且基于数据库构建高扩展和高性能的解决方案难度很大。有序的ID能够更好的确认数据的位置，以及B+数的存储结构中，范围查询的效率更高，并且可以提升B+树数据维护的效率。全局id生成系统需要满足整个公司的业务需求，涉及到亿级别的调用，对性能要求较高。
2025-12-02 21:20:44
320
原创 27.2.12.分布式：分布式和微服务
对于一些大型的互联网项目来说，微服务能够在不影响用户使用的情况下非常方便的实现产品功能的创新和上线。简单来说，分布式是一组通过网络进行通信，并且为了完成共同的计算任务的计算机节点组成的系统。，但是硬件的提升本身也是有瓶颈的，所以当企业对于计算要求越来越高的时候，集中式架构已经无法满足需求了。其实微服务架构本身就是一种分布式架构，它强调的是对部署在各个计算机上的应用服务的粒度。分布式系统的设计理念，其实是来自于小型机或者大型机的计算能力的瓶颈和成本的增加。拆分的好处是使得程序的扩展性更强，开发迭代效率更高。
2025-12-02 21:11:01
293
原创 27.2.11.分布式：Cookie和Session的区别
所以Session是用来弥补Http无状态的不足，简单来说，服务器端可以利用session来存储客户端在同一个会话里面的多次请求记录。客户端第一次访问服务端的时候，服务端会针对这次请求创建一个会话，并生成一个唯一的sessionId来标注这个会话。所以，总的来看，Cookie是客户端的存储机制，Session是服务端的存储机制。基于服务端的session存储机制，再结合客户端的Cookie机制，就可以实现有状态的Http协议。Cookie，它是客户端浏览器用来保存服务端数据的一种机制。
2025-12-02 20:01:11
213
原创 27.2.10.分布式：限流算法
网关层面的限流、或者接口调用的限流，都可以使用令牌桶算法，像Google的Guava，和Redisson的限流，都用到了令牌桶算法。限流的本质是实现系统保护，最终选择什么样的算法，一方面取决于统计的精准度，另一方面考虑限流维度和场景的需求。（如图)漏桶算法，它是一种恒定速率的限流算法，不管请求量是多少，服务端的处理效率是恒定的。令牌桶以恒定速率去生成令牌保存到令牌桶里面，桶的大小是固定的，令牌桶满了以后就不再生成令牌。流量低峰的时候，令牌桶会出现堆积，因此当出现瞬时高峰的时候，有足够多的令牌。
2025-12-02 19:38:11
204
原创 27.2.9.分布式：分布式锁
因此，在集群架构中，由于数据一致性的问题，极端情况下，多个线程抢占同一个锁的现象是很难避免的。锁的互斥方面，Zookeeper 通过有序节点和 Watch 机制 实现锁的互斥与唤醒，而 etcd 则基于 Prefix 机制 和 Watch 结合来实现类似功能。往表里面插入一条数据，如果已经有其他的线程获得了某个方法的锁，那这个时候插入数据会失败，从而保证了互斥性。分布式锁和线程锁本质上是一样的，线程锁的生命周期是单进程多线程，可以实现锁的排他性，当key不存在就返回1，存在就返回0。
2025-12-02 19:18:32
384
原创 27.2.8.分布式：项目中如何保证的接口幂等
具体来说，SETNX 命令只有在键不存在时才会执行设置操作，如果该键已存在，则不做任何操作。，在很多的业务场景中，都会存在业务状态的流转，并且这些状态流转只会前进，所以我们在对数据进行修改的时候，比如支付操作，如果支付接口被重复调了N次，那资金的扣减只发生一次，这就是幂等。原因很简单｛如图｝， 在分布式架构中，由于引入了网络通信导致一个请求，一旦出现重复消息，就会抛异常，我们可以捕获这个异常来避免重复对数据做变更。一个接口，使用相同的参数重复执行的情况下，对数据造成的改变只发生一次。
2025-12-02 18:58:10
291
原创 27.2.7.分布式：RPC 和 HTTP 协议的区别
Client stub作为客户端存根，代理客户端请求并把请求参数进行组装，再把组装的参数通过Pack也就是序列化。的通信而设计的远程通信协议，它定义了通信协议的报文规范（如图），我们可以使用http协议来实现跨网络节点的数据传输。所以，通过这样一个模型，就实现了RPC的目标，让开发者在没有任何感知的情况下实现了远程方法的调用。是，让开发人员在进行远程方法调用的时候，就像调用本地方法一样，不需要额外为了完成这个交互做过的编码。协议底层的数据传输，即可以直接使用TCP协议，也可以使用http协议。
2025-12-02 18:46:05
307
原创 27.2.6.分布式：消息队列MQ
流量削峰一般应用在大流量入口且短时间内业务需求处理不完的服务中心，为了权衡高可用，把大量的并行任务发送到MQ中，依据MQ的存储及分发功能，平稳的处理后续的业务，起到一个大流量缓冲的作用。比如订单系统与WMS、EHR系统，有关联但不哪么紧密，每个系统之间只需要把约定的消息发送到MQ，另外的系统去消费即可。解决了各个系统可以采用不同的架构、语言来实现，从而大大增加了系统的灵活性。服务方只需要把协商好的消息发送到消息队列，剩下的由消费消息的服务去处理，主要负责消息所承载的业务信息的实例化。一个消息队列的终端。
2025-12-02 18:28:49
391
原创 27.2.5.分布式：负载均衡
根据目标服务器的请求数量来决定请求分发的权重，也就是目标服务集群中，请求更少的节点将会获得更多的请求。基于Mac地址来实现请求分发，一般采用虚拟Mac的方式实现，服务器收到请求后，通过动态分配后端服务的实际Mac地址进行响应从而实现负载均衡。负载均衡机制的核心目的是让客户端的请求合理均匀的分发到多台目标服务器，由于请求被多个节点分发，使得服务端的性能得到有效的提升。基于IP层负载，一般通过虚拟IP的方式实现，外部请求访问虚拟IP，服务器收到请求后根据后端实际IP地址进行转发。
2025-12-02 10:41:45
772
原创 27.2.3.分布式：分布式事务的原理
保证每个节点的事务达到同时成功和同时失败，为了实现这样一个需求，我们会引入Xopen/DTP模型提供的XA协议，基于2pc或者3pc的方式来实现。但是，在如果全局事务管理器中的多个节点中，如果任意一个节点再进行事务提交确认时，由于网络通信延迟导致阻塞，就会影响到所有节点事务的提交，而这个阻塞过程也会影响阻塞用户的请求线程，这对于用户体验以及整体性能的影响较大。下单接口的成功与否，不仅取决于本地节点的数据库操作，而且还依赖第三方系统的结果，这时候分布式事务就保证这些操作要么全部成功，要么全部失败。
2025-12-02 09:02:28
278
原创 4.2.18.Redis：解决Hash冲突
为了 rehash 更高效，Redis 还默认使用了两个全局哈希表，一个用于当前使用，称为主哈希表，如果出现大量的key的冲突导致链表过长的情况下，会导致数据的检索效率变慢，Redis是怎么解决这个问题的呢？组成，哈希桶中的 entry 元素保存了 key 和value 指针，其中 key 指向了实际的键，所谓hash冲突，是指不同的key，计算出来的结果落到了同一个hash桶中。，也就是采用链表的方式来保存同一个hash桶中的多个元素。来保存的所有键值对，这张哈希表，有多个。
2025-12-01 23:24:19
206
原创 4.2.17.Redis：热Key
关于热点key，简单理解，就是访问频率发很高的key，由于访问量较大，热点key有可能会导致服务器资源不足出现宕机的问题。1）在一些高并发的场景中，比如秒杀、热搜等。2）由于资源分配不平衡导致访问热点问题。）使用多级缓存的设计，通过增加本地缓存的方式减少目标节点的访问。）通过对访问频率较高的节点进行扩容，通过负载均衡的方式分散流量。监控工具、或者客户端程序上报的方式来识别热点key。）把热点key进行拆分，实现并发流量的分流。一般情况下，我们可以通过。
2025-12-01 23:19:45
144
原创 4.2.16.Redis：过期策略
是指被动访问某个key的时候，才会判断 key 是否已过期，过期则清除。极端情况可能出现大量的过期key 没有再次被访问，从而不会被清除，占用大量内存。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的 CPU 资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。，是指每个设置过期时间的 key 都需要创建一个定时器，到过期时间就会立即对 key进行清除。但是这两种方案都有点极端，Redis里面还有另外一种折中的方案，就是定期过期。而Redis 中同时使用了。定时过期、惰性过期、定期过期。
2025-12-01 23:12:09
149
约瑟夫问题
2018-06-26
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人