该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/go

https://www.travellings.cn/go.html

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/moments/2026/04/11/perfect-days

2026.04.11

这是一部好好电影，值得看很多次，因为一次感觉有些意犹未尽，好像品出来些什么，但没有“成品”。

首先，这部电影很对我的审美，每一帧都很清新，整洁，有条不紊，其要表达的内涵我也能get到一点，但想要具体用语言描述清楚，也许我还得再看几遍，也许我还得再在生活中历练几段。

所以就我感悟到一些碎片，支离破碎的写一些，希望日后能将其拼凑完整。

1.主角对待生活的态度是我很喜欢，并且心底里隐约向往的，电影里提到的一句“以后是以后，现在是现在”，这句话我认为想表达的就是“活在当下”，也让我联想到《一句顶一万句》里面的“日子是过以后，不是过从前”。

2.主角是享受工作的吗？答案我认为是否。打扫厕所这件事对主角来说其实只是维持生活秩序的手段，从影片中可以看得出来，主角其实是不图钱不图名甚至不图感情（让其自然发生），这很接近我的“本我”，工作是生活中附带的一笔，它像是缝补衣服的麻线，让一些缺口规整起来。

3.那主角在体验或者说追求的是什么？从剧情中他的姐/妹可以看得出来他本来的物质条件是很不错的，住在乡下，独居，做厕所清洁工，这一切必然是他自己的选择。在这些选择背后，我认为主角追求的是“心灵的自由与平静”，他有善良的内心和善于发现美的眼睛，在生活中他凭借这两点就足以获得自己的追求。

无论今天有什么样的情绪波动，发生了什么事，总是按时睡前看书，到点睡觉，准时起床（加班除外哈哈哈），能做到这一点真的难得，主角不是圣人，他会哭，会笑，或者一边哭一边笑；也许他有自己的遗憾或者烦恼，也许他有自己内心的挣扎或者彷徨，但是这一切都不会阻碍：明早我要给我的小树浇水，出门前要买一罐咖啡，路上要听我喜欢的磁带，别忘了和陌生人的井字格游戏，别忘了给大树朋友拍照，别忘了晚上去喝一杯。

最后，生活充满变数，充满意外，但是也充满日升日落，晴天雨天，可能不确定中的一些确定能够让我们更好的面对这一切，加油。

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/thinkings#thinking-12

稳住心态，保证睡眠，坚持锻炼，加油

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/thinkings#thinking-11

要把决定做对，而不是做对的决定

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/thinkings#thinking-10

平常心

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/posts/spring-mvc

我一直感觉SpringMVC的执行过程有些抽象，有些概念有点绕，于是我想着先把很多概念了解清楚，最后再把流程给捋清楚，尝试之后对我的理解还是很有效的，这篇文章经过我的整理输出后由AI润色和修正了格式等内容

1. 什么是 Spring MVC

Spring MVC 是 Spring 体系中的 Web MVC 框架，用来帮助我们基于 Servlet 快速开发 Web 应用。

这里的 MVC 指的是：

• Model：模型数据，或者说业务数据
• View：视图，负责展示页面
• Controller：控制器，负责接收请求、组织调用、返回结果

它的核心思想是把请求接入、参数处理、业务调用、结果响应这些职责拆开，让代码结构更清晰。

需要注意一点：Controller 负责的是请求入口和流程协调，真正的业务逻辑通常应该放在 Service 层，而不是全部堆在 Controller 里。

2. 什么是 Servlet

Servlet 本质上是 Java Web 的一套规范，用来定义服务器如何接收 HTTP 请求、如何处理请求、如何返回 HTTP 响应。

像 Tomcat、Jetty 这样的 Web 容器会实现这套规范，并负责：

• 加载 Servlet
• 管理 Servlet 生命周期
• 在请求到来时调用对应的 Servlet

可以把它理解成：Servlet 提供了 Java Web 最基础的请求处理能力，而 Spring MVC 是构建在这套能力之上的更高层封装。

3. Spring MVC 和 Servlet 是什么关系

Spring MVC 是建立在 Servlet 规范之上的。

它的核心入口是 DispatcherServlet。DispatcherServlet 本身就是一个 Servlet，所以它可以像普通 Servlet 一样被 Web 容器加载和调用。

也就是说：

• Web 容器负责把请求交给 DispatcherServlet
• DispatcherServlet 负责在 Spring MVC 内部完成后续流程

后续这些流程包括：

• 路由分发
• 查找处理器
• 参数绑定
• 调用控制器方法
• 处理返回值
• 视图解析或响应体输出

4. Spring MVC 的几个核心组件

4.1 DispatcherServlet 是什么

DispatcherServlet 是 Spring MVC 的核心调度器，也是整个请求处理流程的统一入口。

浏览器发来的请求，通常会先到它这里，再由它决定后续交给谁处理。

它的职责可以概括为：

• 接收请求
• 分发请求
• 协调各个组件一起工作
• 最终生成响应

4.2 HandlerMapping 是什么

HandlerMapping 可以理解成“请求路径到处理器的映射表”。

当请求到来时，它会根据请求信息去找到对应的处理器。匹配条件通常包括：

• URL
• HTTP 请求方法
• 其他请求条件

在注解驱动开发里，Spring 启动时会解析诸如 @RequestMapping、@GetMapping、@PostMapping 这类映射信息，并建立对应关系。

4.3 Controller 和处理器是什么关系

在日常开发里，我们会写很多 @Controller 或 @RestController 类。

对于注解驱动的 Spring MVC 来说，真正执行请求处理逻辑的，通常是 Controller 中某一个具体的方法。这个方法通常就可以理解为当前请求对应的处理器。

也就是说：

• Controller 是处理请求的载体
• 具体的处理器，通常是其中某个带映射注解的方法

所以 HandlerMapping 最终定位到的，通常不是整个类，而是类中的某个方法。

4.4 HandlerAdapter 是什么

HandlerAdapter 可以理解成“处理器执行适配器”。

DispatcherServlet 找到处理器之后，并不是自己直接用反射去调用，而是交给合适的 HandlerAdapter 来执行。

它主要负责：

• 参数解析与绑定
• 类型转换
• 调用目标方法
• 处理方法返回值

在基于注解的 Spring MVC 中，最常见的是 RequestMappingHandlerAdapter。

4.5 ViewResolver 是什么

ViewResolver 是视图解析器。

当控制器返回的是一个“视图名”时，Spring MVC 会通过 ViewResolver 把这个名字解析成真正的视图对象，比如 JSP 或 Thymeleaf 模板。

4.6 HttpMessageConverter 是什么

HttpMessageConverter 是消息转换器。

当前后端分离接口返回的是对象、JSON、XML 等响应体数据时，Spring MVC 会通过它把 Java 对象转换成 HTTP 响应内容。

最常见的场景就是把 Java 对象转换为 JSON。

5. Controller 执行完之后，会返回什么

这部分要分成两种场景来看。

5.1 传统服务端页面渲染

如果是传统 Web 项目，控制器方法通常可能返回：

• 视图名，比如 "userList"
• ModelAndView

这时 Spring MVC 的处理思路是：

1. 控制器方法执行完成
2. 得到视图相关结果
3. 交给 ViewResolver 解析视图
4. 由视图技术渲染页面
5. 最终把 HTML 返回给浏览器

5.2 前后端分离接口返回

如果是前后端分离项目，控制器方法通常返回：

• 一个普通对象
• ResponseEntity
• 标注了 @ResponseBody 的返回结果

如果类上使用了 @RestController，本质上也等价于默认带有 @ResponseBody 语义。

这时流程就不是“返回视图”，而是“直接返回数据”。

更准确地说，这类返回值会由 Spring MVC 的返回值处理机制配合 HttpMessageConverter 写入响应体，而不是再走视图解析。

所以这里不要简单理解成“HandlerAdapter 返回了 null”，更准确的理解应该是：

• 控制器方法返回的是数据
• Spring MVC 把这些数据写进 HTTP 响应体
• DispatcherServlet 不再进行视图渲染

6. 一次请求在 Spring MVC 中是怎么流转的

把前面的内容串起来，一次典型请求大致会经过下面这些步骤。

1. 浏览器发起 HTTP 请求。
2. Web 容器接收到请求后，把请求交给 DispatcherServlet。
3. DispatcherServlet 调用 HandlerMapping 查找当前请求对应的处理器。
4. 找到处理器后，DispatcherServlet 再交给合适的 HandlerAdapter 去执行。
5. HandlerAdapter 完成参数绑定、类型转换，然后调用目标控制器方法。
6. 控制器方法执行业务流程，并返回结果。
7. 如果返回的是视图名或 ModelAndView，则进入视图解析和页面渲染流程。
8. 如果返回的是对象或 ResponseEntity，则通过 HttpMessageConverter 直接写入响应体。
9. 最终响应返回给客户端。

为了先把主线讲清楚，这里暂时没有展开拦截器、异常处理器、文件上传解析器这些扩展机制，但它们本质上也都是围绕这条主流程工作的。

7. 几个容易混淆的点

7.1 Controller 不等于业务逻辑

Controller 的主要职责是接收请求、做参数承接、组织调用和返回结果。

真正的业务逻辑通常应该放在 Service 层。这样分层才清晰，也更容易维护。

7.2 DispatcherServlet 不是“一个类包办一切”

虽然 DispatcherServlet 是统一入口，但它并不是自己完成所有工作。

它更像一个总调度器，会把不同阶段的工作分别交给：

• HandlerMapping
• HandlerAdapter
• ViewResolver
• HttpMessageConverter

7.3 前后端分离场景下，通常不会再走视图解析

如果控制器返回的是 JSON 数据，那么重点就不再是 ViewResolver，而是返回值处理机制和 HttpMessageConverter。

也就是说，前后端分离项目和传统服务端页面渲染项目，后半段流程是不一样的。

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/thinkings#thinking-9

AI时代，如何放大凸显自己的长处，变得更加重要

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/thinkings#thinking-8

有时候感觉有那种摇滚精神，反叛精神是十分十分可贵的，那种燥的气息仿佛是生命力的外显，怀念，昔日我曾风华正茂，如今我正苍老。

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/thinkings#thinking-6

AI 时代说个小暴论，越是在这种鼓吹人人都可以创造的时代，越要静下心来做一些长期主义的事情。LLM 是一把锋利的刀，你买了这把刀，别人也可以买，这并不能带来什么本质性的差距。所以还是要沉下来，做一些长期主义、有积累的事情。

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/thinkings#thinking-5

死亡是每个人必修的课题

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/posts/elasticsearch-guide

1.基础学习

一、 什么是 Elasticsearch？

Elasticsearch（简称 ES） 是一个基于 Lucene 的开源、分布式、RESTful 搜索引擎。它不仅是一个数据库，更是为了解决传统关系型数据库（如 MySQL）在全文检索、海量数据搜索和实时分析方面的不足而设计的。

为什么不用 MySQL 的 LIKE 查询？

• 性能差：LIKE '%关键词%' 无法利用索引，数据量大时查询极慢。
• 结果不精准：无法根据相关性进行排序（比如“最匹配”的内容排在前面）。
• 缺乏分词能力：难以处理复杂的自然语言搜索。

二、 核心概念与实战操作

1. 核心术语对照

2. 基础操作（DSL 语法）

ES 使用 JSON 格式的 DSL（领域特定语言）进行交互，建议配合可视化工具 Kibana 使用。

• 创建索引：需指定字段类型，也就是映射mapping。text 用于全文检索（会分词），keyword 用于精确匹配（不分词）。

• 插入数据：直接发送 POST 请求提交 JSON 文档。

• 搜索数据：使用 match 进行全文搜索，ES 会自动分词并计算匹配度。

3. Java 客户端开发

在生产中，通常使用 Spring Data Elasticsearch。它允许开发者通过定义接口（继承 ElasticsearchRepository）并使用注解（如 @Document）来操作 ES，就像使用 MyBatis-Plus 一样简单。后文会有代码示例

三、 ES 为什么这么快？（核心特性）

1. 倒排索引 (Inverted Index)

这是 ES 的灵魂。它不直接存整行数据，而是记录单词 -> 文档 ID 列表的映射。搜索时，系统先对搜索词进行分词，然后通过倒排索引直接定位包含这些词的文档，无需全表扫描。

2. 分词器 (Analyzer)

• 标准分词器：对中文支持较差（按字拆分）。
• IK 分词器：中文搜索必备，提供 ik_smart（智能切分）和 ik_max_word（最细粒度切分）模式。

3. 相关性评分

ES 默认采用 BM25 算法，通过词频（TF）、逆文档频率（IDF）和文档长度来计算分数（_score），确保用户最想要的结果排在最前面。

四、 生产环境的挑战与方案

1. 数据同步

由于 ES 和 MySQL 是独立系统，需要解决数据一致性问题：

• 定时任务：适合实时性要求不高的场景。
• 双写：代码层面同时写入两端，但需处理写入失败。
• Canal 监听：实时监听 MySQL 的 Binlog 变更并同步，延迟低。

2. 高可用与扩展

• 集群部署：通过多节点（主节点、数据节点）保证服务不宕机。
• 分片 (Shard)：将大索引拆分存放在不同节点，提升存储上限和并发能力。
• 副本 (Replica)：分片的备份，防止节点损坏导致数据丢失。

3. 常见进阶问题

• 深度分页：ES 默认限制查询前 10,000 条。深层次翻页建议使用 search_after。
• ELK 生态：Elasticsearch (存储) + Logstash (收集) + Kibana (展示)，是目前主流的日志分析方案。

建议：学习 ES 最好的方式是动手实践，先在本地搭建一个单机版环境，尝试通过 Kibana 练习各种 DSL 查询。

2.代码实现

我们通常会选择在 Spring Boot 项目中集成 Spring Data Elasticsearch。这是目前 Java 后端最主流、也是最高效的开发方式。

1. 环境准备与配置

首先，在项目的 pom.xml 中引入依赖：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-elasticsearch</artifactId>
</dependency>

在 application.yml 中配置 ES 服务器地址：

spring:
  elasticsearch:
    uris: http://localhost:9200

2. 定义实体类（Mapping 映射）

通过注解将 Java 对象映射为 ES 的索引结构。text 类型用于搜索，keyword 用于精确过滤。

@Data
@Document(indexName = "article") // 指定索引名称
public class Article {
    @Id
    private Long id;

    // type = Text 表示支持全文检索，analyzer 指定分词器
    @Field(type = FieldType.Text, analyzer = "ik_max_word", searchAnalyzer = "ik_smart")
    private String title;

    @Field(type = FieldType.Text, analyzer = "ik_max_word")
    private String content;

    // type = Keyword 表示不分词，直接匹配
    @Field(type = FieldType.Keyword)
    private String category;

    @Field(type = FieldType.Date, format = DateFormat.basic_date_time)
    private LocalDateTime createTime;
}

3. 编写 Repository 接口

这是 Spring Data 的精髓，你只需要定义方法名，框架会自动帮你生成 DSL 查询语句。

public interface ArticleRepository extends ElasticsearchRepository<Article, Long> {
    
    // 自动解析：根据标题全文检索
    List<Article> findByTitle(String title);
    
    // 自动解析：根据分类精确匹配
    List<Article> findByCategory(String category);
    
    // 复合查询：标题匹配且分类一致
    List<Article> findByTitleAndCategory(String title, String category);
}

4. 高级搜索：使用 ElasticsearchTemplate

如果 Repository 的方法名无法满足复杂的业务逻辑（如高亮、聚合、复杂的布尔过滤），可以使用 ElasticsearchTemplate。

示例：带高亮和过滤的复合搜索

@Autowired
private ElasticsearchRestTemplate elasticsearchRestTemplate;

public void complexSearch(String keyword) {
    // 1. 构建查询条件（类似 SQL 的 WHERE）
    NativeSearchQuery searchQuery = new NativeSearchQueryBuilder()
            .withQuery(QueryBuilders.boolQuery()
                    .must(QueryBuilders.matchQuery("title", keyword)) // 必须匹配标题
                    .should(QueryBuilders.matchQuery("content", keyword))) // 内容匹配可加分
            .withHighlightFields(new HighlightBuilder.Field("title")) // 设置高亮字段
            .withPageable(PageRequest.of(0, 10)) // 分页
            .build();

    // 2. 执行搜索
    SearchHits<Article> searchHits = elasticsearchRestTemplate.search(searchQuery, Article.class);

    // 3. 处理高亮结果
    searchHits.getSearchHits().forEach(hit -> {
        Article article = hit.getContent();
        List<String> highlightTitle = hit.getHighlightField("title");
        if (!highlightTitle.isEmpty()) {
            article.setTitle(highlightTitle.get(0)); // 替换为带 <em> 标签的内容
        }
        System.out.println("搜索结果: " + article);
    });
}

5. 核心逻辑总结

在实际开发中，代码流程通常是：

1. MySQL 写入：文章发布成功。
2. 触发同步：通过 articleRepository.save(article) 同步到 ES。
3. 用户搜索：调用自定义的 search 方法，获取经过分词和评分排序后的结果。

注意：
在本地调试时，请确保已经安装了 IK 分词器 插件，否则代码中的 analyzer = "ik_max_word" 会导致 ES 报错。

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/message

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/about

一个正在成长的大三学生

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/thinkings#thinking-4

如果思考的页面可以插入图片就好了

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/posts/mysql-mvcc

首先，什么是 MVCC

MVCC 的中文是多版本并发控制，它是 InnoDB 在处理普通 SELECT 这类快照读时实现一致性读的核心机制，主要服务于读已提交（RC） 和 可重复读（RR） 这两个隔离级别。

并发事务里常见的冲突主要有两类：

• 读写冲突：事务 A 在读一行数据，事务 B 同时修改这行数据
• 写写冲突：两个事务同时修改同一行数据

写写冲突仍然需要依赖锁来保证串行化；MVCC 主要解决的是读写并发时，如何让读操作尽量不阻塞写操作。

需要注意，MVCC 主要用于快照读，不适用于所有读操作。像 SELECT ... FOR UPDATE、SELECT ... FOR SHARE、UPDATE、DELETE 这类当前读，仍然要结合锁来工作。

MVCC 的三个核心点

1. 隐藏字段

   • trx_id：最后一次修改该记录版本的事务 ID
   • roll_pointer：指向该记录上一个历史版本的 undo log 指针

2. undo log 版本链

   一行记录每次被修改时，旧版本不会立刻消失，而是被写入 undo log，再通过 roll_pointer 串起来，形成一条从新到旧的版本链。

3. Read View

   Read View 可以理解为事务做快照读时拿到的一份“可见性规则”。事务会基于这份规则，从版本链上判断哪个版本对自己可见。

Read View 中几个关键字段

• m_ids：创建 Read View 时，系统中活跃的读写事务 ID 集合
• min_trx_id：m_ids 中最小的事务 ID
• max_trx_id：创建 Read View 时，系统将要分配给下一个事务的 ID
• creator_trx_id：创建这个 Read View 的事务 ID

这里要特别注意：

• 记录上的 trx_id，表示“这个版本是由哪个事务生成的”
• creator_trx_id，表示“当前正在读取数据的事务是谁”

这两个不是同一个概念。

可见性判断算法

当事务进行快照读时，会从版本链的最新版本开始判断可见性。这里参与判断的 trx_id，指的是“当前正在检查的那个记录版本的事务 ID”，不是当前读请求所属事务的 ID。

判断规则可以概括为：

1. 如果版本的 trx_id == creator_trx_id，该版本可见

   原因：这是当前事务自己生成的版本，当前事务当然可以看到。

2. 如果版本的 trx_id < min_trx_id，该版本可见

   原因：说明生成这个版本的事务，在 Read View 创建前就已经提交了。

3. 如果版本的 trx_id >= max_trx_id，该版本不可见

   原因：说明这个版本对应的事务，是在 Read View 创建之后才开始的。

4. 如果 min_trx_id <= trx_id < max_trx_id

   • trx_id 在 m_ids 中：不可见，说明该事务在创建 Read View 时仍然活跃，尚未提交
   • trx_id 不在 m_ids 中：可见，说明该事务在创建 Read View 前已经提交

如果某个版本不可见，就顺着版本链继续找更老的版本，直到找到第一个可见版本为止。

RC 和 RR 的本质区别

1. RC（读已提交）

   每次执行快照读时，都会创建新的 Read View，所以同一个事务里两次普通 SELECT，可能看到不同的已提交结果，这就是不可重复读产生的原因。

2. RR（可重复读）

   默认情况下，事务中的第一次快照读会创建 Read View，后续快照读复用同一个 Read View，因此同一个事务里的多次普通 SELECT 通常会看到同一份快照。

这里的表述要稍微严谨一点：

• RR 下“保持一致”的是普通快照读看到的历史快照
• 如果当前事务自己更新了数据，那么它仍然可以看到自己更新后的结果
• 如果执行的是当前读，也不走这套快照可见性逻辑

另外，InnoDB 中 RR 并不是“事务一启动就一定创建 Read View”。通常是第一次执行快照读时才创建；如果显式使用了 START TRANSACTION WITH CONSISTENT SNAPSHOT，则会在事务开始时创建一致性视图。

举例说明版本选择过程

假设有三个事务并发执行：

• 事务 101：较早启动，修改了某行数据，但还没有提交
• 事务 102：稍后修改了同一行数据，并且已经提交
• 事务 103：当前事务，正在执行一次快照读

假设这行数据原本的最后已提交版本是 trx_id=100。

之后：

• 事务 102 修改该行，生成一个新版本，trx_id=102
• 事务 101 又基于更新后的数据生成更“新”的版本，trx_id=101，但它尚未提交

于是版本链可以表示为：

(101) -> (102) -> (100)

其中 (101) 是当前记录上最新的版本。

现在事务 103 在执行第一次快照读时创建 Read View。此时：

• 活跃事务只有 101，所以 m_ids = {101}
• min_trx_id = 101
• max_trx_id = 104，表示下一个将被分配的事务 ID 是 104
• creator_trx_id = 103

事务 103 读取这行数据时，会这样判断：

1. 先看最新版本 (101)

   trx_id=101 落在 min_trx_id <= trx_id < max_trx_id 区间内，并且 101 在 m_ids 中，说明该版本对应的事务在创建 Read View 时仍然活跃，因此不可见。

2. 顺着版本链看下一个版本 (102)

   trx_id=102 也还是落在min_trx_id <= trx_id < max_trx_id 区间内，但 102 不在 m_ids 中，说明它在 Read View 创建前已经提交，因此这个版本可见。

3. 返回版本 (102) 的数据

所以，事务 103 读到的是事务 102 提交后的值，而不是事务 101 尚未提交的值。

如果隔离级别是 RC，那么事务 103 每次执行快照读都会重新创建 Read View：

• 只要事务 101 还没提交，新的 Read View 中仍然会把 101 视为活跃事务，因此看不到版本 101
• 一旦事务 101 提交，下一次快照读重新生成 Read View 时，101 不再出现在活跃事务列表中，此时就可能读到版本 101 ::: link-card href="https://www.bilibili.com/video/BV1Yc411N7tK" title="10分钟带你深刻理解MySQL中的MVCC机制" desc="参考引用" newtab="true"

::: ::: link-card href="https://www.bilibili.com/video/BV1Kr4y1i7ru" title="MySQL数据库入门到精通" desc="参考引用" newtab="true"

:::

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/thinkings#thinking-2

Life, the Universe and Everything.

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/thinkings#thinking-1

hello world

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/posts/cookie-session-token

2025-11-10

前言

无状态的HTTP协议

很久很久之前， Web基本都是文档的浏览而已。既然是浏览， 作为服务器， 不需要记录在某一段时间里都浏览了什么文档， 每次请求都是一个新的HTTP协议，就是请求加响应。不用记录谁刚刚发了HTTP请求， 每次请求都是全新的。

如何管理会话

随着交互式Web应用的兴起， 像在线购物网站，需要登录的网站等，马上面临一个问题，就是要管理回话，记住那些人登录过系统，哪些人往自己的购物车中放商品，也就是说我必须把每个人区分开。

本文主要讲解cookie，session, token 这三种是如何管理会话的；

cookie

cookie 是一个非常具体的东西，指的就是浏览器里面能永久存储的一种数据。跟服务器没啥关系，仅仅是浏览器实现的一种数据存储功能。

cookie由服务器生成，发送给浏览器，浏览器把cookie以KV形式存储到某个目录下的文本文件中，下一次请求同一网站时会把该cookie发送给服务器。由于cookie是存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间。所以每个域的cookie数量是有限制的。

如何设置

客户端设置

 document.cookie = "name=xiaoming; age=12 "

• 客户端可以设置cookie的一下选项: expires, domain, path, secure(只有在https协议的网页中, 客户端设置secure类型cookie才能生效), 但无法设置httpOnly选项

设置cookie => cookie被自动添加到request header中 => 服务端接收到cookie

服务端设置

不管你是请求一个资源文件(如html/js/css/图片), 还是发送一个ajax请求, 服务端都会返回response.而response header中有一项叫set-cookie, 是服务端专门用来设置cookie的;

• 一个set-cookie只能设置一个cookie, 当你想设置多个, 需要添加同样多的set-cookie
• 服务端可以设置cookie的所有选项: expires, domain, path, secure, HttpOnly

Cookie，SessionStorage，LocalStorage

HTML5提供了两种本地存储的方式 sessionStorage 和 localStorage；

session

什么是session

session从字面上讲，就是会话。这个就类似你和一个人交谈，你怎么知道当时和你交谈的是张三而不是李四呢？对方肯定有某种特征（长相等）表明他是张三； session也是类似的道理，服务器要知道当前请求发给自己的是谁。为了做这种区分，服务器就是要给每个客户端分配不同的"身份标识"，然后客户端每次向服务器发请求的时候，都带上这个”身份标识“，服务器就知道这个请求来自与谁了。 至于客户端怎么保存这个”身份标识“，可以有很多方式，对于浏览器客户端，大家都采用cookie的方式。

过程(服务端session + 客户端 sessionId)

• 1.用户向服务器发送用户名和密码
• 2.服务器验证通过后,在当前对话(session)里面保存相关数据,比如用户角色, 登陆时间等;
• 3.服务器向用户返回一个session_id, 写入用户的cookie
• 4.用户随后的每一次请求, 都会通过cookie, 将session_id传回服务器
• 5.服务端收到 session_id, 找到前期保存的数据, 由此得知用户的身份

存在的问题

扩展性不好

单机当然没问题， 如果是服务器集群， 或者是跨域的服务导向架构， 这就要求session数据共享，每台服务器都能够读取session。

举例来说， A网站和B网站是同一家公司的关联服务。现在要求，用户只要在其中一个网站登录，再访问另一个网站就会自动登录，请问怎么实现？这个问题就是如何实现单点登录的问题

1. Nginx ip_hash 策略，服务端使用 Nginx 代理，每个请求按访问 IP 的 hash 分配，这样来自同一 IP 固定访问一个后台服务器，避免了在服务器 A 创建 Session，第二次分发到服务器 B 的现象。

2. Session复制：任何一个服务器上的 Session 发生改变（增删改），该节点会把这个 Session 的所有内容序列化，然后广播给所有其它节点。

   

3. 共享Session：将Session Id 集中存储到一个地方，所有的机器都来访问这个地方的数据。这种方案的优点是架构清晰，缺点是工程量比较大。另外，持久层万一挂了，就会单点失败；

   

另一种方案是服务器索性不保存session数据了，所有数据就保存在客户端，每次请求都发回服务器。这种方案就是接下来要介绍的基于Token的验证;

Token

过程

1. 用户通过用户名和密码发送请求
2. 程序验证
3. 程序返回一个签名的token给客户端
4. 客户端储存token, 并且每次用每次发送请求
5. 服务端验证Token并返回数据

这个方式的技术其实很早就已经有很多实现了，而且还有现成的标准可用，这个标准就是JWT;

JWT(JSON Web Token)

数据结构

实际的JWT大概就像下面这样：

JSON Web Tokens由dot（.）分隔的三个部分组成，它们是：

• Header（头部）
• Payload（负载）
• Signature（签名）

因此，JWT通常如下展示：

xxxxx.yyyyy.zzzz

Header（头部）

Header 是一个 JSON 对象

 {
  "alg": "HS256", // 表示签名的算法，默认是 HMAC SHA256（写成 HS256）
  "typ": "JWT"  // 表示Token的类型，JWT 令牌统一写为JWT
}

Payload（负载）

Payload 部分也是一个 JSON 对象，用来存放实际需要传递的数据

 {
  // 7个官方字段
  "iss": "a.com", // issuer：签发人
  "exp": "1d", // expiration time： 过期时间
  "sub": "test", // subject: 主题
  "aud": "xxx", // audience： 受众
  "nbf": "xxx", // Not Before：生效时间
  "iat": "xxx", // Issued At： 签发时间
  "jti": "1111", // JWT ID：编号
  // 可以定义私有字段
  "name": "John Doe",
  "admin": true
}

JWT 默认是不加密的，任何人都可以读到，所以不要把秘密信息放在这个部分。

Signature（签名）

Signature 是对前两部分的签名，防止数据被篡改。

首先，需要指定一个密钥(secret)。这个密钥只有服务器才知道，不能泄露给用户。然后，使用Header里面指定的签名算法（默认是 HMAC SHA256），按照下面的公式产生签名。

 HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

算出签名后，把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用"点"（.）分隔，就可以返回给用户。

 JWT = Base64(Header) + "." + Base64(Payload) + "." + $Signature

如何保证安全？

• 发送JWT要使用HTTPS；不使用HTTPS发送的时候，JWT里不要写入秘密数据
• JWT的payload中要设置expire时间

使用方式

客户端收到服务器返回的 JWT，可以储存在 Cookie 里面，也可以储存在 localStorage。此后，客户端每次与服务端通信，都要带上这个JWT。你可以把它放在Cookie里面自动发送，但是这样不能跨域，所以更好的做法是放在HTTP请求的头信息 Authorization 字段里面。

Authorization: Bearer <token></token>

另一种做法是， 跨域的时候， JWT就放在POST请求的数据体里。

JWT 的作用

JWT最开始的初衷是为了实现授权和身份认证作用的，可以实现无状态，分布式的Web应用授权。大致实现的流程如下

1. 客户端需要携带用户名/密码等可证明身份的的内容去授权服务器获取JWT信息；
2. 每次服务都携带该Token内容与Web服务器进行交互，由业务服务器来验证Token是否是授权发放的有效Token，来验证当前业务是否请求合法。

这里需要注意：不是每次请求都要申请一次Token，这是需要注意，如果不是对于安全性要求的情况，不建议每次都申请，因为会增加业务耗时；比如只在登陆时申请，然后使用JWT的过期时间或其他手段来保证JWT的有效性；

Acesss Token，Refresh Token

JWT最大的优势是服务器不再需要存储Session，使得服务器认证鉴权业务可以方便扩展。这也是JWT最大的缺点由于服务器不需要存储Session状态，因此使用过程中无法废弃某个Token，或者更改Token的权限。也就是说一旦JWT签发了，到期之前就会始终有效。 我们可以基于上面提到的问题做一些改进。

前面讲的Token，都是Acesss Token，也就是访问资源接口时所需要的Token，还有另外一种Token，Refresh Token。一般情况下，Refresh Token的有效期会比较长。而Access Token的有效期比较短，当Acesss Token由于过期而失效时，使用Refresh Token就可以获取到新的Token，如果Refresh Token也失效了，用户就只能重新登录了。Refresh Token及过期时间是存储在服务器的数据库中，只有在申请新的Acesss Token时才会验证，不会对业务接口响应时间造成影响，也不需要向Session一样一直保持在内存中以应对大量的请求。

一个简单的JWT使用示例

JWT工具类

package com.example.jwtdemo.util;

import io.jsonwebtoken.Claims;
import io.jsonwebtoken.Jwts;
import io.jsonwebtoken.SignatureAlgorithm;
import org.springframework.stereotype.Component;

import java.util.Date;
import java.util.HashMap;
import java.util.Map;

@Component
public class JwtUtil {
    
    private static final String SECRET = "your_secret_string";
    private static final long EXPIRATION = 60 * 1000; // 1分钟
    
    /**
     * 生成Token
     */
    public String generateToken(String userName) {
        Map<String, Object> claims = new HashMap<>();
        claims.put("iss", userName);
        
        return Jwts.builder()
                .setClaims(claims)
                .setExpiration(new Date(System.currentTimeMillis() + EXPIRATION))
                .signWith(SignatureAlgorithm.HS256, SECRET)
                .compact();
    }
    
    /**
     * 从Token中获取用户名
     */
    public String getUserNameFromToken(String token) {
        Claims claims = getClaimsFromToken(token);
        return claims.get("iss", String.class);
    }
    
    /**
     * 验证Token是否过期
     */
    public boolean isTokenExpired(String token) {
        Claims claims = getClaimsFromToken(token);
        Date expiration = claims.getExpiration();
        return expiration.before(new Date());
    }
    
    /**
     * 解析Token
     */
    private Claims getClaimsFromToken(String token) {
        return Jwts.parser()
                .setSigningKey(SECRET)
                .parseClaimsJws(token)
                .getBody();
    }
}

请求/响应DTO类

package com.example.jwtdemo.dto;

import lombok.Data;

@Data
public class LoginRequest {
    private String userName;
    private String password;
}

package com.example.jwtdemo.dto;

import lombok.Data;

@Data
public class ResponseResult<T> {
    private String errorMsg;
    private String msg;
    private T data;
    
    public static <T> ResponseResult<T> success(T data, String msg) {
        ResponseResult<T> result = new ResponseResult<>();
        result.setData(data);
        result.setMsg(msg);
        result.setErrorMsg("");
        return result;
    }
    
    public static <T> ResponseResult<T> error(String errorMsg) {
        ResponseResult<T> result = new ResponseResult<>();
        result.setErrorMsg(errorMsg);
        result.setMsg("");
        result.setData(null);
        return result;
    }
}

package com.example.jwtdemo.dto;

import lombok.Data;

@Data
public class UserInfo {
    private String username;
}

控制器类 (AuthController.java)

package com.example.jwtdemo.controller;

import com.example.jwtdemo.dto.LoginRequest;
import com.example.jwtdemo.dto.ResponseResult;
import com.example.jwtdemo.dto.UserInfo;
import com.example.jwtdemo.util.JwtUtil;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.web.bind.annotation.*;

@RestController
@CrossOrigin(origins = "*") // 允许跨域
public class AuthController {
    
    @Autowired
    private JwtUtil jwtUtil;
    
    @PostMapping("/login")
    public ResponseResult<String> login(@RequestBody LoginRequest request) {
        String userName = request.getUserName();
        String password = request.getPassword();
        
        // 简单的验证逻辑，实际项目中需要查询数据库
        if (userName == null || userName.trim().isEmpty()) {
            return ResponseResult.error("用户名不能为空");
        }
        
        String token = jwtUtil.generateToken(userName);
        return ResponseResult.success(token, "登陆成功");
    }
    
    @GetMapping("/getUsername")
    public ResponseResult<UserInfo> getUsername(@RequestHeader("Authorization") String authHeader) {
        try {
            // 提取Bearer Token
            String token = authHeader.substring(7);
            
            if (jwtUtil.isTokenExpired(token)) {
                return ResponseResult.error("Token已过期，请重新登录");
            }
            
            String userName = jwtUtil.getUserNameFromToken(token);
            UserInfo userInfo = new UserInfo();
            userInfo.setUsername(userName);
            
            return ResponseResult.success(userInfo, "获取用户名成功");
        } catch (Exception e) {
            return ResponseResult.error("Token验证失败");
        }
    }
}

主应用类 (JwtDemoApplication.java)

package com.example.jwtdemo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class JwtDemoApplication {
    public static void main(String[] args) {
        SpringApplication.run(JwtDemoApplication.class, args);
        System.out.println("启动成功，端口：3200");
    }
}

Maven依赖

<dependencies>
        <!-- Spring Boot Web -->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
            <version>2.7.0</version>
        </dependency>
        
        <!-- JWT -->
        <dependency>
            <groupId>io.jsonwebtoken</groupId>
            <artifactId>jjwt</artifactId>
            <version>0.9.1</version>
        </dependency>
        
        <!-- Lombok -->
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>1.18.24</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>

配置文件 (application.properties)

server.port=3200
server.servlet.context-path=/
# 日志配置
logging.level.com.example.jwtdemo=DEBUG

前端HTML页面 (resources/static/index.html)

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>JWT-demo</title>
    <style>
        .login-wrap {
            height: 100px;
            width: 200px;
            border: 1px solid #ccc;
            padding: 20px;
            margin-bottom: 20px;
        }
        input {
            margin: 5px 0;
            padding: 5px;
            width: 180px;
        }
        button {
            padding: 5px 10px;
            margin: 5px 0;
        }
    </style>
</head>
<body>
    <div class="login-wrap">
        <input type="text" placeholder="用户名" class="userName">
        <br>
        <input type="password" placeholder="密码" class="password">
        <br>
        <br>
        <button class="btn">登陆</button>
    </div>
    
    <button class="btn1">获取用户名</button>
    <p class="username"></p>

    <script>
        var btn = document.querySelector('.btn');
        
        btn.onclick = function () {
            var userName = document.querySelector('.userName').value;
            var password = document.querySelector('.password').value;
            
            fetch('http://localhost:3200/login', {
                method: 'POST',
                headers: {
                    'Content-Type': 'application/json',
                },
                body: JSON.stringify({
                    userName: userName,
                    password: password
                })
            })
            .then(function (response) {
                return response.json();
            })
            .then(function (res) {
                // 获取到Token，将Token存储在localStorage
                if (res.errorMsg) {
                    alert('登录失败: ' + res.errorMsg);
                    return;
                }
                
                localStorage.setItem('token', res.data);
                localStorage.setItem('token_exp', new Date().getTime());
                alert(res.msg);
            })
            .catch(err => {
                alert('本地测试错误: ' + err.message);
                console.error('本地测试错误', err);
            });
        }
        
        var btn1 = document.querySelector('.btn1');
        btn1.onclick = function () {
            var usernameElement = document.querySelector('.username');
            const token = localStorage.getItem('token');
            
            if (!token) {
                alert('请先登录');
                return;
            }
            
            fetch('http://localhost:3200/getUsername', {
                headers: {
                    'Authorization': 'Bearer ' + token
                }
            })
            .then(function (response) {
                return response.json();
            })
            .then(function (res) {
                console.log('返回用户信息结果', res);
                if (res.errorMsg) {
                    alert(res.errorMsg);
                    usernameElement.innerHTML = '';
                } else {
                    usernameElement.innerHTML = `姓名：${res.data.username}`;
                }
            })
            .catch(err => {
                console.error(err);
                alert('请求失败: ' + err.message);
            });
        }
    </script>
</body>
</html>

运行说明

1. 启动应用：运行 JwtDemoApplication.java的 main 方法

2. 访问页面：打开浏览器访问 http://localhost:3200/index.html

3. 测试流程：

   • 输入用户名密码点击登录

   • 登录成功后点击"获取用户名"按钮

   • 等待1分钟后Token过期，再次点击"获取用户名"会显示过期提示

运行代码

区别

Cookie和Session的区别

1. 存储位置不同： cookie数据存放在客户的浏览器上，session数据放在服务器上
2. 隐私策略不同：cookie不是很安全， 别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session
3. session会在一定时间内保存在服务器上。当访问增多，就会比较占用你服务器的性能，考虑到减轻服务器性能方面，应当使用cookie
4. 存储大小不同： 单个cookie保存的数据不能超过4k, 很多浏览器都限制一个站点最多保存20个cookie

一般建议： 将登陆信息等重要信息存放为session, 其他信息如果需要保留，可以放在cookie中

Token和Session的区别

Session是一种HTTP储存机制， 为无状态的HTTP提供持久机制; Token就是令牌， 比如你授权(登录)一个程序时，它就是个依据，判断你是否已经授权该软件；

Session和Token并不矛盾，作为身份认证Token安全性比Session好，因为每一个请求都有签名还能防止监听以及重放攻击，而Session就必须依赖链路层来保障通讯安全了。如上所说，如果你需要实现有状态的回话，仍然可以增加Session来在服务端保存一些状态。

总结

cookie，session，Token没有绝对的好与坏之分，只要还是要结合实际的业务场景和需求来决定采用哪种方式来管理回话，当然也可以三种都用。

参考引用

• 详解 Cookie，Session，Token
• 彻底理解cookie，session，token
• Cookie、Session、Token那点事儿（原创）
• 3种web会话管理的方式
• 你真的了解 Cookie 和 Session 吗
• 不要用JWT替代session管理（上）：全面了解Token,JWT,OAuth,SAML,SSO
• Session 、Cookie和Token三者的关系和区别

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/posts/redission-lock

2025-06-01

1 分布式锁-redission功能介绍

基于setnx实现的分布式锁存在下面的问题：

重入问题：重入问题是指 获得锁的线程可以再次进入到相同的锁的代码块中，可重入锁的意义在于防止死锁，比如HashTable这样的代码中，他的方法都是使用synchronized修饰的，假如他在一个方法内，调用另一个方法，那么此时如果是不可重入的，不就死锁了吗？所以可重入锁他的主要意义是防止死锁，我们的synchronized和Lock锁都是可重入的。

不可重试：是指目前的分布式只能尝试一次，我们认为合理的情况是：当线程在获得锁失败后，他应该能再次尝试获得锁。

超时释放：我们在加锁时增加了过期时间，这样的我们可以防止死锁，但是如果卡顿的时间超长，虽然我们采用了lua表达式防止删锁的时候，误删别人的锁，但是毕竟没有锁住，有安全隐患

主从一致性： 如果Redis提供了主从集群，当我们向集群写数据时，主机需要异步的将数据同步给从机，而万一在同步过去之前，主机宕机了，就会出现死锁问题。

那么什么是Redission呢

Redisson是一个在Redis的基础上实现的Java驻内存数据网格（In-Memory Data Grid）。它不仅提供了一系列的分布式的Java常用对象，还提供了许多分布式服务，其中就包含了各种分布式锁的实现。

Redission提供了分布式锁的多种多样的功能

2 分布式锁-Redission快速入门

引入依赖：

<dependency>
	<groupId>org.redisson</groupId>
	<artifactId>redisson</artifactId>
	<version>3.13.6</version>
</dependency>

配置Redisson客户端：

@Configuration
public class RedissonConfig {

    @Bean
    public RedissonClient redissonClient(){
        // 配置
        Config config = new Config();
        config.useSingleServer().setAddress("redis://192.168.150.101:6379")
            .setPassword("123321");
        // 创建RedissonClient对象
        return Redisson.create(config);
    }
}

如何使用Redission的分布式锁

@Resource
private RedissionClient redissonClient;

@Test
void testRedisson() throws Exception{
    //获取锁(可重入)，指定锁的名称
    RLock lock = redissonClient.getLock("anyLock");
    //尝试获取锁，参数分别是：获取锁的最大等待时间(期间会重试)，锁自动释放时间，时间单位
    boolean isLock = lock.tryLock(1,10,TimeUnit.SECONDS);
    //判断获取锁成功
    if(isLock){
        try{
            System.out.println("执行业务");    
        }finally{
            //释放锁
            lock.unlock();
        }
  
    }
  
  
  
}

在 VoucherOrderServiceImpl

注入RedissonClient

@Resource
private RedissonClient redissonClient;

@Override
public Result seckillVoucher(Long voucherId) {
        // 1.查询优惠券
        SeckillVoucher voucher = seckillVoucherService.getById(voucherId);
        // 2.判断秒杀是否开始
        if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {
            // 尚未开始
            return Result.fail("秒杀尚未开始！");
        }
        // 3.判断秒杀是否已经结束
        if (voucher.getEndTime().isBefore(LocalDateTime.now())) {
            // 尚未开始
            return Result.fail("秒杀已经结束！");
        }
        // 4.判断库存是否充足
        if (voucher.getStock() < 1) {
            // 库存不足
            return Result.fail("库存不足！");
        }
        Long userId = UserHolder.getUser().getId();
        //创建锁对象 这个代码不用了，因为我们现在要使用分布式锁
        //SimpleRedisLock lock = new SimpleRedisLock("order:" + userId, stringRedisTemplate);
        RLock lock = redissonClient.getLock("lock:order:" + userId);
        //获取锁对象
        boolean isLock = lock.tryLock();
   
		//加锁失败
        if (!isLock) {
            return Result.fail("不允许重复下单");
        }
        try {
            //获取代理对象(事务)
            IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();
            return proxy.createVoucherOrder(voucherId);
        } finally {
            //释放锁
            lock.unlock();
        }
 }

3 分布式锁-redission可重入锁原理

在Lock锁中，他是借助于底层的一个voaltile的一个state变量来记录重入的状态的，比如当前没有人持有这把锁，那么state=0，假如有人持有这把锁，那么state=1，如果持有这把锁的人再次持有这把锁，那么state就会+1 ，如果是对于synchronized而言，他在c语言代码中会有一个count，原理和state类似，也是重入一次就加一，释放一次就-1 ，直到减少成0 时，表示当前这把锁没有被人持有。

在redission中，我们的也支持支持可重入锁

在分布式锁中，他采用hash结构用来存储锁，其中大key表示表示这把锁是否存在，用小key表示当前这把锁被哪个线程持有，所以接下来我们一起分析一下当前的这个lua表达式

这个地方一共有3个参数

KEYS[1] ： 锁名称

ARGV[1]： 锁失效时间

ARGV[2]： id + ":" + threadId; 锁的小key

exists: 判断数据是否存在 name：是lock是否存在,如果==0，就表示当前这把锁不存在

redis.call('hset', KEYS[1], ARGV[2], 1);此时他就开始往redis里边去写数据 ，写成一个hash结构

Lock{

id +

":" + threadId : 1

}

如果当前这把锁存在，则第一个条件不满足，再判断

redis.call('hexists', KEYS[1], ARGV[2]) == 1

此时需要通过大key+小key判断当前这把锁是否是属于自己的，如果是自己的，则进行

redis.call('hincrby', KEYS[1], ARGV[2], 1)

将当前这个锁的value进行+1 ，redis.call('pexpire', KEYS[1], ARGV[1]); 然后再对其设置过期时间，如果以上两个条件都不满足，则表示当前这把锁抢锁失败，最后返回pttl，即为当前这把锁的失效时间

如果小伙帮们看了前边的源码， 你会发现他会去判断当前这个方法的返回值是否为null，如果是null，则对应则前两个if对应的条件，退出抢锁逻辑，如果返回的不是null，即走了第三个分支，在源码处会进行while(true)的自旋抢锁。

"if (redis.call('exists', KEYS[1]) == 0) then " +
                  "redis.call('hset', KEYS[1], ARGV[2], 1); " +
                  "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                  "return nil; " +
              "end; " +
              "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
                  "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
                  "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                  "return nil; " +
              "end; " +
              "return redis.call('pttl', KEYS[1]);"

4 分布式锁-redission锁重试和WatchDog机制

说明：由于课程中已经说明了有关tryLock的源码解析以及其看门狗原理，所以笔者在这里给大家分析lock()方法的源码解析，希望大家在学习过程中，能够掌握更多的知识

抢锁过程中，获得当前线程，通过tryAcquire进行抢锁，该抢锁逻辑和之前逻辑相同

1、先判断当前这把锁是否存在，如果不存在，插入一把锁，返回null

2、判断当前这把锁是否是属于当前线程，如果是，则返回null

所以如果返回是null，则代表着当前这哥们已经抢锁完毕，或者可重入完毕，但是如果以上两个条件都不满足，则进入到第三个条件，返回的是锁的失效时间，同学们可以自行往下翻一点点，你能发现有个while( true) 再次进行tryAcquire进行抢锁

long threadId = Thread.currentThread().getId();
Long ttl = tryAcquire(-1, leaseTime, unit, threadId);
// lock acquired
if (ttl == null) {
    return;
}

接下来会有一个条件分支，因为lock方法有重载方法，一个是带参数，一个是不带参数，如果带带参数传入的值是-1，如果传入参数，则leaseTime是他本身，所以如果传入了参数，此时leaseTime != -1 则会进去抢锁，抢锁的逻辑就是之前说的那三个逻辑

if (leaseTime != -1) {
    return tryLockInnerAsync(waitTime, leaseTime, unit, threadId, RedisCommands.EVAL_LONG);
}

如果是没有传入时间，则此时也会进行抢锁， 而且抢锁时间是默认看门狗时间 commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout()

ttlRemainingFuture.onComplete((ttlRemaining, e) 这句话相当于对以上抢锁进行了监听，也就是说当上边抢锁完毕后，此方法会被调用，具体调用的逻辑就是去后台开启一个线程，进行续约逻辑，也就是看门狗线程

RFuture<Long> ttlRemainingFuture = tryLockInnerAsync(waitTime,
                                        commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout(),
                                        TimeUnit.MILLISECONDS, threadId, RedisCommands.EVAL_LONG);
ttlRemainingFuture.onComplete((ttlRemaining, e) -> {
    if (e != null) {
        return;
    }

    // lock acquired
    if (ttlRemaining == null) {
        scheduleExpirationRenewal(threadId);
    }
});
return ttlRemainingFuture;

此逻辑就是续约逻辑，注意看commandExecutor.getConnectionManager().newTimeout（） 此方法

Method( new TimerTask() {},参数2 ，参数3 )

指的是：通过参数2，参数3 去描述什么时候去做参数1的事情，现在的情况是：10s之后去做参数一的事情

因为锁的失效时间是30s，当10s之后，此时这个timeTask 就触发了，他就去进行续约，把当前这把锁续约成30s，如果操作成功，那么此时就会递归调用自己，再重新设置一个timeTask()，于是再过10s后又再设置一个timerTask，完成不停的续约

那么大家可以想一想，假设我们的线程出现了宕机他还会续约吗？当然不会，因为没有人再去调用renewExpiration这个方法，所以等到时间之后自然就释放了。

private void renewExpiration() {
    ExpirationEntry ee = EXPIRATION_RENEWAL_MAP.get(getEntryName());
    if (ee == null) {
        return;
    }
  
    Timeout task = commandExecutor.getConnectionManager().newTimeout(new TimerTask() {
        @Override
        public void run(Timeout timeout) throws Exception {
            ExpirationEntry ent = EXPIRATION_RENEWAL_MAP.get(getEntryName());
            if (ent == null) {
                return;
            }
            Long threadId = ent.getFirstThreadId();
            if (threadId == null) {
                return;
            }
      
            RFuture<Boolean> future = renewExpirationAsync(threadId);
            future.onComplete((res, e) -> {
                if (e != null) {
                    log.error("Can't update lock " + getName() + " expiration", e);
                    return;
                }
          
                if (res) {
                    // reschedule itself
                    renewExpiration();
                }
            });
        }
    }, internalLockLeaseTime / 3, TimeUnit.MILLISECONDS);
  
    ee.setTimeout(task);
}

5 分布式锁-redission锁的MutiLock原理

为了提高redis的可用性，我们会搭建集群或者主从，现在以主从为例

此时我们去写命令，写在主机上， 主机会将数据同步给从机，但是假设在主机还没有来得及把数据写入到从机去的时候，此时主机宕机，哨兵会发现主机宕机，并且选举一个slave变成master，而此时新的master中实际上并没有锁信息，此时锁信息就已经丢掉了。

为了解决这个问题，redission提出来了MutiLock锁，使用这把锁咱们就不使用主从了，每个节点的地位都是一样的， 这把锁加锁的逻辑需要写入到每一个主丛节点上，只有所有的服务器都写入成功，此时才是加锁成功，假设现在某个节点挂了，那么他去获得锁的时候，只要有一个节点拿不到，都不能算是加锁成功，就保证了加锁的可靠性。

那么MutiLock 加锁原理是什么呢？笔者画了一幅图来说明

当我们去设置了多个锁时，redission会将多个锁添加到一个集合中，然后用while循环去不停去尝试拿锁，但是会有一个总共的加锁时间，这个时间是用需要加锁的个数 * 1500ms ，假设有3个锁，那么时间就是4500ms，假设在这4500ms内，所有的锁都加锁成功， 那么此时才算是加锁成功，如果在4500ms有线程加锁失败，则会再次去进行重试.

该内容由 RSS 渲染生成，最佳阅读体验请前往：https://xancel.top/posts/toolbox

2025-06-10

图片类

作图

• 在线手写风格作图白板Excalidraw

• 在线矢量图作图软件（draw.io）app.diagrams.net

• 在线图论作图网站Graph Editor

• tikz 有限状态机可视化制作Finite State Machine Designer

识图

• SauceNAO

修改图片

• 移除背景（完全免费）RemoveBg

• 纯前端免费图片压缩PicDiet

• 图片压缩（需上传）DocSmall

• 擦除图片上物品（免费功能受限）cleanup.pictures

代码类

可视化

• 正则表达式可视化Regulex

• Python 执行过程可视化PythonTutor

• GLSL 流体场可视化Field Play

编解码

• 超强多合一编解码工具CyberChef

• 三词地址（用三个单词编码一个地点）what3words

学习工具

• 缓动曲线Easing Function Cheat Sheet

• 多编译器编译结果浏览Compiler Explorer

• 大 O 复杂度比较查询Big O Cheat Sheet

• C 类型声明转英文描述cdecl

设计类

配色

• 配色方案网站Color Hunt

• 配色方案网站（带 Figma 插件） Coolors

• 颜色查找及转换工具HexColor16

• 日式传统颜色列表Nippon Colors

• 日系颜色名称列表 Color Site

• Flat UI 配色方案Flat UI Colors

图标

• 各系列图标合集icones

数学类

• 数列查找OEIS

其它

• Emoji 查询EmojiAll

• ffmpeg 指令生成ffmpeg-commander