负载均衡

大型网站架构系列:负载均衡详解(2)

北战南征 提交于 2020-03-29 05:20:40
本文是负载均衡详解的第一篇文章,介绍负载均衡算法, 硬件负载均衡。部分内容摘自读书笔记。 三、负载均衡算法 常用的负载均衡算法有,轮询,随机,最少链接,源地址散列,加权等方式; 3.1 轮询 将所有请求,依次分发到每台服务器上,适合服务器硬件同相同的场景。 优点:服务器请求数目相同; 缺点:服务器压力不一样,不适合服务器配置不同的情况; 3.2 随机 请求随机分配到各个服务器。 优点:使用简单; 缺点:不适合机器配置不同的场景; 3.3 最少链接 将请求分配到连接数最少的服务器(目前处理请求最少的服务器)。 优点:根据服务器当前的请求处理情况,动态分配; 缺点:算法实现相对复杂,需要监控服务器请求连接数; 3.4 Hash(源地址散列) 根据IP地址进行Hash计算,得到IP地址。 优点:将来自同一IP地址的请求,同一会话期内,转发到相同的服务器;实现会话粘滞。 缺点:目标服务器宕机后,会话会丢失; 3.5 加权 在轮询,随机,最少链接,Hash’等算法的基础上,通过加权的方式,进行负载服务器分配。 优点:根据权重,调节转发服务器的请求数目; 缺点:使用相对复杂; 四、硬件负载均衡 采用硬件的方式实现负载均衡,一般是单独的负载均衡服务器,价格昂贵,一般土豪级公司可以考虑,业界领先的有两款,F5和A10。 使用硬件负载均衡,主要考虑一下几个方面: (1)功能考虑

Nginx七层反向代理和负载均衡

让人想犯罪 __ 提交于 2020-03-28 04:37:55
1.介绍 1.1 Nginx不仅是一个出色的 web软件,其七层代理和负载均衡也是相当出色。 Nginx做前端代理,当用户请求服务时,可以根据 url进行判断,然后分配到不同的后台 webserver上。 1.2 Nginx的负载均衡实现原理:首先在 http模块中配置使用 upstream模块定义后台的 web server的池子,名为 proxy-web,在池子中我们可以添加多台后台 webserver,其中状态检查、调度算法都是在池子中配置;然后在 serverr模块中定义虚拟主机,但是这个虚拟主机不指定自己的 web目录站点,它将使用 location匹配 url然后转发到上面定义好的 web池子中,最后根据调度策略再转发到后台 web server上 2.负载均衡配置项的介绍 2.1 upstream调度算法介绍 ( 1) rr轮询(默认) 按照请求顺序分配到每个 RS,和 lvs中的 rr算法一样,如果 RS宕机,会自动剔除,默认情况下只检测 80端口,如果 RS报 402、 403、 503、 504错误,会直接返回给客户端。 ( 2) weight(权重) 在 rr的基础上再加上权重(默认是 rr+weight),权重轮询和访问成正比,值越大分配的越多,可以根据服务器的配置设置权重,可以解决服务器性能不均进行请求分配的问题 ( 3) ip_hash 解决动态网页

《从Paxos到zookeeper》第6章 Zookeeper的典型应用场景(下)

 ̄綄美尐妖づ 提交于 2020-03-27 11:06:53
目录 6.2 Zookeeper在大型分布式系统中的应用 6.2.1 Hadoop YARN介绍 如何解决ResourceManager单点问题,实现高可用? 6.2.3 Kafka 术语介绍 问题 Kafka与Zookeeper Broker注册管理 Topic注册管理 生产者负载均衡 消费者负载均衡 消费分区与消费者关系 消息消费进度Offset记录 消费者注册 负载均衡 1)Range策略 2)RoundRobin策略 资料 6.3 Zookeeper在阿里巴巴的实践与应用 6.3.2 案例二 RPC服务框架:Dubbo 服务提供者 服务消费者 监控中心 6.3.3 案例三 基于MySQL Binlog的增量订阅和消费组件:Canal Canal基本工作原理 Canal Server主备切换设计 Canal Client的HA设计 6.3.4 案例四 分布式数据库同步系统:Otter 分布式SEDA模型 数据模型 任务处理流程(多阶段任务协调处理) 6.2 Zookeeper在大型分布式系统中的应用 6.2.1 Hadoop YARN介绍 YARN是Hadoop为了提高计算节点的扩展性,同时为了支持多计算模型和提供资源的细粒度调度而引入的全新一代分布式协调框架。 核心为ResourceManager,资源管理中心,负责集群中所有资源的统一管理和分配。 (可理解为YARN的大脑

全网最全微服务架构—Spring Cloud详解,没有比这更详细的了!

懵懂的女人 提交于 2020-03-26 22:51:24
软件是有生命的,你做出来的架构决定了这个软件它这一生是坎坷还是幸福。 本文不是讲解如何使用Spring Cloud的教程,而是探讨Spring Cloud是什么,以及它诞生的背景和意义。 一、背景 2008年以后,国内互联网行业飞速发展,我们对软件系统的需求已经不再是过去”能用就行”这种很low的档次了,像 抢红包、双十一这样的活动 不断逼迫我们去突破软件系统的性能上限,传统的IT企业”能用就行”的开发思想已经不能满足互联网 高并发、大流量的性能要求 。系统架构 走向分布式 已经是服务器开发领域解决该问题唯一的出路,然而分布式系统由于天生的复杂度,并不像开发单体应用一样把框架一堆就能搞定,因此各大互联网公司都在投入技术力量研发自己的基础设施。这里面比较有名的如 阿里的开源项目dubbo, Netflix开发的一系列服务框架 。在这种“百花齐放”、重复造轮子的状况下,必然要出现一种统一的标准来简化分布式系统的开发, Spring Cloud 应运而生。 二、Spring Cloud是什么 Spring Cloud是一系列框架的有序集合 。它利用 Spring Boot 的开发便利性巧妙地简化了分布式系统基础设施的开发,如 服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控 等,都可以用Spring Boot的开发风格做到一键启动和部署。Spring并没有重复制造轮子

软件架构杂谈(二) --- Cluster (HA)

心已入冬 提交于 2020-03-26 17:04:19
3 月,跳不动了?>>> 浅谈软件架构 ( 二 ) cnyinlinux 之前发布过的博文,已经对 C/S 和 B/S 作了讨论,本文将讨论的是集群— Cluster 。 1. C/S 2. B/S 3. Cluster (HA) 4. Cloud 5. Distributed 6. APNS-like 7. P2P 集群的技术是近年来计算机应用大规模普及,以及性能要求逐渐提高的形势下提出来的。简而言之,集群就是一批独立计算机联合运作处理某一高要求任务的技术。其建立在网络互连的基础上,核心是节点间任务分配——调度算法。 集群有几个显著特点: A .提高性能 B .降低成本 C .高扩展性 D .高可靠性 集群与分布式的功能还是有区别的,关于分布式架构在别文讨论。 从应用场景和特性分为以下几种,本文将分别介绍各自特点。 1 )双机热备(高可用 HA ) 2 )科学集群 3 )负载均衡 一,双机热备,也被叫做高可用集群 (HA) 。这种方式也称为集群。它指的是具备同样功能且数据共享的多台机器之间构成相互备份的物理结构,每一时刻对外提供业务的机器只有 1 台,其他多台构成它的备份,若业务机出现故障,其他备份机立马接管任务,对外而言丝毫感受不到业务主机的故障。这样维修人员可以立马修复故障机,修好后成为新的备份机。这样就构成了相互备份的小集团,极大提高了实时业务的可靠性。

为啥要有微服务?啥是微服务?

谁说我不能喝 提交于 2020-03-26 09:42:30
前言 为什么要有微服务呢? 什么是微服务? SpringCloud 中为什么会有那么多的组件? ...... 作为SpringCloud教程的第一篇,不讲解具体的技术使用,通过一个通俗易懂的小故事,来解决这些疑惑。 本文分为三个部分: 架构的演变,即为什么会出现微服务技术 什么是微服务,即微服务的标准概念 微服务要解决什么问题,即微服务中那么多的组件都是干嘛的 从单体到微服务「小故事讲解架构演变」 新技术会站在老技术的基础上,解决老技术出现的问题的同时,进行迭代和演化 单体架构 这年,可能是十年前也可能是十五年前,小鹿入职了一家处于萌芽期的电商公司—并夕夕商城。 这个时候公司初创,人少,事儿少,用户少,当然了老板的钱也少,本着多快好省的信念,作为公司唯一开发工程师小鹿,跌跌撞撞的开发了一款能用的商城网站,架构如下: 网站整体非常的简单,在没什么用户的现阶段也是非常的好用,而且还非常的省心,但是没有想到的是,公司业务越来越好,用户量是越来越大,随着访问量的不断增大,项目经常卡死故障。 于是老板大手一挥,指引商城技术改革,emmm,还加钱招人,又招了小羊,小马数位同事,对并夕夕商城进行升级优化。 经过激烈的讨论,优化方向为:增加应用负载能力,即负载均衡,应用服务器集群 于是,噔噔蹬蹬,新的架构出现了 负载均衡 增加负载均衡之后,应用服务器不再是系统的瓶颈了

架构必备词汇

情到浓时终转凉″ 提交于 2020-03-26 07:28:42
高可用 负载均衡(负载均衡算法) 反向代理 服务隔离 服务限流 服务降级(自动优雅降级) 失效转移 超时重试(代理超时、容器超时、前端超时、中间件超时、数据库超时、NoSql超时) 回滚机制(上线回滚、数据库版本回滚、事务回滚) 高并发 应用缓存 HTTP缓存 多级缓存 分布式缓存 连接池 异步并发 分布式事务 二阶段提交(强一致) 三阶段提交(强一致) 消息中间件(最终一致性),推荐阿里的RocketMQ 队列 任务队列 消息队列 请求队列 扩容 单体垂直扩容 单体水平扩容 应用拆分 数据库拆分 数据库分库分表 数据异构 分布式任务 网络安全 SQL注入 XSS攻击 CSRF攻击 拒绝服务(DoS,Denial of Service)攻击 架构装逼必备工具 操作系统 Linux(必备)、某软的 负载均衡 DNS、F5、LVS、Nginx、OpenResty、HAproxy、负载均衡SLB(阿里云) 分布式框架 Dubbo、Motan、Spring-Could 数据库中间件 DRDS (阿里云)、Mycat、360 Atlas、Cobar (不维护了) 消息队列 RabbitMQ、ZeroMQ、Redis、ActiveMQ、Kafka 注册中心 Zookeeper、Redis 缓存 Redis、Oscache、Memcache、Ehcache 集成部署 Docker、Jenkins

Nginx介绍(一)

梦想的初衷 提交于 2020-03-25 03:13:14
Nginx (engine x) 是一个高性能的HTTP和反向代理web服务器,同时也提供了IMAP/POP3/SMTP服务。 Nginx最大的特点是对高并发的支持和高效的负载均衡,在高并发的需求场景下,是Apache服务器不错的替代品。 一、Nginx的优缺点 1. 优点 (1) 高并发量:根据官方给出的数据,能够支持高达 50,000 个并发连接数的响应。 (2) 内存消耗少:处理静态文件,同样起web 服务,比apache 占用更少的内存及资源,所有它是轻量级的。 (3) 简单稳定:配置简单,基本在一个conf文件中配置,性能比较稳定,可以7*24小时长时间不间断运行。 (4) 模块化程度高:Nginx是高度模块化的设计,编写模块相对简单,包括 gzipping, byte ranges, chunked responses,以及 SSI-filter 等 filter,支持 SSL 和 TLSSNI。 (5) 支持Rwrite重写规则:能够根据域名、URL的不同, 将HTTP请求分发到不同的后端服务器群组。 (6) 低成本:Nginx可以做高并发的负载均衡,且Nginx是开源免费的,如果使用F5等硬件来做负载均衡,硬件成本比较高。 (7) 支持多系统:Nginx代码完全用C语言从头写成,已经移植到许多体系结构和操作系统,包括:Linux、FreeBSD、Solaris

zookeeper、dubbo、kafka随笔

我的梦境 提交于 2020-03-24 18:50:13
1 zookeeper如何实现高可用 1 zookeeper 多台构成集群实现高可用,有三种角色群首(leader),追随者(follower),观察者(observer)。 Leader作为整个ZooKeeper集群的主节点,负责响应所有对ZooKeeper状态变更的请求。它会将每个状态更新请求进行排序和编号,以便保证整个集群内部消息处理的FIFO Follower的逻辑就比较简单了。除了响应本服务器上的读请求外,follower还要处理leader的提议,并在leader提交该提议时在本地也进行提交。,leader和follower构成ZooKeeper集群的法定人数,也就是说,只有他们才参与新leader的选举、响应leader的提议。 如果ZooKeeper集群的读取负载很高,或者客户端多到跨机房,可以设置一些observer服务器,以提高读取的吞吐量。Observer和Follower比较相似,只有一些小区别:首先observer不属于法定人数,即不参加选举也不响应提议;其次是observer不需要将事务持久化到磁盘,一旦observer被重启,需要从leader重新同步整个名字空间。 2 zookeeper如何实现负载均衡? 以前接触的负载均衡是通过VIP调度到各个节点。如:nginx+keepalived实现负载均衡和高可用

spring cloud的理解

前提是你 提交于 2020-03-24 12:25:55
一、什么是spring cloud? spring cloud 可以认为是一种分布式服务的框架,它为开发人员提供了快速构建分布式系统的常用模式的一些工具,比如说配置管理、服务的注册与发现、服务调用的负载均衡、资源隔离、熔断降级等等,spring cloud为这些提供了一阵套完整的解决方案。 二、什么是分布式系统? 上面说spring cloud是一种分布式服务的框架,那么什么是分布式服务呢? 在谈什么是分布式系统之前,可以先回顾一下以前的那种所有的功能模块都放在一个服务里的那种系统,一个系统化几十万行代码,部署在单台机器上。一个比较大的系统,可能有十几个人协作开发,但是使用的都是同一套代码,大家功能开发完成过后,使用的都是同一套代码来发布生产上线。这样做有些什么问题呢? 代码耦合严重,维护很困难。大家使用的同一套代码,一旦一个人有需求需要修改公用代码,由于对其他人的业务逻辑不熟悉,很可能改了上线过后,会影响其他人的已经存在于线上的功能。另外数据也有可能是耦合在一起的,一个人修改了数据,然后并不知道别人对这个数据是有依赖的,最后一上线,就发现出问题了。系统不复杂还好,随着业务发展,功能增多,在原有的一个工程里面不断地增加代码,这对于后期的维护简直是一个灾难。 代码复用性问题。多个人协作开发,一个人之前写过这个功能的代码,但对另外一个人没有感知且需要依赖这个功能的代码