负载均衡图片上传

㈠ nginx负载均衡时上传的图片怎么处理

局域网内可以考虑 rsync + inotify-tools

inotify可以监控文件系统的各种变化，当文件有任何变动时，就触发rsync同步，这样刚好解决了同步数据的实时性问题。

局域网内多台服务器时可以配置Nginx把上传等写操作固定到其中一台php-FPM服务器,然后用inotify+rsync同步到其它机器.

比如上传操作定向到服务器192.168.1.10进行处理:
location ^~ /upload.php {
include fastcgi_params;
fastcgi_pass 192.168.1.10:9000;
fastcgi_param SCRIPT_FILENAME /srv/www$fastcgi_script_name;
}
在服务器192.168.1.10上用inotify+rsync同步文件到其他服务器. 除上传外，删除、更改、移动等写操作也要定向到192.168.1.10这台服务器进行处理。

㈡ 磊科NR236W双WAN路由器负载均衡上传问题

其一、接入两条1M ADSL的效果接近于一条2M 光纤，但是费用会大幅降低!由于线路优化效果的存在使得路由器能接入两条1M ADSL的效果接近于一条2M 光纤，实际你可以选择B.6 M ADSL；其二，是可以使用A出口的，双WAN路由器它里边主要是由一个IP均衡器来分配的，所以你所说的情况是得以解决的。希望能帮到你，还望采纳

㈢ 负载均衡基本介绍

【负载均衡架构部分转自】 58沈剑 [架构师之路]( https://mp.weixin.qq.com/s

负载均衡： 是分布式系统架构设计中必须考虑的因素之一，它通常是指，将请求/数据【均匀】分摊到多个操作单元上执行，负载均衡的关键在于【均匀】
常见的负载均衡方案：

【客户端层】到【反向代理层】的负载均衡，是通过“DNS轮询”实现的：DNS-server对于一个域名配置了多个解析ip，每次DNS解析请求来访问DNS-server，会轮询返回这些ip，保证每个ip的解析概率是相同的。这些ip就是nginx的外网ip，以做到每台nginx的请求分配也是均衡的。

【反向代理层】到【站点层】的负载均衡，是通过“nginx”实现的。通过修改nginx.conf，可以实现多种负载均衡策略：

【站点层】到【服务层】的负载均衡，是通过“服务连接池”实现的。
上游连接池会建立与下游服务多个连接，每次请求会“随机”选取连接来访问下游服务。（也即是rpc框架实现的）

在数据量很大的情况下，由于数据层（db，cache）涉及数据的水平切分，所以数据层的负载均衡更为复杂一些，它分为“数据的均衡”，与“请求的均衡”。
数据的均衡是指 ：水平切分后的每个服务（db，cache），数据量是差不多的。
请求的均衡是指 ：水平切分后的每个服务（db，cache），请求量是差不多的。
（1）按照range水平切分

（2）按照id哈希水平切分

[图片上传中...(-6b2508-1561902875888-0)]

常见的负载均衡系统包括 3 种：DNS 负载均衡、硬件负载均衡和软件负载均衡。

硬件负载均衡是通过单独的硬件设备来实现负载均衡功能，这类设备和路由器、交换机类似，可以理解为一个用于负载均衡的基础网络设备。比如业界非常出名的F5

缺点：
（1）价格实在非常昂贵
（2）扩展性不强

软件负载均衡通过负载均衡软件来实现负载均衡功能，常见的有 Nginx 和 LVS。

nginx和F5： https://blog.csdn.net/chabale/article/details/8956717
nginx和lvs比较： https://blog.51cto.com/hzcto/2086691
lvs： https://www.cnblogs.com/liwei0526vip/p/6370103.html
ELB： https://aws.amazon.com/cn/elasticloadbalancing/
SLB： https://help.aliyun.com/proct/27537.html

题目：日活跃用户 1000 万的论坛的负载均衡集群，该如何设计呢？
（1）评估流量
1000万DAU，换算成秒级（一天12小时），平均约等于232。
考虑每个用户操作次数，假定10，换算成平均QPS=2320。
考虑峰值是均值倍数，假定5，换算成峰值QPS=11600。
考虑静态资源、图片资源、服务拆分等，流量放大效应，假定10，QPS 10=116000。
（2）容量规划
考虑高可用、异地多活，QPS 2=232000。
考虑未来半年增长，QPS*1.5=348000。
（3）方案设计
可以用三级导流：
第一级，DNS，确定机房，以目前量级，可以不考虑。
第二级，确定集群，扩展优先，则选Haproxy/LVS，稳定优先则选F5。
第三级，Nginx+KeepAlived，确定实例。
（4）架构图

接入层技术：

缺点：

优点：

缺点：

优点：

缺点：

缺点：

nginx毕竟是软件，性能比tomcat好，但总有个上限，超出了上限，还是扛不住。lvs就不一样了，它实施在操作系统层面；f5的性能又更好了，它实施在硬件层面；它们性能比nginx好很多，例如每秒可以抗10w，这样可以利用他们来扩容。

99.9999%的公司到这一步基本就能解决接入层高可用、扩展性、负载均衡的问题。 假设还扛不住的话，就要考虑使用硬件设备f5等。如果还是扛不住，那么只有DNS来扩容了。

水平扩展，才是解决性能问题的根本方案，能够通过加机器扩充性能的方案才具备最好的扩展性。 facebook，google，的PV是不是超过80亿呢，它们的域名只对应一个ip么，终点又是起点，还是得通过DNS轮询来进行扩容：

比如购买了阿里云或者aws。那么基本会使用云厂商提供的负载均衡中间件，比如aws（elb）、阿里云（slb）。这个负载均衡软件可以认为是 lvs+keepalived的高可用负载均衡服务

后端的service有可能部署在硬件条件不同的服务器上：
1）如果对标最低配的服务器“均匀”分摊负载，高配的服务器的利用率不足；
2）如果对标最高配的服务器“均匀”分摊负载，低配的服务器可能会扛不住；

（1）通过“静态权重”标识service的处理能力

优点： 简单，能够快速的实现异构服务器的负载均衡。
缺点： 权重是固定的，无法自适应动态调整，而很多时候，服务器的处理能力是很难用一个固定的数值量化。

（2）通过“动态权重”标识service的处理能力
提问：通过什么来标识一个service的处理能力呢？
回答：其实一个service能不能处理得过来，能不能响应得过来，应该由调用方说了算。调用服务，快速处理了，处理能力跟得上；调用服务，处理超时了，处理能力很有可能跟不上了。

动态权重设计：

例如：

（1）设置一个阈值，超过阈值直接丢弃

（2）借助“动态权重”来实施过载保护
案例策略：

1）service的负载均衡、故障转移、超时处理通常是RPC-client连接池层面来实施的
2）异构服务器负载均衡，最简单的方式是静态权重法，缺点是无法自适应动态调整
3）动态权重法，可以动态的根据service的处理能力来分配负载，需要有连接池层面的微小改动
4）过载保护，是在负载过高时，service为了保护自己，保证一定处理能力的一种自救方法
5）动态权重法，还可以用做service的过载保护

㈣ php负载均衡，服务器上传图片

又看到你了。
你理解错了吧，访问B服务器不一定上传就得上传到B服务器，图片服务器应该有自己的域名（img.xxx.com）用户访问的是B服务器做好的网站，但是使用上传时提交到的是A的域名。

㈤ Spring Cloud Gateway整合Nacos实现服务路由及集群负载均衡

我们都知道 Spring Cloud Gateway 是一个基于 Spring Boot 、 Spring WebFlux 、 Project Reactor 构建的高性能网关，旨在提供简单、高效的API路由。

Spring Cloud Gateway基于 Netty 运行，因此在传统Servlet容器中或者打成war包是不能正常运行的。

这里我们注册中心选型的是 Nacos ，如果还没有安装Nacos，请参考： Nacos快速安装部署 。

如果URI以==lb==开头，比如如上配置中的 lb://user-service ， Spring Cloud Gateway 会用 解析服务名为 user-service 的实例对应的实际host和端口，并做集群负载均衡。

这项功能通过全局过滤器 实现，官网描述如下：
[图片上传失败...(image-b13395-1655546589820)]

RouteRecordGlobalFilter 这个全局过滤器我们主要用来记录路由后的实际代理地址，以及调用耗时。

我们看下 RouteToRequestUrlFilter 的描述会发现实际路由地址会通过 ServerWebExchange 中名为 ServerWebExchangeUtils.GATEWAY_REQUEST_URL_ATTR 的属性保存。

[图片上传失败...(image-a33940-1655546589820)]

关于 RouteToRequestUrlFilter 的部分源码如下：

分别启动api-gateway、指定概要文件启动两个user-service服务实例、和两个message-service服务实例，查看Nacos控制台。
[图片上传失败...(image-34bdc6-1655546589820)]

可以看到，api-gateway启动了一个服务实例，user-service和message-service都启动了两个服务实例。

连续访问 http://localhost:9000/user/info ，可以看到user-service集群服务实例被轮询调用。

分别访问 http://localhost:9000/user/info 、 http://localhost:9000/message/info ，我们可以看到基于路径匹配的服务路由分发是成功的。

㈥ NFS架构(转载)

1.为什么用共享存储
2.存储有哪些工具
3.共享存储应用场景有哪些
4.部署nfs共享存储
5.客户端尝试连接共享存储
什么是NFS？
NFS 是 Network File System 的缩写及网络文件系统。 NFS 主要功能是通过局域网络让不同的主机系统之间可以共享文件或目录。
NFS 系统和 Windows 网络共享、网络驱动器类似, 只不过 windows 用于局域网, NFS 用于企业集群架构中, 如果是大型网站, 会用到更复杂的分布式文件系统 FastDFS,glusterfs,HDFS
那么我们为什么要使用数据存储共享服务？
1.实现多台服务器之间数据共享
2.实现多台服务器之间数据一致

下面我将通过图解给大家展示集群需要共享存储服务的理由。
1.A 用户上传图片经过负载均衡，负载均衡将上传请求调度至 WEB1 服务器上。
2.B 用户访问 A 用户上传的图片，此时 B 用户被负载均衡调度至 WEB2 上，因为 WEB2 上没有这张图片，所以 B用户无法看到 A 用户传的图片

如果有共享存储的情况
1.A 用户上传图片无论被负载均衡调度至 WEB1 还是 WEB2, 最终数据都被写入至共享存储
2.B 用户访问 A 用户上传图片时，无论调度至 WEB1 还是 WEB2，最终都会上共享存储访问对应的文件，这样就可以访问到资源了

NFS工作原理
1.用户进程访问 NFS 客户端，使用不同的函数对数据进行处理
2.NFS 客户端通过 TCP/IP 的方式传递给 NFS 服务端
3.NFS 服务端接收到请求后，会先调用 portmap 进程进行端口映射。
4.nfsd 进程用于判断 NFS 客户端是否拥有权限连接 NFS 服务端。
5.Rpc.mount 进程判断客户端是否有对应的权限进行验证。
6.idmap 进程实现用户映射和压缩
7.最后 NFS 服务端会将对应请求的函数转换为本地能识别的命令，传递至内核，由内核驱动硬件。
注意: rpc 是一个远程过程调用，那么使用 nfs 必须有 rpc 服务

1.nfs依赖于RPC服务来传递消息
2.NFS服务启动的端口号是随机的,启动之后会向本地的RCP注册
3.先启动RPC服务,再启动NFS服务
4.NFS和RPC之间的通讯是他们自己内部完成的,对于用户来说无感知
5.NFS客户端和服务端不会直接沟通,必须通过RPC服务传递消息
6.防火墙要开放RPC服务的端口

nfs 服务程序的配置文件为/etc/exports，需要严格按照共享目录的路径 允许访问的 NFS 客户端（共享权限参数）格式书写，定义要共享的目录与相应的权限，具体书写方式如下图所示

配置文件参数解释：
执行 man exports 命令，然后切换到文件结尾，可以快速查看如下样例格式：
nfs共享参数 参数作用
rw 读写权限
ro 只读权限
root_squash
当 NFS 客户端以 root 管理员访问时，映射为 NFS 服务器的匿名用户(不常用)
no_root_squash
当 NFS 客户端以 root 管理员访问时，映射为 NFS 服务器的 root 管理员(不常用)
all_squash
无论 NFS 客户端使用什么账户访问，均映射为 NFS 服务器的匿名用户(常用)
no_all_squash
无论 NFS 客户端使用什么账户访问，都不进行压缩
sync
同时将数据写入到内存与硬盘中，保证不丢失数据
async
优先将数据保存到内存，然后再写入硬盘；这样效率更高，但可能会丢失数据
anonuid
配置 all_squash 使用,指定 NFS 的用户 UID,必须存在系统

anongid
配置 all_squash 使用,指定 NFS 的用户 UID,必须存在系统

写入配置文件：注意！IP地址和后面的小括号没有空格

创建数据目录和授权:

在使用 NFS 服务进行文件共享之前，需要使用 RPC（Remote Procere Call 远程过程调用服务将 NFS 服务器的IP 地址和端口号信息发送给客户端。因此，在启动 NFS 服务之前，需要先重启并启用 rpcbind 服务程序,同时都加入开机自启动

客户端安装nfs服务十分简单，只需要安装nfs软件包即可

安装完成后只需要启动rpcbind，不需要启动nfs

使用showmount命令查看nfs共享信息查询 NFS 服务器的远程共享信息，其输出格式为“共享的目录名称 允许使用客户端地址”。

挂载命令: 创建挂载目录
在 NFS 客户端创建一个挂载目录, 使用 mount 命令并结合-t 参数, 指定要挂载的文件系统的类型, 并在命令后面写上服务器的 IP 地址, 以及服务器上的共享目录, 最后需要写上要挂载到本地系统(客户端)的目录

查看是否挂载成功：

测试写入数据是否正常

写入开机自动挂载

卸载命令：注意!卸载的时候如果提示”umount.nfs: /nfsdir: device is busy”先切换到其他目录再卸载

强制卸载命令：

服务端配置：

客户端挂载：

测试读取：

写入测试：

服务端配置：

服务端创建用户及授权：

重启NFS服务：

更改目录授权：

客户端操作:

我们会发现依然可以写入，但是为了避免这种情况发生，建议客户端也创建相同uid gid的用户

参考博客

启动NFS会开启如下端口：
1）portmapper 端口：111 udp/tcp；
2）nfs/nfs_acl 端口：2049 udp/tcp；
3）mountd 端口："32768--65535" udp/tcp
4）nlockmgr 端口："32768--65535" udp/tcp
系统 RPC服务在 nfs服务启动时默认会给 mountd 和 nlockmgr 动态选取一个随机端口来进行通讯。

1.查看NFS启动后的端口

2.将随机的端口号设置固定

3.重启nfs和rpc服务

4.再次查看端口信息,发现端口号已经固定了

5.设置iptables

6.保存配置

如果设置了开机自启动，但是系统启动的时候NFS并没有提供服务，就会导致开机自检的时候卡在挂在那一步

NFS 存储优点
1.NFS 文件系统简单易用、方便部署、数据可靠、服务稳定、满足中小企业需求。
2.NFS 文件系统内存放的数据都在文件系统之上，所有数据都是能看得见
NFS 存储局限
1.存在单点故障, 如果构建高可用维护麻烦 web->nfs()->backup
2.NFS 数据明文, 并不对数据做任何校验。
3.客户端挂载 NFS 服务没有密码验证, 安全性一般(内网使用)
NFS 应用建议
1.生产场景应将静态数据尽可能往前端推, 减少后端存储压力
2.必须将存储里的静态资源通过 CDN 缓存 jpg\png\mp4\avi\css\js
3.如果没有缓存或架构本身历史遗留问题太大, 在多存储也无用

准备 3 台虚拟机服务器，并且请按照要求搭建配置 NFS 服务。
NFS 服务端（A）
NFS 客户端（B）
NFS 客户端（C）
1.在 NFS 服务端(A)上共享/data/w(可写)及/data/r(只读)
2.在 NFS 客户端(B/C)上进行挂载
环境准备

㈦ 阿里slb做为k8s的负载均衡的限制

如果在本地搭建，我们可以使用haproxy+keepalived方式轻松实现k8s中的负载均衡，但是阿里的ecs不能使用keepalived,所以我们被迫只能使用阿里的 slb了。

既然keepalived的方式不能使用，那我们就使用阿里的slb进行负载均衡呗，由于该负载均衡不需要被外部访问，只提供对k8s集群节点之间的访问,所以我们就使用私网的slb。
[图片上传失败...(image-b02d7-1604545387128)]

我们保证该slb和k8s集群节点的node属于同一个局域网内，具体配置如下

第一步就是监听该slb的6443端口，该端口后端的服务器组分别是3台ecs的6443端口(apiserver服务)。接着我们可以 在master1节点 上执行如下命令

由于后端服务器组的 apiserver 都尚未运行，预期会出现一个连接拒绝错误。然而超时意味着负载均衡器不能和控制平面节点通信。 如果发生超时，请重新配置负载均衡器与控制平面节点进行通信。

我们在master1节点上创建kubeadm-config.yaml文件，用于初始化控制平面节点，如下。

接着我们在master1节点上执行如下命令初始化

最后结果如下

看上面的日志好像是kubelet的问题。我们先确认kubelet是否运行,发现处于running状态。

接着查看kubelet的日志

发现一个奇怪的问题，https://192.168.4.11:6443提示timeout。

接着我们在master1节点上首先测试本地的6443端口是否已经启用

看到master1节点的6443端口已经被占用，接着我们在 master1 节点测试slb的6443端口服务，按理说master1节点的6443服务已经启用，那么slb的6443服务也应该是可用可连通的。

遗憾的是slb的6443端口并没有连通，我们在master2,master3节点上分别连接slb的6443端口，发现都timeout。 我们又找了同一局域网内的另一台ecs，该ecs不属于slb的后端服务器，在该ecs上却能连接slb的6443端口 ，现在问题找到了：

带着这个疑问我们提了阿里工单，客服最后给出结论。

私网的slb是不可以使用了，我们换成公网slb之后重新按照上述流传执行一遍，最后初始化控制平面节点成功。

初始化之前slb的6443端口负载的后端服务器组的6443服务肯定都没有启动。
初始化开始后先在本地拉取相关镜像，随后apiserver等服务启动起来，也就是本地的6443服务已经启动。
接着验证slb的6443的连通性，由于master1节点的6443服务已经启动，那么slb的后端组在健康检查中就会发现有master1节点6443端口一起启动，所以slb的6443端口服务也就正常启动了。

通过上面的描述，在 控制平面节点 上大致需要满足以下俩点才能初始化成功

优点：可以将kubeconfig文件复制到你笔记本电脑上，进而可以在你本地访问集群，也正是由于这种方式可能造成安全泄漏的问题。
缺点：apiserver暴露的ip是公网ip，一是各个节点之间沟通的效率变低，二是具有安全性问题。

如果公司非得使用私网的话，我们可以采取这种方式，大概拓扑图如下

最上层是一个私网的slb,该slb的后端服务器组为俩个haproxy,使用俩台haproxy可以避免haproxy的单点故障，haproxy的后端服务器为3台k8s的master节点。

估计看到这里有人会有疑问，上面介绍的私网slb方式会导致四层监听的后端服务器无法访问私网SLB问题，那么该种方式就不会有这个问题吗？我们带着疑问进行测试。

我们准备6台ecs,配置如下

slb监听6443端口，该端口的后端服务器组为俩台haproxy并监听8888端口。

haproxy监听8888端口，该端口的后端服务器组为3台控制平面节点并监听6443端口,haproxy.cfg文件如下。

我们使用haproxy:1.7镜像，在俩台haproxy所在节点分别执行如下操作：

kubeadm-config文件中controlPlaneEndpoint参数应为私网slb+6443端口，配置文件如下

执行初始化，发现可以初始化成功

以下所有测试在 master1 节点上测试
我们首先测试master1节点的apserver服务，6443端口是否已经被占用

master1节点的6443端口显示已经被占用，接着我们测试haproxy节点的8888端口是否连通

显示haproxy的8888端口已经连通，接着测试slb的6443端口是否被占用,发现可以连通

到此说明我们的3层架构都已经连通,说明此方案是可以执行的。

之前提的那个疑问我们现在得到了答案。 但有一点是需要特别注意的

优点：由于中间多了一层haproxy，所以巧妙的解决了私网slb四层监听的后端服务器无法访问私网SLB问题。
缺点：很显而易见了，中间多了一层haproxy的转发代理，而且也增加了成本。

现在大概有俩中方式可以实现k8s的高可用，一种是使用公网slb的方式，另一种是使用私网+haproxy+node的方式，这俩中方式各有优缺点，结合自己的实际情况选择适合的方案。

㈧ 关于Nginx负载均衡目录同步问题

近期外包接单，做了一个简单的系统，本以为如此简单一个Tomcat就足以满足，结果客户要求需要两台服务器负载均衡，之前负载均衡都是由专门的人负责，第一次自己实现Nginx，走了不少弯路。

由于项目组有附件上传的功能，没有专门的文件服务器，将附件都存放在了ROOT底下，负载均衡后发现经常找不到图片，明显是因为两台服务器资源不同步的问题造成的，于是开始研究服务器目录同步，使用Rsync+Sersync实现目录同步，具体步骤：

1：制定两台服务器中的一台为主服务器（安装软件rsync+sersync，但是不需要启动rsync），另一台为从服务器(安装软件rsync，需要启动rsync)

2：从服务器安装完rsync需要对/etc/rsyncd.conf 进行配置：

uid = root                                  #拥有目录权限用户

gid = root                                  #拥有目录权限的组

use chroot = no                         #内网使用可以不用配置

max connections = 200              #最大连接数  

timeout = 300                               #超时时间

pid file = /var/run/rsyncd.pid              #启动进程写入此PID文件

lock file = /var/run/rsyncd.lock            #lock文件来配合最大连接数参数

log file = /var/log/rsyncd.log               #日志文件

ignore errors = yes                         #忽略I/O错误

read only = false                           #允许读写      

list = false                                #不列出列表

hosts allow = 192.168.1.0/24                #允许网段

hosts deny = *                              #拒绝其他网段

auth users = users                          #认证用户

secrets file = /opt/app/rsyncd/auth.pass    #密码文件

[web]                                       #同步目录

path = /backup/web

设置 /opt/app/rsyncd/auth.pass文件格式为user:password

给 /opt/app/rsyncd/auth.pass添加600权限 chmod 600  /opt/app/rsyncd/auth.pass

启动rsync  rsnyc --daemon

3：主服务器部署

主服务器安装完sersync后需要配置confxml.xml，在sersync的安装目录下

<sersync>

    <!--<remote ip="192.168.8.39" name="tongbu"/>-->

    <!--<remote ip="192.168.8.40" name="tongbu"/>-->

    </localpath>

     <rsync>

     <commonParams params="-artuz"/>

       <timeout start="false" time="100"/><!-- timeout=100 -->

        <ssh start="false"/>

        </rsync>

<failLog path="/tmp/rsync_fail_log.sh" timeToExecute="60"/>

<!--default every 60mins execute once-->

<crontab start="false" schele="600"><!--600mins-->

 <crontabfilter start="false">

   <exclude expression="*.php"></exclude>

  <exclude expression="info/*"></exclude>

            </crontabfilter>

        </crontab>

        <plugin start="false" name="command"/>

    </sersync>

启动sersync :/opt/soft/sersync/sersync/sersync2 -d -r -o /opt/soft/sersync/sersync/confxml.xml

location ~ .*\.(gif|jpg|jpeg|png|flv|mp3)$ { #静态

          proxy_pass http://192.168.1.12:80/;

        }

㈨ 在供电的公众号上申请电表，上传图片资料时一直显示失败

未能上传图片原因主要有以下两种情况：
1.可能由于图片大小不符合上传要求，建议您将图片大小调整为小于5M，再重新上传。
2.网络异常导致无法上传。请换个时间再重新上传。
如图片小于5M并且网络正常仍无法上传，建议您拨打95598供电服务热线进行反映，供电企业将安排相关客户经理为您跟进处理。
希望我们的回答能对您有所帮助。

㈩ 关于linux中利用nginx+tomcat配置负载均衡并实现session复制的问题，用户上传的图片文件该怎么处理

占点空间算个毛线的事，如果要不占用空间，就要重新设计架构，有哪个时间还不如多捞点钱，什么空间的钱都赚几十倍出来了，要不然就等着被老板喷吧。