腾讯面试：说说6大Nginx负载均衡？手写一下权重轮询策略?

文章很长，且持续更新，建议收藏起来，慢慢读！疯狂创客圈总目录 博客园版 为您奉上珍贵的学习资源 ：

免费赠送 :《尼恩Java面试宝典》 持续更新+ 史上最全 + 面试必备 2000页+ 面试必备 + 大厂必备 +涨薪必备
免费赠送 :《尼恩技术圣经+高并发系列PDF》 ，帮你 实现技术自由，完成职业升级， 薪酬猛涨！加尼恩免费领
免费赠送 经典图书:《Java高并发核心编程（卷1）加强版》 面试必备 + 大厂必备 +涨薪必备 加尼恩免费领
免费赠送 经典图书:《Java高并发核心编程（卷2）加强版》 面试必备 + 大厂必备 +涨薪必备 加尼恩免费领
免费赠送 经典图书:《Java高并发核心编程（卷3）加强版》 面试必备 + 大厂必备 +涨薪必备 加尼恩免费领

免费赠送 资源宝库： Java 必备 百度网盘资源大合集 价值>10000元 加尼恩领取

腾讯面试：说说6大Nginx负载均衡？手写一下权重轮询策略?

尼恩特别说明： 尼恩的文章，都会在 《技术自由圈》 公号 发布， 并且维护最新版本。 如果发现图片 不可见， 请去 《技术自由圈》 公号 查找

尼恩说在前面

在40岁老架构师 尼恩的读者交流群(50+)中，最近有小伙伴拿到了一线互联网企业如得物、阿里、滴滴、极兔、有赞、希音、百度、网易、美团的面试资格，遇到很多很重要的面试题：

1.讲一下什么是负载均衡，什么是轮询策略、随机策略、哈希策略

2.讲一下什么是 基于权重的负载均衡 策略？

3 手写一个 基于权重的负载均衡 策略？

最近有小伙伴在面试 腾讯，又遇到了相关的面试题。小伙伴懵了，因为没有遇到过，所以支支吾吾的说了几句，面试官不满意，面试挂了。

所以，尼恩给大家做一下系统化、体系化的梳理，使得大家内力猛增，可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”，然后实现”offer直提”。

当然，这道面试题，以及参考答案，也会收入咱们的 《尼恩Java面试宝典PDF》V171版本，供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。

最新《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请关注本公众号【技术自由圈】获取，回复：领电子书

1. 为什么需要负载均衡

负载均衡 解决访问统一入口的请求分发/请求路由的问题，我们可以在集群前面增加负载均衡设备，实现流量分发。

当系统面临大量用户访问，负载过高的时候，通常会使用增加服务器数量来进行横向扩展，使用集群和负载均衡提高整个系统的处理能力。

从单机网站到分布式网站，很重要的区别是业务拆分和分布式部署，将应用拆分后，部署到不同的机器上，实现大规模分布式系统。

分布式和业务拆分解决了，从集中到分布的问题，但是每个部署的独立业务还存在单点的问题和访问统一入口问题，为解决单点故障，我们可以采取冗余的方式，将相同的应用部署到多台机器上。

在服务器集群中，Nginx起到一个代理服务器的角色（即反向代理），

负载均衡 的作用： 为了避免单独一个服务器压力过大，将来自用户的请求转发给不同的服务器。

在这里插入图片描述

2. Nginx的5大负载均衡策略策略

负载均衡用于从“upstream”模块定义的后端服务器列表中选取一台服务器接受用户的请求。

一个最基本的upstream模块是这样的，模块内的server是服务器列表：

#动态服务器组
upstream backend_group{server localhost:8080; #backend  1server localhost:8081; #backend  2server localhost:8082; #backend  3server localhost:8083; #backend  4
}
  • 192.168.1.1:80：指定后端真实服务器可以是域名或ip，默认是80端口
  • weight：指定每个后端主机的调度的权重，默认为1
  • max_conns：指定后端主机最大并发连接数
  • max_fails：指定后端主机健康检查多少次失败后才将主机标记为不可用（默认1次，0为不做健康检测）
  • fail_timeout：指定后端主机健康检测超时多少时间为一次失败（默认10秒）
  • backup：指定sorry_server，当所有后端主机健康检测失败时，会显示此服务器的页面
  • down：将当前主机标记为不可用（维护时使用）

在upstream模块配置完成后，要让指定的访问反向代理到服务器列表：

#其他页面反向代理到backend 容器
location ~ .*${index index.jsp index.html;proxy_pass http://backend_group;
}

这就是最基本的负载均衡实例，但这不足以满足实际需求；目前Nginx服务器的upstream模块支持6种方式的分配：

负载均衡策略

轮循 默认方式
Weight 权重方式
Ip_hash 依据ip分配方式
Lease_conn 最少连接方式
Fair（第三方） 响应时间方式
Url_hash（第三方） 依据url分配方式

在这里，只详细说明Nginx自带的负载均衡策略，第三方不多描述。

2.1. roundrobin 轮询 策略

尼恩提示大家，nginx 缺省配置就是roundrobin 轮询策略。

roundrobin 最基本的配置方法，上面的例子就是轮询的方式，它是upstream模块默认的负载均衡默认策略。

roundrobin 策略中，每个请求会按时间顺序逐一分配到不同的后端服务器。

在这里插入图片描述

roundrobin 有如下参数：

fail_timeout 与max fails结合使用
max_fails 设置在fail timeout参数设置的时间内最大失败次数，如果在这个时间内，所有针对该服务器的请求都失败了，那么认为该服务器会被认为是停机了
fail_time 服务器会被认为停机的时间长度,默认为10s。
backup 标记该服务器为备用服务器。当主服务器停止时，请求会被发送到它这里。
down 标记服务器永久停机了。

注意：

  • 在轮询中，如果服务器down掉了，会自动剔除该服务器。
  • 此策略适合服务器配置相当，无状态且短平快的服务使用。

轮询很容易实现，将请求按顺序轮流分配到后台服务器上，均衡的对待每一台服务器，而不关心服务器实际的连接数和当前的系统负载。
适合场景：适合于应用服务器硬件都相同的情况。

2.2. 加权 轮循 weighted roundrobin

权重方式，在轮询策略的基础上指定轮询的几率。

在轮询的基础上根据硬件配置不同，按权重分发到不同的服务器。

weighted roundrobin 加权 轮循 是：能者多劳的思想。

weighted roundrobin 加权 轮循 的策略是：

  • 给高性能的机器分配更高的权重，使其能处理更多的请求，
  • 而性能低、负载高的机器，配置较低的权重，让其处理较少的请求。

在这里插入图片描述

加权 轮循 weighted roundrobin 例子如下：

#动态服务器组
upstream backend_group{server localhost:8080  weight=2; #backend  1server localhost:8081; #backend 2server localhost:8082; #backend 3server localhost:8083; #backend 4
}

在该例子中，weight参数用于指定轮询几率，weight的默认值为1；

weight的数值与访问比率成正比，比如 backend 1的weight的数值为2，其 被访问的几率为其他服务器的两倍。

注意：

  • 权重越高分配到需要处理的请求越多。
  • 此策略可以与least_conn和ip_hash结合使用。
  • 此策略比较适合服务器的硬件配置差别比较大的情况。

2.3. ip_hash

根据服务消费者请求客户端的IP地址，通过哈希函数计算得到一个哈希值，将此哈希值和服务器列表的大小进行取模运算，得到的结果便是要访问的服务器地址的序号。

在这里插入图片描述

ip_hash 指定负载均衡器按照基于客户端IP的分配方式，这个方法确保了相同的客户端的请求一直发送到相同的服务器，以保证session会话。

这样每个访客都固定访问一个后端服务器，可以解决session不能跨服务器的问题。

#动态服务器组
upstream backend_group{ip_hash;  #保证每个访客固定访问一个后端服务器server localhost:8080 ; #backend  1server localhost:8081; #backend  2server localhost:8082; #backend  3server localhost:8083 ; #backend 4 
}

注意：

  • 在nginx版本1.3.1之前，不能在ip_hash中使用权重（weight）。
  • ip_hash不能与backup同时使用。
  • 此策略适合有状态服务，比如session。
  • 当有服务器需要剔除，必须手动down掉。

ip_hash 适合场景：根据请求的来源IP进行hash计算，同一IP地址的客户端，当后端服务器列表不变时，它每次都会映射到同一台后端服务器进行访问。

2.4. least_conn

roundrobin 轮询算法是把请求平均的转发给各个后端，使它们的负载大致相同；但是，有些请求占用的时间很长，会导致其所在的后端负载较高。

least_conn 把请求转发给连接数较少的后端服务器。

least_conn 记录每个服务器正在处理的请求数，把新的请求分发到最少连接的服务器上。

这种情况下，least_conn这种方式就可以达到更好的负载均衡效果。

#动态服务器组
upstream backend_group{least_conn;  #把请求转发给连接数较少的后端服务器server localhost:8080 ; #backend  1server localhost:8081; #backend  2server localhost:8082; #backend  3server localhost:8083 ; #backend 4 
}

注意：

  • 此负载均衡策略适合请求处理时间长短不一造成服务器过载的情况。

2.5. 第三方策略：fair

第三方的负载均衡策略的实现需要安装第三方插件。

fair 策略是 按照服务器端的响应时间来分配请求，响应时间短的优先分配。

#动态服务器组
upstream backend_group{server localhost:8080; #backend  7.0server localhost:8081; #backend  8.0server localhost:8082; #backend  8.5server localhost:8083; #backend  9.0fair;  #实现响应时间短的优先分配
}

2.6. 第三方策略：url_hash

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，要配合缓存命中来使用。

同一个资源多次请求，可能会到达不同的服务器上，导致不必要的多次下载，缓存命中率不高，以及一些资源时间的浪费。

而使用url_hash，可以使得同一个url（也就是同一个资源请求）会到达同一台服务器，一旦缓存住了资源，再此收到请求，就可以从缓存中读取。

#动态服务器组
upstream backend_group{hash $request_uri;  #实现每个url定向到同一个后端服务器server localhost:8080; #backend  7.0server localhost:8081; #backend  8.0server localhost:8082; #backend  8.5server localhost:8083; #backend  9.0
}

以上便是6种负载均衡策略的实现方式，其中除了轮询和轮询权重外，都是Nginx根据不同的算法实现的。

在实际运用中，需要根据不同的场景选择性运用，大都是多种策略结合使用以达到实际需求。

3. 手写一个 基于权重的负载均衡Weighted Round Robin算法

设计一个类似于 Nginx 基于权重的负载均衡算法，需要考虑以下几个核心要素：

  • 服务器的权重、

  • 负载均衡策略、

  • 状态维护机制等。

手写一个 基于权重的负载均衡Weighted Round Robin算法，以下是具体的设计步骤：

3.1. 服务器列表与权重设定

每个服务器都有一个权重，权重值越大，表示服务器的处理能力越强，收到的请求应该越多。

服务器列表可以用一个数组或链表来表示，包含服务器的 IP、当前负载状态、最大处理能力等。

servers = [{"ip": "192.168.1.1", "weight": 5, "current_weight": 0},{"ip": "192.168.1.2", "weight": 3, "current_weight": 0},{"ip": "192.168.1.3", "weight": 2, "current_weight": 0}
]

3.2. 加权轮询算法

加权轮询是一种简单但有效的负载均衡算法。

每次将请求发送到当前权重最高的服务器上，并对该服务器的当前权重进行调整。

具体步骤：

  1. 初始化总权重：计算所有服务器权重的总和。
  2. 选择服务器：遍历服务器列表，选出current_weight最大的服务器。
  3. 调整权重
    • 对选择的服务器，将其current_weight减去总权重；
    • 对所有服务器，将current_weight加上各自的权重。
  4. 发送请求：将请求分发给选中的服务器。

3.3. 伪代码 实现一个Weighted Round Robin算法：

def weighted_round_robin(servers):total_weight = sum(server['weight'] for server in servers)selected = Nonefor server in servers:# 更新 current_weightserver['current_weight'] += server['weight']# 选择 current_weight 最大的服务器if selected_server==null or server['current_weight'] > selected['current_weight']:selected_server = server# 将选择的服务器的 current_weight 减去总权重selected_server['current_weight'] -= total_weightreturn selected_server

3.4. 基于权重的负载均衡Weighted Round Robin算法示例：

假设有三台服务器，权重分别为 5、3、2。

初始状态下所有服务器的current_weight都为 0，负载均衡算法的分配过程如下：

请求 服务器1权重 服务器2权重 服务器3权重 选择的服务器
1 5 3 2 服务器1
2 0 6 4 服务器2
3 5 3 6 服务器3
4 10 6 4 服务器1

通过这种方式，较高权重的服务器会优先获得更多请求，但每台服务器的负载会相对均衡。

4. 手写Java 版本的 Weighted Round Robin算法

可以在 Java 中实现一个加权轮询（Weighted Round Robin）的负载均衡器。

Weighted Round Robin算法将按照服务器的权重分配请求，确保高权重的服务器接收到更多请求。

4.1. 服务器类设计

首先，需要设计一个服务器类 Server，包括服务器的 IP、权重、当前权重和当前负载等属性。

package com.crazymakercircle.loadbalance;import lombok.Data;@Data
public class Server {private  int usedCount;   //使用次数private String ip;  //ipprivate int weight;  //权重private int currentWeight;  //当前权重public Server(String ip, int weight) {this.ip = ip;this.weight = weight;this.currentWeight = 0;this.usedCount = 0;}public void usedOne() {System.out.println("选中之后： ip = " + ip + " currentWeight = " + currentWeight + " weight = " + weight);usedCount++;}}

4.2. 加权轮询负载均衡算法

设计一个 WeightedRoundRobinBalancer 类来实现加权轮询算法，管理多个 Server 实例的请求分发。

package com.crazymakercircle.loadbalance;import java.util.List;
public class WeightedRoundRobinBalancer {private List<Server> servers; //服务列表private int totalWeight; //总权重public WeightedRoundRobinBalancer(List<Server> servers) {this.servers = servers;// 初始化总权重this.totalWeight = servers.stream().mapToInt(Server::getWeight).sum();System.out.println("totalWeight = " + totalWeight);}// 获取当前轮询中要选择的服务器public Server doSelect() {Server selectedServer = null;for (Server server : servers) {// 增加当前权重server.setCurrentWeight(server.getCurrentWeight() + server.getWeight());// 选择 currentWeight 最大的服务器if (selectedServer == null || server.getCurrentWeight() > selectedServer.getCurrentWeight()) {selectedServer = server;}}// 将选择的服务器 currentWeight 减去总权重if (selectedServer != null) {selectedServer.setCurrentWeight(selectedServer.getCurrentWeight() - totalWeight);}selectedServer.usedOne();return selectedServer;}
}

4.3. 测试代码

接下来，我们可以创建一些服务器并测试负载均衡器的效果：

import java.util.Arrays;public class LoadBalancerTest {public static void main(String[] args) {// 创建服务器列表，服务器的权重分别为 5, 3, 2Server server1 = new Server("192.168.1.1", 5);Server server2 = new Server("192.168.1.2", 3);Server server3 = new Server("192.168.1.3", 2);WeightedRoundRobinBalancer balancer = new WeightedRoundRobinBalancer(Arrays.asList(server1, server2, server3));// 模拟 10 次请求，观察每次请求分配到的服务器for (int i = 0; i < 10; i++) {Server selectedServer = balancer.getServer();System.out.println("Request " + (i + 1) + " is handled by server: " + selectedServer.getIp());}}
}

4.4. 结果输出

根据不同服务器的权重，负载均衡器会以加权轮询的方式分配请求：

totalWeight = 10
选中之后： ip = 192.168.1.1 currentWeight = -5 weight = 5
>>>>>>> 请求 1 路由到: 192.168.1.1
选中之后： ip = 192.168.1.2 currentWeight = -4 weight = 3
>>>>>>> 请求 2 路由到: 192.168.1.2
选中之后： ip = 192.168.1.3 currentWeight = -4 weight = 2
>>>>>>> 请求 3 路由到: 192.168.1.3
选中之后： ip = 192.168.1.1 currentWeight = 0 weight = 5
>>>>>>> 请求 4 路由到: 192.168.1.1
选中之后： ip = 192.168.1.1 currentWeight = -5 weight = 5
>>>>>>> 请求 5 路由到: 192.168.1.1
选中之后： ip = 192.168.1.2 currentWeight = -2 weight = 3
>>>>>>> 请求 6 路由到: 192.168.1.2
选中之后： ip = 192.168.1.1 currentWeight = -5 weight = 5
>>>>>>> 请求 7 路由到: 192.168.1.1
选中之后： ip = 192.168.1.3 currentWeight = -4 weight = 2
>>>>>>> 请求 8 路由到: 192.168.1.3
选中之后： ip = 192.168.1.2 currentWeight = -3 weight = 3
>>>>>>> 请求 9 路由到: 192.168.1.2
选中之后： ip = 192.168.1.1 currentWeight = 0 weight = 5
>>>>>>> 请求 10 路由到: 192.168.1.1
选中之后： ip = 192.168.1.1 currentWeight = -5 weight = 5
>>>>>>> 请求 11 路由到: 192.168.1.1
选中之后： ip = 192.168.1.2 currentWeight = -4 weight = 3
>>>>>>> 请求 12 路由到: 192.168.1.2
选中之后： ip = 192.168.1.3 currentWeight = -4 weight = 2
>>>>>>> 请求 13 路由到: 192.168.1.3
选中之后： ip = 192.168.1.1 currentWeight = 0 weight = 5
>>>>>>> 请求 14 路由到: 192.168.1.1
选中之后： ip = 192.168.1.1 currentWeight = -5 weight = 5
>>>>>>> 请求 15 路由到: 192.168.1.1
选中之后： ip = 192.168.1.2 currentWeight = -2 weight = 3
>>>>>>> 请求 16 路由到: 192.168.1.2
选中之后： ip = 192.168.1.1 currentWeight = -5 weight = 5
>>>>>>> 请求 17 路由到: 192.168.1.1
选中之后： ip = 192.168.1.3 currentWeight = -4 weight = 2
>>>>>>> 请求 18 路由到: 192.168.1.3
选中之后： ip = 192.168.1.2 currentWeight = -3 weight = 3
>>>>>>> 请求 19 路由到: 192.168.1.2
选中之后： ip = 192.168.1.1 currentWeight = 0 weight = 5
>>>>>>> 请求 20 路由到: 192.168.1.1
=======》打印 总次数分布
192.168.1.1:10
192.168.1.2:6
192.168.1.3:4

4.5. 动态调整与状态维护

这个实现只是最基本的加权轮询。为了提升实际使用的性能，还可以做一些优化：

  • 动态权重调整：根据服务器的实时负载，动态调整权重。比如，监控 CPU 或内存使用率，负载高的服务器权重减少，负载低的权重增加。
  • 健康检查：定期检查服务器状态，将不可用的服务器从列表中移除，以防止请求被发送到已经不可用的服务器。
public void healthCheck() {// 遍历所有服务器，检查其健康状态servers.removeIf(server -> !isHealthy(server));
}private boolean isHealthy(Server server) {// 实现对服务器的健康检查，返回 true 表示健康return true;  // 简单示例，实际可以发送请求或 ping 检查服务器状态
}

4.6. 优化与扩展

  • 最小连接数优先：在加权轮询的基础上，还可以结合最小连接数策略，优先将请求分配给当前连接数最少的服务器。
  • 一致性哈希：为提高稳定性，避免请求在服务器上下线时大量转移，可以结合一致性哈希算法，使得请求尽可能落在相同的服务器上。

这种基于加权轮询的负载均衡算法简单、高效，特别适合处理不同性能的服务器集群。结合健康检查、动态权重调整等机制，可以进一步优化负载均衡的效果。

总结

通过 Java 实现的基于权重的负载均衡算法，能够根据服务器的不同权重来智能地分发请求，确保高权重的服务器承载更多的流量。

同时，结合动态权重调整和健康检查机制，可以进一步优化该负载均衡算法的性能和稳定性。

说在最后：有问题找老架构取经‍

关于讲一下什么是 基于权重的负载均衡 策略？尼恩给大家梳理的满分答案，已经彻底出来了。

通过这个问题的深度回答，可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”，然后实现”offer直提”。

在面试之前，建议大家系统化的刷一波 5000页《尼恩Java面试宝典PDF》，里边有大量的大厂真题、面试难题、架构难题。

很多小伙伴刷完后， 吊打面试官， 大厂横着走。

在刷题过程中，如果有啥问题，大家可以来 找 40岁老架构师尼恩交流。

另外，如果没有面试机会，可以找尼恩来改简历、做帮扶。

遇到职业难题，找老架构取经， 可以省去太多的折腾，省去太多的弯路。

尼恩指导了大量的小伙伴上岸，前段时间，刚指导一个40岁+被裁小伙伴，拿到了一个年薪100W的offer。

狠狠卷，实现 “offer自由” 很容易的， 前段时间一个武汉的跟着尼恩卷了2年的小伙伴， 在极度严寒/痛苦被裁的环境下， offer拿到手软， 实现真正的 “offer自由” 。

技术自由的实现路径：

实现你的 架构自由：

《吃透8图1模板，人人可以做架构》

《10Wqps评论中台，如何架构？B站是这么做的！！！》

《阿里二面：千万级、亿级数据，如何性能优化？ 教科书级 答案来了》

《峰值21WQps、亿级DAU，小游戏《羊了个羊》是怎么架构的？》

《100亿级订单怎么调度，来一个大厂的极品方案》

《2个大厂 100亿级 超大流量 红包 架构方案》

… 更多架构文章，正在添加中

实现你的 响应式 自由：

《响应式圣经：10W字，实现Spring响应式编程自由》

这是老版本 《Flux、Mono、Reactor 实战（史上最全）》

实现你的 spring cloud 自由：

《Spring cloud Alibaba 学习圣经》 PDF

《分库分表 Sharding-JDBC 底层原理、核心实战（史上最全）》

《一文搞定：SpringBoot、SLF4j、Log4j、Logback、Netty之间混乱关系（史上最全）》

实现你的 linux 自由：

《Linux命令大全：2W多字，一次实现Linux自由》

实现你的 网络 自由：

《TCP协议详解 (史上最全)》

《网络三张表：ARP表, MAC表, 路由表，实现你的网络自由！！》

实现你的 分布式锁 自由：

《Redis分布式锁（图解 - 秒懂 - 史上最全）》

《Zookeeper 分布式锁 - 图解 - 秒懂》

实现你的 王者组件 自由：

《队列之王： Disruptor 原理、架构、源码 一文穿透》

《缓存之王：Caffeine 源码、架构、原理（史上最全，10W字 超级长文）》

《缓存之王：Caffeine 的使用（史上最全）》

《Java Agent 探针、字节码增强 ByteBuddy（史上最全）》

实现你的 面试题 自由：

4800页《尼恩Java面试宝典 》 40个专题

免费获取11个技术圣经PDF：

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

如若内容造成侵权/违法违规/事实不符，请联系编程知识网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

ONCE论文阅读笔记

ONCE论文阅读笔记

ONCE: Boosting Content-based Recommendation with Both Open- and Closed-source Large Language Models论文阅读笔记 Abstract ​ 现有的推荐器在理解项目内容方面面临着巨大挑战。大语言模型（LLM）拥有深层语义理解能力和来自预训练的广泛知识，已被证明在各种自然语言处理…
阅读更多...
LeetCode刷题笔记9.2-9.9

LeetCode刷题笔记9.2-9.9

leetCode刷题笔记(9.2-9.9） 48.旋转图像(9.3） 1）图像即二维数组，图像的旋转本质上是二维数组的旋转变换 2）二维数组从外层来看，是若干个子数组的集合，子数组内部维护各自的元素，即若干个row里是row.length个column 3）由此可理解下面几个关于二维数组的函数：创建二维数…
阅读更多...
从零搭建 Docker 私有库

从零搭建 Docker 私有库

对于涉及机密的公司，不可能提供镜像给公网中的镜像仓库，所以需要创建一个本地私人仓库供给团队使用，基于公司内部项目构建镜像。对于涉及机密的公司，不可能提供镜像给公网中的镜像仓库，所以需要创建一个本地私人仓库供给团队使用，基于公司内部项目构建镜像。 Docker Regi…
阅读更多...
[C++ Daily] 确保类复制了所有应该复制的成员

[C++ Daily] 确保类复制了所有应该复制的成员

确保类复制了所有应该复制的成员结果:源代码: #include <iostream> #include <string> #include <vector> /*** copy操作应该包含对象内的所有成员变量及所有父类的成员变量,* 此种可以通过调用对应的拷贝构造与拷贝赋值操作完成*//// @brief simple termina…
阅读更多...
Docker 知识梳理及其安装使用

Docker 知识梳理及其安装使用

Docker 介绍 Docker 是一个强大的工具，用于高效开发、打包和部署应用程序。Docker 是一种容器管理服务。Docker 于 2013 年发布。它是开源的，可用于 Windows、macOS 和 Linux 等不同平台。Docker 正在快速交付、测试和部署代码。这样可以减少编写代码和在生产环境中运行代码之…
阅读更多...
硬件功能电路

硬件功能电路

EEPROMLCD1602电路数码管max485红外开关蜂鸣器译码器移位寄存器步进电机控制复位电路下载电路电源模块温度模块红外热敏电阻交通灯时钟555彩屏矩阵按键单片机烧录电路数码管红外发射显示模块红外接收蜂鸣器驱动流水灯usb供电单片机矩阵单片机电路时钟ADC接口电路单片机电源声音…
阅读更多...
BeanShell预处理器获取jmeter请求后变量无法替换

BeanShell预处理器获取jmeter请求后变量无法替换

背景 jmeter接口验签逻辑是从请求参数中获取值处理加密验签后，讲请求参数中的sign值替换 如果处理后直接讲sign生成Jmeter变量，在当前请求是无法替换的，因为jmeter请求的URL和body已经运行，不会再重新运行替换解决方法 在当前预处理程序中再写处理当前请求的逻辑// 替换URL…
阅读更多...
word 看不到页眉和页脚 以及空白页面的设置

word 看不到页眉和页脚 以及空白页面的设置

修改文档时，发现递交的文档 不显示 页眉和页脚 以及空白页面的设置在选项卡中勾选jcmaxx33@gmail.com jcmaxx33Team@github
阅读更多...
plsql工具无法显示tables问题

plsql工具无法显示tables问题

每次打开plsql12时tables、views等为空，没有表和视图等 解决办法：选择tool->preferences2、取消勾选最近使用最后重新选择已经登录的用户，就可以正常显示table了
阅读更多...
Ftrans无缝替代FTP方案：保障数据传输的安全性与合规性！

Ftrans无缝替代FTP方案：保障数据传输的安全性与合规性！

FTP（文件传输协议）是一种用于在网络上进行文件传输的标准网络协议，历史悠久并且被广泛使用。但随着业务规模和文件体量的快速增长，在应用实践中，FTP存在一些安全和效率问题。因此政府单位需要可以平滑替代FTP的文件传输解决方案，从而更好的保障数据安全、提升工作效率。具…
阅读更多...
Ftrans跨域文件传输方案，数据流动无阻的高效路径！

Ftrans跨域文件传输方案，数据流动无阻的高效路径！

大型集团企业由于其规模庞大、业务广泛且往往将分支机构、办事处分布在多个地域，因此会涉及到跨域文件传输的需求。主要源于以下几个方面： 1.业务协同：集团内部的不同部门或子公司可能位于不同的地理位置，但需要进行紧密的业务协同。文件传输是实现这种协同的重要方式之一，…
阅读更多...
【详解】网络隔离环境下，跨网文件交换存在的核心问题及解决方法

【详解】网络隔离环境下，跨网文件交换存在的核心问题及解决方法

一、为什么要进行网络隔离？ 随着互联网技术的发展和推进，人们对于网络使用的场景也越来越多元化，而网络黑客入侵、病毒攻击、网络泄密等安全事件的不断发生，也让人们认识到网络安全的重要性。企业、社会、国家机构在日常经营管理中，由于业务和数据的保密和安全需求，需要对…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023