负载均衡

补充：负载均衡和读写分离楼主并没有尝试使用过，这里作为学习笔记，有些只是概念性的理解一下，后续补充具体案例及使用方法介绍 负载均衡 概念 多个服务器的数据库完成一个服务器数据库的事 ( 数据库必须保持一致性 ) 利用多台服务器的读写能力，但是数据同步和访问分配交给第三方，读的压力分摊到不同的 服务器，写时多台服务器都得完成，对外只有一个 IP ，使用者是不知道细节的 读写分离 概念 基于二八原则： 80% 的操作都是读， 20%s 写。实现原理：就是把读和写的眼里分开，降低 IO 压力 一主多从，主库写从库读。数据同步，从主库到从库 ( 肯定是有延迟的 ) 四种读写分离方式 1 Link 到主库 + 定时任务 2 日志传送 (sql2005) 实现原理：备份 -- 复制 -- 恢复，简单但是有局限性 ( 局域网，只能文件夹共享 ) 3 镜像 snapshot ：内存拍照 主库，对外提供服务。 从库，通过快照恢复，数据跟主库一致 ( 不对外提供服务 ) 监控转移，负责检查状况，有问题切到从库 4 数据复制 ( 发布订阅 ) 主库 -- 发布服务器 -- 从库 延迟小，配置方便，但是需要程序配合 实现方式参考 ： https://blog.csdn.net/u012861467/article/details/76411216 https://blog.csdn.net/qq

10.1 负载均衡的概念 对用户请求的数据进行调度的作用 对用户访问的请求网站可以进行压力的分担 10.2 常见的代理方式 10.2.1 正向代理 10.2.2 反向代理 10.3 负载均衡的部署环节 10.3.1 服务器的准备 lb01 服务器 :172.16.1.5 web01 服务器 :172.16.1.7 web02 服务器 :172.16.1.8 10.3.2 服务器环境的准备 10.3.2.1 web 服务器的配置(172.16.1.7,172.16.1.8) [root@web02 ~] # cd /etc/nginx/conf.d/ [root@web02 conf.d] # vim www.conf server { listen 80; server_name www.oldboy.com; location / { root /html/www; index index.html index.htm; } } [root@web01 conf.d] # cd /html/ 创建站点目录 [root@web01 html] # mkdir -p www [root@web01 html] # cd www [root@web01 www] # echo "$(hostname -i) www.oldboy.com" > index.html [root

静态路由 原理概述 由管理员手工配置和维护的，是单向的路由，可实现负载均衡和路由备份。 配置： ip route 目标网段地址目标网段掩码下一跳地址/出接口 ip route-static 192.168.1.0 255.255.255.0 10.0.12.1 浮动静态路由：静态路由备份技术（平时查看路由表不可见，当原有链路断时生效） 缺省路由：目的地址和掩码都为 0 的特殊路由，报文的目的地址无法匹配时按照缺省路由转发（转发给运营商就不管了）。 静态路由实验： 拓扑图： 一、配置 PC 的 IP 因为 PC1 和 PC2 再同一网段，所以之间可以 ping 通 PC1 和 PC3 不在同一网段，所以之间 ping 不通 二、配置路由器 1. 配置端口 E0/0/0 R1: R2: 配置端口 S0/0/0 R1: R2: 测试一下 尝试 PC1pingPC3 发现还是 ping 不通，查看一下 R1 抓包，是有数据传到的；查看 R2 的抓包，发现在有请求包，没有回复包，此时需要创建静态路由。 此时 PC1pingPC3 、 PC4 就可以通了 至此，静态路由的实验已经完成了！ 浮动静态路由 及负载均衡 实验： R1 为总部， R2/R3 是两个分部，现需要总部与各个分部都能够通信，且分部之间在通信时，直连链路为主要链路，通过分部的链路为备用链路。本实验使用浮动静态路由实现需求

这几篇将API安全的 流控、认证、审计、授权 简单的过一遍，对这些概念先有个 初步印象 。后边还会详细讲解。 本篇说API安全之 流控 ~ 第一印象。 一、概念 流控， 流量控制，只放系统能处理的请求的数量过去， 处于api安全链路的第一关。 为什么要做流控？保证系统的可用性，防止大流量把系统给压死。流控的位置做在认证、审计、授权等整个安全机制的最前边，提前控制流量，避免其他无用的资源浪费。 如果没有流控放在第一道档线，攻击者弄一堆 肉鸡 ，发起 DDOS 攻击，即使你后边的认证、审计、授权 做得再好，也可能把你的服务压死。 比如系统每秒只能处理500个请求，那么每秒就放500个请求过去，多了的请求直接拒绝掉，这样的话系统不会被压死。实际中的流控是非常复杂的，不是简单地设个数就完了。 二，流控做在哪？ 实际开发中限流可以在很多地方做的， 比如： 1，在负载均衡上做， 2，在反向代理上做， 在负载均衡或反向代理层面上做限流，实际上一般是针对真个集群做的限流。比如你一个用户服务，实际部署的时候可能是四个机器或者八个机器的集群，在负载均衡或反向代理层面做的集群就是真对整个集群做的限流，整个集群能撑多少流量，做个限流。 3，在自己的应用代码上做。 只针对单个应用的节点做的流控，跟反向代理、负载均衡做的限流不是一个维度的，如果能配的话，把两边都配上，他们并不冲突

实验环境 实验拓扑图 实验编址 实验步骤 在各个路由器中进入端口以后，用 ip address 命令来设置各个端口的ip地址。以R1为例。 首先实现两分部之间，总部与两分部之间的通信。在R1，R2，R3上分别进行如下静态路由的配置。 配置完成以后使用命令 display ip routing-table 查看R1的路由表。发现R1上已经存在以主机PC2为目的的路由条目。 此时测试PC1与PC2的连通性，发现两台主机已经可以ping通。 此时可以用 tracert 命令来测试所经过的网关。发现数据经过R1和R3到达PC2的。在PC2上也可以ping通PC1并且是通过R3和R1到达PC1的，这里就不再展示了。 然后在公司总部测试到达两个分部的连通性。均可以正常到达。 我们可以设置路由备份使R3链路故障时，PC1的数据仍然可以通过R2那条链路发送给PC2。 在R1上指定下一条为R2并将优先级设置为100。（默认为60） 再次查看R1的路由表。但是发现路由表中数据没有变化。 使用命令 display ip routing-table protocol static 查看静态路由的路由信息。此时优先级为100 和60的两条链路均已存在。在R3上做相同的配置，使PC2到达PC1时也可以经过两条路径，此处不再展示。 将R1的S1/0/1端口关闭测试备份路由的可行性。使用 tracert

服务发现角色 服务发现有三个角色，服务提供者、服务消费者和服务中介。 服务中介：联系服务提供者和服务消费者的桥梁。 服务提供者：将自己提供的服务地址注册到服务中介。 服务消费者：从服务中介那里查找自己想要的服务的地址，然后享受这个服务。 服务中介提供多个服务，每个服务对应多个服务提供者。 服务发现的模式 目前，服务发现主要存在有两种模式，客户端模式与服务端模式，两者的本质区别在于，客户端是否保存服务列表信息。下面用两个图来表示客户端模式与服务端模式。 客户端模式 在客户端模式下，如果要进行微服务调用，首先要周期性到服务注册中心获取服务列表（客户端维护这个这个服务列表），然后再根据调用端本地的负载均衡策略，进行服务调用。 服务端模式 在服务端模式下，调用方直接向服务注册中心进行请求，服务注册中心再通过自身负载均衡策略，对微服务进行调用。这个模式下，调用方不需要在自身节点维护服务发现逻辑以及服务注册信息，这个模式相对来说比较类似DNS模式。 客户端模式与服务端模式 总结服务端模式和客户端模式的区分 客户端模式：所有客户端需要维护服务列表信息，负载均衡策略而服务端模式下则无需这些额外的实现。 服务端模式：客户端每次请求都必须访问服务中介，获得服务列表，负载均衡策略等是服务端实现。 服务端模式下，更容易实现多语言的接入，更具有通用性，但是在客户端模式下

摘自： https://www.cnblogs.com/chenhg/p/11960941.html windows下的nginx应用 nginx（背景） 　　　　nginx是一个高性能的HTTP服务器，以前我经常在linux系统中配置，主要做反向代理和负载均衡，最近根据业务需要，需要在window中配置反向和负载，下面就介绍一下nginx的安装与使用 nginx介绍 　Nginx是一款 轻量级 的 Web 服务器/ 反向代理 服务器及 电子邮件 (IMAP/POP3)代理服务器，并在一个BSD-like 协议下发行。其特点是占有内存少， 并发 能力强　并发量在50,000 【官方】 nginx的下载和安装 　　下载： http://nginx.org/en/download.html 　　点进去选择版本下载即可：如图 　　　　　　　　　　　 　　　　　　　　　　下载解压： 　　　　　　　　　　　　 　　　　　　　　　　进入nginx文件夹，双击nginx.exe即可简单启动【命令在最后会贴出来】 　　　　　　　　　　　双击后黑窗口闪退，可以在任务管理器中查看nginx进程 　　　　　　　　　　　　 　　　　　　　　　　然后在浏览器输入localhost 　　　　　　　　　　 　　　　　　nginx的简单启动已经测试通过 　　　　　　 注意

nginx（背景） 　　　　nginx是一个高性能的HTTP服务器，以前我经常在linux系统中配置，主要做反向代理和负载均衡，最近根据业务需要，需要在window中配置反向和负载，下面就介绍一下nginx的安装与使用 nginx介绍 　Nginx是一款 轻量级 的 Web 服务器/ 反向代理 服务器及 电子邮件 (IMAP/POP3)代理服务器，并在一个BSD-like 协议下发行。其特点是占有内存少， 并发 能力强　并发量在50,000 【官方】 nginx的下载和安装 　　下载： http://nginx.org/en/download.html 　　点进去选择版本下载即可：如图 　　　　　　　　　　　 　　　　　　　　　　下载解压： 　　　　　　　　　　　　 　　　　　　　　　　进入nginx文件夹，双击nginx.exe即可简单启动【命令在最后会贴出来】 　　　　　　　　　　　双击后黑窗口闪退，可以在任务管理器中查看nginx进程 　　　　　　　　　　　　 　　　　　　　　　　然后在浏览器输入localhost 　　　　　　　　　　 　　　　　　nginx的简单启动已经测试通过 　　　　　　 注意：根据不同的系统可能会出现80端口被占用的情况，eg，在win10下，80端口可能被IIS程序占用，只需要改nginx的默认端口就行了 nginx的反向代理 　　　　反向代理

原文链接: https://www.cnblogs.com/tommyli/p/3766189.html ZooKeeper 典型应用场景一览 数据发布与订阅（配置中心） 发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务式服务框架的服务地址列表等就非常适合使用。 应用中用到的一些配置信息放到ZK上进行集中管理。这类场景通常是这样：应用在启动的时候会主动来获取一次配置，同时，在节点上注册一个Watcher，这样一来，以后每次配置有更新的时候，都会实时通知到订阅的客户端，从来达到获取最新配置信息的目的。 分布式搜索服务中，索引的元信息和服务器集群机器的节点状态存放在ZK的一些指定节点，供各个客户端订阅使用。 分布式日志收集系统。这个系统的核心工作是收集分布在不同机器的日志。收集器通常是按照应用来分配收集任务单元，因此需要在ZK上创建一个以应用名作为path的节点P，并将这个应用的所有机器ip，以子节点的形式注册到节点P上，这样一来就能够实现机器变动的时候，能够实时通知到收集器调整任务分配。 系统中有些信息需要动态获取，并且还会存在人工手动去修改这个信息的发问。通常是暴露出接口，例如JMX接口，来获取一些运行时的信息。引入ZK之后，就不用自己实现一套方案了

上篇文章和大家聊了 Spring Session 实现 Session 共享的问题，有的小伙伴看了后表示对 Nginx 还是很懵，因此有了这篇文章，算是一个 Nginx 扫盲入门吧！ 基本介绍 Nginx 是一个高性能的 HTTP 和反向代理 web 服务器，同时也提供了 IMAP/POP3/SMTP 服务。 Nginx 是由伊戈尔·赛索耶夫为俄罗斯访问量第二的 Rambler.ru 站点开发的，第一个公开版本 0.1.0 发布于 2004 年 10 月 4 日。 Nginx 特点是占有内存少，并发能力强。 事实上 nginx 的并发能力确实在同类型的网页服务器中表现较好，一般来说，如果我们在项目中引入了 Nginx ，我们的项目架构可能是这样： 在这样的架构中 ， Nginx 所代表的角色叫做负载均衡服务器或者反向代理服务器，所有请求首先到达 Nginx 上，再由 Nginx 根据提前配置好的转发规则，将客户端发来的请求转发到某一个 Tomcat 上去。 那么这里涉及到两个概念： 负载均衡服务器 就是进行请求转发，降低某一个服务器的压力。负载均衡策略很多，也有很多层，对于一些大型网站基本上从 DNS 就开始负载均衡，负载均衡有硬件和软件之分，各自代表分别是 F5 和 Nginx （目前 Nginx 已经被 F5 收购），早些年，也可以使用 Apache 来做负载均衡，但是效率不如