大家好，我是二哥呀。

虾皮在去年之前，还是很多大厂人外逃的首选项，因为总部在新加坡，比较有外企范，但去年就突然急转直下，队伍收紧了不少。

作为东南亚电商市场的领头羊，市场覆盖了新加坡、马来西亚、泰国、菲律宾、印尼、越南等地，目前也开始进军巴西和墨西哥等新兴市场。

我从 offershow 上也统计了一波 25 届虾皮目前开出来的薪资状况，方便大家做个参考。

• 本科 985，后端岗，给了 32k，还有 5 万签字费，自己硬 A 出来的，15 天年假，base 上海，早 9.30 晚 7 点


• 硕士双一流，后端给了 40 万年包，但已经签了其他的三方，拒了，11 月 31 日下午开的


• 硕士 985，后端开发，给到了 23k，白菜价，主要面试的时候表现太差了


• 硕士海归，后端开发给了 26.5k，还有三万签字费，咩别的高，就释放了


• 硕士211，测试岗，只给了 21k，还有 3 万年终奖，但拒了

从目前统计到的情况来看，虾皮其实还蛮舍得给钱的，似乎有点超出了外界对他的期待。但很多同学因为去年的情况，虾皮只能拿来做备胎，不太敢去。

从虾皮母公司 Sea 发布的2024 年第三季度财报来看，电子商务（主要是 Shopee）收入增长了 42.6%，达到了 31.8 亿美元，均超预期。

总之，希望能尽快扭转颓势吧，这样学 Java 的小伙伴也可以有更多的选择。

那接下来，我们就以 Java 面试指南中收录的虾皮面经同学 13 一面为例，来看看下面的面试难度，自己是否有一战之力。

虾皮面经同学 13 一面

tcp为什么是可靠的

TCP 首先通过三次握手和四次挥手来保证连接的可靠性，然后通过校验和、序列号、确认应答、超时重传、滑动窗口等机制来保证数据的可靠传输。

①、校验和：TCP 报文段包括一个校验和字段，用于检测报文段在传输过程中的变化。如果接收方检测到校验和错误，就会丢弃这个报文段。

推荐阅读：TCP 校验和计算方法

②、序列号/确认机制：TCP 将数据分成多个小段，每段数据都有唯一的序列号，以确保数据包的顺序传输和完整性。同时，发送方如果没有收到接收方的确认应答，会重传数据。

③、流量控制：接收方会发送窗口大小告诉发送方它的接收能力。发送方会根据窗口大小调整发送速度，避免网络拥塞。

④、超时重传：如果发送方发送的数据包超过了最大生存时间，接收方还没有收到，发送方会重传数据包以保证丢失数据重新传输。

⑤、拥塞控制：TCP 会采用慢启动的策略，一开始发的少，然后逐步增加，当检测到网络拥塞时，会降低发送速率。在网络拥塞缓解后，传输速率也会自动恢复。

http的get和post区别

GET 请求主要用于获取数据，参数附加在 URL 中，存在长度限制，且容易被浏览器缓存，有安全风险；而 POST 请求用于提交数据，参数放在请求体中，适合提交大量或敏感的数据。

另外，GET 请求是幂等的，多次请求不会改变服务器状态；而 POST 请求不是幂等的，可能对服务器数据有影响。

https使用过吗 怎么保证安全

HTTP 是明文传输的，存在数据窃听、数据篡改和身份伪造等问题。而 HTTPS 通过引入 SSL/TLS，解决了这些问题。

SSL/TLS 在加密过程中涉及到了两种类型的加密方法：

• 非对称加密：服务器向客户端发送公钥，然后客户端用公钥加密自己的随机密钥，也就是会话密钥，发送给服务器，服务器用私钥解密，得到会话密钥。


• 对称加密：双方用会话密钥加密通信内容。

客户端会通过数字证书来验证服务器的身份，数字证书由 CA 签发，包含了服务器的公钥、证书的颁发机构、证书的有效期等。

https能不能抓包

可以，HTTPS 可以抓包，但因为通信内容是加密的，需要解密后才能查看。

其原理是通过一个中间人，伪造服务器证书，并取得客户端的信任，然后将客户端的请求转发给服务器，将服务器的响应转发给客户端，完成中间人攻击。

常用的抓包工具有 Wireshark、Fiddler、Charles 等。

threadlocal 原理 怎么避免垃圾回收？

ThreadLocal 的实现原理就是，每个线程维护一个 Map，key 为 ThreadLocal 对象，value 为想要实现线程隔离的对象。

1、当需要存线程隔离的对象时，通过 ThreadLocal 的 set 方法将对象存入 Map 中。

2、当需要取线程隔离的对象时，通过 ThreadLocal 的 get 方法从 Map 中取出对象。

3、Map 的大小由 ThreadLocal 对象的多少决定。

通常情况下，随着线程 Thread 的结束，其内部的 ThreadLocalMap 也会被回收，从而避免了内存泄漏。

但如果一个线程一直在运行，并且其 ThreadLocalMap 中的 Entry.value 一直指向某个强引用对象，那么这个对象就不会被回收，从而导致内存泄漏。当 Entry 非常多时，可能就会引发更严重的内存溢出问题。

使用完 ThreadLocal 后，及时调用 remove() 方法释放内存空间。remove() 方法会将当前线程的 ThreadLocalMap 中的所有 key 为 null 的 Entry 全部清除，这样就能避免内存泄漏问题。

mysql慢查询

慢 SQL 也就是执行时间较长的 SQL 语句，MySQL 中 long_query_time 默认值是 10 秒，也就是执行时间超过 10 秒的 SQL 语句会被记录到慢查询日志中。

可通过 show variables like 'long_query_time'; 查看当前的 long_query_time 值。

不过，生产环境中，10 秒太久了，超过 1 秒的都可以认为是慢 SQL 了。

mysql事务隔离级别

事务的隔离级别定了一个事务可能受其他事务影响的程度，MySQL 支持的四种隔离级别分别是：读未提交、读已提交、可重复读和串行化。

遇到过mysql死锁或者数据不安全吗

有，一次典型的场景是在技术派项目中，两个事务分别更新两张表，但是更新顺序不一致，导致了死锁。

-- 创建表/插入数据

CREATE TABLE account (

    id INT AUTO_INCREMENT PRIMARY KEY,

    balance INT NOT NULL

);



INSERT INTO account (balance) VALUES (100), (200);



-- 事务 1

START TRANSACTION;

-- 锁住 id=1 的行

UPDATE account SET balance = balance - 10 WHERE id = 1;



-- 等待锁住 id=2 的行（事务 2 已锁住）

UPDATE account SET balance = balance + 10 WHERE id = 2;



-- 事务 2

START TRANSACTION;

-- 锁住 id=2 的行

UPDATE account SET balance = balance - 10 WHERE id = 2;



-- 等待锁住 id=1 的行（事务 1 已锁住）

UPDATE account SET balance = balance + 10 WHERE id = 1;

两个事务访问相同的资源，但是访问顺序不同，导致了死锁。

解决方法：

第一步，使用 SHOW ENGINE INNODB STATUS\G; 查看死锁信息。

第二步，调整事务的资源访问顺序，保持一致。

怎么解决依赖冲突的

比如在一个项目中，Spring Boot 和其他库对 Jackson 的版本有不同要求，导致序列化和反序列化功能出错。

这时候，可以先使用 mvn dependency:tree分析依赖树，找到冲突；然后在 dependencyManagement 中强制统一 Jackson 版本，或者在传递依赖中使用 exclusion 排除不需要的版本。

spring事务

在 Spring 中，事务管理可以分为两大类：声明式事务管理和编程式事务管理。

编程式事务可以使用 TransactionTemplate 和 PlatformTransactionManager 来实现，需要显式执行事务。允许我们在代码中直接控制事务的边界，通过编程方式明确指定事务的开始、提交和回滚。

声明式事务是建立在 AOP 之上的。其本质是通过 AOP 功能，对方法前后进行拦截，将事务处理的功能编织到拦截的方法中，也就是在目标方法开始之前启动一个事务，在目标方法执行完之后根据执行情况提交或者回滚事务。

相比较编程式事务，优点是不需要在业务逻辑代码中掺杂事务管理的代码，Spring 推荐通过 @Transactional 注解的方式来实现声明式事务管理，也是日常开发中最常用的。

常见的linux命令

我自己常用的 Linux 命令有 top 查看系统资源、ps 查看进程、netstat 查看网络连接、ping 测试网络连通性、find 查找文件、chmod 修改文件权限、kill 终止进程、df 查看磁盘空间、free 查看内存使用、service 启动服务、mkdir 创建目录、rm 删除文件、rmdir 删除目录、cp 复制文件、mv 移动文件、zip 压缩文件、unzip 解压文件等等这些。

git命令

• git clone <repository-url>：克隆远程仓库。


• git status：查看工作区和暂存区的状态。


• git add <file>：将文件添加到暂存区。


• git commit -m "message"：提交暂存区的文件到本地仓库。


• git log：查看提交历史。


• git merge <branch-name>：合并指定分支到当前分支。


• git checkout <branch-name>：切换分支。


• git pull：拉取远程仓库的更新。

内容来源

三分恶的面渣逆袭：javabetter.cn/sidebar/san…
二哥的 Java 进阶之路（GitHub 已有 13000+star）：github.com/itwanger/to…

最后，把二哥的座右铭送给大家：没有什么使我停留——除了目的，纵然岸旁有玫瑰、有绿荫、有宁静的港湾，我是不系之舟。共勉 💪。

最近观看公司前辈文档，看到对大数据量跑批的优化方案，参照自己的理解和之前相关经验整理了一份优化方案~

Background

定义： 跑批通常指代的是我们应用程序在固定日期针对某一批大量数据定时进行特定的处理，在金融业务中一般跑批的场景有分户日结、账务计提、账单逾期、不良资产处理等等，它具有高连贯性特点，通常我们执行完跑批后还要对跑批数据进行进一步处理，比如发 MQ 给下游消费，数仓拉取分析等。。。

跑批最怕的就是上来就干，从不考虑涉及到第三方接口时的响应时间、大事务等问题。

Problem

针对大数据量跑批会有很多的问题，比如我们要在指定日期指定时间的大数据量去处理，还要保证处理期间尽可能的高效，在出现错误时也要进行相应的补偿措施，避免影响到其它业务等 ~

Analyze

通过以上问题的总结，我们可以得出要完整的进行大数据量跑批任务我们的代码设计需要具备以下的几点素质：

Solution

大数据量的数据是很庞大的，如果一次性都加载到内存里面将会是灾难性的后果，因此我们要对大数据量数据进行分割处理，这是防止 OOM 必要的一环！此外，监控、异常等方法措施也要实施到位，到问题出现再补救就晚了~

1、数据库问题

使用数据库扫表问题：
遍历数据对数据库的压力是很大的，越往后速度越慢；

解决：
遍历数据库越往后查压力越大，可以设置在每次查询的时候携带上一次的极值，让你分页查找的offect永远控制在0；

2、分片广播

分片： 在生产环境中，都是采用集群部署，如果一个跑批任务只跑在一个机器上，那效率肯定很低，我们可以利用 xxl-job「分片广播」 和 「动态分片」 功能；

分布式调度幂等： 分布式任务调度只能保证准时调到一个节点上，而且通常都有失败重试的功能。所以任务幂等都是要的，一般都是通过分布式锁来实现，这里遵循简单原则使用数据库就可以了，可以通过在任务表里 insert 一条唯一的任务记录，通过唯一键来防止重复调度。

除了用唯一键，还可以在记录中增加一个状态字段，使用乐观锁来更新状态。比如开始是初始化状态，更新成正在运行的状态，更新失败说明别的节点已经在跑这个任务。当然分布式锁的实现方案有很多，比如 redis、zk 等等。

集群分布式任务调度 xxl-job： 执行器集群部署时，“分片广播” 以执行器为维度进行分片，任务路由策略选择”分片广播”情况下，一次任务调度将会广播触发对应集群中所有执行器执行一次任务，同时系统自动传递分片参数；可根据分片参数开发分片任务；

• 分片任务场景：10个执行器的集群来处理10w条数据，每台机器只需要处理1w条数据，耗时降低10倍；


• 广播任务场景：广播执行器机器运行shell脚本、广播集群节点进行缓存更新等

// Index 是属于 Total 第几个序列（从0开始）

int shardIndex = XxlJobHelper.getShardIndex();

// Total 是总的执行器数量

int shardTotal = XxlJobHelper.getShardTotal();

3、分批获取

4、事务控制

5、充分利用服务器资源

需要充分利用服务器资源，采用多线程，MySQL的CPU在罚息期间也是低于 50%、IOPS 使用率低于 50%；
其实跑数据是 io 密集型的，不需要非得压榨服务器资源 ~

6、MQ 消费任务并行

MQ 消费消息队列的消息时要在每个节点上同时跑多个子任务才能资源利用最大化。那么就使用到线程池了，如果选择的是Kafka或者 RocketMQ，他们的客户端本来就是线程池消费的，只需要合理调整客户端参数就可以了。如果使用的是 Redis，那就需要自己创建一个线程池，然后让一个 EventLoop 线程从 Redis 队列中取任务。放入线程池中运行，因为我们已经使用 Redis 队列做缓冲，所以线程池的队列长度设为0，这里直接使用JDK提供的 SynchronousQueue。（这里以java为例）

7、动态调整并发度

跑批任务中能动态调整速度是很重要的，有 2 个地方可以进行操作：

8、失败任务如何继续

一般分布式调度路径：

在这个链条中，可能导致任务失败或者中止的原因无非下面几个。

其实解决起来也简单，因为其它因素导致失败，你需要记录下任务的进度，然后在失败的点去再次重试 ~

9、下游接口时间

跑批最怕的就是上来就干，从不考虑涉及到第三方接口时的响应时间，如果不考虑第三方接口调用时间，那么在测试时候你会发现频繁的 YGC，这是很致命的问题，属于你设计之外的事件，但也是你必须要考虑的~

解决起来也简单，在业务可以容忍的情况下，我们可以将调用接口的业务逻辑设计一个中间态，然后挂起我们的这个业务，随后用定时任务去查询我们的业务结果，在收到信息后继续我们的业务逻辑，避免它一直在内存中堆积 ~

10、线程安全

在进行跑批时，一般会采用多线程的方式进行处理，因此要考虑线程安全的问题，比如使用线程安全的容器，使用JUC包下的工具类。

11、异常 & 监控

Reference

京东云定时任务优化总结(从半个小时优化到秒级)
记一次每日跑批任务耗时性能从六分钟优化到半分钟历程及总结

@RestControllerAdvice

public class GlobalExceptionHandler {



    /**

     *  参数校检异常

     * @param e

     * @return

     */

    @ExceptionHandler(value = MethodArgumentNotValidException.class)

    public ResponseResult handle(MethodArgumentNotValidException e) {

        BindingResult bindingResult = e.getBindingResult();



        StringJoiner joiner = new StringJoiner(";");



        for (ObjectError error : bindingResult.getAllErrors()) {

            String code = error.getCode();

            String[] codes = error.getCodes();



            String property = codes[1];

            property = property.replace(code ,"").replaceFirst(".","");



            String defaultMessage = error.getDefaultMessage();

            joiner.add(property+defaultMessage);

        }

        return handleException(joiner.toString());

    }



    private ResponseResult handleException(String msg) {

        ResponseResult result = new ResponseResult<>();

        result.setMessage(msg);

        result.setCode(500);

        return result;

    }

}

public interface CreationGr0up {

}

public interface UpdateGr0up {

}

创建一个UserBean用户类，分别校验 username 字段不能为空和id字段必须大于0，然后加上CreationGr0up和 UpdateGr0up 分组。

/**

 * @author 公众号-索码理(suncodernote)

 */

@Data

public class UserBean {



    @NotEmpty( groups = {CreationGr0up.class})

    private String username;



    @Min(value = 18)

    private Integer age;



    @Email(message = "邮箱格式不正确")

    private String email;



    @Min(value  = 1 ,groups = {UpdateGr0up.class})

    private Long id;

}

3. 创建接口

在ValidationController 中新建两个接口 updateUser 和 createUser：

@RestController

@RequestMapping("validation")

public class ValidationController {



    @GetMapping("updateUser")

    public UserBean updateUser(@Validated({UpdateGr0up.class})  UserBean userBean){

        return userBean;

    }



    @GetMapping("createUser")

    public UserBean createUser(@Validated({CreationGr0up.class})  UserBean userBean){

        return userBean;

    }

}

4. 测试

先对 createUser接口进行测试，我们将id的值设置为0，也就是不满足id必须大于0的条件，同样 username 不传值，即不满足 username 不能为空的条件。  通过测试结果我们可以看到，虽然id没有满足条件，但是并没有提示，只提示了username不能为空。

再对 updateUser接口进行测试，条件和测试 createUser接口的条件一样，再看测试结果，和 createUser接口测试结果完全相反，只提示了id最小不能小于1。 

至此，分组功能就演示完毕了。

嵌套校验

介绍嵌套校验之前先看一下两个概念：

有这样一个需求，在保存用户时，用户地址必须要填写。下面来简单看下示例：

在AddressBean 设置 country和city两个属性为必填项。

@Data

public class AddressBean {



    @NotBlank

    private String country;



    @NotBlank

    private String city;

}

2. 修改用户类，将AddressBean作为用户类的一个嵌套属性

特别提示：想要嵌套校验生效，必须在嵌套属性上加 @Valid 注解。

@Data

public class UserBean {



    @NotEmpty(groups = {CreationGr0up.class})

    private String username;



    @Min(value = 18)

    private Integer age;



    private String email;



    @Min(value  = 1 ,groups = {UpdateGr0up.class})

    private Long id;



	//嵌套验证必须要加上@Valid

    @Valid

    @NotNull

    private AddressBean address;

}

3. 创建一个嵌套校验测试接口

@PostMapping("nestValid")

public UserBean nestValid(@Validated @RequestBody UserBean userBean){

    System.out.println(userBean);

    return userBean;

}

4. 测试

我们在传参时，只传 country字段，通过响应结果可以看到提示了city 字段不能为空。 

可以看到使用了 @Valid 注解来对 Address 对象进行验证，这会触发对其中的 Address 对象的验证。通过这种方式，可以确保嵌套属性内部的对象也能够参与到整体对象的验证过程中，从而提高验证的完整性和准确性。

总结

本文介绍了@Valid注解和@Validated注解的不同，同时也进一步介绍了Springboot 参数校验的使用。不管是 JSR-303、JSR-380又或是 Hibernate Validator ，它们提供的参数校验注解都是有限的，实际工作中这些注解可能是不够用的，这个时候就需要我们自定义参数校验了。下篇文章将介绍一下如何自定义一个参数校验器。

一、什么是责任链模式？

责任链模式（Chain of Responsibility Pattern） 是一种行为设计模式，它允许将请求沿着一个处理链传递，直到链中的某个对象处理它。这样，发送者无需知道哪个对象将处理请求，所有的处理对象都可以尝试处理请求或将请求传递给链上的下一个对象。

核心思想：将请求的发送者与接收者解耦，通过让多个对象组成一条链，使得请求沿着链传递，直到被处理。

---

二、责任链模式的特点

1. 解耦请求发出者和处理者：请求的发送者不需要知道具体的处理者是谁，增强了系统的灵活性和扩展性。
2. 动态组合处理逻辑：可以根据需要动态改变链的结构，添加或移除处理者。
3. 职责单一：责任链模式可以将每个验证逻辑封装到一个独立的处理器中，每个处理器负责单一的验证职责，符合单一职责原则。
4. 可扩展性： 增加新的验证逻辑时，处理者只需继承一个统一的接口，并添加新的处理器，而不需要修改现有的代码。
5. 清晰的流程: 将所有验证逻辑组织在一起，使得代码结构更加清晰，易于理解。

---

三、责任链模式和策略模式结合的意义

• 责任链模式的作用：
  • 用于动态处理请求，将多个处理逻辑串联起来。
• 策略模式的作用：
  • 用于封装一组算法，使得可以在运行时动态选择需要的算法。

结合两者：

• 责任链模式负责串联和传递请求，而策略模式定义了每一个处理者的具体处理逻辑。
• 两者结合可以实现既动态构建责任链，又灵活应用不同策略来处理请求的需求。

---

四、责任链模式解决的问题

1. 耦合过高：将请求的处理者从请求的发送者中解耦，使得处理者可以独立扩展或变更。
2. 复杂的多条件判断：避免在代码中使用过多 if-else 或 switch-case 语句。
3. 灵活性不足：通过链的动态组合可以轻松调整请求的传递逻辑或插入新的处理者。
4. 代码重复：每个处理者只专注于处理它关心的部分，减少重复代码。

---

五、代码中的责任链模式解析

场景 1：商品上架逻辑（多重校验）

实现一个类似的场景——商品上架逻辑（如校验商品信息、库存信息等），可以按照以下步骤实现：

1. 定义责任链抽象接口

public interface MerchantAdminAbstractChainHandler extends Ordered {



    /**

     * 执行责任链逻辑

     *

     * @param requestParam 责任链执行入参

     */

    void handler(T requestParam);



    /**

     * @return 责任链组件标识

     */

    String mark();

}

2. 定义商品上架的责任链标识：

public enum ChainBizMarkEnum {

    MERCHANT_ADMIN_CREATE_PRODUCT_TEMPLATE_KEY,

    MERCHANT_ADMIN_PRODUCT_UPSHELF_KEY; // 新增商品上架责任链标识

}

3. 定义每个处理器的通用行为：

@Component

public final class MerchantAdminChainContext implements ApplicationContextAware, CommandLineRunner {

    /**

     * 应用上下文，通过Spring IOC获取Bean实例

     */

    private ApplicationContext applicationContext;



    /**

     * 保存商品上架责任链实现类

     * 


     * Key：{@link MerchantAdminAbstractChainHandler#mark()}

     * Val：{@link MerchantAdminAbstractChainHandler} 一组责任链实现 Spring Bean 集合

     * 


     * 比如有一个商品上架模板创建责任链，实例如下：

     * Key：MERCHANT_ADMIN_CREATE_PRODUCT_TEMPLATE_KEY

     * Val：

     * - 验证商品信息基本参数是否必填 —— 执行器  {@link ProductInfoNotNullChainFilter}

     * - 验证商品库存 —— 执行器 {@link ProductInventoryCheckChainFilter}

     */

    private final Map> abstractChainHandlerContainer = new HashMap<>();



    /**

     * 责任链组件执行

     * @param mark 责任链组件标识

     * @param requestObj 请求参数

     */

    public void handler(String mark,T requestObj){

        // 根据 mark 标识从责任链容器中获取一组责任链实现 Bean 集合

        List abstractChainHandlers = abstractChainHandlerContainer.get(mark);

        if (CollectionUtils.isEmpty(abstractChainHandlers)) {

            throw new RuntimeException(String.format("[%s] Chain of Responsibility ID is undefined.", mark));

        }

        abstractChainHandlers.forEach(each -> each.handler(requestObj));

    }



    /**

     * 执行方法，接收可变参数

     * 本方法主要用于初始化和处理商品上架抽象责任链容器

     * 它从Spring容器中获取所有MerchantAdminAbstractChainHandler类型的Bean，

     * 并根据它们的mark进行分类和排序，以便后续处理

     *

     * @param args 可变参数，可能包含方法运行所需的额外信息

     * @throws Exception 如果方法执行过程中遇到错误，抛出异常

     */

    @Override

    public void run(String... args) throws Exception {

        // 从 Spring IOC 容器中获取指定接口 Spring Bean 集合

        Map chainFilterMap = applicationContext.getBeansOfType(MerchantAdminAbstractChainHandler.class);

        // 遍历所有获取到的Bean，并将它们根据mark分类存入抽象责任链容器中

        chainFilterMap.forEach((beanName, bean) -> {

            // 判断 Mark 是否已经存在抽象责任链容器中，如果已经存在直接向集合新增；如果不存在，创建 Mark 和对应的集合

            List abstractChainHandlers = abstractChainHandlerContainer.getOrDefault(bean.mark(), new ArrayList<>());

            abstractChainHandlers.add(bean);

            abstractChainHandlerContainer.put(bean.mark(), abstractChainHandlers);

        });

        // 遍历抽象责任链容器，对每个 Mark 对应的责任链实现类集合进行排序

        abstractChainHandlerContainer.forEach((mark, chainHandlers) -> {

            // 对每个 Mark 对应的责任链实现类集合进行排序，优先级小的在前

            chainHandlers.sort(Comparator.comparing(Ordered::getOrder));

        });

    }



    @Override

    public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {

        this.applicationContext = applicationContext;

    }

}

4. 定义商品上架的责任链处理器：

@Component

public class ProductInfoNotNullChainFilter implements MerchantAdminAbstractChainHandler {

    @Override

    public void handler(ProductUpShelfReqDTO requestParam) {

        if (StringUtils.isEmpty(requestParam.getProductName())) {

            throw new RuntimeException("商品名称不能为空！");

        }

        if (requestParam.getPrice() == null || requestParam.getPrice() <= 0) {

            throw new RuntimeException("商品价格必须大于0！");

        }

        System.out.println("商品信息非空校验通过");

    }



    @Override

    public int getOrder() {

        return 1;

    }



    @Override

    public String mark() {

        return ChainBizMarkEnum.MERCHANT_ADMIN_PRODUCT_UPSHELF_KEY.name();

    }

}



@Component

public class ProductInventoryCheckChainFilter implements MerchantAdminAbstractChainHandler {

    @Override

    public void handler(ProductUpShelfReqDTO requestParam) {

        if (requestParam.getStock() <= 0) {

            throw new RuntimeException("商品库存不足，无法上架！");

        }

        System.out.println("商品库存校验通过");

    }



    @Override

    public int getOrder() {

        return 2;

    }



    @Override

    public String mark() {

        return ChainBizMarkEnum.MERCHANT_ADMIN_PRODUCT_UPSHELF_KEY.name();

    }

}

5. 调用责任链进行处理：

@Service

@RequiredArgsConstructor

public class ProductServiceImpl {

    private final MerchantAdminChainContext merchantAdminChainContext;



    public void upShelfProduct(ProductUpShelfReqDTO requestParam) {

        // 调用责任链进行校验

        merchantAdminChainContext.handler(

            ChainBizMarkEnum.MERCHANT_ADMIN_PRODUCT_UPSHELF_KEY.name(),

            requestParam

        );

        System.out.println("商品上架逻辑开始执行...");

        // 后续的商品上架业务逻辑

    }

}

上述代码实现了一个基于 责任链模式 的电商系统，主要用于处理复杂的业务逻辑，如商品上架模板的创建。这种模式的设计使得每个业务逻辑通过一个独立的处理器（Handler）进行处理，并将这些处理器串联成一个链，通过统一的入口执行每一步处理操作。

---

1. 代码的组成部分与职责解析

(1) 责任链抽象接口：MerchantAdminAbstractChainHandler

• 定义了责任链中的基础行为：
• void handler(T requestParam)
  • 定义了该处理器的具体逻辑。
  • 这是责任链的核心方法，每个处理器都会接收到传入的参数 requestParam，并根据具体的业务逻辑进行相应的处理。
• 设计思想：
  • T 是一个泛型参数，可以适配不同类型的业务场景（如对象校验、数据处理等）。
  • 如果某个处理器不满足条件，可以抛出异常或者提供返回值来中断后续处理器的运行。
  • 每个处理器只负责完成自己的一部分逻辑，保持模块化设计。

(2) 抽象处理器接口：MerchantAdminAbstractChainHandler

• 定义了责任链中每个节点的通用行为：
• void handler(T requestParam)
  • 责任链的核心方法，定义了如何处理传入的请求参数 requestParam。
  • 每个实现类都会根据具体的业务需求，在该方法中实现自己的处理逻辑，比如参数校验、数据转换等。
  • 如果某个处理环节中发生错误，可以通过抛出异常中断责任链的执行。
  • handler(T requestParam)：执行具体的处理逻辑。
  • mark()：返回处理器所属的责任链标识（Mark）。
• String mark()
  • 返回当前处理器所属的责任链标识（Mark）。
  • 不同的责任链可以通过 mark() 值进行分组管理。
  • 比如在商品上架创建责任链中，mark() 可以返回 MERCHANT_ADMIN_CREATE_PRODUCT_TEMPLATE_KEY。
• int getOrder()
  • 用于定义处理器的执行顺序。
  • 通过实现 Ordered 接口的 getOrder() 方法，开发者可以灵活地控制每个处理器在责任链中的执行顺序。
  • 默认值为 Ordered.LOWEST_PRECEDENCE（优先级最低），可以根据需求覆盖此方法返回更高的优先级（数值越小优先级越高）。
• 通过继承Ordered 接口来用于指定处理器的执行顺序，优先级小的会先执行。（模版如下）

import org.springframework.core.Ordered;



/**

 * 商家上架责任链处理器抽象接口

 * 

 * @param  处理参数的泛型类型（比如请求参数）

 */

public interface MerchantAdminAbstractChainHandler extends Ordered {



    /**

     * 执行责任链的具体逻辑

     *

     * @param requestParam 责任链执行的入参

     */

    void handler(T requestParam);



    /**

     * 获取责任链处理器的标识（mark）

     * 

     * 每个处理器所属的责任链标识需要唯一，用于区分不同的责任链。

     *

     * @return 责任链组件标识

     */

    String mark();



    /**

     * 获取责任链执行顺序

     * 

     * Spring 的 {@link Ordered} 接口方法，数值越小优先级越高。

     * 默认返回 `Ordered.LOWEST_PRECEDENCE`，表示优先级最低。

     *

     * @return 处理器的执行顺序。

     */

    @Override

    default int getOrder() {

        return Ordered.LOWEST_PRECEDENCE;

    }

}

(2) 责任链上下文：MerchantAdminChainContext

• 负责管理责任链的初始化和执行：
  • 在 Spring 容器启动时 (CommandLineRunner)，扫描实现了 MerchantAdminAbstractChainHandler 接口的所有 Spring Bean，并根据它们的 mark() 属性将它们归类到不同的链条中。
  • 在链条内部，根据 Ordered 的优先级对处理器进行排序。
  • 提供统一的 handler() 方法，根据标识 (Mark) 执行对应的责任链。

(3) 业务服务层：ProductInventoryCheckChainFilter

• 通过 MerchantAdminChainContext 调用对应的责任链，完成业务参数校验逻辑。
• 责任链完成校验后，后续可以继续执行其他具体的业务逻辑。

责任链的执行流程

通过 MerchantAdminChainContext，上述两个处理器会被自动扫描并加载到责任链中。运行时，根据 mark() 和 getOrder() 的值，系统自动按顺序执行它们。

五、Java 实现责任链模式 + 策略模式

以下是实现一个责任链 + 策略模式的完整 Java 示例。

场景：模拟用户请求的审核流程（如普通用户审批、管理员审批、高级管理员审批），并结合不同策略处理请求。

1. 定义处理请求的接口

// 抽象处理者接口

public interface RequestHandler {

    // 设置下一个处理者

    void setNextHandler(RequestHandler nextHandler);

    

    // 处理请求的方法

    void handleRequest(UserRequest request);

}

2. 定义用户请求类

// 请求类

public class UserRequest {

    private String userType; // 用户类型（普通用户、管理员等）

    private String requestContent; // 请求内容



    public UserRequest(String userType, String requestContent) {

        this.userType = userType;

        this.requestContent = requestContent;

    }



    public String getUserType() {

        return userType;

    }



    public String getRequestContent() {

        return requestContent;

    }

}

3. 定义不同的策略（处理逻辑）

// 策略接口

public interface RequestStrategy {

    void process(UserRequest request);

}



// 普通用户处理策略

public class BasicUserStrategy implements RequestStrategy {

    @Override

    public void process(UserRequest request) {

        System.out.println("普通用户的请求正在处理：" + request.getRequestContent());

    }

}



// 管理员处理策略

public class AdminUserStrategy implements RequestStrategy {

    @Override

    public void process(UserRequest request) {

        System.out.println("管理员的请求正在处理：" + request.getRequestContent());

    }

}



// 高级管理员处理策略

public class SuperAdminStrategy implements RequestStrategy {

    @Override

    public void process(UserRequest request) {

        System.out.println("高级管理员的请求正在处理：" + request.getRequestContent());

    }

}

4. 实现责任链模式的处理者

// 具体处理者，结合策略

public class RequestHandlerImpl implements RequestHandler {

    private RequestStrategy strategy; // 策略

    private RequestHandler nextHandler; // 下一个处理者



    public RequestHandlerImpl(RequestStrategy strategy) {

        this.strategy = strategy;

    }



    @Override

    public void setNextHandler(RequestHandler nextHandler) {

        this.nextHandler = nextHandler;

    }



    @Override

    public void handleRequest(UserRequest request) {

        // 策略处理

        strategy.process(request);

        // 将请求传递给下一个处理者

        if (nextHandler != null) {

            nextHandler.handleRequest(request);

        }

    }

}

5. 测试责任链 + 策略模式

public class ChainStrategyExample {

    public static void main(String[] args) {

        // 创建策略

        RequestStrategy basicStrategy = new BasicUserStrategy();

        RequestStrategy adminStrategy = new AdminUserStrategy();

        RequestStrategy superAdminStrategy = new SuperAdminStrategy();



        // 创建责任链处理者，并设置链条

        RequestHandler basicHandler = new RequestHandlerImpl(basicStrategy);

        RequestHandler adminHandler = new RequestHandlerImpl(adminStrategy);

        RequestHandler superAdminHandler = new RequestHandlerImpl(superAdminStrategy);



        basicHandler.setNextHandler(adminHandler);

        adminHandler.setNextHandler(superAdminHandler);



        // 模拟用户请求

        UserRequest basicRequest = new UserRequest("普通用户", "请求访问资源 A");

        UserRequest adminRequest = new UserRequest("管理员", "请求修改资源 B");

        UserRequest superAdminRequest = new UserRequest("高级管理员", "请求删除资源 C");



        // 处理请求

        System.out.println("处理普通用户请求：");

        basicHandler.handleRequest(basicRequest);



        System.out.println("\n处理管理员请求：");

        adminHandler.handleRequest(adminRequest);



        System.out.println("\n处理高级管理员请求：");

        superAdminHandler.handleRequest(superAdminRequest);

    }

}

---

六、为何责任链模式和策略模式结合使用？

1. 责任链控制流程，策略定义处理逻辑：
   • 责任链模式将处理请求的逻辑连接成链，便于动态调整请求传递的流程。
   • 策略模式将处理逻辑封装为独立的策略，可以灵活复用和替换。
2. 职责分离：
   • 责任链模式负责管理请求的传递，策略模式专注于实现具体的业务逻辑。
   • 结合使用可以让代码结构更清晰，职责分配更明确。
3. 增强灵活性和可扩展性：
   • 责任链可以动态增删处理者，策略可以动态选择或扩展新的处理逻辑，两者结合大大增强了系统的适配性和扩展性。

---

通过责任链模式与策略模式的结合，可以应对复杂的处理流程和多变的业务需求，同时保持代码的简洁与高内聚的设计结构。

作者：后端出路在何方
来源：juejin.cn/post/7457366224823124003

权限模型-ABAC模型

📝 ABAC 的概念

ABAC 的概念

ABAC（Attribute-Based Access Control）基于属性的访问控制的权限模型，是一种细粒度的权限控制模型，通过对请求中的各种属性进行分析和匹配，实现对权限的灵活的、动态的控制。

ABAC 的组成部分

1. 主体（Subject）: 发起访问资源请求的用户或实体（如应用程序、系统）。主体具有多种属性，例如角色、身份、部门、敏感级别、创建时间。

💡Tips: 实际中可能就是存储用户信息的记录表、发起请求的设备信息等。

2. 对象（Object）: 被访问的资源或数据。对象可以是文件、数据库表、API 接口等，同样具备多种属性，如文件名、文件类型、敏感级别、创建时间等。
3. 操作（Action）: 用户试图对资源的操作 ，例如”读”、“写”、“创建“、”删除“、”复制“等。
4. 环境（Environment）: 外部环境属性，如访问时间、地点、网络状态、安全级别等，用于动态调整访问策略。
5. 策略（Policy）: 定义允许或拒绝的访问的规则。策略基于主体、对象、操作和环境属性的组合，通过逻辑规则决定是否允许访问。

💡Tips: 策略如何定义？
一般来说 策略都有自己的语法设计，以 XML、JSON 这种形式去描述一个访问策略如何构成。 策略也是访问规则，本文中不再做区分。

ABAC 工作的基本原理

ABAC 的基本原理是：系统根据主体、对象、操作、环境的属性，以及预定义的策略，动态生成访问决策。

简单流程

1. 发起请求 : 通常一个访问请求由主体、对象（资源）、环境、操作中的一个或者多个组成。每个组成部分又有各自的属性，需要用到各个组成部分的属性，去动态构建一个访问规则。

   例如 中午 12 点后禁止 A 部门的人访问 B 系统这个访问规则。

   中午 12 点以后：环境（时间属性）

   A 部门的人：主体（身份属性）

   B 系统：对象（被访问的资源）

   访问: 操作

2. 匹配属性：在预设的访问规则库中查找与请求匹配的规则或规则集合。
3. 规则评估：根据匹配的访问规则中的具体规则来评估请求。将请求中的属性值与规则中的条件进行对比，判断请求是否满足规则中的条件。例如请求中包含了访问的时间在 12 点以后，那么访问控制系统就会对比访问时间这个属性值。
4. 返回结果：向用户返回最终的规则执行的结果。

💡Tips: 图中只是演示了一个大致的工作流程，实际要设计一个 ABAC 权限系统要复杂的多。

因为所有的规则条件是动态的、逻辑也是动态执行的。

ABAC的难点

试想以下场景：

• 当前文档是文档的拥有者且是拥有者才能编辑。
• 售卖的产品只能是上海地区的用户才能可见。
• 中午 12 点后禁止 A 部门的人访问 B 系统。

如果使用 RBAC 模型很难实现以上的需求。RBAC 是静态的权限模型，没有对象的属性动态参与计算的，所以很难实现以上场景。

ABAC 系统非常灵活但实现比较困难，

1.属性收集和管理复杂度

• 属性管理

  访问规则依赖属性和属性值去构建，特别是动态属性（实时位置，时间），如何确保获取到最新的属性值。

💡Tips: 属性是否可以动态增加也是构建系统的一部分，例如用户属性中你增加了一项职业，那该属性的值类型和获取该值的方法如何定义也是属性管理的一个难点。

• 数据一致性和同步

  分布式系统中，各种属性的数据源可能分散在不同的系统中，如何准确的、高效的获取该属性和属性值。

2.访问规则的复杂度

• 条件逻辑

  构建一个访问规则通常包含复杂的条件，条件可能是大于、小于、区间、地理位置等。这些条件需要仔细的定义和维护。

• 多条件组合

  访问规则需要涵盖不同属性的组合条件，属性组合的数量随着属性的增加呈指数型增长。

• 策略管理

  如果访问规则在数量一直增长，访问规则的生命周期（更新、删除）将变得复杂。如果其中属性的变动也会影响现有存在的访问规则。

• 动态性

  ABAC进行决策时需要实时评估所有相关属性的当前值，并与策略条件进行匹配。这种评估会增加计算的开销，尤其在处理大量请求时对计算资源要求更高。

3.透明性

• 可追溯性

  ABAC的动态决策过程复杂，审计和跟踪某个过程中的条件匹配和组合算法变得困难。为了便于审计和问题排查，ABAC 系统通常需要记录详细的决策日志，这增加了额外的复杂性。

• 决策透明度

  复杂的条件和组合逻辑使得管理员在排查和解释某个请求的决策较为困难，用户请求被拒绝可能难以理解其原因，这对系统性提出了挑战。

ABAC 的实现

标准实现-XACML

XACML 是一种基于 XML 的标准访问控制控制策略语言，用于定义和管理复杂的访问控制需求。

💡Tips: XACML 是 ABAC 的一个标准实现，用 XML 文件定义访问的策略集，然后提交 XACML 引擎来进行权限决策。由于这个太过复杂，这里不讲述了。有兴趣的可以看下官网XACML version 3.0。（当然还有其他标准的实现）

ABAC 的权限系统设计的核心

目前 ABAC 系统没有单独使用的，基本都是搭配RBAC （基于角色的权限模型）来使用。目前已有的类似方案如 AWS的 IAM （Identity And Access Management）也都是借鉴了 ABAC 的设计理念来实现的精细权限控制。

一个 ABAC 系统通常需要考虑以下核心的三个关键步骤：

1. 属性管理：属性的定义、结构和属性值的获取。
2. 访问规则：访问规则的结构化和语法定义。
3. 规则编辑器：规则编辑器和规则匹配引擎。

💡Tips: 目前这里探讨的设计因为没有具体的场景，这里的所说的设计权做参考。顺便一提属性管理、规则编辑器、访问规则其实设计的思路和CDP系统非常相似。

属性管理

属性有动态属性和静态属性，如性别那就是静态的，年龄、角色、地理位置这些都是动态的。

属性管理的难点是属性的定义和属性值获取。

• 属性的定义

  一般来说属性的定义包括属性名、字段类型、来源（获取该属性值的方式）。

  业务确认属性的范围，也就是说设计时确认了目前业务要用到哪些属性就不能进行更改（修改、删除）操作。如果是需要动态的进行属性的新增、修改就需要更抽象的灵活设计。

💡Tips: 如果其他的访问规则中使用了该属性，修改和删除都会影响使用该属性的访问规则。

• 属性值的获取

  属性和属性值的来源单一 例如用户的属性就一张用户表，那直接读取用户表就好了。如果你的用户数据是分散在不同来源的，需要考虑的如何聚合数据和保证数据一致性的问题。

访问规则

目前现在是有一些ABAC 的设计系统大多都是采用 JSON 语言描述访问规则。该 JSON 中包含了访问规则中所用到的属性、条件、操作等。示例如下：

{

  "subject": {

    "role": "manager",

    "department": "finance"

  },

  "object": {

    "type": "document",

    "sensitivity": "confidential"

  },

  "action": "view",

  "environment": {

    "ip": "192.168.1.*",

    "time": {

      "start": "09:00",

      "end": "18:00"

    }

  },

  "effect": "allow"

}

💡 实际开发中根据业务场景，系统中描述JSON 中的结构语义都有自己的规范。

规则编辑和规则匹配

ABAC 的核心部分是**如何构建一个规则编辑器和规则匹配引擎**，这个规则编辑器需要满足各种复杂条件的组合（这里的条件指的是一个条件或多个条件）。这里的条件之间的关系可能不止“且”的关系，可能还存在“或”。

一些地方描述构建规则为动态 SQL 的构建，但是这种方式需要对应的资源需要映射为数据库记录且有对应的属性存在表结构中，简单就是理解是宽表+属性。可有些属性是没办法在数据库结构中体现的如访问位置、访问时间等，这些就需要在规则匹配引擎中做设计了。

💡Tips: 目前所说的规则编辑和规则匹配都是为了动态 SQL 的构建，这块比较有通用性（有些数据权限设计采用的就是该种思路。）。至于其他方式需要考虑具体的业务环境。

规则编辑器通常都设计成管理界面，通过界面上选取中的属性和条件构成一个JSON ，然后提交到规则匹配引擎去执行，将JSON 转换成动态 SQL，发起访问请求时去拿到访问规则构建的SQL去执行。

💡Tips 这里的规则匹配引擎最主要的工作就是根据 JSON 中的描述的规则，动态生成一段 SQL。

总结

事实上 ABAC 现在没有什么标准建模，借鉴ABAC 的设计思维达到你想要的基于属性控制权限就可以了。至于采用何种方式、是否搭配其他权限模型，具体业务、具体分析。

作者：newrain_zh
来源：juejin.cn/post/7445219433017376780

其实调用第三方接口完成一个智能语音系统是非常简单的，像阿里、科大讯飞、微软都有相关接口，直接根据官方文档集成就可以，但想要离线的就要麻烦一点了，主要是想不花钱，现在人工智能基本是python的天下，不得不感慨，再不学python感觉自己要被淘汰了。

言归正传，首先说一下标题中的ASR+LLM+TTS，ASR就是语音识别，LLM就是大语言模型，TTS就是文字转语音，要想把这几个功能做好对电脑性能要求还是蛮高的，本次方案是一个新的尝试也是减少对性能的消耗

1.先看效果

生成的音频效果放百度网盘 通过网盘分享的文件：result.wav
链接: pan.baidu.com/s/19ImtqunH… 提取码: hm67
听完之后是不是感觉效果很好，但是。。。后面再说吧

2.如何做

2.1ASR功能

添加依赖

 <!-- 获取音频信息 -->

  <dependency>

     <groupId>org</groupId>

     <artifactId>jaudiotagger</artifactId>

     <version>2.0.3</version>

  </dependency>



<!-- 语音识别 -->

<dependency>

    <groupId>net.java.dev.jna</groupId>

    <artifactId>jna</artifactId>

    <version>5.7.0</version>

</dependency>

<dependency>

    <groupId>com.alphacephei</groupId>

    <artifactId>vosk</artifactId>

    <version>0.3.32</version>

</dependency>

代码实现，需要提前下载模型，去vosk官网下载：VOSK Models (alphacephei.com)中文模型一个大的一个小的，小的识别速度快准确率低，大的识别速度慢准确率高

提前预加载模型，提升识别速度

private static final Model model = loadModel();



private static Model loadModel() {

  try {

      String path=System.getProperty("user.dir");

      return new Model(path+"\vosk-model-small-cn-0.22");

  } catch (Exception e) {

      throw new RuntimeException("Failed to load model", e);

  }

}

语音转文字方法实现

public  String voiceToText(String filePath) {

    File file = new File(filePath);



    LibVosk.setLogLevel(LogLevel.DEBUG);

    String msg = null;

    int sampleRate = 0;

    RandomAccessFile rdf = null;

    /**

     * "r": 以只读方式打开。调用结果对象的任何 write 方法都将导致抛出 IOException。

     * "rw": 打开以便读取和写入。

     * "rws": 打开以便读取和写入。相对于 "rw"，"rws" 还要求对“文件的内容”或“元数据”的每个更新都同步写入到基础存储设备。

     * "rwd" : 打开以便读取和写入，相对于 "rw"，"rwd" 还要求对“文件的内容”的每个更新都同步写入到基础存储设备。

     */

    try {

        rdf = new RandomAccessFile(file, "r");

        sampleRate=toInt(read(rdf));

        System.out.println(file.getName() + " SampleRate:" + sampleRate);  // 采样率、音频采样级别 8000 = 8KHz

        rdf.close();

    } catch (FileNotFoundException e) {

        throw new RuntimeException(e);

    } catch (IOException e) {

        throw new RuntimeException(e);

    }

    try (

        InputStream ais = AudioSystem.getAudioInputStream(file);

        Recognizer recognizer = new Recognizer(model, 16000)) {

        int bytes;

        byte[] b = new byte[1024];

        while ((bytes = ais.read(b)) >= 0) {

            recognizer.acceptWaveForm(b, bytes);

        }

        String result=recognizer.getResult();

        JSONObject jsonObject = JSONObject.parseObject(result);

         msg=jsonObject.getString("text");

} catch (UnsupportedAudioFileException e) {

        throw new RuntimeException(e);

    } catch (IOException e) {

        throw new RuntimeException(e);

    }

    return msg;

}

2.2LLM问答功能

这个就要请出神奇的羊驼ollama（链接：Ollama），下载即用非常简单，可以运行大部分主流大语言模型，在官网models选择要加载的模型在控制台运行对应的命令即可

添加依赖

<dependency>

    <groupId>io.springboot.ai</groupId>

    <artifactId>spring-ai-ollama-spring-boot-starter</artifactId>

    <version>1.0.3</version>

</dependency>

加入配置

spring:

  ai:

    ollama:

      base-url: http://10.3.0.178:11434 //接口地址 默认端口11434

      chat:

        options:

          model: qwen2 //模型名称

        enabled: true

代码实现，引入OllamaChatClient，然后调用call方法

@Resource

private OllamaChatClient ollamaChatClient;

//msg为提问的信息

String ask=ollamaChatClient.call(msg);

2.3TTS功能

添加依赖

<dependency>

    <groupId>com.hynnet</groupId>

    <artifactId>jacob</artifactId>

    <version>1.18</version>

</dependency>

代码实现

public boolean localTextToSpeech(String text, int volume, int speed,String outPath) {

    try {

        // 调用dll朗读方法

        ActiveXComponent ax = new ActiveXComponent("Sapi.SpVoice");

        // 音量 0 - 100

        ax.setProperty("Volume", new Variant(volume));

        // 语音朗读速度 -10 到 +10

        ax.setProperty("Rate", new Variant(speed));

        // 输入的语言内容

        Dispatch dispatch = ax.getObject();

        // 本地执行朗读

//            Dispatch.call(dispatch, "Speak", new Variant(text));



        //开始生成语音文件，构建文件流

        ax = new ActiveXComponent("Sapi.SpFileStream");

        Dispatch sfFileStream = ax.getObject();

        //设置文件生成格式

        ax = new ActiveXComponent("Sapi.SpAudioFormat");

        Dispatch fileFormat = ax.getObject();

        // 设置音频流格式

        Dispatch.put(fileFormat, "Type", new Variant(22));

        // 设置文件输出流格式

        Dispatch.putRef(sfFileStream, "Format", fileFormat);

        // 调用输出文件流打开方法，创建一个音频文件

        Dispatch.call(sfFileStream, "Open", new Variant(outPath), new Variant(3), new Variant(true));

        // 设置声音对应输出流为输出文件对象

        Dispatch.putRef(dispatch, "AudioOutputStream", sfFileStream);

        // 设置音量

        Dispatch.put(dispatch, "Volume", new Variant(volume));

        // 设置速度

        Dispatch.put(dispatch, "Rate", new Variant(speed));

        // 执行朗读

        Dispatch.call(dispatch, "Speak", new Variant(text));

        // 关闭输出文件

        Dispatch.call(sfFileStream, "Close");

        Dispatch.putRef(dispatch, "AudioOutputStream", null);



        // 关闭资源

        sfFileStream.safeRelease();

        fileFormat.safeRelease();

        // 关闭朗读的操作

        dispatch.safeRelease();

        ax.safeRelease();

        return true;

    } catch (Exception e) {

        e.printStackTrace();

        return false;

    }

}

到此为止功能就全部实现了，在不联网的情况下也可以免费使用，但这个TTS生成出来的语音太机器了，所以在上面的示例中我说但是，因为机器音实在太难受了，所以用了另一个方案，但这个方案需要联网，暂时看是不需要收费（后续使用发现是有接口调用次数限制）
，这个大家就看原作者介绍吧（ikfly/java-tts: java-tts 文本转语音 (github.com)）

最终实现效果来看还是能接受的吧，整个过程速度还比较快，python的语音相关项目也看了很多，如果部署一个python的TTS服务，效果可能还会好点，但是我试过的速度都有点慢啊，还是容我再继续研究一下吧

背景

最近一两周在做从MySQL迁移到PostgreSQL的任务(新项目，历史包袱较小，所以迁移比较顺利), 感觉还是有一些知识，可以拿出来分享，希望对大家有所帮助。

为什么要转到PostgreSQL

因架构团队安全组安全需求，需要将Mysql迁移到PostgreSQL。实际迁移下来，发现PostgreSQL挺优秀的，比MySQL严谨很多，很不错。

迁移经验

引入PostgreSQL驱动，调整链接字符串

pagehelper方言调整

涉及order, group，name, status, type 等关键字，要用引号括起来

JSON字段及JsonTypeHandler

项目中用到了比较多的JSON字段。在mysql中，也有JSON字段类型，但是有时候我们用了varchar或text，在mybatis typehandler中是当成字符来处理的。但是在postgresql中，相对严谨，如果字段类型是json,那么在java中会被封装为PGObject，所以我们原来的JsonTypeHandler就要被改造。

/**

 * JSON类型处理器

 *

 * @author james.h.fu

 * @create 2024/10/9 20:45

 */

@Slf4j

public class JsonTypeHandler extends BaseTypeHandler {

    private static final ObjectMapper mapper = new ObjectMapper();



    static {

        mapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, Boolean.FALSE);

        mapper.setSerializationInclusion(JsonInclude.Include.NON_NULL);

    }



    private final Class clazz;

    private TypeReferenceextends T> typeReference;



    public JsonTypeHandler(Class clazz) {

        if (clazz == null) throw new IllegalArgumentException("Type argument cannot be null");

        this.clazz = clazz;

    }



    @Override

    public void setNonNullParameter(PreparedStatement ps, int i, T parameter, JdbcType jdbcType) throws SQLException {

        setObject(ps, i, parameter);

    }



    @Override

    public T getNullableResult(ResultSet rs, String columnName) throws SQLException {

        return toObject(rs, columnName);

    }



    @Override

    public T getNullableResult(ResultSet rs, int columnIndex) throws SQLException {

        return toObject(rs, columnIndex);

    }



    @Override

    public T getNullableResult(CallableStatement cs, int columnIndex) throws SQLException {

        return toObject(cs, columnIndex);

    }



    protected TypeReferenceextends T> getTypeReference() {

        return new TypeReference() {};

    }



    private String toJson(T object) {

        try {

            return mapper.writeValueAsString(object);

        } catch (Exception ex) {

            log.error("JsonTypeHandler error on toJson content:{}", JsonUtil.toJson(object), ex);

            throw new RuntimeException("JsonTypeHandler error on toJson", ex);

        }

    }



    private T toObject(String content) {

        if (!StringUtils.hasText(content)) {

            return null;

        }

        try {

            if (clazz.getName().equals("java.util.List")) {

                if (Objects.isNull(typeReference)) {

                    typeReference = getTypeReference();

                }

                return (T) mapper.readValue(content, typeReference);

            }

            return mapper.readValue(content, clazz);

        } catch (Exception ex) {

            log.error("JsonTypeHandler error on toObject content:{},class:{}", content, clazz.getName(), ex);

            throw new RuntimeException("JsonTypeHandler error on toObject", ex);

        }

    }



//    protected boolean isPostgre() {

//        SqlSessionFactory sqlSessionFactory = SpringUtil.getBean(SqlSessionFactory.class);

//        Configuration conf = sqlSessionFactory.getConfiguration();

//        DataSource dataSource = conf.getEnvironment().getDataSource();

//        try (Connection connection = dataSource.getConnection()) {

//            String url = connection.getMetaData().getURL();

//            return url.contains("postgresql");

//        } catch (SQLException e) {

//            throw new RuntimeException("Failed to determine database type", e);

//        }

//    }



    @SneakyThrows

    private void setObject(PreparedStatement ps, int i, T parameter) {

        PGobject jsonObject = new PGobject();

        jsonObject.setType("json");

        jsonObject.setValue(JsonUtil.toJson(parameter));

        ps.setObject(i, jsonObject);

    }



    @SneakyThrows

    private T toObject(ResultSet rs, String columnName) {

        Object object = rs.getObject(columnName);

        return toObject(object);

    }



    @SneakyThrows

    private T toObject(ResultSet rs, int columnIndex) {

        Object object = rs.getObject(columnIndex);

        return toObject(object);

    }



    @SneakyThrows

    private T toObject(CallableStatement rs, int columnIndex) {

        Object object = rs.getObject(columnIndex);

        return toObject(object);

    }



    public T toObject(Object object) {

        if (object instanceof String json) {

            return this.toObject(json);

        }

        if (object instanceof PGobject pgObject) {

            String json = pgObject.getValue();

            return this.toObject(json);

        }



        return null;

    }

}





    <result column="router_info" jdbcType="OTHER" property="routerInfo" typeHandler="***.cms.cmslib.mybatis.JsonTypeHandler"/>





<set>

<if test="routerInfo != null">

	router_info = #{routerInfo,typeHandler=***.cms.cmslib.mybatis.JsonTypeHandler}

  if>

set>

where id = #{id}

如果JSON中存储是的List, Map，Set等类型时, 会存在泛型类型中类型擦除的问题。因此，如果存在这种情况，我们需要扩展子类，在子类中提供详细的类型信息TypeReference。

/**

 * @author james.h.fu

 * @create 2024/12/9 20:45

 */

public class ComponentUpdateListJsonTypeHandler extends JsonTypeHandler> {

    public ComponentUpdateListJsonTypeHandler(Class<List<ComponentUpdate>> clazz) {

        super(clazz);

    }



    @Override

    protected TypeReference getTypeReference() {

        return new TypeReference<List<ComponentUpdate>>() {

        };

    }

}

4. pgsql不支持mysql insert ignore语法,  pgsql提供了类似的语法:

INSERT INTO orders (product_id, user_id)



VALUES (101, 202)



ON CONFLICT (product_id, user_id) DO NOTHING;

但是与mysql insert ignore并不完全等价,  关于这个点如何改造,  需要结合场景或者业务逻辑来斟酌定夺.

5. pgsql也不支持INSERT ... ON DUPLICATE KEY UPDATE,   如果代码中有使用这个语法,  pgsql提供了类似的语法:

INSERT INTO users (email, name, age)

VALUES ('test@example.com', 'John', 30)

ON CONFLICT (email)

DO UPDATE SET

name = EXCLUDED.name,

age = EXCLUDED.age;

EXCLUDED 是一个特殊的表别名，用于引用因冲突而被排除（Excluded）的、尝试插入的那条数据.

CONFLICT也可以直接面向唯一性约束.  假如users有一个唯一性约束: unique_email_constraint,  上述SQL可以改成:

INSERT INTO users (email, name, age)

VALUES ('test@example.com', 'John', 30)

ON CONFLICT ON CONSTRAINT unique_email_constraint

DO UPDATE SET

name = EXCLUDED.name,

age = EXCLUDED.age;

6. 分页：mysql的分页使用的是:   limit B(offset),A(count)， 但是pgsql不支持这种语法, pgsql支持的是如下两种:

(1)、limit A offset B; (2)、OFFSET B ROWS FETCH NEXT A ROWS ONLY;

7. pgsql查询区分大小写,  而mysql是不区分的
8. 其它情况 (1)、代码中存在取1个数据的场景，原来mysql写法是limit 0,1, 要调整为limit 1; (2)、在mysql中BIT(1)或tinyint（值0，1）可以转换为Boolean。但是在pgsql中不支持。需要明确使用boolean类型或INT类型, 或者使用typerhandler处理。

ALTER TABLE layout 

ALTER COLUMN init_instance TYPE INT2

USING CASE 

    WHEN init_instance = B'1' THEN 1

    WHEN init_instance = B'0' THEN 0

    ELSE NULL

END;



update component c

set init_instance = cp.init_instance 

from  component_publish cp 

where c.init_instance is null and c.id = cp.component_id ;

(3)、迁移数据后，统一将自增列修改

DO $$

DECLARE

    rec RECORD;

BEGIN

    FOR rec IN 

        SELECT 

            tc.sequencename

        FROM pg_sequences tc

    LOOP

        EXECUTE format('ALTER SEQUENCE %I RESTART WITH 100000', rec.sequencename);

        RAISE NOTICE 'Reset sequence % to 100000', rec.sequencename;

    END LOOP;

END $$;

总结

在日常开发中，我们一定要再严谨一些，规范编码。这样能让写我的代码质量更好，可移植性更高。

附录

在PostgreSQL 中，有哪些数据类型？

PostgreSQL 支持多种数据类型，下面列出一些常用的数据类型：

• 数值类型
  • smallint：2字节整数
  • integer：4字节整数
  • bigint：8字节整数
  • decimal 或 numeric：任意精度的数值
  • real：4字节浮点数
  • double precision：8字节浮点数
  • smallserial：2字节序列整数
  • serial：4字节序列整数
  • bigserial：8字节序列整数
• 字符与字符串类型
  • character varying(n) 或 varchar(n)：变长字符串，最大长度为n
  • character(n) 或 char(n)：定长字符串，长度为n
  • text：变长字符串，没有长度限制
• 日期/时间类型
  • date：存储日期（年月日）
  • time [ (p) ] [ without time zone ]：存储时间（时分秒），可指定精度p，默认不带时区
  • time [ (p) ] with time zone：存储时间（时分秒），可指定精度p，带时区
  • timestamp [ (p) ] [ without time zone ]：存储日期和时间，默认不带时区
  • timestamp [ (p) ] with time zone：存储日期和时间，带时区
  • interval：存储时间间隔
• 布尔类型
  • boolean：存储真或假值
• 二进制数据类型
  • bytea：存储二进制字符串
• 几何类型
  • point：二维坐标点
  • line：无限长直线
  • lseg：线段
  • box：矩形框
  • path：闭合路径或多边形
  • polygon：多边形
  • circle：圆
• 网络地址类型
  • cidr：存储IPv4或IPv6网络地址
  • inet：存储IPv4或IPv6主机地址和可选的CIDR掩码
  • macaddr：存储MAC地址
• 枚举类型
  • enum：用户定义的一组排序标签
• 位串类型
  • bit( [n] )：固定长度位串
  • bit varying( [n] )：变长位串
• JSON类型
  • json：存储JSON数据
  • jsonb：存储JSON数据，以二进制形式存储，并支持查询操作
• UUID类型
  • uuid：存储通用唯一标识符
• XML类型
  • xml：存储XML数据

这些数据类型可以满足大多数应用的需求。在创建表时，根据实际需要选择合适的数据类型是非常重要的。

在MyBatis中，jdbcType有哪些？

jdbcType 是 MyBatis 和其他 JDBC 相关框架中用于指定 Java 类型和 SQL 类型之间映射的属性。以下是常见的 jdbcType 值及其对应的 SQL 数据类型：

• NULL：表示 SQL NULL 类型
• VARCHAR：表示 SQL VARCHAR 或 VARCHAR2 类型
• CHAR：表示 SQL CHAR 类型
• NUMERIC：表示 SQL NUMERIC 类型
• DECIMAL：表示 SQL DECIMAL 类型
• BIT：表示 SQL BIT 类型
• TINYINT：表示 SQL TINYINT 类型
• SMALLINT：表示 SQL SMALLINT 类型
• INTEGER：表示 SQL INTEGER 类型
• BIGINT：表示 SQL BIGINT 类型
• REAL：表示 SQL REAL 类型
• FLOAT：表示 SQL FLOAT 类型
• DOUBLE：表示 SQL DOUBLE 类型
• DATE：表示 SQL DATE 类型（只包含日期部分）
• TIME：表示 SQL TIME 类型（只包含时间部分）
• TIMESTAMP：表示 SQL TIMESTAMP 类型（包含日期和时间部分）
• BLOB：表示 SQL BLOB 类型（二进制大对象）
• CLOB：表示 SQL CLOB 类型（字符大对象）
• ARRAY：表示 SQL ARRAY 类型
• DISTINCT：表示 SQL DISTINCT 类型
• STRUCT：表示 SQL STRUCT 类型
• REF：表示 SQL REF 类型
• DATALINK：表示 SQL DATALINK 类型
• BOOLEAN：表示 SQL BOOLEAN 类型
• ROWID：表示 SQL ROWID 类型
• LONGNVARCHAR：表示 SQL LONGNVARCHAR 类型
• NVARCHAR：表示 SQL NVARCHAR 类型
• NCHAR：表示 SQL NCHAR 类型
• NCLOB：表示 SQL NCLOB 类型
• SQLXML：表示 SQL XML 类型
• JAVA_OBJECT：表示 SQL JAVA_OBJECT 类型
• OTHER：表示 SQL OTHER 类型
• LONGVARBINARY：表示 SQL LONGVARBINARY 类型
• VARBINARY：表示 SQL VARBINARY 类型
• LONGVARCHAR：表示 SQL LONGVARCHAR 类型

在使用 MyBatis 或其他 JDBC 框架时，选择合适的 jdbcType 可以确保数据正确地在 Java 和数据库之间进行转换。

作者：Java分布式架构实战
来源：juejin.cn/post/7460410854775455794

Hello，大家好，今天我们来聊一下关于系统中的枚举是如何统一进行管理的。

业务场景

我们公司有这样的一个业务场景前端表单中 下拉选择的枚举值，是需要从后端获取的。那么这时候有个问题，我们不可能每次新增加一个枚举，都需要 改造获取枚举 的相关接口（getEnum），所以我们就需要对系统中的所有枚举类，进行统一的一个管理。

核心思路

为了解决这个问题，我们采用了如下的方案

相关实现

枚举定义

基于以上的思想，我们对枚举类定义了如下的规范，例如

@**IsEnum**

public enum BooleanEnum implements BaseEnums {

    YES("是", "1"),

    NO("否", "2")

            ;



    private String text;

    @EnumValue

    private String value;



    YesNoEnum(String text, String value) {

        this.text = text;

        this.value = value;

    }



    public String getText() {

        return text;

    }



    @Override

    public String getValue() {

        return value;

    }



    @Override

    public String toString() {

        return "YesNoEnum{" +

                "text='" + text + '\'' +

                ", value=" + value +

                '}';

    }



    @Override

    public EnumRequest toJson() {

        return new EnumRequest(value, text);

    }



    @JsonCreator

    public static YesNoEnum fromCode(String value) {

        for (YesNoEnum status : YesNoEnum.values()) {

            if (status.value.equals(value)) {

                return status;

            }

        }

        return null; // 或抛出异常

    }

}

注册发现

那么我们是如何实现服务的注册发现的呢？在这里主要是 使用了 SpringBoot 提供的接口CommandLineRunner （关于CommandLineRunner 可以参考这篇文章blog.csdn.net/python113/a…

在应用启动时，我们回去扫描 枚举所在的 包，通过 类上 是否包含 IsEnum 注解，判断是否需要对外暴露

 // 指定要扫描的包

        String basePackage = "com.xxx.enums";



        // 创建扫描器

        ClassPathScanningCandidateComponentProvider scanner =

                new ClassPathScanningCandidateComponentProvider(false);

        scanner.addIncludeFilter(new AnnotationTypeFilter(EnumMarker.class));



        // 扫描指定包

        Set<BeanDefinition> beans = scanner.findCandidateComponents(basePackage);



        // 注册枚举

        for (org.springframework.beans.factory.config.BeanDefinition beanDefinition : beans) {

            try {

                Class<?> enumClass = Class.forName(beanDefinition.getBeanClassName());

                if (Enum.class.isAssignableFrom(enumClass)) {

                    enumManager.registerEnum((Class<? extends Enum<?>>) enumClass);

                }

            } catch (ClassNotFoundException e) {

                e.printStackTrace();

            }

        }

ClassPathScanningCandidateComponentProvider 是 Spring 框架中的一个类，主要用于扫描指定路径下符合条件的候选组件（通常是 Bean 定义）。它允许我们在类路径中扫描并筛选符合特定条件（如标注特定注解、实现某接口等）的类，以实现自动化配置、依赖注入等功能。

典型用途

在基于注解的 Spring 应用中，我们可以使用它来动态扫描特定包路径下的类并注册成 Spring Bean。例如，Spring 扫描 @Component、@Service、@Repository 等注解标注的类时就会用到它。

主要方法

• addIncludeFilter(TypeFilter filter) ：添加一个包含过滤器，用于筛选扫描过程中包含的类。


• findCandidateComponents(String basePackage) ：扫描指定包路径下的候选组件（符合条件的类），并返回符合条件的 BeanDefinition 对象集合。


• addExcludeFilter(TypeFilter filter) ：添加一个排除过滤器，用于排除特定类。

最终呢，会将找到的枚举值，放在一个EnumManager中的一个Map集合中

 private final Map<Class<?>, List<Enum<?>>> enumMap = new HashMap<>(); // 类与枚举类型的映射关系

 private final Map<String, List<Enum<?>>> enumNameMap = new HashMap<>(); // 名称与枚举的映射管理

 public <E extends Enum<E>> void registerEnum(Class<? extends Enum<?>> enumClass) {

        Enum<?>[] enumConstants = enumClass.getEnumConstants();

        final List<Enum<?>> list = Arrays.asList(enumConstants);

        enumMap.put(enumClass, list);

        enumNameMap.put(enumClass.getSimpleName(), list); 

    }

enumClass.getEnumConstants() 是 Java 反射 API 中的一个方法，用于获取某个枚举类中定义的所有枚举实例。getEnumConstants() 会返回一个包含所有枚举常量的数组，每个元素都是该枚举类的一个实例。

这样子我们就可以通过枚举的名称或者class 获取枚举列表返回给前端

enumMap.get(enumClass); enumNameMap.get(enumName);

请求与响应

我们项目中使用的序列化器 是Jackson，通过 @JsonValue 与@JsonCreator两个注解实现的。

@JsonValue：对象序列化为json时会调用这个注解标记的方法

@JsonValue

public EnumRequest toJson() {

        return new EnumRequest(value, text);

    }

@JsonCreator ：json反序列化对象时会调用这个注解标记的方法

 @JsonCreator

    public static YesNoEnum fromCode(String value) {

        for (YesNoEnum status : YesNoEnum.values()) {

            if (status.value.equals(value)) {

                return status;

            }

        }

        return null; // 或抛出异常

    }

但是这里有个坑，我们SpringBoot的版本是2.5，使用 @JsonCreator 时会报错，这时候只需要降低jackson 的版本就可以了

 // 排除 spring-boot-starter-web 中的jsckson

 <dependency>

            <groupId>org.springframework.boot</groupId>

            <artifactId>spring-boot-starter-web</artifactId>

            <exclusions>

                <exclusion>

                    <groupId>com.fasterxml.jackson.core</groupId>

                    <artifactId>jackson-databind</artifactId>

                </exclusion>

                <exclusion>

                    <groupId>com.fasterxml.jackson.core</groupId>

                    <artifactId>jackson-core</artifactId>

                </exclusion>

                <exclusion>

                    <groupId>com.fasterxml.jackson.core</groupId>

                    <artifactId>jackson-annotations</artifactId>

                </exclusion>

            </exclusions>

        </dependency>

        

   <dependency>

            <groupId>com.fasterxml.jackson.core</groupId>

            <artifactId>jackson-databind</artifactId>

            <version>2.10.5</version>

        </dependency>

        <dependency>

            <groupId>com.fasterxml.jackson.core</groupId>

            <artifactId>jackson-core</artifactId>

            <version>2.10.5</version>

        </dependency>

        <dependency>

            <groupId>com.fasterxml.jackson.core</groupId>

            <artifactId>jackson-annotations</artifactId>

            <version>2.10.5</version>

        </dependency>      

Mybatis Plus 枚举中的使用

• 在applicaton.yml文件中添加如下参数

# 在控制台输出sql

mybatis-plus:

  type-enums-package: com.xxx.enums // 定义枚举的扫描包

• 将枚举值中 存入到数据库的字段 使用 @EnumValue注解进行标记，例如：上面提供的YesNoEnum 类中的value字段使用 @EnumValue 进行了标记 数据库中实际保存的就是 value 的值（1/2）


• 将domian 中 直接定义为枚举类型就可以了，是不是非常简单呢？

以上就是本篇文章的全部内容，如果有更好的方案欢迎小伙伴们评论区讨论！

【谈一谈】Redis是AP还是CP?

再说这个话题之前,这里的是AP和CP不是"A片"和"C骗"啊 !~哈哈哈,就离谱,博文后面我会解释下的

我说下自己对Redis的感觉,我一直很好奇Redis,不仅仅是当缓存用那么简单,包括的它的底层设计

所以,思考再三,我决定先从Redis基础开始写(基础是王道!~万丈高楼平地起,我米开始!~嘿嘿)

一、总纲图:

二、什么是CAP?

要想谈一谈我们本文的主题AP和CP,可能有的小伙伴会说: 这我也不是 怎么熟悉啊!

那么我们先复习下大名鼎鼎的CAP 理论

CAP理论

看下面的这张图,我们会发现CAP对应的三个单词【建议自己画画图,印象深刻】

C: 一致性(Consistency)--

• 每次读取都会收到最新的写入数据或者错误信息


• (注:这里面的一致性,指的是强一致性,不是市面上所说的所有节点在相同时间看到是一样的数据)

A:可用性(Availability)--

• 每个请求都会收到非错误地响应,但是这个响应的信息不保证是最新的 ,只保证可用

P:分区容错性(Partition Tolerance)--

• 就是网络节点间丢弃或者延迟一定数量(就是任意数量)信息,也不影响大局,系统还是能够正常运行

好了,我们言归正传,回到我们的主题上面

三、为啥说Redis是AP?不是CP?

我们知道,Redis是一个开源的内存数据库,且是执行单线程处理

但是网上,若是喜欢读博客的小伙伴,会发现很多人说这样一句话:

• 单机的Redis是CP的,集群的REDIS是AP的

这句话真的对吗? 大家在看下文前,倾思考思考!~我当时读到第一反应就是疑惑,于是我就去查询大量资料

有的人说:

1. CAP是针对分布式场景中,如果是单机REDIS,就压根儿和什么分布式不着边,都没 P了!!还说哈AP和 CP??


2. 在单机的REDIS中,应为只有一个实例,那么他的一致性是有保障的,如果这个节点挂了,就没有可用性可言了,所以他是CP系统

我在这里说下,以上两个观点都特么错的!!!以偏概全,混淆是非!~就是AP!!

~哈哈哈!你可能会说:我去,那你证明啊,这特么为啥是错的啊!,别急嘛!我们往下读,让你心服口服,嘿嘿

REDIS是AP的理由

第一点: 一致性

我们都知道,REDIS的设计目标是高性能,高扩展和高可用性 ,

而且REDIS的一致性模型是最终一致性:

(什么意思呢?)就是在某个时间点读取的数据可能不是最新的,但殊途同归,最终会达到一致的状态

为什么Redis无法保持强一致性??

主要原因: 异步复制

• 因为Redis在分布式的设计中采用的是异步复制,者导致在节点之间存在数据在同步和延迟不一致的情况存在


• 
  

  
  

  换句话说:

  
  

  
  
  • 当某个节点的数据发生改变,Redis会将这个节点的修改操作发送给其他节点进行同步~(这是正常步骤,没毛病是不,我们继续往下看)
  
  
  • 但是(不怕一万,就怕万一来了,哈哈哈)因为网络传输的延迟,拥塞等原因,这些操作没有立即被被其他节点收到和执行,
  
  
  • 从而产生节点之间数据不一致的情况!!!
  
  

  
  

  
  


• 
  

  
  

  抛开上面的影响点,节点故障对Redis的一致性影响也是很大的

  
  

  举个例子:

  
  

  当一个节点宕机时,这个节点的 数据就可能同步不到其他节点上,这就会导致数据在节点间不一致

  
  

  你可能有疑惑?那Redis不是有哨兵和复制等机制吗?

  
  

  但是,问题就是但是,哈哈~这些机制是能提高系统的可用性和容错性,能完全解决吗?

  
  

  ~(你没看错,就是完全解决,能吗??)不能吧,自己主观推下也能想到那种万一场景吧!!!

  
  

  
  

你说既然异步不行,那么我就用同步机制就不好了!!不就是CP了???

~~no!no!NO !哈哈哈,年轻人,想的太简单了哈!

我们看看官网是怎么说的()

• Redis客户端可以使用WAIT命令请求特定数据进行同步复制


• 使用WAIT,只能说发生故障时丢失写操作的概率会大大降低,且是在难以触发的故障模式情况下


• 但是!!


• 
  

  
  

  WAIT只能确保数据在Redis实例中有指定数量的副本被确认

  
  

  不能将一组REdis转换为具有强一制性的CP系统

  
  

  
  

• 
  

  
  

  什么意思?

  
  

  在故障转移期间,由于Redis的持久化配置,当中已确认的写操作,仍然可能会丢失

  
  

  
  

完结!~

士不可以不弘毅,任重而道远,诸君共勉!~

防重复提交

1、自定义防重复提交注解

/**

 * 自定义注解防止表单重复提交

 * 

 * @author ruoyi

 *

 */

@Inherited

@Target(ElementType.METHOD)

@Retention(RetentionPolicy.RUNTIME)

@Documented

public @interface RepeatSubmit

{

    /**

     * 间隔时间(ms)，小于此时间视为重复提交

     */

    public int interval() default 5000;



    /**

     * 提示消息

     */

    public String message() default "不允许重复提交，请稍候再试";

}

@Inherited：

该元注解表示如果一个类使用了这个 RepeatSubmit 注解，那么它的子类也会自动继承这个注解。这在某些需要对一组相关的控制器方法进行统一重复提交检查的场景下很有用，子类无需再次显式添加该注解。



@Target(ElementType.METHOD)：

表明这个注解只能应用在方法上。在实际应用中，通常会将其添加到控制器类的处理请求的方法上，比如 Spring MVC 的 @RequestMapping 注解修饰的方法。



@Retention(RetentionPolicy.RUNTIME)：

意味着该注解在运行时仍然存在，可以通过反射机制获取到。这样在运行时，通过 AOP（面向切面编程）等技术拦截方法调用时，就能够读取到注解的属性值，从而实现重复提交的检查逻辑。



@Documented：

这个元注解用于将注解包含在 JavaDoc 中。当生成项目文档时，使用了该注解的方法会在文档中显示该注解及其属性，方便其他开发者了解该方法具有防止重复提交的功能以及相关的配置参数。

    /**

     * 间隔时间(ms)，小于此时间视为重复提交

     */

    public int interval() default 5000;

定义了一个名为 interval 的属性，类型为 int，表示两次提交之间允许的最小时间间隔，单位是毫秒。默认值为 5000，即 5 秒。如果两次提交的时间间隔小于这个值，就会被视为重复提交。

    /**

     * 提示消息

     */

    public String message() default "不允许重复提交，请稍候再试";

定义了一个名为 message 的属性，类型为 String，用于在检测到重复提交时返回给客户端的提示消息。默认消息为 “不允许重复提交，请稍候再试”。开发者可以根据具体业务需求，在使用注解时自定义这个提示消息。

2、防止重复提交的抽象类

​ 抽象类可以自己有 具体方法

/**

 * 防止重复提交拦截器

 *

 * @author ruoyi

 */

@Component

public abstract class RepeatSubmitInterceptor implements HandlerInterceptor

{

    @Override

    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception

    {

        if (handler instanceof HandlerMethod)

        {

            HandlerMethod handlerMethod = (HandlerMethod) handler;

            Method method = handlerMethod.getMethod();

            RepeatSubmit annotation = method.getAnnotation(RepeatSubmit.class);

            if (annotation != null)

            {

                if (this.isRepeatSubmit(request, annotation))

                {

                    AjaxResult ajaxResult = AjaxResult.error(annotation.message());

                    ServletUtils.renderString(response, JSON.toJSONString(ajaxResult));

                    return false;

                }

            }

            return true;

        }

        else

        {

            return true;

        }

    }



    /**

     * 验证是否重复提交由子类实现具体的防重复提交的规则

     *

     * @param request 请求信息

     * @param annotation 防重复注解参数

     * @return 结果

     * @throws Exception

     */

    public abstract boolean isRepeatSubmit(HttpServletRequest request, RepeatSubmit annotation);

}

2.1、preHandle 方法

自定义抽象类拦截器 RepeatSubmitInterceptor 实现了 HandlerInterceptor 接口，重写 preHandle 方法

preHandle方法是负责拦截请求的

• 如果isRepeatSubmit方法返回true，表示当前请求是重复提交。此时会创建一个包含错误信息的AjaxResult对象，错误信息就是RepeatSubmit注解中设置的message。然后通过ServletUtils.renderString方法将AjaxResult对象转换为 JSON 字符串，并将其作为响应返回给客户端，同时返回false，阻止请求继续处理。


• 如果方法上不存在RepeatSubmit注解，或者isRepeatSubmit方法返回false，表示当前请求不是重复提交，就返回true，允许请求继续执行后续的处理流程。

@Override

    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception

    {

        if (handler instanceof HandlerMethod)

        {

            HandlerMethod handlerMethod = (HandlerMethod) handler;

            Method method = handlerMethod.getMethod();

            RepeatSubmit annotation = method.getAnnotation(RepeatSubmit.class);

            if (annotation != null)

            {

                if (this.isRepeatSubmit(request, annotation))

                {

                    AjaxResult ajaxResult = AjaxResult.error(annotation.message());

                    ServletUtils.renderString(response, JSON.toJSONString(ajaxResult));

                    return false;

                }

            }

            return true;

        }

        else

        {

            return true;

        }

    }

参数说明：

• HttpServletRequest request：提供了关于当前 HTTP 请求的信息，如请求头、请求参数、请求方法等。


• HttpServletResponse response：用于设置 HTTP 响应，例如设置响应头、响应状态码、写入响应内容等。


• Object handler：代表即将被执行的处理器对象，在 Spring MVC 中，它通常是一个 HandlerMethod，但也可能是其他类型。

方法解释：

 if (handler instanceof HandlerMethod)

        {

            HandlerMethod handlerMethod = (HandlerMethod) handler;

            Method method = handlerMethod.getMethod();

            RepeatSubmit annotation = method.getAnnotation(RepeatSubmit.class);

首先检查 handler 是否是 HandlerMethod 类型的 ， 不是的话，直接放行，不做重复提交检查， 因为该拦截器主要针对被 @RepeatSubmit 注解标记的方法进行处理。

如果 handler 是 HandlerMethod 类型的话，将 handler 转换成为 HandlerMethod 并获取对应的 Method 对象。

然后通过 getMethod（） 方法 获取 方法，并通过 getAnnotation 方法获取 RepeatSubmit 注解 ，

if (annotation != null) {

                if (this.isRepeatSubmit(request, annotation)) {

                    AjaxResult ajaxResult = AjaxResult.error(annotation.message());

                    ServletUtils.renderString(response, JSON.toJSONString(ajaxResult));

                    return false;

                }

            }

            return true;

判断是否获取到 RepeatSubmit 注解，没有获取到，返回 true ， 允许请求继续执行后续的处理流程。

运用 isRepeatSubmit 方法 判断是否是 重复提交

如果当前请求是重复提交 将注解的 错误信息 封装给结果映射对象

并调用 renderString 方法 将字符串渲染到客户端

    /**

     * 将字符串渲染到客户端

     * 

     * @param response 渲染对象

     * @param string 待渲染的字符串

     */

    public static void renderString(HttpServletResponse response, String string)

    {

        try

        {

            response.setStatus(200);

            response.setContentType("application/json");

            response.setCharacterEncoding("utf-8");

            response.getWriter().print(string);

        }

        catch (IOException e)

        {

            e.printStackTrace();

        }

    }

2.2、isRepeatSubmit 方法

判断是否重复提交 true 重复提交 false 不重复提交

    /**

     * 验证是否重复提交由子类实现具体的防重复提交的规则

     *

     * @param request 请求信息

     * @param annotation 防重复注解参数

     * @return 结果

     * @throws Exception

     */

    public abstract boolean isRepeatSubmit(HttpServletRequest request, RepeatSubmit annotation);

    public final String REPEAT_PARAMS = "repeatParams";



    public final String REPEAT_TIME = "repeatTime";



    // 令牌自定义标识

    @Value("${token.header}")

    private String header;   // token.header = "Authorization"



    @Autowired

    private RedisCache redisCache;	





	@SuppressWarnings("unchecked")

    @Override

    public boolean isRepeatSubmit(HttpServletRequest request, RepeatSubmit annotation)

    {

        String nowParams = "";

        if (request instanceof RepeatedlyRequestWrapper)

        {

            RepeatedlyRequestWrapper repeatedlyRequest = (RepeatedlyRequestWrapper) request;

            nowParams = HttpHelper.getBodyString(repeatedlyRequest);

        }



        // body参数为空，获取Parameter的数据

        if (StringUtils.isEmpty(nowParams))

        {

            nowParams = JSON.toJSONString(request.getParameterMap());

        }

        Map<String, Object> nowDataMap = new HashMap<String, Object>();

        nowDataMap.put(REPEAT_PARAMS, nowParams);

        nowDataMap.put(REPEAT_TIME, System.currentTimeMillis());



        // 请求地址（作为存放cache的key值）

        String url = request.getRequestURI();



        // 唯一值（没有消息头则使用请求地址）

        String submitKey = StringUtils.trimToEmpty(request.getHeader(header));



        // 唯一标识（指定key + url + 消息头）

        String cacheRepeatKey = CacheConstants.REPEAT_SUBMIT_KEY + url + submitKey;



        Object sessionObj = redisCache.getCacheObject(cacheRepeatKey);

        if (sessionObj != null)

        {

            Map<String, Object> sessionMap = (Map<String, Object>) sessionObj;

            if (sessionMap.containsKey(url))

            {

                Map<String, Object> preDataMap = (Map<String, Object>) sessionMap.get(url);

                if (compareParams(nowDataMap, preDataMap) && compareTime(nowDataMap, preDataMap, annotation.interval()))

                {

                    return true;

                }

            }

        }

        Map<String, Object> cacheMap = new HashMap<String, Object>();

        cacheMap.put(url, nowDataMap);

        redisCache.setCacheObject(cacheRepeatKey, cacheMap, annotation.interval(), TimeUnit.MILLISECONDS);

        return false;

    }

	@SuppressWarnings("unchecked")

注解 @SuppressWarnings("unchecked")： 这个注解用于抑制编译器的 “unchecked” 警告。在代码中，可能存在一些未经检查的类型转换操作，使用该注解可以告诉编译器忽略这些警告。

String nowParams = "";

初始化一个字符串变量 nowParams 用于存储当前请求的参数。

 if (request instanceof RepeatedlyRequestWrapper)

        {

            RepeatedlyRequestWrapper repeatedlyRequest = (RepeatedlyRequestWrapper) request;

            nowParams = HttpHelper.getBodyString(repeatedlyRequest);

        }

判断 当前请求是否是 RepeatedlyRequestWrapper 类型的

RepeatedlyRequestWrapper 是自定义的 允许多次请求的请求体 （详情见备注）

如果是的话，强转对象，并且 通过 getBodyString 方法 （详情见备注） 获取请求体的字符串内容，并且赋值给 nowParams

        // body参数为空，获取Parameter的数据

        if (StringUtils.isEmpty(nowParams))

        {

            nowParams = JSON.toJSONString(request.getParameterMap());

        }

        Map<String, Object> nowDataMap = new HashMap<String, Object>();

        nowDataMap.put(REPEAT_PARAMS, nowParams); //REPEAT_PARAMS = "repeatParams"

        nowDataMap.put(REPEAT_TIME, System.currentTimeMillis()); //REPEAT_TIME = "repeatTime"

if (StringUtils.isEmpty(nowParams))：如果通过上述方式获取的 nowParams 为空，说明请求体可能为空，此时通过 JSON.toJSONString(request.getParameterMap()) 将请求参数转换为 JSON 字符串，并赋值给 nowParams。这样无论请求参数是在请求体中还是在 URL 参数中，都能获取到。

• Map<String, Object> nowDataMap = new HashMap<String, Object>(); 创建一个新的 HashMap 用于存储当前请求的数据。


• nowDataMap.put(REPEAT_ PARAMS, nowParams); 将获取到的请求参数存入 nowDataMap 中，使用常量 REPEAT_PARAMS 作为键。


• nowDataMap.put(REPEAT_TIME, System.currentTimeMillis()); 将当前时间戳存入 nowDataMap 中，使用常量 REPEAT_TIME 作为键。

		// 请求地址（作为存放cache的key值）

        String url = request.getRequestURI();



        // 唯一值（没有消息头则使用请求地址）

        String submitKey = StringUtils.trimToEmpty(request.getHeader(header));



        // 唯一标识（指定key + url + 消息头）

        String cacheRepeatKey = CacheConstants.REPEAT_SUBMIT_KEY + url + submitKey;

																// REPEAT_SUBMIT_KEY = "repeat_submit:"