nginx是一款自由的、开源的、高性能的HTTP服务器和反向代理服务器;同时也是一个IMAP、POP3、SMTP代理服务器;nginx可以作为一个HTTP服务器进行网站的发布处理,另外nginx可以作为反向代理进行负载均衡的实现。
这里主要通过三个方面简单介绍nginx
反向代理
负载均衡
nginx特点
说到代理,首先我们要明确一个概念,所谓代理就是一个代表、一个渠道;
此时就设计到两个角色,一个是被代理角色,一个是目标角色,被代理角色通过这个代理访问目标角色完成一些任务的过程称为代理操作过程;如同生活中的专卖店~客人到adidas专卖店买了一双鞋,这个专卖店就是代理,被代理角色就是adidas厂家,目标角色就是用户
正向代理
说反向代理之前,我们先看看正向代理,正向代理也是大家最常接触的到的代理模式,我们会从两个方面来说关于正向代理的处理模式,分别从软件方面和生活方面来解释一下什么叫正向代理
在如今的网络环境下,我们如果由于技术需要要去访问国外的某些网站,此时你会发现位于国外的某网站我们通过浏览器是没有办法访问的,此时大家可能都会用一个操作FQ进行访问,FQ的方式主要是找到一个可以访问国外网站的代理服务器,我们将请求发送给代理服务器,代理服务器去访问国外的网站,然后将访问到的数据传递给我们!
上述这样的代理模式称为正向代理,正向代理最大的特点是客户端非常明确要访问的服务器地址;服务器只清楚请求来自哪个代理服务器,而不清楚来自哪个具体的客户端;正向代理模式屏蔽或者隐藏了真实客户端信息。
反向代理
明白了什么是正向代理,我们继续看关于反向代理的处理方式,举例如我大天朝的某宝网站,每天同时连接到网站的访问人数已经爆表,单个服务器远远不能满足人民日益增长的购买欲望了,此时就出现了一个大家耳熟能详的名词:分布式部署;也就是通过部署多台服务器来解决访问人数限制的问题;某宝网站中大部分功能也是直接使用nginx进行反向代理实现的,并且通过封装nginx和其他的组件之后起了个高大上的名字:Tengine,有兴趣的童鞋可以访问Tengine的官网查看具体的信息:http://tengine.taobao.org/
那么反向代理具体是通过什么样的方式实现的分布式的集群操作呢,我们先看一个示意图:
通过上述的图解大家就可以看清楚了,多个客户端给服务器发送的请求,nginx服务器接收到之后,按照一定的规则分发给了后端的业务处理服务器进行处理了。此时~请求的来源也就是客户端是明确的,但是请求具体由哪台服务器处理的并不明确了,nginx扮演的就是一个反向代理角色
反向代理,主要用于服务器集群分布式部署的情况下,反向代理隐藏了服务器的信息!
项目场景
通常情况下,我们在实际项目操作时,正向代理和反向代理很有可能会存在在一个应用场景中,正向代理代理客户端的请求去访问目标服务器,目标服务器是一个反向单利服务器,反向代理了多台真实的业务处理服务器。具体的拓扑图如下:
这里提到的客户端发送的、nginx反向代理服务器接收到的请求数量,就是我们说的负载量
请求数量按照一定的规则进行分发到不同的服务器处理的规则,就是一种均衡规则
所以~将服务器接收到的请求按照规则分发的过程,称为负载均衡。
负载均衡在实际项目操作过程中,有硬件负载均衡和软件负载均衡两种,硬件负载均衡也称为硬负载,如F5负载均衡,相对造价昂贵成本较高,但是数据的稳定性安全性等等有非常好的保障,如中国移动中国联通这样的公司才会选择硬负载进行操作;更多的公司考虑到成本原因,会选择使用软件负载均衡,软件负载均衡是利用现有的技术结合主机硬件实现的一种消息队列分发机制
nginx支持的负载均衡调度算法方式如下:
weight轮询(默认):接收到的请求按照顺序逐一分配到不同的后端服务器,即使在使用过程中,某一台后端服务器宕机,nginx会自动将该服务器剔除出队列,请求受理情况不会受到任何影响。 这种方式下,可以给不同的后端服务器设置一个权重值(weight),用于调整不同的服务器上请求的分配率;权重数据越大,被分配到请求的几率越大;该权重值,主要是针对实际工作环境中不同的后端服务器硬件配置进行调整的。
ip_hash:每个请求按照发起客户端的ip的hash结果进行匹配,这样的算法下一个固定ip地址的客户端总会访问到同一个后端服务器,这也在一定程度上解决了集群部署环境下session共享的问题。
fair:智能调整调度算法,动态的根据后端服务器的请求处理到响应的时间进行均衡分配,响应时间短处理效率高的服务器分配到请求的概率高,响应时间长处理效率低的服务器分配到的请求少;结合了前两者的优点的一种调度算法。但是需要注意的是nginx默认不支持fair算法,如果要使用这种调度算法,请安装upstream_fair模块
url_hash:按照访问的url的hash结果分配请求,每个请求的url会指向后端固定的某个服务器,可以在nginx作为静态服务器的情况下提高缓存效率。同样要注意nginx默认不支持这种调度算法,要使用的话需要安装nginx的hash软件包
Redis 全称 Remote Dictionary Server(即远程字典服务),它是一个基于内存实现的键值型非关系(NoSQL)数据库,由意大利人 Salvatore Sanfilippo 使用 C 语言编写。
Redis 遵守 BSD 协议,实现了免费开源,其最新版本是 6.20,常用版本包括 3.0 、4.0、5.0。自 Redis 诞生以来,它以其超高的性能、完美的文档和简洁易懂的源码广受好评,国内外很多大型互联网公司都在使用 Redis,比如腾讯、阿里、Twitter、Github 等等。
提示:Redis官网(https://redis.io/)提供了完善的社区环境、文档说明,以及更新支持。
常见的内存型数据库,除 Redis 之外,还有 Oracle Berkeley DB(甲骨文旗下的一款产品)、SQlite(轻量级内存数据库)、Memcache(键值型分布式缓存数据库)、Altibase(基于内存的高性能数据库)。
与其他内存型数据库相比,Redis 具有以下特点:
Redis 不仅可以将数据完全保存在内存中,还可以通过磁盘实现数据的持久存储;
Redis 支持丰富的数据类型,包括 string、list、set、zset、hash 等多种数据类型,因此它也被称为“数据结构服务器”;
Redis 支持主从同步,即 master-slave 主从复制模式。数据可以从主服务器向任意数量的从服务器上同步,有效地保证数据的安全性;
Redis 支持多种编程语言,包括 C、C++、Python、Java、PHP、Ruby、Lua 等语言。
与 SQL 型数据库截然不同,Redis 没有提供新建数据库的操作,因为它自带了 16 (0—15)个数据库(默认使用 0 库)。在同一个库中,key 是唯一存在的、不允许重复的,它就像一把“密钥”,只能打开一把“锁”。键值存储的本质就是使用 key 来标识 value,当想要检索 value 时,必须使用与 value 相对应的 key 进行查找。
Redis 数据库没有“表”的概念,它通过不同的数据类型来实现存储数据的需求,不同的数据类型能够适应不同的应用场景,从而满足开发者的需求。
Redis架构
Redis体系架构主要分为两个部分:
Redis服务端
Redis客户端
客户端和服务端可以位于同一台计算机上,也可以位于不同的计算机上。服务端是整个架构的“大脑”,能够把数据存储到内存中,并且起到管理数据的作用。
Redis优势
下面对 Redis 的优势进行了简单总结:
性能极高:Redis 基于内存实现数据存储,它的读取速度是 110000次/s,写速度是 81000次/s;
多用途工具: Redis 有很多的用途,比如可以用作缓存、消息队列、搭建 Redis 集群等;
命令提示功能:Redis 客户端拥有强大的命令提示功能,使用起来非常的方便,降低了学习门槛;
可移植性:Redis 使用用标准 C语言编写的,能够在大多数操作系统上运行,比如 Linux,Mac,Solaris 等。
Redis应用场景
Redis 用来缓存一些经常被访问的热点数据、或者需要耗费大量资源的内容,通过把这些内容放到 Redis 中,可以让应用程序快速地读取它们。例如,网站的首页需要经常被访问,并且在创建首页的过程中会消耗的较多的资源,此时就可以使用 Redis 将整个首页缓存起来,从而降低网站的压力,减少页面访问的延迟时间。
我们知道,数据库的存储方式大体可分为两大类,基于磁盘存储和基于内存存储。磁盘存储的数据库,因为磁头机械运动以及系统调用等因素导致读写效率较低。Redis 基于内存来实现数据存取,相对于磁盘来说,其读写速度要高出好几个数量级。下表将 Redis 数据库与其他常用数据库做了简单对比:
Redis与其他数据库对比
名称 类型 数据存储选项 附加功能
Redis 基于内存存储的键值非关系型数据库 字符串、列表、散列、有序集合、无序集合 发布与订阅、主从复制、持久化存储等
Memcached 基于内存存储的键值缓存型数据库 键值之间的映射 为提升性能构建了多线程服务器
MySQL 基于磁盘的关系型数据库 每个数据库可以包含多个表,每个表可以包含多条记录;
支持第三方扩展。 支持 ACID 性质、主从复制和主主复制
MongoDB 基于磁盘存储的非关系文档型数据库 每个数据库可以包含多个集合,每个集合可以插入多个文档 支持聚合操作、主从复制、分片和空间索引
Redis 基于内存来实现数据的存储,因此其速度非常快。但是我们知道,计算机的内存是非常珍贵的资源,所以 Redis 不适合存储较大的文件或者二进制数据,否则会出现错误,Redis 适合存储较小的文本信息。理论上 Redis 的每个 key、value 的大小不超过 512 MB。
总得来说,上述数据库各有优势,当我们选用数据库时,也要因地制宜,选择一款与业务场景最相符合的数据库。