负载均衡

ribbon的负载均衡策略 com.netflix.loadbalancer.RandomRule：从提供服务的实例中以随机的方式； com.netflix.loadbalancer.RoundRobinRule：以线性轮询的方式，就是维护一个计数器，从提供服务的实例中按顺序选取，第一次选第一个，第二次选第二个，以此类推，到最后一个以后再从头来过； com.netflix.loadbalancer.RetryRule：在RoundRobinRule的基础上添加重试机制，即在指定的重试时间内，反复使用线性轮询策略来选择可用实例； com.netflix.loadbalancer.WeightedResponseTimeRule：对RoundRobinRule的扩展，响应速度越快的实例选择权重越大，越容易被选择； com.netflix.loadbalancer.BestAvailableRule：选择并发较小的实例； com.netflix.loadbalancer.AvailabilityFilteringRule：先过滤掉故障实例，再选择并发较小的实例； com.netflix.loadbalancer.ZoneAwareLoadBalancer：采用双重过滤，同时过滤不是同一区域的实例和故障实例，选择并发较小的实例。 配置方法 1.常用配置 ribbon:

算法介绍 ip_hash算法的原理很简单，根据请求所属的客户端IP计算得到一个数值，然后把请求发往该数值对应的后端。 所以同一个客户端的请求，都会发往同一台后端，除非该后端不可用了。ip_hash能够达到保持会话的效果。 ip_hash是基于round robin的，判断后端是否可用的方法是一样的。 第一步，根据客户端IP计算得到一个数值。 hash1 = (hash0 * 113 + addr[0]) % 6271; hash2 = (hash1 * 113 + addr[1]) % 6271; hash3 = (hash2 * 113 + addr[2]) % 6271; hash3就是计算所得的数值，它只和初始数值hash0以及客户端的IP有关。 第二步，根据计算所得数值，找到对应的后端。 w = hash3 % total_weight; while (w >= peer->weight) { w -= peer->weight; peer = peer->next; p++; } total_weight为所有后端权重之和。遍历后端链表时，依次减去每个后端的权重，直到w小于某个后端的权重。 选定的后端在链表中的序号为p。因为total_weight和每个后端的weight都是固定的，所以如果hash3值相同， 则找到的后端相同。 指令的解析函数

讲师介绍: 稳定性建设: 如何做到服务9999的稳定性即每年不可用时间不到1min 高性能系统: 滴滴运营广告系统即并发量很大 社招面试: 秒杀系统的设计与实现,其本质高并发高可用,这两方面的技术可直接决定公司技术水平,提现个人技术实力 概要: 基本知识和原理 减而治之 cdn原理: 减少读的压力,如订单详情页下发到不同地方的cdn节点,访问加速,回源减少 Nginx限流: 请求到达服务端(即接入层)如何做过载保护 异步队列概念: 如通过异步方式创建订单 分而治之 Nginx负载均衡: 流量到达接入层,接入层分摊到每个server层 难点分析架构思路: 结合具体应用场景分析难点及如何架构 特征 写的强一致性: 抢购时不能发生超卖现象 读的弱一致性: 显示有库存,但下单不成功即减不了库存(如:12306,总库存和实际抢票的库存可以不一致) 难点 极致性能的实现: 可用上万台机器分摊流量达到负载均衡,但成本高; 应该提高单个服务的极致性能 高可用的保证 核心实现思路 极致性能的读服务实现: 需要实时读的库存数 极致性能的写服务实现: 扣库存,同时创建订单 极致性能的排队进度查询实现: 频繁查询排队进展 链路流量优化如何做: 流量第一次到达lvs层( Linux Virtual Server)->接入层->server层->客户端,如何减少每层流量,实现漏斗型流量过滤 兜底方案-高可用

一、ribbon提供的负载均衡策略 RoundRobinRule 轮询 RandomRule 随机 AvailabilityFilteringRule 会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务，还有并发的连接数超过阈值的服务，然后对剩余的服务列表进行轮询 WeightedResponseTimeRule 权重 根据平均响应时间计算所有服务的权重，响应时间越快服务权重越大被选中的概率越高。刚启动时，如果统计信息不足，则使用轮询策略，等信息足够，切换到 WeightedResponseTimeRule RetryRule 重试 先按照轮询策略获取服务，如果获取失败则在指定时间内重试，获取可用服务 BestAvailableRule 选过滤掉多次访问故障而处于断路器跳闸状态的服务，然后选择一个并发量最小的服务 ZoneAvoidanceRule 符合判断server所在区域的性能和server的可用性选择服务 二、配置方法。 @Bean public IRule myRule(){ return new BestAvailableRule(); } 来源： https://www.cnblogs.com/yechen2019/p/11988428.html

UPSTREAM 语法: upstream name { ... } 默认值: — 上下文: http Defines a group of servers. Servers can listen on different ports. In addition, servers listening on TCP and UNIX-domain sockets can be mixed. 定义一组服务器。 这些服务器可以监听不同的端口。 而且，监听TCP和UNIX域套接字的服务器可以混用。 Example: upstream backend { server backend1.example.com weight=5; server 127.0.0.1:8080 max_fails=3 fail_timeout=30s; server unix:/tmp/backend3; server backup1.example.com backup; } By default, requests are distributed between the servers using a weighted round-robin balancing method. In the above example, each 7 requests will be distributed as

在生产应用中，某台“Nginx+PHP+MySQL”接口数据服务器，扮演的角色十分重要，如果服务器硬件或Nginx、MySQL发生故障，而短时间内无法恢复，后果将非常严重。为了避免单点故障，我设计了此套方案，编写了failover.sh脚本，实现了双机互备、全自动切换，故障转移时间只需几十秒。 2、解释： 　　(1)、假设外网域名blog.s135.com解析到外网虚拟IP 72.249.146.214上，内网hosts设置db10对应内网虚拟IP 192.168.146.214 　　(2)、默认情况下，由主机绑定内、外网虚拟IP，备机作为备份，当主机的MySQL、Nginx或服务器出现故障无法访问时，备机会自动接管内、外网虚拟IP。两台服务器都启动负责监控、自动切换虚拟IP的守护进程/usr/bin/nohup /bin/sh /usr/local/webserver/failover/failover.sh 2>&1 > /dev/null & 　　(3)、主机和备机上的MySQL服务器互为主从，互相同步。在主机处于活动状态（即由主机绑定虚拟IP）时，读写主机的MySQL，写到主机的数据会同步到备机；在备机处于活动状态时，读写备机的MySQL，写到备机的数据会同步到主机（如果主机上的MySQL死掉暂时无法同步，主机上的MySQL恢复后，数据会自动从备机上同步过来，反之亦然）。

Service service的概念 Kubernetes Service定义了这样一种抽象:一个Pod的逻辑分组,一种可以访问它们的策略-通常称为微服务。这一组Pod能够被Service访问到,通常是通过Label selector Service能够提供负载均衡的能力,但是在使用上有以下限制: 只提供4层负载均衡能力,而没有7层功能,但有时我们可能需要更多的匹配规则来转发请求,这点上4层负载均衡是不支持的 Service的类型 Service在K8s中有以下四种类型 Clusterlp:默认类型,自动分配一个仅cluster内部可以访问的虚拟IP NodePort:在ClusterlP基础上为Service在每台机器上绑定一个端口,这样就可以通过: Nodeport来访问该服务 LoadBalancer:在NodePort的基础上,借助cloud provider创建一个外部负载均衡器,并将请求转发到: NodePort ExternalName:把集群外部的服务引入到集群内部来,在集群内部直接使用。没有任何类型代理被创建这只有kubernetes 1.7或更高版本的kube-dns才支持 VIP和Service代理 在Kubernetes集群中,每个Node运行一个kube-proxy进程。kube-proxy负责为Service实现了一种 VIP (虚拟IP)的形式

什么是端口转发 版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 转载原文链接： https://www.cnblogs.com/chanshuyi/p/5113424.html ，感谢原作者，本文仅供学习 存档备用 当 我们在服务器上搭建一个图书以及一个电影的应用，其中图书应用启动了 8001 端口，电影应用启动了 8002 端口。此时如果我们可以通过： localhost:8001 //图书 localhost:8002 //电影 但我们一般访问应用的时候都是希望不加端口就访问域名，也即两个应用都通过 80 端口访问。 但我们知道服务器上的一个端口只能被一个程序使用，这时候如何该怎么办呢？一个常用的方法是用 Nginx 进行端口转发。 Nginx 的实现原理是：用 Nginx 监听 80 端口，当有 HTTP 请求到来时，将 HTTP 请求的 HOST 等信息与其配置文件进行匹配并转发给对应的应用。例如当用户访问 book.douban.com 时，Nginx 从配置文件中知道这个是图书应用的 HTTP 请求，于是将此请求转发给 8001 端口的应用处理。当用户访问 movie.douban.com 时，Nginx 从配置文件中知道这个是电影应用的 HTTP 请求，于是将此请求转发给 8002 端口的应用处理。一个简单的

上篇我们介绍了下面这个简单的语音聊天室的架构，遗留了两个问题。首先， 语音服务器是怎么转发语音数据的？ 我们直接上图。图中虚线框表示连接到同一台语音服务器。当A说话的时候，客户端将语音数据上传到A所连接的语音服务器；语音服务器向房间服务器查询A所在房间的其他用户（B-E）所在的语音服务器IP，分几种情况：对于同服务器用户B只需要下发语音数据，对于其他服务器上的用户（C-E）需要转发给相应的语音服务器，其他语音服务器收到转发数据后，根据房间信息，下发给同房间的用户。 有一个细节需要注意， 房间服务器是主动给语音服务器同步房间架构的 。因为语音服务请求量非常大，如果每次转发的时候都查询房间架构信息，那么房间服务器/数据库将成为瓶颈。因此语音服务器本地缓存了房间架构信息（当然缓存也会导致其他的问题，以后会专门讨论）。缓存的同步机制采用用户进退房主动触发房间服务器广播和房间服务器定期推送相结合，这样可以有效 保证网络丢包情况下的数据一致性 。 另外一个问题是 目录服务器是否有点多余？ 答案自然是否定的。当同一房间用户量还比较少的情况下，目录服务器的确可以省略，客户端可以通过DNS解析域名得到语音服务器的IP地址进行连接。 但是，当用户量非常大的时候，DNS缓慢的刷新机制不能满足快速扩容和缩容。目录服务器还有一个重要的作用是 负载均衡 ，相比DNS手工配置的简单的负载均衡策略

一、基于四层的负载均衡 LVS 是四层负载均衡，也就是说建立在 OSI 模型的第四层——传输层之上，传输层上有我们熟悉的 TCP/UDP，LVS 支持 TCP/UDP 的负载均衡。 LVS 的转发主要通过修改 IP 地址（NAT 模式，分为源地址修改 SNAT 和目标地址修改 DNAT）、修改目标 MAC（DR 模式）来实现。 二、为什么 LVS 是在第四层做负载均衡 首先 LVS 不像 HAProxy 等七层软负载面向的是 HTTP 包，所以七层负载可以做的 URL 解析等工作，LVS 无法完成。 其次，某次用户访问是与服务端建立连接后交换数据包实现的，如果在第三层网络层做负载均衡，那么将失去「连接」的语义。软负载面向的对象应该是 一个已经建立连接的用户，而不是一个孤零零的 IP 包。后面会看到，实际上 LVS 的机器代替真实的服务器与用户通过 TCP 三次握手建立了连接，所以 LVS 是需要关心「连接」级别的状态的。 三、LVS 的工作模式主要有 4 种 DR NAT TUNNEL Full-NAT 这里挑选常用的 DR、NAT、Full-NAT 来简单介绍一下 1、DR模式 请求由 LVS 接受，由真实提供服务的服务器（RealServer, RS）直接返回给用户，返回的时候不经过 LVS。 DR 模式下需要 LVS 和绑定同一个 VIP（RS 通过将 VIP 绑定在