基于 ShardingSphere 的分布式数据库负载均衡架构搭建实战

news2025/1/5 10:00:31

本文主要分为 3 部分，将依次介绍：

  • 基于 ShardingSphere 的分布式数据库「负载均衡架构搭建」要点
  • 结合实际的「用户问题案例」，介绍引入「负载均衡」的影响
  • 介绍并展示 ShardingSphere 分布式数据库在云上的「一站式解决方案」

文章目录

    • ShardingSphere 负载均衡架构搭建要点
      • SharidngSphere-JDBC 负载均衡方案
      • SharidngSphere-Proxy 负载均衡方案
        • 部署架构
        • 负载均衡方案要点
        • 对应用层的建议
          • 执行间隔较长的场景考虑按需创建连接
          • 考虑通过通过连接池管理数据库连接
          • 客户端考虑启用 TCP KeepAlive
    • 用户案例：负载均衡配置不合理造成连接中断的问题
      • 问题描述
      • 问题分析
        • 抓包现象一
        • 抓包现象二
        • 客户端应用与 ELB 配置检查
        • 问题结论
    • 超时模拟实验
      • 搭建负载均衡的 ShardingSphere-Proxy 集群环境
      • 配置 nginx stream
      • 构造 Docker compose
      • 启动环境
      • 模拟客户端基于同连接定时任务
        • 构造客户端延迟执行 SQL
        • 预期结果与客户端运行结果
        • 抓包结果分析
    • ShardingSphere on Cloud 一站式解决方案

ShardingSphere 负载均衡架构搭建要点

Apache ShardingSphere 是一款分布式的数据库生态系统，可以将任意数据库转换为分布式数据库，并通过数据分片、弹性伸缩、加密等能力对原有数据库进行增强。它由 ShardingSphere-JDBC 和 ShardingSphere-Proxy 这 2 款既能够独立部署，又支持混合部署配合使用的产品组成。混合部署架构如下：
在这里插入图片描述

SharidngSphere-JDBC 负载均衡方案

其中，ShardingSphere-JDBC 定位为轻量级 Java 框架，在 Java 的 JDBC 层提供的额外服务。ShardingSphere-JDBC 只是在应用进行数据库操作前增加了计算操作，应用进程仍然是通过数据库驱动直接连接数据库。
因此，用户无须单独考虑 ShardingSphere-JDBC 的负载均衡，只需关注其应用程序本身如何进行负载均衡即可。

SharidngSphere-Proxy 负载均衡方案

部署架构

ShardingSphere-Proxy 定位为透明化的数据库代理端，通过数据库协议，向数据库客户端提供服务。 ShardingSphere-Proxy 作为一个独立部署的进程，在其上层进行负载均衡的参考架构如下：
在这里插入图片描述

负载均衡方案要点

社区有同学详细讨论过如何搭建 ShardingSphere-Proxy 集群，也有同学咨询过 ShardingSphere-Proxy 负载均衡后的行为和想象中不一致的问题：

  • 如何搭建 ShardingSphere-Proxy 集群？ https://github.com/apache/shardingsphere/discussions/12593
  • 客户端发送的请求通过 HAProxy 后没有轮询多个 ShardingSphere-Proxy 实例：https://github.com/apache/shardingsphere/issues/20016

ShardingSphere-Proxy 集群负载均衡的要点：数据库协议本身设计是有状态的。例如连接认证状态、事务状态、预编译语句（Prepared Statement）等。

如果 ShardingSphere-Proxy 上层的负载均衡无法理解数据库协议，则只能选择四层负载均衡代理 ShardingSphere-Proxy 集群，客户端与 ShardingSphere-Proxy 的数据库连接状态由具体的 Proxy 实例维护。
由于连接本身状态维护在一个具体的 Proxy 实例上，四层负载均衡只能做到连接级别的负载均衡。对于同一个数据库连接的多个请求，无法轮询到多个 Proxy 实例执行，即无法做到请求级别的负载均衡。
关于四层负载均衡与七层负载均衡的详细信息，本文不再赘述。

对应用层的建议

理论上，客户端直接连接单个 ShardingSphere-Proxy 与通过负载均衡入口连接 ShardingSphere-Proxy 集群相比，在功能上没有区别。但不同负载均衡的技术实现与配置存在差异。例如，直接连接 ShardingSphere-Proxy 没有限制数据库连接会话保持最长时间，但某些 ELB 产品的四层会话保持最大允许 60 分钟，如果空闲的数据库连接被负载均衡超时关闭，但客户端又对被动的 TCP 连接关闭没有感知，可能会导致应用程序报错。
因此，除了在负载均衡层面进行考虑，客户端本身也可以考虑采取一些措施避免引入负载均衡带来的影响。

执行间隔较长的场景考虑按需创建连接

例如执行间隔 1 小时且执行时间较短的定时作业，如果创建连接单例持续使用，数据库连接在大部分时间都处于空闲状态。如果客户端本身无法感知连接状态的变化，长时间空闲会增加连接状态的不确定性。
对于执行间隔较长的场景，可以考虑按需创建连接，使用完毕后释放。

考虑通过通过连接池管理数据库连接

一般的数据库连接池都具备维护有效连接、剔除失效连接等能力，通过连接池管理数据库连接，可以减少自行维护连接的成本。

客户端考虑启用 TCP KeepAlive

一般客户端都能够支持配置 TCP KeepAlive，例如：

  • MySQL Connector/J 支持配置 autoReconnect 或 tcpKeepAlive，默认不开启；
  • PostgreSQL JDBC Driver 支持配置 tcpKeepAlive，默认不开启。

不过，启用 TCP KeepAlive 的方式也存在一定的限制：

  • 客户端不一定支持配置 TCP KeepAlive 或自动重连；
  • 客户端不打算做任何代码或配置调整；
  • TCP KeepAlive 依赖操作系统实现与配置。

用户案例：负载均衡配置不合理造成连接中断的问题

前段时间有用户反馈，其部署的 ShardingSphere-Proxy 集群通过上层负载均衡对外提供服务，使用过程中，发现应用与 ShardingSphere-Proxy 之间的连接稳定性存在问题。

问题描述

某用户生产环境使用 3 节点 ShardingSphere-Proxy 集群，集群通过某云厂商的 ELB 对应用提供服务。

在这里插入图片描述
其中一个应用是执行定时作业的常驻进程，定时作业执行频率为每小时执行一次，作业逻辑中存在数据库操作。用户反馈，每次定时作业触发时，应用日志中都会出现报错：

send of 115 bytes failed with errno=104 Connection reset by peer

检查 ShardingSphere-Proxy 日志，没有任何异常信息。
该问题仅在执行频率为一小时的定时作业中出现，其他应用访问 ShardingSphere-Proxy 均正常。
由于作业逻辑具备重试机制，每次重试后作业执行都能成功，对原本的业务没有造成影响。

问题分析

应用显示报错的原因非常明确：客户端向一个已经关闭的 TCP 连接发送数据。
因此，问题排查的目标是：明确该 TCP 连接关闭的具体原因。

出于以下考虑，我们建议用户在问题复现时间点的前后几分钟内，对应用与 ShardingSphere-Proxy 两侧同时进行网络抓包。

  • 该问题会每小时准时复现；
  • 该问题与网络相关；
  • 该问题不影响用户实时业务。

抓包现象一

ShardingSphere-Proxy 每 15 秒都会客户端发起的收到 TCP 连接建立请求，在完成三次握手建立连接后，客户端却立即向 Proxy 发送了 RST。MySQL 协议的连接建立是由服务端先主动发送 Greeting 给客户端，从抓包结果中看，客户端在接收到 Server Greeting 后没有任何回应就向 Proxy 发送了 RST，甚至在 Proxy 还没有发送 Server Greeting 时就发送了 RST。

在这里插入图片描述
但是，在应用侧抓包结果中，却没有找到符合以上行为的流量。
在阅读用户所使用的 ELB 的文档发现，以上网络交互是该 ELB 的四层健康检查机制的实现方式。因此，该现象与本案例的问题无关。

在这里插入图片描述

抓包现象二

客户端与 ShardingSphere-Proxy 所建立的 MySQL 连接，在 TCP 连接断开阶段，客户端向 Proxy 发送了 RST。
在这里插入图片描述
以上抓包结果显示，客户端先主动向 ShardingSphere-Proxy 发送了 COM_QUIT 命令，即该 MySQL 连接是由客户端主动断开，包括但不限于以下可能的情况：

  • 应用程序对 MySQL 连接的使用已完毕，正常关闭数据库连接；
  • 应用程序与 ShardingSphere-Proxy 的数据库连接受连接池管理，连接池对空闲超时、或超出最长生命周期的空闲连接进行释放操作。

由于连接是应用侧主动关闭，如非应用本身逻辑存在问题，理论上不影响其他业务操作。

经过多轮抓包分析，在问题复现前后的几分钟内，都没有发现 ShardingSphere-Proxy 向客户端发送 RST 的情况。根据现有信息推测，客户端与 ShardingSphere-Proxy 的连接有可能在更早的时候就断开了，只是抓包时长有限，没有采集到断开的那一刻。
ShardingSphere-Proxy 本身没有主动断开客户端连接的逻辑。考虑从客户端与 ELB 这两层去排查问题。

客户端应用与 ELB 配置检查

根据用户反馈：

  • 应用的定时作业为每小时执行一次，应用没有使用数据库连接池，手动维护了一个数据库连接，提供给定时作业持续使用；
  • ELB 配置了四层会话保持，会话空闲超时时间为 40 分钟。

考虑定时作业执行的频率，我们建议用户修改 ELB 会话空闲超时大于定时作业的执行间隔时间。
用户修改 ELB 超时时间为 66 分钟后，Connection reset 问题不再出现。

如果问题排查过程中持续抓包，极有可能在每小时的第 40 分钟捕获到 ELB 断开 TCP 连接的流量。

问题结论

客户端报错 Connection reset by peer 根本原因：
ELB 空闲超时时间小于定时任务执行间隔，客户端空闲的时间超过了 ELB 的会话保持超时时间，导致客户端与 ShardingSphere-Proxy 之间的连接被 ELB 超时断开。
客户端向已经被 ELB 关闭的 TCP 连接发送数据，导致报错 Connection reset by peer。

超时模拟实验

本文进行一个简单的实验，验证客户端在负载均衡会话超时后的表现，并在实验过程中进行抓包，分析网络流量观察负载均衡的行为。

搭建负载均衡的 ShardingSphere-Proxy 集群环境

理论上任何四层负载均衡实现都能作为本文探讨的对象，因此本文使用 nginx 作为四层负载均衡技术实现。

配置 nginx stream

空闲超时设置 1 分钟，即 TCP 会话保持最多 1 分钟。

user  nginx;
worker_processes  auto;

error_log  /var/log/nginx/error.log notice;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

stream {
    upstream shardingsphere {
        hash $remote_addr consistent;

        server proxy0:3307;
        server proxy1:3307;
    }

    server {
        listen 3306;
        proxy_timeout 1m;
        proxy_pass shardingsphere;
    }
}

构造 Docker compose

version: "3.9"
services:

  nginx:
    image: nginx:1.22.0
    ports:
      - 3306:3306
    volumes:
      - /path/to/nginx.conf:/etc/nginx/nginx.conf

  proxy0:
    image: apache/shardingsphere-proxy:5.3.0
    hostname: proxy0
    ports:
      - 3307

  proxy1:
    image: apache/shardingsphere-proxy:5.3.0
    hostname: proxy1
    ports:
      - 3307

启动环境

 $ docker compose up -d 
[+] Running 4/4
 ⠿ Network lb_default     Created                                                                                                      0.0s
 ⠿ Container lb-proxy1-1  Started                                                                                                      0.5s
 ⠿ Container lb-proxy0-1  Started                                                                                                      0.6s
 ⠿ Container lb-nginx-1   Started                                                                                                      0.6s

模拟客户端基于同连接定时任务

构造客户端延迟执行 SQL

此处通过 Java 和 MySQL Connector/J 访问 ShardingSphere-Proxy。
逻辑大致如下：

  1. 与 ShardingSphere-Proxy 建立连接，并向 Proxy 执行一次查询；
  2. 等待 55 秒后，再向 Proxy 执行一次查询；
  3. 等待 65 秒后，再向 Proxy 执行一次查询。
public static void main(String[] args) {
    try (Connection connection = DriverManager.getConnection("jdbc:mysql://127.0.0.1:3306?useSSL=false", "root", "root"); Statement statement = connection.createStatement()) {
        log.info(getProxyVersion(statement));
        TimeUnit.SECONDS.sleep(55);
        log.info(getProxyVersion(statement));
        TimeUnit.SECONDS.sleep(65);
        log.info(getProxyVersion(statement));
    } catch (Exception e) {
        log.error(e.getMessage(), e);
    }
}

private static String getProxyVersion(Statement statement) throws SQLException {
    try (ResultSet resultSet = statement.executeQuery("select version()")) {
        if (resultSet.next()) {
            return resultSet.getString(1);
        }
    }
    throw new UnsupportedOperationException();
}

预期结果与客户端运行结果

预期结果：

  1. 客户端与 ShardingSphere-Proxy 连接建立且第一次查询成功；
  2. 客户端第二次查询成功；
  3. 由于 nginx 空闲超时设置为 1 分钟，客户端第三次查询因 TCP 连接断开报错。

执行结果与预期符合。由于编程语言与数据库驱动的差异，报错信息表现不一致，但根本原因相同：都是 TCP 连接已断开。
日志如下所示：

15:29:12.734 [main] INFO icu.wwj.hello.jdbc.ConnectToLBProxy - 5.7.22-ShardingSphere-Proxy 5.1.1
15:30:07.745 [main] INFO icu.wwj.hello.jdbc.ConnectToLBProxy - 5.7.22-ShardingSphere-Proxy 5.1.1
15:31:12.764 [main] ERROR icu.wwj.hello.jdbc.ConnectToLBProxy - Communications link failure
The last packet successfully received from the server was 65,016 milliseconds ago. The last packet sent successfully to the server was 65,024 milliseconds ago.
        at com.mysql.cj.jdbc.exceptions.SQLError.createCommunicationsException(SQLError.java:174)
        at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:64)
        at com.mysql.cj.jdbc.StatementImpl.executeQuery(StatementImpl.java:1201)
        at icu.wwj.hello.jdbc.ConnectToLBProxy.getProxyVersion(ConnectToLBProxy.java:28)
        at icu.wwj.hello.jdbc.ConnectToLBProxy.main(ConnectToLBProxy.java:21)
Caused by: com.mysql.cj.exceptions.CJCommunicationsException: Communications link failure

The last packet successfully received from the server was 65,016 milliseconds ago. The last packet sent successfully to the server was 65,024 milliseconds ago.
        at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
        at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
        at com.mysql.cj.exceptions.ExceptionFactory.createException(ExceptionFactory.java:61)
        at com.mysql.cj.exceptions.ExceptionFactory.createException(ExceptionFactory.java:105)
        at com.mysql.cj.exceptions.ExceptionFactory.createException(ExceptionFactory.java:151)
        at com.mysql.cj.exceptions.ExceptionFactory.createCommunicationsException(ExceptionFactory.java:167)
        at com.mysql.cj.protocol.a.NativeProtocol.readMessage(NativeProtocol.java:581)
        at com.mysql.cj.protocol.a.NativeProtocol.checkErrorMessage(NativeProtocol.java:761)
        at com.mysql.cj.protocol.a.NativeProtocol.sendCommand(NativeProtocol.java:700)
        at com.mysql.cj.protocol.a.NativeProtocol.sendQueryPacket(NativeProtocol.java:1051)
        at com.mysql.cj.protocol.a.NativeProtocol.sendQueryString(NativeProtocol.java:997)
        at com.mysql.cj.NativeSession.execSQL(NativeSession.java:663)
        at com.mysql.cj.jdbc.StatementImpl.executeQuery(StatementImpl.java:1169)
        ... 2 common frames omitted
Caused by: java.io.EOFException: Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost.
        at com.mysql.cj.protocol.FullReadInputStream.readFully(FullReadInputStream.java:67)
        at com.mysql.cj.protocol.a.SimplePacketReader.readHeaderLocal(SimplePacketReader.java:81)
        at com.mysql.cj.protocol.a.SimplePacketReader.readHeader(SimplePacketReader.java:63)
        at com.mysql.cj.protocol.a.SimplePacketReader.readHeader(SimplePacketReader.java:45)
        at com.mysql.cj.protocol.a.TimeTrackingPacketReader.readHeader(TimeTrackingPacketReader.java:52)
        at com.mysql.cj.protocol.a.TimeTrackingPacketReader.readHeader(TimeTrackingPacketReader.java:41)
        at com.mysql.cj.protocol.a.MultiPacketReader.readHeader(MultiPacketReader.java:54)
        at com.mysql.cj.protocol.a.MultiPacketReader.readHeader(MultiPacketReader.java:44)
        at com.mysql.cj.protocol.a.NativeProtocol.readMessage(NativeProtocol.java:575)
        ... 8 common frames omitted

抓包结果分析

抓包结果显示，在连接空闲超时后，nginx 同时断开了和客户端、Proxy 的 TCP 连接。但由于客户端没有任何感知，发送命令后，nginx 返回了 RST。
nginx 连接空闲超时后，与 Proxy 正常完成了 TCP 断开连接的流程，后续客户端使用已断开的连接发送请求时，Proxy 是完全没有感知的。
分析以下抓包结果：

  • 编号 1~44 是客户端与 ShardingSphere-Proxy 建立 MySQL 连接的交互过程；
  • 编号 45~50 是客户端执行第一次查询；
  • 编号 55~60 是客户端执行第一次查询的 55 秒后，执行第二次查询；
  • 编号 73～77 是在会话超时后，nginx 同时向客户端与 ShardingSphere-Proxy 发起 TCP 连接断开流程；
  • 编号 78～79 是客户端执行第二次查询的 65 秒后，执行第三次查询，发生 Connection Reset。

在这里插入图片描述

ShardingSphere on Cloud 一站式解决方案

人工部署、运维 ShardingSphere-Proxy 集群及负载均衡，难免消耗一定的人力、时间成本。对此，Apache ShardingSphere 重磅推出云上解决方案集合——ShardingSphere on Cloud。

ShardingSphere on Cloud 包括在 AWS、GCP、阿里云等云环境下面向虚机的自动化部署脚本，如 CloudFormation Stack 模板、Terraform 一键部署脚本等，在 Kubernetes 云原生环境下的 Helm Charts、Operator、自动水平扩缩容等工具，以及高可用、可观测性、安全合规、等方面的各类实践内容。
ShardingSphere on Cloud 包括以下能力：

  • 基于 Helm Charts 的 ShardingSphere-Proxy 在 Kubernetes 环境下一键部署；
  • 基于 Operator 的 ShardingSphere-Proxy 在 Kubernetes 环境下一键部署和自动运维；
  • 基于 AWS CloudFormation 的 ShardingSphere-Proxy 快速部署；
  • 基于 Terraform 的 AWS 环境下 ShardingSphere-Proxy 快速部署。

本文简要展示 ShardingSphere on Cloud 的基本能力之一：使用 Helm Charts 在 Kubernetes 一键部署 ShardingSphere-Proxy 集群。

  1. 使用以下 3 行命令，即可实现以默认配置在 Kubernetes 集群内创建一个 3 节点的 ShardingSphere-Proxy 集群，并通过 Service 提供服务。
    helm repo add shardingsphere https://apache.github.io/shardingsphere-on-cloud
helm repo update
helm install shardingsphere-proxy shardingsphere/apache-shardingsphere-proxy-charts -n shardingsphere
    在这里插入图片描述
  2. 应用即可通过 svc 域名访问 ShardingSphere-Proxy 集群。
kubectl run mysql-client --image=mysql:5.7.36 --image-pull-policy=IfNotPresent -- sleep 300
kubectl exec -i -t mysql-client -- mysql -h shardingsphere-proxy-apache-shardingsphere-proxy.shardingsphere.svc.cluster.local -P3307 -uroot -proot

在这里插入图片描述
以上仅仅是对 ShardingSphere on Cloud 基本能力之一的展示，对于更多生产可用的高级特性，欢迎探索 ShardingSphere on Cloud 官方文档。
https://shardingsphere.apache.org/oncloud/current/cn/overview/

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/192680.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

LED背光车载驱动IC 可支持48通道

LED背光车载驱动IC 可支持48通道

特性电源电压范围-VDD:3.3V~5.5V-VLED:27V(max)48 个恒流输出通道- 通道恒流输出范围 0~50mA一 通道间电流输出偏差小于3%- 芯片间电流输出偏差小于 3%Low Knee Voltage:0.55V小于20mA0.6V 大于20mA最大支持4扫，内嵌行控制信号通道灰度实现-支持 PWM/PAMPWM驱动 -灰…
阅读更多...
云帆文档管理系统版本更新说明：v4.6.0

云帆文档管理系统版本更新说明：v4.6.0

一、新增及优化功能资料管理新增打包下载管理端增加资料查阅菜单，管理端和用户端用户有同样的查阅权限，方便其快速的查阅企业的资料信息前端下载文档格式添加下载水印，水印显示的是下载的用户和日期采购合同增加智能识别功能资料管理添加关键…
阅读更多...
KPI考核系统实战之二：swagger框架

KPI考核系统实战之二：swagger框架

KPI考核系统实战之二：swagger框架一、asp.net core 3.1二、融合swagger1.Nuget安装Swashbuckle.AspNetCore2.Startup.cs 注册Swagger服务，使用swagger中间件一、asp.net core 3.1 使用Visual Studio 2022，搭建asp.net core weiapi开发平台&a…
阅读更多...
煤矿皮带运行状态监测预警系统 yolov7

煤矿皮带运行状态监测预警系统 yolov7

煤矿皮带运行状态监测预警系统通过yolov7网络模型深度学习技术，自动对传输皮带运行状态进行实时监测。当监测到皮带撕裂、跑偏、异物、堆煤等异常情况时，立即抓拍预警及时停止皮带同步回传违规信息到后台。介绍Yolo算法之前，首先先介绍一下滑…
阅读更多...
PushKit/Callkit使用经验

PushKit/Callkit使用经验

前言：如果要求使用这两种库，请在查询资料并自己尝试后，多参考苹果官方的API文档：PushKit：https://developer.apple.com/documentation/pushkit?languageobjcCallKit：https://developer.apple.com/document…
阅读更多...
人工智能与模式识别的意义(模式识别与图像处理课程作业)

人工智能与模式识别的意义(模式识别与图像处理课程作业)

人工智能与模式识别的意义(模式识别与图像处理课程作业一、 人工智能的意义二、 模式识别的意义2.1、文字识别2.2、语音识别2.3、指纹识别2.4、遥感2.5、医学诊断1、语音识别技术2、生物认证技术3、数字水印技术一、 人工智能的意义 人工智能的发送对于我们社会的各个方面都具有…
阅读更多...
Word页面中四个直角

Word页面中四个直角

文章目录1、四个直角1）代表页边距2）页边距的设置3）打开或关闭“裁剪标记”2、“裁剪标记”与图片1）插入图片超过这个角能打印显示出来吗？3、“裁剪标记”与表格1、四个直角 1）代表页边距 页面中的四个角代…
阅读更多...
【LoRa网关以及LoRa自组网】以“有人物联网”为例

【LoRa网关以及LoRa自组网】以“有人物联网”为例

【LoRa网关以及LoRa自组网】以“有人物联网”为例0.参考资料1. LoRa 自组网协议的理解1.1【LoRa模块WH-L101-L-P-H10 】1.2【LoRa网关设置】1.3【节点、网关、服务器通讯】1.4【一些注意事项】1.5【专业名词】2.【LoRa点对点通讯 】LoRa网关可以实现多个LoRa节点的数据采集&…
阅读更多...
咖啡商城|基于Springboot+Vue前后端分离咖啡商城系统

咖啡商城|基于Springboot+Vue前后端分离咖啡商城系统

作者主页：编程指南针 作者简介：Java领域优质创作者、CSDN博客专家 、掘金特邀作者、多年架构师设计经验、腾讯课堂常驻讲师 主要内容：Java项目、毕业设计、简历模板、学习资料、面试题库、技术互助 收藏点赞不迷路 关注作者有好处 文末获取源…
阅读更多...
微软开源的 5 个 yyds 课程！

微软开源的 5 个 yyds 课程！

微软在 GitHub 开源了五大课程，面向计算机专业或者入门编程的同学。分别是 Web 开发课程、机器学习课程、物联网课程、数据分析课程、Bash 课程。01为初学者准备的 Web开发课程这个 65k Star 的 Web 开发课程由 Microsoft 的 Azure Cloud Advocates 出品&#xff0…
阅读更多...
prometheus登录认证

prometheus登录认证

目标 登录Prometheus的9090端口页面的时候，需要输入用户名和密码，才能进入Prometheus页面。 设置密码 Prometheus配置密码不能是明文，必须经过bcrypt程序对密码进行Hash处理。 vim gen-pass.py 内容如下： import getpass import…
阅读更多...
Node，docker 中安装node.js

Node，docker 中安装node.js

1.启动docker服务 首先启动docker服务:systemctl start docker 2.获取node最新镜像 启动完成之后拉取node最新镜像：docker pull node 然后开始等待，最后拉取完成会有相应的输出信息。 我们再通过命令确认下node是否拉取成功：docker image…
阅读更多...
大文件上传和下载解决方案

大文件上传和下载解决方案

前言 前端处理 “大” 一直是一个痛点和难点，比如大文件、大数据量。虽然浏览器硬件有限，但是聪明的工程师总是能够最大化利用浏览器的能力和特性，优雅的解决一个个极端问题，满足用户的多样化需求。 断点上传 对于大文件&#…
阅读更多...
Linux中的磁盘管理与打包命令

Linux中的磁盘管理与打包命令

✅作者简介：热爱国学的Java后端开发者，修心和技术同步精进。 🍎个人主页：Java Fans的博客 🍊个人信条：不迁怒，不贰过。小知识，大智慧。 💞当前专栏：Java案例分…
阅读更多...
2022.11.29（面经五，笔试+技术面）

2022.11.29（面经五，笔试+技术面）

2022.11.29（面经五） 笔试题目不难，多刷力扣就成 1.什么是面向对象？ 面向对象：是把构成问题的事务分解成各个对象，而建立对象的目的也不是为了完成一个个步骤，而是为了描述某个事物在解决整个问…
阅读更多...
应用笔记 | TSMaster核心功能之标定数据的管理

应用笔记 | TSMaster核心功能之标定数据的管理

概述标定模块中，标定数据的管理也是其核心功能。主要包括以下方面的内容：标定数据的载入、标定数据导出、标定数据的刷写，以及配套应用程序的刷写等。下面来详细介绍下这些功能。一、标定数据的载入标定数据的载入路径如下：选择目…
阅读更多...
Linux网络设备驱动框架

Linux网络设备驱动框架

1. 网络设备驱动框架 1.1网际协议分层 优点： 便于封装； 1.2 网络设备驱动程序结构分层 协议接口层： 向网络协议提供统一的数据包发送接口，上层任何形式的协议都通过dev_queue_xmit()发送，通过netif_rx()接收&#xf…
阅读更多...
一种用于IDC机房数据挖掘的应用实现

一种用于IDC机房数据挖掘的应用实现

（作者单位：华北石油通信有限公司）摘要：介绍了适用于数据中心可预定义、自定义场景的轻量级应用实现。现实中监测系统的数据大多沉淀在数据库中，且获取不同设备的信号数据并把这些数据展示出来，多受检测系统…
阅读更多...
LabVIEW更高的吞吐量与更少的延迟A

LabVIEW更高的吞吐量与更少的延迟A

LabVIEW更高的吞吐量与更少的延迟1在设计系统时，“速度”有两个含义。“需要多快采集样品？”通常转化为吞吐量。“样本后需要多快获得结果？”通常转化为延迟。在大多数测量或控制应用中，目标是将真实世界的数据从信号中获取到某种…
阅读更多...
LeetCode哈希表相关解法

LeetCode哈希表相关解法

哈希表1. 理论哈希碰撞的解决方法拉链法线性探测法2. 有效的字母异位词[242. 有效的字母异位词](https://leetcode.cn/problems/valid-anagram/)3. 两个数组的交集[349. 两个数组的交集](https://leetcode.cn/problems/intersection-of-two-arrays/)4. 快乐数[202. 快乐数](htt…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023