王不困的博客

rocketmq:...enhance:# 启动隔离，用于激活配置类EnvironmentIsolationConfig# 启动后会自动在topic上拼接激活的配置文件，达到自动隔离的效果# 隔离环境名称，拼接到topic后，topic_dev，默认空字符串。

高并发场景在现场的日常工作中很常见，特别是在互联网公司中，这篇文章就来通过秒杀商品来模拟高并发的场景。本文环境： SpringBoot 2.5.7 + MySQL 8.0 X + MybatisPlus + Swagger2.9.2模拟工具： Jmeter模拟场景： 减库存->创建订单->模拟支付。

安全性在REST API开发中扮演着重要的角色。一个不安全的REST API可以直接访问到后台系统中的敏感数据。因此，企业组织需要关注API安全性。

业务操作日志记录中包含了用户操作的功能名称、功能描述、操作人、操作时间和操作的参数报文，参数报文之所以选择存储在文件中，是因为正常情况下，是不需要知道具体的参数报文，只有在回滚操作的时候才会用到，可以根据上一次的参数报文逆向操作。

一、背景Spring的核心思想就是容器，当容器refresh的时候，外部看上去风平浪静，其实内部则是一片惊涛骇浪，汪洋一片。Springboot更是封装了Spring，遵循约定大于配置，加上自动装配的机制。很多时候我们只要引用了一个依赖，几乎是零配置就能完成一个功能的装配。我非常喜欢这种自动装配的机制，所以在自己开发中间件和公共依赖工具的时候也会用到这个特性。让使用者以最小的代价接入。想要把自动装配玩的转，就必须要了解spring对于bean的构造生命周期以及各个扩展接口。

一、背景公司有个渠道系统，专门对接三方渠道使用，没有什么业务逻辑，主要是转换报文和参数校验之类的工作，起着一个承上启下的作用。最近在优化接口的响应时间，优化了代码之后，但是时间还是达不到要求；有一个诡异的100ms左右的耗时问题，在接口中打印了请求处理时间后，和调用方的响应时间还有差了100ms左右。比如程序里记录150ms，但是调用方等待时间却为250ms左右。下面记录下当时详细的定位&解决流程（其实解决很简单，关键在于怎么定位并找到解决问题的方法）二、定位过程2.1 分析代码。

大家好，我是搬砖！在实际项目开发中我们经常需要对接口进行版本管理。那今天我们就来聊聊为什么需要版本控制，以及如何对REST API进行版本控制。我们将讨论4种版本控制的方法，并比较不同的方法。通过此文您将学到为什么我们需要对RESTful API 进行版本控制?可用的版本控制有哪些?如何实现基于 Restful 的版本控制?

在开发时可以将不带业务含义的格式校验注解放到 Bean 的类定义之上，将带业务逻辑的校验放到 Bean 的类定义的外面。业务规则校验指接口需要满足某些特定的业务规则，举个例子：业务系统的用户需要保证其唯一性，用户属性不能与其他用户产生冲突，不允许与数据库中任何已有用户的用户名称、手机号码、邮箱产生重复。这些约束规则不仅仅为这两个方法服务，它们可能会在用户资源中的其他入口被使用到，乃至在其他分层的代码中被使用到，在 Bean 上做校验就能全部覆盖上述这些使用场景。编辑用户时不能将信息修改成已有用户的属性。

对于互联网来说，只要你系统的接口暴露在外网，就避免不了接口安全问题。如果你的接口在外网裸奔，只要让黑客知道接口的地址和参数就可以调用，那简直就是灾难。举个例子：你的网站用户注册的时候，需要填写手机号，发送手机验证码，如果这个发送验证码的接口没有经过特殊安全处理，那这个短信接口早就被人盗刷不知道浪费多少钱了。那如何保证接口安全呢？一般来说，暴露在外网的api接口需要做到和才能称之为安全的接口。一.防篡改。

Annotation(注解)从JDK 1.5开始, Java增加了对元数据(MetaData)的支持，也就是 Annotation(注解)。注解其实就是代码里的特殊标记，它用于替代配置文件，常见的很多，有 @Override、@Deprecated等什么是元注解元注解是注解的注解，比如当我们需要自定义注解时会需要一些元注解（meta-annotation），如@Target和@Retentionjava内置4种元注解@Target 表示该注解用于什么地方。

一个标准的返回格式至少包含3部分：status 状态值：由后端统一定义各种返回结果的状态码message 描述：本次接口调用的结果描述data 数据：本次返回的数据。"message":"操作成功",当然也可以按需加入其他扩展值，比如我们就在返回对象中添加了接口调用时间4.timestamp: 接口调用时间@Data/** 结果状态 ,具体状态码参见ResultData.java*//**操作成功**/RC100(100,"操作成功"),/**操作失败**/

前面两篇文章我们介绍了如何在SpringBoot中使用Guava和Redis实现接口限流的文章。具体包括1.2.现在，一个问题摆在我们面前：如何将这两种限流机制整合到同一个组件中，以便用户随时切换呢？显然，我们需要定义一个通用的限流组件，将其引入到业务中，并支持通过配置文件自由切换不同的限流机制。举例而言，当使用时，启用Redis分布式限流组件，当使用时，启用Guava限流组件。这种自由切换机制能够为用户提供更大的灵活性和可维护性。接下来，让我们开始动手实现吧！

为什么需要对接口进行限流，也介绍了常见的限流算法，最后还基于Guava工具类实现了接口限流。但是这种方式有个问题，无法实现分布式限流。那今天我们来利用Redis + Lua 来实现分布式限流。Lua 脚本和 MySQL 数据库的存储过程比较相似，他们执行一组命令，所有命令的执行要么全部成功或者失败，以此达到原子性。也可以把 Lua 脚本理解为，一段具有业务逻辑的代码块。

因为互联网系统通常都要面对大并发大流量的请求，在突发情况下（最常见的场景就是秒杀、抢购），瞬时大流量会直接将系统打垮，无法对外提供服务。在完成优化后业务代码和限流代码解耦，开发人员只要一个注解，不用关心限流的实现逻辑，而且减少了代码冗余大大提高了代码可读性，代码评审时谁还敢再笑话你？，水先进入到漏桶里，漏桶里的水按一定速率流出，当流出的速率小于流入的速率时，由于漏桶容量有限，后续进入的水直接溢出（拒绝请求），以此实现限流。，业务代码和限流代码混在一起，而且明显违背了DRY原则，代码冗余，重复劳动。