江南一点雨的专栏

Redis 有多好用咱就不多说了。再好的工具，也得使用得当，才能发挥最佳效用。如果不分青红皂白使劲造，Redis 也扛不住。今天和小伙伴们聊一聊 Redis 中需要慎重使用的几个命令。

前面松哥写了一篇文章和大家聊了 Spring6 中引入的新玩意 AOT（见文章发出来之后，有小伙伴问松哥有没有做性能比较，老实说，这个给落下了，所以今天再来一篇文章，和小伙伴们梳理比较小当我们利用 Native Image 的时候，Spring Boot 启动性能从参数上来说，到底提升了多少。先告诉大家结论：启动速度提升 10 倍以上。

以下内容基于 Spring6.0.4。这个话题其实非常庞大，我本来想从 getBean 方法讲起，但一想这样讲完估计很多小伙伴就懵了，所以我们还是一步一步来，今天我主要是想和小伙伴们讲讲 Spring 容器创建 Bean 最最核心的 createBeanInstance 方法，这个方法专门用来创建一个原始 Bean 实例。松哥这里就以 Spring 源码中方法的执行顺序为例来和小伙伴们分享。

在 2.1 小节和 2.2 小节，分别是求交集和求并集，为了 intersect 和 union 操作方便，在各个单独的索引扫描的时候，都是要获取到有序的主键值的合集，各个索引都获取到有序的主键，然后求交集或者并集就会比较方便。在前面的文章中，松哥和小伙伴们分享了 MySQL 中，InnoDB 存储引擎的数据结构，小伙伴们知道，当我们使用索引进行搜索的时候，每一次的搜索都是在某一棵 B+Tree 中搜索的，如果使用了二级索引的话，可能还会涉及到回表。今天我们就来讨论下这个话题。

在 HTTP 请求中，我们发送请求的时候，可以设置一个请求超时时间-connectTimeout，即在指定的时间内，如果请求没有到达服务端，为了避免客户端一直进行不必要的等待，就会抛出一个请求超时异常。我们之前写过一个登录的案例，在之前的案例中，如果用户在登录时输入了错误的用户名密码的话，那么我们是通过一个普通的数据流返回异常信息，其实，对于异常信息，我们可以通过专门的异常通道来写回到客户端。但是在微服务系统中，我们却很少设置请求超时时间，一般都是用另外一个概念代替，那就是请求截止时间。

有状态服务，即服务端需要记录每次会话的客户端信息，从而识别客户端身份，根据用户身份进行请求的处理，典型的设计如 Tomcat 中的 Session。例如登录：用户登录后，我们把用户的信息保存在服务端 session 中，并且给用户一个 cookie 值，记录对应的 session，然后下次请求，用户携带 cookie 值来（这一步有浏览器自动完成），我们就能识别到对应 session，从而找到用户的信息。服务端保存大量数据，增加服务端压力服务端保存用户状态，不支持集群化部署。

今天我们继续 gRPC 系列。今天我们来继续聊一聊 gRPC 中的拦截器。有请求的发送、处理，当然就会有拦截器的需求，例如在服务端通过拦截器统一进行请求认证等操作，这些就需要拦截器来完成，今天松哥先和小伙伴们来聊一聊 gRPC 中拦截器的基本用法，后面我再整一篇文章和小伙伴们做一个基于拦截器实现的 JWT 认证的 gRPC。我们分别来看。

温馨提示：本文需要结合一起食用，否则可能看不懂。前面一篇文章松哥和大家聊了 gRPC 的基本用法，今天我们再来稍微深入一点点，来看下 gRPC 中四种不同的通信模式。接下来松哥就通过四个完整的案例，来分别和向伙伴们演示这四种不同的通信模式。

了解 gRPC 之前先来看看什么是 RPC。RPC 全称是 Remote Procedure Call，中文一般译作远程过程调用。RPC 是一种进程间的通信模式，程序分布在不同的地址空间里。简单来说，就是两个进程之间互相调用的一种方式。gRPC 则是一个由 Google 发起的开源的 RPC 框架，它是一个高性能远程过程调用 (RPC) 框架，可以在任何环境中运行。gRPC 通过对负载均衡、跟踪、健康检查和身份验证的可插拔支持，有效地连接数据中心内和数据中心之间的服务。

好久没发技术文章了，最近回到工作地，晚上有空又可以码码技术了，今天我们就来聊一个 Spring Boot3 中的新鲜玩意，声明式 HTTP 调用。

玩过微服务的小伙伴对 Spring Cloud 中的的 Spring Cloud Gateway 多多少少都有一些了解，松哥之前既写过相关的文章，也录过相关的视频跟小伙伴们介绍 Spring Cloud Gateway，不过在之前的介绍中，我可能更加侧重于跟小伙伴们介绍 Spring Cloud Gateway 的用法，对于我们在微服务中为什么要使用 Spring Cloud Gateway 可能没有和大家仔细分析过，最近年前得空，我们来一起探讨一下这个话题。

今天我们来聊一下微服务项目中的版本号要怎么设计。小伙伴们平时看到的项目版本号，基本上都是分为了三部分X.Y.Z，版本升级的时候版本号都会变，那么版本号怎么变，这可不是拍脑门决定的，今天我们就一起来探讨一下这个话题。

说起 REST API，小伙伴们多多少少都有听说过，但是如果让你详细介绍一下什么是 REST，估计会有很多人讲不出来，或者只讲出来其中一部分。今天松哥就来和大家一起来聊一聊到底什么是 REST，顺便再来看下 Spring HATEOAS 的用法。

玩过 Dubbo 的小伙伴应该都有听说过一个概念叫做 SOA，每当我们说起微服务的时候，很多人就会去纠结这和 SOA 有啥关系呀？感觉换汤不换药呀。今天松哥来稍微和小伙伴们讨论下这个话题，我们一起来看看 SOA 和微服务到底有何异同。

有不少小伙伴希望松哥能整一个微服务的实战项目，微服务这块技术点其实松哥是讲过很多了，图文版的教程视频版的教程都有，不过确实缺乏一个项目，所以我在想等 TienChin 项目搞完之后，和小伙伴们也来一起搞一个微服务的项目。今天我想从架构的角度来和小伙伴们聊一聊微服务。不聊具体的技术点，就单纯来看看一个微服务项目该怎么设计。

我们来看看 MySQL 官网的介绍：大致翻译下一下就是这样：插入意向锁是一种在 INSERT 操作之前设置的一种间隙锁，插入意向锁表示了一种插入意图，即当多个不同的事务，同时往同一个索引的同一个间隙中插入数据的时候，它们互相之间无需等待，即不会阻塞（要是单纯按照之前间隙锁的理论，必须要等一个间隙锁释放了，下一个事务才可以往相同的间隙处插入数据）。

可能不少小伙伴都注意到了，从 ElasticSearch7.17 这个版本开始，原先的 Java 高级客户端Java High Level REST Client 废弃了，不支持了。老实说，ElasticSearch 算是我用过的所有 Java 工具中，更新最为激进的一个了，在 Es7 中废弃了 TransportClient，7.17 又废弃了 TransportClient，那么现在用啥呢？现在的客户端叫做 Elasticsearch Java API Client。

学过 Spring 的小伙伴相信都知道 AOP，AOP 学的好的小伙伴相信对 AOP 的概念也是轻车熟路：面向切面编程、切点、切面、通知，Aspect、Pointcut、Advice 等如数家珍。AOP 之所以这么重要，是因为它在项目中有着非常广泛的应用，今天这篇文章，松哥就来和大家总结一下，我们在日常开发中，都有哪些典型场景需要用到 AOP。先来一句话总结下，AOP 的使用，基本上都会涉及到自定义注解，一个非常常见的组合，就是自定义注解+AOP。

最近刚好有小伙伴在微信上问到这个问题，松哥就来和大家聊一聊，本文主要和小伙伴们聊一聊思路，不写代码，小伙伴们可以结合松哥之前的文章，应该能够自己写出来本文的代码。当然，思路也只是我自己的一点实践经验，不一定是最完美的方案，欢迎小伙伴们在留言中一起探讨。首先小伙伴们知道，无论我们学习 Shiro 还是 Spring Security，里边的功能无论有哪些，核心都是两个：所以，我们在微服务中处理鉴权问题，也可以从这两个方面来考虑。认证，说白了就是登录。传统的 Web 登录是 Cookie+Session 的方案

最近有小伙伴告诉松哥说面试中被问到这个问题了，不知道该怎么回答，这能忍？捋一篇文章和小伙伴们分享下吧。既然捋成文章，就连同 Spring 事务一起梳理下吧。数据库事务是指作为单个逻辑工作单元执行的一系列操作，这些操作要么一起成功，要么一起失败，是一个不可分割的工作单元。在我们日常工作中，涉及到事务的场景非常多，一个 service 中往往需要调用不同的 dao 层方法，这些方法要么同时成功要么同时失败，我们需要在 service 层确保这一点。说到事务最典型的案例就是转账了：事务有四大特性（ACID）：这就

小伙伴们知道，Spring Cloud Config 很早就提供了配置文件的加解密功能，并且支持对称加密和非对称加密两种不同的模式。Nacos 作为分布式配置中心+服务注册中心的合体，在配置文件加密这块一直差点意思，不过好在，如果你使用的 Nacos 版本大于 2.0.4 这个版本，那么现在也可以通过插件的方式来实现配置文件加密了。

今天聊一个小伙伴在星球上的提问：问题不难，解决方案也有很多，因此我决定撸一篇文章和大家仔细说说这个问题。

上篇文章我们一起学习了 Flowable 中的动态表单，动态表单说白了就是把变量打包定义，零存整取。但是小伙伴们可能很难实实在在 GET 到动态表单一些有创造性的功能，所以今天我们就来继续看看 Flowable 中的外置表单怎么玩，这个跟动态表单有一些本质上的差别。

整体上来说，我们可以将表单分为三种不同的类型：另外小伙伴们需要注意，Flowable 中有很多不同类型的节点，但是只有开始节点和任务节点是支持表单定义的，其他节点均不支持表单定义。今天我们就先来看看动态表单的玩法。假设我有如下一个请假流程：在第一个任务节点中，需要填写请假的基本信息，那么我们选中该节点，然后点击动态表单属性，如下图：然后就可以开启动态表单属性的配置了：我这里一共配置了四个属性，这些属性的含义应该都好理解，我就不一一赘述了。接下来我们来下载这个流程图。流程的 XML 文件下载下来之后，我们可以

在之前松哥给小伙伴们介绍流程定义的时候，流程都是定义好之后立马就激活了，其实在流程定义的这个过程中，我们还可以设置一个激活时间，也就是流程定义好之后，并不会立马激活（不激活就不能据此流程定义创建新流程），而是在延迟某一个固定时间之后，才会激活，代码如下： 表示流程在延迟一分钟之后，才激活。此时，我们启动项目，然后调用该接口部署一个流程，部署完成之后，如果立马调用流程启动方法去启动流程，就会抛出如下异常：可以看到，这里也说的很明确了，这个流程定义目前是一个挂起的状态，无法启动。这个时候，我们去查看 表，就

和前面讲的很多查询类似，当我们弄懂了每一个历史查询的 API 操作的是哪一个数据表，就会发现，历史数据的查询，也可以自定义 SQL。} } }flowable 底层是 MyBatis，所有 SQL 中参数的传递形式和 MyBatis 一致。

我们可以在启动的时候为流程设置变量，小伙伴们注意到，流程变量的 value 也可以是一个对象（不过这个对象要能够序列化，即实现了 Serializable 接口），然后在启动的时候传入这个变量即可。在之前的文章中，松哥也有和小伙伴们使用过流程变量，然而没有和大家系统的梳理过流程变量的具体玩法以及它对应的数据表详情，今天我们就来看看 Flowable 中流程变量的详细玩法。第三小节我们说的全局流程变量是和某一个具体的流程绑定的，而本地流程变量则不同，本地流程变量和某一个 Task 绑定。

这三个里边最常用的当然就是排他网关了，今天松哥就来和小伙伴们聊一聊这三种网关，一起来体验一把这三种网关各自的特征。

前面的文章我们一起玩了 Flowable 中的 ServiceTask，今天我们再来看看 Flowable 中的脚本任务。

前面和小伙伴们分别聊了 Flowable 中的 ReceiveTask 和 UserTask，今天我们来看看另外一个比较常见的 Task --> ServiceTask。

前面松哥和大家分享的都是给 UserTask 设置处理人或者是候选用户，不过小伙伴们也知道，在我们为 UserTask 设置处理人的时候，除了设置单个的处理人，也可以设置 Group，就是某一个用户组内的所有用户都可以处理该 Task。，上面这个 SQL 可以查询出来 zhangsan 这个用户属于 leader 这个分组，在接下来的查询中，会 zhangsan 和 leader 两个参数都会用到。好啦，当这些任务查询出来后，接下来该如何执行，就和前面介绍的内容一样了，我这里就不再赘述了。

上篇文章松哥和大家分享了 Flowable 中设置任务处理人的四种方式，不过那四种方式都是针对单个任务处理人，有的时候，一个任务节点会存在多个候选人，例如 zhangsan 提交一个任务，这个任务即可以 lisi 处理，又可以 wangwu 处理，那么针对这种多个任务候选人的情况，我们该如何处理？其实思路很简答，就是重新为任务设置处理人，且处理人为 null，这就是将任务回退了，接下来其他人可以重新认领该任务了。另外一种常见的需求就是，已经知道了要处理的流程实例了，但是不知道应该由谁来处理，此时通过查询。

UserTask 看名字就知道，需要人工干预，而人工处理的方式有很多种，我们可以设置节点是由哪个用户处理，也可以设置是由哪个用户组来处理（相当于是由哪个角色来处理），今天这篇文章我主要和大家分享设置用户的三种方式，至于如何设置用户组，这个咱们下篇文章再聊。最后再来说说一种特殊情况，就是这个 UserTask 由任务的发起人处理，任务是谁发起的，谁来处理人这个 UserTask。接下来，我们部署并启动这个流程（具体的部署启动方式可以参考本系列之前的文章），启动之后，我们可以在数据库的。

在之前的案例中，松哥和大家举例最多的 Task 主要是 UserTask 和 ServiceTask，ReceiveTask 虽然也和大家提过但是没有仔细讲过，今天我们就来捋一捋 ReceiveTask 在 Flowable 中到底怎么玩。

不知道小伙伴们有没有留意过，在 Flowable 流程图的绘制过程中，我们可以编写一个名为 dataObject 的元素，这个元素可以指定变量的 id、名称以及数据类型等各种属性，并且在流程实例启动的时候，会自动将 dataObject 元素的信息转换为流程实例变量，这个东西也蛮好玩的，今天松哥就带领小伙伴们来捋一捋 Flowable 中的 dataObject。

logger . info("流程定义 {} 已挂起" , processDefinition . getName());} else {logger . info("流程定义 {} 未挂起" , processDefinition . getName());} } }这个查询 SQL 涉及到的表是，该表中有一个名为的字段，该字段表示这个流程是否挂起。如下图：1 表示流程没有挂起。

上篇文章和小伙伴们分享的流程操作主要是正在执行的流程，我们有一个非常常见的场景是查询执行过的流程信息，在上篇文章中，小伙伴们已经知道，对于正在执行的流程，会在 ACT_RU_EXECUTION 表中保存一条对应的记录，不过流程执行结束之后，ACT_RU_EXECUTION 表中的记录会被删除掉，此时要是想查询已经执行过的流程信息，去哪里查询呢？今天我们就来看看 HistoryService 的使用。

流程定义 ProcessDefinition 这个好说，其实就是我们。

接下来我们再来看看查询流程的定义信息。key:{};version:{};} }来看看控制台打印的 SQL：可以看到，就是去流程定义表 ACT_RE_PROCDEF 去查看所有。key:{};version:{};} }我们来看下查询 SQL：其他的查询 API 我就不挨个演示了，方法基本上都是见名知意的。

虽然说我们在实际开发中，很少会直接用到 flowable 中的用户体系，但是，也不太可能完全用不到，毕竟官方设计了这个东西，而存在就必然有其合理性，所以，今天松哥还是来和大家聊一聊，在 Spring Boot 项目中，我们如何去添加、删除、修改一个用户或者组。好啦，差不多就这些内容吧，如果我们想要使用自己的用户体系，又不想抛弃 flowable 的用户，那么可以按照如上方式，在添加系统本地用户的时候，也往 flowable 中添加/更新用户。