负载均衡

课程目录 1.dubbo框架介绍 2.dubbo服务注册与发现，调用 3.dubbo负载均衡 4.dubbo集群容错 5.dubbo与springboot整合 带着问题去学习 了解一个框架并不是说，知道这个东西怎么用就好了，而是要去细致的了解这个框架，这个应用可以干什么，可以为我们带来什么便利。 1. dubbo是什么 Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。 2.为什么要使用dubbo 项目初始阶段： 随着用户量的增多，可以增加应用服务器进行负载，短期内可以产生非常大的成效，但是长期来看投入产出比会逐渐的下降。这时候会对服务进行拆分。 各种业务层、服务层之间的调用一定是通过某种远程RPC技术进行调用。这时候就涉及到以下几个问题： 1.地址维护（当服务越来越多时，服务 URL 配置管理变得非常困难）； 2.负载均衡（当服务越来越多时，F5 硬件负载均衡器的单点压力也越来越大）； 3.限流/容错/降级； 4.链路监控； 解决方案 如果我们使用比如WebService或者简单的使用Http进行调用是没有办法解决这几个问题的。因为这些技术只能实现一个远程的调用，但是在大规模服务化后很多问题都无法解决。Dubbo就是其中一种解决方案。 1.关于地址服务，这时候需要一个服务注册中心

1.nginx的配置文件 nginx 配置文件的整体结构 　　 user nobody nobody; # 指定Nginx Worker进程运行用户以及用户组，默认由nobody账号运行,nobody 是系统用户,是一个不能登陆的帐号，一个特殊用途的用户 ID #启动进程,通常设置成和cpu的数量相等 worker_processes 1; #指定了Nginx要开启的进程数。每个Nginx进程平均耗费10M~12M内存。建议指定和CPU的数量一致即可。 #全局错误日志及PID文件 用来定义全局错误日志文件。日志输出级别有debug、info、notice、warn、error、crit可供选择，其中，debug输出日志最为最详细，而crit输出日志最少 #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; #pid logs/nginx.pid; # pid是个主模块指令，用来指定进程pid的存储文件位置worker_rlimit_nofile 65535; #用于绑定worker进程和CPU， Linux内核2.4以上可用 #工作模式及连接数上限 events { #epoll是多路复用IO(I/O Multiplexing)中的一种方式,

负载均衡的算法 前言 关于负载均衡，我们需要了解，而且在面试的过程中，你懂得。 对于要实现高性能集群，选择好负载均衡器很重要，同时针对不同的业务场景选择合适的负载均衡算法也是非常重要的。 一、源地址哈希算法 唯一不丢失策略的算法，但是负载均衡和源数据信息和哈希算法有很大关系。 源地址哈希法的思想是根据服务消费者请求客户端的 IP 地址，通过哈希函数计算得到一个哈希值，将此哈希值和服务器列表的大小进行取模运算，得到的结果便是要访问的服务器地址的序号。采用源地址哈希法进行负载均衡，相同的 IP 客户端，如果服务器列表不变，将映射到同一个后台服务器进行访问。 伪代码： private static Map<String, Integer> serviceWeightMap = new HashMap<String, Integer>(); static { serviceWeightMap.put("192.168.1.100", 1); serviceWeightMap.put("192.168.1.101", 1); serviceWeightMap.put("192.168.1.102", 4); serviceWeightMap.put("192.168.1.103", 1); } public static String testConsumerHash(String

、##### 负载均衡简单理解： 负载均衡分为两种： 1、客服端负载均衡 2、服务端负载均衡 1、服务端负载均衡 是通过负载均衡器来维护一份服务端列表，比如nginx，就是通过nginx里面来配置多个url，根据负载均衡算法，将请求转发到相应的服务器上面，实现负载均衡。 2、客户端负载均衡 客户端负载均衡与服务端负载均衡最大的区别，就在于每个客户端服务都要有一份要访问的清单，即服务消费者这里需要存一份服务提供者的清单，dubbo架构从zookeeper注册中心获取，spring cloud架构从Eureka Server中获取，然后采用各自的负载均衡算法，dubbo提供有负载均衡算法，spring cloud采用Ribbon的负载均衡，实现服务消费者调用服务提供者的过程的负载均衡 来源： CSDN 作者： songsongDBB28 链接： https://blog.csdn.net/weixin_43231076/article/details/103738711

文章目录 摘要 Ribbon简介 RestTemplate的使用 GET请求方法 getForObject方法 getForEntity方法 POST请求方法 postForObject示例 postForEntity示例 PUT请求方法 PUT请求示例 DELETE请求方法 DELETE请求示例 创建一个user-service模块 在pom.xml中添加相关依赖 在application.yml进行配置 创建用户类User和统一返回前端的响应类Result 添加UserController用于提供调用接口 创建一个ribbon-service模块 在pom.xml中添加相关依赖 在application.yml进行配置 使用@LoadBalanced注解赋予RestTemplate负载均衡的能力 添加UserRibbonController类 负载均衡功能演示 Ribbon的常用配置 全局配置 指定服务进行配置 Ribbon的负载均衡策略 使用到的模块 项目源码地址 项目使用的Spring Cloud为Hoxton版本，Spring Boot为2.2.2.RELEASE版本 摘要 Spring Cloud Netflix Ribbon 是Spring Cloud Netflix 子项目的核心组件之一，主要给服务间调用及API网关转发提供负载均衡的功能，本文将对其用法进行详细介绍

客串： 屌丝的坑人表单神器 走过的那些事儿： 数据库那点事儿 推荐： 手把手教你做关键词匹配项目（搜索引擎）---- 第一天 最新： 手把手教你做关键词匹配项目（搜索引擎）---- 第十八天 文章开始，先吐槽一下:博客的文章都是技术文章，尼玛就不能多点心路历程，XX管理，处事态度，传说中的求职的事儿以及那些年所遇到的萌人萌事。 一说到负载均衡，很多人都认为高、大、上。所以那些开发就把它供得高高在上，想去触摸，又不敢去。 接下来的课程，我们来一起把那所谓的负载均衡踩扁它。 首先我们来了解负载均衡是个啥玩意儿？ 前面有1000个妞等着你来泡，这1000个妞等久了有可能不耐烦，就会走了不让你泡了。你要想同时泡1000个妞，那你就得有分身的能力才行。 只要有了分身的能力，你就再也不用担心妞泡不过来了。 结论得出： 负载均衡 == 分身的能力 你的分身把这个妞泡准了，你这个分身就要跟她一直谈下去，其他的妞过来了你肯定要拒绝丫。 你没泡成功，当然是去寻找下一个目标。 结论得出： 负载均衡还得保持通话 你的分身也偶尔发发小脾气，没激情来泡妞的时候，你就要去修理他，去找他聊聊心。 结论得出： 负载均衡还要懂得修理他（T出泡妞队营） 尼玛负载均衡就为了泡妞，我们果断一起踩扁它。 负载均衡现在市场上面已经有很多成熟的硬件设备，可以掏点钱就可以买了。当然这费用嘛...... 如果你闲费用贵

1.1 什么是负载均衡高可用 nginx作为负载均衡器，所有请求都到了nginx，可见nginx处于非常重点的位置，如果nginx服务器宕机后端web服务将无法提供服务，影响严重。 为了屏蔽负载均衡服务器的宕机，需要建立一个备份机。主服务器和备份机上都运行高可用（High Availability）监控程序，通过传送诸如“I am alive”这样的信息来监控对方的运行状况。当备份机不能在一定的时间内收到这样的信息时，它就接管主服务器的服务IP并继续提供负载均衡服务；当备份管理器又从主管理器收到“I am alive”这样的信息时，它就释放服务IP地址，这样的主服务器就开始再次提供负载均衡服务。 1.2 keepalived+nginx实现主备 1.2.1 什么是keepalived keepalived是集群管理中保证集群高可用的一个服务软件，用来防止单点故障。 Keepalived的作用是检测web服务器的状态，如果有一台web服务器死机，或工作出现故障，Keepalived将检测到，并将有故障的web服务器从系统中剔除，当web服务器工作正常后Keepalived自动将web服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的web服务器。 1.2.2 keepalived工作原理 keepalived是以VRRP协议为实现基础的

1. Nginx负载均衡高可用 首先介绍一下Keepalived，它是一个高性能的服务器高可用或热备解决方案，Keepalived主要来防止服务器单点故障的发生问题，可以通过其与Nginx的配合实现web服务端的高可用。 Keepalived以VRRP协议为实现基础，用VRRP协议来实现高可用性（HA）.VRRP (Virtual Router Redundancy Protocol)协议是用于实现路由器冗余的协议，VRRP协议将两台或多台路由器设备虚拟成一个设备，对外提供虚拟路由器IP（一个或多个），如下图所示： 这张图的意思是，我们使用keepalived来管理两台设备的Nginx，并虚拟出一个IP，我们现在两台装有Nginx的设备分别是192.168.101.3和192.168.101.4，那么我们可以虚拟出一个192.168.156.xx的IP，外界请求直接访问虚拟IP而不是真正的Nginx，让虚拟IP去访问提供服务的Nginx（注意：高可用是指同一时间提供服务的只有一台设备，提供服务的设备挂掉之后，备份服务器便开始提供服务），然后再由Nginx去访问tomcat。 要实现nginx的高可用，需要实现备份机。 我们拿两台虚拟机来搭建nginx高可用环境，这两台设备分别是192.168.101.3（主机名是nginx1）和192.168.101.4（主机名是nginx2）。

1：反向代理 代理就是中介，那有反向代理就有正向代理，两者的区别是什么嘞？ 正向代理隐藏真实客户端，服务端不知道实际发起请求的客户端.，proxy和client同属一个LAN，对server透明； 反向代理隐藏真实服务端，客户端不知道实际提供服务的服务端，proxy和server同属一个LAN，对client透明。 基本配置项　 　（1）proxy_pass 将当前请求反向代理到URL参数指定的服务器上 （2）proxy_method 表示转发时的协议方法名 proxy_method POST; 客户端转发来的GET请求在转发时方法名会改为POST请求 （3）proxy_redirect 当上游服务器返回的响应是重定向或者刷新请求（HTTP响应码是301或者302），可以重设HTTP头部的location或refresh proxy_redirect http://location:8000/two/ http://location:8000/noe/ （4）proxy_next_upstream 当上游服务器请求出现错误，继续换一台服务器转发请求。 　　　　error:在与服务器建立连接，向其传递请求或读取响应标头时发生错误; 　　　　timeout:在与服务器建立连接，向其传递请求或读取响应头时发生超时 　　　　invalid_header:服务器返回空响应或无效响应; 　　　

Kafka是目前非常流行的消息队列中间件，常用于做普通的消息队列、网站的活性数据分析（PV、流量、点击量等）、日志的搜集（对接大数据存储引擎做离线分析）。 全部内容来自网络，可信度有待考证！如有问题，还请及时指正。 概念介绍 在Kafka中消息队列分为三种角色: producer ，即生产者，负责产生日志数据。 broker ，存储节点，负责按照 topic 中的 partition 分区，均匀分布式的存储分区。 consumer ，即消费者，负责读取使用 broker 中的分区。 producer Kafka系统中的生产者，用于产生数据并发送给broker进行存储。由于需要与broker中的分区保持socket连接，因此需要在zk中维护生产者与分区broker的对应关系。同一个topic下的数据，会以某种负载均衡的方式发送到不同的分区中。 broker Broker可以当做Kafka中的存储节点，数据按照topic组织，按照某种负载均衡方式分配到不同的分区中。一个Topic由多个分区组成，每个分区可以设置备份数量。分区由一个leader+多个followers组成，生产者直接与leader进行沟通，leader接收消息后，其他的followers会同步这个消息。所有的follwers同步消息后，该消息才会成为可消费的状态。 Broker中Topic与分区，分区与生产者