你的浏览器禁用了JavaScript, 请开启后刷新浏览器获得更好的体验!

: 环信即时通讯云
单聊、群聊、聊天室...

: 环信开发文档

: 环信FAQ
集成常见问题及答案

: RTE开发者社区
汇聚音视频领域技术干货，分享行业资讯

: 技术讨论区
技术交流、答疑

: 资源下载
收集了海量宝藏开发资源

: iOS Library
不需要辛辛苦苦的去找轮子, 这里都有

: Android Library
不需要辛辛苦苦的去找轮子, 这里都有

什么是系统的鲁棒性？

综合技术讨论

嗨，你好啊，我是猿java 现实中，系统面临的异常情况和不确定性因素是不可避免的。例如，网络系统可能会遭受网络攻击、服务器宕机等问题；金融系统可能会受到市场波动、黑天鹅事件等因素的影响；自动驾驶系统可能会遇到天气恶劣、道路状况复杂等情况。在这些情况下，系统的...

继续阅读 »

嗨，你好啊，我是猿java

现实中，系统面临的异常情况和不确定性因素是不可避免的。例如，网络系统可能会遭受网络攻击、服务器宕机等问题；金融系统可能会受到市场波动、黑天鹅事件等因素的影响；自动驾驶系统可能会遇到天气恶劣、道路状况复杂等情况。

在这些情况下，系统的鲁棒性就显得尤为重要，它能够确保系统能够正确地处理各种异常情况，保持正常运行。因此，这篇文章我们将分析什么是系统的鲁棒性？如何保证系统的鲁棒性？

什么是系统的鲁棒性？

鲁棒性，英文为 Robustness，它是一个多学科的概念，涉及控制理论、计算机科学、工程学等领域。

在计算机领域，系统的鲁棒性是指系统在面对各种异常情况和不确定性因素时，仍能保持稳定运行和正常功能的能力。

鲁棒性是系统稳定性和可靠性的重要指标，一个具有良好鲁棒性的系统能够在遇到各种异常情况时做出正确的响应，不会因为某些异常情况而导致系统崩溃或失效。

鲁棒性要求系统在在遇到各种异常情况都能正常工作，各种异常很难具像化，这看起来是一种比较理想的情况，那么系统的鲁棒性该如何评估呢？

系统鲁棒性的评估

系统的鲁棒性可以从多个方面来考虑和评估，这里主要从三个方面进行评估：

首先，系统的设计和实现应该考虑到各种可能的异常情况，并采取相应的措施来应对

例如，在网络系统中，可以采用防火墙、入侵检测系统等技术来保护系统免受网络攻击；在金融系统中，可以采用风险管理技术来降低市场波动对系统的影响；在自动驾驶系统中，可以采用传感器融合、路径规划等技术来应对复杂的道路状况。

其次，系统在面临异常情况时应该具有自我修复和自我调整的能力

例如，当网络系统遭受攻击时，系统应该能够及时发现并隔离攻击源，同时自动恢复受影响的服务；当金融系统受到市场波动影响时，系统应该能够自动调整投资组合，降低风险；当自动驾驶系统面临复杂道路状况时，系统应该能够根据实时的道路情况调整行驶策略。

此外，系统的鲁棒性还包括对数据异常和不确定性的处理能力

在现实生活中，数据往往会存在各种异常情况，例如数据缺失、噪声数据等。系统应该能够对这些异常数据进行有效处理，保证系统的正常运行。同时，系统也应该能够对数据的不确定性进行有效处理，例如通过概率模型、蒙特卡洛方法等技术来处理数据不确定性，提高系统的鲁棒性。

鲁棒性的架构策略

对于系统的鲁棒性，有没有一些可以落地的策略？

如下图，展示了一些鲁棒性的常用策略，核心思想是：事前-事中-事后！

预防故障(事前)

对于技术人员来说，要有防范未然的意识，因此，对于系统故障要有预防措施，主要的策略包括：

代码质量：绝大部分软件系统是脱离不了代码，因此代码质量是预防故障很核心的一个前提。

脱离服务：脱离服务（Removal from service）这种策略指的是将系统元素临时置于脱机状态，以减轻潜在的系统故障。

替代：替代（Substitution）这种策略使用更安全的保护机制-通常是基于硬件的-用于被视为关键的软件设计特性。

事务：事务（Transactions）针对高可用性服务的系统利用事务语义来确保分布式元素之间交换的异步消息是原子的、一致的、隔离的和持久的。这四个属性被称为“ACID属性”。

预测模型：预测模型（Predictive model.）结合监控使用，用于监视系统进程的健康状态，以确保系统在其标称操作参数内运行，并在检测到预测未来故障的条件时采取纠正措施。

异常预防：异常预防（Exception prevention）这种策略指的是用于防止系统异常发生的技术。

中止：如果确定某个操作是不安全的，它将在造成损害之前被中止（Abort）。这种策略是确保系统安全失败的常见策略。

屏蔽：系统可以通过比较几个冗余的上游组件的结果，并在这些上游组件输出的一个或多个值不同时采用投票程序，来屏蔽（Masking）故障。

复盘：复盘是对事故的整体分析，发现问题的根本原因，查缺补漏，找到完善的方案。

检测故障(事中)

当故障发生时，在采取任何关于故障的行动之前，必须检测或预测故障的存在，故障检测策略主要包括：

监控：监控（Monitor）是用于监视系统的各个其他部分的健康状态的组件：处理器、进程、输入/输出、内存等等。

**Ping/echo：**Ping/echo是指在节点之间交换的异步请求/响应消息对，用于确定通过相关网络路径的可达性和往返延迟。

心跳：心跳（Heartbeat）是一种故障检测机制，它在系统监视器和被监视进程之间进行周期性的消息交换。

时间戳：时间戳（Timestamp）这种策略用于检测事件序列的不正确性，主要用于分布式消息传递系统。

条件监测：条件检测（Condition monitoring.）这种策略涉及检查进程或设备中的条件或验证设计过程中所做的假设。

合理性检查：合理性检查（Sanity checking）这种策略检查特定操作或计算结果的有效性或合理性。

投票：投票（Voting）这种策略的最常见实现被称为三模块冗余（或TMR），它使用三个执行相同操作的组件，每个组件接收相同的输入并将其输出转发给投票逻辑，用于检测三个输出状态之间的任何不一致。

异常检测：异常检测（Exception detection）这种策略用于检测改变执行正常流程的系统状态。

自检测：自检测（Self-test）要求元素（通常是整个子系统）可以运行程序来测试自身的正确运行。自检测程序可以由元素自身启动，或者由系统监视器不时调用。

故障恢复(事后)

故障恢复是指系统出现故障之后如何恢复工作。这是对团队应急能力的一个极大考验，如何在系统故障之后，将故障时间缩小到最短，将事故损失缩减到最小？这往往决定了一个平台，一个公司的声誉，决定了很多技术人员的去留。故障恢复的策略主要包括：

冗余备用：冗余备用（Redundant spare）有三种主要表现形式：主动冗余（热备用）、被动冗余（温备用）和备用（冷备用）。

回滚：回滚（Rollback）允许系统在检测到故障时回到先前已知良好状态，称为“回滚线”——回滚时间。

异常处理：异常处理（Exception handling）要求在检测到异常之后，系统必须以某种方式处理它。

软件升级：软件升级（Software upgrade）的目标是在不影响服务的情况下实现可执行代码映像的在线升级。

重试：重试（Retry）策略假定导致故障的故障是暂时的，重试操作可能会取得成功。

忽略故障行为：当系统确定那些消息是虚假的时，忽略故障行为（Ignore faulty behavior）要求忽略来自特定来源的消息。

优雅降级：优雅降级（Graceful degradation）这种策略在元素故障的情况下保持最关键的系统功能，放弃较不重要的功能。

重新配置：使用重新配置（Reconfiguration），系统尝试通过将责任重新分配给仍在运行的资源来从系统元素的故障中恢复，同时尽可能保持关键功能。

上述这些策略看起来很高大上，好像离你很远，但是其实很多公司都有对应的措施，比如：系统监控，系统告警，数据备份，分布式，服务器集群，多活，降级策略，熔断机制，复盘等等，这些术语应该就和我们的日常开发息息相关了。

总结

系统的鲁棒性是指系统在面对各种异常情况和不确定性因素时，仍能保持稳定运行和正常功能的能力。系统鲁棒性看似一个理想的状态，却是业界一直追求的终极目标，比如，系统稳定性如何做到 5个9（99.999%），甚至是 6个9（99.9999%），这就要求技术人员时刻保持工匠精神、在自己的本职工作上多走一步，只有在各个相关岗位的共同协作下，才能确保系统的鲁棒性。

学习交流

如果你觉得文章有帮助，请帮忙点个赞呗，关注公众号：猿java，持续输出硬核文章。

作者：猿java
来源：juejin.cn/post/7393312386571370536

收起阅读 »

身份认证的尽头竟然是无密码 ?

综合技术讨论

概述几乎所有的系统都会面临安全认证相关的问题，但是安全相关的问题是一个很麻烦的事情。因为它不产生直接的业务价值，而且处理起来复杂繁琐，所以很多时都容易被忽视。很多后期造成重大的安全隐患，往往都是前期的不重视造成的。但庆幸的是安全问题是普遍存在的，而且大家面临...

继续阅读 »

概述

几乎所有的系统都会面临安全认证相关的问题，但是安全相关的问题是一个很麻烦的事情。因为它不产生直接的业务价值，而且处理起来复杂繁琐，所以很多时都容易被忽视。很多后期造成重大的安全隐患，往往都是前期的不重视造成的。但庆幸的是安全问题是普遍存在的，而且大家面临的问题几乎相同，所以可以制定行业标准来规范处理，甚至是可以抽出专门的基础设施（例如：AD、LDAP 等）来专门解决这类共性的问题。总之，关于安全问题非常复杂而且麻烦，对于大多数 99% 的系统来说，不要想着在安全问题领域上搞发明和创新，容易踩坑。而且行业的标准解决方案已经非常成熟了。经过长时间的检验。所以在安全领域，踏踏实实的遵循规范和标准就是最好的安全设计。

HTTP 认证

HTTP 认证协议的最初是在 HTTP/1.1标准中定义的，后续由 IETF 在 RFC 7235 中进行完善。HTTP 协议的主要涉及两种的认证机制。

基本认证

常见的叫法是 HTTP Basic，是一种对于安全性不高，以演示为目的的简单的认证机制（例如你家路由器的登录界面），客户端用户名和密码进行 Base64 编码（注意是编码，不是加密）后，放入 HTTP 请求的头中。服务器在接收到请求后，解码这个字段来验证用户的身份。示例：

GET /some-protected-resource HTTP/1.1

Host: example.com

Authorization: Basic dXNlcjpwYXNzd29yZA==

虽然这种方式简单，但并不安全，因为 base64 编码很容易被解码。建议仅在 HTTPS 协议下使用，以确保安全性。

摘要认证

主要是为了解决 HTTP Basic 的安全问题，但是相对也更复杂一些，摘要认证使用 MD5 哈希函数对用户的密码进行加密，并结合一些盐值（可选）生成一个摘要值，然后将这个值放入请求头中。即使在传输过程中被截获，攻击者也无法直接从摘要中还原出用户的密码。示例：

GET /dir/index.html HTTP/1.1

Host: example.com

Authorization: Digest username="user", realm="example.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/dir/index.html", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41"

**补充：**另在 RFC 7235 规范中还定义当用户没有认证访问服务资源时应返回 401 Unauthorized 状态码，示例：

HTTP/1.1 401 Unauthorized

WWW-Authenticate: Basic realm="Restricted Area"

这一规范目前应用在所有的身份认证流程中，并且沿用至今。

Web 认证

表单认证

虽然 HTTP 有标准的认证协议，但目前实际场景中大多应用都还是基于表单认证实现，具体步骤是：

前端通过表单收集用户的账号和密码

通过协商的方式发送服务端进行验证的方式。

常见的表单认证页面通常如下：

html>

<html>

<head>

    <title>Login Pagetitle>

head>

<body>

    <h2>Login Formh2>

    <form action="/perform_login" method="post">

        <div class="container">

            <label for="username"><b>Usernameb>label>

            <input type="text" placeholder="Enter Username" name="username" required>

            

            <label for="password"><b>Passwordb>label>

            <input type="password" placeholder="Enter Password" name="password" required>

            

            <button type="submit">Loginbutton>

        div>

    form>

body>

html>

为什么表单认证会成为主流？主要有以下几点原因：

界面美化：开发者可以创建定制化的登录界面，可以与应用的整体设计风格保持一致。而 HTTP 认证通常会弹出一个很丑的模态对话框让用户输入凭证。

灵活性：可以在表单里面自定义更多的逻辑和流程，比如多因素认证、密码重置、记住我功能等。这些功能对于提高应用的安全性和便利性非常重要。

安全性：表单认证可以更容易地结合现代的安全实践，背后也有 OAuth 2 、Spring Security 等框架的主持。

表单认证传输内容和格式基本都是自定义本没啥规范可言。但是在 2019 年之后 web 认证开始发布标准的认证协议。

WebAuthn

WebAuthn 是一种彻底抛弃传统密码的认证，完全基于生物识别技术和实体密钥作为身份识别的凭证（有兴趣的小伙伴可以在 github 开启 Webauhtn 的 2FA 认证体验一下）。在 2019 年 3 月，W3C 正式发布了 WebAuthn 的第一版规范。

相比于传统的密码，WebAuthn 具有以下优势：

减少密码泄露：传统的用户名和密码登录容易受到钓鱼攻击和数据泄露的影响。WebAuthn，不依赖于密码，不存在密码丢失风险。

提高用户体验：用户不需要记住复杂的密码，通过使用生物识别等方式可以更快捷、更方便地登录。

多因素认证：WebAuthn 可以作为多因素认证过程中的一部分，进一步增强安全性。使用生物识别加上硬件密钥的方式进行认证，比短信验证码更安全。

总的来说，WebAuthn 是未来的身份认证方式，通过提供一个更安全、更方便的认证方式，目的是替代传统的基于密码的登录方法，从而解决了网络安全中的一些长期问题。WebAuthn 目前已经得到流程的浏览器厂商（Chrome、Firefox、Edge、Safari）、操作系统（WIndows、macOS、Linux）的广泛支持。

实现效果

当你的应用接入 WebAuthn 后，用户便可以通过生物识别设备进行认证，效果如下：

实现原理

WebAuthn 实现较为复杂，这里不做详细描述，具体可参看权威的官方文档，大概交互过程可以参考以下时序图：

登录流程大致可以分为以下步骤：

用户访问登录页面，填入用户名后即可点击登录按钮。

服务器返回随机字符串 Challenge、用户 UserID。

浏览器将 Challenge 和 UserID 转发给验证器。

验证器提示用户进行认证操作。

服务端接收到浏览器转发来的被私钥加密的 Challenge，以此前注册时存储的公钥进行解密，如果解密成功则宣告登录成功。

WebAuthn 采用非对称加密的公钥、私钥替代传统的密码，这是非常理想的认证方案，私钥是保密的，只有验证器需要知道它，连用户本人都不需要知道，也就没有人为泄漏的可能；

备注：你可以通过访问 webauthn.me 了解到更多消息的信息

文章不适合加入过多的演示代码，想要手上体验的可以参考 okta 官方给出基于 Java 17 和 Maven 构建的 webauthn 示例程序，如下：

访问地址：github.com/oktadev/web…

作者：肖卫卫讲编程
来源：juejin.cn/post/7354632375446061083

收起阅读 »

如何优雅的给SpringBoot部署的jar包瘦身？

Java

一、需求背景我们知道Spring Boot项目，是可以通过java -jar 包名启动的。那为什么Spring Boot项目可以通过上述命令启动，而其它普通的项目却不可以呢？原因在于我们在通过以下命令打包时 mvn clean package 一般的...

继续阅读 »

一、需求背景

我们知道Spring Boot项目，是可以通过java -jar 包名启动的。

那为什么Spring Boot项目可以通过上述命令启动，而其它普通的项目却不可以呢？

原因在于我们在通过以下命令打包时

mvn clean package

一般的maven项目的打包命令，不会把依赖的jar包也打包进去的，所以这样打出的包一般都很小

但Spring Boot项目的pom.xml文件中一般都会带有spring-boot-maven-plugin插件。

该插件的作用就是会将依赖的jar包全部打包进去。该文件包含了所有的依赖和资源文件。

也就会导致打出来的包比较大。

打完包就可以通过java -jar 包名启动,确实是方便了。

但当一个系统上线运行后，肯定会有需求迭代和Bug修复，那也就免不了进行重新打包部署。

我们可以想象一种场景，线上有一个紧急致命Bug,你也很快定位到了问题，就改一行代码的事情，当提交代码并完成构建打包并交付给运维。

因为打包的jar很大，一直处于上传中.......

如果你是老板肯定会发火，就改了一行代码却上传几百MB的文件,难道没有办法优化一下吗？

如今迭代发布是常有的事情，每次都上传一个如此庞大的文件，会浪费很多时间。

下面就以一个小项目为例，来演示如何瘦身。

二、瘦身原理

这里有一个最基础 SpringBoot 项目，整个项目代码就一个SpringBoot启动类，单是打包出来的jar就有20多M；

我们通过解压命令，看下jar的组成部分。

tar -zxvf spring-boot-maven-slim-1.0.0.jar

我们可以看出,解压出来的包有三个模块

分为 BOOT-INF，META-INF，org 三个部分

打开 BOOT-INF

classes: 当前项目编译好的代码是放在 classes 里面的,classes 部分是非常小的。

lib: 我们所依赖的 jar 包都是放在 lib 文件夹下,lib部分会很大。

看了这个结构我们该如何去瘦身呢？

项目虽然依赖会很多，但是当版本迭代稳定之后，依赖基本就不会再变动了。

如果可以把这些不变的依赖提前都放到服务器上，打包的时候忽略这些依赖，那么打出来的Jar包就会小很多，直接提升发版效率。

当然这样做你肯定有疑问？

既然打包的时候忽略这些依赖，那通过java -jar 包名还可以启动吗？

这种方式打的包，在项目启动时，需要通过-Dloader.path指定lib的路径,就可以正常启动

java -Dloader.path=./lib -jar xxx.jar

三、瘦身实例演示

1、依赖拆分配置

只需要在项目pom.xml文件中添加下面的配置：

 <build>

  <plugins>

   <plugin>

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

    <artifactId>spring-boot-maven-plugin</artifactId>

    <configuration>

     <executable>true</executable>

     <layout>ZIP</layout>

     <!--这里是填写需要包含进去的jar，

          必须项目中的某些模块，会经常变动，那么就应该将其坐标写进来

          如果没有则nothing ，表示不打包依赖 -->

     <includes>

      <include>

       <groupId>nothing</groupId>

       <artifactId>nothing</artifactId>

      </include>

     </includes>

    </configuration>

   </plugin>



   <!--拷贝依赖到jar外面的lib目录-->

   <plugin>

    <groupId>org.apache.maven.plugins</groupId>

    <artifactId>maven-dependency-plugin</artifactId>

    <executions>

     <execution>

      <id>copy</id>

      <phase>package</phase>

      <goals>

       <goal>copy-dependencies</goal>

      </goals>

      <configuration>

       <!--指定的依赖路径-->

       <outputDirectory>

        ${project.build.directory}/lib

       </outputDirectory>

      </configuration>

     </execution>

    </executions>

   </plugin>

  </plugins>

 </build>

再次打包

mvn clean package

发现target目录中多了个lib文件夹，里面保存了所有的依赖jar。

自己业务相关的jar也只有小小的168kb，相比之前20.2M，足足小了100多倍；

这种方式打的包，在项目启动时，需要通过-Dloader.path指定lib的路径：

java -Dloader.path=./lib -jar spring-boot-maven-slim-1.0.0.jar

虽然这样打包，三方依赖的大小并没有任何的改变，但有个很大的不同就是我们自己的业务包和依赖包分开了；

在不改变依赖的情况下，也就只需要第一次上传lib目录到服务器，后续业务的调整、bug修复，在没调整依赖的情况下，就只需要上传更新小小的业务包即可；

2、自己其它项目的依赖如何处理?

我们在做项目开发时，除了会引用第三方依赖，也会依赖自己公司的其它模块。

比如

这种依赖自己其它项目的工程，也是会经常变动的，所以不宜打到外部的lib，不然就会需要经常上传更新。

那怎么做了?

其实也很简单只需在上面的插件把你需要打进jar的填写进去就可以了

<plugin>

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

 <artifactId>spring-boot-maven-plugin</artifactId>

 <configuration>

  <executable>true</executable>

  <layout>ZIP</layout>

  <!--这里是填写需要包含进去的jar，如果没有则nothing -->

   <includes>

    <include>

     <groupId>com.jincou</groupId>

     <artifactId>xiaoxiao-util</artifactId>

    </include>

   </includes>

 </configuration>

</plugin>

这样只有include中所有添加依赖依然会打进当前业务包中。

四、总结

使用瘦身部署，你的业务包确实小了方便每次的迭代更新，不用每次都上传一个很大的 jar 包，从而节省部署时间。

但这种方式也有一个弊端就是增加了Jar包的管理成本，多人协调开发，构建的时候，还需要专门去关注是否有人更新依赖。

作者：二进制狂人
来源：juejin.cn/post/7260772691501301817

收起阅读 »

不使用代理，我是怎么访问Github的

综合技术讨论

背景最近更换了 windows系统的电脑， git clone 项目的时候会连接超时的错误，不管我怎么把环境变量放到终端里尝试走代理都无果，于是开始了排查以下命令是基于 git bash 终端使用的检测问题通过 ssh -T git@github....

继续阅读 »

背景

最近更换了 windows系统的电脑， git clone 项目的时候会连接超时的错误，不管我怎么把环境变量放到终端里尝试走代理都无果，于是开始了排查

以下命令是基于 git bash 终端使用的

检测问题

通过 ssh -T git@github.com 命令查看，会报如下错误：

ssh: connect to host github.com port 22: : Connection timed out

思索了一下，难道是端口的问题吗，于是从 overflow 上找到回答：

修改 ~/.ssh/config 路径下的内容，增加如下

Host github.com

 Hostname ssh.github.com

 Port 443

这段配置实际上是让 github.com 走 443 端口去执行，评论上有些说 22端口被占用，某些路由器或者其他程序会占用它，想了一下有道理，于是使用 vim ~/.ssh/config 编辑加上，结果...

ssh: connect to host github.com port 443: : Connection timed out

正当我苦苦思索，为什么 ping github.com 超时的时候，脑子里突然回忆起那道久违的八股文面试题： “url输入网址到浏览器上会发生什么"，突然顿悟：是不是DNS解析出了问题，找不到服务器地址？

网上学到一行命令，可以在终端里看DNS服务器的域名解析

nslookup baidu.com

先执行一下 baidu.com 的，得到如下：

Server:		119.6.6.6

Address:	119.6.6.6#53



Non-authoritative answer:

Name:	baidu.com

Address: 110.242.68.66

Name:	baidu.com

Address: 39.156.66.10

再执行一下 nslookup github.com ，果然发现不对劲了：

Name:	github.com

Address: 127.0.0.1

返回了 127.0.0.1，这不对啊，笔者可是读过书的，这是本地的 IP 地址啊，原来是这一步出了问题..

解决问题

大部分同学应该都改过本地的 DNS 域名映射文件，这也是上面那道八股文题中回答的知识点之一，我们打开资源管理器输入一下路径改一下：

C:\Windows\System32\drivers\etc\hosts

MacOs的同学可以在终端使用 sudo vi /etc/hosts 命令修改

在下面加上下面这一行，其中 140.82.113.4 是 github 的服务器地址，添加后就可以走本地的域名映射了

140.82.113.4 github.com

保存之后，就可以不使用代理，快乐访问 github.com 了，笔者顺利的完成了梦想第一步： git clone

结语

我是饮东，欢迎点赞关注，我们江湖再会

作者：饮东
来源：juejin.cn/post/7328112739335372810

收起阅读 »

简单聊聊使用lombok 的争议

Java

大家好，我是G探险者。项目里，因为我使用了Lombok插件，然后代码走查的时候被领导点名了。我心想，这么好用的插件，为啥不推广呢，整天写那些烦人的setter，getter方法就不嫌烦么？领导既然不让用，自然有他的道理。于是我查了一番关于lomb...

继续阅读 »

大家好，我是G探险者。

项目里，因为我使用了Lombok插件，然后代码走查的时候被领导点名了。

我心想，这么好用的插件，为啥不推广呢，整天写那些烦人的setter，getter方法就不嫌烦么？

领导既然不让用，自然有他的道理。

于是我查了一番关于lombok的一些绯闻。就有了这篇文章。

首先呢，Lombok 是一个在 Java 项目中广泛使用的库，旨在通过注解自动生成代码，如 getter 和 setter 方法，以减少重复代码并提高开发效率。然而，Lombok 的使用也带来了一些挑战和争议，特别是关于代码的可读性和与 Java Bean 规范的兼容性。

Lombok 基本使用

示例代码

不使用 Lombok:

public class User {

    private String name;

    private int age;



    public String getName() {

        return name;

    }



    public void setName(String name) {

        this.name = name;

    }



    // 其他 getter 和 setter

}

使用 Lombok:

import lombok.Data;



@Data

public class User {

    private String name;

    private int age;

    // 无需显式编写 getter 和 setter

}

Lombok 的争议

代码可读性和透明度：Lombok 自动生成的代码在源代码中不直接可见，可能对新开发者造成困扰。

工具和 IDE 支持：需要特定的插件或配置，可能引起兼容性问题。

与 Java Bean 规范的兼容性：Lombok 在处理属性命名时可能与 Java Bean 规范产生冲突，特别是在属性名以大写字母开头的情况。

下面我就列举一个例子进行说明。

属性命名的例子

假设有这么一个属性，aName;

标准 Java Bean 规范下：

属性 aName 的setter getter 方法应为 setaName() getaName()。

但是 Lombok 可能生成 getAName()。

这是因为Lombok 在生成getter和setter方法时，将属性名的首字母也大写，即使它是小写的。所以对于aName属性，Lombok生成的方法可能是getAName()和setAName()。

在处理JSON到Java对象的映射时，JSON解析库（如Jackson或Gson）会尝试根据Java Bean规范匹配JSON键和Java对象的属性。它通常期望属性名的首字母在getter和setter方法中是小写的。因此，如果JSON键为"aName"，解析库会寻找setaName()方法。

所以，当你使用Lombok的@Data注解，且Lombok生成的setter方法为setAName()时，JSON解析库可能找不到匹配的方法来设置aName属性，因为它寻找的是setaName()。

这种差异可能在 JSON 到 Java 对象的映射中引起问题。

Java Bean 命名规范

根据 Java Bean 规范，属性名应遵循驼峰式命名法：

单个单词的属性名应全部小写。

多个单词组成的属性名每个单词的首字母通常大写。

结论

Lombok 是一个有用的工具，可以提高编码效率并减少冗余代码。但是，在使用它时，团队需要考虑其对代码可读性、维护性和与 Java Bean 规范的兼容性。在决定是否使用 Lombok 时，项目的具体需求和团队的偏好应该是主要的考虑因素。

作者：G探险者
来源：juejin.cn/post/7310786611805863963

收起阅读 »

token是用来鉴权的，session是用来干什么的？

Java

使用JWT进行用户认证和授权，而Session在一定程度上起到了辅助作用。让我们详细讨论JWT和Session在这种结合模式中的各自作用以及为什么需要Session。 JWT的作用用户认证：JWT包含了用户的身份信息和权限信息，客户端每次请求时将JWT发...

继续阅读 »

使用JWT进行用户认证和授权，而Session在一定程度上起到了辅助作用。
让我们详细讨论JWT和Session在这种结合模式中的各自作用以及为什么需要Session。

JWT的作用

用户认证：JWT包含了用户的身份信息和权限信息，客户端每次请求时将JWT发送给服务器，服务器通过验证JWT来确认用户身份。

无状态性：JWT不需要在服务器端存储用户会话信息，因此服务器可以是无状态的，便于扩展和负载均衡。

Session的作用

附加的安全层：即使JWT是无状态的，但在某些应用场景中，仅依赖JWT可能存在一些安全问题，例如Token的泄露或滥用。Session可以作为一个额外的安全层，确保Token即使有效，也必须在服务器的Session管理器中存在对应的会话。

管理Token的生命周期：通过Session，可以更方便地管理Token的生命周期，例如强制用户重新登录、手动注销Token等操作。

控制“记住我”功能：如果用户选择了“记住我”选项，Session可以记录这个状态，并在JWT过期后，通过Session来决定是否允许继续使用旧的Token。

为什么需要创建Session

尽管JWT可以在无状态环境中使用，但Session的引入带来了以下好处：

防止Token滥用：通过在服务器端验证Session，可以确保即使Token有效，也必须是经过服务器端认证的，从而防止Token被恶意使用。

支持用户主动注销：当用户选择注销时，可以直接删除服务器端的Session记录，确保Token即使没有过期，也无法再被使用。

提供更精细的控制：通过Session，可以实现更精细的权限控制和用户状态管理，例如强制下线、会话过期时间控制等。

状态追踪：在某些场景下，追踪用户状态是必要的，例如监控用户的活跃度、登录历史等，这些信息可以通过Session进行管理。

结合JWT和Session的优势

结合使用JWT和Session，可以同时利用两者的优点，实现安全性和扩展性的平衡：

无状态认证：JWT可以实现无状态认证，便于系统的水平扩展和负载均衡。

状态管理和安全性：Session可以提供额外的状态管理和安全性，确保Token的使用更加安全可靠。

代码示例

以下是一个简化的代码示例，展示了如何在用户登录时创建JWT和Session：

java

Copy code

public LoginResponse login(String username, String password) throws AuthException {

    // 验证用户名和密码

    User user = userService.authenticate(username, password);

    if (user == null) {

        throw new AuthException("Invalid username or password");

    }

    

    // 生成JWT Token

    String token = createJwt(user.getId(), user.getRoles());

    

    // 创建会话

    sessionManagerApi.createSession(token, user);

    

    // 返回Token

    return new LoginResponse(token);

}



public void createSession(String token, User user) {

    LoginUser loginUser = new LoginUser();

    loginUser.setToken(token);

    loginUser.setUserId(user.getId());

    loginUser.setRoles(user.getRoles());

    

    sessionManagerApi.saveSession(token, loginUser);

}

在请求验证时，首先验证JWT的有效性，然后检查Session中是否存在对应的会话：

java

Copy code

@Override

public DefaultJwtPayload validateToken(String token) throws AuthException {

    try {

        // 1. 先校验jwt token本身是否有问题

        JwtContext.me().validateTokenWithException(token);



        // 2. 获取jwt的payload

        DefaultJwtPayload defaultPayload = JwtContext.me().getDefaultPayload(token);



        // 3. 如果是7天免登陆，则不校验session过期

        if (defaultPayload.getRememberMe()) {

            return defaultPayload;

        }



        // 4. 判断session里是否有这个token

        LoginUser session = sessionManagerApi.getSession(token);

        if (session == null) {

            throw new AuthException(AUTH_EXPIRED_ERROR);

        }



        return defaultPayload;

    } catch (JwtException jwtException) {

        if (JwtExceptionEnum.JWT_EXPIRED_ERROR.getErrorCode().equals(jwtException.getErrorCode())) {

            throw new AuthException(AUTH_EXPIRED_ERROR);

        } else {

            throw new AuthException(TOKEN_PARSE_ERROR);

        }

    } catch (io.jsonwebtoken.JwtException jwtSelfException) {

        throw new AuthException(TOKEN_PARSE_ERROR);

    }

}

总结

在这个场景中，JWT用于无状态的用户认证，提供便捷和扩展性；Session作为辅助，提供额外的安全性和状态管理。通过这种结合，可以充分利用两者的优点，确保系统既具备高扩展性，又能提供细致的安全控制。

作者：云原生melo荣
来源：juejin.cn/post/7383017171180568630

收起阅读 »

记一种不错的缓存设计思路

Java

之前与同事讨论接口性能问题时听他介绍了一种缓存设计思路，觉得不错，做个记录供以后参考。场景假设有个以下格式的接口： GET /api?keys={key1,key2,key3,...}&types={1,2,3,...} 其中 keys 是业务...

继续阅读 »

之前与同事讨论接口性能问题时听他介绍了一种缓存设计思路，觉得不错，做个记录供以后参考。

场景

假设有个以下格式的接口：

GET /api?keys={key1,key2,key3,...}&types={1,2,3,...}

其中 keys 是业务主键列表，types 是想要取到的信息的类型。

请求该接口需要返回业务主键列表对应的业务对象列表，对象里需要包含指定类型的信息。

业务主键可能的取值较多，千万量级，type 取值范围为 1-10，可以任意组合，每种 type 对应到数据库是 1-N 张表，示意：

现在设想这个接口遇到了性能瓶颈，打算添加 Redis 缓存来改善响应速度，应该如何设计？

设计思路

方案一：

最简单粗暴的方法是直接使用请求的所有参数作为缓存 key，请求的返回内容为 value。

方案二：

如果稍做一下思考，可能就会想到文首我提到的觉得不错的思路了：

使用 业务主键:表名 作为缓存 key，表名里对应的该业务主键的记录作为 value；

查询时，先根据查询参数 keys，以及 types 对应的表，得到所有 key1:tb_1_1、key1:tb_1_2 这样的组合，使用 Redis 的 mget 命令，批量取到所有缓存中存在的信息，剩下没有命中的，批量到数据库里查询到结果，并放入缓存；

在某个表的数据有更新时，只需刷新 涉及业务主键:该表名 的缓存，或令其失效即可。

小结

在以上两种方案之间做评估和选择，考虑几个方面：

缓存命中率；

缓存数量、占用空间大小；

刷新缓存是否方便；

稍作思考和计算，就会发现此场景下方案二的优势。

另外，就是需要根据实际业务场景，如业务对象复杂度、读写次数比等，来评估合适的缓存数据的粒度和层次，是对应到某一级组合后的业务对象（缓存值对应存储 + 部分逻辑），还是最基本的数据库表/字段（存储的归存储，逻辑的归逻辑）。

作者：mzlogin
来源：juejin.cn/post/7271597656118394899

收起阅读 »

这可能是开源界最好用的行为验证码工具

综合技术讨论

💂 个人网站: IT知识小屋 🤟 版权: 本文由【IT学习日记】原创、需要转载请联系博主 💬 如果文章对你有帮助、欢迎关注、点赞、收藏(一键三连)和订阅专栏哦写在前面大家好，这里是IT学习日记。今日推荐项目：tianai-captcha行为验证码工具...

继续阅读 »

💂 个人网站: IT知识小屋

🤟 版权: 本文由【IT学习日记】原创、需要转载请联系博主

💬 如果文章对你有帮助、欢迎关注、点赞、收藏(一键三连)和订阅专栏哦

写在前面

大家好，这里是IT学习日记。今日推荐项目：tianai-captcha行为验证码工具。

1000+优质开源项目推荐进度：6/1000。如需更多类型优质项目推荐，请在文章后留言。

工具简介

tianai-captcha行为验证码工具：分为 Go 和 Java 两个版本。支持多种验证方式，包括随机验证、曲线匹配、滑块验证、增强版滑块验证、旋转验证、滑动还原、角度验证、刮刮乐、文字点选、图标点选及语序点选等。

该系统能够快速集成到个人项目或系统中，显著提高开发效率。

功能展示

随机型验证码

曲线匹配验证码

滑动验证增强版验证码

滑块验证码

旋转验证码

滑动还原验证码

角度验验证码

刮刮乐验验证码

文字点选验证码

图标验证码

架构设计

tianai-captcha 验证码整体分为生成器(ImageCaptchaGenerator)、校验器(ImageCaptchaValidator)、资源管理器(ImageCaptchaResourceManager) 其中生成器、校验器、资源管理器等都是基于接口模式实现可插拔的，可以替换为自定义实现，灵活度高

生成器 (ImageCaptchaGenerator)

主要负责生成行为验证码所需的图片。

校验器 (ImageCaptchaValidator)

主要负责校验用户滑动的行为轨迹是否合规。

资源管理器 (ImageCaptchaResourceManager)

主要负责读取验证码背景图片和模板图片等。
- 资源存储 (ResourceStore)
  
  负责存储背景图和模板图。
- 资源提供者 (ResourceProvider)
  
  负责将资源存储器中对应的资源转换为文件流。一般资源存储器中存储的是图片的 URL 地址或 ID，资源提供者则负责将 URL 或其他 ID 转换为真正的图片文件。

图片转换器 (ImageTransform)

主要负责将图片文件流转换成字符串类型，可以是 Base64 格式、URL 或其他加密格式，默认实现为 Base64 格式。

工具集成

引入依赖

<!-- maven 导入 -->

<dependency>

    <groupId>cloud.tianai.captcha</groupId>

    <artifactId>tianai-captcha</artifactId>

    <version>1.4.1</version>

</dependency>

使用 ImageCaptchaGenerator生成器生成验证码

public class Test {

    public static void main(String[] args) throws InterruptedException {

        ImageCaptchaResourceManager imageCaptchaResourceManager = new DefaultImageCaptchaResourceManager();

        ImageTransform imageTransform = new Base64ImageTransform();

        ImageCaptchaGenerator imageCaptchaGenerator = new MultiImageCaptchaGenerator(imageCaptchaResourceManager,imageTransform).init(true);

        /*

                生成滑块验证码图片, 可选项

                SLIDER (滑块验证码)

                ROTATE (旋转验证码)

                CONCAT (滑动还原验证码)

                WORD_IMAGE_CLICK (文字点选验证码)



                更多验证码支持 详见 cloud.tianai.captcha.common.constant.CaptchaTypeConstant

         */

        ImageCaptchaInfo imageCaptchaInfo = imageCaptchaGenerator.generateCaptchaImage(CaptchaTypeConstant.SLIDER);

        System.out.println(imageCaptchaInfo);



        // 负责计算一些数据存到缓存中，用于校验使用

        // ImageCaptchaValidator负责校验用户滑动滑块是否正确和生成滑块的一些校验数据; 比如滑块到凹槽的百分比值

        ImageCaptchaValidator imageCaptchaValidator = new BasicCaptchaTrackValidator();

        // 这个map数据应该存到缓存中，校验的时候需要用到该数据

        Map<String, Object> map = imageCaptchaValidator.generateImageCaptchaValidData(imageCaptchaInfo);

    }

}

使用ImageCaptchaValidator校验器验证

public class Test2 {

    public static void main(String[] args) {

        BasicCaptchaTrackValidator sliderCaptchaValidator = new BasicCaptchaTrackValidator();



        ImageCaptchaTrack imageCaptchaTrack = null;

        Map<String, Object> map = null;

        Float percentage = null;

        // 用户传来的行为轨迹和进行校验

        // - imageCaptchaTrack为前端传来的滑动轨迹数据

        // - map 为生成验证码时缓存的map数据

        boolean check = sliderCaptchaValidator.valid(imageCaptchaTrack, map).isSuccess();

//        // 如果只想校验用户是否滑到指定凹槽即可，也可以使用

//        // - 参数1 用户传来的百分比数据

//        // - 参数2 生成滑块是真实的百分比数据

        check = sliderCaptchaValidator.checkPercentage(0.2f, percentage);

    }

}

工具获取

工具下载：gitee.com/dromara/tia…

在线体验：captcha.tianai.cloud/

如果这篇文章对您有帮助，请**“彦祖们”**一定帮我点个 “关注” 和 “点赞”,这对我非常重要。我将会继续推荐更多优质项目和新闻。

作者：IT学习日记v
来源：juejin.cn/post/7391351326153965568

收起阅读 »

java就能写爬虫还要python干嘛？

综合技术讨论

爬虫学得好，牢饭吃得饱！！！切记！！！相信大家多少都会接触过爬虫相关的需求吧，爬虫在绝大多数场景下，能够帮助客户自动的完成部分工作，极大的减少人工操作。目前更多的实现方案可能都是以python为实现基础，但是作为java程序员，咱们需要知道的是，以java...

继续阅读 »

爬虫学得好，牢饭吃得饱！！！切记！！！

相信大家多少都会接触过爬虫相关的需求吧，爬虫在绝大多数场景下，能够帮助客户自动的完成部分工作，极大的减少人工操作。目前更多的实现方案可能都是以python为实现基础，但是作为java程序员，咱们需要知道的是，以java 的方式，仍然可以很方便、快捷的实现爬虫。下面将会给大家介绍两种以java为基础的爬虫方案，同时提供案例供大家参考。

一、两种方案

传统的java实现爬虫方案，都是通过jsoup的方式，本文将采用一款封装好的框架【webmagic】进行实现。同时针对一些特殊的爬虫需求，将会采用【selenium-java】的进行实现，下面针对两种实现方案进行简单介绍和演示配置方式。

1.1 webmagic

官方文档：webmagic.io/

1.1.1 简介

使用webmagic开发爬虫，能够非常快速的实现简单且逻辑清晰的爬虫程序。

四大组件

Downloader：下载页面

PageProcessor：解析页面

Scheduler：负责管理待抓取的URL，以及一些去重的工作。通常不需要自己定制。

Pipeline：获取页面解析结果，数持久化。

Spider

启动爬虫，整合四大组件

1.1.2 整合springboot

webmagic分为核心包和扩展包两个部分，所以我们需要引入如下两个依赖：



<properties>

    <webmagic.version>0.7.5</webmagic.version>

</properties>



<!--WebMagic-->

<dependency>

    <groupId>us.codecraft</groupId>

    <artifactId>webmagic-core</artifactId>

    <version>${webmagic.version}</version>

</dependency>

<dependency>

    <groupId>us.codecraft</groupId>

    <artifactId>webmagic-extension</artifactId>

    <version>${webmagic.version}</version>

</dependency>

到此为止，我们就成功的将webmagic引入进来了，具体使用，将在后面的案例中详细介绍。

1.2 selenium-java

官网地址：http://www.selenium.dev/

1.2.1 简介

selenium是一款浏览器自动化工具，它能够模拟用户操作浏览器的交互。但前提是，我们需要在使用他的机器（windows/linux等）安装上它需要的配置。相比于webmigc的安装，它要繁琐的多了，但使用它的原因，就是为了解决一些webmagic做不到的事情。

支持多种语言：java、python、ruby、javascript等。其使用代码非常简单，以java为例如下：

package dev.selenium.hello;



import org.openqa.selenium.WebDriver;

import org.openqa.selenium.chrome.ChromeDriver;



public class HelloSelenium {

    public static void main(String[] args) {

        WebDriver driver = new ChromeDriver();



        driver.get("https://selenium.dev");



        driver.quit();

    }

}

1.2.2 安装

无论是在windows还是linux上使用selenium，都需要两个必要的组件：

浏览器（chrome）

浏览器驱动（chromeDriver）

需要注意的是，要确保上述两者的版本保持一致。

下载地址

chromeDriver：chromedriver.storage.googleapis.com/index.html

windows

windows的安装相对简单一些，将chromeDriver.exe下载至电脑，chrome浏览器直接官网下载相应安装包即可。严格保证两者版本一致，否则会报错。

在后面的演示程序当中，只需要通过代码指定chromeDriver的路径即可。

linux

linux安装才是我们真正的使用场景，java程序通常是要部署在linux环境的。所以我们需要linux的环境下安装chrome和chromeDriver才能实现想要的功能。

首先要做的是判断我们的linux环境属于哪种系统，是ubuntu、centos还是其他的种类，相应的shell脚本都是不同的。

我们采用云原生的环境，所有的服务均以容器的方式部署，所以要在每一个服务端容器内部安装chrome和chromeDiver。我们使用的是Alpine Linux，一个轻量级linux发行版，非常适合用来做Docker镜像。

我们可以通过apk --help去查看相应的命令，我直接给出安装命令：

# Install Chrome for Selenium

RUN apk add gconf

RUN apk add chromium

RUN apk add chromium-chromedriver

上面的内容，可以放在DockerFile文件中，在部署的时候，会直接将相应组件安装在容器当中。

需要注意的是，在Alpine Linux中自带的浏览器是chromium和chromium-chromedriver，且版本相应较低，但是足够我们的需求所使用了。

/ # apk search chromium

chromium-68.0.3440.75-r0

chromium-chromedriver-68.0.3440.75-r0

1.2.3 整合springboot

我们只需要在爬虫模块引入依赖就好了：

<dependency>

    <groupId>org.seleniumhq.selenium</groupId>

    <artifactId>selenium-java</artifactId>

</dependency>

二、三个案例

下面通过三个简单的案例，给大家实际展示使用效果。

2.1 爬取省份街道

使用webmagic进行省份到街道的数据爬取。注意，本文只提供思路，不提供具体爬取网站信息，请同学们自己根据使用选择。

接下来搭建webmagic的架子，其中有几个关键点：

创建页面解析类，实现PageProcessor。

import us.codecraft.webmagic.Page;

import us.codecraft.webmagic.Site;

import us.codecraft.webmagic.processor.PageProcessor;



/**

 * 页面解析

 *

 * @author wjbgn

 * @date 2023/8/15 17:25

 **/

public class TestPageProcessor implements PageProcessor {

    @Override

    public void process(Page page) {



    }



    @Override

    public Site getSite() {

        return site;

    }

    

    /**

     * 初始化Site配置

     */

    private Site site = Site.me()

            // 重试次数

            .setRetryTimes(3)

            //编码

            .setCharset(StandardCharsets.UTF_8.name())

            // 超时时间

            .setTimeOut(10000)

            // 休眠时间

            .setSleepTime(1000);

    }

实现PageProcessor后，要重写其方法process(Page page)，此方法是我们实现爬取的核心（页面解析）。通常省市区代码分为6级，所以常见的网站均是按照层级区分，我们是从省份开始爬取，即从第三层开始爬取。

初始化变量

@Override

public void process(Page page) {

    // 市级别

    Integer type = 3;

    // 初始化结果明细

    RegionCodeDTO regionCodeDTO = new RegionCodeDTO();

    // 带有父子关系的结果集合

    List<Map<String, Object>> list = new ArrayList();

    // 页面所有元素集合

    List<String> all = new ArrayList<>();

    // 页面中子页面的链接地址

    List<String> urlList = new ArrayList<>();

}

根据不同级别，获取相应页面不同的元素

if (CollectionUtil.isEmpty(all)) {

    // 爬取所有的市,编号，名称

    all = page.getHtml().css("table.citytable").css("tr").css("a", "text").all();

    // 爬取所有的城市下级地址

    urlList = page.getHtml().css("table.citytable").css("tr").css("a", "href").all()

            .stream().distinct().collect(Collectors.toList());

    if (CollectionUtil.isEmpty(all)) {

        // 区县级别

        type = 4;

        all = page.getHtml().css("table.countytable").css("tr.countytr").css("td", "text").all();

        // 获取区

        all.addAll(page.getHtml().css("table.countytable").css("tr.countytr").css("a", "text").all());



        urlList = page.getHtml().css("table.countytable").css("tr").css("a", "href").all()

                .stream().distinct().collect(Collectors.toList());

        if (CollectionUtil.isEmpty(all)) {

            // 街道级别

            type = 5;

            all = page.getHtml().css("table.towntable").css("tr").css("a", "text").all();

            urlList = page.getHtml().css("table.towntable").css("tr").css("a", "href").all()

                    .stream().distinct().collect(Collectors.toList());

            if (CollectionUtil.isEmpty(all)) {

                // 村，委员会

                type = 6;

                List<String> village = new ArrayList<>();

                all = page.getHtml().css("table").css("tr.villagetr").css("td", "text").all();

                for (int i = 0; i < all.size(); i++) {

                    if (i % 3 != 1) {

                        village.add(all.get(i));

                    }

                }

                all = village;

            }

        }

    }

}

定义一个实体类RegionCodeDTO，用来存放临时获取的code，url以及父子关系等内容：

public class RegionCodeDTO {



    private String code;



    private String parentCode;



    private String name;



    private Integer type;



    private String url;



    private List<RegionCodeDTO> regionCodeDTOS;

}

接下来对页面获取的内容（code、name、type）进行组装和临时存储，添加到children中：

// 初始化子集

List<RegionCodeDTO> children = new ArrayList<>();

// 初始化临时节点数据

RegionCodeDTO region = new RegionCodeDTO();

// 解析页面结果集all当中的数据，组装到region 和 children当中

for (int i = 0; i < all.size(); i++) {

    if (i % 2 == 0) {

        region.setCode(all.get(i));

    } else {

        region.setName(all.get(i));

    }

    if (StringUtils.isNotEmpty(region.getCode()) && StringUtils.isNotEmpty(region.getName())) {

        region.setType(type);

        // 添加子集到集合当中

        children.add(region);

        // 重新初始化

        region = new RegionCodeDTO();

    }

}

组装页面链接，并将页面链接组装到children当中。

// 循环遍历页面元素获取的子页面链接

for (int i = 0; i < urlList.size(); i++) {

    String url = null;

    if (StringUtils.isEmpty(urlList.get(0))) {

        continue;

    }

    // 拼接链接，页面的子链接是相对路径，需要手动拼接

    if (urlList.get(i).contains(provinceEnum.getCode() + "/")) {

        url = provinceEnum.getUrlPrefixNoCode();

    } else {

        url = provinceEnum.getUrlPrefix();

    }

    // 将链接放到临时数据子集对象中

    if (urlList.get(i).substring(urlList.get(i).lastIndexOf("/") + 1, urlList.get(i).indexOf(".html")).length() == 9) {

        children.get(i).setUrl(url + page.getUrl().toString().substring(page.getUrl().toString().indexOf(provinceEnum.getCode() + "/") + 3

                , page.getUrl().toString().lastIndexOf("/")) + "/" + urlList.get(i));

    } else {

        children.get(i).setUrl(url + urlList.get(i));

    }

}

将children添加到结果对象当中

// 将子集放到集合当中

regionCodeDTO.setRegionCodeDTOS(children);

在下面的代码当中将进行两件事儿：
- 处理下一页，通过page的addTargetRequests方法，可以进行下一页的跳转，此方法参数可以是listString和String，即支持多个页面跳转和单个页面的跳转。
- 将数据传递到Pipeline，用于数据的存储，Pipeline的实现将在后面具体说明。

// 定义下一页集合

List<String> nextPage = new ArrayList<>();

// 遍历上面的结果子集内容

regionCodeDTO.getRegionCodeDTOS().forEach(regionCodeDTO1 -> {

    // 组装下一页集合

    nextPage.add(regionCodeDTO1.getUrl());

    // 定义并组装结果数据

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

    map.put("regionCode", regionCodeDTO1.getCode());

    map.put("regionName", regionCodeDTO1.getName());

    map.put("regionType", regionCodeDTO1.getType());

    map.put("regionFullName", regionCodeDTO1.getName());

    map.put("regionLevel", regionCodeDTO1.getType());

    list.add(map);

    // 推送数据到pipeline

    page.putField("list", list);

});

// 添加下一页集合到page

page.addTargetRequests(nextPage);

当本次process方法执行完后，将会根据传递过来的链接地址，再次执行process方法，根据前面定义的读取页面元素流程的代码，将不符合type=3的内容，所以将会进入到下一级4的爬取过程，5、6级别原理相同。

创建Pipeline，用于编写数据持久化过程。经过上面的逻辑，已经将所需内容全部获取到，接下来将通过pipline进行数据存储。首先定义pipeline，并实现其process方法，获取结果内容，具体存储数据的代码就不展示了，需要注意的是，此处pipeline没有通过spring容器托管，需要调用业务service需要使用SpringUtils进行获取：

public class RegionDataPipeline implements Pipeline{





@Override

public void process(ResultItems resultItems, Task task) {

// 获取service

IXXXXXXXXXService service = SpringUtils.getBean(IXXXXXXXXXService.class);

// 获取内容

List<Map<String, String>> list = (List<Map<String, String>>) resultItems.getAll().get("list");

// 解析数据，转换为对应实体类

// service.saveBatch

}

启动爬虫

//启动爬虫

Spider.create(new RegionCodePageProcessor(provinceEnum))

        .addUrl(provinceEnum.getUrl())

        .addPipeline(new RegionDataPipeline())

        //此处不能小于2

        .thread(2).start()

2.2 爬取网站静态图片

爬取图片是最常见的需求，我们通常爬取的网站都是静态的网站，即爬取的内容都在网页上面渲染完成的，我们可以直接通过获取页面元素进行抓取。

可以参考下面的文章，直接拉取网站上的图片：juejin.cn/post/705138…

针对获取到的图片网络地址，直接使用如下方式进行下载即可：

url = new URL(imageUrl);

//打开连接

HttpURLConnection conn = (HttpURLConnection) url.openConnection();

//设置请求方式为"GET"

conn.setRequestMethod("GET");

//超时响应时间为10秒

conn.setConnectTimeout(10 * 1000);

//通过输入流获取图片数据

InputStream is = conn.getInputStream();

2.3 爬取网站动态图片

在2.2中我们可以很快地爬取到对应的图片，但是在另外两种场景下，我们获取图片将会不适用上面的方式：

需要拼图，且多层的gis相关图片，此种图片将会在后期进行复杂的图片处理（按位置拼接瓦片，多层png图层叠加），才能获取到我们想要的效果。

动态js加载的图片，直接无法通过css、xpath获取。

所以在这种情况下我们可以使用开篇介绍的selenium-java来解决，本文使用的仅仅是截图的功能，来达到我们需要的效果。具体街区全屏代码如下所示：

public File getItems() {

    // 获取当前操作系统

    String os = System.getProperty("os.name");

    String path;

    if (os.toLowerCase().startsWith("win")) {

        //windows系统

        path = "driver/chromedriver.exe";

    } else {

        //linux系统

        path = "/usr/bin/chromedriver";

    }

    WebDriver driver = null;

    // 通过判断 title 内容等待搜索页面加载完毕，间隔秒

    try {

        System.setProperty("webdriver.chrome.driver", path);

        ChromeOptions chromeOptions = new ChromeOptions();

        chromeOptions.addArguments("--headless");

        chromeOptions.addArguments("--no-sandbox");

        chromeOptions.addArguments("--disable-gpu");

        chromeOptions.addArguments("--window-size=940,820");

        driver = new ChromeDriver(chromeOptions);

        // 截图网站地址

        driver.get(UsaRiverConstant.OBSERVATION_POINT_URL);

        // 休眠用于网站加载

        Thread.sleep(15000);

        // 截取全屏

        File screenshotAs = ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE);

        return screenshotAs;

    } catch (Exception e) {

        throw new RuntimeException(e);

    } finally {

        driver.quit();

    }

}

如上所示，我们获取的是整个页面的图片，还需要对截取的图片进行相应的剪裁，保留我们需要的区域，如下所示：

public static void cutImg(InputStream inputStream, int x, int y, int width, int height, OutputStream outputStream) {//图片路径，截取位置坐标,输出新突破路径

    InputStream fis = inputStream;

    try {

        BufferedImage image = ImageIO.read(fis);

        //切割图片

        BufferedImage subImage = image.getSubimage(x, y, width, height);

        Graphics2D graphics2D = subImage.createGraphics();

        graphics2D.drawImage(subImage, 0, 0, null);

        graphics2D.dispose();

        //输出图片

        ImageIO.write(subImage, "png", outputStream);

    } catch (IOException e) {

        e.printStackTrace();

    } finally {

        try {

            fis.close();

        } catch (IOException e) {

            throw new RuntimeException(e);

        }

    }

}

三、小结

通过如上两个组件的简单介绍，足够应付在java领域的大多数爬取场景。从页面数据、到静态网站图片，在到动态网站的图片截取。本文以提供思路为主，原理请参考相应的官方文档。

爬虫学得好，牢饭吃得饱！！！切记！！！

作者：我犟不过你
来源：juejin.cn/post/7267532912617177129

收起阅读 »

原来Optional用起来这么清爽！

Java

前言大家好，我是捡田螺的小男孩。最近在项目中，看到一段很优雅的代码，用Optional 来判空的。我贴出来给大家看看： //遍历打印 userInfoList for (UserInfo userInfo : Optional.ofNullable(use...

继续阅读 »

前言

大家好，我是捡田螺的小男孩。

最近在项目中，看到一段很优雅的代码，用Optional 来判空的。我贴出来给大家看看：

//遍历打印 userInfoList

for (UserInfo userInfo : Optional.ofNullable(userInfoList)

.orElse(new ArrayList<>())) {

    //print userInfo

}

这段代码因为Optional的存在，优雅了很多，因为userInfoList可能为null，我们通常的做法，是先判断不为空，再遍历：

if (!CollectionUtils.isEmpty(userInfoList)) {

    for (UserInfo userInfo:userInfoList) {

      //print userInfo

    }

  }

显然，Optional让我们的判空更加优雅啦、

关注公众号：捡田螺的小男孩（很多后端干货文章）

1. 没有Optional，传统的判空?

如果只有上面这一个例子的话，大家会不会觉得有点意犹未尽呀。那行，田螺哥再来一个。

假设有一个订单信息类，它有个地址属性。

要获取订单地址的城市，会有这样的代码:

String city = orderInfo.getAddress().getCity();

这块代码会有啥问题呢？是的，可能报空指针问题！为了解决空指针问题，一般我们可以这样处理：

if (orderInfo != null) {

    Address address = orderInfo.getAddress();

    if (address != null) {

        String city = address.getCity();

    }

}

这种写法显然有点丑陋。为了更加优雅一点，我们可以使用Optional

     String city = Optional.ofNullable(orderInfo)

                .map(Order::getAddress)

                .map(Address::getCity)

                .orElseThrow(() ->

                new IllegalStateException("OrderInfo or Address is null"));

这样是不是优雅一点，好了这例子也介绍完了。你们知道，田螺哥很细的。当然，是指写文章很细哈

有些伙伴，可能第一眼看那个Optional优化后的代码有点生疏。因此，接下来，给介绍Optional相关API。

2. Optional API简介

2.1 ofNullable(T value)、empty()、of(T value)

因为我们上面的例子，使用到了 Optional.ofNullable(T value)，第一个函数就讲它啦。源码如下：

  public static <T> Optional<T> ofNullable(T value) {

        return value == null ? empty() : of(value);

    }

如果value为null，就返回 empty()，否则返回 of(value)函数。接下来，我们看Optional的empty() 和 of(value) 函数

public final class Optional<T> {



  private static final Optional<?> EMPTY =  new Optional<>();

    

  public static<T> Optional<T> empty() {

        @SuppressWarnings("unchecked")

        Optional<T> t = (Optional<T>) EMPTY;

        return t;

    }

显然， empty（）函数的作用就是返回EMPTY对象。

而of(value) 函数会返回Optional的构造函数

 public static <T> Optional<T> of(T value) {

    return new Optional<>(value);

 }

对于 Optional的构造函数：

private Optional(T value) {

    this.value = Objects.requireNonNull(value);

}



public static <T> T requireNonNull(T obj) {

  if (obj == null)

    throw new NullPointerException();

  return obj;

}

当value值为空时，会报NullPointerException。

当value值不为空时，能正常构造Optional对象。

2.2 orElseThrow(Supplier<? extends X> exceptionSupplier)、orElse(T other) 、orElseGet(Supplier<? extends T> other)

上面的例子，我们用到了orElseThrow

 .orElseThrow(() -> new IllegalStateException("OrderInfo or Address is null"));

那我们先来介绍一下它吧：

public final class Optional<T> {



  private final T value;

    

  public <X extends Throwable> T orElseThrow(Supplier<? extends X> exceptionSupplier) throws X {

    if (value != null) {

        return value;

    } else {

        throw exceptionSupplier.get();

    }

 }

很简单就是，如果value不为null，就返回value，否则，抛出函数式exceptionSupplier的异常。

一般情况，跟orElseThrow函数功能相似的还有orElse(T other) 和 orElseGet(Supplier<? extends T> other)

public T orElse(T other) {

    return value != null ? value : other;

}

对于orElse，如果value不为null，就返回value ，否则返回 other。

public T orElseGet(Supplier<? extends T> other) {

    return value != null ? value : other.get();

}

对于orElseGet，如果value不为null，就返回value ，否则返回执行函数式other后的结果。

2.3 map 和 flatMap

我们上面的例子，使用到了map(Function<? super T, ? extends U> mapper)

Optional.ofNullable(orderInfo)

                .map(Order::getAddress)

                .map(Address::getCity)

我们先来介绍一下它的：

  public<U> Optional<U> map(Function<? super T, ? extends U> mapper) {

        Objects.requireNonNull(mapper);

        if (!isPresent())

            return empty();

        else {

            return Optional.ofNullable(mapper.apply(value));

        }

    }



   public boolean isPresent() {

        return value != null;

    }

其实这段源码很简答，先是做个空值检查，接着就是value的存在性检查，最后就是应用函数并返回新的 Optional```

跟.map相似的，还有个flatMap，如下:

public<U> Optional<U> flatMap(Function<? super T, Optional<U>> mapper) {

        Objects.requireNonNull(mapper);

        if (!isPresent())

            return empty();

        else {

            return Objects.requireNonNull(mapper.apply(value));

        }

    }

可以发现，它两差别并不是很大，主要就是体现在入参所接受类型不一样。

2.4 isPresent 和ifPresent

我们在使用Optional的过程中呢，有些时候，会使用到isPresent和ifPresent，他们有点像，一个就是判断value值是否为空，另外一个就是判断value值是否为空，再去做一些操作。比如:

public void ifPresent(Consumer<? super T> consumer) {

  if (value != null)

    consumer.accept(value);

}

即判断value值是否为空，然后做一下函数式的操作。

举个例子，这段代码：

if(userInfo!=null){

    doBiz(userInfo);

}

用了isPresent 可以优化为：

 Optional.ofNullable(userInfo)

    .ifPresent(u->{

      doBiz(u);

});

优雅永不过时，嘻嘻~

作者：捡田螺的小男孩
来源：juejin.cn/post/7391065678546386953

收起阅读 »

我毕业俩月，就被安排设计了公司第一个负载均衡方案，真头大

系统设计

前言 Hi 你好，我是东东拿铁，一个正在探索个人IP&副业的后端程序员。今天我想和大家聊一段我自己毕业初期的一段经历，当领导给你安排了无从下手的任务，难以解决的技术问题时，该怎么办？本文会从我的一段经历出发，分析在初入职场、刚刚成为一个程序的时候，...

继续阅读 »

前言

Hi 你好，我是东东拿铁，一个正在探索个人IP&副业的后端程序员。

今天我想和大家聊一段我自己毕业初期的一段经历，当领导给你安排了无从下手的任务，难以解决的技术问题时，该怎么办？

本文会从我的一段经历出发，分析在初入职场、刚刚成为一个程序的时候，遇到自己无解决的问题，和自己的一些解决问题的思考。

如果你工作不满三年，一定要往下看，相信一定会对你有帮助。但如果你已经工作3年以上，那么你应该不会遇到下面的问题啦，但也欢迎你往下看，也许会有不同的收获。

先讲故事

每个人都有自己的职场新人期，这个阶段你会敏感、迷茫。

记得在毕业的2个月后，我的组长给我布置了一个任务，实现服务的热部署。

热部署是什么？

热部署是一种技术，它允许在应用程序运行时不中断地更新或替换软件组件，如代码或配置。这种技术主要应用于Web应用程序和分布式系统中，旨在减少停机时间，提高开发效率，并增强应用程序的可用性。

那时候我们的服务器是单实例，每次升级，一定要先停掉服务，替换war包，然后重启tomcat。想升级，必须要在半夜客户下班的时候升级。

作为一个职场小白，技术小白，第一次接到这种任务的时候，我整个人是一脸懵逼的。

那时候报错的堆栈信息我都看不懂，还得请教组里的同事，CRUD还没整明白呢。就要去解决这个架构问题，可想而知我那时候有多崩溃。

其实选择让我一个毕业2个月的应届生来做，能发现两个基本的背景

公司没有标准化的解决方案，没有人知道你的解决方案是否对错。

包括我的组长、组内老同事在内，也没有人了解如何在生产环境实现热部署，没人可以提供帮助。

因此在这件事的起步阶段，非常的困难。最重要的是，我还不会调研行业的标准方案是什么，刚毕业的我只能埋头苦干，不断试错。

持续的没有进展，也让我内心非常焦虑。多次周会上被问及这件事情，也完全不知道如何汇报进展，因为我自己也不知道，到底什么时候能解决。

记得那时候上厕所、接水的时候，我都是低头不语，装作看不见，生怕他问我一句：“那件事情的进度怎么样了？”

现在想起自己那时候的无助和不安，我都会微微一笑。

很庆幸是在计算机行业，即使是用百度，也能够搜到大把的信息，那段时间也了解到了像Nginx、Redis这样的中间件，最终也是用Nginx，实现了最基本的目标，可以在保证客户使用的情况下，正常的升级我们的系统了。

是的，毕业后的第一家公司的负载均衡和不停机服务发布，是由一个小小毕业生来做的，前期内心有多煎熬，上线的那一刻就有多自豪。

故事讲完了，我相信很多职场人，都会面临这样的场景吧，或许是一个功能不知道怎么去实现，又或者一个方案不知道如何去设计，不敢面对，不敢说出来。

为什么会这样

在职场中，我们大概可以用四个阶段概括

新人期

发展期

成熟期

衰退期

上面我自己的一小段经历，遇到了新人期中最容易面临的问题，技能上的迷茫，和职场上的迷茫。

技能上的迷茫

我们可能发现自己有好多东西不会，什么都要学，却不知道自己该如何入手。

在大厂里，周围人看起来都是大牛，可以看着他们侃侃而谈，虽然自己只能茫然四顾，但起码有着标杆和榜样。

而在普通传统行业，身边连个会的人都没有，自己的摸索更像是盲人摸象。

职场上的迷茫

不知道事情该办成什么样，领导会不会不满意，对我的考核会不会有影响。

又或者主动说了有困难，领导会不会觉得我能力不足？

面对多重困难，我该如何汇报自己的进度？没有进度怎么办。

思考、建立正确的认知

界定问题，比问题本身要重要

技术日新月异，新技术是学不完的，解决问题的方式更是多种多样的。所有成熟的方案，都不是一蹴而就的，而是通过发现问题、解决问题一步步优化完善来的。

所以我们有一个清晰的认知，我们很难得到最优的解决方案，而是把注意力放在问题本身，看看我们到底要解决什么问题。

例如我一开始不知道热部署的含义，但我知道的是，公司想解决服务的不停机升级问题。那么我最终引入了Nginx，通过反向代理，部署多个服务就好了。提供的解决方案，完成了预期，我认为对于一个新人来讲就是合格的。

PS：事实上我在使用了Nginx完成了负载均衡后，我的组长曾和我说，你这个方案感觉不太行，不是领导想要的效果。但点到为止了，也没有什么指导，或者改进措施，最终也用这个方案在生产去部署。

注重当下

职场规则是明确的，可以在员工手册、职级要求中看到。但职场中的潜规则是不明确的，你无法摸清领导最真实的想法。

为什么这么说呢？

领导可能就是想历练你，给你有挑战的事情，想看看你做到什么程度，你的能力边界在哪里

领导对你的预期就是能够解决，也不需要他的指导

不同的想法，对你的要求截然不同。

历练你的时候，即使事情没有结果，领导也不会多说什么，或许这就是一个当下受限于公司运维、资源而难以做到的事情。

但领导相信你能够解决问题的时候，你必须要尽量完成，不然确实会影响到对你的一些看法。

对于职场新手期，你短时间内是无法建立一个良好的向上沟通渠道的（如何建立向上沟通渠道，我们后面再说）。所以对你而言，与其揣摩想法，不如界定好问题，然后注重当下，解决好遇到的每一个困难。

两个方法

目标拆分

有一个关于程序员的经典段子：这个工作已经做完了80%，剩下的**20%**还要用和前面的一样时间。

遇到无从下手，不知如何去解决的问题，是怎么给出一个可执行的分解。

重点来了，拆分的，一定要可执行。每个人对于可执行的区分，是有很大不同的。不同的地方在于可执行的定义，你是否能清楚地知道这个问题该如何解决。

比如文章开头的故事，如果时间回到那一刻，我会这么列出计划

了解什么是热部署，方案调研

了解Nginx是什么，学会使用基本的命令

多个服务之间如何同步信息，比如上一秒在A服务，下一秒在B服务

进行验证，线上部署

学会借力

手里有把锤子,看见什么都是钉子。

我们更倾向于用我们手里的某种工具，去解决所有问题。

在遇到问题时，我们的大脑会根据以往经验做出预判，从而形成思维定势，使得我们倾向于使用熟悉的工具或方法来解决问题。然而，并不是所有问题都是钉子，一旦碰到超出我们经验边界的事情，我们可能会束手无策。

还是分享一段经历：

在字节的时候，我遇到过一个问题场景，就是如何保证集群服务器的本地缓存，保持一致。

直白来讲，我要开一个500人的会议，我准备了500份资料，那么在资料可能会修改的情况下，如何保证大家手里资料，都是最新的？

加载、更新，我能想到的就是用消息队列广播，系统收到消息的时候，每一台服务器都走一遍加载逻辑。

但有一个问题我解决不了，几百台服务器同时请求，如何解决突发的压力问题呢？如果500个人同时去找会议组织人打印，排队不说了，打印机得忙冒烟。

我给身边的一个技术大拿说了我的问题，他说，你可以用公司的一个中间件啊，数据只需要一次加载，然后服务器去下载就好了。是哈，用一个超级打印机打印出500份，分发下去就好了，不用每个人亲自来取呀。

就是几句点拨，同步给我了这一个信息，我了解了一下这个中间件，完美解决了我的问题。

因此，学会借力。找到公司大佬，找到网上的大佬，买杯咖啡、发个红包，直接了当的说出你的问题，咨询解决方案，从更高层次，降维打击你的问题。

当然，一定要在自己思考完、没有结果的情况下，再去请教，能够自己研究明白的，比如使用相关的，不要去麻烦别人。

说在最后

文章到这里就要结束啦，很感谢你能看到最后。

职场初期遇到无从下手的任务时，我们应该建立正确的认知，界定问题，并注重当下。

也分享给你了两个行之有效的方法，目标拆分和学会借力，当然，这一切都离不开你的行动和坚持，这不是方法，而是一个技术人最基本的素质，所以就不多说啦。

不知道你在职场中初期遇到无从下手的问题时，你是怎么处理的呢，欢迎你在评论区和我分享，也希望你点赞、评论、收藏，让我知道对你有所收获，这对我来说很重要。也欢迎你加我的wx：Ldhrlhy10，让我做你的垫脚石，帮你解决你遇到的问题呀，欢迎一起交流～

作者：东东拿铁
来源：juejin.cn/post/7362905254725648438

收起阅读 »

美团多场景建模的探索与实践

系统设计

本文介绍了美团到家/站外投放团队在多场景建模技术方向上的探索与实践。基于外部投放的业务背景，本文提出了一种自适应的场景知识迁移和场景聚合技术，解决了在投放中面临外部海量流量带来的场景数量丰富、场景间差异大的问题，取得了明显的效果提升。希望能给大家带来一些启发或...

继续阅读 »

本文介绍了美团到家/站外投放团队在多场景建模技术方向上的探索与实践。基于外部投放的业务背景，本文提出了一种自适应的场景知识迁移和场景聚合技术，解决了在投放中面临外部海量流量带来的场景数量丰富、场景间差异大的问题，取得了明显的效果提升。希望能给大家带来一些启发或帮助。

1 引言

美团到家Demand-Side Platform（下文简称DSP）平台，主要负责在美团外部媒体上进行商品或者物料的推荐和投放，并不断优化转化效果。随着业务的不断发展与扩大，DSP对接的外部渠道越来越丰富、展示形式越来越多样，物料展示场景的差异性愈发明显（如开屏、插屏、信息流、弹窗等）。

例如，用户在午餐时间更容易点击【某推荐渠道下】【某App】【开屏展示位】的快餐类商家的物料而不是【信息流展示位】的啤酒烧烤类商家物料。场景间差异的背后本质上是用户意图和需求的差异，因此模型需要对越来越多的场景进行定制化建设，以适配不同场景下用户的个性化需求。

业界经典的Mixture-of-Experts架构（MoE，如MMoE、PLE、STAR^[1]等）能一定程度上适配不同场景下用户的个性化需求。这种架构将多个Experts的输出结果通过一个门控网络进行权重分配和组合，以得到最终的预测结果。早期，我们基于MoE架构提出了使用物料推荐渠道进行场景划分的多场景建模方案。然而，随着业务的不断壮大，场景间的差异越来越大、场景数量也越来越丰富，这版模型难以适应业务发展，不能很好地解决DSP背景下存在的以下两个问题：

负迁移现象：以推荐渠道为例，由于不同推荐渠道的流量在用户分布、行为习惯、物料展示形式等方面存在差异，其曝光数、点击率也不在同一个数量级（如下图1所示，不同渠道间点击率相差十分显著），数据呈现典型的“长尾”现象。如果使用推荐渠道进行多场景建模的依据，一方面模型会更倾向于学习到头部渠道的信息，对于尾部渠道会存在学习不充分的问题，另一方面尾部渠道的数据也会给头部渠道的学习带来“噪声”，导致出现负迁移。

数据稀疏难以收敛：DSP会在外部不同媒体上进行物料展示，而用户在访问外部媒体时，其所处的时空背景、上下文信息、不同App以及物料展示位等信息共同构成了当前的场景，这样的场景在十万的量级，每个场景的数据又十分稀疏，导致模型难以在每个场景上得到充分的训练。

在面对此类建模任务时，业界现有的方法是在不同场景间进行知识迁移。例如，SAML^[2]模型采用辅助网络来学习场景的共享知识并迁移至各场景的独有网络；ADIN^[3]和SASS^[4]模型使用门控单元以一种细粒度的方式来选择和融合全局信息到单场景信息中。然而，在DSP背景中复杂多变的流量背景下，场景差异性导致了场景数量的急剧增长，现有方法无法在巨量稀疏场景下有效。

因此，在本文中我们提出了DSP背景下的自适应场景建模方案（AdaScene, Adaptive Scenario Model），同时从知识迁移和场景聚合两个角度进行建模。AdaScene通过控制知识迁移的程度来最大化不同场景共性信息的利用，并使用稀疏专家聚合的方式利用门控网络自动选择专家组成场景表征，缓解了负迁移现象；同时，我们利用损失函数梯度指导场景聚合，将巨大的推荐场景空间约束到有限范围内，缓解了数据稀疏问题，并实现了自适应场景建模方案。

2 自适应场景建模

在本节开始前，我们先介绍多场景模型的建模方式。多场景模型采用输入层 Embedding + 混合专家（Mixture-of-Experts, MoE）的建模范式，其中输入信息包括了用户侧、商家侧以及场景上下文特征。多场景模型的损失由各场景的损失聚合而成，其损失函数形式如下：

其中， $K$ 为场景数量， $α_i$ 为各场景的损失权重值。

我们提出的AdaScene自适应场景模型主要包含以下2个部分：场景知识迁移（Knowledge Transfer）模块以及场景聚合（Scene Aggregation）模块，其模型结构如下图2所示。场景知识迁移模块自适应地控制不同场景间的知识共享程度，并通过稀疏专家网络自动选择 K 个专家构成自适应场景表征。场景聚合模块通过离线预先自动化衡量所有场景间损失函数梯度的相似度，继而通过最大化场景相似度来指导场景的聚合。

该模型结构的整体损失函数如以下公式所示：

其中， $\alpha_{k}$ 为每个场景组的损失函数所对应的系数， $G_k$ 为第 $k$ 个场景组下的的场景数量， $G$ 为某种场景组的划分方式。

下面，我们分别介绍自适应场景知识迁移和场景聚合的建模方案。

2.1 自适应场景知识迁移

在多场景建模中，场景定义方式决定了场景专家的学习样本，很大程度上影响着模型对场景的拟合能力，但无论采用哪种场景定义方式，不同场景间用户分布都存在重叠，用户行为模式也会有相似性。

为提升不同场景间共性的捕捉能力，我们从场景特征和场景专家两个维度探索场景知识迁移的方法，在以物料推荐渠道×App×展示形态作为多场景建模Base模型的基础上，构建了如下图3所示的自适应场景知识迁移模型（Adaptive Knowledge Transfer Network, AKTN）。该模型建立了场景共享参数与私有参数的知识迁移桥梁，能够自适应地控制知识迁移的程度、缓解负迁移现象。

场景特征适配：通过Squeeze-and-Excitation Network^[5]构建场景适应层（Scene Adaption Layer），其结构可表示为 $F_{SE}= FC( ReLU( FC(x)))$ ，其中 $FC$ 表示全连接层， $ReLU$ 为激活函数。由于不同场景对原始特征的关注程度存在较大差异，该层能够根据不同场景的信息生成原始特征的权重，并利用这些权重对输入特征进行相应的变换，实现场景特定的个性化输入表征，提高模型的场景信息捕捉能力。

场景知识迁移：使用GRU门控单元构建场景知识迁移层（Scene Transfer Layer）。GRU门控单元通过场景上下文信息对来自全局场景专家和当前场景专家的信息流动进行控制，筛选出符合当前场景的有用信息；并且，该结构能以层级方式进行堆叠，不断对场景输出进行修正。

场景特征适配在输入层根据场景信息对不同特征进行权重适配，筛选出当前场景下模型最关注的特征；场景知识迁移在隐层专家网络中进行知识迁移，控制共享专家中共性信息向场景独有信息的流动，使得场景共性信息得以传递。

这两种知识迁移方式互为补充、相辅相成，共同提升多场景模型的预估能力。我们对比了不同模块的实验效果，具体结果如下表1所示。可以看出，引入场景知识迁移和特征权重优化在头部、尾部渠道都能带来一定提升，其中尾部小流量场景上（见下表1子场景2、3）有更为明显的提升，可见场景知识迁移缓解了场景之间的负迁移现象。

相关研究和实践表明^[6][7][8]，稀疏专家网络对于提高计算效率和增强模型效果非常有用。因此，我们在AKTN模型的基础上，在专家层进一步优化多场景模型。具体的，我们将场景知识迁移层替换为自动化稀疏专家选择方法，通过门控网络从大规模专家中选取与当前场景最相关的 $K$ 个构成自适应场景表征，其选择过程如下图4所示：

在实践中，我们通过使用可微门控网络对专家进行有效组合，以避免不相关任务之间的负迁移现象。同时大规模专家网络的引入扩大了多场景模型的选择空间，更好地支持了门控网络的选择。考虑到多场景下的海量流量和复杂场景特征，在业界调研的基础上对稀疏专家门控网络进行了探索。

具体而言，我们对以下稀疏门控方法进行了实践：

方法一：通过 $KL$ 散度衡量子场景与各专家之间的相似度，以此选择与当前场景最匹配的 $k$ 个专家。在实现方式上，使用场景*专家的二维矩阵计算相似性，并通过 $KL$ 散度选择出最适合的 $k$ 个专家。

方法二：每个子场景配备一个专家选择门控网络， $m$ 个场景则有 $m$ 个门控网络。对于每个场景的门控网络，配备 $k$ 个单专家选择器^[9]，每个单专家选择器负责从 $n$ 个专家中选择一个作为当前场景的专家（ $n$ 为Experts个数）。在实践中，为提高训练效率，我们对单专家选择器中权重较小的值进行截断，保证每个单专家选择器仅选择一个专家。

在离线实验中，我们以物料推荐渠道 * 展示形态作为场景定义，对上述稀疏门控方法进行了尝试，离线效果如下表2所示：

可以看出，基于软共享机制的专家聚合方法能够更好地通过所激活的相同专家网络对各场景之间的知识进行共享。相较于常见的以截断方式为主的门控网络，使用二进制编码的方式使得其在不损失其他专家网络信息的同时，能够更好地收敛到目标专家数量，同时其可微性使得其在以梯度为基础的优化算法中训练更加稳定。

同时，为了验证稀疏门控网络能否有效区分不同场景并捕捉到场景间差异性，我们使用 $n$ =16个专家中选择 $K$ =7个的例子，对验证集中不同场景下各专家的利用率、选择专家的平均权重进行了可视化分析（如图5-图7所示），实验结果表明该方法能够有效地选择出不同的专家对场景进行表达。

例如，图6中KP_1更多地选择第5个专家，而KP_2更倾向于选择第15个专家。并且，不同场景对各专家的使用率以及选择专家的平均权重也有着明显的差异性，表明该方法能够捕捉到细分场景下流量的差异性并进行差异化的表达。

实验证明，在通过大规模专家网络对每个场景进行建模的同时，基于软共享机制的专家聚合方法能够更好地通过所激活的相同专家网络对各场景之间的知识进行共享。同时，为了进一步探索Experts个数对模型性能的影响，我们在方法二的基础上通过调整专家个数和topK比例设计了多组对比实验，实验结果如下表3所示：

从实验数据可以看出，大规模的Experts结构会带来正向的离线收益；并且随着选取专家个数比例的增加（表3横轴），模型整体的表现效果也有上升的趋势。

2.2 自适应场景聚合

理想情况下，一条请求（流量）可以看作一个独立的场景。但如引言所述，随着DSP业务持续发展，不同的物料展示渠道、形式、位置等持续增加，每个场景的数据十分稀疏，我们无法对每个细分场景进行有效训练。因此，我们需要对各个推荐场景进行聚类、合并。我们使用场景聚合的方法对此问题进行求解，通过衡量所有场景间的相似度，并最大化该相似度来指导场景的聚合，解决了数据稀疏导致难以收敛的问题。具体的，我们将该问题表示为：

其中 $G$ 表示某种分组方式， $f_{s_i}$ 为场景 $s_i$ 在分组 $G_k$ 内与其他场景的总体相似度。在将 $N$ 个场景聚合成 $K$ 个场景组的过程中，我们需要找到使得场景间整体相似度最大的分组方式 $G^{\ast}$ 。

因此，我们在2.1节场景知识迁移模型的基础上，增加了场景聚合部分，提出了基于Two-Stage策略进行训练的场景聚合模型：

Stage 1：基于相似度衡量方法对各场景的相似度进行归纳，并以最大化分组场景的相似度为目标找到各场景的最优聚合方式（如Scene1与Scene 4可聚合为场景组合Scene Gr0up SGA）；

Stage 2：基于Stage 1得到的场景聚合方式，以交叉熵损失为目标函数最小化各场景下的交叉熵损失。

其中，Stage 2与2.1节中所述一致，本节主要针对Stage 1进行阐述。我们认为，一个有效的场景聚合方法应该能自适应地应对流量变化的趋势，能够发现场景之间的内在联系并依据当前流量特点自动适配聚合方法。我们首先想到的是从规则出发，将人工先验知识作为场景聚合的依据，按照推荐渠道、展示形式以及两者叉乘的方式进行了相应迭代。然而这类场景聚合方式需要可靠的人工经验来支撑，且在应对海量流量时不能迅速捕捉到其中的变化。

因此，我们对场景之间关系的建模方法进行了相关的探索。首先，我们通过离线训练时场景之间的表征迁移和组合训练来评估场景之间的影响，但这种方式存在组合空间巨大、训练耗时较长的问题，效率较低。

在多任务的相关研究中^{[10][11][12][13]}，使用梯度信息对任务之间的关系进行建模是一种有效的方法。类似的在多场景模型中，能够根据各场景损失函数的梯度信息对场景间的相似度进行建模，因此我们采用多专家网络并基于梯度信息自动化地对场景之间的相似度进行求解，模型示意如下图8所示：

基于上述思路，我们对场景之间的关系建模方法进行了以下尝试：

1. Gradient Regulation

基于梯度信息能够对场景信息进行潜在表示这一认知，我们在损失函数中加入各场景损失函数关于专家层梯度距离的正则项，整体的损失函数如下所示，该正则项的系数 $\lambda_{s_i,s_j}$ 表示场景之间的相似度， $dist$ 为常见的评估梯度之间距离的方法，比如 $l_1$ ， $l_2$ 距离。

2. Lookahead Strategy

3. Meta Weights

Lookahead Strategy该方法对场景间的关系进行了显式建模，但是这种根据损失函数的变化计算场景相关系数的策略存在着训练不稳定、波动较大的现象，无法像Gradient Regulation这一方法对场景相似度进行求解。

因此，我们引入了场景间的相关性系数矩阵（meta weights），结合前两种方法对该问题进行如下建模，通过场景 $s_i$ 的数据对其与其他场景的相关性系数 $\lambda_{s_i \to s_j}$ 进行更新，同时基于该参数对全局的参数模型 $W$ 进行优化。针对这种典型的两层优化问题，我们基于MAML^[14]方法进行求解，并将meta weights作为场景间的相似度。

我们以推荐渠道和展示形式（是否开屏）的多场景模型作为Base，对上述3种方法做了探索。为了提高训练效率，我们在设计 Stage 1 模型时做了以下优化：

我们对每个方法的GAUC进行了比较，实验效果如下表4所示。相较于人工规则，基于梯度的场景聚合方法都能带来效果的明显提升，表明损失函数梯度能在一定程度上表示场景之间的相似性，并指导多场景进行聚合。

为了更全面的展现场景聚合对于模型预估效果的影响，我们选取Meta Weights进行分组数量的调优实验，具体的实验结果如下表5所示。可以发现：随着分组数的增大，GAUC提升也越大，此时各场景间的负迁移效应减弱；但分组超过一定数量时，场景间总体的相似度减小，GAUC呈下降趋势。

此外，我们对Meta Weigts方法中部分场景间的关系进行了可视化分析，分析结果如下图9所示。以场景作为坐标轴，图中的每个方格表示各场景间的相似度，颜色的深浅表示渠道间的相似程度大小。

从图中可以发现，以渠道和展示形式为粒度的细分场景下，该方法能够学习到不同场景间的相关性，例如A渠道下的信息流(s16)与其他场景的相关性较低，会将其作为独立的场景进行预估，而B渠道下的开屏展示（s9）与C渠道开屏展示（s8）相关性较高，会将其聚合为一个场景进行预估，同时该相似度矩阵不是对称的，这也说明各场景间相互的影响存在着差异。

3 总结与展望

通过多场景学习的探索和实践，我们深入挖掘了推荐模型在不同场景下的建模能力，并分别从场景知识迁移、场景聚合方向进行了尝试和优化，这些尝试提供了更好的理解和解释推荐模型对不同类型流量和场景的应对能力。然而，这只是多场景学习研究的开始，后续我们会探索并迭代以下方向：

更好的场景划分方式：当前多场景的划分主要还是依据渠道（渠道*展示形态）作为流量的划分方式，未来会在媒体、展示位、媒体*时间等维度上进行更详细地探索；

端到端的流量聚合方式：在进行流量聚合时，使用了Two-Stage的策略进行聚合。然而，这种方式不能充分地利用流量数据中相关的信息。因此，需要探索端到端的流量场景聚合方案将更直接和有效地提高推荐模型的能力。

结合多场景学习，在未来的研究中将不断探索新的方法和技术，以提高推荐模型对不同场景和流量类型的建模能力，创造更好的用户体验以及商业价值。

4 作者简介

王驰、森杰、树立、文帅、尹华、肖雄等，均来自美团到家事业群/到家研发平台。

5 参考文献

[1] STAR：Sheng, Xiang-Rong, et al. "One model to serve all: Star topology adaptive recommender for multi-domain ctr prediction." Proceedings of the 30th ACM International Conference on Information & Knowledge Management. 2021.

[2] SAML：Chen, Yuting, et al. "Scenario-aware and Mutual-based approach for Multi-scenario Recommendation in E-Commerce." 2020 International Conference on Data Mining Workshops (ICDMW). IEEE, 2020.

[3] ADIN：Jiang, Yuchen, et al. "Adaptive Domain Interest Network for Multi-domain Recommendation." Proceedings of the 31st ACM International Conference on Information & Knowledge Management. 2022.

[4]SASS：Zhang, Yuanliang, et al. "Scenario-Adaptive and Self-Supervised Model for Multi-Scenario Personalized Recommendation." Proceedings of the 31st ACM International Conference on Information & Knowledge Management. 2022.

[5] Squeeze-and-Excitation：Hu, Jie, Li Shen, and Gang Sun. "Squeeze-and-excitation networks." Proceedings of the IEEE conference on computer vision and pattern recognition. 2018.

[6] 美团外卖推荐情境化智能流量分发的实践与探索

[7] PaLM：ai.googleblog.com/2022/04/pat…

[8] GLaM：proceedings.mlr.press/v162/du22c.…

[9] 单专家选择器：arxiv.org/abs/2106.03…

[10] HOA：proceedings.mlr.press/v119/standl…

[11] Gradient Affinity：proceedings.neurips.cc/paper/2021/…

[12] SRDML：dl.acm.org/doi/abs/10.…

[13] Auto-Lambda：arxiv.org/abs/2202.03…

[14] MAML：arxiv.org/abs/1703.03…

作者：美团技术团队
来源：juejin.cn/post/7278597227785551883

收起阅读 »

DDD项目落地之充血模型实践 | 京东云技术团队

系统设计

背景：充血模型是DDD分层架构中实体设计的一种方案，可以使关注点聚焦于业务实现，可有效提升开发效率、提升可维护性； 1、DDD项目落地整体调用关系调用关系图中的Entity为实体，从进入领域服务（Domin）时开始使用，直到最后返回。 2、实体设计充血...

继续阅读 »

背景：

充血模型是DDD分层架构中实体设计的一种方案，可以使关注点聚焦于业务实现，可有效提升开发效率、提升可维护性；

1、DDD项目落地整体调用关系

调用关系图中的Entity为实体，从进入领域服务（Domin）时开始使用，直到最后返回。

2、实体设计

充血模型是实体设计的一种方法，简单来说，就是一种带有具体行为方法和聚合关联关系的特殊实体；

关于实体设计，需要明白的关键词为：领域服务->聚合->聚合根->实体->贫血模型->充血模型

聚合与聚合根:

聚合是一种关联关系，而聚合根就是这个关系成立的基础，没有聚合根，这个聚合关系就无法成立；

举个例子，存在3个实体：用户、用户组、用户组关联关系，这3个实体形成的关联关系就是聚合，而用户实体就是这个聚合中的聚合根；

实体：

定义在领域层，是领域层的重要元素，从领域划分到工程实践落地，都应该围绕实体进行，DDD中的实体和数据库表不只是1对1关系，可能是1对多或者仅为内存中的对象；

贫血模型：

实体不带有任何行为方法，也不带有聚合关联关系，作用基本相当于值对象（ValueObject），仅作为值传递的对象，和传统三层项目架构中的实体具有相同作用，不建议使用。补充说明：一般我们使用的DTO就可以被当做是值对象

充血模型：

实体中带有具有行为方法和聚合关联关系，行为方法是说create、save、delete等封装了一类可以指代行为的方法，比如在用户实体对象中具有用户组实体的引用，这样当我们需要操作用户组时，只通过用户实体进行操作就可以。

工程实践中，建议采用充血模型，好处是隐藏胶水代码，提升代码可读性，使关注点聚焦于业务实现。

充血模型在实践中的问题：

行为代码量过多，导致实体内部臃肿膨胀，难以阅读，难以维护，对于这种问题，我们需要根据实体行为的代码量多少来采取不同的解决方案。

解决方案：

场景1：行为不会导致实体臃肿的情况下，在实体中完成行为定义

public CooperateServicePackageConfig save() {    

    // 直接调用基础设施层进行保存

    cooperateServicePackageConfigRepository.save(this);    

    return this;

}

场景2：行为导致实体臃肿的情况下，采用外部定义行为的方式，核心思想是借助其他类实现行为代码定义，将臃肿代码外移，保留干净的实体行为：

1）创建工具类，将某个实体中的行为定义其中，实体负责调用该工具类

public CooperateServicePackageConfig save() {    

    // 将处理过程放在工具类中

    ServicePackageSaveUtils.save(this);   

    return this;

 }

2）创建新实体，将该实体的使用场景明确至某个细分行为，比如一个聚合根（ExampleEntity）的保存可能涉及到5个实体的保存，那么我们定义一个ExampleSaveEntity实体，专门用来处理该聚合下的保存行为

实践经验：

1、关于spring bean注入：充血模型在实体中使用静态注入方法实现。例：

private LabelInfoRepository labelInfoRepository = ApplicationContextUtils.getBean(LabelInfoRepository.class);

2、充血模型的实体序列化，排除非必要属性，在一些redis对象缓存时可能会用到。例：

// 使用注解排除序列化属性

@Getter(AccessLevel.NONE)

private LabelInfoRepository labelInfoRepository = ApplicationContextUtils.getBean(LabelInfoRepository.class);

// 使用注解排除序列化属性

@JSONField(serialize = false)

private ServicePackageConfig servicePackageConfig;

// 使用注解排除序列化 get 方法

@Transient

@JSONField(serialize = false)

public static CooperateServicePackageRepositoryQuery getAllCodeQuery(Long contractId) {    

    CooperateServicePackageRepositoryQuery repositoryQuery = new CooperateServicePackageRepositoryQuery();    

    repositoryQuery.setContractIds(com.google.common.collect.Lists.newArrayList(contractId));    

    repositoryQuery.setCode(RightsPlatformConstants.CODE_ALL);   

     return repositoryQuery;

}

3、利用Set方法建立聚合绑定关系。例：

public void setServiceSkuInfos(List<ServiceSkuInfo> serviceSkuInfos) {    

    if (CollectionUtils.isEmpty(serviceSkuInfos)) 

    {        

        return;    

    }    

    this.serviceSkuInfos = serviceSkuInfos;    

    List<String> allSkuNoSet = serviceSkuInfos

                                .stream()

                                .map(one -> one.getSkuNo())

                                .collect(Collectors.toList());   

     String skuJoinStr = Joiner.on(GlobalConstant.SPLIT_CHAR).join(allSkuNoSet);    

     this.setSkuNoSet(skuJoinStr);}

作者：京东健康张君毅

来源：京东云开发者社区

作者：京东云开发者
来源：juejin.cn/post/7264235181778190373

收起阅读 »

域名还能绑定动态IP？真是又涨见识了，再也不用购买固定IP了！赶快收藏

综合技术讨论

大家好，我是冰河~~ 一般家庭网络的公网IP都是不固定的，而我又想通过域名来访问自己服务器上的应用，也就是说：需要通过将域名绑定到动态IP上来实现这个需求。于是乎，我开始探索实现的技术方案。通过在网上查阅一系列的资料后，发现阿里云可以做到实现动态域名解析DD...

继续阅读 »

大家好，我是冰河~~

一般家庭网络的公网IP都是不固定的，而我又想通过域名来访问自己服务器上的应用，也就是说：需要通过将域名绑定到动态IP上来实现这个需求。于是乎，我开始探索实现的技术方案。

通过在网上查阅一系列的资料后，发现阿里云可以做到实现动态域名解析DDNS。于是乎，一顿操作下来，我实现了域名绑定动态IP。这里，我们以Python为例实现。

小伙伴们注意啦：Java版源码已提交到：github.com/binghe001/m…

好了，说干就干，我们开始吧，走起~~

阿里云DDNS前置条件

域名是在阿里云购买的

地址必须是公网地址，不然加了解析也没有用

通过阿里云提供的SDK，然后自己编写程序新增或者修改域名的解析，达到动态解析域名的目的；主要应用于pppoe拨号的环境，比如家里设置了服务器，但是外网地址经常变化的场景；再比如公司的pppoe网关，需要建立vpn的场景。

安装阿里云SDK

需要安装两个SDK库，一个是阿里云核心SDK库，一个是阿里云域名SDK库；

阿里云核心SDK库

pip install aliyun-python-sdk-core

阿里云域名SDK库

pip install aliyun-python-sdk-domain

阿里云DNSSDK库

pip install aliyun-python-sdk-alidns

设计思路

获取阿里云的accessKeyId和accessSecret

获取外网ip

判断外网ip是否与之前一致

外网ip不一致时，新增或者更新域名解析记录

实现方案

这里，我直接给出完整的Python代码，小伙伴们自行替换AccessKey和AccessSecret。

#!/usr/bin/env python

#coding=utf-8



# 加载核心SDK

from aliyunsdkcore.client import AcsClient

from aliyunsdkcore.acs_exception.exceptions import ClientException

from aliyunsdkcore.acs_exception.exceptions import ServerException



# 加载获取 、 新增、 更新、 删除接口

from aliyunsdkalidns.request.v20150109 import DescribeSubDomainRecordsRequest, AddDomainRecordRequest, UpdateDomainRecordRequest, DeleteDomainRecordRequest



# 加载内置模块

import json,urllib



# AccessKey 和 Secret  建议使用 RAM 子账户的 KEY 和 SECRET 增加安全性

ID = 'xxxxxxx'

SECRET = 'xxxxxx'



# 地区节点 可选地区取决于你的阿里云帐号等级，普通用户只有四个，分别是杭州、上海、深圳、河北，具体参考官网API

regionId = 'cn-hangzhou'



# 配置认证信息

client = AcsClient(ID, SECRET, regionId)



# 设置主域名

DomainName = 'binghe.com'



# 子域名列表  列表参数可根据实际需求增加或减少值

SubDomainList = ['a', 'b', 'c']



# 获取外网IP   三个地址返回的ip地址格式各不相同，3322 的是最纯净的格式， 备选1为 json格式  备选2 为curl方式获取  两个备选地址都需要对获取值作进一步处理才能使用

def getIp():

    # 备选地址：1， http://pv.sohu.com/cityjson?ie=utf-8    2，curl -L tool.lu/ip

    with urllib.request.urlopen('http://www.3322.org/dyndns/getip') as response:

        html = response.read()

        ip = str(html, encoding='utf-8').replace("\n", "")

    return ip



# 查询记录

def getDomainInfo(SubDomain):

    request = DescribeSubDomainRecordsRequest.DescribeSubDomainRecordsRequest()

    request.set_accept_format('json')



    # 设置要查询的记录类型为 A记录   官网支持A / CNAME / MX / AAAA / TXT / NS / SRV / CAA / URL隐性（显性）转发  如果有需要可将该值配置为参数传入

    request.set_Type("A")



    # 指定查记的域名 格式为 'test.binghe.com'

    request.set_SubDomain(SubDomain)



    response = client.do_action_with_exception(request)

    response = str(response, encoding='utf-8')



    # 将获取到的记录转换成json对象并返回

    return json.loads(response)



# 新增记录 (默认都设置为A记录，通过配置set_Type可设置为其他记录)

def addDomainRecord(client,value,rr,domainname):

    request = AddDomainRecordRequest.AddDomainRecordRequest()

    request.set_accept_format('json')



    # request.set_Priority('1')  # MX 记录时的必选参数

    request.set_TTL('600')       # 可选值的范围取决于你的阿里云账户等级，免费版为 600 - 86400 单位为秒 

    request.set_Value(value)     # 新增的 ip 地址

    request.set_Type('A')        # 记录类型

    request.set_RR(rr)           # 子域名名称  

    request.set_DomainName(domainname) #主域名



    # 获取记录信息，返回信息中包含 TotalCount 字段，表示获取到的记录条数 0 表示没有记录， 其他数字为多少表示有多少条相同记录，正常有记录的值应该为1，如果值大于1则应该检查是不是重复添加了相同的记录

    response = client.do_action_with_exception(request)

    response = str(response, encoding='utf-8')

    relsult = json.loads(response)

    return relsult



# 更新记录

def updateDomainRecord(client,value,rr,record_id):

    request = UpdateDomainRecordRequest.UpdateDomainRecordRequest()

    request.set_accept_format('json')



    # request.set_Priority('1')

    request.set_TTL('600')

    request.set_Value(value) # 新的ip地址

    request.set_Type('A')

    request.set_RR(rr)

    request.set_RecordId(record_id)  # 更新记录需要指定 record_id ，该字段为记录的唯一标识，可以在获取方法的返回信息中得到该字段的值



    response = client.do_action_with_exception(request)

    response = str(response, encoding='utf-8')

    return response



# 删除记录

def delDomainRecord(client,subdomain):

    info = getDomainInfo(subdomain)

    if info['TotalCount'] == 0:

        print('没有相关的记录信息，删除失败！')

    elif info["TotalCount"] == 1:

        print('准备删除记录')

        request = DeleteDomainRecordRequest.DeleteDomainRecordRequest()

        request.set_accept_format('json')



        record_id = info["DomainRecords"]["Record"][0]["RecordId"]

        request.set_RecordId(record_id) # 删除记录需要指定 record_id ，该字段为记录的唯一标识，可以在获取方法的返回信息中得到该字段的值

        result = client.do_action_with_exception(request)

        print('删除成功，返回信息：')

        print(result)

    else:

        # 正常不应该有多条相同的记录，如果存在这种情况，应该手动去网站检查核实是否有操作失误

        print("存在多个相同子域名解析记录值，请核查后再操作！")



# 有记录则更新，没有记录则新增

def setDomainRecord(client,value,rr,domainname):

    info = getDomainInfo(rr + '.' + domainname)

    if info['TotalCount'] == 0:

        print('准备添加新记录')

        add_result = addDomainRecord(client,value,rr,domainname)

        print(add_result)

    elif info["TotalCount"] == 1:

        print('准备更新已有记录')

        record_id = info["DomainRecords"]["Record"][0]["RecordId"]

        cur_ip = getIp()

        old_ip = info["DomainRecords"]["Record"][0]["Value"]

        if cur_ip == old_ip:

            print ("新ip与原ip相同，不更新！")

        else:

            update_result = updateDomainRecord(client,value,rr,record_id)

            print('更新成功，返回信息：')

            print(update_result)

    else:

        # 正常不应该有多条相同的记录，如果存在这种情况，应该手动去网站检查核实是否有操作失误

        print("存在多个相同子域名解析记录值，请核查删除后再操作！")





IP = getIp()



# 循环子域名列表进行批量操作

for x in SubDomainList:

    setDomainRecord(client,IP,x,DomainName)



# 删除记录测试

# delDomainRecord(client,'b.jsoner.com')



# 新增或更新记录测试

# setDomainRecord(client,'192.168.3.222','a',DomainName)



# 获取记录测试

# print (getDomainInfo(DomainName, 'y'))



# 批量获取记录测试

# for x in SubDomainList:

#     print (getDomainInfo(DomainName, x))



# 获取外网ip地址测试

# print ('(' + getIp() + ')')

Python脚本的功能如下：

获取外网ip地址。

获取域名解析记录。

新增域名解析记录。

更新域名解析记录。

删除域名解析记录（并不建议将该功能添加在实际脚本中）。

批量操作，如果记录不存在则添加记录，存在则更新记录。

另外，有几点需要特别说明：

建议不要将删除记录添加进实际使用的脚本当中。

相同记录是同一个子域名的多条记录，比如 test.binghe.com。

脚本并没有验证记录类型，所以同一子域名下的不同类型的记录也会认为是相同记录，比如：有两条记录分别是 test.binghe.com 的 A 记录和 test.binghe.com 的 AAAA 记录，会被认为是两条相同的 test.binghe.com 记录.如果需要判定为不同的记录，小伙伴们可以根据上述Python脚本自行实现。

可以通过判断获取记录返回的 record_id 来实现精确匹配记录。

最后，可以将以上脚本保存为文件之后，通过定时任务，来实现定期自动更新ip地址。

作者：冰_河
来源：juejin.cn/post/7385106262009004095

收起阅读 »

接口不能对外暴露怎么办？

系统设计

在业务开发的时候，经常会遇到某一个接口不能对外暴露，只能内网服务间调用的实际需求。面对这样的情况，我们该如何实现呢？ 1. 内外网接口微服务隔离将对外暴露的接口和对内暴露的接口分别放到两个微服务上，一个服务里所有的接口均对外暴露，另一个服务的接口只能内网服...

继续阅读 »

在业务开发的时候，经常会遇到某一个接口不能对外暴露，只能内网服务间调用的实际需求。

面对这样的情况，我们该如何实现呢？

1. 内外网接口微服务隔离

将对外暴露的接口和对内暴露的接口分别放到两个微服务上，一个服务里所有的接口均对外暴露，另一个服务的接口只能内网服务间调用。

该方案需要额外编写一个只对内部暴露接口的微服务，将所有只能对内暴露的业务接口聚合到这个微服务里，通过这个聚合的微服务，分别去各个业务侧获取资源。

该方案，新增一个微服务做请求转发，增加了系统的复杂性，增大了调用耗时以及后期的维护成本。

2. 网关 + redis 实现白名单机制

在 redis 里维护一套接口白名单列表，外部请求到达网关时，从 redis 获取接口白名单，在白名单内的接口放行，反之拒绝掉。

该方案的好处是，对业务代码零侵入，只需要维护好白名单列表即可；

不足之处在于，白名单的维护是一个持续性投入的工作，在很多公司，业务开发无法直接触及到 redis，只能提工单申请，增加了开发成本；

另外，每次请求进来，都需要判断白名单，增加了系统响应耗时，考虑到正常情况下外部进来的请求大部分都是在白名单内的，只有极少数恶意请求才会被白名单机制所拦截，所以该方案的性价比很低。

3. 方案三网关 + AOP

相比于方案二对接口进行白名单判断而言，方案三是对请求来源进行判断，并将该判断下沉到业务侧。避免了网关侧的逻辑判断，从而提升系统响应速度。

我们知道，外部进来的请求一定会经过网关再被分发到具体的业务侧，内部服务间的调用是不用走外部网关的（走 k8s 的 service）。

根据这个特点，我们可以对所有经过网关的请求的header里添加一个字段，业务侧接口收到请求后，判断header里是否有该字段，如果有，则说明该请求来自外部，没有，则属于内部服务的调用，再根据该接口是否属于内部接口来决定是否放行该请求。

该方案将内外网访问权限的处理分布到各个业务侧进行，消除了由网关来处理的系统性瓶颈；

同时，开发者可以在业务侧直接确定接口的内外网访问权限，提升开发效率的同时，增加了代码的可读性。

当然该方案会对业务代码有一定的侵入性，不过可以通过注解的形式，最大限度的降低这种侵入性。

具体实操

下面就方案三，进行具体的代码演示。

首先在网关侧，需要对进来的请求header添加外网标识符: from=public

@Component

public class AuthFilter implements GlobalFilter, Ordered {

    @Override

    public Mono < Void > filter ( ServerWebExchange exchange, GatewayFilterChain chain ) {

         return chain.filter(

         exchange.mutate().request(

         exchange.getRequest().mutate().header('id', '').header('from', 'public').build())

         .build()

         )；

    }



    @Override

    public int getOrder () {

        return 0;

    }

 }

接着，编写内外网访问权限判断的AOP和注解

@Aspect

@Component

@Slf4j

public class OnlyIntranetAccessAspect {

 @Pointcut ( '@within(org.openmmlab.platform.common.annotation.OnlyIntranetAccess)' )

 public void onlyIntranetAccessOnClass () {}

 @Pointcut ( '@annotation(org.openmmlab.platform.common.annotation.OnlyIntranetAccess)' )

 public void onlyIntranetAccessOnMethed () {

 }



 @Before ( value = 'onlyIntranetAccessOnMethed() || onlyIntranetAccessOnClass()' )

 public void before () {

     HttpServletRequest hsr = (( ServletRequestAttributes ) RequestContextHolder.getRequestAttributes()) .getRequest ();

     String from = hsr.getHeader ( 'from' );

     if ( !StringUtils.isEmpty( from ) && 'public'.equals ( from )) {

        log.error ( 'This api is only allowed invoked by intranet source' );

        throw new MMException ( ReturnEnum.C_NETWORK_INTERNET_ACCESS_NOT_ALLOWED_ERROR);

            }

     }

 }



@Target({ElementType.METHOD})

@Retention(RetentionPolicy.RUNTIME)

@Documented

public @interface OnlyIntranetAccess {

}

最后，在只能内网访问的接口上加上@OnlyIntranetAccess注解即可

@GetMapping ( '/role/add' )

@OnlyIntranetAccess

public String onlyIntranetAccess() {

    return '该接口只允许内部服务调用';

}





 4. 网关路径匹配 



在DailyMart项目中我采用的是第四种：即在网关中进行路径匹配。









该方案中我们将内网访问的接口全部以前缀/pv开头，然后在网关过滤器中根据路径找到具体校验器，如果是/pv访问的路径则直接提示禁止外部访问。















使用网关路径匹配方案不仅可以应对内网接口的问题，还可以扩展到其他校验机制上。

譬如，有的接口需要通过access_token进行校验，有的接口需要校验api_key 和 api_secret，为了应对这种不同的校验场景，只需要再实现一个校验类即可，由不同的子类实现不同的校验逻辑，扩展非常方便。

作者：程序员蜗牛
来源：juejin.cn/post/7389092138900717579

收起阅读 »

Spring Boot集成pf4j实现插件开发功能

Java

1.什么是pf4j? 一个插件框架，用于实现插件的动态加载，支持的插件格式（zip、jar）。核心组件 **Plugin：**是所有插件类型的基类。每个插件都被加载到一个单独的类加载器中以避免冲突。 **PluginManager：**用于插件管理的所有方...

继续阅读 »

1.什么是pf4j?

一个插件框架，用于实现插件的动态加载，支持的插件格式（zip、jar）。

核心组件

**Plugin：**是所有插件类型的基类。每个插件都被加载到一个单独的类加载器中以避免冲突。

**PluginManager：**用于插件管理的所有方面（加载、启动、停止）。您可以使用内置实现作为JarPluginManager, ZipPluginManager, DefaultPluginManager（它是一个JarPluginManager+ ZipPluginManager），或者您可以从AbstractPluginManager（仅实现工厂方法）开始实现自定义插件管理器。

**PluginLoader：**加载插件所需的所有信息（类）。

**ExtensionPoint：**是应用程序中可以调用自定义代码的点。这是一个java接口标记。任何 java 接口或抽象类都可以标记为扩展点（实现ExtensionPoint接口）。

**Extension：**是扩展点的实现。它是一个类上的 Java 注释

场景

有一个spring-boot实现的web应用，在某一个业务功能上提供扩展点，用户可以基于SDK实现功能扩展，要求可以管理插件，并且能够在业务功能扩展点处动态加载功能。

2.代码工程

实验目的

实现插件动态加载，调用卸载

Demo整体架构

pf4j-api：定义可扩展接口。

pf4j-plugins-01：插件项目，可以包含多个插件，需要实现 plugin-api 中定义的接口。所有的插件jar包，放到统一的文件夹中，方便管理，后续只需要加载文件目录路径即可启动插件。

pf4j-app：主程序，需要依赖 pf4j-api ，加载并执行 pf4j-plugins-01 。

pf4j-api

导入依赖

<dependency>

    <groupId>org.pf4j</groupId>

    <artifactId>pf4j</artifactId>

    <version>3.0.1</version>

</dependency>

自定义扩展接口，集成 ExtensionPoint ，标记为扩展点

package com.et.pf4j;



import org.pf4j.ExtensionPoint;



public interface Greeting extends ExtensionPoint {



    String getGreeting();



}

打包给其他项目引用

pf4j-plugins-01

如果你想要能够控制插件的生命周期，你可以自定义类集成 plugin 重新里面的方法

/*

 * Copyright (C) 2012-present the original author or authors.

 *

 * Licensed under the Apache License, Version 2.0 (the "License");

 * you may not use this file except in compliance with the License.

 * You may obtain a copy of the License at

 *

 *     http://www.apache.org/licenses/LICENSE-2.0

 *

 * Unless required by applicable law or agreed to in writing, software

 * distributed under the License is distributed on an "AS IS" BASIS,

 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

 * See the License for the specific language governing permissions and

 * limitations under the License.

 */

package org.pf4j.demo.welcome;



import com.et.pf4j.Greeting;

import org.apache.commons.lang.StringUtils;



import org.pf4j.Extension;

import org.pf4j.Plugin;

import org.pf4j.PluginWrapper;

import org.pf4j.RuntimeMode;



/**

 * @author Decebal Suiu

 */

public class WelcomePlugin extends Plugin {



    public WelcomePlugin(PluginWrapper wrapper) {

        super(wrapper);

    }



    @Override

    public void start() {

        System.out.println("WelcomePlugin.start()");

        // for testing the development mode

        if (RuntimeMode.DEVELOPMENT.equals(wrapper.getRuntimeMode())) {

            System.out.println(StringUtils.upperCase("WelcomePlugin"));

        }

    }



    @Override

    public void stop() {

        System.out.println("WelcomePlugin.stop()");

    }



    @Extension

    public static class WelcomeGreeting implements Greeting {



        @Override

        public String getGreeting() {

            return "Welcome ,my name is pf4j-plugin-01";

        }



    }



}

打成jar或者zip包，方便主程序加载

pf4j-app

加载插件包

package com.et.pf4j;



import org.pf4j.JarPluginManager;

import org.pf4j.PluginManager;

import org.springframework.boot.autoconfigure.SpringBootApplication;



import java.nio.file.Paths;

import java.util.List;



@SpringBootApplication

public class DemoApplication {



/* public static void main(String[] args) {

      SpringApplication.run(DemoApplication.class, args);

   }*/

   public static void main(String[] args) {





      // create the plugin manager

      PluginManager pluginManager = new JarPluginManager(); // or "new ZipPluginManager() / new DefaultPluginManager()"



      // start and load all plugins of application

      //pluginManager.loadPlugins();



      pluginManager.loadPlugin(Paths.get("D:\\IdeaProjects\\ETFramework\\pf4j\\pf4j-plugin-01\\target\\pf4j-plugin-01-1.0-SNAPSHOT.jar"));

      pluginManager.startPlugins();

      /*

        // retrieves manually the extensions for the Greeting.class extension point

        List<Greeting> greetings = pluginManager.getExtensions(Greeting.class);

        System.out.println("greetings.size() = " + greetings.size());

        */

      // retrieve all extensions for "Greeting" extension point

      List<Greeting> greetings = pluginManager.getExtensions(Greeting.class);

      for (Greeting greeting : greetings) {

         System.out.println(">>> " + greeting.getGreeting());

      }



      // stop and unload all plugins

      pluginManager.stopPlugins();

      //pluginManager.unloadPlugins();





   }

}

3.测试

运行DemoApplication.java 里面的mian函数，可以看到插件加载，调用以及卸载情况

4.引用

pf4j.org/

github.com/pf4j/pf4j-s…

作者：HBLOG
来源：juejin.cn/post/7389912762045251584

收起阅读 »

我真的不想再用mybatis和其衍生框架了选择自研亦是一种解脱

Java

我真的不想再用mybatis和其衍生框架了选择自研亦是一种解脱文档地址 xuejm.gitee.io/easy-query-… GITHUB地址 github.com/xuejmnet/ea… GITEE地址 gitee.com/xuejm/easy-… 为...

继续阅读 »

我真的不想再用mybatis和其衍生框架了选择自研亦是一种解脱

文档地址 xuejm.gitee.io/easy-query-…

GITHUB地址 github.com/xuejmnet/ea…

GITEE地址 gitee.com/xuejm/easy-…

为什么要用orm

众所邹知orm的出现让本来以sql实现的复杂繁琐功能大大简化,对于大部分程序员而言一个框架的出现是为了生产力的提升.。dbc定义了交互数据库的规范,任何数据库的操作都是只需要满足jdbc规范即可,而orm就是为了将jdbc的操作进行简化。我个人“有幸”体验过.net和java的两个大orm，只能说差距很大,当然语言上的一些特性也让java在实现orm上有着比较慢的进度,譬如泛型的出现，lambda的出现。

一个好的orm我觉得需要满足以下几点

强类型,如果不支持强类型那么和手写sql没有区别

能实现80%的纯手写sql的功能,好的orm需要覆盖业务常用功能

支持泛型,“如果一个orm连泛型都不支持那么就没有必要存在”这是一句现实但是又很残酷的结论,但是泛型会大大的减少开发人员的编写错误率

不应该依赖过多的组件,当然这并不是orm特有的,任何一个库其实依赖越少越不易出bug

其实说了这么多总结一下就是一个好的orm应该有ide的提示外加泛型约束帮助开发可以非常顺滑的把代码写下去,并且错误部分可以完全的在编译期间提现出来,运行时错误应该尽可能少的去避免。

为什么放弃mybatis

首先如果你用过其他语言的orm那么再用java的mybatis就像你用惯了java的stream然后去自行处理数据过滤，就像你习惯了kotlin的语法再回到java语法,很难受。这种难受不是自动挡到手动挡的差距,而且自动挡到手推车的差距。

xml配置sql也不知道是哪个“小天才”想出来的,先不说写代码的时候java代码和xml代码跳来跳去,而且xml下>,<必须要配合CDATA不然xml解析就失败,别说转义,我写那玩意在加转义你确定让我后续看得眼睛不要累死吗?美名其曰xml和代码分离方便维护,但是你再怎么方便修改了代码一样需要重启,并且因为代码写在xml里面导致动态条件得能力相对很弱。并且我也不知道mybatis为什么天生不支持分页,需要分页插件来支持,难道一个3202年的orm了还需要这样吗,很难搞懂mybatis的作者难道不写crud代码的吗？有些时候简洁并不是偷懒的原因,当然也有可能是架构的问题导致的。

逻辑删除的功能我觉得稍微正常一点的企业一定都会有这个功能,但是因为使用了myabtis,因为手写sql,所以常常会忘记往sql中添加逻辑删除字段,从而导致一些奇奇怪怪的bug需要排查,因为这些都是编译器无法体现的错误,因为他是字符串,因为mybatis把这个问题的原因指向了用户,这一点他很聪明,这个是用户的错误而不是框架的,但是框架要做的就是尽可能的将一些重复工作进行封装隐藏起来自动完成。

可能又会有一些用户会说所见即所得这样我才能知道他怎么执行了,但是现在哪个orm没有sql打印功能,哪个orm框架执行的sql和打印的sql是不一样的,不是所见即所得。总体而言我觉得mybatis充其量算是sqltemlate,比sqlhelper好的地方就是他是参数化防止sql注入。当然最主要的呀一点事难道java程序员不需要修改表,不需要动表结构,不需要后期维护的吗还是说java程序员写一个项目就换一个地方跳槽,还是说java程序员每个方法都有单元测试。我在转java后理解了一点,原来这就是你们经常说的java加班严重,用这种框架加班不严重就有鬼了。

为什么放弃mybatis衍生框架

有幸在201几年再网上看到了mybatis-plus框架,这块框架一出现就吸引了我,因为他在处理sql的方式上和.net的orm很相似,起码都是强类型,起码不需要java文件和xml文件跳来跳去,平常50%的代码也是可以通过框架的lambda表达式来实现,我个人比较排斥他的字符串模式的querywrapper,因为一门强类型语言缺少了强类型提示，在编写代码的时候会非常的奇怪。包括后期的重构,当然如果你的代码后续不需要你维护那么我觉得你用哪种方式都是ok的反正是一次性的,能出来结果就好了。

继续说mybatis-plus，因为工作的需要再2020年左右针对内部框架进行改造,并且让mybatis-plus支持强类型gr0up by,sum,min,max,any等api。

这个时候其实大部分情况下已经可以应对了,就这样用了1年左右这个框架,包括后续的update的increment,decrement

update table set column=column-1 where id=xxx and column>1

全部使用lambda强类型语法,可以应对多数情况,但是针对join始终没有一个很好地方法。直到我遇到了mpj也就是mybatis-plus-join,但是这个框架也有问题,就是这个逻辑删除在join的子表上不生效，需要手动处理,如果生效那么在where上面,不知道现在怎么样了,当时我也是自行实现了让其出现在join的on后面,但是因为实现是需要实现某个接口的,所以并没有pr代码.
首先定义一个接口

public interface ISoftDelete {

    Boolean getDeleted();

}



//其中join mapper是我自己的实现,主要还是`WrapperFunction`的那段定义

  @Override

    public Scf4jBaseJoinLinq<T1,TR> on(WrapperFunction<MPJAbstractLambdaWrapper<T1, ?>> onFunction) {

        WrapperFunction<MPJAbstractLambdaWrapper<T1, ?>> join=  on->{

            MPJAbstractLambdaWrapper<T1, ?> apply = onFunction.apply(on);

            if(ISoftDelete.class.isAssignableFrom(joinClass)){

                SFunction deleted = LambdaHelper.getFunctionField(joinClass, "deleted", Boolean.class);

                apply.eq(deleted,false);

            }

            return apply;

        };

        joinMapper.setJoinOnFunction(query->{

            query.innerJoin(joinClass,join);

        });

        return joinMapper;

    }

虽然实现了join但是还是有很多问题出现和bug。

比如不支持vo对象的返回,只能返回数据库对象自定义返回列,不然就是查询所有列

再比如如果你希望你的对象update的时候填充null到数据库,那么只能在entity字段上添加,这样就导致这个字段要么全部生效要么全部不生效.

批量插入不支持默认居然是foreach一个一个加,当然这也没关系,但是你真的想实现批处理需要自己编写很复杂的代码并且需要支持全字段。而不是null列不填充

MetaObjectHandler,支持entity的insert和update但是不支持lambdaUpdateWrapper,有时候当前更新人和更新时间都是需要的,你也可以说数据库可以设置最后更新时间,但是最后修改人呢?

非常复杂的动态表名,拜托大哥我只是想改一下表名,目前的解决方案就是try-finally每次用完都需要清理一下当前线程,因为tomcat会复用线程,通过threadlocal来实现,话说pagehelper应该也是这种方式实现的吧
当然其他还有很多问题导致最终我没办法忍受,选择了自研框架,当然我的框架自研是参考了一部分的freesql和sqlsuagr的api,并且还有java的beetsql的实现和部分方法。毕竟站在巨人的肩膀上才能看的更远，不要问我为什么不参考mybatis的,我觉得mybatis已经把简单问题复杂化了,如果需要看懂他的代码是一件很得不偿失的事情,最终我发现我的选择是正确的,我通过参考beetsql的源码很快的清楚了java这边应该需要做的事情,为我编写后续框架节约了太多时间,这边也给beetsql打个广告 https://gitee.com/xiandafu/beetlsql

自研orm有哪些特点

easy-query一款无任何依赖的java全新高性能orm支持单表多表子查询逻辑删除多租户差异更新联级一对一一对多多对一多对多分库分表(支持跨表查询分页等) 动态表名数据库列高效加解密支持like crud拦截器原子更新 vo对象直接返回

文档地址 xuejm.gitee.io/easy-query-…

GITHUB地址 github.com/xuejmnet/ea…

GITEE地址 gitee.com/xuejm/easy-…

强类型,可以帮助团队在构建和查询数据的时候拥有id提示,并且易于后期维护。

泛型可以控制我们编写代码时候的一些低级错误,比如我只查询一张表,但是where语句里面可以使用不存在上下文的表作为条件,进一步限制和加强表达式

easy-query提供了三种模式分别是lambda,property,apt proxy其中lambda表达式方便重构维护,property只是性能最好,apt proxy方便维护,但是重构需要一起重构apt文件

单表查询

//根据条件查询表中的第一条记录

List<Topic> topics = easyQuery

                .queryable(Topic.class)

                .limit(1)

                .toList();

==> Preparing: SELECT t.`id`,t.`stars`,t.`title`,t.`create_time` FROM t_topic t LIMIT 1

<== Total: 1



//根据条件查询id为3的集合

List<Topic> topics = easyQuery

                .queryable(Topic.class)

                .where(o->o.eq(Topic::getId,"3").eq(Topic::geName,"4")

                .toList();



==> Preparing: SELECT t.`id`,t.`stars`,t.`title`,t.`create_time` FROM t_topic t WHERE t.`id` = ? AND t.`name` = ?

==> Parameters: 3(String),4(String)

<== Total: 1

多表

 Topic topic = easyQuery

                .queryable(Topic.class)

                //join 后面是双参数委托，参数顺序表示join表顺序，可以通过then函数切换

                .leftJoin(BlogEntity.class, (t, t1) -> t.eq(t1, Topic::getId, BlogEntity::getId))

                .where(o -> o.eq(Topic::getId, "3"))

                .firstOrNull();



==> Preparing: SELECT t.`id`,t.`stars`,t.`title`,t.`create_time` FROM t_topic t LEFT JOIN t_blog t1 ON t.`id` = t1.`id` WHERE t.`id` = ? LIMIT 1

==> Parameters: 3(String)

<== Total: 1



List<BlogEntity> blogEntities = easyQuery

                .queryable(Topic.class)

                //join 后面是双参数委托，参数顺序表示join表顺序，可以通过then函数切换

                .innerJoin(BlogEntity.class, (t, t1) -> t.eq(t1, Topic::getId, BlogEntity::getId))

                .where((t, t1) -> t1.isNotNull(BlogEntity::getTitle).then(t).eq(Topic::getId, "3"))

                //join查询select必须要带对应的返回结果,可以是自定义dto也可以是实体对象,如果不带对象则返回t表主表数据

                .select(BlogEntity.class, (t, t1) -> t1.columnAll())

                .toList();



==> Preparing: SELECT t1.`id`,t1.`create_time`,t1.`update_time`,t1.`create_by`,t1.`update_by`,t1.`deleted`,t1.`title`,t1.`content`,t1.`url`,t1.`star`,t1.`publish_time`,t1.`score`,t1.`status`,t1.`order`,t1.`is_top`,t1.`top` FROM t_topic t INNER JOIN t_blog t1 ON t.`id` = t1.`id` WHERE t1.`title` IS NOT NULL AND t.`id` = ?

==> Parameters: 3(String)

<== Total: 1

子查询



```java

//SELECT * FROM `t_blog` t1 WHERE t1.`deleted` = ? AND t1.`id` = ?

 Queryable<BlogEntity> subQueryable = easyQuery.queryable(BlogEntity.class)

                .where(o -> o.eq(BlogEntity::getId, "1"));





List<Topic> x = easyQuery

        .queryable(Topic.class).where(o -> o.exists(subQueryable.where(q -> q.eq(o, BlogEntity::getId, Topic::getId)))).toList();





==> Preparing: SELECT t.`id`,t.`stars`,t.`title`,t.`create_time` FROM `t_topic` t WHERE EXISTS (SELECT 1 FROM `t_blog` t1 WHERE t1.`deleted` = ? AND t1.`id` = ? AND t1.`id` = t.`id`)

==> Parameters: false(Boolean),1(String)

<== Time Elapsed: 3(ms)

<== Total: 1





//SELECT t1.`id` FROM `t_blog` t1 WHERE t1.`deleted` = ? AND t1.`id` = ?

Queryable<String> idQueryable = easyQuery.queryable(BlogEntity.class)

            .where(o -> o.eq(BlogEntity::getId, "123"))

            .select(String.class, o -> o.column(BlogEntity::getId));//如果子查询in string那么就需要select string，如果integer那么select要integer 两边需要一致

List<Topic> list = easyQuery

        .queryable(Topic.class).where(o -> o.in(Topic::getId, idQueryable)).toList();





==> Preparing: SELECT t.`id`,t.`stars`,t.`title`,t.`create_time` FROM `t_topic` t WHERE t.`id` IN (SELECT t1.`id` FROM `t_blog` t1 WHERE t1.`deleted` = ? AND t1.`id` = ?)

==> Parameters: false(Boolean),123(String)

<== Time Elapsed: 2(ms)

<== Total: 0

自定义逻辑删除





//@Component //如果是spring

public class MyLogicDelStrategy extends AbstractLogicDeleteStrategy {

    /**

     * 允许datetime类型的属性

     */

    private final Set<Class<?>> allowTypes=new HashSet<>(Arrays.asList(LocalDateTime.class));

    @Override

    protected SQLExpression1<WherePredicate<Object>> getPredicateFilterExpression(LogicDeleteBuilder builder,String propertyName) {

        return o->o.isNull(propertyName);

    }



    @Override

    protected SQLExpression1<ColumnSetter<Object>> getDeletedSQLExpression(LogicDeleteBuilder builder, String propertyName) {

//        LocalDateTime now = LocalDateTime.now();

//        return o->o.set(propertyName,now);

        //上面的是错误用法,将now值获取后那么这个now就是个固定值而不是动态值

        return o->o.set(propertyName,LocalDateTime.now())

                .set("deletedUser",CurrentUserHelper.getUserId());

    }



    @Override

    public String getStrategy() {

        return "MyLogicDelStrategy";

    }



    @Override

    public Set<Class<?>> allowedPropertyTypes() {

        return allowTypes;

    }

}



//为了测试防止数据被删掉,这边采用不存在的id

logicDelTopic.setId("11xx");

//测试当前人员

CurrentUserHelper.setUserId("easy-query");

long l = easyQuery.deletable(logicDelTopic).executeRows();



==> Preparing: UPDATE t_logic_del_topic_custom SET `deleted_at` = ?,`deleted_user` = ? WHERE `deleted_at` IS NULL AND `id` = ?

==> Parameters: 2023-04-01T23:15:13.944(LocalDateTime),easy-query(String),11xx(String)

<== Total: 0

差异更新

要注意是否开启了追踪spring-boot下用@EasyQueryTrack注解即可开启

是否将当前对象添加到了追踪上下文查询添加asTracking或者手动将查询出来的对象进行easyQuery.addTracking(Object entity)

TrackManager trackManager = easyQuery.getRuntimeContext().getTrackManager();

try{

        trackManager.begin();

        Topic topic = easyQuery.queryable(Topic.class)

                .where(o -> o.eq(Topic::getId, "7")).asTracking().firstNotNull("未找到对应的数据");

        String newTitle = "test123" + new Random().nextInt(100);

        topic.setTitle(newTitle);

        long l = easyQuery.updatable(topic).executeRows();

}finally {



        trackManager.release();

}

==> Preparing: UPDATE t_topic SET `title` = ? WHERE `id` = ?

==> Parameters: test1239(String),7(String)

<== Total: 1

关联查询

一对一

学生和学生地址

//数据库对像查询

           List<SchoolStudent> list1 = easyQuery.queryable(SchoolStudent.class)

                        .include(o -> o.one(SchoolStudent::getSchoolStudentAddress).asTracking().disableLogicDelete())

                        .toList();

//vo自定义列映射返回

List<SchoolStudentVO> list1 = easyQuery.queryable(SchoolStudent.class)

                        .include(o -> o.one(SchoolStudent::getSchoolStudentAddress).asTracking().disableLogicDelete())

                        .select(SchoolStudentVO.class,o->o.columnAll()

                                .columnInclude(SchoolStudent::getSchoolStudentAddress,SchoolStudentVO::getSchoolStudentAddress))

                        .toList();

多对一

学生和班级

//数据库对像查询

 List<SchoolStudent> list1 = easyQuery.queryable(SchoolStudent.class)

                        .include(o -> o.one(SchoolStudent::getSchoolClass))

                        .toList();

//自定义列

 List<SchoolStudentVO> list1 = easyQuery.queryable(SchoolStudent.class)

                        .include(o -> o.one(SchoolStudent::getSchoolClass))

                        .select(SchoolStudentVO.class,o->o

                                .columnAll()

                                .columnInclude(SchoolStudent::getSchoolClass,SchoolStudentVO::getSchoolClass,s->s.column(SchoolClassVO::getId))

                        )

                        .toList();



//vo自定义列映射返回

   List<SchoolStudentVO> list1 = easyQuery.queryable(SchoolStudent.class)

                        .include(o -> o.one(SchoolStudent::getSchoolClass))

                        .select(SchoolStudentVO.class,o->o

                                .columnAll()

                                .columnInclude(SchoolStudent::getSchoolClass,SchoolStudentVO::getSchoolClass)

                        )

                        .toList();

一对多

班级和学生

//数据库对像查询

 List<SchoolClass> list1 = easyQuery.queryable(SchoolClass.class)

                        .include(o -> o.many(SchoolClass::getSchoolStudents))

                        .toList();

//vo自定义列映射返回

       List<SchoolClassVO> list1 = easyQuery.queryable(SchoolClass.class)

                        .include(o -> o.many(SchoolClass::getSchoolStudents))

                        .select(SchoolClassVO.class,o->o.columnAll()

                                .columnIncludeMany(SchoolClass::getSchoolStudents,SchoolClassVO::getSchoolStudents))

                        .toList();

多对多

班级和老师

      List<SchoolClass> list2 = easyQuery.queryable(SchoolClass.class)

                .include(o -> o.many(SchoolClass::getSchoolTeachers,1))

                .toList();

  List<SchoolClassVO> list2 = easyQuery.queryable(SchoolClass.class)

                    .include(o -> o.many(SchoolClass::getSchoolTeachers))

                    .select(SchoolClassVO.class,o->o.columnAll()

                            .columnIncludeMany(SchoolClass::getSchoolTeachers,SchoolClassVO::getSchoolTeachers))

                    .toList();

动态报名

List<BlogEntity> blogEntities = easyQuery.queryable(BlogEntity.class)

                .asTable(a -> "aa_bb_cc")

                .where(o -> o.eq(BlogEntity::getId, "123")).toList();





==> Preparing: SELECT t.`id`,t.`create_time`,t.`update_time`,t.`create_by`,t.`update_by`,t.`deleted`,t.`title`,t.`content`,t.`url`,t.`star`,t.`publish_time`,t.`score`,t.`status`,t.`order`,t.`is_top`,t.`top` FROM aa_bb_cc t WHERE t.`deleted` = ? AND t.`id` = ?

==> Parameters: false(Boolean),123(String)

<== Total: 0







List<BlogEntity> blogEntities = easyQuery.queryable(BlogEntity.class)

                .asTable(a->{

                    if("t_blog".equals(a)){

                        return "aa_bb_cc1";

                    }

                    return "xxx";

                })

                .where(o -> o.eq(BlogEntity::getId, "123")).toList();





==> Preparing: SELECT t.`id`,t.`create_time`,t.`update_time`,t.`create_by`,t.`update_by`,t.`deleted`,t.`title`,t.`content`,t.`url`,t.`star`,t.`publish_time`,t.`score`,t.`status`,t.`order`,t.`is_top`,t.`top` FROM aa_bb_cc1 t WHERE t.`deleted` = ? AND t.`id` = ?

==> Parameters: false(Boolean),123(String)

<== Total: 0









List<BlogEntity> x_t_blog = easyQuery

                .queryable(Topic.class)

                .asTable(o -> "t_topic_123")

                .innerJoin(BlogEntity.class, (t, t1) -> t.eq(t1, Topic::getId, BlogEntity::getId))

                .asTable("x_t_blog")

                .where((t, t1) -> t1.isNotNull(BlogEntity::getTitle).then(t).eq(Topic::getId, "3"))

                .select(BlogEntity.class, (t, t1) -> t1.columnAll()).toList();



==> Preparing: SELECT t1.`id`,t1.`create_time`,t1.`update_time`,t1.`create_by`,t1.`update_by`,t1.`deleted`,t1.`title`,t1.`content`,t1.`url`,t1.`star`,t1.`publish_time`,t1.`score`,t1.`status`,t1.`order`,t1.`is_top`,t1.`top` FROM t_topic_123 t INNER JOIN x_t_blog t1 ON t1.`deleted` = ? AND t.`id` = t1.`id` WHERE t1.`title` IS NOT NULL AND t.`id` = ?

==> Parameters: false(Boolean),3(String)

<== Total: 0

最后

感谢各位看到最后,希望以后我的开源框架可以帮助到您,如果您觉得有用可以点点star,这将对我是极大的鼓励

更多文档信息可以参考git地址或者文档

文档地址 xuejm.gitee.io/easy-query-…

GITHUB地址 github.com/xuejmnet/ea…

GITEE地址 gitee.com/xuejm/easy-…

作者：xuejm
来源：juejin.cn/post/7259926933008908325

收起阅读 »

压缩炸弹，Java怎么防止

Java

一、什么是压缩炸弹，会有什么危害 1.1 什么是压缩炸弹压缩炸弹(ZIP)：一个压缩包只有几十KB，但是解压缩后有几十GB，甚至可以去到几百TB，直接撑爆硬盘，或者是在解压过程中CPU飙到100%造成服务器宕机。虽然系统功能没有自动解压，但是假如开发人员在不...

继续阅读 »

一、什么是压缩炸弹，会有什么危害

1.1 什么是压缩炸弹

压缩炸弹(ZIP)：一个压缩包只有几十KB，但是解压缩后有几十GB，甚至可以去到几百TB，直接撑爆硬盘，或者是在解压过程中CPU飙到100%造成服务器宕机。虽然系统功能没有自动解压，但是假如开发人员在不细心观察的情况下进行一键解压(不看压缩包里面的文件大小)，可导致压缩炸弹爆炸。又或者压缩炸弹藏在比较深的目录下，不经意的解压缩，也可导致压缩炸弹爆炸。

以下是安全测试几种经典的压缩炸弹

graph LR

A(安全测试的经典压缩炸弹)

B(zip文件42KB)

C(zip文件10MB)

D(zip文件46MB)

E(解压后5.5G)

F(解压后281TB)

G(解压后4.5PB)



A ---> B --解压--> E

A ---> C --解压--> F

A ---> D --解压--> G



style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style F fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style G fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

压缩炸弹（也称为压缩文件炸弹、炸弹文件）是一种特殊的文件，它在解压缩时会迅速膨胀成极其庞大的文件，可能导致系统资源耗尽、崩溃或磁盘空间耗尽。

压缩炸弹的原理是利用文件压缩算法中的重复模式和递归压缩的特性。它通常是一个非常小的压缩文件，但在解压缩时会生成大量的重复数据，导致文件大小迅速增长。这种文件的设计意图是迫使系统进行大量的解压缩操作，以消耗系统资源或填满磁盘空间。

压缩炸弹可能对系统造成严重的影响，包括系统崩溃、资源耗尽、拒绝服务攻击等。因此，它被视为一种恶意的计算机攻击工具，常常被用于恶意目的或作为安全测试中的一种工具。

1.2 压缩炸弹会有什么危害

graph LR

A(压缩炸弹的危害)

B(资源耗尽)

C(磁盘空间耗尽)

D(系统崩溃)

E(拒绝服务攻击)

F(数据丢失)



A ---> B

A ---> C

A ---> D

A ---> E

A ---> F



style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#98FB98,stroke:#98FB98,stroke-width:2px

style F fill:#00FFFF,stroke:#00FFFF,stroke-width:2px

压缩炸弹可能对计算机系统造成以下具体的破坏：

资源耗尽：压缩炸弹在解压缩时会生成大量的重复数据，导致系统的CPU、内存和磁盘资源被迅速占用。这可能导致系统反应迟缓、无法响应用户的请求，甚至系统崩溃。

磁盘空间耗尽：由于压缩炸弹的膨胀特性，它可能在解压缩过程中填满磁盘空间。这会导致系统无法写入新的数据，造成磁盘空间耗尽，影响系统的正常运行。

系统崩溃：当一个压缩炸弹被解压缩时，系统可能由于资源耗尽或磁盘空间耗尽而崩溃。这可能导致系统重启或需要进行紧急修复，造成数据丢失或系统不可用的情况。

拒绝服务攻击：大规模的解压缩操作可能消耗大量系统资源，导致系统无法正常提供服务。这被恶意攻击者利用，用于进行拒绝服务攻击，使目标系统无法响应合法用户的请求。

数据丢失：在某些情况下，压缩炸弹可能会导致系统文件或数据的损坏或丢失。这可能发生在磁盘空间被耗尽时，写入操作无法成功完成的情况下。

重要提示：压缩炸弹可能对计算机系统造成不可逆的损害，请不要尝试创建、传播或使用压缩炸弹，以保护计算机和网络的安全。

二、怎么检测和处理压缩炸弹，Java怎么防止压缩炸弹

2.1 个人有没有方法可以检测压缩炸弹？

有一些方法可以识别和处理潜在的压缩炸弹，以防止对系统造成破坏。以下是一些常见的方法：

graph LR

A(个人检测压缩炸弹)

B(安全软件和防病毒工具)

C(文件大小限制)

D(文件类型过滤)



A ---> B --> E(推荐)

A ---> C --> F(太大的放个心眼)

A ---> D --> G(注意不认识的文件类型)



style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style F fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style G fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

安全软件和防病毒工具（推荐）：使用最新的安全软件和防病毒工具可以帮助检测和阻止已知的压缩炸弹。这些工具通常具备压缩文件扫描功能，可以检查文件是否包含恶意的压缩炸弹。

文件大小限制：设置对文件大小的限制可以帮助防止解压缩过程中出现过大的文件。通过限制解压缩操作的最大文件大小，可以减少对系统资源和磁盘空间的过度消耗。

文件类型过滤：识别和过滤已知的压缩炸弹文件类型可以帮助阻止这些文件的传输和存储。通过检查文件扩展名或文件头信息，可以识别潜在的压缩炸弹，并阻止其传输或处理。

2.2 Java怎么防止压缩炸弹

在java中实际防止压缩炸弹的方法挺多的，可以采取以下措施来防止压缩炸弹：

graph LR

A(Java防止压缩炸弹)

B(解压缩算法的限制)

C(设置解压缩操作的资源限制)

D(使用安全的解压缩库)

E(文件类型验证和过滤)

F(异步解压缩操作)

G(安全策略和权限控制)



A ---> B

A ---> C

A ---> D

A ---> E

A ---> F

A ---> G



style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#98FB98,stroke:#98FB98,stroke-width:2px

style F fill:#ADD8E6,stroke:#ADD8E6,stroke-width:2px

style G fill:#00FFFF,stroke:#00FFFF,stroke-width:2px

解压缩算法的限制：限制解压缩算法的递归层数和重复模式的检测可以帮助防止解压缩过程无限膨胀。通过限制递归的深度和检测重复模式，可以及时中断解压缩操作并避免过度消耗资源。

设置解压缩操作的资源限制：使用Java的java.util.zip或java.util.jar等类进行解压缩时，可以设置解压缩操作的资源限制，例如限制解压缩的最大文件大小、最大递归深度等。通过限制资源的使用，可以减少对系统资源的过度消耗。

使用安全的解压缩库：确保使用的解压缩库是经过安全验证的，以避免存在已知的压缩炸弹漏洞。使用官方或经过广泛验证的库可以减少受到压缩炸弹攻击的风险。

文件类型验证和过滤：在解压缩之前，可以对文件进行类型验证和过滤，排除潜在的压缩炸弹文件。通过验证文件的类型、扩展名和文件头信息，可以识别并排除不安全的压缩文件。

异步解压缩操作：将解压缩操作放在异步线程中进行，以防止阻塞主线程和耗尽系统资源。这样可以保持应用程序的响应性，并减少对系统的影响。

安全策略和权限控制：实施严格的安全策略和权限控制，限制用户对系统资源和文件的访问和操作。确保只有受信任的用户或应用程序能够进行解压缩操作，以减少恶意使用压缩炸弹的可能性。

2.2.1 使用解压算法的限制来实现防止压缩炸弹

在前面我们说了Java防止压缩炸弹的一些策略，下面我将代码实现通过解压缩算法的限制来实现防止压缩炸弹。

先来看看我们实现的思路：

graph TD

    A(开始) --> B[创建 ZipFile 对象]

    B --> C[打开要解压缩的 ZIP 文件]

    C --> D[初始化 zipFileSize 变量为 0]

    D --> E{是否有更多的条目}

    E -- 是 --> F[获取 ZIP 文件的下一个条目]

    F --> G[获取当前条目的未压缩大小]

    G --> H[将解压大小累加到 zipFileSize 变量]

    H --> I{zipFileSize 是否超过指定的大小}

    I -- 是 --> J[调用 deleteDir方法删除已解压的文件夹]

    J --> K[抛出 IllegalArgumentException 异常]

    K --> L(结束)

    I -- 否 --> M(保存解压文件) --> E

    E -- 否 --> L

 

style A fill:#00FFFF,stroke:#00FFFF,stroke-width:2px

style B fill:#FFC0CB,stroke:#FFC0CB,stroke-width:2px

style C fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style D fill:#FFFFE0,stroke:#FFFFE0,stroke-width:2px

style E fill:#98FB98,stroke:#98FB98,stroke-width:2px

style F fill:#ADD8E6,stroke:#ADD8E6,stroke-width:2px

style G fill:#00FFFF,stroke:#00FFFF,stroke-width:2px

style H fill:#E6E6FA,stroke:#E6E6FA,stroke-width:2px

style I fill:#ADD8E6,stroke:#ADD8E6,stroke-width:2px

style J fill:#00FFFF,stroke:#00FFFF,stroke-width:2px

style K fill:#E6E6FA,stroke:#E6E6FA,stroke-width:2px

style L fill:#FFA07A,stroke:#FFA07A,stroke-width:2px

style M fill:#ADD8E6,stroke:#ADD8E6,stroke-width:2px

实现流程说明如下：

首先，通过给定的 file 参数创建一个 ZipFile 对象，用于打开要解压缩的 ZIP 文件。

zipFileSize 变量用于计算解压缩后的文件总大小。

使用 zipFile.entries() 方法获取 ZIP 文件中的所有条目，并通过 while 循环逐个处理每个条目。

对于每个条目，使用 entry.getSize() 获取条目的未压缩大小，并将其累加到 zipFileSize 变量中。

如果 zipFileSize 超过了给定的 size 参数，说明解压后的文件大小超过了限制，此时会调用 deleteDir() 方法删除已解压的文件夹，并抛出 IllegalArgumentException 异常，以防止压缩炸弹攻击。

创建一个 File 对象 unzipped，表示解压后的文件或目录在输出文件夹中的路径。

如果当前条目是一个目录，且 unzipped 不存在，则创建该目录。

如果当前条目不是一个目录，确保 unzipped 的父文件夹存在。

创建一个 FileOutputStream 对象 fos，用于将解压后的数据写入到 unzipped 文件中。

通过 zipFile.getInputStream(entry) 获取当前条目的输入流。

创建一个缓冲区 buffer，并使用循环从输入流中读取数据，并将其写入到 fos 中，直到读取完整个条目的数据。

最后，在 finally 块中关闭 fos 和 zipFile 对象，确保资源的释放。

实现代码工具类：

import java.io.File;

import java.io.FileOutputStream;

import java.io.InputStream;

import java.util.Enumeration;

import java.util.zip.ZipEntry;

import java.util.zip.ZipFile;



/**

 * 文件炸弹工具类

 *

 * @author bamboo panda

 * @version 1.0

 * @date 2023/10

 */

public class FileBombUtil {



    /**

     * 限制文件大小 1M（限制单位：B）[1M=1024KB 1KB=1024B]

     */

    public static final Long FILE_LIMIT_SIZE = 1024 * 1024 * 1L;



    /**

     * 文件超限提示

     */

    public static final String FILE_LIMIT_SIZE_MSG = "The file size exceeds the limit";



    /**

     * 解压文件（带限制解压文件大小策略）

     *

     * @param file         压缩文件

     * @param outputfolder 解压后的文件目录

     * @param size         限制解压之后的文件大小（单位：B），示例 3M：1024 * 1024 * 3L （FileBombUtil.FILE_LIMIT_SIZE * 3）

     * @throws Exception IllegalArgumentException 超限抛出的异常

     *                   注意：业务层必须抓取IllegalArgumentException异常，如果msg等于FILE_LIMIT_SIZE_MSG

     *                   要考虑后面的逻辑，比如告警

     */

    public static void unzip(File file, File outputfolder, Long size) throws Exception {

        ZipFile zipFile = new ZipFile(file);

        FileOutputStream fos = null;

        try {

            Enumeration<? extends ZipEntry> zipEntries = zipFile.entries();

            long zipFileSize = 0L;

            ZipEntry entry;

            while (zipEntries.hasMoreElements()) {

                // 获取 ZIP 文件的下一个条目

                entry = zipEntries.nextElement();

                // 将解缩大小累加到 zipFileSize 变量

                zipFileSize += entry.getSize();

                // 判断解压文件累计大小是否超过指定的大小

                if (zipFileSize > size) {

                    deleteDir(outputfolder);

                    throw new IllegalArgumentException(FILE_LIMIT_SIZE_MSG);

                }

                File unzipped = new File(outputfolder, entry.getName());

                if (entry.isDirectory() && !unzipped.exists()) {

                    unzipped.mkdirs();

                    continue;

                } else if (!unzipped.getParentFile().exists()) {

                    unzipped.getParentFile().mkdirs();

                }



                fos = new FileOutputStream(unzipped);

                InputStream in = zipFile.getInputStream(entry);



                byte[] buffer = new byte[4096];

                int count;

                while ((count = in.read(buffer, 0, buffer.length)) != -1) {

                    fos.write(buffer, 0, count);

                }

            }

        } finally {

            if (null != fos) {

                fos.close();

            }

            if (null != zipFile) {

                zipFile.close();

            }

        }



    }



    /**

     * 递归删除目录文件

     *

     * @param dir 目录

     */

    private static boolean deleteDir(File dir) {

        if (dir.isDirectory()) {

            String[] children = dir.list();

            //递归删除目录中的子目录下

            for (int i = 0; i < children.length; i++) {

                boolean success = deleteDir(new File(dir, children[i]));

                if (!success) {

                    return false;

                }

            }

        }

        // 目录此时为空，可以删除

        return dir.delete();

    }



}

测试类：

import java.io.File;



/**

 * 文件炸弹测试类

 *

 * @author bamboo panda

 * @version 1.0

 * @date 2023/10

 */

public class Test {



    public static void main(String[] args) {

        File bomb = new File("D:\temp\3\zbsm.zip");

        File tempFile = new File("D:\temp\3\4");

        try {

            FileBombUtil.unzip(bomb, tempFile, FileBombUtil.FILE_LIMIT_SIZE * 60);

        } catch (IllegalArgumentException e) {

            if (FileBombUtil.FILE_LIMIT_SIZE_MSG.equalsIgnoreCase(e.getMessage())) {

                FileBombUtil.deleteDir(tempFile);

                System.out.println("原始文件太大");

            } else {

                System.out.println("错误的压缩文件格式");

            }

        } catch (Exception e) {

            e.printStackTrace();

        }

    }



}

三、总结

文件炸弹是一种恶意的计算机程序或文件，旨在利用压缩算法和递归结构来创建一个巨大且无限增长的文件或文件集
合。它的目的是消耗目标系统的资源，如磁盘空间、内存和处理能力，导致系统崩溃或无法正常运行。文件炸弹可能是有意制造的攻击工具，用于拒绝服务（DoS）攻击或滥用资源的目的。

文件炸弹带来的危害极大，作为开发人员，我们必须深刻认识到文件炸弹的危害性，并始终保持高度警惕，以防止这种潜在漏洞给恐怖分子以可乘之机。

总而言之，我们作为开发人员，要深刻认识到文件炸弹的危害性，严防死守，不给恐怖分子任何可乘之机。通过使用安全工具、限制文件大小、及时更新软件、定期备份数据以及加强安全意识，我们可以有效地防止文件炸弹和其他恶意活动对系统造成损害。

在中国，网络安全和计算机犯罪问题受到相关法律法规的管理和监管。以下是一些中国关于网络安全和计算机犯罪方面的法律文献，其中也涉及到文件炸弹的相关规定：

《中华人民共和国刑法》- 该法律规定了各种计算机犯罪行为的法律责任，包括非法控制计算机信息系统、破坏计算机信息系统功能、非法获取计算机信息系统数据等行为，这些行为可能涉及到使用文件炸弹进行攻击。

《中华人民共和国网络安全法》- 该法律是中国的基本法律，旨在保障网络安全和维护国家网络空间主权。它规定了网络安全的基本要求和责任，包括禁止制作、传播软件病毒、恶意程序和文件炸弹等危害网络安全的行为。

《中华人民共和国计算机信息系统安全保护条例》- 这是一项行政法规，详细规定了计算机信息系统安全的保护措施和管理要求。其中包含了对恶意程序、计算机病毒和文件炸弹等威胁的防范要求。

作者：竹子爱揍功夫熊猫
来源：juejin.cn/post/7289667869557178404

收起阅读 »

一个项目代码讲清楚DO/PO/BO/AO/E/DTO/DAO/ POJO/VO

Java

在现代软件架构中，不同类型的类扮演着不同的角色，共同构成了一个清晰、模块化和可维护的系统。以下是对实体类（Entity）、数据传输对象（DTO）、领域对象（Domain Object）、持久化对象（Persistent Object）、业务对象（Busines...

继续阅读 »

在现代软件架构中，不同类型的类扮演着不同的角色，共同构成了一个清晰、模块化和可维护的系统。以下是对实体类（Entity）、数据传输对象（DTO）、领域对象（Domain Object）、持久化对象（Persistent Object）、业务对象（Business Object）、应用对象（Application Object）、数据访问对象（Data Access Object, DAO）、服务层（Service Layer）和控制器层（Controller Layer）的总体介绍：

不同领域作用

POJO (Plain Old Java Object)

定义：POJO 是一个简单的Java对象，它不继承任何特定的类或实现任何特定的接口，除了可能实现 java.io.Serializable 接口。它通常用于表示数据，不包含业务逻辑。

案例的体现：
- UserEntity 类可以看作是一个POJO，因为它主要包含数据字段和标准的构造函数、getter和setter方法。
- UserDTO 类也是一个POJO，它用于传输数据，不包含业务逻辑。

VO (Value Object)

定义：VO 是一个代表某个具体值或概念的对象，通常用于表示传输数据的结构，不涉及复杂的业务逻辑。

VO（View Object）的特点：

展示逻辑：VO通常包含用于展示的逻辑，例如格式化的日期或货币值。

用户界面相关：VO设计时会考虑用户界面的需求，可能包含特定于视图的属性。

可读性：VO可能包含额外的描述性信息，以提高用户界面的可读性。

实体类（Entity）

作用：代表数据库中的一个表，是数据模型的实现，通常与数据库表直接映射。

使用场景：当需要将应用程序的数据持久化到数据库时使用。

数据传输对象（DTO）

作用：用于在应用程序的不同层之间传输数据，特别是当需要将数据从服务层传输到表示层或客户端时。

使用场景：进行数据传输，尤其是在远程调用或不同服务间的数据交换时。

领域对象（Domain Object）

作用：代表业务领域的一个实体或概念，通常包含业务逻辑和业务状态。

使用场景：在业务逻辑层处理复杂的业务规则时使用。

持久化对象（Persistent Object）

作用：与数据存储直接交互的对象，通常包含数据访问逻辑。

使用场景：执行数据库操作，如CRUD（创建、读取、更新、删除）操作。

业务对象（Business Object）

作用：封装业务逻辑和业务数据，通常与领域对象交互。

使用场景：在业务逻辑层实现业务需求时使用。

应用对象（Application Object）

作用：封装应用程序的运行时配置和状态，通常不直接与业务逻辑相关。

使用场景：在应用程序启动或运行时配置时使用。

数据访问对象（Data Access Object, DAO）

作用：提供数据访问的抽象接口，定义了与数据存储交互的方法。

使用场景：需要进行数据持久化操作时，作为数据访问层的一部分。

服务层（Service Layer）

作用：包含业务逻辑和业务规则，协调应用程序中的不同组件。

使用场景：处理业务逻辑，执行业务用例。

控制器层（Controller Layer）

作用：处理用户的输入，调用服务层的方法，并返回响应结果。

使用场景：处理HTTP请求和响应，作为Web应用程序的前端和后端之间的中介。

案例介绍

用户注册：
- DTO：用户注册信息的传输。
- Entity：用户信息在数据库中的存储形式。
- Service Layer：验证用户信息、加密密码等业务逻辑。

商品展示：
- Entity：数据库中的商品信息。
- DTO：商品信息的传输对象，可能包含图片URL等不需要存储在数据库的字段。
- Service Layer：获取商品列表、筛选和排序商品等。

订单处理：
- Domain Object：订单的业务领域模型，包含订单状态等。
- Business Object：订单处理的业务逻辑。
- DAO：订单数据的持久化操作。

配置加载：
- Application Object：应用程序的配置信息，如数据库连接字符串。

API响应：
- Controller Layer：处理API请求，调用服务层，返回DTO作为响应。

案例代码

视图对象（VO）

一个订单系统，我们需要在用户界面展示订单详情：

// OrderDTO - 数据传输对象

public class OrderDTO {

    private Long id;

    private String customerName;

    private BigDecimal totalAmount;

    // Constructors, getters and setters

}



// OrderVO - 视图对象

public class OrderVO {

    private Long id;

    private String customerFullName; // 格式化后的顾客姓名

    private String formattedTotal; // 格式化后的总金额，如"$1,234.56"

    private String orderDate; // 格式化后的订单日期



    // Constructors, getters and setters



    public OrderVO(OrderDTO dto) {

        this.id = dto.getId();

        this.customerFullName = formatName(dto.getCustomerName());

        this.formattedTotal = formatCurrency(dto.getTotalAmount());

        this.orderDate = formatDateTime(dto.getOrderDate());

    }



    private String formatName(String name) {

        // 实现姓名格式化逻辑

        return name;

    }



    private String formatCurrency(BigDecimal amount) {

        // 实现货币格式化逻辑

        return "$" + amount.toString();

    }



    private String formatDateTime(Date date) {

        // 实现日期时间格式化逻辑

        return new SimpleDateFormat("yyyy-MM-dd").format(date);

    }

}

实体类（Entity）



package com.example.model;



import javax.persistence.*;



@Entity

@Table(name = "users")

public class UserEntity {

    @Id

    @GeneratedValue(strategy = GenerationType.IDENTITY)

    private Long id;



    @Column(nullable = false, unique = true)

    private String username;



    @Column(nullable = false)

    private String password;



    // Constructors, getters and setters

    public UserEntity() {}



    public UserEntity(String username, String password) {

        this.username = username;

        this.password = password;

    }



    public Long getId() {

        return id;

    }



    public void setId(Long id) {

        this.id = id;

    }



    public String getUsername() {

        return username;

    }



    public void setUsername(String username) {

        this.username = username;

    }



    public String getPassword() {

        return password;

    }



    public void setPassword(String password) {

        this.password = password;

    }

}

数据传输对象（DTO）



package com.example.dto;



public class UserDTO {

    private Long id;

    private String username;



    // Constructors, getters and setters

    public UserDTO() {}



    public UserDTO(Long id, String username) {

        this.id = id;

        this.username = username;

    }



    public Long getId() {

        return id;

    }



    public void setId(Long id) {

        this.id = id;

    }



    public String getUsername() {

        return username;

    }



    public void setUsername(String username) {

        this.username = username;

    }

}

领域对象（Domain Object）



package com.example.domain;



public class UserDomain {

    private Long id;

    private String username;



    // Business logic methods

    public UserDomain() {}



    public UserDomain(Long id, String username) {

        this.id = id;

        this.username = username;

    }



    public Long getId() {

        return id;

    }



    public void setId(Long id) {

        this.id = id;

    }



    public String getUsername() {

        return username;

    }



    public void setUsername(String username) {

        this.username = username;

    }



    // Additional domain-specific methods

}

领域对象通常包含业务领域内的概念和逻辑。在订单系统中，这可能包括订单状态、订单项、总价等。

package com.example.domain;



import java.util.List;



public class OrderDomain {

    private String orderId;

    private List items; // 订单项列表

    private double totalAmount;

    private OrderStatus status; // 订单状态



    // Constructors, getters and setters



    public OrderDomain(String orderId, List items) {

        this.orderId = orderId;

        this.items = items;

        this.totalAmount = calculateTotalAmount();

        this.status = OrderStatus.PENDING; // 默认状态为待处理

    }



    private double calculateTotalAmount() {

        double total = 0;

        for (OrderItemDomain item : items) {

            total += item.getPrice() * item.getQuantity();

        }

        return total;

    }



    // 业务逻辑方法，例如更新订单状态

    public void processPayment() {

        // 处理支付逻辑

        if (/* 支付成功条件 */) {

            this.status = OrderStatus.PAYMENT_COMPLETED;

        }

    }



    // 更多业务逻辑方法...

}

持久化对象（Persistent Object）



package com.example.model;



public class UserPersistent extends UserEntity {

    // Methods to interact with persistence layer, extending UserEntity

}

业务对象（Business Object）



package com.example.service;



public class UserBO {

    private UserDomain userDomain;



    public UserBO(UserDomain userDomain) {

        this.userDomain = userDomain;

    }



    // Business logic methods

    public void performBusinessLogic() {

        // Implement business logic

    }

}

OrderBO 业务对象通常封装业务逻辑，可能包含领域对象，并提供业务操作的方法。

package com.example.service;



import com.example.domain.OrderDomain;



public class OrderBO {

    private OrderDomain orderDomain;



    public OrderBO(OrderDomain orderDomain) {

        this.orderDomain = orderDomain;

    }



    // 执行订单处理的业务逻辑

    public void performOrderProcessing() {

        // 例如，处理订单支付

        orderDomain.processPayment();

        // 其他业务逻辑...

    }



    // 更多业务逻辑方法...

}

应用对象（Application Object）



package com.example.config;



public class AppConfig {

    private String environment;

    private String configFilePath;



    public AppConfig() {

        // Initialize with default values or environment-specific settings

    }



    // Methods to handle application configuration

    public void loadConfiguration() {

        // Load configuration from files, environment variables, etc.

    }



    // Getters and setters

}

数据访问对象（Data Access Object）



package com.example.dao;



import com.example.model.UserEntity;

import org.springframework.data.jpa.repository.JpaRepository;

import org.springframework.stereotype.Repository;



@Repository

public interface UserDAO extends JpaRepository {

    // Custom data access methods if needed

    UserEntity findByUsername(String username);

}

- OrderDAO DAO 提供数据访问的抽象接口，定义了与数据存储交互的方法。在Spring Data JPA中，可以继承JpaRepository并添加自定义的数据访问方法。

package com.example.dao;



import com.example.domain.OrderDomain;

import org.springframework.data.jpa.repository.JpaRepository;



public interface OrderDAO extends JpaRepository { // 主键类型为String

    // 自定义数据访问方法，例如根据订单状态查询订单

    List findByStatus(OrderStatus status);

}

服务层（Service Layer）



package com.example.service;



import com.example.dao.UserDAO;

import com.example.dto.UserDTO;

import com.example.model.UserEntity;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.stereotype.Service;



@Service

public class UserService {

    private final UserDAO userDAO;



    @Autowired

    public UserService(UserDAO userDAO) {

        this.userDAO = userDAO;

    }



    public UserDTO getUserById(Long id) {

        UserEntity userEntity = userDAO.findById(id).orElseThrow(() -> new RuntimeException("User not found"));

        return convertToDTO(userEntity);

    }



    private UserDTO convertToDTO(UserEntity entity) {

        UserDTO dto = new UserDTO();

        dto.setId(entity.getId());

        dto.setUsername(entity.getUsername());

        return dto;

    }



    // Additional service methods

}

OrderService服务层协调用户输入、业务逻辑和数据访问。它使用DAO进行数据操作，并可能使用业务对象来执行业务逻辑。

package com.example.service;



import com.example.dao.OrderDAO;

import com.example.domain.OrderDomain;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.stereotype.Service;



import java.util.List;



@Service

public class OrderService {

    private final OrderDAO orderDAO;



    @Autowired

    public OrderService(OrderDAO orderDAO) {

        this.orderDAO = orderDAO;

    }



    public List findAllOrders() {

        return orderDAO.findAll();

    }



    public OrderDomain getOrderById(String orderId) {

        return orderDAO.findById(orderId).orElseThrow(() -> new RuntimeException("Order not found"));

    }



    public void processOrderPayment(String orderId) {

        OrderDomain order = getOrderById(orderId);

        OrderBO orderBO = new OrderBO(order);

        orderBO.performOrderProcessing();

        // 更新订单状态等逻辑...

    }



    // 更多服务层方法...

}

控制器层（Controller Layer）



package com.example.controller;



import com.example.dto.UserDTO;

import com.example.service.UserService;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.web.bind.annotation.*;



@RestController

@RequestMapping("/users")

public class UserController {

    private final UserService userService;



    @Autowired

    public UserController(UserService userService) {

        this.userService = userService;

    }



    @GetMapping("/{id}")

    public UserDTO getUser(@PathVariable Long id) {

        return userService.getUserById(id);

    }



    // Additional controller endpoints

}

总结

这些不同类型的类和层共同构成了一个分层的软件架构，每一层都有其特定的职责和功能。这种分层方法有助于降低系统的复杂性，提高代码的可维护性和可扩展性。通过将业务逻辑、数据访问和用户界面分离，开发人员可以独立地更新和测试每个部分，从而提高开发效率和应用程序的稳定性。

历史热点文章

命令模式（Command Pattern）:网络爬虫任务队列实战案例分析

迭代器模式（Iterator Pattern）：电商平台商品分类浏览实战案例分析

中介者模式（Mediator Pattern）:即时通讯软件实战案例分析

备忘录模式（Memento Pattern）:游戏存档系统实战案例分析

状态模式（State Pattern）:电商平台订单状态管理实战案例分析

责任链模式（Chain of Responsibility Pattern）：电商平台的订单审批流程实战案例分析

访问者模式（Visitor Pattern）:电商平台商品访问统计实战案例分析

工厂方法模式（Factory Method Pattern）: 电商多种支付实战案例分析

抽象工厂模式（Abstract Factory Pattern）：多风格桌面应用实战案例分析

建造者模式（Builder Pattern）：在线订单系统实战案例分析

原型模式（Prototype Pattern）: 云服务环境配置实战案例分析

适配器模式（Adapter Pattern）:第三方支付集成实战案例分析

装饰器模式（Decorator Pattern）:电商平台商品价格策略实战案例分析

单例模式（Singleton Pattern）：购物车实战案例分析

作者：肖哥弹架构
来源：juejin.cn/post/7389212915302105098

收起阅读 »

我去，怎么http全变https了

综合技术讨论

项目场景：在公司做的一个某地可视化项目。部署采用的是前后端分离部署，图片等静态资源请求一台minio服务器。项目平台用的是http图片资源的服务器用的是https 问题描述在以https请求图片资源时，图片请求成功报200。【现象1】: 继图片后续...

继续阅读 »

项目场景：

在公司做的一个某地可视化项目。

部署采用的是前后端分离部署，图片等静态资源请求一台minio服务器。

项目平台用的是http
图片资源的服务器用的是https

问题描述

在以https请求图片资源时，图片请求成功报200。

【现象1】: 继图片后续的请求，后续此域名和子域名下的的url均由http变为https

【现象2】: 界面阻塞报错，无法交互

原因分析：

经过现象查阅，发现出现该现象与浏览器的HSTS有关。

什么是HSTS ?

HTTP的Strict-Transport-Security（HSTS）请求头是一种网络安全机制，用于告诉浏览器仅通过HTTPS与服务器通信，而不是HTTP。它的作用主要有以下几点：

防止协议降级攻击：当浏览器接收到HSTS响应头后，它会将该网站添加到HSTS列表中，并在后续的访问中强制使用HTTPS，即使用户或攻击者尝试通过HTTP访问该网站，浏览器也会自动将其重定向到HTTPS。

减少中间人攻击的风险：通过确保所有通信都通过加密的HTTPS进行，可以降低中间人攻击（MITM）的风险，因为攻击者无法轻易地截获或篡改传输的数据。

提高网站的安全性：HSTS可以作为网站安全策略的一部分，帮助保护用户的敏感信息，如登录凭据、支付信息等。

简化安全配置：对于网站管理员来说，HSTS可以减少需要维护的安全配置，因为浏览器会自动处理HTTPS的重定向。

提高用户体验：由于浏览器会自动处理重定向，用户不需要担心访问的是HTTP还是HTTPS版本，可以更顺畅地浏览网站。

HSTS的配置可以通过max-age指令来设置浏览器应该记住这个策略的时间长度，还可以使用includeSubDomains指令来指示所有子域名也应该遵循这个策略。此外，还有一个preload选项，允许网站所有者将他们的网站添加到浏览器的预加载HSTS列表中，这样用户在第一次访问时就可以立即应用HSTS策略。

于是在我发现该相关的响应头确有此物

解决方案：

那就取决于服务器是在哪里设置的该请求头。可能是在Nginx,Lighttpd,PHP等等，将该响应头配置去除

作者：阿亻
来源：juejin.cn/post/7382386471272448035

收起阅读 »

再有人问你WebSocket为什么牛逼，就把这篇文章发给他！

Java

点赞再看，Java进阶一大半 2008年6月诞生了一个影响计算机世界的通信协议，原先需要二十台计算机资源才能支撑的业务场景，现在只需要一台，这得帮"抠门"老板们省下多少钱，它就是大名鼎鼎的WebSocket协议。很快在下一年也就是2009年的12月，Goog...

继续阅读 »

点赞再看，Java进阶一大半

2008年6月诞生了一个影响计算机世界的通信协议，原先需要二十台计算机资源才能支撑的业务场景，现在只需要一台，这得帮"抠门"老板们省下多少钱，它就是大名鼎鼎的WebSocket协议。很快在下一年也就是2009年的12月，Google浏览器就宣布成为第一个支持WebSocket标准的浏览器。

WebSocket的推动者和设计者就是下面的Michael Carter，他设计的WebSocket协议技术现在每天在全地球有超过20亿的设备在使用。

逮嘎猴，我是南哥。

一个Java进阶的领路人，今天指南的是WebSocket，跟着南哥我们一起Java进阶。

本文收录在我开源的《Java进阶指南》中，一份帮助小伙伴们进阶Java、通关面试的Java学习面试指南，相信能帮助到你在Java进阶路上不迷茫。南哥希望收到大家的 ⭐ Star ⭐支持，这是我创作的最大动力。GitHub地址：github.com/hdgaadd/Jav…。

1. WebSocket概念

1.1 为什么会出现WebSocket

面试官：有了解过WebSocket吗？

一般的Http请求我们只有主动去请求接口，才能获取到服务器的数据。例如前后端分离的开发场景，自嘲为切图仔实际扮猪吃老虎的前端大佬找你要一个配置信息的接口，我们后端开发三下两下开发出一个RESTful架构风格的API接口，只有当前端主动请求，后端接口才会响应。

但上文这种基于HTTP的请求-响应模式并不能满足实时数据通信的场景，例如游戏、聊天室等实时业务场景。现在救世主来了，WebSocket作为一款主动推送技术，可以实现服务端主动推送数据给客户端。大家有没听说过全双工、半双工的概念。

全双工通信允许数据同时双向流动，而半双工通信则是数据交替在两个方向上传输，但在任一时刻只能一个方向上有数据流动

HTTP通信协议就是半双工，而数据实时传输需要的是全双工通信机制，WebSocket采用的便是全双工通信。举个微信聊天的例子，企业微信炸锅了，有成百条消息轰炸你手机，要实现这个场景，大家要怎么设计？用iframe、Ajax异步交互技术配合以客户端长轮询不断请求服务器数据也可以实现，但造成的问题是服务器资源的无端消耗，运维大佬直接找到你工位来。显然服务端主动推送数据的WebSocket技术更适合聊天业务场景。

1.2 WebSocket优点

面试官：为什么WebSocket可以减少资源消耗？

大家先看看传统的Ajax长轮询和WebSocket性能上掰手腕谁厉害。在websocket.org网站提供的Use Case C的测试里，客户端轮询频率为10w/s，使用Poling长轮询每秒需要消耗高达665Mbps，而我们的新宠儿WebSocet仅仅只需要花费1.526Mbps，435倍的差距！！

为什么差距会这么大？南哥告诉你，WebSocket技术设计的目的就是要取代轮询技术和Comet技术。Http消息十分冗长和繁琐，一个Http消息就要包含了起始行、消息头、消息体、空行、换行符，其中请求头Header非常冗长，在大量Http请求的场景会占用过多的带宽和服务器资源。

大家看下百度翻译接口的Http请求，拷贝成curl命令是非常冗长的，可用的消息肉眼看过去没多少。

curl ^"https://fanyi.baidu.com/mtpe-individual/multimodal?query=^%^E6^%^B5^%^8B^%^E8^%^AF^%^95&lang=zh2en^" ^

  -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7" ^

  -H "Accept-Language: zh-CN,zh;q=0.9" ^

  -H "Cache-Control: max-age=0" ^

  -H "Connection: keep-alive" ^

  -H ^"Cookie: BAIDUID=C8FA8569F446CB3F684CCD2C2B32721E:FG=1; BAIDUID_BFESS=C8FA8569F446CB3F684CCD2C2B32721E:FG=1; ab_sr=1.0.1_NDhjYWQyZmRjOWIwYjI3NTNjMGFiODExZWFiMWU4NTY4MjA2Y2UzNGQwZjJjZjI1OTdlY2JmOThlNzk1ZDAxMDljMTA2NTMxYmNlM1OTQ1MTE0ZTI3Y2M0NTIzMzdkMmU2MGMzMjc1OTRiM2EwNTJQ==; RT=^\^"z=1&dm=baidu.com&si=b9941642-0feb-4402-ac2b-a913a3eef1&ss=ly866fx&sl=4&tt=38d&bcn=https^%^3A^%^2F^%^2Ffclog.baidu.com^%^2Flog^%^2Fweirwood^%^3Ftype^%^3Dp&ld=ccy&ul=jes^\^"^" ^

  -H "Sec-Fetch-Dest: document" ^

  -H "Sec-Fetch-Mode: navigate" ^

  -H "Sec-Fetch-Site: same-origin" ^

  -H "Sec-Fetch-User: ?1" ^

  -H "Upgrade-Insecure-Requests: 1" ^

  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36" ^

  -H ^"sec-ch-ua: ^\^"Not/A)Brand^\^";v=^\^"8^\^", ^\^"Chromium^\^";v=^\^"126^\^", ^\^"Google Chrome^\^";v=^\^"126^\^"^" ^

  -H "sec-ch-ua-mobile: ?0" ^

  -H ^"sec-ch-ua-platform: ^\^"Windows^\^"^" &

而WebSocket是基于帧传输的，只需要做一次握手动作就可以让客户端和服务端形成一条通信通道，这仅仅只需要2个字节。我搭建了一个SpringBoot集成的WebSocket项目，浏览器拷贝WebSocket的Curl命令十分简洁明了，大家对比下。

curl "ws://localhost:8080/channel/echo" ^

  -H "Pragma: no-cache" ^

  -H "Origin: http://localhost:8080" ^

  -H "Accept-Language: zh-CN,zh;q=0.9" ^

  -H "Sec-WebSocket-Key: VoUk/1sA1lGGgMElV/5RPQ==" ^

  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36" ^

  -H "Upgrade: websocket" ^

  -H "Cache-Control: no-cache" ^

  -H "Connection: Upgrade" ^

  -H "Sec-WebSocket-Version: 13" ^

  -H "Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits"

如果你要区分Http请求或是WebSocket请求很简单，WebSocket请求的请求行前缀都是固定是ws://。

2. WebSocket实践

2.1 集成WebSocket服务器

面试官：有没动手实践过WebSocket？

大家要在SpringBoot使用WebSocket的话，可以集成spring-boot-starter-websocket，引入南哥下面给的pom依赖。

	<dependencies>

		<dependency>

			<groupId>org.springframework.bootgroupId>

			<artifactId>spring-boot-starter-websocketartifactId>

		dependency>

	dependencies>

感兴趣点开spring-boot-starter-websocket依赖的话，你会发现依赖所引用包名为package jakarta.websocket。这代表SpringBoot其实是集成了Java EE开源的websocket项目。这里有个小故事，Oracle当年决定将Java EE移交给Eclipse基金会后，Java EE就进行了改名，现在Java EE更名为Jakarta EE。Jakarta是雅加达的意思，有谁知道有什么寓意吗，评论区告诉我下？

我们的程序导入websocket依赖后，应用程序就可以看成是一台小型的WebSocket服务器。我们通过@ServerEndpoint可以定义WebSocket服务器对客户端暴露的接口。

@ServerEndpoint(value = "/channel/echo")

而WebSocket服务器要推送消息给到客户端，则使用package jakarta.websocket下的Session对象，调用sendText发送服务端消息。

    private Session session;

    

    @OnMessage

    public void onMessage(String message) throws IOException{

        LOGGER.info("[websocket] 服务端收到客户端{}消息：message={}", this.session.getId(), message);

        this.session.getAsyncRemote().sendText("halo, 客户端" + this.session.getId());

    }

看下getAsyncRemote方法返回的对象，里面是一个远程端点实例。

    RemoteEndpoint.Async getAsyncRemote();

2.2 客户端发送消息

面试官：那客户端怎么发送消息给服务器？

客户端发送消息要怎么操作？这点还和Http请求很不一样。后端开发出接口后，我们在Swagger填充参数，点击Try it out，Http请求就发过去了。

但WebSocket需要我们在浏览器的控制台上操作，例如现在南哥要给我们的WebSocket服务器发送Halo，JavaGetOffer，可以在浏览器的控制台手动执行以下命令。

websocket.send("Halo，JavaGetOffer");

实践的操作界面如下。

作者：Java进阶指南针
来源：juejin.cn/post/7388025457821810698

收起阅读 »

MySQL 9.0 创新版发布，大失所望。。

综合技术讨论

大家好，我是程序员鱼皮。2024 年 7 月 1 日，MySQL 发布了 9.0 创新版本。区别于我们大多数开发者常用的 LTS（Long-Term Support）长期支持版本，创新版本的发布会更频繁、会更快地推出新的特性和变更，可以理解为 “尝鲜版”，适合...

继续阅读 »

大家好，我是程序员鱼皮。2024 年 7 月 1 日，MySQL 发布了 9.0 创新版本。区别于我们大多数开发者常用的 LTS（Long-Term Support）长期支持版本，创新版本的发布会更频繁、会更快地推出新的特性和变更，可以理解为 “尝鲜版”，适合追求前沿技术的同学体验。

我通过阅读官方文档，完整了解了本次发布的新特性，结果怎么说呢，唉，接着往下看吧。。。

下面鱼皮带大家 “尝尝鲜”，来看看 MySQL 9.0 创新版本有哪些主要的变化。

新特性

1、Event 相关 SQL 语句可以被 Prepared

在 MySQL 中，事件（Events）是一种可以在预定时间执行的调度任务，比如定期清理数据之类的，就可以使用事件。

MySQL 9.0 对事件 SQL 提供了 Prepared 支持，包括：

CREATE EVENT

ALTER EVENT

DROP EVENT

prepared 准备语句是一种预编译的 SQL 语句模板，可以在执行时动态地传入参数，从而提高查询的性能和安全性。

比如下面就是一个准备语句，插入的数据可以动态传入：

PREPARE stmt_insert_employee FROM 'INSERT INTO employees (name, salary) VALUES (?, ?)';

2、Performance Schema 新增 2 张表

MySQL 的 Performance Schema 是一个用于监视 MySQL 服务器性能的工具。它提供了一组动态视图和表，记录了 MySQL 服务器内部的活动和资源使用情况，帮助开发者进行性能分析、调优和故障排除。

本次新增的表：

variables_metadata 表：提供关于系统变量的一般信息。包括 MySQL 服务器识别的每个系统变量的名称、作用域、类型、范围和描述。此表的 MIN_VALUE 和 MAX_VALUE 列旨在取代已弃用的 variables_info 表的 MIN_VALUE 和 MAX_VALUE 列。

global_variable_attributes 表：提供有关服务器分配给全局系统变量的属性-值对的信息。

3、SQL 语句优化

现在可以使用以下语法将 EXPLAIN ANALYZE（分析查询执行计划和性能的工具）的 JSON 输出保存到用户变量中：

EXPLAIN ANALYZE FORMAT=JSON INTO @variable select_stmt

随后，可以将这个变量作为 MySQL 的任何 JSON 函数的 JSON 参数使用。

4、向量存储

AI 的发展带火了向量数据库，我们可以利用向量数据库存储喂给 AI 的知识库和文档。

虽然 MySQL 官方更新日志中并没有提到对于向量数据存储的支持，但是网上有博主在 MySQL 9.0 社区版中进行了测试，发现其实已经支持了向量存储，如图：

在此之前，MySQL 推出过一个专门用于分析处理和高性能查询的数据库变体 HeatWave，本来以为只会在 HeatWave 中支持向量存储，没想到社区版也能使用。如果是真的，那可太好了。

5、其他

此外，还优化了 Windows 系统上 MySQL 的安装和使用体验。

废弃和移除

1）在 MySQL 8.0 中，已移除了在 MySQL 8.0 中已废弃的 mysql_native_password 认证插件，并且服务器现在拒绝来自没有 CLIENT_PLUGIN_AUTH 能力的旧客户端程序的 mysql_native 认证请求。为了向后兼容性，mysql_native_password 仍然在客户端上可用；客户端内置的认证插件已转换为动态加载插件。

这些更改还涉及移除以下服务器选项和变量：

--mysql-native-password 服务器选项

--mysql-native-password-proxy-users 服务器选项

default_authentication_plugin 服务器系统变量

2）Performance Schema 中 variables_info 表的 MIN_VALUE 和 MAX_VALUE 列现在已废弃，并可能在将来的 MySQL 版本中移除。开发者应该改为使用 variables_metadata 表的 MIN_VALUE 和 MAX_VALUE 列。

3）ER_SUBQUERY_NO_1_ROW 已从忽略包含 IGNORE 关键字的语句的错误列表中移除。这样做的原因如下：

忽略这类错误有时会导致将 NULL 插入非空列（对于未转换的子查询），或者根本不插入任何行（使用 subquery_to_derived 的子查询）。

当子查询转换为与派生表联接时，行为与未转换查询不同。

升级到 9.0 后，如果包含 SELECT 语句的 UPDATE、DELETE 或 INSERT 语句使用了包含多行结果的标量子查询，带有 IGNORE 关键字的语句可能会引发错误。

总结

看了本次 MySQL 9.0 创新版的更新，说实话，大失所望。在这之前，网上有很多关于 MySQL 9.0 版本新特性的猜测，结果基本上都没有出现。毕竟距离 MySQL 上一次发布的大版本 8.0 已经时隔 6 年，本来以为这次 MySQL 会有一些王炸的新特性，结果呢，本次除了修复了 100 多个 Bug 之外，几乎没啥对开发者有帮助的点。别说没帮助了，我估计很多同学在看这篇文章前都没接触过这些有变更的特性。

我们最关注的，无非就是使用难度、成本和性能提升对吧，最好是什么代码都不用改，直接升级个数据库的版本，性能提升个几倍，还能跟老板吹一波牛皮。

你看看隔壁的 PostgreSQL，这几年，都已经从 11 更新到 17 版本了，AI 时代人家也早就能通过插件支持存储向量数据了。MySQL 你这真的是创新么？

最后，MySQL 9.0 创新版本的下载地址我就不放了，咱还是老老实实用 5.7 和 8.0 版本，MySQL 的新版本，还有很长一条路要走呀！

作者：程序员鱼皮
来源：juejin.cn/post/7387999151411920931

收起阅读 »

.zip 结尾的域名很危险吗？有多危险？

综合技术讨论

Google 于 2023 年 5 月 10 日全面开放了以 .zip 结尾的域名，这一举动引起了安全研究人员和社区的警惕，他们担心该通用顶级域名（gTLD，Generic top-level domains）会被用于创建足以迷惑计算机高手的恶意 URL。 2...

继续阅读 »

Google 于 2023 年 5 月 10 日全面开放了以 .zip 结尾的域名，这一举动引起了安全研究人员和社区的警惕，他们担心该通用顶级域名（gTLD，Generic top-level domains）会被用于创建足以迷惑计算机高手的恶意 URL。

2023 年 5 月 3 日，Google 宣布了包括 .zip 和 .mov 在内的 8 个全新的通用顶级域名：

.dad

.phd

.prof

.esq

.foo

.zip

.mov

.nexus

并于 5 月 10 日通过 Google Domains 向公众开放注册。

Google Domains 是 Google 提供的一项域名注册和管理服务，支持用户搜索和注册域名

小心！含有 .zip 的恶意 URL

安全研究员 Bobby Rauch 指出（The Dangers of Google’s .zip TLD），要警惕含有 .zip、Unicode 字符（特别是 U+2044、U+2215 等）以及 @ 符号的恶意 URL。这类恶意 URL 迷惑性极强，甚至能欺骗十分有经验的用户。

若点击 https://google.com@bing.com 这个 URL，实际访问的是 https://bing.com。这是因为根据 RFC 3986 Uniform Resource Identifier (URI): Generic Syntax 的规定，@ 符号之前的 google.com 应识别为用户信息，其后的 bing.com 才是主机名（域名）。我们可以借助常用的编程语言来确认这一点，如利用 PHP 的 parse_url() 函数：

<?php

var_dump(parse_url("https://google.com@bing.com"));

array(3) {

  ["scheme"]=>

  string(5) "https"

  ["host"]=>

  string(8) "bing.com"

  ["user"]=>

  string(10) "google.com"

}

然而，若 @ 之前有正斜杠 /，如 https://google.com/search@bing.com，则浏览器会将 /search@bing.com 部分识别为路径，最终访问的是 https://google.com/ 下的文件 search@bing.com。由于没有这个文件，结果自然是 404。

<?php

var_dump(parse_url("https://google.com/search@bing.com"));

array(3) {

  ["scheme"]=>

  string(5) "https"

  ["host"]=>

  string(10) "google.com"

  ["path"]=>

  string(16) "/search@bing.com"

}

Bobby Rauch 就是利用了上述规则，创建了一个恶意 URL，

https://github.com∕kubernetes∕kubernetes∕archive∕refs∕tags∕@v1271.zip

乍看之下，这个 URL 似乎是用于从 GitHub 上下载 v1271 这个特定版本的 Kubernetes 的链接。但实际上 parse_url() 函数的解析结果显示，真正要访问的域名却是 v1271.zip 而不是 github.com：

<?php

var_dump(parse_url("https://github.com∕kubernetes∕kubernetes∕archive∕refs∕tags∕@v1271.zip"));

array(3) {

  ["scheme"]=>

  string(5) "https"

  ["host"]=>

  string(9) "v1271.zip"

  ["user"]=>

  string(63) "github.com?__kubernetes?__kubernetes?__archive?__refs?__tags?__"

}

若你不小心点击了这类域名，那么恭喜你，很可能喜提一个 evil.exe（请注意动画演示中的左下角）。

仅凭肉眼可能难以分辨以下两个 URL 的区别吧：

https://github.com∕kubernetes∕kubernetes∕archive∕refs∕tags∕

https://github.com/kubernetes/kubernetes/archive/refs/tags/

但若调整一下字体，则可以发现端倪，

恶意 URL 中的正斜杠 / 根本不是真正的 /（U+002F），

而是下面这个看起来很像 / 的 Unicode 字符：

由于恶意 URL 中并没有使用真正的 /，因此根据 RFC 3986 的规定，@ 之前的部分github.com∕kubernetes∕kubernetes∕archive∕refs∕tags∕ 尽管看似域名与路径，但实际上却是用户信息（真够长的）。

在刚刚的动画演示中，Bobby Rauch 其实还使用了另一个迷惑人的小伎俩——在电子邮件客户端上，将 @ 的字号大小更改为 1，让这个特殊字符几乎看不到，从而更隐秘地伪装了恶意 URL。

对于由以 .zip 结尾的域名带来的安全隐患，Bobby Rauch 给出的建议是，在单击 URL 之前，先将鼠标悬停在该 URL 上并检查浏览器底部显示真正要访问的 URL。

作者：胡译胡说
来源：juejin.cn/post/7384244866875146290

收起阅读 »

听说你会架构设计？来，弄一个打车系统

系统设计

目录引言网约车系统需求设计概要设计详细设计体验优化小结1.引言1.1 台风来袭深圳上周受台风“苏拉”影响，从 9 月 1 日 12 时起在全市启动防台风和防汛一级应急响应。对深圳打工人的具体影响为，当日从下午 4 点起全市实行 “五停”：停工、停业、停市，当日...

继续阅读 »

引言
网约车系统
需求设计
概要设计
详细设计
体验优化
小结

1.引言

1.1 台风来袭

深圳上周受台风“苏拉”影响，从 9 月 1 日 12 时起在全市启动防台风和防汛一级应急响应。

对深圳打工人的具体影响为，当日从下午 4 点起全市实行 “五停”：停工、停业、停市，当日已经停课、晚上 7 点后停运。

由于下午 4 点停市，于是大部分公司都早早下班。其中有赶点下班的，像这样：

有提前下班的，像这样：

还有像我们这样要居家远程办公的：

1.2 崩溃打车

下午 4 点左右，公交和地铁都人满为患。

于是快下班（居家办公）的时候就想着打个车回家，然而打开滴滴之后：

排队人数 142 位，这个排队人数和时长，让我的心一下就拔凉拔凉的。

根据历史经验，在雨天打上车的应答时间得往后推半个小时左右。更何况，这还是台风天气！

滴滴啊滴滴，你就不能提前准备一下嘛，这个等待时长，会让你损失很多订单分成的。

但反过来想，这种紧急预警，也不能完全怪打车平台，毕竟，车辆调度也是需要一定时间的。在这种大家争相逃命（bushi 的时候，周围的车辆估计也不太够用。

卷起来

等着也是等着，于是就回到公司继续看技术文章。这时我突然想到，经过这次车辆紧急调度之后，如果我是滴滴的开发工程师，需要怎么处理这种情况呢？

如果滴滴的面试官在我眼前，他又会怎么考量候选人的技术深度和产品思维呢？

2. 设计一个“网约车系统”

面试官：“滴滴打车用过是吧！看你简历里写道会架构设计是吧，如果让你设计一个网约车系统，你会从哪些方面考虑呢？”

2.1 需求分析

网约车系统（比如滴滴）的核心功能是把乘客的打车订单发送给附件的网约车司机，司机接单后，到上车点接送乘客，乘客下车后完成订单。

其中，司机通过平台约定的比例抽取分成（70%-80%不等），乘客可以根据第三方平台的信用值（比如支付宝）来开通免密支付，在下车后自动支付订单。用例图如下：

乘客和司机都有注册登录功能，分属于乘客用户模块和司机用户模块。网约车系统的另外核心功能是乘客打车，订单分配，以及司机送单。

2.2 概要设计

网约车系统是互联网+共享资源的一种模式，目的是要把车辆和乘客结合起来，节约已有资源的一种方式，通常是一辆网约车对多个用户。

所以对于乘客和司机来说，他们和系统的交互关系是不同的。比如一个人一天可能只打一次车，而一个司机一天得拉好几趟活。

故我们需要开发两个 APP 应用，分别给乘客和司机打车和接单，架构图如下：

1）乘客视角

如上所示：乘客在手机 App 注册成为用户后，可以选择出发地和目的地，进行打车。

打车请求通过负载均衡服务器，经过请求转发等一系列筛选，然后到达 HTTP 网关集群，再由网关集群进行业务校验，调用相应的微服务。

例如，乘客在手机上获取个人用户信息，收藏的地址信息等，可以将请求转发到用户系统。需要叫车时，将出发地、目的地、个人位置等信息发送至打车系统。

2）司机视角

如上图所示：司机在手机 App 注册成为用户并开始接单后，打开手机的位置信息，通过 TCP 长连接定时将自己的位置信息发送给平台，同时也接收平台发布的订单消息。

司机 App 采用 TCP 长连接是因为要定时发送和接收系统消息，若采用 HTTP 推送：
一方面对实时性有影响，另一方面每次通信都得重新建立一次连接会有失体面（耗费资源）。

司机 App：每 3~5 秒向平台发送一次当前的位置信息，包括车辆经纬度，车头朝向等。TCP 服务器集群相当于网关，只是以 TCP 长连接的方式向 App 提供接入服务，地理位置服务负责管理司机的位置信息。

3）订单接收

网关集群充当业务系统的注册中心，负责安全过滤，业务限流，请求转发等工作。

业务由一个个独立部署的网关服务器组成，当请求过多时，可以通过负载均衡服务器将流量压力分散到不同的网关服务器上。

当用户打车时，通过负载均衡服务器将请求打到某一个网关服务器上，网关首先会调用订单系统，为用户创建一个打车订单（订单状态为 “已创建”），并存库。

然后网关服务器调用打车系统，打车系统将用户信息、用户位置、出发地、目的地等数据封装到一个消息包中，发送到消息队列（比如 RabbitMQ），等待系统为用户订单分配司机。

4）订单分配

订单分配系统作为消息队列的消费者，会实时监听队列中的订单。当获取到新的订单消息时，订单分配系统会将订单状态修改为 “订单分配中”，并存库。

然后，订单分配系统将用户信息、用户位置、出发地、目的地等信息发送给订单推送 SDK。

接着，订单推送 SDK 调用地理位置系统，获取司机的实时位置，再结合用户的上车点，选择最合适的司机进行派单，然后把订单消息发送到消息告警系统。这时，订单分配系统将订单状态修改为 “司机已接单” 状态。

订单消息通过专门的消息告警系统进行推送，通过 TCP 长连接将订单推送到匹配上的司机手机 App。

5）拒单和抢单

订单推送 SDK 在分配司机时，会考虑司机当前的订单是否完成。当分配到最合适的司机时，司机也可以根据自身情况选择 “拒单”，但是平台会记录下来评估司机的接单效率。

打车平台里，司机如果拒单太多，就可能在后续的一段时间里将分配订单的权重分数降低，影响自身的业绩。

订单分派逻辑也可以修改为允许附加的司机抢单，具体实现为：

当订单创建后，由订单推送 SDK 将订单消息推送到一定的地理位置范围内的司机 App，在范围内的司机接收到订单消息后可以抢单，抢单完成后，订单状态变为“已派单”。

2.3 详细设计

打车平台的详细设计，我们会关注网约车系统的一些核心功能，如：长连接管理、地址算法、体验优化等。

1）长连接的优势

除了网页上常用的 HTTP 短连接请求，比如：百度搜索一下，输入关键词就发起一个 HTTP 请求，这就是最常用的短连接。

但是大型 APP，尤其是涉及到消息推送的应用（如 QQ、微信、美团等应用），几乎都会搭建一套完整的 TCP 长连接通道。

一张图看懂长连接的优势：

图片来源：《美团点评移动网络优化实践》

通过上图，我们得出结论。相比短连接，长连接优势有三：

连接成功率高
网络延时低
收发消息稳定，不易丢失

2）长连接管理

前面说到了长连接的优势是实时性高，收发消息稳定，而打车系统里司机需要定期发送自身的位置信息，并实时接收订单数据，所以司机 App 采用 TCP 长连接的方式来接入系统。

和 HTTP 无状态连接不同的是，TCP 长连接是有状态的连接。所谓无状态，是指每次用户请求可以随意发送到某一台服务器上，且每台服务器的返回相同，用户不关心是哪台服务器处理的请求。

当然，现在 HTTP2.0 也可以是有状态的长连接，我们此处默认是 HTTP1.x 的情况。

而 TCP 长连接为了保证传输效率和实时性，服务器和用户的手机 App 需要保持长连接的状态，即有状态的连接。

所以司机 App 每次信息上报或消息推送时，都会通过一个特定的连接通道，司机 App 接收消息和发送消息的连接通道是固定不变的。

因此，司机端的 TCP 长连接需要进行专门管理，处理司机 App 和服务器的连接信息，架构图如下：

为了保证每次消息的接收和推送都能找到对应通道，我们需要维护一个司机 App 到 TCP 服务器的映射关系，可以用 Redis 进行保存。

当司机 App 第一次登录，或者和服务器断开连接（比如服务器宕机、用户切换网络、后台关闭手机 App 等），需要重连时，司机 App 会通过用户长连接管理系统重新申请一个服务器连接（可用地址存储在 Zookeeper 中），TCP 连接服务器后再刷新 Redis 的缓存。

3）地址算法

当乘客打车后，订单推送 SDK 会结合司机所在地理位置，结合一个地址算法，计算出最适合的司机进行派单。

目前，手机收集地理位置一般是收集经纬度信息。经度范围是东经 180 到西经 180，纬度范围是南纬 90 到北纬 90。

我们设定西经为负，南纬为负，所以地球上的经度范围就是[-180， 180]，纬度范围就是[-90，90]。如果以本初子午线、赤道为界，地球可以分成4个部分。

根据这个原理，我们可以先将二维的空间经纬度编码成一个字符串，来唯一标识司机和乘客的位置信息。再通过 Redis 的 GeoHash 算法，来获取乘客附加的所有司机信息。

GeoHash 算法的原理是将乘客的经纬度换算成地址编码字符串，表示在某个矩形区域，通过这个算法可以快速找到同一个区域的所有司机。

它的实现用到了跳表数据结构，具体实现为：

将某个市区的一块范围作为 GeoHash 的 key，这个市区范围内所有的司机存储到一个跳表中，当乘客的地理位置出现在这个市区范围时，获取该范围内所有的司机信息。然后进一步筛选出最近的司机信息，进行派单。

4）体验优化

1. 距离算法

作为线上派单，通过距离运算来分配订单效果一定会比较差，因为 Redis 计算的是两点之间的空间距离，但司机必须沿道路行驶过来，在复杂的城市路况下，也许几十米的空间距离行驶十几分钟也未可知。

所以，后续需综合行驶距离（而非空间距离）、司机车头朝向以及上车点进行路径规划，来计算区域内每个司机到达乘客的距离和时间。

更进一步，如果区域内有多个乘客和司机，就要考虑所有人的等待时间，以此来优化用户体验，节省派单时间，提升盈利额。

2. 订单优先级

如果打车订单频繁取消，可根据司机或乘客行为进行判责。判责后给乘客和司机计算信誉分，并告知用户信誉分会影响乘客和司机的使用体验，且关联到派单的优先级。

司机接单优先级

综合考虑司机的信誉分，投诉次数，司机的接单数等等，来给不同信誉分的司机分配不同的订单优先级。

乘客派单优先级

根据乘客的打车时间段，打车距离，上车点等信息，做成用户画像，以合理安排司机，或者适当杀熟（bushi。

PS：目前有些不良打车平台就是这么做的 🐶 甚至之前爆出某打车平台，会根据不同的手机系统，进行差异收费。

4. 小结

4.1 网约车平台发展

目前，全球网约车市场已经达到了数千亿美元的规模，主要竞争者包括滴滴、Uber、Grab 等公司。在中国，滴滴作为最大的网约车平台已经占据了绝大部分市场份额。

网约车的核心商业逻辑比较简单，利益关联方主要为平台、司机、车辆、消费者。

平台分别对接司机、车辆【非必选项，有很多司机是带车上岗】和乘客，通过有效供需匹配赚取整个共享经济链省下的钱。

具体表现为：乘客和司机分别通过网约平台打车和接单，平台提供技术支持。乘客为打车服务付费，平台从交易金额中抽成（10%-30%不等）。

据全国网约车监管信息交互平台统计，截至 2023 年 2 月底，全国共有 303 家网约车平台公司取得网约车平台经营许可。

这些平台一部分是依靠高德打车、百度地图、美团打车为代表的网约车聚合平台；另一部分则是以滴滴出行、花小猪、T3 为代表的出行平台。

4.2 网约车平台现状

随着出行的解封，网约车平台重现生机。

但由于部分网约车聚合平台的准入门槛太低，所以在过去一段时间里暴露出愈来愈多的问题。如车辆、司机合规率低，遇到安全事故，产生责任纠纷，乘客维权困难等等。

由于其特殊的模式，导致其与网约车运营商存在责任边界问题，一直游离在法律边缘。

但随着网约车聚合平台的监管不断落地，全国各地都出行了一定的监管条例。

比如某打车平台要求车辆将司机和乘客的沟通记录留档，除了司机与乘客的在线沟通记录必须保存以外，还需要一个语音电话或车载录音转换，留存一段时间备查。

有了这些人性化的监管条例和技术的不断创新，网约车平台或许会在未来的一段时间内，继续蓬勃发展。

后话

面试官：嗯，又专又红，全面发展！这小伙子不错，关注了~

作者：xin猿意码
来源：juejin.cn/post/7275211391102746684

收起阅读 »

何时使用Elasticsearch而不是MySql

综合技术讨论

MySQL 和 Elasticsearch 是两种不同的数据管理系统，它们各有优劣，适用于不同的场景。本文将从以下几个方面对它们进行比较和分析：数据模型查询语言索引和搜索分布式和高可用性能和扩展性使用场景数据模型 MySQL 是一个关系型数据...

继续阅读 »

MySQL 和 Elasticsearch 是两种不同的数据管理系统，它们各有优劣，适用于不同的场景。本文将从以下几个方面对它们进行比较和分析：

数据模型

查询语言

索引和搜索

分布式和高可用

性能和扩展性

使用场景

数据模型

MySQL 是一个关系型数据库管理系统（RDBMS），它使用表（table）来存储结构化的数据，每个表由多个行（row）和列（column）组成，每个列有一个预定义的数据类型，例如整数、字符串、日期等。MySQL 支持主键、外键、约束、触发器等关系型数据库的特性，以保证数据的完整性和一致性。

Elasticsearch 是一个基于 Lucene 的搜索引擎，它使用文档（document）来存储半结构化或非结构化的数据，每个文档由多个字段（field）组成，每个字段可以有不同的数据类型，例如文本、数字、布尔、数组等。Elasticsearch 支持动态映射（dynamic mapping），可以根据数据自动推断字段的类型和索引方式。

MySQL 和 Elasticsearch 的数据模型有以下几点区别：

MySQL 的数据模型是严格的，需要事先定义好表的结构和约束，而 Elasticsearch 的数据模型是灵活的，可以随时添加或修改字段。

MySQL 的数据模型是二维的，每个表只有行和列两个维度，而 Elasticsearch 的数据模型是多维的，每个文档可以有嵌套的对象或数组。

MySQL 的数据模型是关系型的，可以通过连接（join）多个表来查询相关的数据，而 Elasticsearch 的数据模型是非关系型的，不支持连接操作，需要通过嵌套文档或父子文档来实现关联查询。

推荐博主开源的 H5 商城项目waynboot-mall，这是一套全部开源的微商城项目，包含三个项目：运营后台、H5 商城前台和服务端接口。实现了商城所需的首页展示、商品分类、商品详情、商品 sku、分词搜索、购物车、结算下单、支付宝/微信支付、收单评论以及完善的后台管理等一系列功能。技术上基于最新得 Springboot3.0、jdk17，整合了 MySql、Redis、RabbitMQ、ElasticSearch 等常用中间件。分模块设计、简洁易维护，欢迎大家点个 star、关注博主。

github 地址：github.com/wayn111/way…

查询语言

MySQL 使用标准的 SQL 语言来查询和操作数据，SQL 语言是一种声明式的语言，可以通过简洁的语法来表达复杂的逻辑。SQL 语言支持多种查询类型，例如选择（select）、插入（insert）、更新（update）、删除（delete）、聚合（aggregate）、排序（order by）、分组（gr0up by）、过滤（where）、连接（join）等。

Elasticsearch 使用 JSON 格式的查询 DSL（Domain Specific Language）来查询和操作数据，查询 DSL 是一种基于 Lucene 查询语法的语言，可以通过嵌套的 JSON 对象来构建复杂的查询。查询 DSL 支持多种查询类型，例如全文检索（full-text search）、结构化检索（structured search）、地理位置检索（geo search）、度量检索（metric search）等。

MySQL 和 Elasticsearch 的查询语言有以下几点区别：

MySQL 的查询语言是通用的，可以用于任何关系型数据库系统，而 Elasticsearch 的查询语言是专用的，只能用于 Elasticsearch 系统。

MySQL 的查询语言是字符串形式的，需要拼接或转义特殊字符，而 Elasticsearch 的查询语言是 JSON 形式的，可以直接使用对象或数组表示。

MySQL 的查询语言是基于集合论和代数运算的，可以进行集合操作和数学运算，而 Elasticsearch 的查询语言是基于倒排索引和相关度评分的，可以进行全文匹配和相似度计算。

索引和搜索

MySQL 使用 B+树作为主要的索引结构，B+树是一种平衡多路搜索树，它可以有效地存储和检索有序的数据。MySQL 支持主键索引、唯一索引、普通索引、全文索引等多种索引类型，以加速不同类型的查询。MySQL 也支持外部存储引擎，例如 InnoDB、MyISAM、Memory 等，不同的存储引擎有不同的索引和锁机制。

Elasticsearch 使用倒排索引作为主要的索引结构，倒排索引是一种将文档中的词和文档的映射关系存储的数据结构，它可以有效地支持全文检索。Elasticsearch 支持多种分词器（analyzer）和分词过滤器（token filter），以对不同语言和场景的文本进行分词和处理。Elasticsearch 也支持多种搜索类型，例如布尔搜索（boolean search）、短语搜索（phrase search）、模糊搜索（fuzzy search）、通配符搜索（wildcard search）等，以实现不同精度和召回率的检索。

MySQL 和 Elasticsearch 的索引和搜索有以下几点区别：

MySQL 的索引是基于数据的值的，可以精确地定位数据的位置，而 Elasticsearch 的索引是基于数据的内容的，可以近似地匹配数据的含义。

MySQL 的索引是辅助的，需要手动创建和维护，而 Elasticsearch 的索引是主要的，自动创建和更新。

MySQL 的索引是局部的，只针对单个表或列，而 Elasticsearch 的索引是全局的，涵盖所有文档和字段。

分布式和高可用

MySQL 是一个单机数据库系统，它只能运行在一台服务器上，如果服务器出现故障或负载过高，就会影响数据库的可用性和性能。为了解决这个问题，MySQL 提供了多种复制（replication）和集群（cluster）方案，例如主从复制（master-slave replication）、双主复制（master-master replication）、MySQL Cluster、MySQL Fabric 等，以实现数据的冗余和负载均衡。

Elasticsearch 是一个分布式数据库系统，它可以运行在多台服务器上，形成一个集群（cluster）。每个集群由多个节点（node）组成，每个节点可以承担不同的角色，例如主节点（master node）、数据节点（data node）、协调节点（coordinating node）等。每个节点可以存储多个索引（index），每个索引可以划分为多个分片（shard），每个分片可以有多个副本（replica）。Elasticsearch 通过一致性哈希算法（consistent hashing algorithm）来分配分片到不同的节点上，并通过心跳检测（heartbeat check）来监控节点的状态。如果某个节点出现故障或加入集群，Elasticsearch 会自动进行分片的重新分配和平衡。

MySQL 和 Elasticsearch 的分布式和高可用有以下几点区别：

MySQL 的分布式和高可用是可选的，需要额外配置和管理，而 Elasticsearch 的分布式和高可用是内置的，无需额外操作。

MySQL 的分布式和高可用是基于复制或共享存储的，需要保证数据一致性或可用性之间的权衡，而 Elasticsearch 的分布式和高可用是基于分片和副本的，可以根据需求调整数据冗余度或容错能力。

MySQL 的分布式和高可用是静态的，需要手动扩展或缩容集群规模，而 Elasticsearch 的分布式和高可用是动态的，可以自动适应集群变化。

性能和扩展性

MySQL 是一个面向事务（transaction）的数据库系统，它支持 ACID 特性（原子性、一致性、隔离性、持久性），以保证数据操作的正确性和完整性。MySQL 使用锁机制来实现事务隔离级别（isolation level），不同的隔离级别有不同的并发性能和一致性保证。MySQL 也使用缓冲池（buffer pool）来缓存数据和索引，以提高查询效率。MySQL 的性能主要取决于硬件资源、存储引擎、索引设计、查询优化等因素。

Elasticsearch 是一个面向搜索（search）的数据库系统，它支持近实时（near real-time）的索引和查询，以保证数据操作的及时性和灵活性。Elasticsearch 使用分片和副本来实现数据的分布式存储和并行处理，不同的分片数和副本数有不同的写入吞吐量和读取延迟。Elasticsearch 也使用缓存（cache）和内存映射文件（memory-mapped file）来加速数据和索引的访问，以提高搜索效率。Elasticsearch 的性能主要取决于集群规模、分片策略、文档结构、查询复杂度等因素。

MySQL 和 Elasticsearch 的性能和扩展性有以下几点区别：

MySQL 的性能和扩展性是有限的，它受到单机资源、锁竞争、复制延迟等因素的限制，而 Elasticsearch 的性能和扩展性是无限的，它可以通过增加节点、分片、副本等方式来水平扩展集群。

MySQL 的性能和扩展性是以牺牲搜索能力为代价的，它不能支持复杂的全文检索和相关度评分，而 Elasticsearch 的性能和扩展性是以牺牲事务能力为代价的，它不能保证数据操作的原子性和一致性。

MySQL 的性能和扩展性是以提高写入速度为目标的，它优化了数据插入和更新的效率，而 Elasticsearch 的性能和扩展性是以提高读取速度为目标的，它优化了数据检索和分析的效率。

使用场景

MySQL 和 Elasticsearch 适用于不同的使用场景，根据不同的业务需求，可以选择合适的数据库系统或组合使用两者。以下是一些常见的使用场景：

如果需要存储结构化或半结构化的数据，并且需要保证数据操作的正确性和完整性，可以选择 MySQL 作为主要数据库系统。例如，电商网站、社交网络、博客平台等。

如果需要存储非结构化或多样化的数据，并且需要支持复杂的全文检索和相关度评分，可以选择 Elasticsearch 作为主要数据库系统。例如搜索引擎、日志分析、推荐系统等。

如果需要存储和分析大量的时序数据，并且需要支持实时的聚合和可视化，可以选择Elasticsearch作为主要数据库系统。例如，物联网、监控系统、金融市场等。

如果需要同时满足上述两种需求，并且可以容忍一定程度的数据不一致或延迟，可以将 MySQL 作为主数据库系统，并将部分数据同步到 Elasticsearch 作为辅助数据库系统。例如新闻网站、电影网站、招聘网站等。

自此本文讲解内容到此结束，感谢您的阅读，希望本文对您有所帮助。

作者：程序员wayn
来源：juejin.cn/post/7264528507932327948

收起阅读 »

Easy-Es：像mybatis-plus一样，轻松操作ES

综合技术讨论

0. 引言 es的java客户端不太友好的语法一直饱受诟病，书写一个查询语句可能需要书写一大串的代码，如果能像mybatis--plus一样，支持比较灵活方便的语句生成器那就好了。于是为elasticsearch而生的ORM框架Easy-Es诞生了，使用及其...

继续阅读 »

0. 引言

es的java客户端不太友好的语法一直饱受诟病，书写一个查询语句可能需要书写一大串的代码，如果能像mybatis--plus一样，支持比较灵活方便的语句生成器那就好了。

于是为elasticsearch而生的ORM框架Easy-Es诞生了，使用及其方便快捷，今天我们就一起来学习easy-es，对比看看原生java-client方便之处在哪儿。

1. Easy-Es简介

Easy-Es是以elasticsearch官方提供的RestHighLevelClient为基础，而开发的一款针对es的ORM框架，类似于es版的mybatis-plus，可以让开发者无需掌握es复杂的DSL语句，只要会mysql语法即可使用es，快速实现es客户端语法

官方文档：http://www.easy-es.cn/

2. Easy-Es使用

1、引入依赖

<!-- 引入easy-es最新版本的依赖-->

        <dependency>

            <groupId>org.dromara.easy-es</groupId>

            <artifactId>easy-es-boot-starter</artifactId>

            <version>2.0.0-beta3</version>

        </dependency>



        <!-- 排除springboot中内置的es依赖,以防和easy-es中的依赖冲突-->

        <dependency>

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

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

            <exclusions>

                <exclusion>

                    <groupId>org.elasticsearch.client</groupId>

                    <artifactId>elasticsearch-rest-high-level-client</artifactId>

                </exclusion>

                <exclusion>

                    <groupId>org.elasticsearch</groupId>

                    <artifactId>elasticsearch</artifactId>

                </exclusion>

            </exclusions>

        </dependency>

        <dependency>

            <groupId>org.elasticsearch.client</groupId>

            <artifactId>elasticsearch-rest-high-level-client</artifactId>

            <version>7.14.0</version>

        </dependency>

        <dependency>

            <groupId>org.elasticsearch</groupId>

            <artifactId>elasticsearch</artifactId>

            <version>7.14.0</version>

        </dependency>

2、添加配置项，这里只配置了几个基本的配置项，更多配置可参考官网文档：easy-es 配置介绍

easy-es: 

  # es地址、账号密码

  address: 192.168.244.11:9200

  username: elastic

  password: elastic

3、在启动类中添加es mapper文件的扫描路径

@EsMapperScan("com.example.easyesdemo.mapper")

4、创建实体类，通过@IndexName注解申明索引名称及分片数， @IndexField注解申明字段名、数据类型、分词器等，更多介绍参考官方文档：essy-es 注解介绍

@IndexName(value = "user_easy_es")

@Data

public class UserEasyEs {



    @IndexId(type = IdType.CUSTOMIZE)

    private Long id;



    private String name;



    private Integer age;



    private Integer sex;



    @IndexField(fieldType = FieldType.TEXT, analyzer = Analyzer.IK_SMART, searchAnalyzer = Analyzer.IK_SMART)

    private String address;



    @IndexField(fieldType = FieldType.DATE, dateFormat = "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis")

    private Date createTime;



    private String createUser;



}

5、创建mapper类，继承BaseEsMapper类，注意这里的mapper一定要创建到第3步中设置的mapper扫描路径下com.example.easyesdemo.mapper

public interface UserEsMapper extends BaseEsMapper<UserEasyEs> {

}

6、创建controller，书写创建索引、新增、修改、查询的接口

@RestController

@RequestMapping("es")

@AllArgsConstructor

public class UserEsController {



    private final UserEsMapper userEsMapper;



    /**

     * 创建索引

     * @return

     */

    @GetMapping("create")

    public Boolean createIndex(){

        return userEsMapper.createIndex();

    }



    @GetMapping("save")

    public Integer save(Long id){

        UserEasyEs user = new UserEasyEs();

        user.setId(id);

        user.setName("用户"+id);

        user.setAddress("江苏省无锡市滨湖区");

        user.setAge(30);

        user.setSex(1);

        user.setCreateUser("admin");

        user.setCreateTime(new Date());

        Long count = userEsMapper.selectCount(EsWrappers.lambdaQuery(UserEasyEs.class).eq(UserEasyEs::getId, id));

        if(count > 0){

            return userEsMapper.updateById(user);

        }else{

            return userEsMapper.insert(user);

        }

    }



    @GetMapping("search")

    public List<UserEasyEs> search(String name, String address){

        List<UserEasyEs> userEasyEs = userEsMapper.selectList(

                EsWrappers.lambdaQuery(UserEasyEs.class)

                        .eq(UserEasyEs::getName, name)

                        .match(UserEasyEs::getAddress, address)

                );

        return userEasyEs;

    }



}

7、分别调用几个接口

创建索引

kibana中查询索引，发现创建成功

新增接口
这里新增了4笔

数据新增成功

数据查询

如上便是针对easy-es的简单使用，这里的用法都与mp类似，上手相当简单，不用再写那些复杂的DSL语句了

3. 拓展介绍

条件构造器

上述演示，我们构造查询条件时，使用了EsWrappers来构造条件，用法与mp及其类型，大家根据提示就可以推导出方法如何书写，更详细的使用说明可以查看官方文档：easy-es 条件构造器介绍

索引托管

如果想要自动根据创建的es实体类来创建对应的索引，那么只需要调整索引的托管模式为非手动模式即可，因为这里我不需要自动同步数据，所以选择非平滑模式

easy-es:

  global-config:

    process_index_mode: not_smoothly

其中三种模式的区别为：
平滑模式：smoothly，索引的创建、数据更新迁移等都由easy-es自动完成
非平滑模式：not_smoothly，索引自动创建，但不会自动迁移数据
手动模式：manual，全部操作由用户手动完成，默认模式

数据同步

如果数据源是来自mysql, 那么建议使用canal来进行同步，canal的使用可在我主页搜索。
其次还有DataX, Logstash等同步工具，当然你也可以使用easy-es提供的CRUD接口，来手动同步数据

日志打印

通过开启日志，可以在控制台打印执行的DSL语句，更加方便我们在开发阶段进行问题排查

logging:

  level:

   tracer: trace # 开启trace级别日志,在开发时可以开启此配置,则控制台可以打印es全部请求信息及DSL语句,为了避免重复,开启此项配置后,可以将EE的print-dsl设置为false.

聚合查询
easy-es实现的聚合查询，只要是针对gr0up by这类聚合，也就是es中的Terms aggregation，以及最大值、最小值、平均值、求和，而对于其他类型的聚合，还在不断更新中，但这里大家也需要了解，es的聚合和mysql的聚合完全是不一样的维度和复杂度，es支持非常多的聚合查询，所以其他类型的实现还需要借助RestHighLevelClient来实现

我们利用easy-es来实现下之前书写的聚合案例

@RestController

@AllArgsConstructor

@RequestMapping("order")

public class OrderEsController {



    private final OrderTestEsMapper orderEsMapper;



    @GetMapping("search")

    public String search(){

        SearchResponse search = orderEsMapper.search(EsWrappers.lambdaQuery(OrderTest.class).groupBy(OrderTest::getStatus));



        // 包装查询结果

        Aggregations aggregations = search.getAggregations();

        Terms terms = (Terms)aggregations.asList().get(0);

        List<? extends Terms.Bucket> buckets = terms.getBuckets();

        HashMap<String,Long> statusRes = new HashMap<>();

        buckets.forEach(bucket -> {

            statusRes.put(bucket.getKeyAsString(),bucket.getDocCount());

        });

        System.out.println("---聚合结果---");

        System.out.println(statusRes);

        return statusRes.toString();

    }

}

可以看到实际上的查询语句就一行，而其他的都是对返回结果的封装，因为es本身返回的数据是封装到嵌套的对象中的，所以我们需要对其进行包装

对比原始的查询语句，其易用性上的提升还是很明显的

4. 总结

至此对easy-es的介绍就结束了，可以看到如果是针对es实现CRUD上，easy-es表现出非常好的便捷性，而在复杂的聚合查询中，仍然还有进步空间，目前还需要借助RestHighLevelClient，但easy-es的出现，为未来提供更好用的ES ORM框架，提供了希望和方向

文中演示代码见：gitee.com/wuhanxue/wu…

作者：wu55555
来源：juejin.cn/post/7271896547594682428

收起阅读 »

研发都认为DBA很Low?我反手一个嘴巴子

综合技术讨论

前言我用十多年的DBA经验告诉你，如果你作为研发觉得DBA很Low，你是会吃苦头的“你以为DBA就是安装一下数据库，管理一下数据库？你丢个SQL给DBA优化下？你的日志爆满了DBA给你清理一下？DBA帮你安装下中间件？你以为的DBA只是做这些事？”秉持着和平交...

继续阅读 »

前言

我用十多年的DBA经验告诉你，如果你作为研发觉得DBA很Low，你是会吃苦头的

“你以为DBA就是安装一下数据库，管理一下数据库？你丢个SQL给DBA优化下？你的日志爆满了DBA给你清理一下？DBA帮你安装下中间件？你以为的DBA只是做这些事？”

秉持着和平交流的学习态度，我这里精选了几位高赞粉丝的精彩回答

1.救火能力

1.1 调优

IT界并没有一个通行的 ”拳头“ 来判断谁low，谁更low。有时候，研发写的程序，新功能发布后，就出现磁盘IO出现瓶颈了、或者CPU飙高到100%了，但是这个时候，只是表象，只知道Linux机器的资源耗尽了，DBA得先找到资源消耗在哪了，才能进一步分析原因，用数据说话是应用的问题，才能责令程序员整改。

SQL调优是一个复杂的过程，涉及多个方面，包括但不限于SQL语句的编写、索引的使用、表的连接策略、数据库的统计信息、系统资源的利用等。调优的难度取决于多个因素，包括查询的复杂性、数据量、硬件资源、数据库的工作负载和现有的优化策略。

在这里给大家分享一个执行计划变，1个SQL把系统干崩的情景，由于业务用户检索数据范围过大，导致执行计划谓词越界，通过矫正执行计划及开启操作系统大页，服务器DB一直存在的CPU高负载从75%降低到25%！

生产问题，瞬息万变，DBA要同时熟悉业务，并对硬件、网络要精通，要在这样的复杂情况下作出正确的决策，这一点我想难度不小吧。

1.2 高可用

数据库高可用是指DB集群中任何一个节点的故障都不会影响用户的使用，连接到故障节点的用户会被自动转移到健康节点，从用户感受而言，是感觉不到这种切换。

那么DBA在高可用的配置方面，下面就是某制造业大厂，应用层的链接方式

--jdbc应用端的连接

jdbc:oracle:thin:@(DESCRIPTION =

(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)

(PORT = 1521))(ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)

(PORT = 1521))(LOAD_BALANCE = no)(FAILOVER = yes))

(CONNECT_DATA =(SERVER = DEDICATED)(SERVICE_NAME = dbserver)))

那么这种配置FAILOVER = yes，Net会从多个地址中按顺序选择一个地址进行连接，直到连接成功为止，那么就会保证数据库单节点故障，自动的切换，高可用是故障发生的第一个救命的稻草，系统上线前一定要测试好，才能确保数据库的高可用，这期间DBA功不可没！

还有客户要求选择的一套国产数据库支持核心业务，那么作为DBA在选型及业务适配上就发挥作用了，跟研发确认发现应用是兼容PG的，而且客户要求要同时兼容OLAT和OLTP业务，看下以下这套openGauss国产数据库的高可用架构。

1.openGauss高可用：CM

通过配置VIP故障转移，OLTP连接VIP，进行事物交易

同时支持动态配置CM集群故障切换策略和数据库集群脑裂故障恢复策略，

从而能够尽可能确保集群数据的完整性和一致性。



2.写重定向，报表分析业务连接，支持读写分离

主备节点开启控制参数 enable_remote_execute=on之后

通过备库发起的写操作，会重定向到主库执行

2.监控能力

这方面我是最有发言权了，SA一直是我的本职工作，从机房硬件部署、弱电以及数据库的安装实施，很多东西需要依赖于DBA来做，全力保障应用的稳定性，而且监控到的指标随时可以推送到邮件以及微信。这期间我也发现了很多天窗，原来还可以这么干？

2.1 服务器监控

首先监控Linux服务嘛，那肯定是要全方位系统的监控，网络、磁盘、CPU、内存等等，这才叫监控，那么其实给大家推荐一款免费的监控工作

Prometheus提供了从指标暴露，到指标抓取、存储和可视化，以及最后的监控告警等组件。

数据库监控

Zabbix聚焦于帮助用户通过性能优化和功能升级来快速响应业务需求，从而满足客户的高期望值，并提升IT运维人员的生产力。在可扩展性与性能、稳定性与高可用、可观测性几个领域获得持续提升。监控做不好，救火救到老！拿下Zabbix，现在！立刻！马上！！

1.监控Oracle

博客地址：

https://jeames.blog.csdn.net/article/details/126825934

2.监控PostgreSQL

博客地址：

https://jeames.blog.csdn.net/article/details/120300581

3.监控MySQL

博客地址：

https://jeames.blog.csdn.net/article/details/126825934

3 数据源赋能者

从AI、智能化到云迁移和安全性，业务和技术趋势不断重塑DBA在组织中的角色.DBA 群体站在时代的岔路口，国产数据库太多了应该怎么选？DBA 会被云上数据库抛弃吗？应该如何应对新时代挑战？职业终点在哪里？

1.云数据库解决方案

DBA要善于利用云原生保障数据安全和优化成本



2.数据安全与合规

随着数据保护法律的出台、日益严峻的网络攻击，

DBA必须掌握加密、访问控制和审计等技能



3.灾难恢复和业务连续性

随着企业愈加依赖数据的连续性，

快速恢复丢失数据并最大限度地减少停机时间至关重要



4.自动化和脚本编写

自动化和脚本编写对于DBA管理重复性任务和提高效率尤为关键



5.有效的沟通和协作

有效的沟通和协作仍然是DBA的重要技能。

能够向同事清楚地传达技术信息、与跨职能团队合作，

打破IT部门和业务部门之间的信息差，确保数据库的策略与组织目标保持一致。

4.总结

在一个公司写了屎山代码的研发，可以拍拍屁股走人，然后继续去下一个企业再写个屎山。反正不会追着代码跨省找你。而一个搞崩了系统的DBA，这个闯祸经历将成为他的黑历史，并影响到他未来的就业.因为需要专业DBA的好企业，基本都是几百台服务器起步的大项目，难免不会查背景，这就导致DBA如果想干得好，圈子会越来越小，请记住是干得好，不是混得好，混是会出事的。

好了，以上就是我对DBA的理解了，有不足之处还望指正。

作者：IT邦德
来源：juejin.cn/post/7386505099848646710

收起阅读 »

MySQL 高级（进阶）SQL 语句

综合技术讨论

MySQL 高级（进阶）SQL 语句 1. MySQL SQL 语句 1.1 常用查询常用查询简单来说就是增、删、改、查对 MySQL 数据库的查询，除了基本的查询外，有时候需要对查询的结果集进行处理。例如只取 10 条数据、对查询结果进行排序或分组等...

继续阅读 »

MySQL 高级（进阶）SQL 语句

1. MySQL SQL 语句

1.1 常用查询

常用查询简单来说就是增、删、改、查

对 MySQL 数据库的查询，除了基本的查询外，有时候需要对查询的结果集进行处理。例如只取 10 条数据、对查询结果进行排序或分组等等

1、按关键字排序
PS:类比于windows 任务管理器
使用 SELECT 语句可以将需要的数据从 MySQL 数据库中查询出来，如果对查询的结果进行排序，可以使用 ORDER BY 语句来对语句实现排序，并最终将排序后的结果返回给用户。这个语句的排序不光可以针对某一个字段，也可以针对多个字段

（1）语法
SELECT column1, column2, … FROM table_name ORDER BY column1, column2, …

ASC|DESC
ASC 是按照升序进行排序的，是默认的排序方式，即 ASC 可以省略。SELECT 语句中如果没有指定具体的排序方式，则默认按 ASC方式进行排序。

DESC 是按降序方式进行排列。当然 ORDER BY 前面也可以使用 WHERE 子句对查询结果进一步过滤。

准备工作：

create database k1;

use k1;

create table location (Region char(20),Store_Name char(20));

insert int0 location values('East','Boston');

insert int0 location values('East','New York');

insert int0 location values('West','Los Angeles');

insert int0 location values('West','Houston');

create table store_info (Store_Name char(20),Sales int(10),Date char(10));

insert int0 store_info values('Los Angeles','1500','2020-12-05');

insert int0 store_info values('Houston','250','2020-12-07');

insert int0 store_info values('Los Angeles','300','2020-12-08');

insert int0 store_info values('Boston','700','2020-12-08');

1.2 SELECT

显示表格中一个或数个字段的所有数据记录 语法：SELECT "字段" FROM "表名";

SELECT Store_Name FROM location;

SELECT Store_Name FROM Store_Info;

1.3 DISTINCT

不显示重复的数据记录

语法：SELECT DISTINCT "字段" FROM "表名";

SELECT DISTINCT Store_Name FROM Store_Info;

1.4 AND OR

且或

语法：SELECT "字段" FROM "表名" WHERE "条件1" {[AND|OR] "条件2"}+ ;

1.5 in

显示已知的值的数据记录

语法：SELECT "字段" FROM "表名" WHERE "字段" IN ('值1', '值2', ...);

SELECT * FROM store_info WHERE Store_Name IN ('Los Angeles', 'Houston');

1.6 BETWEEN

显示两个值范围内的数据记录

语法：SELECT "字段" FROM "表名" WHERE "字段" BETWEEN '值1' AND '值2';

2. 通配符 —— 通常与 LIKE 搭配一起使用

% ：百分号表示零个、一个或多个字符

_ ：下划线表示单个字符

'A_Z'：所有以 'A' 起头，另一个任何值的字符，且以 'Z' 为结尾的字符串。例如，'ABZ' 和 'A2Z' 都符合这一个模式，而 'AKKZ' 并不符合 (因为在 A 和 Z 之间有两个字符，而不是一个字符)。

'ABC%': 所有以 'ABC' 起头的字符串。例如，'ABCD' 和 'ABCABC' 都符合这个模式。 '%XYZ': 所有以 'XYZ' 结尾的字符串。例如，'WXYZ' 和 'ZZXYZ' 都符合这个模式。

'%AN%': 所有含有 'AN'这个模式的字符串。例如，'LOS ANGELES' 和 'SAN FRANCISCO' 都符合这个模式。

'_AN%'：所有第二个字母为 'A' 和第三个字母为 'N' 的字符串。例如，'SAN FRANCISCO' 符合这个模式，而 'LOS ANGELES' 则不符合这个模式。

2.1 LIKE

匹配一个模式来找出我们要的数据记录

语法：SELECT "字段" FROM "表名" WHERE "字段" LIKE {模式};

SELECT * FROM store_info WHERE Store_Name like '%os%';

2.2 ORDER BY

按关键字排序

语法：SELECT "字段" FROM "表名" [WHERE "条件"] ORDER BY "字段" [ASC, DESC];

注意：ASC 是按照升序进行排序的，是默认的排序方式。 DESC 是按降序方式进行排序

SELECT Store_Name,Sales,Date FROM store_info ORDER BY Sales DESC;

3. 函数

3.1数学函数

abs(x)	返回 x 的绝对值
rand()	返回 0 到 1 的随机数
mod(x,y)	返回 x 除以 y 以后的余数
power(x,y)	返回 x 的 y 次方
round(x)	返回离 x 最近的整数
round(x,y)	保留 x 的 y 位小数四舍五入后的值
sqrt(x)	返回 x 的平方根
truncate(x,y)	返回数字 x 截断为 y 位小数的值
ceil(x)	返回大于或等于 x 的最小整数
floor(x)	返回小于或等于 x 的最大整数
greatest(x1,x2...)	返回集合中最大的值，也可以返回多个字段的最大的值
least(x1,x2...)	返回集合中最小的值，也可以返回多个字段的最小的值

SELECT abs(-1), rand(), mod(5,3), power(2,3), round(1.89);

SELECT round(1.8937,3), truncate(1.235,2), ceil(5.2), floor(2.1), least(1.89,3,6.1,2.1);

3.2 聚合函数

avg()	返回指定列的平均值
count()	返回指定列中非 NULL 值的个数
min()	返回指定列的最小值
max()	返回指定列的最大值
sum(x)	返回指定列的所有值之和

SELECT avg(Sales) FROM store_info;



SELECT count(Store_Name) FROM store_info;

SELECT count(DISTINCT Store_Name) FROM store_info;



SELECT max(Sales) FROM store_info;

SELECT min(Sales) FROM store_info;



SELECT sum(Sales) FROM store_info;

3.3 字符串函数

trim()	返回去除指定格式的值
concat(x,y)	将提供的参数 x 和 y 拼接成一个字符串
substr(x,y)	获取从字符串 x 中的第 y 个位置开始的字符串，跟substring()函数作用相同
substr(x,y,z)	获取从字符串 x 中的第 y 个位置开始长度为 z 的字符串
length(x)	返回字符串 x 的长度
replace(x,y,z)	将字符串 z 替代字符串 x 中的字符串 y
upper(x)	将字符串 x 的所有字母变成大写字母
lower(x)	将字符串 x 的所有字母变成小写字母
left(x,y)	返回字符串 x 的前 y 个字符
right(x,y)	返回字符串 x 的后 y 个字符
repeat(x,y)	将字符串 x 重复 y 次
space(x)	返回 x 个空格
strcmp(x,y)	比较 x 和 y，返回的值可以为-1,0,1
reverse(x)	将字符串 x 反转

如 sql_mode 开启了 PIPES_AS_CONCAT，"||" 视为字符串的连接操作符而非或运算符，和字符串的拼接函数Concat相类似，这和Oracle数据库使用方法一样的

SELECT Region || ' ' || Store_Name FROM location WHERE Store_Name = 'Boston';

SELECT substr(Store_Name,3) FROM location WHERE Store_Name = 'Los Angeles';

SELECT substr(Store_Name,2,4) FROM location WHERE Store_Name = 'New York'

SELECT TRIM ([ [位置] [要移除的字符串] FROM ] 字符串);

**[位置]：的值可以为 LEADING (起头), TRAILING (结尾), BOTH (起头及结尾)。 **

[要移除的字符串]：从字串的起头、结尾，或起头及结尾移除的字符串。缺省时为空格。

SELECT TRIM(LEADING 'Ne' FROM 'New York');

 

SELECT Region,length(Store_Name) FROM location;

 

SELECT REPLACE(Region,'ast','astern')FROM location;

4. GR0UP BY

对GR0UP BY后面的字段的查询结果进行汇总分组，通常是结合聚合函数一起使用的

GR0UP BY 有一个原则

凡是在 GR0UP BY 后面出现的字段，必须在 SELECT 后面出现；

凡是在 SELECT 后面出现的、且未在聚合函数中出现的字段，必须出现在 GR0UP BY 后面

语法：SELECT "字段1", SUM("字段2") FROM "表名" GR0UP BY "字段1";

SELECT Store_Name, SUM(Sales) FROM store_info GR0UP BY Store_Name ORDER BY sales desc;

5. 别名

字段別名表格別名

语法：SELECT "表格別名"."字段1" [AS] "字段別名" FROM "表格名" [AS] "表格別名";

SELECT A.Store_Name Store, SUM(A.Sales) "Total Sales" FROM store_info A GR0UP BY A.Store_Name;

6. 子查询

子查询也被称作内查询或者嵌套查询，是指在一个查询语句里面还嵌套着另一个查询语句。子查询语句是先于主查询语句被执行的，其结果作为外层的条件返回给主查询进行下一步的查询过滤

连接表格，在WHERE 子句或 HAVING 子句中插入另一个 SQL 语句

语法：SELECT "字段1" FROM "表格1" WHERE "字段2" [比较运算符] #外查询 (SELECT "字段1" FROM "表格2" WHERE "条件"); #内查询

[比较运算符]

可以是符号的运算符，例如 =、>、<、>=、<= ；也可以是文字的运算符，例如 LIKE、IN、BETWEEN

SELECT SUM(Sales) FROM store_info WHERE Store_Name IN

(SELECT Store_Name FROM location WHERE Region = 'West');



SELECT SUM(A.Sales) FROM store_info A WHERE A.Store_Name IN

(SELECT Store_Name FROM location B WHERE B.Store_Name = A.Store_Name);

7. EXISTS

用来测试内查询有没有产生任何结果，类似布尔值是否为真 #如果有的话，系统就会执行外查询中的SQL语句。若是没有的话，那整个 SQL 语句就不会产生任何结果。

语法：SELECT "字段1" FROM "表格1" WHERE EXISTS (SELECT \* FROM "表格2" WHERE "条件");

SELECT SUM(Sales) FROM store_info WHERE EXISTS (SELECT * FROM location WHERE Region = 'West');

8. 连接查询

准备工作

create database k1;

use k1;

create table location (Region char(20),Store_Name char(20));

insert int0 location values('East','Boston');

insert int0 location values('East','New York');

insert int0 location values('West','Los Angeles');

insert int0 location values('West','Houston');

create table store_info (Store_Name char(20),Sales int(10),Date char(10));

insert int0 store_info values('Los Angeles','1500','2020-12-05');

insert int0 store_info values('Houston','250','2020-12-07');

insert int0 store_info values('Los Angeles','300','2020-12-08');

insert int0 store_info values('Boston','700','2020-12-08');

UPDATE store_info SET store_name='Washington' WHERE sales=300;

inner join(内连接)：只返回两个表中联结字段相等的行

left join(左连接)：返回包括左表中的所有记录和右表中联结字段相等的记录

right join(右连接)：返回包括右表中的所有记录和左表中联结字段相等的记录

8.1 内连接

MySQL 中的内连接就是两张或多张表中同时符合某种条件的数据记录的组合。通常在 FROM 子句中使用关键字 INNER JOIN 来连接多张表，并使用 ON 子句设置连接条件，内连接是系统默认的表连接，所以在 FROM 子句后可以省略 INNER 关键字，只使用关键字 JOIN。同时有多个表时，也可以连续使用 INNER JOIN 来实现多表的内连接，不过为了更好的性能，建议最好不要超过三个表

(1) 语法求交集

SELECT column_name(s)FROM table1 INNER JOIN table2 ON table1.column_name = table2.column_name;

SELECT * FROM location A INNER JOIN store_info B on A.Store_Name = B.Store_Name ;

内连查询：通过inner join 的方式将两张表指定的相同字段的记录行输出出来

8.2 左连接

左连接也可以被称为左外连接，在 FROM 子句中使用 LEFT JOIN 或者 LEFT OUTER JOIN 关键字来表示。左连接以左侧表为基础表，接收左表的所有行，并用这些行与右侧参考表中的记录进行匹配，也就是说匹配左表中的所有行以及右表中符合条件的行。

SELECT * FROM location A LEFT JOIN store_info B on A.Store_Name = B.Store_Name ;

左连接中左表的记录将会全部表示出来，而右表只会显示符合搜索条件的记录，右表记录不足的地方均为 NULL

8.3 右连接

右连接也被称为右外连接，在 FROM 子句中使用 RIGHT JOIN 或者 RIGHT OUTER JOIN 关键字来表示。右连接跟左连接正好相反，它是以右表为基础表，用于接收右表中的所有行，并用这些记录与左表中的行进行匹配

SELECT * FROM location A RIGHT JOIN store_info B on A.Store_Name = B.Store_Name ;

9. UNION ----联集

将两个SQL语句的结果合并起来，两个SQL语句所产生的字段需要是同样的数据记录种类

UNION ：生成结果的数据记录值将没有重复，且按照字段的顺序进行排序

语法：[SELECT 语句 1] UNION [SELECT 语句 2];

SELECT Store_Name FROM location UNION SELECT Store_Name FROM store_info;

UNION ALL ：将生成结果的数据记录值都列出来，无论有无重复

语法：[SELECT 语句 1] UNION ALL [SELECT 语句 2];

SELECT Store_Name FROM location UNION ALL SELECT Store_Name FROM store_info;

9.1 交集值

取两个SQL语句结果的交集

SELECT A.Store_Name FROM location A INNER JOIN store_info B ON A.Store_Name = B.Store_Name;



SELECT A.Store_Name FROM location A INNER JOIN store_info B USING(Store_Name);

取两个SQL语句结果的交集，且没有重复

SELECT DISTINCT A.Store_Name FROM location A INNER JOIN store_info B USING(Store_Name);



SELECT DISTINCT Store_Name FROM location WHERE (Store_Name) IN (SELECT Store_Name FROM store_info);



SELECT DISTINCT A.Store_Name FROM location A LEFT JOIN store_info B USING(Store_Name) WHERE B.Store_Name IS NOT NULL;



SELECT A.Store_Name FROM (SELECT B.Store_Name FROM location B INNER JOIN store_info C ON B.Store_Name = C.Store_Name) A 

GR0UP BY A.Store_Name;



SELECT A.Store_Name FROM 

(SELECT DISTINCT Store_Name FROM location UNION ALL SELECT DISTINCT Store_Name FROM store_info) A 

GR0UP BY A.Store_Name HAVING COUNT(*) > 1;

9.2 无交集值

显示第一个SQL语句的结果，且与第二个SQL语句没有交集的结果，且没有重复

SELECT DISTINCT Store_Name FROM location WHERE (Store_Name) NOT IN (SELECT Store_Name FROM store_info);



SELECT DISTINCT A.Store_Name FROM location A LEFT JOIN store_info B USING(Store_Name) WHERE B.Store_Name IS NULL;



SELECT A.Store_Name FROM 

(SELECT DISTINCT Store_Name FROM location UNION ALL SELECT DISTINCT Store_Name FROM store_info) A 

GR0UP BY A.Store_Name HAVING COUNT(*) = 1;

10. case

是 SQL 用来做为 IF-THEN-ELSE 之类逻辑的关键字

语法：

SELECT CASE ("字段名")

  WHEN "条件1" THEN "结果1"

  WHEN "条件2" THEN "结果2"

  ...

  [ELSE "结果N"]

  END

FROM "表名";

"条件" 可以是一个数值或是公式。 ELSE 子句则并不是必须的。

SELECT Store_Name, CASE Store_Name 

  WHEN 'Los Angeles' THEN Sales * 2 

  WHEN 'Boston' THEN 2000

  ELSE Sales 

  END 

"New Sales",Date 

FROM store_info;



#"New Sales" 是用于 CASE 那个字段的字段名。

11. 正则表达式

匹配模式	描述	实例
^	匹配文本的结束字符	‘^bd’ 匹配以 bd 开头的字符串
$	匹配文本的结束字符	‘qn$’ 匹配以 qn 结尾的字符串
.	匹配任何单个字符	‘s.t’ 匹配任何 s 和 t 之间有一个字符的字符串
*	匹配零个或多个在它前面的字符	‘fo*t’ 匹配 t 前面有任意个 o
+	匹配前面的字符 1 次或多次	‘hom+’ 匹配以 ho 开头，后面至少一个m 的字符串
字符串	匹配包含指定的字符串	‘clo’ 匹配含有 clo 的字符串
p1\|p2	匹配 p1 或 p2	‘bg\|fg’ 匹配 bg 或者 fg
[...]	匹配字符集合中的任意一个字符	‘[abc]’ 匹配 a 或者 b 或者 c
[^...]	匹配不在括号中的任何字符	‘[^ab]’ 匹配不包含 a 或者 b 的字符串
{n}	匹配前面的字符串 n 次	‘g{2}’ 匹配含有 2 个 g 的字符串
{n,m}	匹配前面的字符串至少 n 次，至多m 次	‘f{1,3}’ 匹配 f 最少 1 次，最多 3 次

语法：SELECT "字段" FROM "表名" WHERE "字段" REGEXP {模式};

SELECT * FROM store_info WHERE Store_Name REGEXP 'os';

SELECT * FROM store_info WHERE Store_Name REGEXP '^[A-G]';

SELECT * FROM store_info WHERE Store_Name REGEXP 'Ho|Bo';

12. 存储过程

存储过程是一组为了完成特定功能的SQL语句集合。

存储过程在使用过程中是将常用或者复杂的工作预先使用SQL语句写好并用一个指定的名称存储起来，这个过程经编译和优化后存储在数据库服务器中。当需要使用该存储过程时，只需要调用它即可。存储过程在执行上比传统SQL速度更快、执行效率更高。

存储过程的优点：

1、执行一次后，会将生成的二进制代码驻留缓冲区，提高执行效率

2、SQL语句加上控制语句的集合，灵活性高

3、在服务器端存储，客户端调用时，降低网络负载

4、可多次重复被调用，可随时修改，不影响客户端调用

5、可完成所有的数据库操作，也可控制数据库的信息访问权限

12.1 创建存储过程

DELIMITER $$							#将语句的结束符号从分号;临时改为两个$$(可以是自定义)

CREATE PROCEDURE Proc()					#创建存储过程，过程名为Proc，不带参数

-> BEGIN								#过程体以关键字 BEGIN 开始

-> select * from Store_Info;			#过程体语句

-> END $$								#过程体以关键字 END 结束

DELIMITER ;								#将语句的结束符号恢复为分号

实例

DELIMITER $$							#将语句的结束符号从分号;临时改为两个$$(可以自定义)

CREATE PROCEDURE Proc5()				#创建存储过程，过程名为Proc5，不带参数

-> BEGIN								#过程体以关键字 BEGIN 开始

-> create table user (id int (10), name char(10),score int (10));

-> insert int0 user values (1, 'cyw',70);

-> select * from cyw;			        #过程体语句

-> END $$								#过程体以关键字 END 结束

DELIMITER ;								#将语句的结束符号恢复为分号

12.2 调用存储过程

CALL Proc;

12.3 查看存储过程

SHOW CREATE PROCEDURE [数据库.]存储过程名; #查看某个存储过程的具体信息

SHOW CREATE PROCEDURE Proc;



SHOW PROCEDURE STATUS [LIKE '%Proc%'] \G

12.4 存储过程的参数

**IN 输入参数：**表示调用者向过程传入值（传入值可以是字面量或变量）

**OUT 输出参数：**表示过程向调用者传出值(可以返回多个值)（传出值只能是变量）

**INOUT 输入输出参数：**既表示调用者向过程传入值，又表示过程向调用者传出值（值只能是变量）

DELIMITER $$				

CREATE PROCEDURE Proc6(IN inname CHAR(16))		

-> BEGIN					

-> SELECT * FROM store_info WHERE Store_Name = inname;

-> END $$					

DELIMITER ;					



CALL Proc6('Boston');

12.5 修改存储过程

ALTER PROCEDURE <过程名>[<特征>... ]

ALTER PROCEDURE GetRole MODIFIES SQL DATA SQL SECURITY INVOKER;

MODIFIES sQLDATA:表明子程序包含写数据的语句

SECURITY:安全等级

invoker:当定义为INVOKER时，只要执行者有执行权限，就可以成功执行。

12.6 删除存储过程

存储过程内容的修改方法是通过删除原有存储过程，之后再以相同的名称创建新的存储过程。如果要修改存储过程的名称，可以先删除原存储过程，再以不同的命名创建新的存储过程。

DROP PROCEDURE IF EXISTS Proc;		

#仅当存在时删除，不添加 IF EXISTS 时，如果指定的过程不存在，则产生一个错误

13. 条件语句

if-then-else ···· end if

mysql> delimiter $$

mysql> 

mysql> CREATE PROCEDURE proc8(IN pro int)

    -> 

    -> begin

    -> 

    -> declare var int; 

    -> set var=pro*2;

    -> if var>=10 then 

    -> update t set id=id+1;

    -> else

    -> update t set id=id-1;

    -> end if;

    -> end $$



mysql> delimiter ;

14. 循环语句

while ···· end while

mysql> delimiter $$

mysql> 

mysql> create procedure proc9()

    -> begin 

    -> declare var int(10);  

    -> set var=0;

    -> while var<6 do 

    -> insert int0 t values(var);

    -> set var=var+1;

    -> end while;

    -> end $$ 



mysql> delimiter ;

15. 视图表 create view

15.1 视图表概述

视图，可以被当作是虚拟表或存储查询。

视图跟表格的不同是，表格中有实际储存数据记录，而视图是建立在表格之上的一个架构，它本身并不实际储存数据记录。

临时表在用户退出或同数据库的连接断开后就自动消失了，而视图不会消失。
视图不含有数据，只存储它的定义，它的用途一般可以简化复杂的查询。

比如你要对几个表进行连接查询，而且还要进行统计排序等操作，写sql语句会很麻烦的，用视图将几个表联结起来，然后对这个视图进行查询操作，就和对一个表查询一样，很方便。

15.2 视图表能否修改？

首先我们需要知道，视图表保存的是select语句的定义，所以视图表可不可以修改需要视情况而定。

如果 select 语句查询的字段是没有被处理过的源表字段，则可以通过视图表修改源表数据；

如果select 语句查询的字段是被 gr0up by语句或函数处理过的字段，则不可以直接修改视图表的数据。

create view v_store_info as select store_name,sales from store_info;



update v_store_info set sales=1000 where store_name='Houston';

create view v_sales as select store_name,sum(sales) from store_info gr0up by store_name having sum(sales)>1000;



update v_sales set store_name='xxxx' where store_name='Los Angeles';

15.3 基本语法

15.3.1 创建视图表

语法

create view "视图表名" as "select 语句";

create view v_region_sales as select a.region region,sum(b.sales) sales from location a 

inner join store_info b on a.store_name = b.store_name gr0up by region;

15.4 查看视图表

语法

select * from 视图表名;

select * from v_region_sales;

15.5 删除视图表

语法

drop view 视图表名;

drop view v_region_sales;

15.6 通过视图表求无交集值

将两个表中某个字段的不重复值进行合并

只出现一次（count =1 ），即无交集

通过

create view 视图表名 as select distinct 字段 from 左表 union all select distinct 字段 from 右表;



select 字段 from 视图表名 gr0up by 字段 having count(字段)=1;

#先建立视图表

create viem v_union as select distinct store_name from location union all select distinct store_name from store_info;

#再通过视图表求无交集

select store_name from v_union gr0up by store_name having count(*)=1;

作者：lc111
来源：juejin.cn/post/7291952951047929868

收起阅读 »

哇塞，新来个架构师，把Nacos注册中心讲得炉火纯青，佩服佩服~~

综合技术讨论

大家好，我是三友~~ 今天就应某位小伙伴的要求，来讲一讲Nacos作为服务注册中心底层的实现原理不知你是否跟我一样，在使用Nacos时有以下几点疑问：临时实例和永久实例是什么？有什么区别？服务实例是如何注册到服务端的？服务实例和服务端之间是如何保活的...

继续阅读 »

大家好，我是三友~~

今天就应某位小伙伴的要求，来讲一讲Nacos作为服务注册中心底层的实现原理

不知你是否跟我一样，在使用Nacos时有以下几点疑问：

临时实例和永久实例是什么？有什么区别？

服务实例是如何注册到服务端的？

服务实例和服务端之间是如何保活的？

服务订阅是如何实现的？

集群间数据是如何同步的？CP还是AP？

Nacos的数据模型是什么样的？

本文就通过探讨上述问题来探秘Nacos服务注册中心核心的底层实现原理。

虽然Nacos最新版本已经到了2.x版本，但是为了照顾那些还在用1.x版本的同学，所以本文我会同时去讲1.x版本和2.x版本的实现

临时实例和永久实例

临时实例和永久实例在Nacos中是一个非常非常重要的概念

之所以说它重要，主要是因为我在读源码的时候发现，临时实例和永久实例在底层的许多实现机制是完全不同的

临时实例

临时实例在注册到注册中心之后仅仅只保存在服务端内部一个缓存中，不会持久化到磁盘

这个服务端内部的缓存在注册中心届一般被称为服务注册表

当服务实例出现异常或者下线之后，就会把这个服务实例从服务注册表中剔除

永久实例

永久服务实例不仅仅会存在服务注册表中，同时也会被持久化到磁盘文件中

当服务实例出现异常或者下线，Nacos只会将服务实例的健康状态设置为不健康，并不会对将其从服务注册表中剔除

所以这个服务实例的信息你还是可以从注册中心看到，只不过处于不健康状态

这是就是两者最最最基本的区别

当然除了上述最基本的区别之外，两者还有很多其它的区别，接下来本文还会提到

这里你可能会有一个疑问

为什么Nacos要将服务实例分为临时实例和永久实例?

主要还是因为应用场景不同

临时实例就比较适合于业务服务，服务下线之后可以不需要在注册中心中查看到

永久实例就比较适合需要运维的服务，这种服务几乎是永久存在的，比如说MySQL、Redis等等

MySQL、Redis等服务实例可以通过SDK手动注册

对于这些服务，我们需要一直看到服务实例的状态，即使出现异常，也需要能够查看时实的状态

所以从这可以看出Nacos跟你印象中的注册中心不太一样，他不仅仅可以注册平时业务中的实例，还可以注册像MySQL、Redis这个服务实例的信息到注册中心

在SpringCloud环境底下，一般其实都是业务服务，所以默认注册服务实例都是临时实例

当然如果你想改成永久实例，可以通过下面这个配置项来完成

spring

  cloud:

    nacos:

      discovery:

        #ephemeral单词是临时的意思，设置成false，就是永久实例了

        ephemeral: false

这里还有一个小细节

在1.x版本中，一个服务中可以既有临时实例也有永久实例，服务实例是永久还是临时是由服务实例本身决定的

但是2.x版本中，一个服务中的所有实例要么都是临时的要么都是永久的，是由服务决定的，而不是具体的服务实例

所以在2.x可以说是临时服务和永久服务

为什么2.x把临时还是永久的属性由实例本身决定改成了由服务决定?

其实很简单，你想想，假设对一个MySQL服务来说，它的每个服务实例肯定都是永久的，不会出现一些是永久的，一些是临时的情况吧

所以临时还是永久的属性由服务本身决定其实就更加合理了

服务注册

作为一个服务注册中心，服务注册肯定是一个非常重要的功能

所谓的服务注册，就是通过注册中心提供的客户端SDK（或者是控制台）将服务本身的一些元信息，比如ip、端口等信息发送到注册中心服务端

服务端在接收到服务之后，会将服务的信息保存到前面提到的服务注册表中

1、1.x版本的实现

在Nacos在1.x版本的时候，服务注册是通过Http接口实现的

代码如下

整个逻辑比较简单，因为Nacos服务端本身就是用SpringBoot写的

但是在2.x版本的实现就比较复杂了

2、2.x版本的实现

2.1、通信协议的改变

2.x版本相比于1.x版本最主要的升级就是客户端和服务端通信协议的改变，由1.x版本的Http改成了2.x版本gRPC

gRPC是谷歌公司开发的一个高性能、开源和通用的RPC框架，Java版本的实现底层也是基于Netty来的

之所以改成了gRPC，主要是因为Http请求会频繁创建和销毁连接，白白浪费资源

所以在2.x版本之后，为了提升性能，就将通信协议改成了gRPC

根据官网显示，整体的效果还是很明显，相比于1.x版本，注册性能总体提升至少2倍

虽然通信方式改成了gRPC，但是2.x版本服务端依然保留了Http注册的接口，所以用1.x的Nacos SDK依然可以注册到2.x版本的服务端

2.2、具体的实现

Nacos客户端在启动的时候，会通过gRPC跟服务端建立长连接

这个连接会一直存在，之后客户端与服务端所有的通信都是基于这个长连接来的

当客户端发起注册的时候，就会通过这个长连接，将服务实例的信息发送给服务端

服务端拿到服务实例，跟1.x一样，也会存到服务注册表

除了注册之外，当注册的是临时实例时，2.x还会将服务实例信息存储到客户端中的一个缓存中，供Redo操作

所谓的Redo操作，其实就是一个补偿机制，本质是个定时任务，默认每3s执行一次

这个定时任务作用是，当客户端与服务端重新建立连接时（因为一些异常原因导致连接断开）

那么之前注册的服务实例肯定还要继续注册服务端（断开连接服务实例就会被剔除服务注册表）

所以这个Redo操作一个很重要的作用就是重连之后的重新注册的作用

除了注册之外，比如服务订阅之类的操作也需要Redo操作，当连接重新建立，之前客户端的操作都需要Redo一下

小总结

1.x版本是通过Http协议来进行服务注册的

2.x由于客户端与服务端的通信改成了gRPC长连接，所以改成通过gRPC长连接来注册

2.x比1.x多个Redo操作，当注册的服务实例是临时实例是，出现网络异常，连接重新建立之后，客户端需要将服务注册、服务订阅之类的操作进行重做

这里你可能会有个疑问

既然2.x有Redo机制保证客户端与服务端通信正常之后重新注册，那么1.x有类似的这种Redo机制么？

当然也会有，接下往下看。

心跳机制

心跳机制，也可以被称为保活机制，它的作用就是服务实例告诉注册中心我这个服务实例还活着

在正常情况下，服务关闭了，那么服务会主动向Nacos服务端发送一个服务下线的请求

Nacos服务端在接收到请求之后，会将这个服务实例从服务注册表中剔除

但是对于异常情况下，比如出现网络问题，可能导致这个注册的服务实例无法提供服务，处于不可用状态，也就是不健康

而此时在没有任何机制的情况下，服务端是无法知道这个服务处于不可用状态

所以为了避免这种情况，一些注册中心，就比如Nacos、Eureka，就会用心跳机制来判断这个服务实例是否能正常

在Nacos中，心跳机制仅仅是针对临时实例来说的，临时实例需要靠心跳机制来保活

心跳机制在1.x和2.x版本的实现也是不一样的

1.x心跳实现

在1.x中，心跳机制实现是通过客户端和服务端各存在的一个定时任务来完成的

在服务注册时，发现是临时实例，客户端会开启一个5s执行一次的定时任务

这个定时任务会构建一个Http请求，携带这个服务实例的信息，然后发送到服务端

在Nacos服务端也会开启一个定时任务，默认也是5s执行一次，去检查这些服务实例最后一次心跳的时间，也就是客户端最后一次发送Http请求的时间

当最后一次心跳时间超过15s，但没有超过30s，会把这服务实例标记成不健康

当最后一次心跳超过30s，直接把服务从服务注册表中剔除

这就是1.x版本的心跳机制，本质就是两个定时任务

其实1.x的这个心跳还有一个作用，就是跟上一节说的gRPC时Redo操作的作用是一样的

服务在处理心跳的时候，发现心跳携带这个服务实例的信息在注册表中没有，此时就会添加到服务注册表

所以心跳也有Redo的类似效果

2.x心跳实现

在2.x版本之后，由于通信协议改成了gRPC，客户端与服务端保持长连接，所以2.x版本之后它是利用这个gRPC长连接本身的心跳来保活

一旦这个连接断开，服务端就会认为这个连接注册的服务实例不可用，之后就会将这个服务实例从服务注册表中提出剔除

除了连接本身的心跳之外，Nacos还有服务端的一个主动检测机制

Nacos服务端也会启动一个定时任务，默认每隔3s执行一次

这个任务会去检查超过20s没有发送请求数据的连接

一旦发现有连接已经超过20s没发送请求，那么就会向这个连接对应的客户端发送一个请求

如果请求不通或者响应失败，此时服务端也会认为与客户端的这个连接异常，从而将这个客户端注册的服务实例从服务注册表中剔除

所以对于2.x版本，主要是两种机制来进行保活：

连接本身的心跳机制，断开就直接剔除服务实例

Nacos主动检查机制，服务端会对20s没有发送数据的连接进行检查，出现异常时也会主动断开连接，剔除服务实例

小总结

心跳机制仅仅针对临时实例而言

1.x心跳机制是通过客户端和服务端两个定时任务来完成的，客户端定时上报心跳信息，服务端定时检查心跳时间，超过15s标记不健康，超过30s直接剔除

1.x心跳机制还有类似2.x的Redo作用，服务端发现心跳的服务信息不存在会，会将服务信息添加到注册表，相当于重新注册了

2.x是基于gRPC长连接本身的心跳机制和服务端的定时检查机制来的，出现异常直接剔除

健康检查

前面说了，心跳机制仅仅是临时实例用来保护的机制

而对于永久实例来说，一般来说无法主动上报心跳

就比如说MySQL实例，肯定是不会主动上报心跳到Nacos的，所以这就导致无法通过心跳机制来保活

所以针对永久实例的情况，Nacos通过一种叫健康检查的机制去判断服务实例是否活着

健康检查跟心跳机制刚好相反，心跳机制是服务实例向服务端发送请求

而所谓的健康检查就是服务端主动向服务实例发送请求，去探测服务实例是否活着

健康检查机制在1.x和2.x的实现机制是一样的

Nacos服务端在会去创建一个健康检查任务，这个任务每次执行时间间隔会在2000~7000毫秒之间

当任务触发的时候，会根据设置的健康检查的方式执行不同的逻辑，目前主要有以下三种方式：

HTTP

MySQL

TCP的方式就是根据服务实例的ip和端口去判断是否能连接成功，如果连接成功，就认为健康，反之就任务不健康

HTTP的方式就是向服务实例的ip和端口发送一个Http请求，请求路径是需要设置的，如果能正常请求，说明实例健康，反之就不健康

MySQL的方式是一种特殊的检查方式，他可以执行下面这条Sql来判断数据库是不是主库

默认情况下，都是通过TCP的方式来探测服务实例是否还活着

服务发现

所谓的服务发现就是指当有服务实例注册成功之后，其它服务可以发现这些服务实例

Nacos提供了两种发现方式：

主动查询

服务订阅

主动查询就是指客户端主动向服务端查询需要关注的服务实例，也就是拉（pull）的模式

服务订阅就是指客户端向服务端发送一个订阅服务的请求，当被订阅的服务有信息变动就会主动将服务实例的信息推送给订阅的客户端，本质就是推（push）模式

在我们平时使用时，一般来说都是选择使用订阅的方式，这样一旦有服务实例数据的变动，客户端能够第一时间感知

并且Nacos在整合SpringCloud的时候，默认就是使用订阅的方式

对于这两种服务发现方式，1.x和2.x版本实现也是不一样

服务查询其实两者实现都很简单

1.x整体就是发送Http请求去查询服务实例，2.x只不过是将Http请求换成了gRPC的请求

服务端对于查询的处理过程都是一样的，从服务注册表中查出符合查询条件的服务实例进行返回

不过对于服务订阅，两者的机制就稍微复杂一点

在Nacos客户端，不论是1.x还是2.x都是通过SDK中的NamingService#subscribe方法来发起订阅的

当有服务实例数据变动的时，客户端就会回调EventListener，就可以拿到最新的服务实例数据了

虽然1.x还是2.x都是同样的方法，但是具体的实现逻辑是不一样的

1.x服务订阅实现

在1.x版本的时候，服务订阅的处理逻辑大致会有以下三步：

第一步，客户端在启动的时候，会去构建一个叫PushReceiver的类

这个类会去创建一个UDP Socket，端口是随机的

其实通过名字就可以知道这个类的作用，就是通过UDP的方式接收服务端推送的数据的

第二步，调用NamingService#subscribe来发起订阅时，会先去服务端查询需要订阅服务的所有实例信息

之后会将所有服务实例数据存到客户端的一个内部缓存中

并且在查询的时候，会将这个UDP Socket的端口作为一个参数传到服务端

服务端接收到这个UDP端口后，后续就通过这个端口给客户端推送服务实例数据

第三步，会为这次订阅开启一个不定时执行的任务

之所以不定时，是因为这个当执行异常的时候，下次执行的时间间隔就会变长，但是最多不超过60s，正常是10s，这个10s是查询服务实例是服务端返回的

这个任务会去从服务端查询订阅的服务实例信息，然后更新内部缓存

这里你可能会有个疑问

既然有了服务变动推送的功能，为什么还要定时去查询更新服务实例信息呢?

其实很简单，那就是因为UDP通信不稳定导致的

虽然有Push，但是由于UDP通信自身的不确定性，有可能会导致客户端接收变动信息失败

所以这里就加了一个定时任务，弥补这种可能性，属于一个兜底的方案。

这就是1.x版本的服务订阅的实现

2.x服务订阅的实现

讲完1.x的版本实现，接下来就讲一讲2.x版本的实现

由于2.x版本换成了gRPC长连接的方式，所以2.x版本服务数据变更推送已经完全抛弃了1.x的UDP做法

当有服务实例变动的时候，服务端直接通过这个长连接将服务信息发送给客户端

客户端拿到最新服务实例数据之后的处理方式就跟1.x是一样了

除了处理方式一样，2.x也继承了1.x的其他的东西

比如客户端依然会有服务实例的缓存

定时对比机制也保留了，只不过这个定时对比的机制默认是关闭状态

之所以默认关闭，主要还是因为长连接还是比较稳定的原因

当客户端出现异常，接收不到请求，那么服务端会直接跟客户端断开连接

当恢复正常，由于有Redo操作，所以还是能拿到最新的实例信息的

所以2.x版本的服务订阅功能的实现大致如下图所示

这里还有个细节需要注意

在1.x版本的时候，任何服务都是可以被订阅的

但是在2.x版本中，只支持订阅临时服务，对于永久服务，已经不支持订阅了

小总结

服务查询1.x是通过Http请求；2.x通过gRPC请求

服务订阅1.x是通过UDP来推送的；2.x就基于gRPC长连接来实现的

1.x和2.x客户端都有服务实例的缓存，也有定时对比机制，只不过1.x会自动开启；2.x提供了一个开个，可以手动选择是否开启，默认不开启

数据一致性

由于Nacos是支持集群模式的，所以一定会涉及到分布式系统中不可避免的数据一致性问题

1、服务实例的责任机制

再说数据一致性问题之前，先来讨论一下服务实例的责任机制

什么是服务实例的责任机制？

比如上面提到的服务注册、心跳管理、监控检查机制，当只有一个Nacos服务时，那么自然而言这个服务会去检查所有的服务实例的心跳时间，执行所有服务实例的健康检查任务

但是当出现Nacos服务出现集群时，为了平衡各Nacos服务的压力，Nacos会根据一定的规则让每个Nacos服务只管理一部分服务实例的

当然每个Nacos服务的注册表还是全部的服务实例数据

这个管理机制我给他起了一个名字，就叫做责任机制，因为我在1.x和2.x都提到了responsible这个单词

本质就是Nacos服务对哪些服务实例负有心跳监测，健康检查的责任。

2、CAP定理和BASE理论

谈到数据一致性问题，一定离不开两个著名分布式理论

CAP定理

BASE理论

CAP定理中，三个字母分别代表这些含义：

C，Consistency单词的缩写，代表一致性，指分布式系统中各个节点的数据保持强一致，也就是每个时刻都必须一样，不一样整个系统就不能对外提供服务

A，Availability单词的缩写，代表可用性，指整个分布式系统保持对外可用，即使从每个节点获取的数据可能都不一样，只要能获取到就行

P，Partition tolerance单词的缩写，代表分区容错性。

所谓的CAP定理，就是指在一个分布式系统中，CAP这三个指标，最多同时只能满足其中的两个，不可能三个都同时满足

为什么三者不能同时满足？

对于一个分布式系统，网络分区是一定需要满足的

而所谓分区指的是系统中的服务部署在不同的网络区域中

比如，同一套系统可能同时在北京和上海都有部署，那么他们就处于不同的网络分区，就可能出现无法互相访问的情况

当然，你也可以把所有的服务都放在一个网络分区，但是当网络出现故障时，整个系统都无法对外提供服务，那这还有什么意义呢？

所以分布式系统一定需要满足分区容错性，把系统部署在不同的区域网络中

此时只剩下了一致性和可用性，它们为什么不能同时满足？

其实答案很简单，就因为可能出现网络分区导致的通信失败。

比如说，现在出现了网络分区的问题，上图中的A网络区域和B网络区域无法相互访问

此时假设往上图中的A网络区域发送请求，将服务中的一个值 i 属性设置成 1

如果保证可用性，此时由于A和B网络不通，此时只有A中的服务修改成功，B无法修改成功，此时数据AB区域数据就不一致性，也就没有保证数据一致性

如果保证一致性，此时由于A和B网络不通，所以此时A也不能修改成功，必须修改失败，否则就会导致AB数据不一致

虽然A没修改成功，保证了数据一致性，AB还是之前相同的数据，但是此时整个系统已经没有写可用性了，无法成功写数据了。

所以从上面分析可以看出，在有分区容错性的前提下，可用性和一致性是无法同时保证的。

虽然无法同时一致性和可用性，但是能不能换种思路来思考一下这个问题

首先我们可以先保证系统的可用性，也就是先让系统能够写数据，将A区域服务中的i修改成1

之后当AB区域之间网络恢复之后，将A区域的i值复制给B区域，这样就能够保证AB区域间的数据最终是一致的了

这不就皆大欢喜了么

这种思路其实就是BASE理论的核心要点，优先保证可用性，数据最终达成一致性。

BASE理论主要是包括以下三点：

基本可用（Basically Available）：系统出现故障还是能够对外提供服务，不至于直接无法用了

软状态（Soft State）：允许各个节点的数据不一致

最终一致性，（Eventually Consistent）：虽然允许各个节点的数据不一致，但是在一定时间之后，各个节点的数据最终需要一致的

BASE理论其实就是妥协之后的产物。

3、Nacos的AP和CP

Nacos其实目前是同时支持AP和CP的

具体使用AP还是CP得取决于Nacos内部的具体功能，并不是有的文章说的可以通过一个配置自由切换。

就以服务注册举例来说，对于临时实例来说，Nacos会优先保证可用性，也就是AP

对于永久实例，Nacos会优先保证数据的一致性，也就是CP

接下来我们就来讲一讲Nacos的CP和AP的实现原理

3.1、Nacos的AP实现

对于AP来说，Nacos使用的是阿里自研的Distro协议

在这个协议中，每个服务端节点是一个平等的状态，每个服务端节点正常情况下数据是一样的，每个服务端节点都可以接收来自客户端的读写请求

当某个节点刚启动时，他会向集群中的某个节点发送请求，拉取所有的服务实例数据到自己的服务注册表中

这样其它客户端就可以从这个服务节点中获取到服务实例数据了

当某个服务端节点接收到注册临时服务实例的请求，不仅仅会将这个服务实例存到自身的服务注册表，同时也会向其它所有服务节点发送请求，将这个服务数据同步到其它所有节点

所以此时从任意一个节点都是可以获取到所有的服务实例数据的。

即使数据同步的过程发生异常，服务实例也成功注册到一个Nacos服务中，对外部而言，整个Nacos集群是可用的，也就达到了AP的效果

同时为了满足BASE理论，Nacos也有下面两种机制保证最终节点间数据最终是一致的：

失败重试机制

定时对比机制

失败重试机制是指当数据同步给其它节点失败时，会每隔3s重试一次，直到成功

定时对比机制就是指，每个Nacos服务节点会定时向所有的其它服务节点发送一些认证的请求

这个请求会告诉每个服务节点自己负责的服务实例的对应的版本号，这个版本号随着服务实例的变动就会变动

如果其它服务节点的数据的版本号跟自己的对不上，那就说明其它服务节点的数据不是最新的

此时这个Nacos服务节点就会将自己负责的服务实例数据发给不是最新数据的节点，这样就保证了每个节点的数据是一样的了。

3.2、Nacos的CP实现

Nacos的CP实现是基于Raft算法来实现的

在1.x版本早期，Nacos是自己手动实现Raft算法

在2.x版本，Nacos移除了手动实现Raft算法，转而拥抱基于蚂蚁开源的JRaft框架

在Raft算法，每个节点主要有三个状态

Leader，负责所有的读写请求，一个集群只有一个

Follower，从节点，主要是负责复制Leader的数据，保证数据的一致性

Candidate，候选节点，最终会变成Leader或者Follower

集群启动时都是节点Follower，经过一段时间会转换成Candidate状态，再经过一系列复杂的选择算法，选出一个Leader

这个选举算法比较复杂，完全值得另写一篇文章，这里就不细说了。不过立个flag，如果本篇文章点赞量超过28个，我连夜爆肝，再来一篇。

当有写请求时，如果请求的节点不是Leader节点时，会将请求转给Leader节点，由Leader节点处理写请求

比如，有个客户端连到的上图中的Nacos服务2节点，之后向Nacos服务2注册服务

Nacos服务2接收到请求之后，会判断自己是不是Leader节点，发现自己不是

此时Nacos服务2就会向Leader节点发送请求，Leader节点接收到请求之后，会处理服务注册的过程

为什么说Raft是保证CP的呢？

主要是因为Raft在处理写的时候有一个判断过程

首先，Leader在处理写请求时，不会直接数据应用到自己的系统，而是先向所有的Follower发送请求，让他们先处理这个请求

当超过半数的Follower成功处理了这个写请求之后，Leader才会写数据，并返回给客户端请求处理成功

如果超过一定时间未收到超过半数处理成功Follower的信号，此时Leader认为这次写数据是失败的，就不会处理写请求，直接返回给客户端请求失败

所以，一旦发生故障，导致接收不到半数的Follower写成功的响应，整个集群就直接写失败，这就很符合CP的概念了。

不过这里还有一个小细节需要注意

Nacos在处理查询服务实例的请求直接时，并不会将请求转发给Leader节点处理，而是直接查当前Nacos服务实例的注册表

这其实就会引发一个问题

如果客户端查询的Follower节点没有及时处理Leader同步过来的写请求（过半响应的节点中不包括这个节点），此时在这个Follower其实是查不到最新的数据的，这就会导致数据的不一致

所以说，虽然Raft协议规定要求从Leader节点查最新的数据，但是Nacos至少在读服务实例数据时并没有遵守这个协议

当然对于其它的一些数据的读写请求有的还是遵守了这个协议。

JRaft对于读请求其实是做了很多优化的，其实从Follower节点通过一定的机制也是能够保证读到最新的数据

数据模型

在Nacos中，一个服务的确定是由三部分信息确定

命名空间（Namespace）：多租户隔离用的，默认是public

分组（Gr0up）：这个其实可以用来做环境隔离，服务注册时可以指定服务的分组，比如是测试环境或者是开发环境，默认是DEFAULT_GR0UP

服务名（ServiceName）：这个就不用多说了

通过上面三者就可以确定同一个服务了

在服务注册和订阅的时候，必须要指定上述三部分信息，如果不指定，Nacos就会提供默认的信息

不过，在Nacos中，在服务里面其实还是有一个集群的概念

在服务注册的时候，可以指定这个服务实例在哪个集体的集群中，默认是在DEFAULT集群下

在SpringCloud环境底下可以通过如下配置去设置

spring

  cloud:

    nacos:

      discovery:

        cluster-name: sanyoujavaCluster

在服务订阅的时候，可以指定订阅哪些集群下的服务实例

当然，也可以不指定，如果不指定话，默认就是订阅这个服务下的所有集群的服务实例

我们日常使用中可以将部署在相同区域的服务划分为同一个集群，比如杭州属于一个集群，上海属于一个集群

这样服务调用的时候，就可以优先使用同一个地区的服务了，比跨区域调用速度更快。

总结

到这，终终终于总算是讲完了Nacos作为注册中心核心的实现原理

作者：zzyang90
来源：juejin.cn/post/7347325319198048283

收起阅读 »

你居然还去服务器上捞日志，搭个日志收集系统难道不香么！

综合技术讨论

1 ELK日志系统经典的ELK架构或现被称为Elastic Stack。Elastic Stack架构为Elasticsearch + Logstash + Kibana + Beats的组合： Beats负责日志的采集 Logstash负责做日志的聚合和...

继续阅读 »

1 ELK日志系统

经典的ELK架构或现被称为Elastic Stack。Elastic Stack架构为Elasticsearch + Logstash + Kibana + Beats的组合：

Beats负责日志的采集

Logstash负责做日志的聚合和处理

ES作为日志的存储和搜索系统

Kibana作为可视化前端展示

整体架构图：

2 EFK日志系统

容器化场景中，尤其k8s环境，用户经常使用EFK架构。F代表Fluent Bit，一个开源多平台的日志处理器和转发器。Fluent Bit可以：

让用户从不同来源收集数据/日志

统一并发到多个目的地

完全兼容Docker和k8s环境

3 PLG日志系统

3.1 Prometheus+k8s日志系统

PLG

Grafana Labs提供的另一个日志解决方案PLG逐渐流行。PLG架构即Promtail + Loki + Grafana的组合：

Grafana，开源的可视化和分析软件，允许用户查询、可视化、警告和探索监控指标。Grafana主要提供时间序列数据的仪表板解决方案，支持超过数十种数据源。

Grafana Loki是一组可以组成一个功能齐全的日志堆栈组件，与其它日志系统不同，Loki只建立日志标签的索引而不索引原始日志消息，而是为日志数据设置一组标签，即Loki运营成本更低，效率还提高几个数量级。

Loki设计理念

Prometheus启发，可实现可水平扩展、高可用的多租户日志系统。Loki整体架构由不同组件协同完成日志收集、索引、存储等。

各组件如下，Loki’s Architecture深入了解。Loki就是like Prometheus, but for logs。

Promtail是一个日志收集的代理，会将本地日志内容发到一个Loki实例，它通常部署到需要监视应用程序的每台机器/容器上。Promtail主要是用来发现目标、将标签附加到日志流以及将日志推送到Loki。截止到目前，Promtail可以跟踪两个来源的日志：本地日志文件和systemd日志（仅支持AMD64架构）。

4 PLG V.S ELK

4.1 ES V.S Loki

ELK/EFK架构确实强，经多年实际环境验证。存储在ES中的日志通常以非结构化JSON对象形式存储在磁盘，且ES为每个对象都建索引，以便全文搜索，然后用户可特定查询语言搜索这些日志数据。

而Loki数据存储解耦：

既可在磁盘存储

也可用如Amazon S3云存储系统

Loki日志带有一组标签名和值，只有标签对被索引，这种权衡使它比完整索引操作成本更低，但针对基于内容的查询，需通过LogQL再单独查询。

4.2 Fluentd V.S Promtail

相比Fluentd，Promtail专为Loki定制，它可为运行在同一节点的k8s Pods做服务发现，从指定文件夹读取日志。Loki类似Prometheus的标签方式。因此，当与Prometheus部署在同一环境，因为相同的服务发现机制，来自Promtail的日志通常具有与应用程序指标相同的标签，统一标签管理。

4.3 Grafana V.S Kibana

Kibana提供许多可视化工具来进行数据分析，高级功能如异常检测等机器学习功能。Grafana针对Prometheus和Loki等时间序列数据打造，可在同一仪表板上查看日志指标。

参考

http://www.javaedge.cn/#/special

作者：JavaEdge在掘金
来源：juejin.cn/post/7295623585364082739

收起阅读 »

超级火爆的前端视频方案 FFmpeg ，带你体验一下~

综合技术讨论

前言大家好，我是林三心，用最通俗易懂的话讲最难的知识点是我的座右铭，基础是进阶的前提是我的初心~ ffmpeg FFmpeg 是一个开源的、跨平台的多媒体框架，它可以用来录制、转换和流式传输音频和视频。它包括了一系列的库和工具，用于处理多媒体内容，比如 l...

继续阅读 »

前言

大家好，我是林三心，用最通俗易懂的话讲最难的知识点是我的座右铭，基础是进阶的前提是我的初心~

ffmpeg

FFmpeg 是一个开源的、跨平台的多媒体框架，它可以用来录制、转换和流式传输音频和视频。它包括了一系列的库和工具，用于处理多媒体内容，比如 libavcodec（一个编解码库），libavformat（一个音视频容器格式库），libavutil（一个实用库），以及 ffmpeg 命令行工具本身。

FFmpeg 被广泛用于各种应用中，包括视频转换、视频编辑、视频压缩、直播流处理等。它支持多种音视频编解码器和容器格式，因此能够处理几乎所有类型的音视频文件。由于其功能强大和灵活性，FFmpeg 成为了许多视频相关软件和服务的底层技术基础。

很多网页都是用 ffmpeg 来进行视频切片，比如一个视频很大，如果通过一个连接去请求整个视频的话，那势必会导致加载时间过长，严重阻碍了用户观感

所以很多视频网站都会通过视频切片的方式来优化用户观感，就是一部分一部分地去加载出来，这样有利于用户的体验

安装 ffmpeg

安装包下载

首先到 ffmpeg 的安装网页：http://www.gyan.dev/ffmpeg/buil…

下载解压后将文件夹改名为 ffmpeg

环境变量配置

环境变量配置是为了能在电脑上使用 ffmpeg 命令行

体验 ffmpeg

先准备一个视频，比如我准备了一个视频，总共 300 多 M

视频切片

并在当前的目录下输入以下的命令

 ffmpeg -i jhys.mkv 

 -c:v libx264 

 -c:a aac 

 -hls_time 60 

 -hls_segment_type mpegts 

 -hls_list_size 0 

 -f hls 

 -max_muxing_queue_size 1024 

 output.m3u8

接着 ffmpeg 会帮你将这个视频进行分片

直到切片步骤执行完毕，我们可以看到视频已经别切成几个片了

在这个命令中：

-i input_video.mp4 指定了输入视频文件。

-c:v libx264 -c:a aac 指定了视频和音频的编解码器。

-hls_time 10 指定了每个 M3U8 片段的时长，单位为秒。在这里，每个片段的时长设置为 10 秒。

-hls_segment_type mpegts 指定了 M3U8 片段的类型为 MPEG-TS。

-hls_list_size 0 设置 M3U8 文件中包含的最大片段数。这里设置为 0 表示没有限制。

-f hls 指定了输出格式为 HLS。

-max_muxing_queue_size 1024 设置了最大复用队列大小，以确保输出不会超过指定大小。

最后输出的文件为 output.m3u8

视频播放

创建一个简单的前端项目

可以看到浏览器会加载所有的视频切片

作者：Sunshine_Lin
来源：juejin.cn/post/7361998447908864011

收起阅读 »

写给Java开发的16个小建议

Java

前言开发过程中其实有很多小细节要去注意，只有不断去抠细节，写出精益求精的代码，从量变中收获质变。技术的进步并非一蹴而就，而是通过无数次的量变，才能引发质的飞跃。我们始终坚信，只有对每一个细节保持敏锐的触觉，才能绽放出完美的技术之花。从一行行代码中，我们品...

继续阅读 »

前言

开发过程中其实有很多小细节要去注意，只有不断去抠细节，写出精益求精的代码，从量变中收获质变。

技术的进步并非一蹴而就，而是通过无数次的量变，才能引发质的飞跃。我们始终坚信，只有对每一个细节保持敏锐的触觉，才能绽放出完美的技术之花。

从一行行代码中，我们品味到了追求卓越的滋味。每一个小小的优化，每一个微妙的改进，都是我们追求技艺的印记。我们知道，只有更多的关注细节，才能真正理解技术的本质，洞察其中的玄机。正是在对细节的把握中，我们得以成就更好的技术人生。

耐心看完，你一定会有所收获。

补充

20230928

针对评论区指出的第14条示例的问题，现已修正。

原来的示例贴在这里，接受大家的批评：

1. 代码风格一致性：

代码风格一致性可以提高代码的可读性和可维护性。例如，使用Java编程中普遍遵循的命名约定（驼峰命名法），使代码更易于理解。

// 不好的代码风格

int g = 10;

String S = "Hello";



// 好的代码风格

int count = 10;

String greeting = "Hello";

2. 使用合适的数据结构和集合：

选择适当的数据结构和集合类可以改进代码的性能和可读性。例如，使用HashSet来存储唯一的元素。

// 不好的例子 - 使用ArrayList存储唯一元素

List<Integer> list = new ArrayList<>();

list.add(1);

list.add(2);

list.add(1); // 重复元素



// 好的例子 - 使用HashSet存储唯一元素

Set<Integer> set = new HashSet<>();

set.add(1);

set.add(2);

set.add(1); // 自动忽略重复元素

3. 避免使用魔法数值：

使用常量或枚举来代替魔法数值可以提高代码的可维护性和易读性。

// 不好的例子 - 魔法数值硬编码

if (status == 1) {

    // 执行某些操作

}



// 好的例子 - 使用常量代替魔法数值

final int STATUS_ACTIVE = 1;

if (status == STATUS_ACTIVE) {

    // 执行某些操作

}

4. 异常处理：

正确处理异常有助于代码的健壮性和容错性，避免不必要的try-catch块可以提高代码性能。

// 不好的例子 - 捕获所有异常，没有具体处理

try {

    // 一些可能抛出异常的操作

} catch (Exception e) {

    // 空的异常处理块

}



// 好的例子 - 捕获并处理特定异常，或向上抛出

try {

    // 一些可能抛出异常的操作

} catch (FileNotFoundException e) {

    // 处理文件未找到异常

} catch (IOException e) {

    // 处理其他IO异常

}

5. 及时关闭资源：

使用完资源后，及时关闭它们可以避免资源泄漏，特别是对于文件流、数据库连接等资源。

更好的处理方式参见第16条，搭配try-with-resources食用最佳

// 不好的例子 - 未及时关闭数据库连接

Connection conn = null;

Statement stmt = null;

try {

    conn = DriverManager.getConnection(DB_URL, DB_USER, DB_PASSWORD);

    stmt = conn.createStatement();

    // 执行数据库查询操作

} catch (SQLException e) {

    e.printStackTrace();

} finally {

    // 数据库连接未关闭

}



// 好的例子 - 使用try-with-resources确保资源及时关闭，避免了数据库连接资源泄漏的问题

try (Connection conn = DriverManager.getConnection(DB_URL, DB_USER, DB_PASSWORD);

    Statement stmt = conn.createStatement()) {

    // 执行数据库查询操作

} catch (SQLException e) {

    e.printStackTrace();

}

6. 避免过度使用全局变量：

过度使用全局变量容易引发意外的副作用和不可预测的结果，建议尽量避免使用全局变量。

// 不好的例子 - 过度使用全局变量

public class MyClass {

    private int count;



    // 省略其他代码

}



// 好的例子 - 使用局部变量或实例变量

public class MyClass {

    public void someMethod() {

        int count = 0;

        // 省略其他代码

    }

}

7. 避免不必要的对象创建：

避免在循环或频繁调用的方法中创建不必要的对象，可以使用对象池、StringBuilder等技术。

// 不好的例子 - 频繁调用方法创建不必要的对象

public String formatData(int year, int month, int day) {

    String formattedDate = String.format("%d-d-d", year, month, day); // 每次调用方法都会创建新的String对象

    return formattedDate;

}



// 好的例子 - 避免频繁调用方法创建不必要的对象

private static final String DATE_FORMAT = "%d-d-d";

public String formatData(int year, int month, int day) {

    return String.format(DATE_FORMAT, year, month, day); // 重复使用同一个String对象

}

8. 避免使用不必要的装箱和拆箱：

避免频繁地在基本类型和其对应的包装类型之间进行转换，可以提高代码的性能和效率。

// 不好的例子

Integer num = 10; // 不好的例子，自动装箱

int result = num + 5; // 不好的例子，自动拆箱



// 好的例子 - 避免装箱和拆箱

int num = 10; // 好的例子，使用基本类型

int result = num + 5; // 好的例子，避免装箱和拆箱

9. 使用foreach循环遍历集合：

使用foreach循环可以简化集合的遍历，并提高代码的可读性。

// 不好的例子 - 可读性不强，并且增加了方法调用的开销

List<String> names = Arrays.asList("Alice", "Bob", "Charlie");

for (int i = 0; i < names.size(); i++) {

    System.out.println(names.get(i)); // 不好的例子

}



// 好的例子 - 更加简洁，可读性更好，性能上也更优

List<String> names = Arrays.asList("Alice", "Bob", "Charlie");

for (String name : names) {

    System.out.println(name); // 好的例子

}

10. 使用StringBuilder或StringBuffer拼接大量字符串：

在循环中拼接大量字符串时，使用StringBuilder或StringBuffer可以避免产生大量临时对象，提高性能。

// 不好的例子 - 每次循环都产生新的字符串对象

String result = "";

for (int i = 0; i < 1000; i++) {

    result += "Number " + i + ", ";

}



// 好的例子 - StringBuilder不会产生大量临时对象

StringBuilder result = new StringBuilder();

for (int i = 0; i < 1000; i++) {

    result.append("Number ").append(i).append(", ");

}

11. 使用equals方法比较对象的内容：

老生常谈的问题，在比较对象的内容时，使用equals方法而不是==操作符，确保正确比较对象的内容。

// 不好的例子

String name1 = "Alice";

String name2 = new String("Alice");

if (name1 == name2) {

    // 不好的例子，使用==比较对象的引用，而非内容

}



// 好的例子

String name1 = "Alice";

String name2 = new String("Alice");

if (name1.equals(name2)) {

    // 好的例子，使用equals比较对象的内容

}

12. 避免使用多个连续的空格或制表符：

多个连续的空格或制表符会使代码看起来杂乱不堪，建议使用合适的缩进和空格，保持代码的清晰可读。

// 不好的例子

int    a = 10;  // 不好的例子，多个连续的空格和制表符

String   name   =   "John";  // 不好的例子，多个连续的空格和制表符



// 好的例子

int a = 10; // 好的例子，适当的缩进和空格

String name = "John"; // 好的例子，适当的缩进和空格

13. 使用日志框架记录日志：

在代码中使用日志框架（如Log4j、SLF4J）来记录日志，而不是直接使用System.out.println()，可以更灵活地管理日志输出和级别。

// 不好的例子：

System.out.println("Error occurred"); // 不好的例子，直接输出日志到控制台



// 好的例子：

logger.error("Error occurred"); // 好的例子，使用日志框架记录日志

14. 避免在循环中创建对象：

在循环中频繁地创建对象会导致大量的内存分配和垃圾回收，影响性能。尽量在循环外部创建对象，或使用对象池来复用对象，从而减少对象的创建和销毁开销。

// 不好的例子 - 在循环过程中频繁地创建和销毁对象，增加了垃圾回收的负担

for (int i = 0; i < 1000; i++) {

    // 在每次循环迭代中创建新的对象，增加内存分配和垃圾回收的开销

    Person person = new Person("John", 30);

    System.out.println("Name: " + person.getName() + ", Age: " + person.getAge());

}





// 好的例子 - 在循环外部创建对象，减少内存分配和垃圾回收的开销

Person person = new Person("John", 30);

for (int i = 0; i < 1000; i++) {

    System.out.println("Name: " + person.getName() + ", Age: " + person.getAge());



    // 可以根据需要修改 person 对象的属性

    person.setName("Alice");

    person.setAge(25);

}

15. 使用枚举替代常量：

这条其实和第3条一个道理，使用枚举可以更清晰地表示一组相关的常量，并且能够提供更多的类型安全性和功能性。

// 不好的例子 - 使用常量表示颜色

public static final int RED = 1;

public static final int GREEN = 2;

public static final int BLUE = 3;



// 好的例子 - 使用枚举表示颜色

public enum Color {

    RED, GREEN, BLUE

}

16. 使用try-with-resources语句：

在处理需要关闭的资源（如文件、数据库连接等）时，使用try-with-resources语句可以自动关闭资源，避免资源泄漏。

// 不好的例子 - 没有使用try-with-resources

FileReader reader = null;

try {

    reader = new FileReader("file.txt");

    // 执行一些操作

} catch (IOException e) {

    // 处理异常

} finally {

    if (reader != null) {

        try {

            reader.close();

        } catch (IOException e) {

            // 处理关闭异常

        }

    }

}



// 好的例子 - 使用try-with-resources自动关闭资源

try (FileReader reader = new FileReader("file.txt")) {

    // 执行一些操作

} catch (IOException e) {

    // 处理异常

}

总结

这16个小建议，希望对你有所帮助。

技术的路上充满挑战，但要相信，把细节搞好，技术会越来越牛。小小的优化，微小的改进，都能让我们的代码变得更好。

时间飞逝，我们要不断学习，不断努力。每个技术小突破都是我们不懈努力的成果。要用心倾听，用心琢磨，这样才能在技术的道路上越走越远。

从每一次写代码的过程中，我们收获更多。我们要踏实做好每个细节。在代码的世界里，细节是我们的罗盘。

坚持初心，不忘初心！

作者：一只叫煤球的猫
来源：juejin.cn/post/7261835383201726523

收起阅读 »

我写了一个程序，让端口占用无路可逃

Java

作为一个 Java 工程师，经常会遇到这么个场景：IDEA 里的程序正在运行，此时直接关闭了 IDEA 而没有先关闭正在运行的服务。在绝大多数情境下，此方式都无伤大雅，但总有一些抽风的场景运行的程序并没有被正常的关闭，也就导致了重启项目时将会提示 xxxx ...

继续阅读 »

作为一个 Java 工程师，经常会遇到这么个场景：IDEA 里的程序正在运行，此时直接关闭了 IDEA 而没有先关闭正在运行的服务。

在绝大多数情境下，此方式都无伤大雅，但总有一些抽风的场景运行的程序并没有被正常的关闭，也就导致了重启项目时将会提示 xxxx 端口已被占用。

在 Windows 下此方式解决也十分简单，在命令行输入下述两个命令即可根据端口关闭对应的进程。

# 端口占用进程

netstat -ano | findstr <port>



# 进程关闭

taskkill -PID <pid> -F

虽然说也不麻烦但却很繁杂，试想一下当遇到这种情况下，我需要先翻笔记找出这两个命令，在打开命令行窗口执行，一套连招下来相当影响编程情绪。

因此，我决定写一个程序能够便捷的实现这个操作，最好是带 GUI 页面。

说干就干，整个程序功能其实并不复杂，对于页面的展示要求也不高，我就确定下来了直接通过 Java Swing 实现 GUI 部分。而对于命令执行部分，在 Java 中提供了 Process 类可用于执行命令。

先让我们看下 Process 的作用方式，以最简单的 ping baidu.com 测试为例。

public void demo() {  

    ProcessBuilder processBuilder = new ProcessBuilder();  

    List<String> command = new ArrayList<>();  

    command.add("ping");  

    command.add("www.baidu.com");  

    processBuilder.command(command);  

    

    try {  

        Process process = processBuilder.start();  

        try (  

            InputStreamReader ir = new InputStreamReader(process.getInputStream(), "GBK");  

            BufferedReader br = new BufferedReader(ir)  

        ) {  

            String line;  

            while ((line = br.readLine()) != null) {  

                System.out.println(line);  

            }  

        }  

    } catch (IOException e) {  

        e.printStackTrace();  

    }  

}

运行上述的代码，在控制台可以得到下图结果：

在上述程序中，ProcessBuilder 用于构建命令，processBuilder.start() 则相当于你敲下回车执行，而执行的结果的则以 IO 流的形式返回，这里通过 readLine() 将返回的结果逐行的形式进行读取。

了解的大概原理之后，剩下的事情就简单了，只需要将之前提到的两个命令以同样的方式通过 Process 执行就可以，再通过 Java Swing 进行一个页面展示就可以。

具体的实现并不复杂，这里就不详细展开介绍，完整的项目代码已经上传到 GitHub，感兴趣的小伙伴可自行前往查看，仓库地址：windows-process。

下面主要介绍程序的使用与效果，开始前可以去上述提到的仓库 relase 里将打包完成的 exe 程序下载，下载地址。

下载后启动 window process.exe 程序，在启动之后会先弹出下图的提示，这是因为使用了 exe4j 打包程序，选择确认即可。

选择确认之后即会展示下图页面，列表中展示的数据即 netstat -ano 命令返回的结果，

在选中列表任意一条进程记录后，会将该进程对应的端口号和 PID 填充至上面的输入框中。

同时，可在 Port 输入框中输入对应的端口号实现快速查询，若需要停止某个进程，则将点击对应端口进程记录其 PID 会自动填入输入框中，然后单击 Kill 按钮，成功停止进程后将会进行相应的提示。

最后的最后，再臭不要脸的给自己要个赞，觉得不错的可以去 GitHub 仓库上下载下来看看，如果能点个 star 更是万分感谢，这里再贴一下仓库地址：windows-process。

作者：烽火戏诸诸诸侯
来源：juejin.cn/post/7385499574881026089

收起阅读 »

null 不好，我真的推荐你使用 Optional

Java

"Null 很糟糕." - Doug Lea。 Doug Lea 是一位美国的计算机科学家，他是 Java 平台的并发和集合框架的主要设计者之一。他在 2014 年的一篇文章中说过：“Null sucks.”1，意思是 null 很糟糕。他认为 null 是...

继续阅读 »

"Null 很糟糕." - Doug Lea。

Doug Lea 是一位美国的计算机科学家，他是 Java 平台的并发和集合框架的主要设计者之一。他在 2014 年的一篇文章中说过：“Null sucks.”1，意思是 null 很糟糕。他认为 null 是一种不明确的表示，它既可以表示一个值不存在，也可以表示一个值未知，也可以表示一个值无效。这样就会导致很多逻辑错误和空指针异常，给程序员带来很多麻烦。他建议使用 Optional 类来封装可能为空的值，从而提高代码的可读性和健壮性。

"发明 null 引用是我的十亿美元错误。" - Sir C. A. R. Hoare。

Sir C. A. R. Hoare 是一位英国的计算机科学家，他是快速排序算法、Hoare 逻辑和通信顺序进程等重要概念的发明者。他在 2009 年的一个软件会议上道歉说：“I call it my billion-dollar mistake. It was the invention of the null reference in 1965.”，意思是他把 null 引用称为他的十亿美元错误。他说他在 1965 年设计 ALGOL W 语言时，引入了 null 引用的概念，用来表示一个对象变量没有指向任何对象。他当时认为这是一个很简单和自然的想法，但后来发现这是一个非常糟糕的设计，因为它导致了无数的错误、漏洞和系统崩溃。他说他应该使用一个特殊的对象来表示空值，而不是使用 null。

自作者从事 Java 编程一来，就与 null 引用相伴，与 NullPointerException 相遇已经是家常便饭了。

null 引用是一种表示一个对象变量没有指向任何对象的方式，它是 Java 语言中的一个特殊值，也是导致空指针异常（NullPointerException）的主要原因。虽然 null 引用可以用来表示一个值不存在或未知，也可以用来节省内存空间。但是它也不符合面向对象的思想，因为它不是一个对象，不能调用任何方法或属性。

可以看到，null 引用并不好，我们应该尽量避免使用 null，那么我们该怎么避免 null 引用引起的逻辑错误和运行时异常嘞？

其实这个问题 Java 的设计者也知道，于是他们在 Java8 之后设计引入了 Optional 类解决这个问题，本文将给大家详细介绍下 Optional 类的设计目的以及使用方法。

Optional 类是什么？

Optional 类是 java 8 中引入的一个新的类，它的作用是封装一个可能为空的值，从而避免空指针异常（NullPointerException）。Optional 类可以看作是一个容器，它可以包含一个非空的值，也可以为空。Optional 类提供了一些方法，让我们可以更方便地处理可能为空的值，而不需要显式地进行空值检查或者使用 null。

推荐作者开源的 H5 商城项目waynboot-mall，这是一套全部开源的微商城项目，包含三个项目：运营后台、H5 商城前台和服务端接口。实现了商城所需的首页展示、商品分类、商品详情、商品 sku、分词搜索、购物车、结算下单、支付宝/微信支付、收单评论以及完善的后台管理等一系列功能。技术上基于最新得 Springboot3.0、jdk17，整合了 MySql、Redis、RabbitMQ、ElasticSearch 等常用中间件。分模块设计、简洁易维护，欢迎大家点个 star、关注我。

github 地址：github.com/wayn111/way…

Optional 类的设计

Optional 类的设计是基于函数式编程的思想，它借鉴了 Scala 和 Haskell 等语言中的 Option 类型。Optional 类实现了 java.util.function 包中的 Supplier、Consumer、Predicate、Function 等接口，这使得它可以和 lambda 表达式或者方法引用一起使用，形成更简洁和优雅的代码。

Optional 类被 final 修饰，因此它是一个不可变的类，它有两个静态方法用于创建 Optional 对象。

`Optional.empty()`

Optional.empty 表示一个空的 Optional 对象，它不包含任何值。

// 创建一个空的 Optional 对象

Optional empty = Optional.empty();

`Optional.of(T value)`

Optional.of 表示一个非空的 Optional 对象，它包含一个非空的值。

// 创建一个非空的 Optional 对象

Optional hello = Optional.of("Hello");

`Optional.ofNullable(T value)`

注意，如果我们使用 Optional.of 方法传入一个 null 值，会抛出 NullPointerException。如果我们不确定一个值是否为空，可以使用 Optional.ofNullable 方法，它会根据值是否为空，返回一个相应的 Optional 对象。例如：

// 创建一个可能为空的 Optional 对象

Optional name = Optional.ofNullable("Hello");

Optional 对象的使用方法

Optional 对象提供了一些方法，让我们可以更方便地处理可能为空的值，而不需要显式地进行空值检查或者使用 null。以下是一些常用的方法。

`isPresent()`

判断 Optional 对象是否包含一个非空的值，返回一个布尔值。

`get()`

如果 Optional 对象包含一个非空的值，返回该值，否则抛出 NoSuchElementException 异常。



// 使用 isPresent 和 get 方法

Optional name = Optional.ofNullable("tom");

if (name.isPresent()) {

    System.out.println("Hello, " + name.get());

} else {

    System.out.println("Name is not available");

}

// 输出：Hello tom

`ifPresent(Consumer action)`

如果 Optional 对象包含一个非空的值，执行给定的消费者操作，否则什么也不做。

// 使用 ifPresent(Consumer action)

Optional name = Optional.ofNullable("tom");

name.ifPresent(s -> {

    System.out.println("Hello, " + name.get());

});

// 输出：Hello tom

`orElse(T other)`

如果 Optional 对象包含一个非空的值，返回该值，否则返回给定的默认值。

// 使用 orElse(T other)

Optional name = Optional.ofNullable(null);

String greeting = "Hello, " + name.orElse("Guest");

System.out.println(greeting);

// 输出：Hello Guest

`orElseGet(Supplier supplier)`

如果 Optional 对象包含一个非空的值，返回该值，否则返回由给定的供应者操作生成的值。

// 使用 orElseGet(Supplier supplier)

Optional name = Optional.ofNullable(null);

String greeting = "Hello, " + name.orElseGet(() -> "Guset");

System.out.println(greeting);

// 输出：Hello Guset

`orElseThrow(Supplier exceptionSupplier)`

如果 Optional 对象包含一个非空的值，返回该值，否则抛出由给定的异常供应者操作生成的异常。

// 使用 orElseThrow(Supplier exceptionSupplier)

Optional name = Optional.ofNullable(null);

String greeting = "Hello, " + name.orElseThrow(() -> new NullPointerException("null"));

// 抛出 java.lang.NullPointerException: null 异常

`map(Function mapper)`

如果 Optional 对象包含一个非空的值，对该值应用给定的映射函数，返回一个包含映射结果的 Optional 对象，否则返回一个空的 Optional 对象。

// 使用 map(Function mapper)

Optional name = Optional.ofNullable("tom");

String greeting = "Hello, " + name.map(s -> s.toUpperCase()).get();

System.out.println(greeting);

// 输出：Hello TOM

`flatMap(Function> mapper)`

如果 Optional 对象包含一个非空的值，对该值进行 mapper 参数操作，返回新的 Optional 对象，否则返回一个空的 Optional 对象。

// 使用 flatMap(Function> mapper)

Optional name = Optional.ofNullable("tom");

String greeting = name.flatMap(s -> Optional.of("Hello " + s)).get();

System.out.println(greeting);

// 输出：Hello tom

`filter(Predicate predicate)`

如果 Optional 对象包含一个非空的值，并且该值满足给定的谓词条件，返回包含该值的 Optional 对象，否则返回一个空的 Optional 对象。

// filter(Predicate predicate)

Optional name = Optional.ofNullable("tom");

String greeting = "Hello " + name.filter(s -> !s.isEmpty()).get();

System.out.println(greeting);

// 输出：Hello tom

Java 9 中 Optional 改进

Java 9 中 Optional 类有了一些改进，主要是增加了三个新的方法，分别是 stream()、ifPresentOrElse() 和 or()。这些方法可以让我们更方便地处理可能为空的值，以及和流或其他返回 Optional 的方法结合使用。我来详细讲解一下这些方法的作用和用法。

`stream()`

这个方法可以将一个 Optional 对象转换为一个 Stream 对象，如果 Optional 对象包含一个非空的值，那么返回的 Stream 对象就包含这个值，否则返回一个空的 Stream 对象。这样我们就可以利用 Stream 的各种操作来处理 Optional 的值，而不需要显式地判断是否为空。我们可以用 stream() 方法来过滤一个包含 Optional 的列表，只保留非空的值，如下所示：

List> list = Arrays.asList(

        Optional.empty(),

        Optional.of("A"),

        Optional.empty(),

        Optional.of("B")

);



// 使用 stream() 方法过滤列表，只保留非空的值

List filteredList = list.stream()

        .flatMap(Optional::stream)

        .collect(Collectors.toList());



System.out.println(filteredList);

// 输出 [A, B]

`ifPresentOrElse(Consumer action, Runnable emptyAction)`

这个方法可以让我们在 Optional 对象包含值或者为空时，执行不同的操作。它接受两个参数，一个是 Consumer 类型的 action，一个是 Runnable 类型的 emptyAction。如果 Optional 对象包含一个非空的值，那么就执行 action.accept(value)，如果 Optional 对象为空，那么就执行 emptyAction.run()。这样我们就可以避免使用 if-else 语句来判断 Optional 是否为空，而是使用函数式编程的方式来处理不同的情况。我们可以用 ifPresentOrElse() 方法来打印 Optional 的值，或者提示不可用，如下所示：

Optional optional = Optional.of(1);

optional.ifPresentOrElse(

    x -> System.out.println("Value: " + x),

    () -> System.out.println("Not Present.")

);



optional = Optional.empty();

optional.ifPresentOrElse(

    x -> System.out.println("Value: " + x),

    () -> System.out.println("Not Present.")

);



// 输出：Value: 1

// 输出：Not Present.

`or(Supplier> supplier)`

这个方法可以让我们在 Optional 对象为空时，返回一个预设的值。它接受一个 Supplier 类型的 supplier，如果 Optional 对象包含一个非空的值，那么就返回这个 Optional 对象本身，如果 Optional 对象为空，那么就返回 supplier.get() 返回的 Optional 对象。这样我们就可以避免使用三元运算符或者其他方式来设置默认值，而是使用函数式编程的方式来提供备选值。我们可以用 or() 方法来设置 Optional 的默认值，如下所示：

Optional optional = Optional.of("Hello ");

Supplier> supplier = () -> Optional.of("tom");

optional = optional.or(supplier);

optional.ifPresent(x -> System.out.println(x));



optional = Optional.empty();

optional = optional.or(supplier);

optional.ifPresent(x -> System.out.println(x));



// 输出：Hello 

// 输出：tom

为什么我推荐你使用 Optional 类

最后我总结一下使用 Optional 类的几个好处：

可以避免空指针异常，提高代码的健壮性和可读性。

可以减少显式的空值检查和 null 的使用，使代码更简洁和优雅。

可以利用函数式编程的特性，实现更灵活和高效的逻辑处理。

可以提高代码的可测试性，方便进行单元测试和集成测试。

总之，Optional 类是一个非常有用的类，它可以帮助我们更好地处理可能为空的值，提高代码的质量和效率。所以我强烈推荐你在 Java 开发中使用 Optional 类，你会发现它的魅力和好处。

作者：程序员wayn
来源：juejin.cn/post/7302322661957845028

收起阅读 »

搭建个人直播间，实现24小时B站、斗鱼、虎牙等无人直播！

综合技术讨论

不知道大家平时看不看直播呢？现在有各式各样的直播，游戏直播、户外直播、带货直播、经典电视/电影直播等等。电视、电影直播是24小时不间断无人直播，如斗鱼/虎牙中的一起看，这种直播要如何实现呢？其实非常简单，只需要一台服务器和视频资源就能完成。再借助于直播...

继续阅读 »

不知道大家平时看不看直播呢？现在有各式各样的直播，游戏直播、户外直播、带货直播、经典电视/电影直播等等。

电视、电影直播是24小时不间断无人直播，如斗鱼/虎牙中的一起看，这种直播要如何实现呢？

其实非常简单，只需要一台服务器和视频资源就能完成。

再借助于直播推流工具，如 KPlayer,将电视剧、电影等媒体资源推流到直播间，就能实现24小时无人直播了！

关注微信公众号：【Java陈序员】，获取开源项目分享、AI副业分享、超200本经典计算机电子书籍等。

KPlayer 简介

KPlayer —— ByteLang Studio 设计开发的一款用于在 Linux 环境下进行媒体资源推流的应用程序。

只需要简单的修改配置文件即可达到开箱即用的目的，不需要了解众多推流适配、视频编解码的细节即可方便的将媒体资源在主流直播平台上进行直播。意愿是提供一个简单易上手、扩展丰富、性能优秀适合长时间不间断推流的直播推流场景。

功能特色：

本地/网络视频资源的无缝推流，切换资源不导致断流

可自定义配置的编码参数，例如分辨率、帧率等

自定义多输出源，适合相同内容一次编码多路推流节省硬件资源

提供缓存机制避免相同内容二次编解码，大大降低在循环场景下对硬件资源的消耗

丰富的API接口在运行时对播放行为和资源动态控制

提供基础插件并具备自定义插件开发的能力

项目地址：https://github.com/bytelang/kplayer-go

在线文档：https://docs.kplayer.net/v0.5.8/

安装 KPlayer

KPlayer 支持一键安装、手动安装和 Docker 安装。

一键安装

通过 ssh 进入到你的服务器中，找到合适的目录并运行以下的命令进行下载：

curl -fsSL get.kplayer.net | bash

手动安装（可选）

1、下载压缩包

wget http://download.bytelang.cn/kplayer-v0.5.8-linux_amd64.tar.gz

2、解压压缩包

tar zxvf kplayer-v0.5.8-linux_amd64.tar.gz

安装完成

1、执行 cd kplayer 进入到 kplayer 目录，使用 ll 查看文件列表：

-rw-r--r-- 1 root root 285 3月  23 18:23 config.json.example

-rwxr-xr-x 1 root root 27M 7月  29 11:12 kplayer

config.json.example 是 KPlayer 最小化的配置信息示例

kplayer 是 KPlayer 服务启动、停止的执行脚本命令

2、使用 ./kplayer 命令查看当前版本

创建配置文件

1、使用 cp 命令重命名并复制一份 config.json.example

cp config.json.example config.json

2、修改配置文件

{

    "version": "2.0.0",

    "resource": {

        "lists": [

            "/video/example_1.mp4",

            "/video/example_2.mp4"

        ]

    },

    "output": {

        "lists": [

            {

                "path": "rtmp://127.0.0.1:1935/push"

            }

        ]

    }

}

resource.lists 视频资源文件路径

output.lists 直播推流地址，在B站、斗鱼、虎牙等直播平台中开启直播后，将会得到推流地址与推流码

开启直播

上传视频

上传视频资源到服务器，并修改 KPlayer 中的 resource.lists 视频路径

❗❗❗注意：直播的媒体文件必须得有平台版权，否则就会被投诉，封禁直播间❗

{

    "version": "2.0.0",

    "resource": {

        "lists": [

            "/data/software/movie/WechatMomentScreenshot.mp4",

            "/data/software/movie/IT Tools.mp4",

            "/data/software/movie/EasyCode.mp4",

            "/data/software/movie/TinyRDM.mp4",

            "/data/software/movie/Fooocus.mp4",

            "/data/software/movie/Stirling-PDF.mp4"

        ]

    },

    "output": {

        "lists": [

            {

                "path": "rtmp://127.0.0.1:1935/push"

            }

        ]

    }

  }

}

获取推流地址

以开启B站直播为例。

1、点击首页直播

2、点击网页右侧的开播设置

3、选择分类，点击开播

前提需要身-份-证和姓名实名认证

4、复制直播间地址

rtmp://live-push.bilivideo.com/live-bvc/?streamname=live_*********_********&key=**************&schedule=rtmp&pflag=1

5、将直播间地址配置到 KPlayer 配置文件中的 output.lists 直播推流地址

{

    "version": "2.0.0",

    "resource": {

        "lists": [

            "/data/software/movie/WechatMomentScreenshot.mp4",

            "/data/software/movie/IT Tools.mp4",

            "/data/software/movie/EasyCode.mp4",

            "/data/software/movie/TinyRDM.mp4",

            "/data/software/movie/Fooocus.mp4",

            "/data/software/movie/Stirling-PDF.mp4"

        ]

    },

    "output": {

        "lists": [

            {

                "path": "rtmp://live-push.bilivideo.com/live-bvc/?streamname=live_*********_********&key=**************&schedule=rtmp&pflag=1"

            }

        ]

    }

}

运行 `KPlayer`

执行以下命令启动 KPlayer

./kplayer play start

后台运行 KPlayer

./kplayer play start --daemon

测试访问

打开直播间地址，可以看到已经开始直播了。

斗鱼、虎牙等其他直播平台的直播配置也是类似的流程，只需要获取到平台的直播推流地址，并进行配置即可！可以同时配置多个平台同时进行直播！

配置循环播放

KPlayer 提供了很多的配置项，有资源配置、播放配置等。

如：可以配置循环播放视频，这样就可以保证24小时不间断的循环播放视频。

{

    "version": "2.0.0",

    "resource": {

        "lists": [

            "/data/software/movie/WechatMomentScreenshot.mp4",

            "/data/software/movie/IT Tools.mp4",

            "/data/software/movie/EasyCode.mp4",

            "/data/software/movie/TinyRDM.mp4",

            "/data/software/movie/Fooocus.mp4",

            "/data/software/movie/Stirling-PDF.mp4"

        ]

    },

    "output": {

        "lists": [

            {

                "path": "rtmp://live-push.bilivideo.com/live-bvc/?streamname=live_*********_********&key=**************&schedule=rtmp&pflag=1"

            }

        ]

    },

    ## 播放配置

    "play": {

        "fill_strategy": "ratio",

        ## 启用推流编码缓存，会生成缓存，命中缓存节约CPU资源

        "skip_invalid_resource": true,

        "cache_on": true,

         # 播放模式为按顺序且循环播放

        "play_model": "loop"

  }

}

更多的配置信息可参考 KPlayer 提供的文档。

Docker 安装 KPlayer

1、创建缓存目录 /data/software/docker/kplayer/cache

cd /data/software/docker/kplayer

mkdir cache

2、创建配置文件 /data/software/docker/kplayer/config.json

cd /data/software/docker/kplayer

touch config.json

填入配置信息：

{

    "version": "2.0.0",

    "resource": {

        "lists": [

            "/data/software/movie/WechatMomentScreenshot.mp4",

            "/data/software/movie/IT Tools.mp4",

            "/data/software/movie/EasyCode.mp4",

            "/data/software/movie/TinyRDM.mp4",

            "/data/software/movie/Fooocus.mp4",

            "/data/software/movie/Stirling-PDF.mp4"

        ]

    },

    "output": {

        "lists": [

            {

                "path": "rtmp://live-push.bilivideo.com/live-bvc/?streamname=live_*********_********&key=**************&schedule=rtmp&pflag=1"

            }

        ]

    },

    ## 播放配置

    "play": {

        "fill_strategy": "ratio",

        ## 启用推流编码缓存，会生成缓存，命中缓存节约CPU资源

        "skip_invalid_resource": true,

        "cache_on": true,

         # 播放模式为按顺序且循环播放

        "play_model": "loop"

  }

}

2、创建 docker-compose.yml

version: "3.3"

services:

  kplayer:

    container_name: kplayer

    volumes:

      - "/data/software/movie:/video"

      - "/data/software/docker/kplayer/config.json:/kplayer/config.json"

      - "/data/software/docker/kplayer/cache:/kplayer/cache"

    restart: always

    image: "bytelang/kplayer"

3、启动容器

docker-compose up -d

以上，就是利用服务器搭建个人直播间的全流程，整个步骤不是很复杂。

我们可以利用闲置的服务器，将自己收藏的电影、电视等资源进行全天候直播，每天还能获得一定的收益！

❗❗❗注意：直播的媒体文件必须得有平台版权，否则就会被投诉，封禁直播间❗

最后

推荐的开源项目已经收录到 GitHub 项目，欢迎 Star：

https://github.com/chenyl8848/great-open-source-project

或者访问网站，进行在线浏览：

https://chencoding.top:8090/#/

作者：Java陈序员
来源：juejin.cn/post/7385929329640226828

收起阅读 »

使用双异步后，从 191s 优化到 2s

Java

大家好，我是哪吒。在开发中，我们经常会遇到这样的需求，将Excel的数据导入数据库中。一、一般我会这样做：通过POI读取需要导入的Excel；以文件名为表名、列头为列名、并将数据拼接成sql；通过JDBC或mybatis插入数据库；操作起来，...

继续阅读 »

大家好，我是哪吒。

在开发中，我们经常会遇到这样的需求，将Excel的数据导入数据库中。

一、一般我会这样做：

通过POI读取需要导入的Excel；

以文件名为表名、列头为列名、并将数据拼接成sql；

通过JDBC或mybatis插入数据库；

操作起来，如果文件比较多，数据量都很大的时候，会非常慢。

访问之后，感觉没什么反应，实际上已经在读取 + 入库了，只是比较慢而已。

读取一个10万行的Excel，居然用了191s，我还以为它卡死了呢！

private void readXls(String filePath, String filename) throws Exception {

    @SuppressWarnings("resource")

    XSSFWorkbook xssfWorkbook = new XSSFWorkbook(new FileInputStream(filePath));

    // 读取第一个工作表

    XSSFSheet sheet = xssfWorkbook.getSheetAt(0);

    // 总行数

    int maxRow = sheet.getLastRowNum();



    StringBuilder insertBuilder = new StringBuilder();



    insertBuilder.append("insert int0 ").append(filename).append(" ( UUID,");



    XSSFRow row = sheet.getRow(0);

    for (int i = 0; i < row.getPhysicalNumberOfCells(); i++) {

        insertBuilder.append(row.getCell(i)).append(",");

    }



    insertBuilder.deleteCharAt(insertBuilder.length() - 1);

    insertBuilder.append(" ) values ( ");



    StringBuilder stringBuilder = new StringBuilder();

    for (int i = 1; i <= maxRow; i++) {

        XSSFRow xssfRow = sheet.getRow(i);

        String id = "";

        String name = "";

        for (int j = 0; j < row.getPhysicalNumberOfCells(); j++) {

            if (j == 0) {

                id = xssfRow.getCell(j) + "";

            } else if (j == 1) {

                name = xssfRow.getCell(j) + "";

            }

        }



        boolean flag = isExisted(id, name);

        if (!flag) {

            stringBuilder.append(insertBuilder);

            stringBuilder.append('\'').append(uuid()).append('\'').append(",");

            for (int j = 0; j < row.getPhysicalNumberOfCells(); j++) {

                stringBuilder.append('\'').append(value).append('\'').append(",");

            }

            stringBuilder.deleteCharAt(stringBuilder.length() - 1);

            stringBuilder.append(" )").append("\n");

        }

    }



    List collect = Arrays.stream(stringBuilder.toString().split("\n")).collect(Collectors.toList());

    int sum = JdbcUtil.executeDML(collect);

}



private static boolean isExisted(String id, String name) {

    String sql = "select count(1) as num from " + static_TABLE + " where ID = '" + id + "' and NAME = '" + name + "'";

    String num = JdbcUtil.executeSelect(sql, "num");

    return Integer.valueOf(num) > 0;

}



private static String uuid() {

    return UUID.randomUUID().toString().replace("-", "");

}

二、谁写的？拖出去，斩了！

优化1：先查询全部数据，缓存到map中，插入前再进行判断，速度快了很多。

优化2：如果单个Excel文件过大，可以采用异步 + 多线程读取若干行，分批入库。

优化3：如果文件数量过多，可以采一个Excel一个异步，形成完美的双异步读取插入。

使用双异步后，从 191s 优化到 2s，你敢信？

下面贴出异步读取Excel文件、并分批读取大Excel文件的关键代码。

1、readExcelCacheAsync控制类

@RequestMapping(value = "/readExcelCacheAsync", method = RequestMethod.POST)

@ResponseBody

public String readExcelCacheAsync() {

    String path = "G:\\测试\\data\\";

    try {

		// 在读取Excel之前，缓存所有数据

        USER_INFO_SET = getUserInfo();



        File file = new File(path);

        String[] xlsxArr = file.list();

        for (int i = 0; i < xlsxArr.length; i++) {

            File fileTemp = new File(path + "\\" + xlsxArr[i]);

            String filename = fileTemp.getName().replace(".xlsx", "");

            readExcelCacheAsyncService.readXls(path + filename + ".xlsx", filename);

        }

    } catch (Exception e) {

        logger.error("|#ReadDBCsv|#异常: ", e);

        return "error";

    }

    return "success";

}

2、分批读取超大Excel文件

@Async("async-executor")

public void readXls(String filePath, String filename) throws Exception {

    @SuppressWarnings("resource")

    XSSFWorkbook xssfWorkbook = new XSSFWorkbook(new FileInputStream(filePath));

    // 读取第一个工作表

    XSSFSheet sheet = xssfWorkbook.getSheetAt(0);

    // 总行数

    int maxRow = sheet.getLastRowNum();

    logger.info(filename + ".xlsx，一共" + maxRow + "行数据！");

    StringBuilder insertBuilder = new StringBuilder();



    insertBuilder.append("insert int0 ").append(filename).append(" ( UUID,");



    XSSFRow row = sheet.getRow(0);

    for (int i = 0; i < row.getPhysicalNumberOfCells(); i++) {

        insertBuilder.append(row.getCell(i)).append(",");

    }



    insertBuilder.deleteCharAt(insertBuilder.length() - 1);

    insertBuilder.append(" ) values ( ");



    int times = maxRow / STEP + 1;

    //logger.info("将" + maxRow + "行数据分" + times + "次插入数据库！");

    for (int time = 0; time < times; time++) {

        int start = STEP * time + 1;

        int end = STEP * time + STEP;



        if (time == times - 1) {

            end = maxRow;

        }



        if(end + 1 - start > 0){

            //logger.info("第" + (time + 1) + "次插入数据库！" + "准备插入" + (end + 1 - start) + "条数据！");

            //readExcelDataAsyncService.readXlsCacheAsync(sheet, row, start, end, insertBuilder);

            readExcelDataAsyncService.readXlsCacheAsyncMybatis(sheet, row, start, end, insertBuilder);

        }

    }

}

3、异步批量入库

@Async("async-executor")

public void readXlsCacheAsync(XSSFSheet sheet, XSSFRow row, int start, int end, StringBuilder insertBuilder) {

    StringBuilder stringBuilder = new StringBuilder();

    for (int i = start; i <= end; i++) {

        XSSFRow xssfRow = sheet.getRow(i);

        String id = "";

        String name = "";

        for (int j = 0; j < row.getPhysicalNumberOfCells(); j++) {

            if (j == 0) {

                id = xssfRow.getCell(j) + "";

            } else if (j == 1) {

                name = xssfRow.getCell(j) + "";

            }

        }



		// 先在读取Excel之前，缓存所有数据，再做判断

        boolean flag = isExisted(id, name);

        if (!flag) {

            stringBuilder.append(insertBuilder);

            stringBuilder.append('\'').append(uuid()).append('\'').append(",");

            for (int j = 0; j < row.getPhysicalNumberOfCells(); j++) {

                stringBuilder.append('\'').append(value).append('\'').append(",");

            }

            stringBuilder.deleteCharAt(stringBuilder.length() - 1);

            stringBuilder.append(" )").append("\n");

        }

    }



    List collect = Arrays.stream(stringBuilder.toString().split("\n")).collect(Collectors.toList());

    if (collect != null && collect.size() > 0) {

        int sum = JdbcUtil.executeDML(collect);

    }

}



private boolean isExisted(String id, String name) {

    return ReadExcelCacheAsyncController.USER_INFO_SET.contains(id + "," + name);

}

4、异步线程池工具类

@Async的作用就是异步处理任务。

在方法上添加@Async，表示此方法是异步方法；

在类上添加@Async，表示类中的所有方法都是异步方法；

使用此注解的类，必须是Spring管理的类；

需要在启动类或配置类中加入@EnableAsync注解，@Async才会生效；

在使用@Async时，如果不指定线程池的名称，也就是不自定义线程池，@Async是有默认线程池的，使用的是Spring默认的线程池SimpleAsyncTaskExecutor。

默认线程池的默认配置如下：

默认核心线程数：8；

最大线程数：Integet.MAX_VALUE；

队列使用LinkedBlockingQueue；

容量是：Integet.MAX_VALUE；

空闲线程保留时间：60s；

线程池拒绝策略：AbortPolicy；

从最大线程数可以看出，在并发情况下，会无限制的创建线程，我勒个吗啊。

也可以通过yml重新配置：

spring:

  task:

    execution:

      pool:

        max-size: 10

        core-size: 5

        keep-alive: 3s

        queue-capacity: 1000

        thread-name-prefix: my-executor

也可以自定义线程池，下面通过简单的代码来实现以下@Async自定义线程池。

@EnableAsync// 支持异步操作

@Configuration

public class AsyncTaskConfig {



    /**

     * com.google.guava中的线程池

     * @return

     */

    @Bean("my-executor")

    public Executor firstExecutor() {

        ThreadFactory threadFactory = new ThreadFactoryBuilder().setNameFormat("my-executor").build();

        // 获取CPU的处理器数量

        int curSystemThreads = Runtime.getRuntime().availableProcessors() * 2;

        ThreadPoolExecutor threadPool = new ThreadPoolExecutor(curSystemThreads, 100,

                200, TimeUnit.SECONDS,

                new LinkedBlockingQueue<>(), threadFactory);

        threadPool.allowsCoreThreadTimeOut();

        return threadPool;

    }



    /**

     * Spring线程池

     * @return

     */

    @Bean("async-executor")

    public Executor asyncExecutor() {

        ThreadPoolTaskExecutor taskExecutor = new ThreadPoolTaskExecutor();

        // 核心线程数

        taskExecutor.setCorePoolSize(24);

        // 线程池维护线程的最大数量，只有在缓冲队列满了之后才会申请超过核心线程数的线程

        taskExecutor.setMaxPoolSize(200);

        // 缓存队列

        taskExecutor.setQueueCapacity(50);

        // 空闲时间，当超过了核心线程数之外的线程在空闲时间到达之后会被销毁

        taskExecutor.setKeepAliveSeconds(200);

        // 异步方法内部线程名称

        taskExecutor.setThreadNamePrefix("");



        /**

         * 当线程池的任务缓存队列已满并且线程池中的线程数目达到maximumPoolSize，如果还有任务到来就会采取任务拒绝策略

         * 通常有以下四种策略：

         * ThreadPoolExecutor.AbortPolicy:丢弃任务并抛出RejectedExecutionException异常。

         * ThreadPoolExecutor.DiscardPolicy：也是丢弃任务，但是不抛出异常。

         * ThreadPoolExecutor.DiscardOldestPolicy：丢弃队列最前面的任务，然后重新尝试执行任务（重复此过程）

         * ThreadPoolExecutor.CallerRunsPolicy：重试添加当前的任务，自动重复调用 execute() 方法，直到成功

         */

        taskExecutor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());

        taskExecutor.initialize();

        return taskExecutor;

    }

}

5、异步失效的原因

注解@Async的方法不是public方法；

注解@Async的返回值只能为void或Future；

注解@Async方法使用static修饰也会失效；

没加@EnableAsync注解；

调用方和@Async不能在一个类中；

在Async方法上标注@Transactional是没用的，但在Async方法调用的方法上标注@Transcational是有效的；

三、线程池中的核心线程数设置问题

有一个问题，一直没时间摸索，线程池中的核心线程数CorePoolSize、最大线程数MaxPoolSize，设置成多少，最合适，效率最高。

借着这个机会，测试一下。

1、我记得有这样一个说法，CPU的处理器数量

将核心线程数CorePoolSize设置成CPU的处理器数量，是不是效率最高的？

// 获取CPU的处理器数量

int curSystemThreads = Runtime.getRuntime().availableProcessors() * 2;

Runtime.getRuntime().availableProcessors()获取的是CPU核心线程数，也就是计算资源。

CPU密集型，线程池大小设置为N，也就是和cpu的线程数相同，可以尽可能地避免线程间上下文切换，但在实际开发中，一般会设置为N+1，为了防止意外情况出现线程阻塞，如果出现阻塞，多出来的线程会继续执行任务，保证CPU的利用效率。

IO密集型，线程池大小设置为2N，这个数是根据业务压测出来的，如果不涉及业务就使用推荐。

在实际中，需要对具体的线程池大小进行调整，可以通过压测及机器设备现状，进行调整大小。

如果线程池太大，则会造成CPU不断的切换，对整个系统性能也不会有太大的提升，反而会导致系统缓慢。

我的电脑的CPU的处理器数量是24。

那么一次读取多少行最合适呢？

测试的Excel中含有10万条数据，10万/24 = 4166，那么我设置成4200，是不是效率最佳呢？

测试的过程中发现，好像真的是这样的。

2、我记得大家都习惯性的将核心线程数CorePoolSize和最大线程数MaxPoolSize设置成一样的，都爱设置成200。

是随便写的，还是经验而为之？

测试发现，当你将核心线程数CorePoolSize和最大线程数MaxPoolSize都设置为200的时候，第一次它会同时开启150个线程，来进行工作。

这个是为什么？

3、经过数十次的测试

发现核心线程数好像差别不大

每次读取和入库的数量是关键，不能太多，因为每次入库会变慢；

也不能太少，如果太少，超过了150个线程，就会造成线程阻塞，也会变慢；

四、通过EasyExcel读取并插入数据库

EasyExcel的方式，我就不写双异步优化了，大家切记陷入低水平勤奋的怪圈。

1、ReadEasyExcelController

@RequestMapping(value = "/readEasyExcel", method = RequestMethod.POST)

@ResponseBody

public String readEasyExcel() {

    try {

        String path = "G:\\测试\\data\\";

        String[] xlsxArr = new File(path).list();

        for (int i = 0; i < xlsxArr.length; i++) {

            String filePath = path + xlsxArr[i];

            File fileTemp = new File(path + xlsxArr[i]);

            String fileName = fileTemp.getName().replace(".xlsx", "");

            List list = new ArrayList<>();

            EasyExcel.read(filePath, UserInfo.class, new ReadEasyExeclAsyncListener(readEasyExeclService, fileName, batchCount, list)).sheet().doRead();

        }

    }catch (Exception e){

        logger.error("readEasyExcel 异常：",e);

        return "error";

    }

    return "suceess";

}

2、ReadEasyExeclAsyncListener

public ReadEasyExeclService readEasyExeclService;

	// 表名

    public String TABLE_NAME;

    // 批量插入阈值

    private int BATCH_COUNT;

    // 数据集合

    private List LIST;



    public ReadEasyExeclAsyncListener(ReadEasyExeclService readEasyExeclService, String tableName, int batchCount, List list) {

        this.readEasyExeclService = readEasyExeclService;

        this.TABLE_NAME = tableName;

        this.BATCH_COUNT = batchCount;

        this.LIST = list;

    }



    @Override

    public void invoke(UserInfo data, AnalysisContext analysisContext) {

        data.setUuid(uuid());

        data.setTableName(TABLE_NAME);

        LIST.add(data);

        if(LIST.size() >= BATCH_COUNT){

            // 批量入库

            readEasyExeclService.saveDataBatch(LIST);

        }

    }



    @Override

    public void doAfterAllAnalysed(AnalysisContext analysisContext) {

        if(LIST.size() > 0){

        	// 最后一批入库

            readEasyExeclService.saveDataBatch(LIST);

        }

    }



    public static String uuid() {

        return UUID.randomUUID().toString().replace("-", "");

    }

}

3、ReadEasyExeclServiceImpl

@Service

public class ReadEasyExeclServiceImpl implements ReadEasyExeclService {



    @Resource

    private ReadEasyExeclMapper readEasyExeclMapper;



    @Override

    public void saveDataBatch(List list) {

    	// 通过mybatis入库

        readEasyExeclMapper.saveDataBatch(list);

        // 通过JDBC入库

        // insertByJdbc(list);

        list.clear();

    }

    

    private void insertByJdbc(List list){

        List sqlList = new ArrayList<>();

        for (UserInfo u : list){

            StringBuilder sqlBuilder = new StringBuilder();

            sqlBuilder.append("insert int0 ").append(u.getTableName()).append(" ( UUID,ID,NAME,AGE,ADDRESS,PHONE,OP_TIME ) values ( ");

            sqlBuilder.append("'").append(ReadEasyExeclAsyncListener.uuid()).append("',")

                            .append("'").append(u.getId()).append("',")

                            .append("'").append(u.getName()).append("',")

                            .append("'").append(u.getAge()).append("',")

                            .append("'").append(u.getAddress()).append("',")

                            .append("'").append(u.getPhone()).append("',")

                            .append("sysdate )");

            sqlList.add(sqlBuilder.toString());

        }



        JdbcUtil.executeDML(sqlList);

    }

}

4、UserInfo

@Data

public class UserInfo {



    private String tableName;



    private String uuid;



    @ExcelProperty(value = "ID")

    private String id;



    @ExcelProperty(value = "NAME")

    private String name;



    @ExcelProperty(value = "AGE")

    private String age;



    @ExcelProperty(value = "ADDRESS")

    private String address;



    @ExcelProperty(value = "PHONE")

    private String phone;

}

作者：哪吒编程
来源：juejin.cn/post/7315730050577694720

收起阅读 »

SpringBoot统一结果返回，统一异常处理，大牛都这么玩

Java

引言在开发Spring Boot应用时，我们经常面临着不同的控制器方法需要处理各种不同类型的响应结果，以及在代码中分散处理异常可能导致项目难以维护的问题。你是否曾经遇到过在不同地方编写相似的返回格式，或者在处理异常时感到有些混乱？这些看似小问题的积累，实际上...

继续阅读 »

引言

在开发Spring Boot应用时，我们经常面临着不同的控制器方法需要处理各种不同类型的响应结果，以及在代码中分散处理异常可能导致项目难以维护的问题。你是否曾经遇到过在不同地方编写相似的返回格式，或者在处理异常时感到有些混乱？这些看似小问题的积累，实际上可能对项目产生深远的影响。统一结果返回和统一异常处理并非只是为了规范代码，更是为了提高团队的协作效率、降低项目维护的难度，并使代码更易于理解和扩展。

本文的目的是帮助你更好地理解和应用Spring Boot中的统一结果返回和统一异常处理。通过详细的讨论和实例演示，我们将为你提供一套清晰的指南，让你能够在自己的项目中轻松应用这些技术，提高代码质量，减轻开发压力。

统一结果返回

统一结果返回是一种通过定义通用的返回格式，使所有的响应结果都符合同一标准的方法。这有助于提高代码的一致性，减少重复代码的编写，以及使客户端更容易理解和处理API的响应。统一结果返回不仅规范了代码结构，还能提高团队协作效率，降低项目维护的难度。

接下来让我们一起看看在SpringBoot中如何实现统一结果返回。

1. 定义通用的响应对象

当实现统一结果返回时，需要创建一个通用的响应对象，定义成功和失败的返回情况，并确保在接口中使用这个通用返回对象。

@Setter  

@Getter  

public class ResultResponse<T> implements Serializable {  

    private static final long serialVersionUID = -1133637474601003587L;  



    /**  

     * 接口响应状态码  

     */  

    private Integer code;  



    /**  

     * 接口响应信息  

     */  

    private String msg;  



    /**  

     * 接口响应的数据  

     */  

    private T data;

}

2. 定义接口响应状态码

统一结果返回的关键之一是规定一套通用的状态码。这有助于客户端更容易地理解和处理 API 的响应，同时也为开发者提供了一致的标准。通常，一些 HTTP 状态码已经被广泛接受，如：

200 OK：表示成功处理请求。

201 Created：表示成功创建资源。

204 No Content：表示成功处理请求，但没有返回任何内容。

对于错误情况，也可以使用常见的 HTTP 状态码，如：

400 Bad Request：客户端请求错误。

401 Unauthorized：未授权访问。

404 Not Found：请求资源不存在。

500 Internal Server Error：服务器内部错误。

除了 HTTP 状态码外，你还可以定义自己的应用程序特定状态码，以表示更具体的情况。确保文档中清晰地说明了每个状态码所代表的含义，使开发者能够正确地解释和处理它们。

public enum StatusEnum {  

    SUCCESS(200 ,"请求处理成功"),  

    UNAUTHORIZED(401 ,"用户认证失败"),  

    FORBIDDEN(403 ,"权限不足"),  

    SERVICE_ERROR(500, "服务器去旅行了，请稍后重试"),  

    PARAM_INVALID(1000, "无效的参数"),  

    ;  

    public final Integer code;  



    public final String message;  



    StatusEnum(Integer code, String message) {  

        this.code = code;  

        this.message = message;  

    }  



}

3. 定义统一的成功和失败的处理方法

定义统一的成功和失败的响应方法有助于保持代码一致性和规范性，简化控制器逻辑，提高代码复用性，降低维护成本，提高可读性，促进团队协作，以及更便于进行测试。

/**  

 * 封装成功响应的方法  

 * @param data 响应数据  

 * @return reponse  

 * @param <T> 响应数据类型  

 */  

public static <T> ResultResponse<T> success(T data) {  



    ResultResponse<T> response = new ResultResponse<>();  

    response.setData(data);  

    response.setCode(StatusEnum.SUCCESS.code);  

    return response;  

}  



/**  

 * 封装error的响应  

 * @param statusEnum error响应的状态值  

 * @return  

 * @param <T>  

 */  

public static <T> ResultResponse<T> error(StatusEnum statusEnum) {  

   return error(statusEnum, statusEnum.message);  

}  



/**  

 * 封装error的响应  可自定义错误信息

 * @param statusEnum error响应的状态值  

 * @return  

 * @param <T>  

 */  

public static <T> ResultResponse<T> error(StatusEnum statusEnum, String errorMsg) {  

    ResultResponse<T> response = new ResultResponse<>();  

    response.setCode(statusEnum.code);  

    response.setMsg(errorMsg);  

    return response;  

}

4. web层统一响应结果

在web层使用统一结果返回的目的是将业务逻辑的处理结果按照预定的通用格式进行封装，以提高代码的一致性和可读性。

@RestController  

@RequestMapping("user")  

@Validated  

@Slf4j  

public class UserController {  



    private IUserService userService;  



    /**  

     * 创建用户  

     * @param requestVO  

     * @return  

     */  

    @PostMapping("create")  

    public ResultResponse<Void> createUser(@Validated @RequestBody UserCreateRequestVO requestVO){  

        return ResultResponse.success(null);  

    }



    /**  

     * 根据用户ID获取用户信息  

     * @param userId 用户id  

     * @return 用户信息  

     */  

    @GetMapping("info")  

    public ResultResponse<UserInfoResponseVO> getUser(@NotBlank(message = "请选择用户") String userId){  

        final UserInfoResponseVO responseVO = userService.getUserInfoById(userId);  

        return ResultResponse.success(responseVO);  

    }  



    @Autowired  

    public void setUserService(IUserService userService) {  

        this.userService = userService;  

    }  

}

调用接口，响应的信息统一为：

{

    "code": 200,

    "msg": null,

    "data": null

}

{

    "code": 200,

    "msg": null,

    "data": {

        "userId": "121",

        "userName": "码农Academy"

    }

}

统一结果返回通过定义通用的返回格式、成功和失败的返回情况，以及在控制器中使用这一模式，旨在提高代码的一致性、可读性和可维护性。采用统一的响应格式简化了业务逻辑处理流程，使得开发者更容易处理成功和失败的情况，同时客户端也更容易理解和处理 API 的响应。这一实践有助于降低维护成本、提高团队协作效率，并促进代码的规范化。

统一异常处理

统一异常处理的必要性体现在保持代码的一致性、提供更清晰的错误信息、以及更容易排查问题。通过定义统一的异常处理方式，确保在整个应用中对异常的处理保持一致，减少了重复编写相似异常处理逻辑的工作，同时提供友好的错误信息帮助开发者和维护人员更快地定位和解决问题，最终提高了应用的可维护性和可读性。

1.定义统一的异常类

我们需要定义服务中可能抛出的自定义异常类。这些异常类可以继承自RuntimeException，并携带有关异常的相关信息。即可理解为局部异常，用于特定的业务处理中异常。手动埋点抛出。

@Getter  

public class ServiceException extends RuntimeException{  



    private static final long serialVersionUID = -3303518302920463234L;  



    private final StatusEnum status;  



    public ServiceException(StatusEnum status, String message) {  

        super(message);  

        this.status = status;  

    }  



    public ServiceException(StatusEnum status) {  

        this(status, status.message);  

    }  

}

2.异常处理器

创建一个全局的异常处理器，使用@ControllerAdvice 或者 @RestControllerAdvice注解和@ExceptionHandler注解来捕获不同类型的异常，并定义处理逻辑。

2.1 @ControllerAdvice注解

用于声明一个全局控制器建言（Advice），相当于把@ExceptionHandler、@InitBinder和@ModelAttribute注解的方法集中到一个地方。常放在一个特定的类上，这个类被认为是全局异常处理器，可以跨足多个控制器。

当时用@ControllerAdvice时，我们需要在异常处理方法上加上@ResponseBody，同理我们的web接口。但是如果我们使用@RestControllerAdvice 就可以不用加，同理也是web定义的接口

2.2 `@ExceptionHandler`注解

用于定义异常处理方法，处理特定类型的异常。放在全局异常处理器类中的具体方法上。

通过这两个注解的配合，可以实现全局的异常处理。当控制器中抛出异常时，Spring Boot会自动调用匹配的@ExceptionHandler方法来处理异常，并返回定义的响应。

@Slf4j  

@ControllerAdvice  

public class ExceptionAdvice {  



    /**  

     * 处理ServiceException  

     * @param serviceException ServiceException  

     * @param request 请求参数  

     * @return 接口响应  

     */  

    @ExceptionHandler(ServiceException.class)  

    @ResponseBody  

    public ResultResponse<Void> handleServiceException(ServiceException serviceException, HttpServletRequest request) {  

        log.warn("request {} throw ServiceException \n", request, serviceException);  

        return ResultResponse.error(serviceException.getStatus(), serviceException.getMessage());  

    }  



    /**  

     * 其他异常拦截  

     * @param ex 异常  

     * @param request 请求参数  

     * @return 接口响应  

     */  

    @ExceptionHandler(Exception.class)  

    @ResponseBody  

    public ResultResponse<Void> handleException(Exception ex, HttpServletRequest request) {  

        log.error("request {} throw unExpectException \n", request, ex);  

        return ResultResponse.error(StatusEnum.SERVICE_ERROR);  

    }

}

3.异常统一处理使用

在业务开发过程中，我们可以在service层处理业务时，可以手动抛出业务异常。由全局异常处理器进行统一处理。

@Service  

@Slf4j  

public class UserServiceImpl implements IUserService {  



    private IUserManager userManager;



    /**  

     * 创建用户  

     *  

     * @param requestVO 请求参数  

     */  

    @Override  

    public void createUser(UserCreateRequestVO requestVO) {  

        final UserDO userDO = userManager.selectUserByName(requestVO.getUserName());  

        if (userDO != null){  

            throw new ServiceException(StatusEnum.PARAM_INVALID, "用户名已存在");  

        }  

    }



    @Autowired  

    public void setUserManager(IUserManager userManager) {  

        this.userManager = userManager;  

    }  

}

@RestController  

@RequestMapping("user")  

@Validated  

@Slf4j  

public class UserController {  



    private IUserService userService;  



    /**  

     * 创建用户  

     * @param requestVO  

     * @return  

     */  

    @PostMapping("create")  

    public ResultResponse<Void> createUser(@Validated @RequestBody UserCreateRequestVO requestVO){  

        userService.createUser(requestVO);  

        return ResultResponse.success(null);  

    }



    @Autowired  

    public void setUserService(IUserService userService) {  

        this.userService = userService;  

    }  

}

当我们请求接口时，假如用户名称已存在，接口就会响应：

{

    "code": 1000,

    "msg": "用户名已存在",

    "data": null

}

统一异常处理带来的好处包括提供一致的异常响应格式，简化异常处理逻辑，记录更好的错误日志，以及更容易排查和解决问题。通过统一处理异常，我们确保在整个应用中对异常的处理方式一致，减少了重复性代码的编写，提高了代码的规范性。简化的异常处理逻辑降低了开发者的工作负担，而更好的错误日志有助于更迅速地定位和解决问题，最终提高了应用的可维护性和稳定性。

其他类型的异常处理

在项目开发过程中，我们还有一些常见的特定异常类型，比如MethodArgumentNotValidException和UnexpectedTypeException等，并为它们定义相应的异常处理逻辑。这些特定异常可能由于请求参数校验失败或意外的数据类型问题而引起，因此有必要为它们单独处理，以提供更具体和友好的异常响应。

1.MethodArgumentNotValidException

由于请求参数校验失败引起的异常，通常涉及到使用@Valid注解或者@Validated进行请求参数校验。我们可以在异常处理器中编写@ExceptionHandler方法，捕获并处理MethodArgumentNotValidException，提取校验错误信息，并返回详细的错误响应。

/**  

 * 参数非法校验  

 * @param ex  

 * @return  

 */  

@ExceptionHandler(MethodArgumentNotValidException.class)  

@ResponseBody  

public ResultResponse<Void> handleMethodArgumentNotValidException(MethodArgumentNotValidException ex) {  

    try {  

        List<ObjectError> errors = ex.getBindingResult().getAllErrors();  

        String message = errors.stream().map(ObjectError::getDefaultMessage).collect(Collectors.joining(","));  

        log.error("param illegal: {}", message);  

        return ResultResponse.error(StatusEnum.PARAM_INVALID, message);  

    } catch (Exception e) {  

        return ResultResponse.error(StatusEnum.SERVICE_ERROR);  

    }  

}

当我们使用@Valid注解或者@Validated进行请求参数校验不通过时，响应结果为：

{

    "code": 1000,

    "msg": "请输入地址信息,用户年龄必须小于60岁,请输入你的兴趣爱好",

    "data": null

}

关于@Valid注解或者@Validated进行参数校验的功能请参考：SpringBoot优雅校验参数

2.UnexpectedTypeException

意外的数据类型异常，通常表示程序运行时发生了不符合预期的数据类型问题。一个常见的使用场景是在数据转换或类型处理的过程中。例如，在使用 Spring 表单绑定或数据绑定时，如果尝试将一个不符合预期类型的值转换为目标类型，就可能抛出 UnexpectedTypeException。这通常会发生在将字符串转换为数字、日期等类型时，如果字符串的格式不符合目标类型的要求。

我们可以在异常处理器中编写@ExceptionHandler方法，捕获并处理UnexpectedTypeException，提供适当的处理方式，例如记录错误日志，并返回合适的错误响应。

@ExceptionHandler(UnexpectedTypeException.class)  

@ResponseBody  

public ResultResponse<Void> handleUnexpectedTypeException(UnexpectedTypeException ex,  

                                                        HttpServletRequest request) {  

    log.error("catch UnexpectedTypeException, errorMessage: \n", ex);  

    return ResultResponse.error(StatusEnum.PARAM_INVALID, ex.getMessage());  

}

当发生异常时，接口会响应：

{

    "code": 500,

    "msg": "服务器去旅行了，请稍后重试",

    "data": null

}

3.ConstraintViolationException

javax.validation.ConstraintViolationException 是 Java Bean Validation（JSR 380）中的一种异常。它通常在使用 Bean Validation 进行数据校验时，如果校验失败就会抛出这个异常。即我们在使用自定义校验注解时，如果不满足校验规则，就会抛出这个错误。

@ExceptionHandler(ConstraintViolationException.class)  

@ResponseBody  

public ResultResponse<Void> handlerConstraintViolationException(ConstraintViolationException ex, HttpServletRequest request) {  

    log.error("request {} throw ConstraintViolationException \n", request, ex);  

    return ResultResponse.error(StatusEnum.PARAM_INVALID, ex.getMessage());  

}

案例请参考：SpringBoot优雅校验参数，注册ConstraintValidator示例中的@UniqueUser校验。

4.HttpMessageNotReadableException

表示无法读取HTTP消息的异常，通常由于请求体不合法或不可解析。

@ResponseBody  

@ResponseStatus(HttpStatus.BAD_REQUEST)  

@ExceptionHandler(HttpMessageNotReadableException.class)  

public ResultResponse<Void> handleHttpMessageNotReadableException(HttpMessageNotReadableException ex,  

HttpServletRequest request) {  

    log.error("request {} throw ucManagerException \n", request, ex);  

    return ResultResponse.error(StatusEnum.SERVICE_ERROR);  

}

5.HttpRequestMethodNotSupportedException

Spring Framework 中的异常类，表示请求的 HTTP 方法不受支持。当客户端发送了一个使用不被服务器支持的 HTTP 方法（如 GET、POST、PUT、DELETE等）的请求时，可能会抛出这个异常。

@ExceptionHandler({HttpRequestMethodNotSupportedException.class, HttpMediaTypeException.class})  

@ResponseBody  

public ResultResponse<Void> handleMethodNotSupportedException(Exception ex) {  

    log.error("HttpRequestMethodNotSupportedException \n", ex);  

    return ResultResponse.error(StatusEnum.HTTP_METHOD_NOT_SUPPORT);  

}

全局异常处理与局部异常处理在Spring Boot应用开发中扮演不同角色。全局异常处理通过统一的异常处理器确保了整个应用对异常的处理一致性，减少了冗余代码，提高了代码的整洁度。然而，这种方式可能在灵活性上略显不足，无法满足每个具体控制器或业务场景的个性化需求。

相比之下，局部异常处理能够为每个控制器或业务场景提供更具体、灵活的异常处理逻辑，允许定制化的异常响应。这使得在复杂的项目中更容易处理特定的异常情况，同时提供更详细的错误信息。然而，局部异常处理可能带来代码冗余和维护难度的问题，特别是在大型项目中。

在实际应用中，选择全局异常处理还是局部异常处理应根据项目规模和需求进行权衡。对于小型项目或简单场景，全局异常处理可能是一种更简单、合适的选择。而对于大型项目或需要个性化异常处理的复杂业务逻辑，局部异常处理则提供了更为灵活的方案。最佳实践是在项目中根据具体情况灵活使用这两种方式，以平衡一致性和个性化需求。

最佳实践与注意事项

1. 最佳实践

统一响应格式： 在异常处理中，使用统一的响应格式有助于客户端更容易理解和处理错误。通常，返回一个包含错误码、错误信息和可能的详细信息的响应对象。

详细错误日志： 在异常处理中记录详细的错误日志，包括异常类型、发生时间、请求信息等。这有助于快速定位和解决问题。

使用HTTP状态码： 根据异常的性质，选择适当的HTTP状态码。例如，使用HttpStatus.NOT_FOUND表示资源未找到，HttpStatus.BAD_REQUEST表示客户端请求错误等。

异常分类： 根据异常的种类，合理分类处理。可以定义不同的异常类来表示不同的异常情况，然后在异常处理中使用@ExceptionHandler分别处理。

全局异常处理： 使用全局异常处理机制来捕获未被特定控制器处理的异常，以确保应用在整体上的健壮性。

2 注意事项

不滥用异常： 异常应该用于表示真正的异常情况，而不是用作控制流程。滥用异常可能导致性能问题和代码可读性降低。

不忽略异常： 避免在异常处理中忽略异常或仅仅打印日志而不进行适当的处理。这可能导致潜在的问题被掩盖，难以追踪和修复。

避免空的catch块： 不要在catch块中什么都不做，这样会使得异常难以被发现。至少在catch块中记录日志，以便了解异常的发生。

适时抛出异常： 不要过于吝啬地抛出异常，但也不要无谓地滥用。在必要的时候使用异常，例如表示无法继续执行的错误情况。

测试异常场景： 编写单元测试时，确保覆盖异常场景，验证异常的正确抛出和处理。

总结

异常处理在应用开发中是至关重要的一环，它能够提高应用的健壮性、可读性和可维护性。全局异常处理和局部异常处理各有优劣，需要根据项目的规模和需求来灵活选择。通过采用统一的响应格式、详细的错误日志、适当的HTTP状态码等最佳实践，可以使异常处理更为有效和易于管理。同时，注意避免滥用异常、忽略异常、适时抛出异常等注意事项，有助于确保异常处理的质量。在开发过程中，持续关注和优化异常处理，将有助于提高应用的稳定性和用户体验。

本文已收录我的个人博客：码农Academy的博客，专注分享Java技术干货，包括Java基础、Spring Boot、Spring Cloud、Mysql、Redis、Elasticsearch、中间件、架构设计、面试题、程序员攻略等

作者：码农Academy
来源：juejin.cn/post/7322463748006248459

收起阅读 »

不要再用 StringBuilder 拼接字符串了，来试试字符串模板

Java

引言字符串操作是 Java 中使用最频繁的操作，没有之一。其中非常常见的操作之一就是对字符串的组织，由于常见所以就衍生了多种方案。比如我们要实现 x + y = ?，方案有如下几种使用 + 进行字符串拼接 String s = x + " + " + ...

继续阅读 »

引言

字符串操作是 Java 中使用最频繁的操作，没有之一。其中非常常见的操作之一就是对字符串的组织，由于常见所以就衍生了多种方案。比如我们要实现 x + y = ?，方案有如下几种

使用 + 进行字符串拼接

String s = x + " + " + y + " = " + (x + y);

使用 StringBuilder

String s = new StringBuilder()

                 .append(x)

                 .append(" + ")

                 .append(y)

                 .append(" = ")

                 .append(x + y)

                 .toString()

String::format 和 String::formatted 将格式字符串从参数中分离出来

String s = String.format("%2$d + %1$d = %3$d", x, y, x + y);

or 

String s = "%2$d + %1$d = %3$d".formatted(x, y, x + y);

java.text.MessageFormat

String s = MessageFormat.format("{0} + {1} = {2}", x,y, x + y);

这四种方案虽然都可以解决，但很遗憾的是他们或多或少都有点儿缺陷，尤其是面对 Java 13 引入的文本块（Java 13 新特性—文本块）更是束手无措。

字符串模板

为了简化字符串的构造和格式化，Java 21 引入字符串模板功能，该特性主要目的是为了提高在处理包含多个变量和复杂格式化要求的字符串时的可读性和编写效率。

它的设计目标是：

通过简单的方式表达混合变量的字符串，简化 Java 程序的编写。

提高混合文本和表达式的可读性，无论文本是在单行源代码中（如字符串字面量）还是跨越多行源代码（如文本块）。

通过支持对模板及其嵌入式表达式的值进行验证和转换，提高根据用户提供的值组成字符串并将其传递给其他系统（如构建数据库查询）的 Java 程序的安全性。

允许 Java 库定义字符串模板中使用的格式化语法（java.util.Formatter ），从而保持灵活性。

简化接受以非 Java 语言编写的字符串（如 SQL、XML 和 JSON）的 API 的使用。

支持创建由字面文本和嵌入式表达式计算得出的非字符串值，而无需通过中间字符串表示。

该特性处理字符串的新方法称为：Template Expressions，即：模版表达式。它是 Java 中的一种新型表达式，不仅可以执行字符串插值，还可以编程，从而帮助开发人员安全高效地组成字符串。此外，模板表达式并不局限于组成字符串——它们可以根据特定领域的规则将结构化文本转化为任何类型的对象。

STR 模板处理器

STR 是 Java 平台定义的一种模板处理器。它通过用表达式的值替换模板中的每个嵌入表达式来执行字符串插值。使用 STR 的模板表达式的求值结果是一个字符串。

STR 是一个公共静态 final 字段，会自动导入到每个 Java 源文件中。

我们先看一个简单的例子：

    @Test

    public void STRTest() {

        String sk = "死磕 Java 新特性";

        String str1 = STR."{sk}，就是牛";

        System.out.println(str1);

    }

// 结果.....

死磕 Java 新特性，就是牛

上面的 STR."{sk}，就是牛" 就是一个模板表达式，它主要包含了三个部分：

模版处理器：STR

包含内嵌表达式（{blog}）的模版

通过.把前面两部分组合起来，形式如同方法调用

当模版表达式运行的时候，模版处理器会将模版内容与内嵌表达式的值组合起来，生成结果。

这个例子只是 STR模版处理器一个很简单的功能，它可以做的事情有很多。

数学运算

比如上面的 x + y = ?：

    @Test

    public void STRTest() {

        int x = 1,y =2;

        String str = STR."{x} + {y} = {x + y}";

        System.out.println(str);

    }

这种写法是不是简单明了了很多？

调用方法

STR模版处理器还可以调用方法，比如：

String str = STR."今天是：{ LocalDate.now()} ";

当然也可以调用我们自定义的方法：

    @Test

    public void STRTest() {

        String str = STR."{getSkStr()},就是牛";

        System.out.println(str);

    }



    public String getSkStr() {

        return "死磕 Java 新特性";

    }

访问成员变量

STR模版处理器还可以访问成员变量，比如：

public record User(String name,Integer age) {

}



@Test

public void STRTest() {

  User user = new User("大明哥",18);

  String str = STR."{user.name()}今年{user.age()}";

  System.out.println(str);

}

需要注意的是，字符串模板表达式中的嵌入表达式数量没有限制，它从左到右依次求值，就像方法调用表达式中的参数一样。例如：

    @Test

    public void STRTest() {

        int i = 0;

        String str = STR."{i++},{i++},{i++},{i++},{i++}";

        System.out.println(str);

    }

// 结果......

0,1,2,3,4

同时，表达式中也可以嵌入表达式：

    @Test

    public void STRTest() {

        String name = "大明哥";

        String sk = "死磕 Java 新特性";

        String str = STR."{name}的{STR."{sk},就是牛..."}";

        System.out.println(str);

    }

// 结果......

大明哥的死磕 Java 新特性,就是牛...

但是这种嵌套的方式会比较复杂，容易搞混，一般不推荐。

多行模板表达式

为了解决多行字符串处理的复杂性，Java 13 引入文本块（Java 13 新特性—文本块），它是使用三个双引号（"""）来标记字符串的开始和结束，允许字符串跨越多行而无需显式的换行符或字符串连接。如下：

String html = """

              <html>

                  <body>

                      <h2>skjava.com</h2>

                      <ul>

                        <li>死磕 Java 新特性</li>

                        <li>死磕 Java 并发</li>

                        <li>死磕 Netty</li>

                        <li>死磕 Redis</li>

                      </ul>

                  </body>

              </html>

              """;

如果字符串模板表达式，我们就只能拼接这串字符串了，这显得有点儿繁琐和麻烦。而字符串模版表达式也支持多行字符串处理，我们可以利用它来方便的组织html、json、xml等字符串内容，比如这样：

    @Test

    public void STRTest() {

        String title = "skjava.com";

        String sk1 = "死磕 Java 新特性";

        String sk2 = "死磕 Java 并发";

        String sk3 = "死磕 Netty";

        String sk4 = "死磕 Redis";



        String html = STR."""

              <html>

                  <body>

                      <h2>{title}</h2>

                      <ul>

                        <li>{sk1}</li>

                        <li>{sk2}</li>

                        <li>{sk3}</li>

                        <li>{sk4}</li>

                      </ul>

                  </body>

              </html>

              """;

        System.out.println(html);

    }

如果决定定义四个 sk 变量麻烦，可以整理为一个集合，然后调用方法生成 <li> 标签。

FMT 模板处理器

FMT 是 Java 定义的另一种模板处理器。它除了与STR模版处理器一样提供插值能力之外，还提供了左侧的格式化处理。下面我们来看看他的功能。比如我们要整理模式匹配的 Switch 表达在 Java 版本中的迭代，也就是下面这个表格

Java 版本	更新类型	JEP	更新内容
Java 17	第一次预览	JEP 406	引入模式匹配的 Swith 表达式作为预览特性。
Java 18	第二次预览	JEP 420	对其做了改进和细微调整
Java 19	第三次预览	JEP 427	进一步优化模式匹配的 Swith 表达式
Java 20	第四次预览	JEP 433
Java 21	正式特性	JEP 441	成为正式特性

如果使用 STR 模板处理器，代码如下：

    @Test

    public void STRTest() {

        SwitchHistory[] switchHistories = new SwitchHistory[]{

                new SwitchHistory("Java 17","第一次预览","JEP 406","引入模式匹配的 Swith 表达式作为预览特性。"),

                new SwitchHistory("Java 18","第二次预览","JEP 420","对其做了改进和细微调整"),

                new SwitchHistory("Java 19","第三次预览","JEP 427","进一步优化模式匹配的 Swith 表达式"),

                new SwitchHistory("Java 20","第四次预览","JEP 433",""),

                new SwitchHistory("Java 21","正式特性","JEP 441","成为正式特性"),

        };



        String history = STR."""

                Java 版本     更新类型    JEP 更新内容

                {switchHistories[0].javaVersion()} {switchHistories[0].updateType()} {switchHistories[0].jep()} {switchHistories[0].content()}

                {switchHistories[1].javaVersion()} {switchHistories[1].updateType()} {switchHistories[1].jep()} {switchHistories[1].content()}

                {switchHistories[2].javaVersion()} {switchHistories[2].updateType()} {switchHistories[2].jep()} {switchHistories[2].content()}

                {switchHistories[3].javaVersion()} {switchHistories[3].updateType()} {switchHistories[3].jep()} {switchHistories[3].content()}

                {switchHistories[4].javaVersion()} {switchHistories[4].updateType()} {switchHistories[4].jep()} {switchHistories[4].content()}

                """;

        System.out.println(history);

    }

得到的效果是这样的：

Java 版本     更新类型    JEP 更新内容

Java 17 第一次预览 JEP 406 引入模式匹配的 Swith 表达式作为预览特性。

Java 18 第二次预览 JEP 420 对其做了改进和细微调整

Java 19 第三次预览 JEP 427 进一步优化模式匹配的 Swith 表达式

Java 20 第四次预览 JEP 433 

Java 21 正式特性 JEP 441 成为正式特性

是不是很丑？完全对不齐，没法看。为了解决这个问题，就可以采用FMT模版处理器，在每一列左侧定义格式：

   @Test

    public void STRTest() {

        SwitchHistory[] switchHistories = new SwitchHistory[]{

                new SwitchHistory("Java 17","第一次预览","JEP 406","引入模式匹配的 Swith 表达式作为预览特性。"),

                new SwitchHistory("Java 18","第二次预览","JEP 420","对其做了改进和细微调整"),

                new SwitchHistory("Java 19","第三次预览","JEP 427","进一步优化模式匹配的 Swith 表达式"),

                new SwitchHistory("Java 20","第四次预览","JEP 433",""),

                new SwitchHistory("Java 21","正式特性","JEP 441","成为正式特性"),

        };



        String history = FMT."""

                Java 版本     更新类型        JEP             更新内容

                %-10s{switchHistories[0].javaVersion()}  %-9s{switchHistories[0].updateType()} %-10s{switchHistories[0].jep()} %-20s{switchHistories[0].content()}

                %-10s{switchHistories[1].javaVersion()}  %-9s{switchHistories[1].updateType()} %-10s{switchHistories[1].jep()} %-20s{switchHistories[1].content()}

                %-10s{switchHistories[2].javaVersion()}  %-9s{switchHistories[2].updateType()} %-10s{switchHistories[2].jep()} %-20s{switchHistories[2].content()}

                %-10s{switchHistories[3].javaVersion()}  %-9s{switchHistories[3].updateType()} %-10s{switchHistories[3].jep()} %-20s{switchHistories[3].content()}

                %-10s{switchHistories[4].javaVersion()}  %-9s{switchHistories[4].updateType()} %-10s{switchHistories[4].jep()} %-20s{switchHistories[4].content()}

                """;

        System.out.println(history);

    }

输出如下：

Java 版本     更新类型        JEP             更新内容

Java 17     第一次预览     JEP 406    引入模式匹配的 Swith 表达式作为预览特性。

Java 18     第二次预览     JEP 420    对其做了改进和细微调整         

Java 19     第三次预览     JEP 427    进一步优化模式匹配的 Swith 表达式

Java 20     第四次预览     JEP 433                        

Java 21     正式特性       JEP 441    成为正式特性

作者：大明哥_
来源：juejin.cn/post/7323251349302706239

收起阅读 »

SpringBoot接收参数的19种方式

Java

1. Get 请求 1.1 以方法的形参接收参数 1.这种方式一般适用参数比较少的情况 @RestController @RequestMapping("/user") @Slf4j public class UserController { @Ge...

继续阅读 »

1. Get 请求

1.1 以方法的形参接收参数

1.这种方式一般适用参数比较少的情况

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {



    @GetMapping("/detail")

    public Result<User> getUserDetail(String name,String phone) {

        log.info("name:{}",name);

        log.info("phone:{}",phone);

       return  Result.success(null);

    }

}

2.参数用 @RequestParam 标注，表示这个参数需要必传，否则会报错。

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {



    @GetMapping("/detail")

    public Result<User> getUserDetail(@RequestParam String name,@RequestParam String phone) {

        log.info("name:{}",name);

        log.info("phone:{}",phone);

       return  Result.success(null);

    }

}

1.2 以实体类接收参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {



    @GetMapping("/detail")

    public Result<User> getUserDetail(User user) {

        log.info("name:{}",user.getName());

        log.info("phone:{}",user.getPhone());

       return  Result.success(null);

    }

}

注：Get 请求以实体类接收参数时，不能用 RequestParam 注解进行标注，因为不支持这样的方式获取参数。

1.3 通过 HttpServletRequest 接收参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @GetMapping("/detail")

    public Result<User> getUserDetail(HttpServletRequest request) {

        String name = request.getParameter("name");

        String phone = request.getParameter("phone");

        log.info("name:{}",name);

        log.info("phone:{}",phone);

       return  Result.success(null);

    }

}

1.4 通过 @PathVariable 注解接收参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {



    @GetMapping("/detail/{name}/{phone}")

    public Result<User> getUserDetail(@PathVariable String name,@PathVariable String phone) {

        log.info("name:{}",name);

        log.info("phone:{}",phone);

       return  Result.success(null);

    }

}

1.5 接收数组参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {



    @GetMapping("/detail")

    public Result<User> getUserDetail(String[] names) {

        Arrays.asList(names).forEach(name->{

            System.out.println(name);

        });

       return  Result.success(null);

    }

}

1.6 接收集合参数

springboot 接收集合参数，需要用 RequestParam 注解绑定参数，否则会报错！！

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {



    @GetMapping("/detail")

    public Result<User> getUserDetail(@RequestParam List<String> names) {

        names.forEach(name->{

            System.out.println(name);

        });

       return  Result.success(null);

    }

}

2. Post 请求

2.1 以方法的形参接收参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {



    @PostMapping("/save")

    public Result<User> getUserDetail(String name,String phone) {

      log.info("name:{}",name);

      log.info("phone:{}",phone);

       return  Result.success(null);

    }

}

注：和 Get 请求一样，如果方法形参用 RequestParam 注解标注，表示这个参数需要必传。

2.2 通过 param 提交参数，以实体类接收参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {



    @PostMapping("/save")

    public Result<User> getUserDetail(User user) {

      log.info("name:{}",user.getName());

      log.info("phone:{}",user.getPhone());

       return  Result.success(null);

    }

}

注：Post 请求以实体类接收参数时，不能用 RequestParam 注解进行标注，因为不支持这样的方式获取参数。

2.3 通过 HttpServletRequest 接收参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {



    @PostMapping("/save")

    public Result<User> getUserDetail(HttpServletRequest httpServletRequest) {

      log.info("name:{}",httpServletRequest.getParameter("name"));

      log.info("phone:{}",httpServletRequest.getParameter("phone"));

       return  Result.success(null);

    }

}

2.4 通过 @PathVariable 注解进行接收

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {



    @PostMapping("/save/{name}")

    public Result<User> getUserDetail(@PathVariable String name) {

      log.info("name:{}",name);

       return  Result.success(null);

    }

}

2.5 请求体以 form-data 提交参数，以实体类接收参数

form-data 是表单提交的一种方式，比如常见的登录请求。

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @PostMapping("/save")

    public Result<User> getUserDetail(User user) {

      log.info("name:{}",user.getName());

      log.info("phone:{}",user.getPhone());

       return  Result.success(null);

    }

}

2.6 请求体以 x-www-form-urlencoded 提交参数，以实体类接收参数

x-www-form-urlencoded 也是表单提交的一种方式，只不过提交的参数被进行了编码，并且转换成了键值对。

例如你用form-data 提交的参数：

name: 知否君

age: 22

用 x-www-form-urlencoded 提交的参数：

name=%E5%BC%A0%E4%B8%89&age=22

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @PostMapping("/save")

    public Result<User> getUserDetail(User user) {

      log.info("name:{}",user.getName());

      log.info("phone:{}",user.getPhone());

       return  Result.success(null);

    }

}

2.7 通过 @RequestBody 注解接收参数

注：RequestBody 注解主要用来接收前端传过来的 body 中 json 格式的参数。

2.7.1 接收实体类参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @PostMapping("/save")

    public Result<User> getUserDetail(@RequestBody User user) {

      log.info("name:{}",user.getName());

      log.info("phone:{}",user.getPhone());

       return  Result.success(null);

    }

}

2.7.2 接收数组和集合

接收数组

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @PostMapping("/save")

    public Result<User> getUserDetail(@RequestBody String[] names) {

        Arrays.asList(names).forEach(name->{

            System.out.println(name);

        });

       return  Result.success(null);

    }

}

接收集合

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @PostMapping("/save")

    public Result<User> getUserDetail(@RequestBody List<String> names) {

        names.forEach(name->{

            System.out.println(name);

        });

       return  Result.success(null);

    }

}

2.8 通过 Map 接收参数

1.以 param 方式传参， RequestParam 注解接收参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @PostMapping("/save")

    public Result<User> getUserDetail(@RequestParam Map<String,Object> map) {

        System.out.println(map);

        System.out.println(map.get("name"));

       return  Result.success(null);

    }

}

2.以 body json 格式传参，RequestBody 注解接收参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @PostMapping("/save")

    public Result<User> getUserDetail(@RequestBody Map<String,Object> map) {

        System.out.println(map);

        System.out.println(map.get("name"));

       return  Result.success(null);

    }

}

2.9 RequestBody 接收一个参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @PostMapping("/save")

    public Result<User> getUserDetail(@RequestBody String name) {

        System.out.println(name);

       return  Result.success(null);

    }

}

3. Delete 请求

3.1 以 param 方式传参，以方法形参接收参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @DeleteMapping("/delete")

    public Result<User> getUserDetail(@RequestParam String name) {

        System.out.println(name);

       return  Result.success(null);

    }

}

3.2 以 body json 方式传参，以实体类接收参数

注：需要用 RequestBody 注解，否则接收的参数为 null

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @DeleteMapping("/delete")

    public Result<User> getUserDetail(@RequestBody User user) {

        System.out.println(user);

       return  Result.success(null);

    }

}

3.3 以 body json 方式传参，以 map 接收参数

注：需要用 RequestBody 注解，否则接收的参数为 null

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @DeleteMapping("/delete")

    public Result<User> getUserDetail(@RequestBody Map<String,Object> map) {

        System.out.println(map);

       return  Result.success(null);

    }

}

3.4 PathVariable 接收参数

@RestController

@RequestMapping("/user")

@Slf4j

public class UserController {

    @DeleteMapping("/delete/{name}")

    public Result<User> getUserDetail(@PathVariable String name) {

        System.out.println(name);

       return  Result.success(null);

    }

}

作者：知否技术
来源：juejin.cn/post/7343243744479625267

收起阅读 »

是的，JDK 也有不为人知的“屎山”！

Java

在前几天我写了一篇文章分享了为何避免使用 Collectors.toMap()，感兴趣的可以去瞧一眼：Stream很好，Map很酷，但答应我别用toMap()。评论区也有小伙伴提到自己也踩过同样的坑，在那篇文章里介绍了 toMap() 有哪些的易踩的坑，今天...

继续阅读 »

在前几天我写了一篇文章分享了为何避免使用 Collectors.toMap()，感兴趣的可以去瞧一眼：Stream很好，Map很酷，但答应我别用toMap()。

评论区也有小伙伴提到自己也踩过同样的坑，在那篇文章里介绍了 toMap() 有哪些的易踩的坑，今天就让我们好好的扒一扒 Map 的底裤，看看这背后不为人知的故事。

要讲 Map，可以说 HashMap 是日常开发使用频次最高的，我愿称其为古希腊掌管性能的神。

举个简单的例子，如何判断两个集合是否存在交集？最简单也最粗暴的方式，两层 for 遍历暴力检索，别跟我提什么时间空间复杂度，给我梭哈就完事。

public void demo() {  

    List<Integer> duplicateList = new ArrayList<>();  

    List<Integer> list1 = List.of(1, 2, 3, 4);  

    List<Integer> list2 = List.of(3, 4, 5, 6);  

    for (Integer l1 : list1) {  

        for (Integer l2 : list2) {  

            if (Objects.equals(l1, l2)) {  

                duplicateList.add(l1);  

            }  

        }  

    }  

    System.out.println(duplicateList);  

}

敲下回车提交代码之后，当还沉浸在等待领导夸你做事又稳又快的时候，却发现领导黑着脸向你一步步走来。

刚准备开始摸鱼的你吓得马上回滚了提交，在一番资料查询之后你发现了原来可以通过 Map 实现 O(n) 级的检索效率，你意气风发的敲下一段新的代码：

public void demo() {  

    List<Integer> duplicateList = new ArrayList<>();  

    List<Integer> list1 = List.of(1, 2, 3, 4);  

    List<Integer> list2 = List.of(3, 4, 5, 6);  



    Map<Integer, Integer> map = new HashMap<>();  

    list2.forEach(it -> map.put(it, it));  

    for (Integer l : list1) {  

        if (Objects.nonNull(map.get(l))) {  

            duplicateList.add(l);  

        }  

    }  

    System.out.println(duplicateList);  

}

重新提交代码起身上厕所，你昂首挺胸的特地从领导面前路过，领导回了你一个肯定的眼神。

让我们回到 HashMap 的身上，作为八股十级选手而言的你，什么数据结构红黑树可谓信手拈来，但我们今天不谈八股，只聊聊背后的一些设计理念。

众所周知，在 HashMap 中有且仅允许存在一个 key 为 null 的元素，当 key 已存在默认的策略是进行覆盖，比如下面的示例最终 map 的值即 {null=2}。

Map<Integer, Integer> map = new HashMap<>();  

map.put(null, 1);  

map.put(null, 2);  

System.out.println(map);

同时 HashMap 对于 value 的值并没有额外限制，只要你愿意，你甚至可以放几百万 value 为空的元素像下面这个例子：

Map<Integer, Integer> map = new HashMap<>();  

map.put(1, null);

map.put(2, null);

map.put(3, null);

map.put(4, null);

map.put(5, null);

System.out.println(map);

这也就引出了今天的重点！

在 stream 中使用 Collectors.toMap() 时，如果你不注意还是按照惯性思维那么它就会让你感受一下什么叫做暴击。就像上一篇文章提到的其异常触发机制，但却并不知道为什么要这么设计？

作为网络冲浪小能手，我反手就是在 stackoverflow 发了提问，咱虽然笨但主打一个好学。

值得一提的是，评论区有个老哥回复的相当戳我，他的回复如下:

用我三脚猫的英语水平翻译一下，大概意思如下：

因为人家 toMap() 并没有说返回的是 HashMap，所以你凭什么想要人家遵循跟 HashMap 一样的规则呢？

我滴个乖乖，他讲的似乎好有道理的样子。

我一开始也差点信了，但其实你认真看 toMap() 的内部实现，你会发现其返回的不偏不倚正好就是 HashMap。

如果你还不信，以上篇文章的代码为例，执行后获取其类型可以看到输出就是 HashMap。

这时候我的 CPU 又烧了，这还是我认识的 HashMap，怎么开始跟 stream 混之后就开始六亲不认了，是谁说的代码永远不会变心的？

一切彷佛又回到了起点，为什么在新的 stream 中不遵循大家已经熟悉规范，而是要改变习惯对此做出限制？

stackoverflow 上另外的一个老哥给出的他的意见：

让我这个四级 751 分老手再给大家做个免费翻译官简化一下观点：

在 Collectors.toMap() 的文档中已经标注其并不保证返回 Map 的具体类型，以及是否可变、序列化性以及是否线程安全，而 JDK 拥有众多的版本，可能在你的环境已经平稳运行了数年，但换个环境之后在不同的 JDK 下可能程序就发生了崩溃。因此，这些额外的保障实际上还帮了你的忙。

回头去看 toMap() 方法上的文档说明，确实也像这位老哥提到的那样。

而在 HashMap 中允许 Key 与 Value 为空带来的一个问题在此时也浮现了出来，当存入一个 value 为空的元素时，再后续执行 get() 再次读取时，存在一个问题那就是二义性。

很显然执行 get() 返回的结果将为空，那这个空究竟是 Map 中不存在这个元素？还是我存入的元素其 value 为空？这一点我想只有老天爷知道，而这种二义性所带来的问题在设计层面显然是一个失误。

那么到这里，我们就可以得到一个暴论：HashMap 允许 key 和 value 为空就是 JDK 留下的“屎山”！

为了验证这一结论，我们可以看看在新的 ConcurrentHashMap 中 JDK 是怎么做的？查看源码可以看到，在 put() 方法的一开始就执行了 key 与 value 的空值校验，也验证了上面的猜想。

这还原不够支撑我们的结论，让我们继续深挖这背后还有什么猫腻。

首先让我看看是谁写的 ConcurrentHashMap，在 openjdk 的 GitHub 仓库类文档注释可以看到主要的开发者是 Doug Lea。

那 Doug Lea 又是何方大佬，通过维基百科的可以看到其早期是 Java 并发社区的主席，他参与了一众的 JDK 并发设计工作，可谓吾辈偶像。

在网络搜罗相关的资讯找到对应的话题，虽然图中的链接已经不存在了，但还是能从引用的内容看出其核心的原因正是为了规避的结果的模糊性，与前文我们讨论的二义性不尽相同。

那为什么 JDK 不同步更新 HashMap 的设计理念，在新版 HashMap 中引入 key 与 value 的非空校验？

我想剩下的理由只有一个：HashMap 的使用范围实在太广，就算是 JDK 自己也很难在不变更原有结构的基础上进行改动，而在 JDK 1.2 便被提出并广泛应用，对于一个发展了数十年的语言而言，兼容性是十分重要的一大考量。

因此，我们可以看到，在后续推出的 Map 中，往往对 key 与 Value 都作了进一步的限制，而对于 HashMap 而言，可能 JDK 官方也是有心无力吧。

到这里基本也就盖棺定论了，但本着严谨的态度大胆假设小心求证，让我们再来看看大家伙的意见，万一不小心就被人网暴了。

在 stackoverflow 上另外几篇有关 Map 回答下可以看到，许多人都认为 HashMap 支持空值是一个存在缺陷的设计。

感兴趣的小伙伴可以去原帖查看，这里我就不再展开介绍了，原帖链接：Why does Map.of not allow null keys and values?。

看到这里，下次别人或者老板再说你写的代码是屎山的时候，请昂首挺胸自信的告诉他 JDk 都会犯错，我写的这点又算得了什么？

作者：烽火戏诸诸诸侯
来源：juejin.cn/post/7384629198130610215

收起阅读 »

零 rust 基础前端使直接上手 tauri 开发一个小工具

综合技术讨论

起因有一天老爸找我，他们公司每年都要在线看视频学习，要花费很多时间，问我有没有办法可以自动学习。在这之前，我还给我老婆写了个浏览器插件，解决了她的在线学习问题，她学习的是一个叫好医生的学习网站，我通过研究网站的接口和代码，帮她开发出了一键学习全部课程和自动...

继续阅读 »

起因

有一天老爸找我，他们公司每年都要在线看视频学习，要花费很多时间，问我有没有办法可以自动学习。

在这之前，我还给我老婆写了个浏览器插件，解决了她的在线学习问题，她学习的是一个叫好医生的学习网站，我通过研究网站的接口和代码，帮她开发出了一键学习全部课程和自动考试的插件，原本需要十来天的学习时间，分分钟就解决了。

有兴趣的可以看一下，好医生自动学习+考试插件源码。

正因为这次的经历，我直接接下了这个需求，毕竟可以在家人面前利用自己的能力去帮他们解决问题，是一件非常骄傲的事。

事情并没有那么简单

我回家一看，他们的学习平台是个桌面端的软件（毕竟是银行的平台，做的比那个好医生严谨的多），内嵌的浏览器，无法打开控制台，更没办法装插件，甚至视频学习调了什么接口，有什么漏洞都无法发现，我感觉有点无能为力。

但是牛逼吹出去了，也得想办法做。

技术选型

既然没办法找系统漏洞去快速学习，那只能按部就班的去听课了，我第一想到的方式是用按键精灵写个脚本，去自动点击就可以了。但是我爸又想给他的同事用，再教他们用按键精灵还是有点上手成本的，所以我打算自己开发一个小工具去实现。

由于我是个前端开发者，做桌面端首先想到的是 Electron，因为我有一些开发经验，所以并不难，但打包后的体积太大，本来一个小工具，做这么大，这不是显得我技术太烂嘛。

所以我选择了 tauri 去开发。

需求分析

首先我想到的方式就是：

用鼠标框选一个区域，然后记录这个区域的颜色信息，记录区域坐标。

不断循环识别这个区域，匹配颜色。

如果匹配到颜色，则点击这个区域。

例如，本节课程学习后，会弹出提示框，进入下一节学习，那么可以识别这个按钮，如果屏幕出现这个按钮，则点击，从而实现自动学习的目的。

我还给它起了个很形象的名字，叫做打地鼠。

由于要点击的不一定只有一个下一节，可能还有其他章节的可能要学习，所以还实现了多任务执行，这样可以识别多个位置。

有兴趣可以看一下源码。

零基础入门 rust

Tauri 已经提供了很多可以在前端调用的接口去实现很多桌面端的功能，但也不能完全能满足我本次开发的需求，所以还是要学习一点 rust 的语法。

这里简单说一下我学到的一些简单语法，方便大家快速入门。由于功能简单，我们并不需要了解 rust 那些高深的内容，了解基础语法即可，不然想学会 rust 我觉得真心很难。我们完全可以先入门，再深入。

适合人群

有一定其他编程语言(C/Java/Go/Python/JavaScript/Typescript/Dart等)基础。你至少得会写点代码是吧。

环境安装

推荐使用 rustup 安装 rust，rustup 是官方提供的的安装工具。

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

安装后，检查版本，这类似安装 node 后查看版本去验证是否成功安装。

rustc --version



>>> rustc 1.73.0 (cc66ad468 2023-10-03)

cargo 是 rust 官方的包管理工具，类似 npm，这里也校验一下是否成功安装。

cargo --version

如果提示不存在指令，重新打开终端再尝试。

编辑器

官方推荐 Clion，是开发 rust 首选开发工具。

不过作为前端，我们依然希望可以使用 vscode 去开发，当然，这也是没有问题的。

vscode 需要搭配 rust-analyzer 一起使用。

除了上面提到的两个命令，还有 rustup 命令也可以直接使用了：

rustup component add rust-analyzer

执行后就都配置好了，可以进行语法的学习了。

变量与常量的声明

定义变量和常量的声明 javascript 和 rust 是一样的，都是通过 let 和 const，但是在定义变量时还是有一些区别的：

默认情况下，变量是不可变的。（这点对于前端同学来说是不是很奇怪？）

如果你想定义一个可变的变量，需要在变量名前面加上 mut。

let x = 1;

x = 2; ❌

let mut x = 1;

x = 2; ✅

如果你不想用 mut，你也可以使用相同的名称声明新的变量：

let x = 1;

let x = x + 1;

Rust 里常量的命名规范是使用全大写字母，每个单词之间使用下划线分开，虽然 JS 没有强制的规范，但是我们也是这么做的。

数据类型

对于只了解 javascript 的同学，这个是非常重要的一环，因为 rust 需要在定义变量时做出类型的定义。即使是有过 typescript 开发经验的同学，这里也有着非常大的区别。这里只说一些与 js 区别较大的地方。

数字

首先 ts 对于数字的类型都是统一的 number，但是 rust 区别就比较大了，分为有符号整型，无符号整型，浮点型。

有 i8、i16、i32、i64、i128、u8、u16、u32、u64、isize、usize、f32、f64。

虽然上面看起来有这么多种类型去定义一个数字类型，实际上它们只是去定义了这个值所占用的空间，新手其实不用太过于纠结这里。如果你不知道应该选择哪种类型，直接使用默认的i32即可，速度也很快。有符号就是分正负(+,-)，无符号只有正数。浮点型在现代计算机里上 f64 和 f32 运行速度差不多，f64 更加精确，所以不用太纠结。

数组

数组定义也有很大区别，你需要一开始就定义好数组的长度：

let a: [i32; 5] = [0; 5];

这表示定义一个包含 5 个元素的数组，所有元素都初始化为 0。一旦定义，数组的大小就不能改变了。

这是不是让前端同学很难理解，那么如何定义一个可变的数组呢？这好像更符合前端的思维。

在 Rust 中，Vec 是一个动态数组，也就是说，它可以在运行时增加或减少元素。

let v: Vec<i32> = Vec::new();

v.push(4);

这是不是更符合前端的直觉？毕竟后面我们要使用鼠标框选一个范围的颜色，这个颜色数组是不固定的，所以要用到 Vec。

数据类型就说到这，其他的有兴趣自行了解即可。

引用包

rust 同 javascript 一样，也可以引入其他包，但语法上就不太一样了，例如：

use autopilot::{geometry::Point, screen, mouse};

强行翻译成 es module 引入：

import { Point, screen, mouse } from 'autopilot';

看到 :: 是不是有点懵逼，javascript 可没有这样的东西，你可以直觉的把它和 . 想象成一样就行。

:: 主要用于访问模块（module）或类型（type）的成员。例如，你可以使用 :: 来访问模块中的函数或常量，或者访问枚举的成员。

. 用于访问结构体（struct）、枚举（enum）或者 trait 对象的实例成员，包括字段（field）和方法（method）。

其他语法

循环：

for i in 0..colors.len() {}

条件判断：

if colors[i] != screen_colors[i] {



}

他们就是少了括号，还有一些高级的语法是 ES 没有的，这都很好理解。

那么我说这样就算入门了，不算过分吧？如果你要学一个语言，千万别因为它难而不敢上手，你直接上手去做，遇坑就填，你会进步很快。

如果你觉得这样很难写代码，那么我建议你买个 copilot 或者平替通义灵码，你上手写点小东西应该就不成问题了，毕竟我就这样就开始做了。

软件开发

Tauri 官网翻译还不全，读起来可能有点吃力，借助翻译工具将就着看吧，我有心帮大家翻译，但是提了 pr，好几天也没人审核。

你可以把 tauri 当作前端和后端不分离的项目，webview 就是前端，rust 写后端。

创建项目

tauri 提供了很多方式去帮你创建一个新的项目：

这里初始化一个 vite + vue + ts 的项目：

最后的目录结构可以看一下：

src 就是前端的目录。

src-tauri 就是后端的目录。

前端

前端是老本行，不想说太多的东西，大家都很熟悉，把页面写出来就可以了。

值得一提的就是 tauri 提供的一些接口，这些接口可以让我们实现一些浏览器上无法实现的功能。

与后端通讯

import { invoke } from "@tauri-apps/api";



invoke('event_name', payload)

通过 invoke 可以调用 rust 方法，并通过 payload 去传递参数。

窗口间传递信息

这里的窗口指的是软件的窗口，不是浏览器的标签页。由于我们要框选一块显示器上的区域，所以要创建一个新的窗口去实现，而选择后要将数据传递给主窗口。

import { listen } from '@tauri-apps/api/event';



listen<{ index: number}>("location", async (event) => {

  const index = event.payload.index;

  // ...

})

获取窗口实例

例如隐藏当前窗口的操作：

import { getCurrent } from '@tauri-apps/api/window';



const win = getCurrent()

win.hide() // 显示窗口即 win.show()

与之相似的还有：

appWindow 获取主窗口实例。

getAll 获取所有窗口实例，可以通过 label 来区分窗口。

最主要的是 WebviewWindow，可以通过他去创建一个新的窗口。

const screenshot = new WebviewWindow("screenshot", {

  title: "screenshot",

  decorations: false,

  // 对应 views/screenshot.vue

  url: `/#/screenshot?index=${props.index}`,

  alwaysOnTop: true,

  transparent: true,

  hiddenTitle: true,

  maximized: true,

  visible: false,

  resizable: false,

  skipTaskbar: false,

})

这里我们创建了一个最大化、透明的窗口，且它位于屏幕最上方，页面指向就是 vue-router 的路由，index 是因为我们不确定要创建多少个窗口，用于区分。

可以通过创建这样的透明窗口，然后实现一个框选区域的功能，这对于前端来说，并不难。

例如鼠标点击左键，滑动鼠标，再松开左键，绘制这个矩形，再加一个按钮。

随后将位置信息传递给主窗口，并关闭这个透明窗口。

后端

首先，src-tauri/src/main.rs 是已经创建好的入口文件，里面已有一些内容，不用都了解。

暴露给前端的方法

tauri::Builder::default().invoke_handler(tauri::generate_handler![scan_once, ...])

通过 invoke_handler 可以暴露给前端 invoke 调用的方法。

! 在 rust 中是指宏调用，主要是方便，并不是 javascript 里的非的含义，这里注意下。

获取屏幕颜色

这里为了性能，我只获取了 x 起始位置到 x 结束位置，y 轴取中间一行的颜色。

use autopilot::{geometry::Point, screen};



pub fn scan_colors(start_x: f64, end_x: f64, y: f64) -> Vec<[u8; 3]> {

    // 双重循环，根据 start_x, end_x, y 定义坐标数组

    let mut points: Vec<Point> = Vec::new();

    let mut x = start_x;

    while x < end_x {

        points.push(Point::new(x, y));

        x += 1.0;

    }

    // 循环获取坐标数组的颜色

    let mut colors: Vec<[u8; 3]> = Vec::new();

    for point in points {

        let pixel = screen::get_color(point).unwrap();

        colors.push([pixel[0], pixel[1], pixel[2]]);

    }

    return colors;

}

这样就获取到一组颜色数组，包含了 RGB 信息。

这里安装了一个叫 autopilot 的包，可以通过 cargo add autopilot 安装，他可以获取屏幕的颜色，也可以操作鼠标。

鼠标操作

使用 autopilot::mouse 可以进行鼠标操作，移动至 x、y 坐标、病点击鼠标左键。

use autopilot::{geometry::Point, mouse};



mouse::move_to(Point::new(x, y));

mouse::click(mouse::Button::Left, );

配置权限

在 src-tauri/tauri.conf.json 中配置 allowlist，如果不想了解都有哪些权限，直接 all: true，全部配上，以后再慢慢了解。

"tauri": {

    "macOSPrivateApi": true,

    "allowlist": {

      "all": true,

    },

}

注意 mac 上如果使用透明窗口，还需要配置 macOSPrivateApi。

整体流程就是这样的，其他都是细节处理，有兴趣可以看下源码。

构建

我爸的电脑是 windows，而我的是 mac，所以需要构建一个 windows 安装包，但是 tauri 依赖本机库和开链，所以想跨平台编译是不可能的，最好的方法就是托管在 GitHub Actions 这种 CI/CD 平台去做。

在项目下创建 .github/workflows/release.yml，它将会在你发布 tag 时触发构建。

name: Release



on:

  push:

    tags:

      - 'v*'

  workflow_dispatch:



concurrency:

  group: release-${{ github.ref }}

  cancel-in-progress: true



jobs:

  publish:

    strategy:

      fail-fast: false

      matrix:

        platform: [macos-latest, windows-latest]



    runs-on: ${{ matrix.platform }}

    steps:

      - uses: actions/checkout@v4

      - uses: pnpm/action-setup@v2

        with:

          version: 8

          run_install: true



      - name: Use Node.js

        uses: actions/setup-node@v4

        with:

          node-version: 20

          cache: 'pnpm'



      - name: install Rust stable

        uses: actions-rs/toolchain@v1

        with:

          toolchain: stable



      - name: Build Vite + Tauri

        run: pnpm build



      - name: Create release

        uses: tauri-apps/tauri-action@v0

        env:

          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

        with:

          tagName: v__VERSION__ # the action automatically replaces \_\_VERSION\_\_ with the app version

          releaseName: 'v__VERSION__'

          releaseBody: 'See the assets to download and install this version.'

          releaseDraft: true

          prerelease: false

这里提供一个实例，具体情况具体修改。

secrets.GITHUB_TOKEN 并不需要你配置，他是自动获取的，主要是获得权限去操作你的仓库。因为构建完成会自动创建 release，并上传安装包。

你还需要修改一下仓库的配置：

选中 Read and write permissions，勾选
Allow GitHub Actions to create and approve pull requests。

当你发布 tag 后，会触发 action 执行。

可见，打包速度真的很慢。

Actions 执行完毕后，进入 Releases 页面，可以看到安装包已经发布。

总结

关于 tauri 和 electron，甚至是 flutter、qt 这种技术方向没必要讨论谁好谁坏，主要还是考虑项目的痛点，去选择适合自己的方式，没必要捧高踩低。

Rust 真的很难学，我上文草草几句入门，其实并没有那么简单，刚上手会踩很多坑，甚至无从下手不会写代码。我主要的目的是希望大家有想法就要着手去做，毕竟站在岸上学不会游泳。Flutter 使用 dart，我曾经写写过两个 app，相比于 rust，dart 对于前端同学来说可以更轻松的学习。

Tauri 我目前还是比较看好，也很看好 rust，大家有时间的话还是值得学习一下，尤其是 2.0 版本还支持了移动端。

看到很多同学，在学习一门语言或技术时，总是不知道做什么，不只是工作，其实我们身边有很多事情都可以去做，可能只是你想不到。我平时真的是喜欢利用代码去搞一些奇奇怪怪的事，例如我写过 vscode 摸鱼插件、自动学习视频的 chrome 插件、互赞平台、小电影爬虫等等，这些都是用 javascript 就实现的。你可以做的很多，给自己提一个需求，然后不要怕踩坑，踩坑的过程是你进步最快的过程，享受它。

作者：codexu
来源：juejin.cn/post/7320288231194755122

收起阅读 »

告别破解版烦恼!Navicat Premium Lite免费版它来了

综合技术讨论

作为一名后端开发者，在开发过程中使用可视化工具查看数据库中的数据是我们的基本操作。Navicat作为一款广受欢迎的数据库连接工具，深受我们喜爱和挑战。我们喜爱它强大的功能和直观的操作习惯，但又对它的收费模式感到不满。个人使用可以通过破解解决，然而在公司环境下，...

继续阅读 »

作为一名后端开发者，在开发过程中使用可视化工具查看数据库中的数据是我们的基本操作。Navicat作为一款广受欢迎的数据库连接工具，深受我们喜爱和挑战。我们喜爱它强大的功能和直观的操作习惯，但又对它的收费模式感到不满。个人使用可以通过破解解决，然而在公司环境下，由于侵权问题，我们通常被禁止使用，这令我们感到很不便。然而，最近Navicat推出了一款免费的产品——Navicat Premium Lite。

Navicat Premium Lite

Navicat Premium Lite 是 Navicat 的精简版，拥有基本数据库操作所需的核心功能。它允许你从单个应用程序同时连接到各种数据库平台，包括 MySQL、Redis、PostgreSQL、SQL Server、Oracle、MariaDB、SQLite 和 MongoDB。Navicat Premium Lite 提供简化的数据库管理体验，使其成为用户的实用选择。

下载地址：https://www.navicat.com.cn/download/direct-download?product=navicat170_premium_lite_cs_x64.exe&location=1

文档地址： https://www.navicat.com.cn/products/navicat-premium-lite

安装及功能对比

由于这个版本是免费版，不需要破解，所以安装我们此处就不多作介绍。

功能对比

功能对比列表地址：https://www.navicat.com.cn/products/navicat-premium-feature-matrix

Navicat Premium Lite 基础功能都是有的，但是和企业版的相比，还是缺失了一些功能，具体大家可查看官网地址，我们此处列举部分

_20240628063823.jpg

使用感受

整体使用了下，感觉和破解版使用的差别基本不大，缺失的功能几乎无影响。

_20240628064405.jpg

总结

Navicat Premium Lite不仅仅是一款功能全面的数据库管理工具，更是因其免费且功能强大而备受青睐的原因。对于个人开发者、小型团队以及教育用途来说，Navicat Premium Lite提供了一个完全满足需求的解决方案，而无需支付高昂的许可费用。其稳定性、易用性和丰富的功能使得它在数据库管理领域中具备了极高的竞争力。

作者：修己xj
来源：juejin.cn/post/7384997446219743272

收起阅读 »

多级校验、工作流，这样写代码才足够优雅！

综合技术讨论

责任链模式，简而言之，就是将多个操作组装成一条链路进行处理。请求在链路上传递，链路上的每一个节点就是一个处理器，每个处理器都可以对请求进行处理，或者传递给链路上的下一个处理器处理。责任链模式的应用场景，在实际工作中，通常有如下两种应用场景。操作需要经...

继续阅读 »

责任链模式，简而言之，就是将多个操作组装成一条链路进行处理。

请求在链路上传递，链路上的每一个节点就是一个处理器，每个处理器都可以对请求进行处理，或者传递给链路上的下一个处理器处理。

责任链模式的应用场景，在实际工作中，通常有如下两种应用场景。

操作需要经过一系列的校验，通过校验后才执行某些操作。

工作流。企业中通常会制定很多工作流程，一级一级的去处理任务。

下面通过两个案例来学习一下责任链模式。

案例一：创建商品多级校验场景

以创建商品为例，假设商品创建逻辑分为以下三步完成：

①创建商品、

②校验商品参数、

③保存商品。

第②步校验商品又分为多种情况的校验，必填字段校验、规格校验、价格校验、库存校验等等。

这些检验逻辑像一个流水线，要想创建出一个商品，必须通过这些校验。如下流程图所示：

图片

伪代码如下：

创建商品步骤，需要经过一系列的参数校验，如果参数校验失败，直接返回失败的结果；通过所有的参数校验后，最终保存商品信息。

图片

如上代码看起来似乎没什么问题，它非常工整，而且代码逻辑很清晰。

PS：我没有把所有的校验代码都罗列在一个方法里，那样更能产生对比性，但我觉得抽象并分离单一职责的函数应该是每个程序员最基本的规范！

但是随着业务需求不断地叠加，相关的校验逻辑也越来越多，新的功能使代码越来越臃肿，可维护性较差。

更糟糕的是，这些校验组件不可复用，当你有其他需求也需要用到一些校验时，你又变成了Ctrl＋C , Ctrl＋V程序员，系统的维护成本也越来越高。如下图所示：

图片

伪代码同上，这里就不赘述了。

终于有一天，你忍无可忍了，决定重构这段代码。

使用责任链模式优化：创建商品的每个校验步骤都可以作为一个单独的处理器，抽离为一个单独的类，便于复用。

这些处理器形成一条链式调用，请求在处理器链上传递，如果校验条件不通过，则处理器不再向下传递请求，直接返回错误信息；若所有的处理器都通过检验，则执行保存商品步骤。

图片

案例一实战：责任链模式实现创建商品校验

UML图：一览众山小

图片

AbstractCheckHandler表示处理器抽象类，负责抽象处理器行为。其有3个子类，分别是：

NullValueCheckHandler：空值校验处理器

PriceCheckHandler：价格校验处理

StockCheckHandler：库存校验处理器

AbstractCheckHandler 抽象类中， handle()定义了处理器的抽象方法，其子类需要重写handle()方法以实现特殊的处理器校验逻辑；

protected ProductCheckHandlerConfig config 是处理器的动态配置类，使用protected声明，每个子类处理器都持有该对象。

该对象用于声明当前处理器、以及当前处理器的下一个处理器nextHandler，另外也可以配置一些特殊属性，比如说接口降级配置、超时时间配置等。

AbstractCheckHandler nextHandler 是当前处理器持有的下一个处理器的引用，当前处理器执行完毕时，便调用nextHandler执行下一处理器的handle()校验方法；

protected Result next() 是抽象类中定义的，执行下一个处理器的方法，使用protected声明，每个子类处理器都持有该对象。

当子类处理器执行完毕(通过)时，调用父类的方法执行下一个处理器nextHandler。

HandlerClient 是执行处理器链路的客户端，HandlerClient.executeChain()方法负责发起整个链路调用，并接收处理器链路的返回值。

商品参数对象：保存商品的入参

ProductVO是创建商品的参数对象，包含商品的基础信息。

并且其作为责任链模式中多个处理器的入参，多个处理器都以ProductVO为入参进行特定的逻辑处理。

实际业务中，商品对象特别复杂。咱们化繁为简，简化商品参数如下：

/**

 * 商品对象

 */

@Data

@Builder

public class ProductVO {

    /**

     * 商品SKU，唯一

     */

    private Long skuId;

    /**

     * 商品名称

     */

    private String skuName;

    /**

     * 商品图片路径

     */

    private String Path;

    /**

     * 价格

     */

    private BigDecimal price;

    /**

     * 库存

     */

    private Integer stock;

}

抽象类处理器：抽象行为，子类共有属性、方法

AbstractCheckHandler：处理器抽象类，并使用@Component注解注册为由Spring管理的Bean对象，这样做的好处是，我们可以轻松的使用Spring来管理这些处理器Bean。

/**

 * 抽象类处理器

 */

@Component

public abstract class AbstractCheckHandler {



    /**

     * 当前处理器持有下一个处理器的引用

     */

    @Getter

    @Setter

    protected AbstractCheckHandler nextHandler;





    /**

     * 处理器配置

     */

    @Setter

    @Getter

    protected ProductCheckHandlerConfig config;



    /**

     * 处理器执行方法

     * @param param

     * @return

     */

    public abstract Result handle(ProductVO param);



    /**

     * 链路传递

     * @param param

     * @return

     */

    protected Result next(ProductVO param) {

        //下一个链路没有处理器了，直接返回

        if (Objects.isNull(nextHandler)) {

            return Result.success();

        }



        //执行下一个处理器

        return nextHandler.handle(param);

    }



}

在AbstractCheckHandler抽象类处理器中，使用protected声明子类可见的属性和方法。

使用 @Component注解，声明其为Spring的Bean对象，这样做的好处是可以利用Spring轻松管理所有的子类，下面会看到如何使用。

抽象类的属性和方法说明如下：

public abstract Result handle()：表示抽象的校验方法，每个处理器都应该继承AbstractCheckHandler抽象类处理器，并重写其handle方法，各个处理器从而实现特殊的校验逻辑，实际上就是多态的思想。

protected ProductCheckHandlerConfig config：表示每个处理器的动态配置类，可以通过“配置中心”动态修改该配置，实现处理器的“动态编排”和“顺序控制”。配置类中可以配置处理器的名称、下一个处理器、以及处理器是否降级等属性。

protected AbstractCheckHandler nextHandler：表示当前处理器持有下一个处理器的引用，如果当前处理器handle()校验方法执行完毕，则执行下一个处理器nextHandler的handle()校验方法执行校验逻辑。

protected Result next(ProductVO param)：此方法用于处理器链路传递，子类处理器执行完毕后，调用父类的next()方法执行在config 配置的链路上的下一个处理器，如果所有处理器都执行完毕了，就返回结果了。

ProductCheckHandlerConfig配置类 :

/**

 * 处理器配置类

 */

@AllArgsConstructor

@Data

public class ProductCheckHandlerConfig {

    /**

     * 处理器Bean名称

     */

    private String handler;

    /**

     * 下一个处理器

     */

    private ProductCheckHandlerConfig next;

    /**

     * 是否降级

     */

    private Boolean down = Boolean.FALSE;

}

子类处理器：处理特有的校验逻辑

AbstractCheckHandler抽象类处理器有3个子类分别是：

NullValueCheckHandler：空值校验处理器

PriceCheckHandler：价格校验处理

StockCheckHandler：库存校验处理器

各个处理器继承AbstractCheckHandler抽象类处理器，并重写其handle()处理方法以实现特有的校验逻辑。

NullValueCheckHandler：空值校验处理器。针对性校验创建商品中必填的参数。如果校验未通过，则返回错误码ErrorCode，责任链在此截断(停止)，创建商品返回被校验住的错误信息。注意代码中的降级配置！

super.getConfig().getDown()是获取AbstractCheckHandler处理器对象中保存的配置信息，如果处理器配置了降级，则跳过该处理器，调用super.next()执行下一个处理器逻辑。

同样，使用@Component注册为由Spring管理的Bean对象，

/**

 * 空值校验处理器

 */

@Component

public class NullValueCheckHandler extends AbstractCheckHandler{



    @Override

    public Result handle(ProductVO param) {

        System.out.println("空值校验 Handler 开始...");

        

        //降级：如果配置了降级，则跳过此处理器，执行下一个处理器

        if (super.getConfig().getDown()) {

            System.out.println("空值校验 Handler 已降级，跳过空值校验 Handler...");

            return super.next(param);

        }

        

        //参数必填校验

        if (Objects.isNull(param)) {

            return Result.failure(ErrorCode.PARAM_NULL_ERROR);

        }

        //SkuId商品主键参数必填校验

        if (Objects.isNull(param.getSkuId())) {

            return Result.failure(ErrorCode.PARAM_SKU_NULL_ERROR);

        }

        //Price价格参数必填校验

        if (Objects.isNull(param.getPrice())) {

            return Result.failure(ErrorCode.PARAM_PRICE_NULL_ERROR);

        }

        //Stock库存参数必填校验

        if (Objects.isNull(param.getStock())) {

            return Result.failure(ErrorCode.PARAM_STOCK_NULL_ERROR);

        }

        

        System.out.println("空值校验 Handler 通过...");

        

        //执行下一个处理器

        return super.next(param);

    }

}

PriceCheckHandler：价格校验处理。

针对创建商品的价格参数进行校验。这里只是做了简单的判断价格>0的校验，实际业务中比较复杂，比如“价格门”这些防范措施等。

/**

 * 价格校验处理器

 */

@Component

public class PriceCheckHandler extends AbstractCheckHandler{

    @Override

    public Result handle(ProductVO param) {

        System.out.println("价格校验 Handler 开始...");



        //非法价格校验

        boolean illegalPrice =  param.getPrice().compareTo(BigDecimal.ZERO) <= 0;

        if (illegalPrice) {

            return Result.failure(ErrorCode.PARAM_PRICE_ILLEGAL_ERROR);

        }

        //其他校验逻辑...



        System.out.println("价格校验 Handler 通过...");



        //执行下一个处理器

        return super.next(param);

    }

}

StockCheckHandler：库存校验处理器。

针对创建商品的库存参数进行校验。

/**

 * 库存校验处理器

 */

@Component

public class StockCheckHandler extends AbstractCheckHandler{

    @Override

    public Result handle(ProductVO param) {

        System.out.println("库存校验 Handler 开始...");



        //非法库存校验

        boolean illegalStock = param.getStock() < 0;

        if (illegalStock) {

            return Result.failure(ErrorCode.PARAM_STOCK_ILLEGAL_ERROR);

        }

        //其他校验逻辑..



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



        //执行下一个处理器

        return super.next(param);

    }

}

客户端：执行处理器链路

HandlerClient客户端类负责发起整个处理器链路的执行，通过executeChain()方法。

如果处理器链路返回错误信息，即校验未通过，则整个链路截断（停止），返回相应的错误信息。

public class HandlerClient {



  public static Result executeChain(AbstractCheckHandler handler, ProductVO param) {

      //执行处理器

      Result handlerResult = handler.handle(param);

      if (!handlerResult.isSuccess()) {

          System.out.println("HandlerClient 责任链执行失败返回：" + handlerResult.toString());

          return handlerResult;

      }

      return Result.success();

  }

}

以上，责任链模式相关的类已经创建好了。

接下来就可以创建商品了。

创建商品：抽象步骤，化繁为简

createProduct()创建商品方法抽象为2个步骤：①参数校验、②创建商品。

参数校验使用责任链模式进行校验，包含：空值校验、价格校验、库存校验等等，只有链上的所有处理器均校验通过，才调用saveProduct()创建商品方法；否则返回校验错误信息。

在createProduct()创建商品方法中，通过责任链模式，我们将校验逻辑进行解耦。createProduct()创建商品方法中不需要关注都要经过哪些校验处理器，以及校验处理器的细节。

/**

 * 创建商品

 * @return

 */

@Test

public Result createProduct(ProductVO param) {



    //参数校验，使用责任链模式

    Result paramCheckResult = this.paramCheck(param);

    if (!paramCheckResult.isSuccess()) {

        return paramCheckResult;

    }



    //创建商品

    return this.saveProduct(param);

}

参数校验：责任链模式

参数校验paramCheck()方法使用责任链模式进行参数校验，方法内没有声明具体都有哪些校验，具体有哪些参数校验逻辑是通过多个处理器链传递的。如下：

/**

 * 参数校验：责任链模式

 * @param param

 * @return

 */

private Result paramCheck(ProductVO param) {



    //获取处理器配置：通常配置使用统一配置中心存储，支持动态变更

    ProductCheckHandlerConfig handlerConfig = this.getHandlerConfigFile();



    //获取处理器

    AbstractCheckHandler handler = this.getHandler(handlerConfig);



    //责任链：执行处理器链路

    Result executeChainResult = HandlerClient.executeChain(handler, param);

    if (!executeChainResult.isSuccess()) {

        System.out.println("创建商品 失败...");

        return executeChainResult;

    }



    //处理器链路全部成功

    return Result.success();

}

paramCheck()方法步骤说明如下：

👉 步骤1：获取处理器配置。

通过getHandlerConfigFile()方法获取处理器配置类对象，配置类保存了链上各个处理器的上下级节点配置，支持流程编排、动态扩展。

通常配置是通过Ducc(京东自研的配置中心)、Nacos(阿里开源的配置中心)等配置中心存储的，支持动态变更、实时生效。

基于此，我们便可以实现校验处理器的编排、以及动态扩展了。

我这里没有使用配置中心存储处理器链路的配置，而是使用JSON串的形式去模拟配置，大家感兴趣的可以自行实现。

/**

 * 获取处理器配置：通常配置使用统一配置中心存储，支持动态变更

 * @return

 */

private ProductCheckHandlerConfig getHandlerConfigFile() {

    //配置中心存储的配置

    String configJson = "{"handler":"nullValueCheckHandler","down":true,"next":{"handler":"priceCheckHandler","next":{"handler":"stockCheckHandler","next":null}}}";

    //转成Config对象

    ProductCheckHandlerConfig handlerConfig = JSON.parseObject(configJson, ProductCheckHandlerConfig.class);

    return handlerConfig;

}

ConfigJson存储的处理器链路配置JSON串，在代码中可能不便于观看，我们可以使用json.cn等格式化看一下，如下，配置的整个调用链路规则特别清晰。

图片

getHandlerConfigFile()类获到配置类的结构如下，可以看到，就是把在配置中心储存的配置规则，转换成配置类ProductCheckHandlerConfig对象，用于程序处理。

注意，此时配置类中存储的仅仅是处理器Spring Bean的name而已，并非实际处理器对象。

图片

接下来，通过配置类获取实际要执行的处理器。

👉 步骤2：根据配置获取处理器。

上面步骤1通过getHandlerConfigFile()方法获取到处理器链路配置规则后，再调用getHandler()获取处理器。

getHandler()参数是如上ConfigJson配置的规则，即步骤1转换成的ProductCheckHandlerConfig对象；

根据ProductCheckHandlerConfig配置规则转换成处理器链路对象。代码如下：

 * 使用Spring注入:所有继承了AbstractCheckHandler抽象类的Spring Bean都会注入进来。Map的Key对应Bean的name,Value是name对应相应的Bean

 */

@Resource

private Map handlerMap;



/**

 * 获取处理器

 * @param config

 * @return

 */

private AbstractCheckHandler getHandler (ProductCheckHandlerConfig config) {

    //配置检查：没有配置处理器链路，则不执行校验逻辑

    if (Objects.isNull(config)) {

        return null;

    }

    //配置错误

    String handler = config.getHandler();

    if (StringUtils.isBlank(handler)) {

        return null;

    }

    //配置了不存在的处理器

    AbstractCheckHandler abstractCheckHandler = handlerMap.get(config.getHandler());

    if (Objects.isNull(abstractCheckHandler)) {

        return null;

    }

    

    //处理器设置配置Config

    abstractCheckHandler.setConfig(config);

    

    //递归设置链路处理器

    abstractCheckHandler.setNextHandler(this.getHandler(config.getNext()));



    return abstractCheckHandler;

}

👉 👉 步骤2-1：配置检查。

代码14~27行，进行了配置的一些检查操作。如果配置错误，则获取不到对应的处理器。代码23行handlerMap.get(config.getHandler())是从所有处理器映射Map中获取到对应的处理器Spring Bean。

注意第5行代码，handlerMap存储了所有的处理器映射，是通过Spring @Resource注解注入进来的。注入的规则是：所有继承了AbstractCheckHandler抽象类（它是Spring管理的Bean）的子类（子类也是Spring管理的Bean）都会注入进来。

注入进来的handlerMap中 Map的Key对应Bean的name，Value是name对应的Bean实例，也就是实际的处理器，这里指空值校验处理器、价格校验处理器、库存校验处理器。如下：

图片

这样根据配置ConfigJson（👉 步骤1：获取处理器配置）中handler:"priceCheckHandler"的配置，使用handlerMap.get(config.getHandler())便可以获取到对应的处理器Spring Bean对象了。

👉 👉 步骤2-2：保存处理器规则。

代码29行，将配置规则保存到对应的处理器中abstractCheckHandler.setConfig(config)，子类处理器就持有了配置的规则。

👉 👉 步骤2-3：递归设置处理器链路。

代码32行，递归设置链路上的处理器。

//递归设置链路处理器 abstractCheckHandler.setNextHandler(this.getHandler(config.getNext()));

这一步可能不太好理解，结合ConfigJson配置的规则来看，似乎就很很容易理解了。

图片

由上而下，NullValueCheckHandler 空值校验处理器通过setNextHandler()方法设置自己持有的下一节点的处理器，也就是价格处理器PriceCheckHandler。

接着，PriceCheckHandler价格处理器，同样需要经过步骤2-1配置检查、步骤2-2保存配置规则，并且最重要的是，它也需要设置下一节点的处理器StockCheckHandler库存校验处理器。

StockCheckHandler库存校验处理器也一样，同样需要经过步骤2-1配置检查、步骤2-2保存配置规则，但请注意StockCheckHandler的配置，它的next规则配置了null，这表示它下面没有任何处理器要执行了，它就是整个链路上的最后一个处理节点。

通过递归调用getHandler()获取处理器方法，就将整个处理器链路对象串联起来了。如下：

图片

友情提示：递归虽香，但使用递归一定要注意截断递归的条件处理，否则可能造成死循环哦！

实际上，getHandler()获取处理器对象的代码就是把在配置中心配置的规则ConfigJson，转换成配置类ProductCheckHandlerConfig对象，再根据配置类对象，转换成实际的处理器对象，这个处理器对象持有整个链路的调用顺序。

👉 步骤3：客户端执行调用链路。

public class HandlerClient {



  public static Result executeChain(AbstractCheckHandler handler, ProductVO param) {

      //执行处理器

      Result handlerResult = handler.handle(param);

      if (!handlerResult.isSuccess()) {

          System.out.println("HandlerClient 责任链执行失败返回：" + handlerResult.toString());

          return handlerResult;

      }

      return Result.success();

  }

}

getHandler()获取完处理器后，整个调用链路的执行顺序也就确定了，此时，客户端该干活了！

HandlerClient.executeChain(handler, param)方法是HandlerClient客户端类执行处理器整个调用链路的，并接收处理器链路的返回值。

executeChain()通过AbstractCheckHandler.handle()触发整个链路处理器顺序执行，如果某个处理器校验没有通过!handlerResult.isSuccess()，则返回错误信息；所有处理器都校验通过，则返回正确信息Result.success()。

总结：串联方法调用流程

基于以上，再通过流程图来回顾一下整个调用流程。

图片

测试：代码执行结果

场景1：创建商品参数中有空值（如下skuId参数为null），链路被空值处理器截断，返回错误信息

//创建商品参数

ProductVO param = ProductVO.builder()

      .skuId(null).skuName("华为手机").Path("http://...")

      .price(new BigDecimal(1))

      .stock(1)

      .build();

测试结果

图片

场景2：创建商品价格参数异常（如下price参数），被价格处理器截断，返回错误信息

ProductVO param = ProductVO.builder()

      .skuId(1L).skuName("华为手机").Path("http://...")

      .price(new BigDecimal(-999))

      .stock(1)

      .build();

测试结果

图片

场景 3：创建商品库存参数异常（如下stock参数），被库存处理器截断，返回错误信息。

//创建商品参数，模拟用户传入

ProductVO param = ProductVO.builder()

      .skuId(1L).skuName("华为手机").Path("http://...")

      .price(new BigDecimal(1))

      .stock(-999)

      .build();

测试结果

图片

场景4：创建商品所有处理器校验通过，保存商品。

![15](C:\Users\18796\Desktop\文章\15.png)![15](C:\Users\18796\Desktop\文章\15.png)![15](C:\Users\18796\Desktop\文章\15.png)![15](C:\Users\18796\Desktop\文章\15.png)//创建商品参数，模拟用户传入

ProductVO param = ProductVO.builder()

      .skuId(1L).skuName("华为手机").Path("http://...")

      .price(new BigDecimal(999))

      .stock(1).build();

测试结果

责任链的优缺点

作者：程序员蜗牛
来源：juejin.cn/post/7384632888321179659

收起阅读 »

第一次使用缓存，因为没预热，翻车了

综合技术讨论

缓存不预热会怎么样？我帮大家淌了路。缓存不预热会导致系统接口性能下降，数据库压力增加，更重要的是导致我写了两天的复盘文档，在复盘会上被骂出了翔。悲惨的上线时刻事情发生在几年前，我刚毕业时，第一次使用缓存内心很激动。需求场景是虚拟商品页面需要向用户透出库存状...

继续阅读 »

缓存不预热会怎么样？我帮大家淌了路。缓存不预热会导致系统接口性能下降，数据库压力增加，更重要的是导致我写了两天的复盘文档，在复盘会上被骂出了翔。

悲惨的上线时刻

事情发生在几年前，我刚毕业时，第一次使用缓存内心很激动。需求场景是虚拟商品页面需要向用户透出库存状态，提单时也需要校验库存状态是否可售卖。但是由于库存状态的计算包含较复杂的业务逻辑，耗时比较高，在500ms以上。如果要在商品页面透出库存状态那么商品页面耗时增加500ms，这几乎是无法忍受的事情。

如何实现呢？最合适的方案当然是缓存了，我当时设计的方案是如果缓存有库存状态直接读缓存，如果缓存查不到，则计算库存状态，然后加载进缓存，同时设定过期时间。何时写库存呢？答案是过期后，cache miss时重新加载进缓存。由于计算逻辑较复杂，库存扣减等用户写操作没有同步更新缓存，但是产品认可库存状态可以有几分钟的状态不一致。为什么呢？

因为仓库有冗余库存，就算库存状态不一致导致超卖，也能容忍。同时库存不足以后，需要运营补充库存，而补充库存的时间是肯定比较长的。虽然补充库存完成几分钟后，才变为可售卖的，产品也能接受。梳理完缓存的读写方案，我就沉浸于学习Redis的过程。

第一次使用缓存，我把时间和精力都放在Redis存储结构，Redis命令，Redis为什么那么快等方面的关注。如饥似渴的学习Redis知识。

直到上线阶段我也没有意识到系统设计的缺陷。

代码写的很快，测试验证也没有问题。然而上线过程中，就开始噼里啪啦的报警，开始我并没有想到报警这事和我有关。直到有人问我，“XXX，你是不是在上线库存状态的需求？”。

我人麻了，”怎么了，啥事”，我颤抖的问

“商品页面耗时暴涨，赶紧回滚”。一个声音传来

“我草”，那一瞬间，我的血压上涌，手心发痒，心跳加速，头皮发麻，颤抖的手不知道怎么在发布系统点回滚，“我没回滚过啊，咋回滚啊？”

“有降级开关吗”? 一个声音传来。

"没写..."。我回答的时候觉得自己真是二笔，为啥没加降级啊。（这也是复盘被骂的重要原因）

那么如何对缓存进行预热呢？

如何预热缓存

灰度放量

灰度放量实际上并不是缓存预热的办法，但是确实能避免缓存雪崩的问题。例如这个需求场景中，如果我没有放开全量数据，而是选择放量1%的流量。这样系统的性能不会有较大的下降，并且逐步放量到100%。

虽然这个过程中，没有主动同步数据到缓存，但是通过控制放量的节奏，保证了初始化缓存过程中，不会出现较大的耗时波动。

例如新上线的缓存逻辑，可以考虑逐渐灰度放量。

扫描数据库刷缓存

如果缓存维度是商品维度或者用户维度，可以考虑扫描数据库，提前预热部分数据到缓存中。

开发成本较高。除了开发缓存部分的代码，还需要开发扫描全表的任务。为了控制缓存刷新的进度，还需要使用线程池增加并发，使用限流器限制并发。这个方案的开发成本较高。

通过数据平台刷缓存

这是比较好的方式，具体怎么实现呢？

数据平台如果支持将数据库离线数据同步到Hive，Hive数据同步到Kafka，我们就可以编写Hive SQL，建立ETL任务。把业务需要被刷新的数据同步到Kafka中，再消费Kafka，把数据写入到缓存中。在这个过程中通过数据平台控制并发度，通过Kafka 分片和消费线程并发度控制缓存写入的速率。

这个方案开发逻辑包括ETL 任务，消费Kafka写入缓存。这两部分的开发工作量不大。并且相比扫描全表任务，ETL可以编写更加复杂的SQL，修改后立即上线，无需自己控制并发、控制限流。在多个方面ETL刷缓存效率更高。

但是这个方案需要公司级别支持多个存储系统之间可以进行数据同步。例如mysql、kafka、hive等。

除了首次上线，是否还有其他场景需要预热缓存呢？

需要预热缓存的其他场景

如果Redis挂了，数据怎么办

刚才提到上线前，一定要进行缓存预热。还有一个场景：假设Redis挂了，怎么办？全量的缓存数据都没有了，全部请求同时打到数据库，怎么办。

除了首次上线需要预热缓存，实际上如果缓存数据丢失后，也需要预热缓存。所以预热缓存的任务一定要开发的，一方面是上线前预热缓存，同时也是为了保证缓存挂掉后，也能重新预热缓存。

假如有大量数据冷启动怎么办

假如促销场景，例如春节抢红包，平时非活跃用户会在某个时间点大量打开App，这也会导致大量cache miss，进而导致雪崩。此时就需要提前预热缓存了。具体的办法，可以考虑使用ETL任务。离线加载大量数据到Kafka，然后再同步到缓存。

总结

一定要预热缓存，不然线上接口性能和数据库真的扛不住。

可以通过灰度放量，扫描全表、ETL数据同步等方式预热缓存

Redis挂了，大量用户冷启动的促销场景等场景都需要提前预热缓存。

作者：五阳
来源：juejin.cn/post/7277461864349777972

收起阅读 »

半夜被慢查询告警吵醒，limit深度分页的坑

综合技术讨论

故事梅雨季，闷热的夜，令人窒息，窗外一道道闪电划破漆黑的夜幕，小猫塞着耳机听着恐怖小说，辗转反侧，终于睡意来了，然而挨千刀的手机早不振晚不振，偏偏这个时候振动了一下，一个激灵，没有按捺住对内容的好奇，点开了短信，卧槽？告警信息，原来是负责的服务出现慢查询了。小...

继续阅读 »

故事

梅雨季，闷热的夜，令人窒息，窗外一道道闪电划破漆黑的夜幕，小猫塞着耳机听着恐怖小说，辗转反侧，终于睡意来了，然而挨千刀的手机早不振晚不振，偏偏这个时候振动了一下，一个激灵，没有按捺住对内容的好奇，点开了短信，卧槽？告警信息，原来是负责的服务出现慢查询了。小猫想起来，今天在下班之前上线了一个版本，由于新增了一个业务字段，所以小猫写了相关的刷数据的接口，在下班之前调用开始刷历史数据。

考虑到表的数据量比较大，一次性把数据全部读取出来然后在内存里面去刷新数据肯定是不现实的，所以小猫采用了分页查询的方式依次根据条件查询出结果，然后进行表数据的重置。没想到的是，数据量太大，分页的深度越来越深，渐渐地，慢查询也就暴露出来了。

强迫症小猫瞬间睡意全无，翻起来打开电脑开始解决问题。

那么为什么用使用limit之后会出现慢查询呢？接下来老猫和大家一起来剖析一下吧。

limit分页为什么会变慢？

在解释为什么慢之前，咱们来重现一下小猫的慢查询场景。咱们从实际的例子推进。

做个小实验

假设我们有一张这样的业务表，商品Product表。具体的建表语句如下：

CREATE TABLE `Product` (

  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,

  `type` tinyint(3) unsigned NOT NULL DEFAULT '1' ,

  `spuCode` varchar(50) NOT NULL DEFAULT '' ,

  `spuName` varchar(100) NOT NULL DEFAULT '' ,

  `spuTitle` varchar(300) NOT NULL DEFAULT '' ,

  `channelId` bigint(20) unsigned NOT NULL DEFAULT '0',

  `sellerId` bigint(20) unsigned NOT NULL DEFAULT '0'

  `mallSpuCode` varchar(32) NOT NULL DEFAULT '',

  `originCategoryId` bigint(20) unsigned NOT NULL DEFAULT '0' ,

  `originCategoryName` varchar(50) NOT NULL DEFAULT '' ,

  `marketPrice` decimal(10,2) unsigned NOT NULL DEFAULT '0.00',

  `status` tinyint(3) unsigned NOT NULL DEFAULT '1' ,

  `isDeleted` tinyint(3) unsigned NOT NULL DEFAULT '0',

  `timeCreated` datetime(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3),

  `timeModified` datetime(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3) ,

  PRIMARY KEY (`id`) USING BTREE,

  UNIQUE KEY `uk_spuCode` (`spuCode`,`channelId`,`sellerId`),

  KEY `idx_timeCreated` (`timeCreated`),

  KEY `idx_spuName` (`spuName`),

  KEY `idx_channelId_originCategory` (`channelId`,`originCategoryId`,`originCategoryName`) USING BTREE,

  KEY `idx_sellerId` (`sellerId`)

) ENGINE=InnoDB AUTO_INCREMENT=12553120 DEFAULT CHARSET=utf8mb4 COMMENT='商品表'

从上述建表语句中我们发现timeCreated走普通索引。接下来我们根据创建时间来执行一下分页查询：

当为浅分页的时候，如下：

select * from Product where timeCreated > "2020-09-12 13:34:20" limit 0,10

此时执行的时间为： "executeTimeMillis":1

当调整分页查询为深度分页之后，如下：

select * from Product where timeCreated > "2020-09-12 13:34:20" limit 10000000,10

此时深度分页的查询时间为： "executeTimeMillis":27499

此时看到这里，小猫的场景已经重现了，此时深度分页的查询已经非常耗时。

剖析一下原因

简单回顾一下普通索引和聚簇索引

我们来回顾一下普通索引和聚簇索引（也有人叫做聚集索引）的关系。

大家可能都知道Mysql底层用的数据结构是B+tree（如果有不知道的伙伴可以自己了解一下为什么mysql底层是B+tree）,B+tree索引其实可以分为两大类，一类是聚簇索引，另外一类是非聚集索引（即普通索引）。

（1）聚簇索引：InnoDB存储表是索引组织表，聚簇索引就是一种索引组织形式，聚簇索引叶子节点存放表中所有行数据记录的信息，所以经常会说索引即数据，数据即索引。当然这个是针对聚簇索引。

由图可知在执行查询的时候，从根节点开始共经历了3次查询即可找到真实数据。倘若没有聚簇索引的话，就需要在磁盘上进行逐个扫描，直至找到数据为止。显然，索引会加快查询速度，但是在写入数据的时候，由于需要维护这颗B+树，因此在写入过程中性能也会下降。

（2）普通索引：普通索引在叶子节点并不包含所有行的数据记录，只是会在叶子节点存本身的键值和主键的值，在检索数据的时候，通过普通索引子节点上的主键来获取想要找到的行数据记录。

由图可知流程，首先从非聚簇索引开始寻找聚簇索引，找到非聚簇索引上的聚簇索引后，就会到聚簇索引的B+树上进行查询，通过聚簇索引B+树找到完整的数据。该过程比较专业的叫法也被称为“回表”。

看一下实际深度分页执行过程

有了以上的知识基础我们再来回过头看一下上述深度分页SQL的执行过程。上述的查询语句中idx_timeCreated显然是普通索引，咱们结合上述的知识储备点，其深度分页的执行就可以拆分为如下步骤：

1、通过普通索引idx_timeCreated，过滤timeCreated，找到满足条件的记录ID；

2、通过ID，回到主键索引树，找到满足记录的行，然后取出展示的列（回表）；

3、扫描满足条件的10000010行，然后扔掉前10000000行，返回。

结合看一下执行计划：

原因其实很清晰了：显然，导致这句SQL速度慢的问题出现在第2步。其中发生了10000010次回表，这前面的10000000条数据完全对本次查询没有意义，但是却占据了绝大部分的查询时间。

再深入一点从底层存储来看，数据库表中行数据、索引都是以文件的形式存储到磁盘(硬盘)上的，而硬盘的速度相对来说要慢很多，存储引擎运行sql语句时，需要访问硬盘查询文件，然后返回数据给服务层。当返回的数据越多时，访问磁盘的次数就越多，就会越耗时。

替换limit分页的一些方案。

上述我们其实已经搞清楚深度分页慢的原因了，总结为“无用回表次数过多”。

那怎么优化呢？相信大家应该都已经知道了，其核心当然是减少无用回表次数了。

有哪些方式可以帮助我们减少无用回表次数呢？

子查询法

思路：如果把查询条件，转移回到主键索引树，那就不就可以减少回表次数了。所以，咱们将实际的SQL改成下面这种形式：

select * FROM Product where id >= (select p.id from Product p where p.timeCreated > "2020-09-12 13:34:20" limit 10000000, 1) LIMIT 10;

测试一下执行时间： "executeTimeMillis":2534

我们可以明显地看到相比之前的27499，时间整整缩短了十倍，在结合执行计划观察一下。

我们综合上述的执行计划可以看出，子查询 table p查询是用到了idx_timeCreated索引。首先在索引上拿到了聚集索引的主键ID,省去了回表操作，然后第二查询直接根据第一个查询的 ID往后再去查10个就可以了!

显然这种优化方式是有效的。

使用inner join方式进行优化

这种优化的方式其实和子查询优化方法如出一辙，其本质优化思路和子查询法一样。我们直接来看一下优化之后的SQL：

select * from Product p1 inner join (select p.id from Product p where p.timeCreated > "2020-09-12 13:34:20" limit 10000000,10) as p2 on p1.id = p2.id

测试一下执行的时间： "executeTimeMillis":2495

咱们发现和子查询的耗时其实差不多，该思路是先通过idx_timeCreated二级索引树查询到满足条件的主键ID，再与原表通过主键ID内连接，这样后面直接走了主键索引了，同时也减少了回表。

上面两种方式其核心优化思想都是减少回表次数进行优化处理。

标签记录法（锚点记录法）

我们再来看下一种优化思路，上述深度分页慢原因我们也清楚了，一次性查询的数据太多也是问题，所以我们从这个点出发去优化，每次查询少量的数据。那么我们可以采用下面那种锚点记录的方式。类似船开到一个地方短暂停泊之后继续行驶，那么那个停泊的地方就是抛锚的地方，老猫喜欢用锚点标记来做比方，当然看到网上有其他的小伙伴称这种方式为标签记录法。其实意思也都差不多。

这种方式就是标记一下上次查询到哪一条了，下次再来查的时候，从该条开始往下扫描。我们直接看一下SQL：

select * from Product p where p.timeCreated > "2020-09-12 13:34:20" and id>10000000 limit 10

显然，这种方式非常快，耗时如下： "executeTimeMillis":1

但是这种方式显然是有缺陷的，大家想想如果我们的id不是连续的，或者说不是自增形式的，那么我们得到的数据就一定是不准确的。与此同时咱们也不能跳页查看，只能前后翻页。

当然存在相同的缺陷，我们还可以换一种写法。

select * from Product p where p.timeCreated > "2020-09-12 13:34:20" and id between 10000000 and 10000010

这种方式也是一样存在上述缺陷，另外的话更要注意的是between ...and语法是两头都是闭区域间。上述语句如果ID连续不断地情况下，咱们最终得到的其实是11条数据，并不是10条数据，所以这个地方还是需要注意的。

存入到es中

上述罗列的几种分页优化的方法其实已经够用了，那么如果数据量再大点的话咋整，那么我们可能就要选择其他中间件进行查询了，当然我们可以选择es。那么es真的就是万能药吗？显然不是。ES中同样存在深度分页的问题，那么针对es的深度分页，那么又是另外一个故事了，这里咱们就不展开了。

写到最后

那么半夜三更爬起来优化慢查询的小猫究竟有没有解决问题呢？电脑前，小猫长吁了一口气，解决了！我们看下小猫的优化方式：

select * from InventorySku isk inner join (select id from InventorySku where inventoryId = 6058 limit 109500,500 ) as d on isk.id = d.id

显然小猫采用了inner join的优化方法解决了当前的问题。

相信小伙伴们后面遇到这类问题也能搞定了。

作者：程序员老猫
来源：juejin.cn/post/7384652811554308147

收起阅读 »

零成本搭建个人图床服务器

综合技术讨论

前言图床服务器是一种用于存储和管理图片的服务器，可以给我们提供将图片上传后能外部访问浏览的服务。这样我们在写文章时插入的说明图片，就可以集中放到图床里，既方便多平台文章发布，又能统一管理和备份。当然下面通过在 GitHub 上搭建的图床，不光不用成本，而且...

继续阅读 »

前言

图床服务器是一种用于存储和管理图片的服务器，可以给我们提供将图片上传后能外部访问浏览的服务。这样我们在写文章时插入的说明图片，就可以集中放到图床里，既方便多平台文章发布，又能统一管理和备份。

当然下面通过在 GitHub 上搭建的图床，不光不用成本，而且还能上传视频或音乐。操作方法和以前在 GitHub 上搭建静态博客类似，但是中间会多一些一些工具介绍和技巧。

流程

创建仓库

设置仓库

连接仓库

应用 Typora

创建仓库

创建仓库和平时的代码托管一样，添加一个 public 权限仓库，用默认的 main 分支。当然也可以提前创建一个目录，但是根目录最好有一个 index.html。

设置仓库

设置仓库主要是添加提交 Token，和配置 GitHub Pages 参数。而这两小步的设置，在前面文章 "Hexo 博客搭建" 有比较详细介绍，所以这里就稍微文字带过了。

Token 生成

登陆 GitHub -> Settings -> Developer settings -> Personal access tokens -> Tokens (classic)，然后点击 "Generate new token"，填写备注和过期时间，权限主要勾选 "repo"、"workflow"、"user"。最后生成 "ghp_" 前缀的字符串就是 Token 了，复制并保存下来。

GitHub Pages 配置

进入仓库页 -> Settings -> Pages，设置 Branch，指定仓库的分支和分支根目录，Source 选择 "Deploy from a branch"，最后刷新或者重新进入，把访问链接地址复制保存下来。

连接仓库

连接可以除了 API 方式，也可以用第三方的工具，比如 "PicGo"。工具位置自行搜索哈，下面以他为例，演示工具的连接配置、文件上传和访问测试。

连接配置

找到 "图床设置" -> "GitHub"，下面主要填写仓库名（需带上账户名），分支名（默认 main 即可），Token（上面生成保存下来的），存储路径（后带斜杠）可以填写已存在，如果不存在则在仓库根目录下新建。

文件上传

文件格式除了下面指定的如 Markdown、HTML、URL 外，还能上传图片音乐视频等（亲测有效）。点击 "上传区"，将文件直接拖动到该窗口，提示上传成功后，进入 GitHub 仓库下查看是否存在。

访问测试

访问就是能将仓库里的图片或视频以外链的方式展示，就像将文件放在云平台的存储桶一样。将前面 GitHub Pages 开启的链接复制下来，然后拼接存储路径和文件名就可以访问了。

应用 Typora

Typora 通过 PicGo 软件自动上传图片到 GitHub 仓库中。打开 Typora 的文件 -> 偏好设置 -> 图像 -> 上传图片 -> 配置 PicGo 路径，然后指定一下 PicGo 的安装位置。

开始使用

可以点击 "验证图片上传选项"，验证成功就代表已经将 Typora 的图标上传到仓库，也可以直接将图片复制到当前 md 文档位置。

![image-20240608145607117](https://raw.githubusercontent.com/z11r00/zd_image_bed/main/img/image-20240608145607117.png)

上传成功后会将返回一个如上面的远程链接，并且无法打开和显示，这是就要在 PicGo 工具的图床设置中。将自己 GitHUb 上的域名设定为自定义域名，格式 "域名 / 仓库名", 在 Typora 上传图片后重启就可展示了。

作者：北桥苏
来源：juejin.cn/post/7384320850722553867

收起阅读 »

12306全球最大票务系统与Gemfire介绍

综合技术讨论

全球最大票务系统自2019年12月12日发售春运首日车票，截至2020年1月9日，12306全渠道共发售车票4.12亿张，日均售票能力达到了2000万张，平均一年售出30亿张火车票，也就是说12306已经发展成全球交易量最大的实时票务系统。 12306发布数...

继续阅读 »

全球最大票务系统

自2019年12月12日发售春运首日车票，截至2020年1月9日，12306全渠道共发售车票4.12亿张，日均售票能力达到了2000万张，平均一年售出30亿张火车票，也就是说12306已经发展成全球交易量最大的实时票务系统。

12306发布数据显示，2020年春运期间，40天的春运期间，12306最高峰日网站点击量为1495亿次，这相当于每个中国人一天在12306上点击了100次，平均每秒点击量为170多万次。而全球访问量最大的搜索引擎网站， 谷歌日访问量也不过是56亿次，一个12306的零头。 再看一下大家习惯性做对比的淘宝，2019年双十一当天，淘宝的日活跃用户为4.76亿，相当于每个人也在淘宝上点击300多次，才能赶上12306的峰值点击量。

上亿人口，40天时间，30亿次出行，12306之前，全球没有任何一家公司和产品接手过类似的任务。这个网站是在数亿人苛刻的目光中，做一件史无前例却又必须成功的事情。

历史发展

10年前铁道部顶着重重压力决心要解决买车票这个全民难题，2010年春运首日12306网站开通并试运行，2011年12月23日网站正式上线，铁道部兑现了让网络售票覆盖所有车次的承诺，不料上线第一天，全民蜂拥而入，流量暴增，网站宕机，除此之外，支付流程繁琐支付渠道单一，各种问题不断涌现，宕机可能会迟到，但永远不会缺席，12306上线的第二年，网站仍然难以支撑春运的巨大流量，很多人因为网站的各种问题导致抢票失败，甚至耽误了去线下买票的最佳时机，铁道部马不解鞍听着批评，一次又一次给12306改版升级，这个出生的婴儿几乎是在骂声中长大的。2012年9月，中秋国庆双节来临之前，12306又一次全站崩溃，本来大家习以为常的操作，却被另一个消息彻底出炉，这次崩溃之前，铁道部曾花了3.3亿对系统进行升级，中标的不是IBM惠普EMC等大牌厂商，而是拥有国字号背景的太极股份和同方股份，铁道部解释说3.3亿已经是最低价了，但没人能听进去，大家只关心他长成了什么样，没人关心他累不累，从此之后，铁道部就很少再发声明了。

2013年左右，各种互联网公司表示我行我上，开发了各种抢票网站插件。当时360浏览器靠免费抢票创下国内浏览器使用率的最高纪录，百度猎豹搜狗UC也纷纷加入，如今各类生活服务APP，管他干啥的，都得植入购票抢票功能和服务，12306就这样被抢票软件围捕了。不同的是，过去抢票是免费，现在由命运馈赠的火车票，都在明面上标好了价格，比如抢票助力包，一般花钱买10元5份，也可以邀请好友砍一刀，抢票速度上，分为低快高级光速VIP等等速度，等级越高就越考验钱包。

2017年12306上线了选座和接续换乘功能，从此爱人可以自由抢靠窗座，而且夹在两人之间坐立不安，换乘购票也变得简单。2019年上线官方捡漏神器候补购票功能，可以代替科技黄牛，自动免费为旅客购买退票余票。......

阿里云当时主要是给他们提供虚拟机服务，主要是做IaaS这一层，就是基础设施服务这一层，2012年熟悉阿里云历史的应该都知道，那个时候阿里云其实还是很小的一个厂商，所以不要盲目夸大阿里云在里面起的作用。

技术难点

1、巨大流量，高请求高并发。

2、抢票流量。每天放出无数个爬虫机器人，模拟真人登陆12306，不间断的刷新网站余票，这会滋生很多的灰色流量，也会给12306本身的话造成非常大的压力。

3、动态库存。电商的任务是购物结算，库存是唯一且稳定的，而12306每卖出一张车票，不仅要减少首末站的库存，还要同时减少一趟列车所有过路站的。

以北京西到深圳福田的G335次高铁为例，表面上看起来中间有16个车站及16个SKU，但实际上不同的起始站都会产生新的SKU。我们将所有起始和终点的可能性相加，就是16+15+14一直加到一，一共136个SKU，而每种票对应三种座位，所以一共是408个商品。然后更复杂的是用户每买一张票会影响其他商品的库存，假如用户买了一张北京西的高碑店东的票，那北京始发的16个SKU库存都要减一，但是它并不影响非北京始发车票的库存，
更关键的是这些SKU间有的互斥，有的不互斥，优先卖长的还是优先卖短程的呢，每一次火车票的出售都会引发连锁变化，让计算量大大增加，如果再叠加当前的选座功能，计算数量可能还要再翻倍，而这些计算数据需要在大量购票者抢票的数秒，甚至数毫秒内完成，难度可想而知有多多大。

4、随机性。你永远都不知道哪一个人会在哪一天，去到哪一个地点，而双十一的预售和发货，其实已经提前准备了一个月，甚至几个月，并不是集中在双十一那天爆发的那一天。所以必须要有必须要有动态扩容的能力。

读扩散和写扩散

上面说的动态库存，就比如 A -> B -> C -> D 共 4 个车站，假如乘客买了 B -> C 的车票，那么同时会影响到 A->C，A->D，B->C，B->D，涉及了多个车站的排列组合，这里计算是比较耗费性能的。

那么这里就涉及到了 “读扩散” 和 “写扩散” 的问题，在 12 年的时候，12306 使用的就是读扩散，也就是在扣减余票库存的时候，直接扣减对应车站，而在查询的时候，进行动态计算。而写扩散就是在写的时候，就动态计算每个车站应该扣除多少余票库存，在查询的时候直接查即可。

12306本身他其实是读的流量远远大于写的流量，我个人是认为写扩散其实会更好一点。

Pivotal Gemfire

Redis 在互联网公司中使用的是比较多的，而在银行、12306 很多实时交易的系统中，很多采用 Pivotal Gemfire作为解决方案。Redis 是开源的缓存解决方案，而 Pivotal Gemfire 是商用的，我们在互联网项目中为什么使用 Redis 比较多呢，就是因为 Redis 是开源的，不要钱，开源对应的也就是稳定性不是那么的强，并且开源社区也不会给你提供解决方案，毕竟你是白嫖的，而在银行以及 12306 这些系统中，它们对可靠性要求非常的高，因此会选择商用的 Pivotal Gemfire，不仅性能强、高可用，而且 Gemfire 还会提供一系列的解决方案，据说做到了分布式系统中的 CAP。

12306 的性能瓶颈就在于余票的查询操作上，上边已经说了，12306 是采用读扩散，也就是客户买票之后，扣减库存只扣减对应车站之间的余票库存，在读的时候，再来动态的计算每个站点应该有多少余票，因此读性能是 12306 的性能瓶颈。

当时 12306 也尝试了许多其他的解决方案，比如 cassandra 和 mamcached，都扛不住查询的流量，而使用 Gemfire 之后扛住了流量，因此就使用了 Gemfire。2012年6月一期先改造12306的主要瓶颈——余票查询系统。 9月份完成代码改造，系统上线。2012年国庆，又是网上订票高峰期间，大家可以显著发现，可以登录12306，虽然还是很难订票，但是查询余票很快。2012年10月份，二期用GemFire改造订单查询系统(客户查询自己的订单记录)。2013年春节，又是网上订票高峰期间，大家可以显著发现，可以登录12306，虽然还是很难订票，但是查询余票很快，而且查询自己的订票和下订单也很快。

技术改造之后，在只采用10几台X86服务器实现了以前数十台小型机的余票计算和查询能力，单次查询的最长时间从之前的15秒左右下降到0.2秒以下，缩短了75倍以上。 2012年春运的极端高流量并发情况下，系统几近瘫痪。而在改造之后，支持每秒上万次的并发查询，高峰期间达到2.6万个查询/秒吞吐量，整个系统效率显著提高；订单查询系统改造，在改造之前的系统运行模式下，每秒只能支持300-400个查询/秒的吞吐量，高流量的并发查询只能通过分库来实现。改造之后，可以实现高达上万个查询/秒的吞吐量，而且查询速度可以保障在20毫秒左右。新的技术架构可以按需弹性动态扩展，并发量增加时，还可以通过动态增加X86服务器来应对，保持毫秒级的响应时间。

通过云计算平台虚拟化技术，将若干X86服务器的内存集中起来，组成最高可达数十TB的内存资源池，将全部数据加载到内存中，进行内存计算。计算过程本身不需要读写磁盘，只是定期将数据同步或异步方式写到磁盘。GemFire在分布式集群中保存了多份数据，任何一台机器故障，其它机器上还有备份数据，因此通常不用担心数据丢失，而且有磁盘数据作为备份。GemFire支持把内存数据持久化到各种传统的关系数据库、Hadoop库和其它文件系统中。大家知道，当前计算架构的瓶颈在存储，处理器的速度按照摩尔定律翻番增长，而磁盘存储的速度增长很缓慢，由此造成巨大高达10万倍的差距。这样就很好理解GemFire为什么能够大幅提高系统性能了。Gemfire 的存储和计算都在一个地方，它的存储和实时计算的性能目前还没有其他中间件可以取代。

但是 Gemfire 也存在不足的地方，对于扩容的支持不太友好的，因为它里边有一个 Bucket 类似于 Topic 的概念，定好 Bucket 之后，扩容是比较难的，在 12306 中，也有过测试，需要几十个T的内存就可以将业务数据全部放到内存中来，因此直接将内存给加够，也就不需要很频繁的扩容。

12306业务解决方案

当然在优化中，我们靠改变架构加机器可以提升速度效率，剩下的也需要业务上的优化。

1、验证码。如果说是淘宝啊这种网站，他用这种验证码，用12306的验证码，可能大家都不会用了，对不对，但是12306他比较特殊，因为铁路全国就他一家，所以说他可以去做这个事情，他不用把用户体验放在第一位
。他最高的优先级是怎么把票给需要的人手上。

当然这个利益的确是比较大，所以也会采用这种人工打码的方式，可以雇一批大学生去做这个验证码识别。

2、候补。候补车票其实相当于整个系统上，它是一个异步的过程，你可以在这里排队，后面的话也没有抢到票，后面再通知你。

3、分时段售票。对于抢票来说，瞬时抢票会导致对服务器有瞬间很大的压力，因此从业务设计上来说需要将抢票的压力给分散开，比如今天才开启抢15天之后的车票。2点抢票，3点抢票等等。

总结

只有程序员才知道，一个每天完成超过1500万个订单，承受近1500亿次点击的系统到底有多难，在高峰阶段的时候，平均每秒就要承受170多万次的点击，面对铁路运输这种特殊的运算模式，也能够保证全国人民在短时间内抢到回家的票，12306就是在无数国人的苛责和质疑中，创造了一个世界的奇迹。

12306除了技术牛，还有着自己的人情关怀，系统会自动识别购票者的基本信息，如果识别出订单里有老人会优先给老人安排下铺儿童和家长会尽量安排在邻近的位置，12306 在保证所有人都能顺利抢到回家的票的同时，还在不断地增加更多的便利，不仅在乎技术问题，更在乎人情异味，12306可能还不够完美，但他一直在努力变得更好，为我们顺利回家提供保障，这是背后无数程序员日夜坚守的结果，我们也应该感谢总设计师单杏花女士，所以你可以调侃，可以批评，但不能否认12306背后所做出的所有努力！

作者：jack_xu
来源：juejin.cn/post/7381747852831653929

收起阅读 »

秒懂双亲委派机制

Java

前言最近有位小伙伴问了我一个问题：JDBC为什么会破坏双亲委派机制？这个问题挺有代表性的。双亲委派机制是Java中非常重要的类加载机制，它保证了类加载的完整性和安全性，避免了类的重复加载。这篇文章就跟大家一起聊聊，Java中类加载的双亲委派机制到底是怎...

继续阅读 »

前言

最近有位小伙伴问了我一个问题：JDBC为什么会破坏双亲委派机制？

这个问题挺有代表性的。

双亲委派机制是Java中非常重要的类加载机制，它保证了类加载的完整性和安全性，避免了类的重复加载。

这篇文章就跟大家一起聊聊，Java中类加载的双亲委派机制到底是怎么回事，有哪些破坏双亲委派机制的案例，为什么要破坏双亲委派机制，希望对你会有所帮助。

1 为什么要双亲委派机制？

我们的Java在运行之前，首先需要把Java代码转换成字节码，即class文件。

然后JVM需要把字节码通过一定的方式加载到内存中的运行时数据区。

这种方式就是类加载器（ClassLoader）。

再通过加载、验证、准备、解析、初始化这几个步骤完成类加载过程，然后再由jvm执行引擎的解释器和JIT即时编译器去将字节码指令转换为本地机器指令进行执行。

我们在使用类加载器加载类的时候，会面临下面几个问题：

如何保证类不会被重复加载？类重复加载会出现很多问题。

类加载器是否允许用户自定义？

如果允许用户自定义，如何保证类文件的安全性？

如何保证加载的类的完整性？

为了解决上面的这一系列的问题，我们必须要引入某一套机制，这套机制就是：双亲委派机制。

2 什么是双亲委派机制？

接下来，我们看看什么是双亲委派机制。

双亲委派机制的基本思想是：当一个类加载器试图加载某个类时，它会先委托给其父类加载器，如果父类加载器无法加载，再由当前类加载器自己进行加载。

这种层层委派的方式有助于保障类的唯一性，避免类的重复加载，并提高系统的安全性和稳定性。

在Java中默认的类加载器有3层：

启动类加载器（Bootstrap Class Loader）：负责加载 %JAVA_HOME%/jre/lib 目录下的核心Java类库，比如：rt.jar、charsets.jar等。它是最顶层的类加载器，通常由C++编写。

扩展类加载器（Extension Class Loader）：负责加载Java的扩展库，一般位于/lib/ext目录下。

应用程序类加载器（Application Class Loader）：也称为系统类加载器，负责加载用户类路径（ClassPath）下的应用程序类。

用一张图梳理一下，双亲委派机制中的3种类加载器的层次关系：

但这样不够灵活，用户没法控制，加载自己想要的一些类。

于是，Java中引入了自定义类加载器。

创建一个新的类并继承ClassLoader类，然后重写findClass方法。

该方法主要是实现从那个路径读取 ar包或者.class文件，将读取到的文件用字节数组来存储，然后可以使用父类的defineClass来转换成字节码。

如果想破坏双亲委派的话，就重写loadClass方法，否则不用重写。

类加载器的层次关系改成：

双亲委派机制流程图如下：

具体流程大概是这样的：

需要加载某个类时，先检查自定义类加载器是否加载过，如果已经加载过，则直接返回。

如果自定义类加载器没有加载过，则检查应用程序类加载器是否加载过，如果已经加载过，则直接返回。

如果应用程序类加载器没有加载过，则检查扩展类加载器是否加载过，如果已经加载过，则直接返回。

如果扩展类加载器没有加载过，则检查启动类加载器是否加载过，如果已经加载过，则直接返回。

如果启动类加载器没有加载过，则判断当前类加载器能否加载这个类，如果能加载，则加载该类，然后返回。

如果启动类加载器不能加载该类，则交给扩展类加载器。扩展类加载器判断能否加载这个类，如果能加载，则加载该类，然后返回。

如果扩展类加载器不能加载该类，则交给应用程序类加载器。应用程序类加载器判断能否加载这个类，如果能加载，则加载该类，然后返回。

如果应用程序类加载器不能加载该类，则交给自定义类加载器。自定义类加载器判断能否加载这个类，如果能加载，则加载该类，然后返回。

如果自定义类加载器，也无法加载这个类，则直接抛ClassNotFoundException异常。

这样做的好处是：

保证类不会重复加载。加载类的过程中，会向上问一下是否加载过，如果已经加载了，则不会再加载，这样可以保证一个类只会被加载一次。

保证类的安全性。核心的类已经被启动类加载器加载了，后面即使有人篡改了该类，也不会再加载了，防止了一些有危害的代码的植入。

3 破坏双亲委派机制的场景

既然Java中引入了双亲委派机制，为什么要破坏它呢？

答：因为它有一些缺点。

下面给大家列举一下，破坏双亲委派机制最常见的场景。

3.1 JNDI

JNDI是Java中的标准服务，它的代码由启动类加载器去加载。

但JNDI要对资源进行集中管理和查找，它需要调用由独立厂商在应用程序的ClassPath下的实现了JNDI接口的代码，但启动类加载器不可能“认识”这些外部代码。

为了解决这个问题，Java后来引入了线程上下文类加载器（Thread Context ClassLoader）。

这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置。

如果创建线程时没有设置，他将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。

有了线程上下文加载器，JNDI服务就可以使用它去加载所需要的SPI代码，也就是父类加载器请求子类加载器去完成类加载的动作，这样就打破了双亲委派机制。

3.2 JDBC

原生的JDBC中Driver驱动本身只是一个接口，并没有具体的实现，具体的实现是由不同数据库类型去实现的。

例如，MySQL的mysql-connector.jar中的Driver类具体实现的。

原生的JDBC中的类是放在rt.jar包，是由启动类加载器进行类加载的。

在JDBC中需要动态去加载不同数据库类型的Driver实现类，而mysql-connector.jar中的Driver实现类是用户自己写的代码，启动类加载器肯定是不能加载的，那就需要由应用程序启动类去进行类加载。

为了解决这个问题，也可以使用线程上下文类加载器（Thread Context ClassLoader）。

3.3 Tomcat容器

Tomcat是Servlet容器，它负责加载Servlet相关的jar包。

此外，Tomcat本身也是Java程序，也需要加载自身的类和一些依赖jar包。

这样就会带来下面的问题：

一个Tomcat容器下面，可以部署多个基于Servlet的Web应用，但如果这些Web应用下有同名的Servlet类，又不能产生冲突，需要相互独立加载和运行才行。

但如果多个Web应用，使用了相同的依赖，比如：SpringBoot、Mybatis等。这些依赖包所涉及的文件非常多，如果全部都独立，可能会导致JVM内存不足。也就是说，有些公共的依赖包，最好能够只加载一次。

我们还需要将Tomcat本身的类，跟Web应用的类隔离开。

这些原因导致，Tomcat没有办法使用传统的双亲委派机制加载类了。

那么，Tomcat加载类的机制是怎么样的？

CommonClassLoader：是Tomcat最基本的类加载器，它加载的类可以被Tomcat容器和Web应用访问。

CatalinaClassLoader：是Tomcat容器私有的类加载器，加载类对于Web应用不可见。

SharedClassLoader：各个Web应用共享的类加载器，加载的类对于所有Web应用可见，但是对于Tomcat容器不可见。

WebAppClassLoader：各个Web应用私有的类加载器，加载类只对当前Web应用可见。比如不同war包应用引入了不同的Spring版本，这样能加载各自的Spring版本，相互隔离。

3.4 热部署

由于用户对程序动态性的追求，比如：代码热部署、代码热替换等功能，引入了OSGi（Open Service Gateway Initiative）。

OSGi中的每一个模块（称为Bundle）。

当程序升级或者更新时，可以只停用、重新安装然后启动程序的其中一部分，对企业来说这是一个非常诱人的功能。

OSGi的Bundle类加载器之间只有规则，没有固定的委派关系。

各个Bundle加载器是平级关系。

不是双亲委派关系。

作者：苏三说技术
来源：juejin.cn/post/7383894631312769074

收起阅读 »

ThreadLocal不香了，ScopedValue才是王道

Java

ThreadLocal的缺点在Java中，当多个方法要共享一个变量时，我们会选择使用ThreadLocal来进行共享，比如：以上代码将字符串“dadudu”通过设置到ThreadLocal中，从而可以做到在main()方法中赋值，在a(...

继续阅读 »

ThreadLocal的缺点

在Java中，当多个方法要共享一个变量时，我们会选择使用ThreadLocal来进行共享，比如：以上代码将字符串“dadudu”通过设置到ThreadLocal中，从而可以做到在main()方法中赋值，在a()、b()方法中获取值，从而共享值。

生命在于思考，我们来想想ThreadLocal有什么缺点：

第一个就是权限问题，也许我们只需要在main()方法中给ThreadLocal赋值，在其他方法中获取值就可以了，而上述代码中a()、b()方法都有权限给ThreadLocal赋值，ThreadLocal不能做权限控制。
第二个就是内存问题，ThreadLocal需要手动强制remove，也就是在用完ThreadLocal之后，比如b()方法中，应该调用其remove()方法，但是我们很容易忘记调用remove()，从而造成内存浪费。

ScopedValue

而JDK21中的新特性ScopedValue能不能解决这两个缺点呢？我们先来看一个ScopedValue的Demo：

首先需要通过ScopedValue.newInstance()生成一个ScopedValue对象，然后通过ScopedValue.runWhere()方法给ScopedValue对象赋值，runWhere()的第三个参数是一个lambda表达式，表示作用域，比如上面代码就表示：给NAME绑定值为"dadudu"，但是仅在调用a()方法时才生效，并且在执行runWhere()方法时就会执行lambda表达式。

比如上面代码的输出结果为：

从结果可以看出在执行runWhere()时会执行a()，a()方法中执行b()，b()执行完之后返回到main()方法执行runWhere()之后的代码，所以，在a()方法和b()方法中可以拿到ScopedValue对象所设置的值，但是在main()方法中是拿不到的（报错了），b()方法之所以能够拿到，是因为属于a()方法调用栈中。

所以在给ScopedValue绑定值时都需要指定一个方法，这个方法就是所绑定值的作用域，只有在这个作用域中的方法才能拿到所绑定的值。

ScopedValue也支持在某个方法中重新开启新的作用域并绑定值，比如：

以上代码中，在a()方法中重新给ScopedValue绑定了一个新值“xiaodudu”，并指定了作用域为c()方法，所以c()方法中拿到的值为“xiaodudu”，但是b()中仍然拿到的是“dadudu”，并不会受到影响，以上代码的输出结果为：

甚至如果把代码改成：

以上代码在a()方法中有两处调用了c()方法，我想大家能思考出c1和c2输出结果分别是什么：

所以，从以上分析可以看到，ScopedValue有一定的权限控制：就算在同一个线程中也不能任意修改ScopedValue的值，就算修改了对当前作用域（方法）也是无效的。另外ScopedValue也不需要手动remove，关于这块就需要分析它的实现原理了。

实现原理

大家先看下面代码，注意看下注释：

执行main()方法时，main线程执行过程中会执行runWhere()方法三次，而每次执行runWhere()时都会生成一个Snapshot对象，Snapshot对象中记录了所绑定的值，而Snapshot对象有一个prev属性指向上一次所生成的Snapshot对象，并且在Thread类中新增了一个属性scopedValueBindings，专门用来记录当前线程对应的Snapshot对象。

比如在执行main()方法中的runWhere()时：

会先生成Snapshot对象1，其prev为null，并将Snapshot对象1赋值给当前线程的scopedValueBindings属性，然后执行a()方法
在执行a()方法中的runWhere()时，会先生成Snapshot对象2，其prev为Snapshot对象1，并将Snapshot对象2赋值给当前线程的scopedValueBindings属性，使得在执行b()方法时能从当前线程拿到Snapshot对象2从而拿到所绑定的值，runWhere()内部在执行完b()方法后会取prev，从而取出Snapshot对象1，并将Snapshot对象1赋值给当前线程的scopedValueBindings属性，然后继续执行a()方法后续的逻辑，如果后续逻辑调用了get()方法，则会取当前线程的scopedValueBindings属性拿到Snapshot对象1，从Snapshot对象1中拿到所绑定的值就可以了，而对于Snapshot对象2由于没有引用则会被垃圾回收掉。

所以，在用ScopedValue时不需要手动remove。

好了，关于ScopedValue就介绍到这啦，下次继续分享JDK21新特性，欢迎大家关注我的公众号：Hoeller，第一时间接收我的原创技术文章，谢谢大家的阅读。

作者：IT周瑜
来源：juejin.cn/post/7287241480770928655

收起阅读 »

开发经理：谁在项目里面用Stream. paraller()直接gun

Java

大家好，我是小玺，今天给大家分享一下项目中关于Stream.parallel() 碰到的坑。 Stream.parallel() 是Java 8及以上版本引入的Stream API中的一个方法，它用于将一个串行流转换为并行流。并行流可以在多个处理器上同时执行操...

继续阅读 »

大家好，我是小玺，今天给大家分享一下项目中关于Stream.parallel() 碰到的坑。

Stream.parallel() 是Java 8及以上版本引入的Stream API中的一个方法，它用于将一个串行流转换为并行流。并行流可以在多个处理器上同时执行操作，从而显著提高对大量数据进行处理的性能。

踩坑日记

某个大型项目，晚上十一点多有个用户对小部分数据进行某项批量操作后，接口大半天没有反应最后返回超时报错，但是过了一段时间后，出现了部分数据被修改成功，部分数据则没有反应。用户立马跳起来，打电话投诉到公司领导层，于是乎领导层对上至开发经理和PM，下至小开发进行会议批斗，要求马上排查并解决问题，毕竟项目这么大，当初也是要求测试做过压测的，怎么出现这么大的生产事故。

于是乎开发和实施运维分头行事，开发人员排查问题，实施人员先把问题数据维护好，不能应该用户使用。一群开发也是很疑惑，开发和测试环境都没法复现出问题，简单过一下代码也没看出个所以然，由于时间问题，不得不呼叫一手开发经理帮忙看看，开发经理后台接口看完Stream.parallel()进行的操作代码立马就炸了，git看了下提交人【会笑】,把这个开发从头到脚喷了一遍。

在对会笑单独进行了长达半小时的“耐心教育”后(ps:问题安排另一名开发同事修复)，开发经理给团队的所有后端开发人员又都教育了一遍。原来会笑在用并行流的时候，没有考虑线程池配置和事务问题，把一堆数据进行了批量更新，Stream.parallel()并行流默认使用的是ForkJoinPool.commonPool()作为线程池，该线程池默认最大线程数就是CPU核数。

雀食对于一些初中级开发来说，开发过程中往往喜欢用一些比较新颖的写法来实现但是对新语法又是一知半解的，Stream.parallel()作为Java的新特性，也就成了其中一个反面教材。如果操作数据量不大的情况，其实没有必要用到Stream.parallel()，效率反而会变差。

注意事项

线程安全：并行流并不能保证线程安全性，因此，如果流中的元素是共享资源或操作本身不是线程安全的，你需要确保正确同步或使用线程安全的数据结构。

数据分区：Java的并行流机制会自动对数据进行分区，但在某些情况下，数据分区的开销可能大于并行带来的收益，特别是对于小规模数据集。

效率考量：并非所有的流操作都能从并行化中受益，有些操作（如短流操作或依赖于顺序的操作）并行执行反而可能导致性能下降。而且，过多的上下文切换也可能抵消并行带来的优势。

资源消耗：并行流默认使用的线程池大小可能与机器的实际物理核心数相适应，但也可能与其他并发任务争夺系统资源。

结果一致性：并行流并不保证执行的顺序性，也就是说，如果流操作的结果依赖于元素的处理顺序，则不应该使用并行流。

事务处理：在涉及到事务操作时，通常需要避免在并行流中直接处理，如上述例子所示，应当将事务边界放在单独的服务方法内，确保每个线程内的事务独立完成。

Tips：线程数可以通JVM启动参数-Djava.util.concurrent.ForkJoinPool.common.parallelism=20进行修改

作者：小玺
来源：juejin.cn/post/7355431482687864883

收起阅读 »