精华内容
下载资源
问答
  • Eureka工作原理

    万次阅读 多人点赞 2019-07-03 10:46:48
    Eureka 工作原理 上节内容为大家介绍了,注册中心 Eureka 产品的使用,以及如何利用 Eureka 搭建单台和集群的注册中心。这节课我们来继续学习 Eureka,了解它的相关概念、工作流程机制等。 Eureka 作为 Spring Cloud...

    Eureka 工作原理

    上节内容为大家介绍了,注册中心 Eureka 产品的使用,以及如何利用 Eureka 搭建单台和集群的注册中心。这节课我们来继续学习 Eureka,了解它的相关概念、工作流程机制等。

    Eureka 作为 Spring Cloud 体系中最核心、默认的注册中心组件,研究它的运行机制,有助于我们在工作中更好地使用它。

    Eureka 核心概念

    回到上节的服务注册调用示意图,服务提供者和服务的消费者,本质上也是 Eureka Client 角色。整体上可以分为两个主体:Eureka Server 和 Eureka Client。
    在这里插入图片描述

    Eureka Server:注册中心服务端

    注册中心服务端主要对外提供了三个功能:

    服务注册
    服务提供者启动时,会通过 Eureka Client 向 Eureka Server 注册信息,Eureka Server 会存储该服务的信息,Eureka Server 内部有二层缓存机制来维护整个注册表

    提供注册表
    服务消费者在调用服务时,如果 Eureka Client 没有缓存注册表的话,会从 Eureka Server 获取最新的注册表

    同步状态
    Eureka Client 通过注册、心跳机制和 Eureka Server 同步当前客户端的状态。

    Eureka Client:注册中心客户端
    Eureka Client 是一个 Java 客户端,用于简化与 Eureka Server 的交互。Eureka Client 会拉取、更新和缓存 Eureka Server 中的信息。因此当所有的 Eureka Server 节点都宕掉,服务消费者依然可以使用缓存中的信息找到服务提供者,但是当服务有更改的时候会出现信息不一致。

    Register: 服务注册
    服务的提供者,将自身注册到注册中心,服务提供者也是一个 Eureka Client。当 Eureka Client 向 Eureka Server 注册时,它提供自身的元数据,比如 IP 地址、端口,运行状况指示符 URL,主页等。

    Renew: 服务续约
    Eureka Client 会每隔 30 秒发送一次心跳来续约。 通过续约来告知 Eureka Server 该 Eureka Client 运行正常,没有出现问题。 默认情况下,如果 Eureka Server 在 90 秒内没有收到 Eureka Client 的续约,Server 端会将实例从其注册表中删除,此时间可配置,一般情况不建议更改。

    服务续约的两个重要属性

    服务续约任务的调用间隔时间,默认为30秒
    eureka.instance.lease-renewal-interval-in-seconds=30
    
    服务失效的时间,默认为90秒。
    eureka.instance.lease-expiration-duration-in-seconds=90
    

    Eviction 服务剔除
    当 Eureka Client 和 Eureka Server 不再有心跳时,Eureka Server 会将该服务实例从服务注册列表中删除,即服务剔除。

    Cancel: 服务下线
    Eureka Client 在程序关闭时向 Eureka Server 发送取消请求。 发送请求后,该客户端实例信息将从 Eureka Server 的实例注册表中删除。该下线请求不会自动完成,它需要调用以下内容:

    DiscoveryManager.getInstance().shutdownComponent()

    GetRegisty: 获取注册列表信息
    Eureka Client 从服务器获取注册表信息,并将其缓存在本地。客户端会使用该信息查找其他服务,从而进行远程调用。该注册列表信息定期(每30秒钟)更新一次。每次返回注册列表信息可能与 Eureka Client 的缓存信息不同,Eureka Client 自动处理。

    如果由于某种原因导致注册列表信息不能及时匹配,Eureka Client 则会重新获取整个注册表信息。 Eureka Server 缓存注册列表信息,整个注册表以及每个应用程序的信息进行了压缩,压缩内容和没有压缩的内容完全相同。Eureka Client 和 Eureka Server 可以使用 JSON/XML 格式进行通讯。在默认情况下 Eureka Client 使用压缩 JSON 格式来获取注册列表的信息。

    获取服务是服务消费者的基础,所以必有两个重要参数需要注意:

    # 启用服务消费者从注册中心拉取服务列表的功能
    eureka.client.fetch-registry=true
    
    # 设置服务消费者从注册中心拉取服务列表的间隔
    eureka.client.registry-fetch-interval-seconds=30
    

    Remote Call: 远程调用
    当 Eureka Client 从注册中心获取到服务提供者信息后,就可以通过 Http 请求调用对应的服务;服务提供者有多个时,Eureka Client 客户端会通过 Ribbon 自动进行负载均衡。

    自我保护机制

    默认情况下,如果 Eureka Server 在一定的 90s 内没有接收到某个微服务实例的心跳,会注销该实例。但是在微服务架构下服务之间通常都是跨进程调用,网络通信往往会面临着各种问题,比如微服务状态正常,网络分区故障,导致此实例被注销。

    固定时间内大量实例被注销,可能会严重威胁整个微服务架构的可用性。为了解决这个问题,Eureka 开发了自我保护机制,那么什么是自我保护机制呢?

    Eureka Server 在运行期间会去统计心跳失败比例在 15 分钟之内是否低于 85%,如果低于 85%,Eureka Server 即会进入自我保护机制。

    Eureka Server 触发自我保护机制后,页面会出现提示:

    在这里插入图片描述

    Eureka Server 进入自我保护机制,会出现以下几种情况:
    (1 Eureka 不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
    (2 Eureka 仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用)
    (3 当网络稳定时,当前实例新的注册信息会被同步到其它节点中

    Eureka 自我保护机制是为了防止误杀服务而提供的一个机制。当个别客户端出现心跳失联时,则认为是客户端的问题,剔除掉客户端;当 Eureka 捕获到大量的心跳失败时,则认为可能是网络问题,进入自我保护机制;当客户端心跳恢复时,Eureka 会自动退出自我保护机制。

    如果在保护期内刚好这个服务提供者非正常下线了,此时服务消费者就会拿到一个无效的服务实例,即会调用失败。对于这个问题需要服务消费者端要有一些容错机制,如重试,断路器等。

    通过在 Eureka Server 配置如下参数,开启或者关闭保护机制,生产环境建议打开:

    eureka.server.enable-self-preservation=true
    

    Eureka 集群原理

    再来看看 Eureka 集群的工作原理。我们假设有三台 Eureka Server 组成的集群,第一台 Eureka Server 在北京机房,另外两台 Eureka Server 在深圳和西安机房。这样三台 Eureka Server 就组建成了一个跨区域的高可用集群,只要三个地方的任意一个机房不出现问题,都不会影响整个架构的稳定性。

    在这里插入图片描述

    从图中可以看出 Eureka Server 集群相互之间通过 Replicate 来同步数据,相互之间不区分主节点和从节点,所有的节点都是平等的。在这种架构中,节点通过彼此互相注册来提高可用性,每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。

    如果某台 Eureka Server 宕机,Eureka Client 的请求会自动切换到新的 Eureka Server 节点。当宕机的服务器重新恢复后,Eureka 会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时,所有的操作都会进行节点间复制,将请求复制到其它 Eureka Server 当前所知的所有节点中。

    另外 Eureka Server 的同步遵循着一个非常简单的原则:只要有一条边将节点连接,就可以进行信息传播与同步。所以,如果存在多个节点,只需要将节点之间两两连接起来形成通路,那么其它注册中心都可以共享信息。每个 Eureka Server 同时也是 Eureka Client,多个 Eureka Server 之间通过 P2P 的方式完成服务注册表的同步。

    Eureka Server 集群之间的状态是采用异步方式同步的,所以不保证节点间的状态一定是一致的,不过基本能保证最终状态是一致的。

    Eureka 分区
    Eureka 提供了 Region 和 Zone 两个概念来进行分区,这两个概念均来自于亚马逊的 AWS:
    region:可以理解为地理上的不同区域,比如亚洲地区,中国区或者深圳等等。没有具体大小的限制。根据项目具体的情况,可以自行合理划分 region。
    zone:可以简单理解为 region 内的具体机房,比如说 region 划分为深圳,然后深圳有两个机房,就可以在此 region 之下划分出 zone1、zone2 两个 zone。

    上图中的 us-east-1c、us-east-1d、us-east-1e 就代表了不同的 Zone。Zone 内的 Eureka Client 优先和 Zone 内的 Eureka Server 进行心跳同步,同样调用端优先在 Zone 内的 Eureka Server 获取服务列表,当 Zone 内的 Eureka Server 挂掉之后,才会从别的 Zone 中获取信息。

    Eurka 保证 AP

    Eureka Server 各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而 Eureka Client 在向某个 Eureka 注册时,如果发现连接失败,则会自动切换至其它节点。只要有一台 Eureka Server 还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。

    Eurka 工作流程

    了解完 Eureka 核心概念,自我保护机制,以及集群内的工作原理后,我们来整体梳理一下 Eureka 的工作流程:

    1、Eureka Server 启动成功,等待服务端注册。在启动过程中如果配置了集群,集群之间定时通过 Replicate 同步注册表,每个 Eureka Server 都存在独立完整的服务注册表信息

    2、Eureka Client 启动时根据配置的 Eureka Server 地址去注册中心注册服务

    3、Eureka Client 会每 30s 向 Eureka Server 发送一次心跳请求,证明客户端服务正常

    4、当 Eureka Server 90s 内没有收到 Eureka Client 的心跳,注册中心则认为该节点失效,会注销该实例

    5、单位时间内 Eureka Server 统计到有大量的 Eureka Client 没有上送心跳,则认为可能为网络异常,进入自我保护机制,不再剔除没有上送心跳的客户端

    6、当 Eureka Client 心跳请求恢复正常之后,Eureka Server 自动退出自我保护模式

    7、Eureka Client 定时全量或者增量从注册中心获取服务注册表,并且将获取到的信息缓存到本地

    8、服务调用时,Eureka Client 会先从本地缓存找寻调取的服务。如果获取不到,先从注册中心刷新注册表,再同步到本地缓存

    9、Eureka Client 获取到目标服务器信息,发起服务调用

    10、Eureka Client 程序关闭时向 Eureka Server 发送取消请求,Eureka Server 将实例从注册表中删除

    这就是Eurka基本工作流程

    总结

    讲了 Eureka 核心概念、Eureka 自我保护机制和 Eureka 集群原理。通过分析 Eureka 工作原理,我可以明显地感觉到 Eureka 的设计之巧妙,通过一些列的机制,完美地解决了注册中心的稳定性和高可用性。

    Eureka 为了保障注册中心的高可用性,容忍了数据的非强一致性,服务节点间的数据可能不一致, Client-Server 间的数据可能不一致。比较适合跨越多机房、对注册中心服务可用性要求较高的使用场景。

    展开全文
  • Nginx工作原理和优化总结。

    万次阅读 多人点赞 2013-05-16 11:04:53
    NGINX以高性能的负载均衡器,缓存,和web...首先我们先了解其工作原理。 1. Nginx的模块与工作原理 Nginx由内核和模块组成,其中,内核的设计非常微小和简洁,完成的工作也非常简单,仅仅通过查找配置文件将客...

          NGINX以高性能的负载均衡器,缓存,和web服务器闻名,驱动了全球超过 40% 最繁忙的网站。在大多数场景下,默认的 NGINX 和 Linux 设置可以很好的工作,但要达到最佳性能,有些时候必须做些调整。首先我们先了解其工作原理。

     

    一.  Nginx的模块与工作原理


    Nginx由内核和模块组成,其中,内核的设计非常微小和简洁,完成的工作也非常简单,仅仅通过查找配置文件将客户端请求映射到一个location block(location是Nginx配置中的一个指令,用于URL匹配),而在这个location中所配置的每个指令将会启动不同的模块去完成相应的工作。

    Nginx的模块从结构上分为核心模块、基础模块和第三方模块:

    核心模块:HTTP模块、EVENT模块和MAIL模块

    基础模块:HTTP Access模块、HTTP FastCGI模块、HTTP Proxy模块和HTTP Rewrite模块,

    第三方模块:HTTP Upstream Request Hash模块、Notice模块和HTTP Access Key模块。

    用户根据自己的需要开发的模块都属于第三方模块。正是有了这么多模块的支撑,Nginx的功能才会如此强大。

    Nginx的模块从功能上分为如下三类。

    Handlers(处理器模块)。此类模块直接处理请求,并进行输出内容和修改headers信息等操作。Handlers处理器模块一般只能有一个。

    Filters (过滤器模块)。此类模块主要对其他处理器模块输出的内容进行修改操作,最后由Nginx输出。

    Proxies (代理类模块)。此类模块是Nginx的HTTP Upstream之类的模块,这些模块主要与后端一些服务比如FastCGI等进行交互,实现服务代理和负载均衡等功能。

    图1-1展示了Nginx模块常规的HTTP请求和响应的过程。

          

    Nginx本身做的工作实际很少,当它接到一个HTTP请求时,它仅仅是通过查找配置文件将此次请求映射到一个location block,而此location中所配置的各个指令则会启动不同的模块去完成工作,因此模块可以看做Nginx真正的劳动工作者。通常一个location中的指令会涉及一个handler模块和多个filter模块(当然,多个location可以复用同一个模块)。handler模块负责处理请求,完成响应内容的生成,而filter模块对响应内容进行处理。

    Nginx的模块直接被编译进Nginx,因此属于静态编译方式。启动Nginx后,Nginx的模块被自动加载,不像Apache,首先将模块编译为一个so文件,然后在配置文件中指定是否进行加载。在解析配置文件时,Nginx的每个模块都有可能去处理某个请求,但是同一个处理请求只能由一个模块来完成。 

     

     

    二.  Nginx的进程模型


    在工作方式上,Nginx分为单工作进程和多工作进程两种模式。在单工作进程模式下,除主进程外,还有一个工作进程,工作进程是单线程的;在多工作进程模式下,每个工作进程包含多个线程。Nginx默认为单工作进程模式。

    Nginx在启动后,会有一个master进程和多个worker进程。

    1、master进程:管理进程

      master进程主要用来管理worker进程,具体包括如下4个主要功能:
            (1)接收来自外界的信号。
            (2)向各worker进程发送信号。
            (3)监控woker进程的运行状态。
            (4)当woker进程退出后(异常情况下),会自动重新启动新的woker进程。

    用户交互接口:master进程充当整个进程组与用户的交互接口,同时对进程进行监护。它不需要处理网络事件,不负责业务的执行,只会通过管理worker进程来实现重启服务、平滑升级、更换日志文件、配置文件实时生效等功能。

    重启work进程:我们要控制nginx,只需要通过kill向master进程发送信号就行了。比如kill -HUP pid,则是告诉nginx,从容地重启nginx,我们一般用这个信号来重启nginx,或重新加载配置,因为是从容地重启,因此服务是不中断的。

    master进程在接收到HUP信号后是怎么做的呢?

    1)、首先master进程在接到信号后,会先重新加载配置文件,然后再启动新的worker进程,并向所有老的worker进程发送信号,告诉他们可以光荣退休了。

    2)、新的worker在启动后,就开始接收新的请求,而老的worker在收到来自master的信号后,就不再接收新的请求,并且在当前进程中的所有未处理完的请求处理完成后,再退出。

    直接给master进程发送信号,这是比较传统的操作方式,nginx在0.8版本之后,引入了一系列命令行参数,来方便我们管理。比如,./nginx -s reload,就是来重启nginx,./nginx -s stop,就是来停止nginx的运行。如何做到的呢?我们还是拿reload来说,我们看到,执行命令时,我们是启动一个新的nginx进程,而新的nginx进程在解析到reload参数后,就知道我们的目的是控制nginx来重新加载配置文件了,它会向master进程发送信号,然后接下来的动作,就和我们直接向master进程发送信号一样了。

    2、worker进程:处理请求

    而基本的网络事件,则是放在worker进程中来处理了。多个worker进程之间是对等的,他们同等竞争来自客户端的请求,各进程互相之间是独立的。一个请求,只可能在一个worker进程中处理,一个worker进程,不可能处理其它进程的请求。worker进程的个数是可以设置的,一般我们会设置与机器cpu核数一致,这里面的原因与nginx的进程模型以及事件处理模型是分不开的。

    worker进程之间是平等的,每个进程,处理请求的机会也是一样的。当我们提供80端口的http服务时,一个连接请求过来,每个进程都有可能处理这个连接,怎么做到的呢?

     Nginx采用异步非阻塞的方式来处理网络事件,类似于Libevent,具体过程如下:

    1)接收请求:首先,每个worker进程都是从master进程fork过来,在master进程建立好需要listen的socket(listenfd)之后,然后再fork出多个worker进程。所有worker进程的listenfd会在新连接到来时变得可读,每个work进程都可以去accept这个socket(listenfd)。当一个client连接到来时,所有accept的work进程都会受到通知,但只有一个进程可以accept成功,其它的则会accept失败。为保证只有一个进程处理该连接,Nginx提供了一把共享锁accept_mutex来保证同一时刻只有一个work进程在accept连接。所有worker进程在注册listenfd读事件前抢accept_mutex,抢到互斥锁的那个进程注册listenfd读事件,在读事件里调用accept接受该连接。

    2)处理请求:当一个worker进程在accept这个连接之后,就开始读取请求,解析请求,处理请求,产生数据后,再返回给客户端,最后才断开连接,这样一个完整的请求就是这样的了。

    我们可以看到,一个请求,完全由worker进程来处理,而且只在一个worker进程中处理。worker进程之间是平等的,每个进程,处理请求的机会也是一样的。

    nginx的进程模型,可以由下图来表示:

    三.   Nginx为啥性能高-多进程IO模型


          参考http://mp.weixin.qq.com/s?__biz=MjM5NTg2NTU0Ng==&mid=407889757&idx=3&sn=cfa8a70a5fd2a674a91076f67808273c&scene=23&srcid=0401aeJQEraSG6uvLj69Hfve#rd

    1、nginx采用多进程模型好处

          首先,对于每个worker进程来说,独立的进程,不需要加锁,所以省掉了锁带来的开销,同时在编程以及问题查找时,也会方便很多。

          其次,采用独立的进程,可以让互相之间不会影响,一个进程退出后,其它进程还在工作,服务不会中断,master进程则很快启动新的worker进程。当然,worker进程的异常退出,肯定是程序有bug了,异常退出,会导致当前worker上的所有请求失败,不过不会影响到所有请求,所以降低了风险。

    2、nginx多进程事件模型:异步非阻塞


             虽然nginx采用多worker的方式来处理请求,每个worker里面只有一个主线程,那能够处理的并发数很有限啊,多少个worker就能处理多少个并发,何来高并发呢?非也,这就是nginx的高明之处,nginx采用了异步非阻塞的方式来处理请求,也就是说,nginx是可以同时处理成千上万个请求的。一个worker进程可以同时处理的请求数只受限于内存大小,而且在架构设计上,不同的worker进程之间处理并发请求时几乎没有同步锁的限制,worker进程通常不会进入睡眠状态,因此,当Nginx上的进程数与CPU核心数相等时(最好每一个worker进程都绑定特定的CPU核心),进程间切换的代价是最小的。

           而apache的常用工作方式(apache也有异步非阻塞版本,但因其与自带某些模块冲突,所以不常用),每个进程在一个时刻只处理一个请求因此,当并发数上到几千时,就同时有几千的进程在处理请求了。这对操作系统来说,是个不小的挑战,进程带来的内存占用非常大,进程的上下文切换带来的cpu开销很大,自然性能就上不去了,而这些开销完全是没有意义的。

         

     

             为什么nginx可以采用异步非阻塞的方式来处理呢,或者异步非阻塞到底是怎么回事呢?具体请看:使用 libevent 和 libev 提高网络应用性能——I/O模型演进变化史

             我们先回到原点,看看一个请求的完整过程:首先,请求过来,要建立连接,然后再接收数据,接收数据后,再发送数据。

             具体到系统底层,就是读写事件,而当读写事件没有准备好时,必然不可操作,如果不用非阻塞的方式来调用,那就得阻塞调用了,事件没有准备好,那就只能等了,等事件准备好了,你再继续吧。阻塞调用会进入内核等待,cpu就会让出去给别人用了,对单线程的worker来说,显然不合适,当网络事件越多时,大家都在等待呢,cpu空闲下来没人用,cpu利用率自然上不去了,更别谈高并发了。好吧,你说加进程数,这跟apache的线程模型有什么区别,注意,别增加无谓的上下文切换。所以,在nginx里面,最忌讳阻塞的系统调用了。不要阻塞,那就非阻塞喽。非阻塞就是,事件没有准备好,马上返回EAGAIN,告诉你,事件还没准备好呢,你慌什么,过会再来吧。好吧,你过一会,再来检查一下事件,直到事件准备好了为止,在这期间,你就可以先去做其它事情,然后再来看看事件好了没。虽然不阻塞了,但你得不时地过来检查一下事件的状态,你可以做更多的事情了,但带来的开销也是不小的。

    关于IO模型:http://blog.csdn.net/hguisu/article/details/7453390

           nginx支持的事件模型如下(nginx的wiki):

           Nginx支持如下处理连接的方法(I/O复用方法),这些方法可以通过use指令指定。

    • select– 标准方法。 如果当前平台没有更有效的方法,它是编译时默认的方法。你可以使用配置参数 –with-select_module 和 –without-select_module 来启用或禁用这个模块。
    • poll– 标准方法。 如果当前平台没有更有效的方法,它是编译时默认的方法。你可以使用配置参数 –with-poll_module 和 –without-poll_module 来启用或禁用这个模块。
    • kqueue– 高效的方法,使用于 FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X. 使用双处理器的MacOS X系统使用kqueue可能会造成内核崩溃。
    • epoll 高效的方法,使用于Linux内核2.6版本及以后的系统。在某些发行版本中,如SuSE 8.2, 有让2.4版本的内核支持epoll的补丁。
    • rtsig 可执行的实时信号,使用于Linux内核版本2.2.19以后的系统。默认情况下整个系统中不能出现大于1024个POSIX实时(排队)信号。这种情况 对于高负载的服务器来说是低效的;所以有必要通过调节内核参数 /proc/sys/kernel/rtsig-max 来增加队列的大小。可是从Linux内核版本2.6.6-mm2开始, 这个参数就不再使用了,并且对于每个进程有一个独立的信号队列,这个队列的大小可以用 RLIMIT_SIGPENDING 参数调节。当这个队列过于拥塞,nginx就放弃它并且开始使用 poll 方法来处理连接直到恢复正常。
    • /dev/poll – 高效的方法,使用于 Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+.
    • eventport – 高效的方法,使用于 Solaris 10. 为了防止出现内核崩溃的问题, 有必要安装这个 安全补丁。

            在linux下面,只有epoll是高效的方法

            下面再来看看epoll到底是如何高效的
           Epoll是Linux内核为处理大批量句柄而作了改进的poll。 要使用epoll只需要这三个系统调用:epoll_create(2), epoll_ctl(2), epoll_wait(2)。它是在2.5.44内核中被引进的(epoll(4) is a new API introduced in Linux kernel 2.5.44),在2.6内核中得到广泛应用。

            epoll的优点

    • 支持一个进程打开大数目的socket描述符(FD)

            select 最不能忍受的是一个进程所打开的FD是有一定限制的,由FD_SETSIZE设置,默认值是2048。对于那些需要支持的上万连接数目的IM服务器来说显 然太少了。这时候你一是可以选择修改这个宏然后重新编译内核,不过资料也同时指出这样会带来网络效率的下降,二是可以选择多进程的解决方案(传统的 Apache方案),不过虽然linux上面创建进程的代价比较小,但仍旧是不可忽视的,加上进程间数据同步远比不上线程间同步的高效,所以也不是一种完 美的方案。不过 epoll则没有这个限制,它所支持的FD上限是最大可以打开文件的数目,这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左 右,具体数目可以cat /proc/sys/fs/file-max察看,一般来说这个数目和系统内存关系很大。

    • IO效率不随FD数目增加而线性下降

             传统的select/poll另一个致命弱点就是当你拥有一个很大的socket集合,不过由于网络延时,任一时间只有部分的socket是”活跃”的,但 是select/poll每次调用都会线性扫描全部的集合,导致效率呈现线性下降。但是epoll不存在这个问题,它只会对”活跃”的socket进行操 作—这是因为在内核实现中epoll是根据每个fd上面的callback函数实现的。那么,只有”活跃”的socket才会主动的去调用 callback函数,其他idle状态socket则不会,在这点上,epoll实现了一个”伪”AIO,因为这时候推动力在os内核。在一些 benchmark中,如果所有的socket基本上都是活跃的—比如一个高速LAN环境,epoll并不比select/poll有什么效率,相 反,如果过多使用epoll_ctl,效率相比还有稍微的下降。但是一旦使用idle connections模拟WAN环境,epoll的效率就远在select/poll之上了。

    • 使用mmap加速内核与用户空间的消息传递。

            这 点实际上涉及到epoll的具体实现了。无论是select,poll还是epoll都需要内核把FD消息通知给用户空间,如何避免不必要的内存拷贝就很 重要,在这点上,epoll是通过内核于用户空间mmap同一块内存实现的。而如果你想我一样从2.5内核就关注epoll的话,一定不会忘记手工 mmap这一步的。

    • 内核微调

             这一点其实不算epoll的优点了,而是整个linux平台的优点。也许你可以怀疑linux平台,但是你无法回避linux平台赋予你微调内核的能力。比如,内核TCP/IP协 议栈使用内存池管理sk_buff结构,那么可以在运行时期动态调整这个内存pool(skb_head_pool)的大小— 通过echo XXXX>/proc/sys/net/core/hot_list_length完成。再比如listen函数的第2个参数(TCP完成3次握手 的数据包队列长度),也可以根据你平台内存大小动态调整。更甚至在一个数据包面数目巨大但同时每个数据包本身大小却很小的特殊系统上尝试最新的NAPI网卡驱动架构。

        (epoll内容,参考epoll_互动百科)

          推荐设置worker的个数为cpu的核数,在这里就很容易理解了,更多的worker数,只会导致进程来竞争cpu资源了,从而带来不必要的上下文切换。而且,nginx为了更好的利用多核特性,提供了cpu亲缘性的绑定选项,我们可以将某一个进程绑定在某一个核上,这样就不会因为进程的切换带来cache的失效。像这种小的优化在nginx中非常常见,同时也说明了nginx作者的苦心孤诣。比如,nginx在做4个字节的字符串比较时,会将4个字符转换成一个int型,再作比较,以减少cpu的指令数等等。

    代码来总结一下nginx的事件处理模型:

     

    while (true) {
        for t in run_tasks:
            t.handler();
        update_time(&now);
        timeout = ETERNITY;
        for t in wait_tasks: /* sorted already */
            if (t.time <= now) {
                t.timeout_handler();
            } else {
                timeout = t.time - now;
                break;
            }
        nevents = poll_function(events, timeout);
        for i in nevents:
            task t;
            if (events[i].type == READ) {
                t.handler = read_handler;
            } else { /* events[i].type == WRITE */
                t.handler = write_handler;
            }
            run_tasks_add(t);
    }

     

     

     

    四.  Nginx+FastCGI运行原理


    1、什么是 FastCGI

    FastCGI是一个可伸缩地、高速地在HTTP server和动态脚本语言间通信的接口。多数流行的HTTP server都支持FastCGI,包括Apache、Nginx和lighttpd等。同时,FastCGI也被许多脚本语言支持,其中就有PHP。

    FastCGI是从CGI发展改进而来的。传统CGI接口方式的主要缺点是性能很差,因为每次HTTP服务器遇到动态程序时都需要重新启动脚本解析器来执行解析,然后将结果返回给HTTP服务器。这在处理高并发访问时几乎是不可用的。另外传统的CGI接口方式安全性也很差,现在已经很少使用了。

    FastCGI接口方式采用C/S结构,可以将HTTP服务器和脚本解析服务器分开,同时在脚本解析服务器上启动一个或者多个脚本解析守护进程。当HTTP服务器每次遇到动态程序时,可以将其直接交付给FastCGI进程来执行,然后将得到的结果返回给浏览器。这种方式可以让HTTP服务器专一地处理静态请求或者将动态脚本服务器的结果返回给客户端,这在很大程度上提高了整个应用系统的性能。

    2、Nginx+FastCGI运行原理

    Nginx不支持对外部程序的直接调用或者解析,所有的外部程序(包括PHP)必须通过FastCGI接口来调用。FastCGI接口在Linux下是socket(这个socket可以是文件socket,也可以是ip socket)。

    wrapper:为了调用CGI程序,还需要一个FastCGI的wrapper(wrapper可以理解为用于启动另一个程序的程序),这个wrapper绑定在某个固定socket上,如端口或者文件socket。当Nginx将CGI请求发送给这个socket的时候,通过FastCGI接口,wrapper接收到请求,然后Fork(派生)出一个新的线程,这个线程调用解释器或者外部程序处理脚本并读取返回数据;接着,wrapper再将返回的数据通过FastCGI接口,沿着固定的socket传递给Nginx;最后,Nginx将返回的数据(html页面或者图片)发送给客户端。这就是Nginx+FastCGI的整个运作过程,如图1-3所示。

           

     

          所以,我们首先需要一个wrapper,这个wrapper需要完成的工作:

    1. 通过调用fastcgi(库)的函数通过socket和ningx通信(读写socket是fastcgi内部实现的功能,对wrapper是非透明的)
    2. 调度thread,进行fork和kill
    3. 和application(php)进行通信

    3、spawn-fcgi与PHP-FPM

           FastCGI接口方式在脚本解析服务器上启动一个或者多个守护进程对动态脚本进行解析,这些进程就是FastCGI进程管理器,或者称为FastCGI引擎。 spawn-fcgi与PHP-FPM就是支持PHP的两个FastCGI进程管理器。因此HTTPServer完全解放出来,可以更好地进行响应和并发处理。

           spawn-fcgi与PHP-FPM的异同:
           1)spawn-fcgi是HTTP服务器lighttpd的一部分,目前已经独立成为一个项目,一般与lighttpd配合使用来支持PHP。但是ligttpd的spwan-fcgi在高并发访问的时候,会出现内存泄漏甚至自动重启FastCGI的问题。即:PHP脚本处理器当机,这个时候如果用户访问的话,可能就会出现白页(即PHP不能被解析或者出错)。

           2)Nginx是个轻量级的HTTP server,必须借助第三方的FastCGI处理器才可以对PHP进行解析,因此其实这样看来nginx是非常灵活的,它可以和任何第三方提供解析的处理器实现连接从而实现对PHP的解析(nginx.conf中很容易设置)nginx也可以使用spwan-fcgi(需要一同安装lighttpd,但是需要为nginx避开端口,一些较早的blog有这方面安装的教程),但是由于spawn-fcgi具有上面所述的用户逐渐发现的缺陷,现在慢慢减少用nginx+spawn-fcgi组合了。

           由于spawn-fcgi的缺陷,现在出现了第三方(目前已经加入到PHP core中)的PHP的FastCGI处理器PHP-FPM,它和spawn-fcgi比较起来有如下优点:

           由于它是作为PHP的patch补丁来开发的,安装的时候需要和php源码一起编译,也就是说编译到php core中了,因此在性能方面要优秀一些;

    同时它在处理高并发方面也优于spawn-fcgi,至少不会自动重启fastcgi处理器。因此,推荐使用Nginx+PHP/PHP-FPM这个组合对PHP进行解析。

          相对Spawn-FCGI,PHP-FPM在CPU和内存方面的控制都更胜一筹,而且前者很容易崩溃,必须用crontab进行监控,而PHP-FPM则没有这种烦恼。
           FastCGI 的主要优点是把动态语言和HTTP Server分离开来,所以Nginx与PHP/PHP-FPM经常被部署在不同的服务器上,以分担前端Nginx服务器的压力,使Nginx专一处理静态请求和转发动态请求,而PHP/PHP-FPM服务器专一解析PHP动态请求。

    4、Nginx+PHP-FPM

          PHP-FPM是管理FastCGI的一个管理器,它作为PHP的插件存在,在安装PHP要想使用PHP-FPM时在老php的老版本(php5.3.3之前)就需要把PHP-FPM以补丁的形式安装到PHP中,而且PHP要与PHP-FPM版本一致,这是必须的)

       PHP-FPM其实是PHP源代码的一个补丁,旨在将FastCGI进程管理整合进PHP包中。必须将它patch到你的PHP源代码中,在编译安装PHP后才可以使用。
       PHP5.3.3已经集成php-fpm了,不再是第三方的包了。PHP-FPM提供了更好的PHP进程管理方式,可以有效控制内存和进程、可以平滑重载PHP配置,比spawn-fcgi具有更多优点,所以被PHP官方收录了。在./configure的时候带 –enable-fpm参数即可开启PHP-FPM。

          fastcgi已经在php5.3.5的core中了,不必在configure时添加 --enable-fastcgi了。老版本如php5.2的需要加此项。

          当我们安装Nginx和PHP-FPM完后,配置信息:

         PHP-FPM的默认配置php-fpm.conf:

         listen_address  127.0.0.1:9000 #这个表示php的fastcgi进程监听的ip地址以及端口

          start_servers

          min_spare_servers

          max_spare_servers

          Nginx配置运行php: 编辑nginx.conf加入如下语句:

          location ~ \.php$ {
                root html;   
                fastcgi_pass 127.0.0.1:9000; 指定了fastcgi进程侦听的端口,nginx就是通过这里与php交互的
                fastcgi_index index.php;
                include fastcgi_params;
                 fastcgi_param SCRIPT_FILENAME   /usr/local/nginx/html$fastcgi_script_name;
        }

        Nginx通过location指令,将所有以php为后缀的文件都交给127.0.0.1:9000来处理,而这里的IP地址和端口就是FastCGI进程监听的IP地址和端口。

         其整体工作流程:

         1)、FastCGI进程管理器php-fpm自身初始化,启动主进程php-fpm和启动start_servers个CGI 子进程。

               主进程php-fpm主要是管理fastcgi子进程,监听9000端口。

               fastcgi子进程等待来自Web Server的连接。

         2)、当客户端请求到达Web Server Nginx是时,Nginx通过location指令,将所有以php为后缀的文件都交给127.0.0.1:9000来处理,即Nginx通过location指令,将所有以php为后缀的文件都交给127.0.0.1:9000来处理。

          3)FastCGI进程管理器PHP-FPM选择并连接到一个子进程CGI解释器。Web server将CGI环境变量和标准输入发送到FastCGI子进程。

          4)、FastCGI子进程完成处理后将标准输出和错误信息从同一连接返回Web Server。当FastCGI子进程关闭连接时,请求便告处理完成。

          5)、FastCGI子进程接着等待并处理来自FastCGI进程管理器(运行在 WebServer中)的下一个连接。

     

    五.   Nginx+PHP正确配置


    一般web都做统一入口:把PHP请求都发送到同一个文件上,然后在此文件里通过解析「REQUEST_URI」实现路由。

    Nginx配置文件分为好多块,常见的从外到内依次是「http」、「server」、「location」等等,缺省的继承关系是从外到内,也就是说内层块会自动获取外层块的值作为缺省值。

    例如:

    server {
        listen 80;
        server_name foo.com;
        root /path;
        location / {
            index index.html index.htm index.php;
            if (!-e $request_filename) {
                rewrite . /index.php last;
            }
        }
        location ~ \.php$ {
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME /path$fastcgi_script_name;
            fastcgi_pass 127.0.0.1:9000;
            fastcgi_index index.php;
        }
    } 

    1)  不应该在location 模块定义index

    一旦未来需要加入新的「location」,必然会出现重复定义的「index」指令,这是因为多个「location」是平级的关系,不存在继承,此时应该在「server」里定义「index」,借助继承关系,「index」指令在所有的「location」中都能生效。

    2)     使用try_files

    接下来看看「if」指令,说它是大家误解最深的Nginx指令毫不为过:

    if (!-e $request_filename) {
        rewrite . /index.php last;
    }

    很多人喜欢用「if」指令做一系列的检查,不过这实际上是「try_files」指令的职责:

    try_files $uri $uri/ /index.php;

    除此以外,初学者往往会认为「if」指令是内核级的指令,但是实际上它是rewrite模块的一部分,加上Nginx配置实际上是声明式的,而非过程式的,所以当其和非rewrite模块的指令混用时,结果可能会非你所愿。

     

    3)fastcgi_params」配置文件

    include fastcgi_params;

    Nginx有两份fastcgi配置文件,分别是「fastcgi_params」和「fastcgi.conf」,它们没有太大的差异,唯一的区别是后者比前者多了一行「SCRIPT_FILENAME」的定义:

    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

    注意:$document_root 和 $fastcgi_script_name 之间没有 /。

    原本Nginx只有「fastcgi_params」,后来发现很多人在定义「SCRIPT_FILENAME」时使用了硬编码的方式,于是为了规范用法便引入了「fastcgi.conf」。

     

    不过这样的话就产生一个疑问:为什么一定要引入一个新的配置文件,而不是修改旧的配置文件?这是因为「fastcgi_param」指令是数组型的,和普通指令相同的是:内层替换外层;和普通指令不同的是:当在同级多次使用的时候,是新增而不是替换。换句话说,如果在同级定义两次「SCRIPT_FILENAME」,那么它们都会被发送到后端,这可能会导致一些潜在的问题,为了避免此类情况,便引入了一个新的配置文件。

    此外,我们还需要考虑一个安全问题:在PHP开启「cgi.fix_pathinfo」的情况下,PHP可能会把错误的文件类型当作PHP文件来解析。如果Nginx和PHP安装在同一台服务器上的话,那么最简单的解决方法是用「try_files」指令做一次过滤:

     

    try_files $uri =404;

    依照前面的分析,给出一份改良后的版本,是不是比开始的版本清爽了很多:

    server {
        listen 80;
        server_name foo.com;
        root /path;
        index index.html index.htm index.php;
        location / {
            try_files $uri $uri/ /index.php;
        }
        location ~ \.php$ {
           try_files $uri =404;
           include fastcgi.conf;
           fastcgi_pass 127.0.0.1:9000;
       }
    }

     

     

     

     

    六.   Nginx优化


     1. 编译安装过程优化

    1).减小Nginx编译后的文件大小

    在编译Nginx时,默认以debug模式进行,而在debug模式下会插入很多跟踪和ASSERT之类的信息,编译完成后,一个Nginx要有好几兆字节。而在编译前取消Nginx的debug模式,编译完成后Nginx只有几百千字节。因此可以在编译之前,修改相关源码,取消debug模式。具体方法如下:

    在Nginx源码文件被解压后,找到源码目录下的auto/cc/gcc文件,在其中找到如下几行:

     # debug  
    CFLAGS=”$CFLAGS -g” 

    注释掉或删掉这两行,即可取消debug模式。

    2.为特定的CPU指定CPU类型编译优化

    在编译Nginx时,默认的GCC编译参数是“-O”,要优化GCC编译,可以使用以下两个参数:

    1. --with-cc-opt='-O3' 
    2. --with-cpu-opt=CPU  #为特定的 CPU 编译,有效的值包括:
      pentium, pentiumpro, pentium3, # pentium4, athlon, opteron, amd64, sparc32, sparc64, ppc64 

    要确定CPU类型,可以通过如下命令: #cat /proc/cpuinfo | grep "model name" 

     

    2. 利用TCMalloc优化Nginx的性能

    TCMalloc的全称为Thread-Caching Malloc,是谷歌开发的开源工具google-perftools中的一个成员。与标准的glibc库的Malloc相比,TCMalloc库在内存分配效率和速度上要高很多,这在很大程度上提高了服务器在高并发情况下的性能,从而降低了系统的负载。下面简单介绍如何为Nginx添加TCMalloc库支持。

    要安装TCMalloc库,需要安装libunwind(32位操作系统不需要安装)和google-perftools两个软件包,libunwind库为基于64位CPU和操作系统的程序提供了基本函数调用链和函数调用寄存器功能。下面介绍利用TCMalloc优化Nginx的具体操作过程。

    1).安装libunwind库

    可以从http://download.savannah.gnu.org/releases/libunwind下载相应的libunwind版本,这里下载的是libunwind-0.99-alpha.tar.gz。安装过程如下

    #tar zxvf libunwind-0.99-alpha.tar.gz  
    # cd libunwind-0.99-alpha/  
    #CFLAGS=-fPIC ./configure  
    #make CFLAGS=-fPIC  
    #make CFLAGS=-fPIC install

    2).安装google-perftools

    可以从http://google-perftools.googlecode.com下载相应的google-perftools版本,这里下载的是google-perftools-1.8.tar.gz。安装过程如下:

    [root@localhost home]#tar zxvf google-perftools-1.8.tar.gz  
    [root@localhost home]#cd google-perftools-1.8/  
    [root@localhost google-perftools-1.8]# ./configure  
    [root@localhost google-perftools-1.8]#make && make install  
    [root@localhost google-perftools-1.8]#echo "/usr/
    local/lib" > /etc/ld.so.conf.d/usr_local_lib.conf  
    [root@localhost google-perftools-1.8]# ldconfig

    至此,google-perftools安装完成。

    3).重新编译Nginx

    为了使Nginx支持google-perftools,需要在安装过程中添加“–with-google_perftools_module”选项重新编译Nginx。安装代码如下:

    [root@localhostnginx-0.7.65]#./configure \  
    >--with-google_perftools_module --with-http_stub_status_module  --prefix=/opt/nginx  
    [root@localhost nginx-0.7.65]#make  
    [root@localhost nginx-0.7.65]#make install

    到这里Nginx安装完成。

    4).为google-perftools添加线程目录

    创建一个线程目录,这里将文件放在/tmp/tcmalloc下。操作如下:

    [root@localhost home]#mkdir /tmp/tcmalloc  
    [root@localhost home]#chmod 0777 /tmp/tcmalloc

    5).修改Nginx主配置文件

    修改nginx.conf文件,在pid这行的下面添加如下代码:

    #pid        logs/nginx.pid;  
    google_perftools_profiles /tmp/tcmalloc;

    接着,重启Nginx即可完成google-perftools的加载。

    6).验证运行状态

    为了验证google-perftools已经正常加载,可通过如下命令查看:

    [root@ localhost home]# lsof -n | grep tcmalloc  
    nginx      2395 nobody   9w  REG    8,8       0    1599440 /tmp/tcmalloc.2395  
    nginx      2396 nobody   11w REG   8,8       0    1599443 /tmp/tcmalloc.2396  
    nginx      2397 nobody   13w REG  8,8        0    1599441  /tmp/tcmalloc.2397  
    nginx     2398 nobody    15w REG  8,8     0    1599442 /tmp/tcmalloc.2398

    由于在Nginx配置文件中设置worker_processes的值为4,因此开启了4个Nginx线程,每个线程会有一行记录。每个线程文件后面的数字值就是启动的Nginx的pid值。

    至此,利用TCMalloc优化Nginx的操作完成。

    3.Nginx内核参数优化

    内核参数的优化,主要是在Linux系统中针对Nginx应用而进行的系统内核参数优化。

    下面给出一个优化实例以供参考。

    net.ipv4.tcp_max_tw_buckets = 6000
    net.ipv4.ip_local_port_range = 1024 65000  
    net.ipv4.tcp_tw_recycle = 1
    net.ipv4.tcp_tw_reuse = 1
    net.ipv4.tcp_syncookies = 1
    net.core.somaxconn = 262144
    net.core.netdev_max_backlog = 262144
    net.ipv4.tcp_max_orphans = 262144
    net.ipv4.tcp_max_syn_backlog = 262144
    net.ipv4.tcp_synack_retries = 1
    net.ipv4.tcp_syn_retries = 1
    net.ipv4.tcp_fin_timeout = 1
    net.ipv4.tcp_keepalive_time = 30

     

    将上面的内核参数值加入/etc/sysctl.conf文件中,然后执行如下命令使之生效:

    [root@ localhost home]#/sbin/sysctl -p 

    下面对实例中选项的含义进行介绍:

    TCP参数设置:

    net.ipv4.tcp_max_tw_buckets :选项用来设定timewait的数量,默认是180 000,这里设为6000。

    net.ipv4.ip_local_port_range:选项用来设定允许系统打开的端口范围。在高并发情况否则端口号会不够用。当NGINX充当代理时,每个到上游服务器的连接都使用一个短暂或临时端口。

    net.ipv4.tcp_tw_recycle:选项用于设置启用timewait快速回收.

    net.ipv4.tcp_tw_reuse:选项用于设置开启重用,允许将TIME-WAIT sockets重新用于新的TCP连接。

    net.ipv4.tcp_syncookies:选项用于设置开启SYN Cookies,当出现SYN等待队列溢出时,启用cookies进行处理。

    net.ipv4.tcp_max_orphans:选项用于设定系统中最多有多少个TCP套接字不被关联到任何一个用户文件句柄上。如果超过这个数字,孤立连接将立即被复位并打印出警告信息。这个限制只是为了防止简单的DoS攻击。不能过分依靠这个限制甚至人为减小这个值,更多的情况下应该增加这个值。

    net.ipv4.tcp_max_syn_backlog:选项用于记录那些尚未收到客户端确认信息的连接请求的最大值。对于有128MB内存的系统而言,此参数的默认值是1024,对小内存的系统则是128。

    net.ipv4.tcp_synack_retries参数的值决定了内核放弃连接之前发送SYN+ACK包的数量。

    net.ipv4.tcp_syn_retries选项表示在内核放弃建立连接之前发送SYN包的数量。

    net.ipv4.tcp_fin_timeout选项决定了套接字保持在FIN-WAIT-2状态的时间。默认值是60秒。正确设置这个值非常重要,有时即使一个负载很小的Web服务器,也会出现大量的死套接字而产生内存溢出的风险。

    net.ipv4.tcp_syn_retries选项表示在内核放弃建立连接之前发送SYN包的数量。

    如果发送端要求关闭套接字,net.ipv4.tcp_fin_timeout选项决定了套接字保持在FIN-WAIT-2状态的时间。接收端可以出错并永远不关闭连接,甚至意外宕机。

    net.ipv4.tcp_fin_timeout的默认值是60秒。需要注意的是,即使一个负载很小的Web服务器,也会出现因为大量的死套接字而产生内存溢出的风险。FIN-WAIT-2的危险性比FIN-WAIT-1要小,因为它最多只能消耗1.5KB的内存,但是其生存期长些。

    net.ipv4.tcp_keepalive_time选项表示当keepalive启用的时候,TCP发送keepalive消息的频度。默认值是2(单位是小时)。

     

    缓冲区队列:

    net.core.somaxconn:选项的默认值是128, 这个参数用于调节系统同时发起的tcp连接数,在高并发的请求中,默认的值可能会导致链接超时或者重传,因此,需要结合并发请求数来调节此值。

     由NGINX可接受的数目决定。默认值通常很低,但可以接受,因为NGINX 接收连接非常快,但如果网站流量大时,就应该增加这个值。内核日志中的错误消息会提醒这个值太小了,把值改大,直到错误提示消失。
    注意: 如果设置这个值大于512,相应地也要改变NGINX listen指令的backlog参数。

    net.core.netdev_max_backlog:选项表示当每个网络接口接收数据包的速率比内核处理这些包的速率快时,允许发送到队列的数据包的最大数目。

     

    4.PHP-FPM的优化

    如果您高负载网站使用PHP-FPM管理FastCGI,这些技巧也许对您有用:

    1)增加FastCGI进程数

    把PHP FastCGI子进程数调到100或以上,在4G内存的服务器上200就可以建议通过压力测试获取最佳值。

    2)增加 PHP-FPM打开文件描述符的限制

    标签rlimit_files用于设置PHP-FPM对打开文件描述符的限制,默认值为1024。这个标签的值必须和Linux内核打开文件数关联起来,例如,要将此值设置为65 535,就必须在Linux命令行执行“ulimit -HSn 65536”。

           然后 增加 PHP-FPM打开文件描述符的限制:
         # vi /path/to/php-fpm.conf
        找到
    “<valuename="rlimit_files">1024</value>”
    把1024更改为 4096或者更高
    .
    重启 PHP-FPM.

           ulimit -n 要调整为65536甚至更大。如何调这个参数,可以参考网上的一些文章。命令行下执行 ulimit -n 65536即可修改。如果不能修改,需要设置  /etc/security/limits.conf,加入

    * hard nofile65536

    * soft nofile 65536

             3)适当增加max_requests

        标签max_requests指明了每个children最多处理多少个请求后便会被关闭,默认的设置是500。

        <value name="max_requests"> 500 </value>

    5.nginx.conf的参数优化

    nginx要开启的进程数 一般等于cpu的总核数 其实一般情况下开4个或8个就可以。

        每个nginx进程消耗的内存10兆的模样

    worker_cpu_affinity
        仅适用于linux,使用该选项可以绑定worker进程和CPU(2.4内核的机器用不了)

        假如是8 cpu 分配如下:
        worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000

    00100000 01000000 10000000

        nginx可以使用多个worker进程,原因如下:

    to use SMP 
    to decrease latency when workers blockend on disk I/O 
    to limit number of connections per process when select()/poll() is

    used The worker_processes and worker_connections from the event sections

    allows you to calculate maxclients value: k max_clients = worker_processes * worker_connections

    worker_rlimit_nofile 102400;

        每个nginx进程打开文件描述符最大数目 配置要和系统的单进程打开文件数一致,linux 2.6内核下开启文件打开数为65535,worker_rlimit_nofile就相应应该填写65535 nginx调度时分配请求到进程并不是那么的均衡,假如超过会返回502错误。我这里写的大一点

    use epoll

        Nginx使用了最新的epoll(Linux 2.6内核)和kqueue(freebsd)网络I/O模型,而Apache则使用的是传统的select模型。

    处理大量的连接的读写,Apache所采用的select网络I/O模型非常低效。在高并发服务器中,轮询I/O是最耗时间的操作 目前Linux下能够承受高并发

        访问的Squid、Memcached都采用的是epoll网络I/O模型。

    worker_processes 

        NGINX工作进程数(默认值是1)。在大多数情况下,一个CPU内核运行一个工作进程最好,建议将这个指令设置成自动就可以。有时可能想增大这个值,比如当工作进程需要做大量的磁盘I/O。

    worker_connections 65535;
       每个工作进程允许最大的同时连接数 (Maxclient = work_processes * worker_connections)

    keepalive_timeout 75

        keepalive超时时间

        这里需要注意官方的一句话:
    The parameters can differ from each other. Line Keep-Alive:

    timeout=time understands Mozilla and Konqueror. MSIE itself shuts

    keep-alive connection approximately after 60 seconds.

     

    client_header_buffer_size 16k
    large_client_header_buffers 4 32k

    客户请求头缓冲大小 
    nginx默认会用client_header_buffer_size这个buffer来读取header值,如果header过大,它会使用large_client_header_buffers来读取

    如果设置过小HTTP头/Cookie过大 会报400 错误 nginx 400 bad request
    求行如果超过buffer,就会报HTTP 414错误(URI Too Long) nginx接受最长的HTTP头部大小必须比其中一个buffer大,否则就会报400的HTTP错误(Bad Request)。

    open_file_cache max 102400

    使用字段:http, server, location 这个指令指定缓存是否启用,如果启用,将记录文件以下信息: ·打开的文件描述符,大小信息和修改时间. ·存在的目录信息. ·在搜索文件过程中的错误信息 -- 没有这个文件,无法正确读取,参考open_file_cache_errors 指令选项:
    ·max - 指定缓存的最大数目,如果缓存溢出,最长使用过的文件(LRU)将被移除
    例: open_file_cache max=1000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on;

    open_file_cache_errors
    语法:open_file_cache_errors on | off 默认值:open_file_cache_errors off 使用字段:http, server, location 这个指令指定是否在搜索一个文件是记录cache错误.

    open_file_cache_min_uses

    语法:open_file_cache_min_uses number 默认值:open_file_cache_min_uses 1 使用字段:http, server, location 这个指令指定了在open_file_cache指令无效的参数中一定的时间范围内可以使用的最小文件数,如 果使用更大的值,文件描述符在cache中总是打开状态.
    open_file_cache_valid

    语法:open_file_cache_valid time 默认值:open_file_cache_valid 60 使用字段:http, server, location 这个指令指定了何时需要检查open_file_cache中缓存项目的有效信息.


    开启gzip
    gzip on;
    gzip_min_length 1k;
    gzip_buffers 4 16k;
    gzip_http_version 1.0;
    gzip_comp_level 2;
    gzip_types text/plain application/x-javascript text/css

    application/xml;
    gzip_vary on;

    缓存静态文件:

    location ~* ^.+\.(swf|gif|png|jpg|js|css)$ {
        root /usr/local/ku6/ktv/show.ku6.com/;
        expires 1m;
    }

     

    响应缓冲区:

    比如我们Nginx+Tomcat 代理访问JS无法完全加载,这几个参数影响:

    proxy_buffer_size 128k;
    proxy_buffers   32 128k;
    proxy_busy_buffers_size 128k;

    Nginx在代理了相应服务后或根据我们配置的UpStream和location来获取相应的文件,首先文件会被解析到nginx的内存或者临时文件目录中,然后由nginx再来响应。那么当proxy_buffers和proxy_buffer_size以及proxy_busy_buffers_size 都太小时,会将内容根据nginx的配置生成到临时文件中,但是临时文件的大小也有默认值。所以当这四个值都过小时就会导致部分文件只加载一部分。所以要根据我们的服务器情况适当的调整proxy_buffers和proxy_buffer_size以及proxy_busy_buffers_size、proxy_temp_file_write_size。具体几个参数的详细如下:

    proxy_buffers   32 128k;  设置了32个缓存区,每个的大小是128k

    proxy_buffer_size 128k; 每个缓存区的大小是128k,当两个值不一致时没有找到具体哪个有效,建议和上面的设置一致。

    proxy_busy_buffers_size 128k;设置使用中的缓存区的大小,控制传输至客户端的缓存的最大

    proxy_temp_file_write_size 缓存文件的大小

     

    6.优化访问日志

        记录每个请求会消耗CPU和I/O周期,一种降低这种影响的方式是缓冲访问日志。使用缓冲,而不是每条日志记录都单独执行写操作,NGINX会缓冲一连串的日志记录,使用单个操作把它们一起写到文件中。
        要启用访问日志的缓存,就涉及到在access_log指令中buffer=size这个参数。当缓冲区达到size值时,NGINX会把缓冲区的内容写到日志中。让NGINX在指定的一段时间后写缓存,就包含flush=time参数。当两个参数都设置了,当下个日志条目超出缓冲区值或者缓冲区中日志条目存留时间超过设定的时间值,NGINX都会将条目写入日志文件。当工作进程重新打开它的日志文件或退出时,也会记录下来。要完全禁用访问日志记录的功能,将access_log 指令设置成off参数。

     

    7.限流

    你可以设置多个限制,防止用户消耗太多的资源,避免影响系统性能和用户体验及安全。 以下是相关的指令:
    limit_conn and limit_conn_zone:NGINX接受客户连接的数量限制,例如单个IP地址的连接。设置这些指令可以防止单个用户打开太多的连接,消耗超出自己的资源。
    limit_rate:传输到客户端响应速度的限制(每个打开多个连接的客户消耗更多的带宽)。设置这个限制防止系统过载,确保所有客户端更均匀的服务质量。
    limit_req and limit_req_zone:NGINX处理请求的速度限制,与limit_rate有相同的功能。可以提高安全性,尤其是对登录页面,通过对用户限制请求速率设置一个合理的值,避免太慢的程序覆盖你的应用请求(比如DDoS攻击)。
    max_conns:上游配置块中服务器指令参数。在上游服务器组中单个服务器可接受最大并发数量。使用这个限制防止上游服务器过载。设置值为0(默认值)表示没有限制。
    queue (NGINX Plus) :创建一个队列,用来存放在上游服务器中超出他们最大max_cons限制数量的请求。这个指令可以设置队列请求的最大值,还可以选择设置在错误返回之前最大等待时间(默认值是60秒)。如果忽略这个指令,请求不会放入队列。

     

     

     

     

    七.   错误排查


    1、Nginx 502 Bad Gateway:

    作为网关或者代理工作的服务器尝试执行请求时,从上游服务器接收到无效的响应。

    常见原因:
    1、后端服务挂了的情况,直接502 (nginx error日志:connect() failed (111: Connection refused) )
    2、后端服务在重启
    实例:将后端服务关掉,然后向nginx发送请求后端接口,nginx日志可以看到502错误。

    如果nginx+php出现502, 错误分析:

    php-cgi进程数不够用、php执行时间长(mysql慢)、或者是php-cgi进程死掉,都会出现502错误

    一般来说Nginx 502 Bad Gateway和php-fpm.conf的设置有关,而Nginx 504 Gateway Time-out则是与nginx.conf的设置有关

    1)、查看当前的PHP FastCGI进程数是否够用:

    netstat -anpo | grep "php-cgi" | wc -l

      如果实际使用的“FastCGI进程数”接近预设的“FastCGI进程数”,那么,说明“FastCGI进程数”不够用,需要增大。

    2)、部分PHP程序的执行时间超过了Nginx的等待时间,可以适当增加

         nginx.conf配置文件中FastCGI的timeout时间,例如:

    http {
        ......
        fastcgi_connect_timeout 300;
        fastcgi_send_timeout 300;
        fastcgi_read_timeout 300;
        ......
    }

    2、504 Gateway Timeout :

    nginx作为网关或者代理工作的服务器尝试执行请求时,未能及时从上游服务器(URI标识出的服务器,例如HTTP、FTP、LDAP)收到响应。

    常见原因:
    该接口太耗时,后端服务接收到请求,开始执行,未能在设定时间返回数据给nginx
    后端服务器整体负载太高,接受到请求之后,由于线程繁忙,未能安排给请求的接口,导致未能在设定时间返回数据给nginx

     

    2、413 Request Entity Too Large
       

        解决:增大client_max_body_size

        client_max_body_size:指令指定允许客户端连接的最大请求实体大小,它出现在请求头部的Content-Length字段. 如果请求大于指定的值,客户端将收到一个"Request Entity Too Large" (413)错误. 记住,浏览器并不知道怎样显示这个错误.

        php.ini中增大
    post_max_size 和upload_max_filesize

    3、 Ngnix error.log出现:upstream sent too big header while reading response header from upstream错误

    1)如果是nginx反向代理
       proxy是nginx作为client转发时使用的,如果header过大,超出了默认的1k,就会引发上述的upstream sent too big header (说白了就是nginx把外部请求给后端server,后端server返回的header  太大nginx处理不过来就导致了。

      server {
            listen       80;
            server_name  *.xywy.com ;

            large_client_header_buffers 4 16k;

            location / {

              #添加这3行 
               proxy_buffer_size 64k;
               proxy_buffers   32 32k;
               proxy_busy_buffers_size 128k;

               proxy_set_header Host $host;
               proxy_set_header X-Real-IP       $remote_addr;
               proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;

        }

    }        

    2) 如果是 nginx+PHPcgi 

      错误带有 upstream: "fastcgi://127.0.0.1:9000"。就该 

      多加:

      fastcgi_buffer_size 128k;
      fastcgi_buffers 4 128k;

    server {
            listen       80;
            server_name  ddd.com;
            index index.html index.htm index.php;
       
            client_header_buffer_size 128k;
            large_client_header_buffers 4 128k;
            proxy_buffer_size 64k;
            proxy_buffers 8 64k;
            fastcgi_buffer_size 128k;
            fastcgi_buffers 4 128k;

            location / {

              ......

            }

    }         

     

    八  、 Nginx的php漏洞


    漏洞介绍:nginx是一款高性能的web服务器,使用非常广泛,其不仅经常被用作反向代理,也可以非常好的支持PHP的运行。80sec发现其中存在一个较为严重的安全问题,默认情况下可能导致服务器错误的将任何类型的文件以PHP的方式进行解析,这将导致严重的安全问题,使得恶意的攻击者可能攻陷支持php的nginx服务器。
    漏洞分析:nginx默认以cgi的方式支持php的运行,譬如在配置文件当中可以以
    location ~ .php$ {
    root html;
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name;
    include fastcgi_params;
    }


    的方式支持对php的解析,location对请求进行选择的时候会使用URI环境变量进行选择,其中传递到后端Fastcgi的关键变量SCRIPT_FILENAME由nginx生成的$fastcgi_script_name决定,而通过分析可以看到$fastcgi_script_name是直接由URI环境变量控制的,这里就是产生问题的点。而为了较好的支持PATH_INFO的提取,在PHP的配置选项里存在cgi.fix_pathinfo选项,其目的是为了从SCRIPT_FILENAME里取出真正的脚本名。
    那么假设存在一个http://www.80sec.com/80sec.jpg,我们以如下的方式去访问

    http://www.80sec.com/80sec.jpg/80sec.php
    将会得到一个URI
    /80sec.jpg/80sec.php

    经过location指令,该请求将会交给后端的fastcgi处理,nginx为其设置环境变量SCRIPT_FILENAME,内容为
    /scripts/80sec.jpg/80sec.php
    而在其他的webserver如lighttpd当中,我们发现其中的SCRIPT_FILENAME被正确的设置为
    /scripts/80sec.jpg
    所以不存在此问题。
    后端的fastcgi在接受到该选项时,会根据fix_pathinfo配置决定是否对SCRIPT_FILENAME进行额外的处理,一般情况下如果不对fix_pathinfo进行设置将影响使用PATH_INFO进行路由选择的应用,所以该选项一般配置开启。Php通过该选项之后将查找其中真正的脚本文件名字,查找的方式也是查看文件是否存在,这个时候将分离出SCRIPT_FILENAME和PATH_INFO分别为
    /scripts/80sec.jpg和80sec.php
    最后,以/scripts/80sec.jpg作为此次请求需要执行的脚本,攻击者就可以实现让nginx以php来解析任何类型的文件了。

    POC: 访问一个nginx来支持php的站点,在一个任何资源的文件如robots.txt后面加上/80sec.php,这个时候你可以看到如下的区别:

    访问http://www.80sec.com/robots.txt

    HTTP/1.1 200 OK
    Server: nginx/0.6.32
    Date: Thu, 20 May 2010 10:05:30 GMT
    Content-Type: text/plain
    Content-Length: 18
    Last-Modified: Thu, 20 May 2010 06:26:34 GMT
    Connection: keep-alive
    Keep-Alive: timeout=20
    Accept-Ranges: bytes


    访问访问http://www.80sec.com/robots.txt/80sec.php

    HTTP/1.1 200 OK
    Server: nginx/0.6.32
    Date: Thu, 20 May 2010 10:06:49 GMT
    Content-Type: text/html
    Transfer-Encoding: chunked
    Connection: keep-alive
    Keep-Alive: timeout=20
    X-Powered-By: PHP/5.2.6


    其中的Content-Type的变化说明了后端负责解析的变化,该站点就可能存在漏洞。

    漏洞厂商:http://www.nginx.org

    解决方案:

    我们已经尝试联系官方,但是此前你可以通过以下的方式来减少损失

    关闭cgi.fix_pathinfo为0

    或者

    if ( $fastcgi_script_name ~ ..*/.*php ) {
    return 403;
    }

    PS: 鸣谢laruence大牛在分析过程中给的帮助

     

    展开全文
  • MTCNN工作原理

    万次阅读 多人点赞 2018-11-01 17:47:26
    MTCNN工作原理 MTCNN是什么 MTCNN,Multi-task convolutional neural network(多任务卷积神经网络),将人脸区域检测与人脸关键点检测放在了一起,基于cascade框架。总体可分为PNet、RNet、和ONet三层网络结构, ...

    MTCNN工作原理

    MTCNN是什么

    MTCNN,Multi-task convolutional neural network(多任务卷积神经网络),将人脸区域检测与人脸关键点检测放在了一起,它的主题框架类似于cascade。总体可分为P-Net、R-Net、和O-Net三层网络结构。

    它是2016年中国科学院深圳研究院提出的用于人脸检测任务的多任务神经网络模型,该模型主要采用了三个级联的网络,采用候选框加分类器的思想,进行快速高效的人脸检测。这三个级联的网络分别是快速生成候选窗口的P-Net、进行高精度候选窗口过滤选择的R-Net和生成最终边界框与人脸关键点的O-Net。和很多处理图像问题的卷积神经网络模型,该模型也用到了图像金字塔、边框回归、非最大值抑制等技术。

    MTCNN实现流程

    构建图像金字塔

    首先将图像进行不同尺度的变换,构建图像金字塔,以适应不同大小的人脸的进行检测。

    P-Net

    全称为Proposal Network,其基本的构造是一个全卷积网络。对上一步构建完成的图像金字塔,通过一个FCN进行初步特征提取与标定边框,并进行Bounding-Box Regression调整窗口与NMS进行大部分窗口的过滤。

    P-Net是一个人脸区域的区域建议网络,该网络的将特征输入结果三个卷积层之后,通过一个人脸分类器判断该区域是否是人脸,同时使用边框回归和一个面部关键点的定位器来进行人脸区域的初步提议,该部分最终将输出很多张可能存在人脸的人脸区域,并将这些区域输入R-Net进行进一步处理。

    这一部分的基本思想是使用较为浅层、较为简单的CNN快速生成人脸候选窗口。

    Proposal Network

    R-Net

    全称为Refine Network,其基本的构造是一个卷积神经网络,相对于第一层的P-Net来说,增加了一个全连接层,因此对于输入数据的筛选会更加严格。在图片经过P-Net后,会留下许多预测窗口,我们将所有的预测窗口送入R-Net,这个网络会滤除大量效果比较差的候选框,最后对选定的候选框进行Bounding-Box RegressionNMS进一步优化预测结果。

    因为P-Net的输出只是具有一定可信度的可能的人脸区域,在这个网络中,将对输入进行细化选择,并且舍去大部分的错误输入,并再次使用边框回归和面部关键点定位器进行人脸区域的边框回归和关键点定位,最后将输出较为可信的人脸区域,供O-Net使用。对比与P-Net使用全卷积输出的1x1x32的特征,R-Net使用在最后一个卷积层之后使用了一个128的全连接层,保留了更多的图像特征,准确度性能也优于P-Net。

    R-Net的思想是使用一个相对于P-Net更复杂的网络结构来对P-Net生成的可能是人脸区域区域窗口进行进一步选择和调整,从而达到高精度过滤和人脸区域优化的效果。

    Refine Network

    O-Net

    全称为Output Network,基本结构是一个较为复杂的卷积神经网络,相对于R-Net来说多了一个卷积层。O-Net的效果与R-Net的区别在于这一层结构会通过更多的监督来识别面部的区域,而且会对人的面部特征点进行回归,最终输出五个人脸面部特征点。

    是一个更复杂的卷积网络,该网络的输入特征更多,在网络结构的最后同样是一个更大的256的全连接层,保留了更多的图像特征,同时再进行人脸判别、人脸区域边框回归和人脸特征定位,最终输出人脸区域的左上角坐标和右下角坐标与人脸区域的五个特征点。O-Net拥有特征更多的输入和更复杂的网络结构,也具有更好的性能,这一层的输出作为最终的网络模型输出。

    O-Net的思想和R-Net类似,使用更复杂的网络对模型性能进行优化

    Output Network

    集成架构及系统思想

    MTCNN为了兼顾性能和准确率,避免滑动窗口加分类器等传统思路带来的巨大的性能消耗,先使用小模型生成有一定可能性的目标区域候选框,然后在使用更复杂的模型进行细分类和更高精度的区域框回归,并且让这一步递归执行,以此思想构成三层网络,分别为P-Net、R-Net、O-Net,实现快速高效的人脸检测。在输入层使用图像金字塔进行初始图像的尺度变换,并使用P-Net生成大量的候选目标区域框,之后使用R-Net对这些目标区域框进行第一次精选和边框回归,排除大部分的负例,然后再用更复杂的、精度更高的网络O-Net对剩余的目标区域框进行判别和区域边框回归。

    下面是整个系统的工作流图

    工作流程

    技术细节

    FCN(全卷积网络)

    全卷积网络就是去除了传统卷积网络的全连接层,然后对其进行反卷积对最后一个卷积层(或者其他合适的卷积层)的feature map进行上采样,使其恢复到原有图像的尺寸(或者其他),并对反卷积图像的每个像素点都可以进行一个类别的预测,同时保留了原有图像的空间信息。
    同时,在反卷积对图像进行操作的过程中,也可以通过提取其他卷积层的反卷积结果对最终图像进行预测,合适的选择会使得结果更好、更精细。

    IoU

    对于某个图像的子目标图像和对这个子目标图像进行标定的预测框,把最终标定的预测框与真实子图像的自然框(通常需要人工标定)的某种相关性叫做IOU(Intersection over Union),经常使用的标准为两个框的交叉面积与合并面积之和。

    Bounding-Box regression:

    • 解决的问题:
      IOU小于某个值时,一种做法是直接将其对应的预测结果丢弃,而Bounding-Box regression的目的是对此预测窗口进行微调,使其接近真实值。
    • 具体逻辑
      在图像检测里面,子窗口一般使用四维向量(x,y,w,h)表示,代表着子窗口中心所对应的母图像坐标与自身宽高,目标是在前一步预测窗口对于真实窗口偏差过大的情况下,使得预测窗口经过某种变换得到更接近与真实值的窗口。
      在实际使用之中,变换的输入输出按照具体算法给出的已经经过变换的结果和最终适合的结果的变换,可以理解为一个损失函数的线性回归。

    NMS(非极大值抑制)

    顾名思义,非极大值抑制就是抑制不是极大值的元素。在目标检测领域里面,可以使用该方法快速去掉重合度很高且标定相对不准确的预测框,但是这种方法对于重合的目标检测不友好。

    Soft-NMS

    对于优化重合目标检测的一种改进方法。核心在于在进行NMS的时候不直接删除被抑制的对象,而是降低其置信度。处理之后在最后统一一个置信度进行统一删除。

    PRelu

    MTCNN中,卷积网络采用的激活函数是PRelu,带有参数的带有参数的Relu,相对于Relu滤除负值的做法,PRule对负值进行了添加参数而不是直接滤除,这种做法会给算法带来更多的计算量和更多的过拟合的可能性,但是由于保留了更多的信息,也可能是训练结果拟合性能更好。

    我的思考

    对于Soft-NMS来说,在进行非极大值抑制的时候,可以结合实际应用场景将部分重合的窗口的置信度与其重合度进行线性或者非线性变换来进行更富有逻辑意义的滤除,而不是简单的降低置信度之后进行统一滤除。
    在进行卷积的时候,是否能够使用不同大小的卷积核使得卷积网络更加敏捷,同时保留、突出的特征更多,从而进一步提高算法的精度与效率。

    参考文献

    1. Joint Face Detection and Alignment using Multi-task Cascaded Convolutional Networks
    2. Ways for Visualizing Convolutional Networks
    3. 全卷积网络 FCN 详解
    4. FCN
    5. 非极大值抑制(Non-Maximum Suppression,NMS)
    6. 【论文解析】MTCNN论文要点翻译
    展开全文
  • Mybatis工作原理

    万次阅读 多人点赞 2018-06-24 00:16:53
    本片博客针对Mybatis内部工作原理进行阐述。 一、Mybatis工作原理图 mybatis 原理图如下所示: 二、工作原理解析 mybatis应用程序通过SqlSessionFactoryBuilder从mybatis-config.xml配置文件(也...

    引言

    在mybatis的基础知识中我们已经可以对mybatis的工作方式窥斑见豹(参考:《MyBatis————基础知识》)。

    本片博客针对Mybatis内部工作原理进行阐述。

    一、Mybatis工作原理图

    mybatis 原理图如下所示:

    二、工作原理解析

    mybatis应用程序通过SqlSessionFactoryBuilder从mybatis-config.xml配置文件(也可以用Java文件配置的方式,需要添加@Configuration)来构建SqlSessionFactory(SqlSessionFactory是线程安全的);

    然后,SqlSessionFactory的实例直接开启一个SqlSession,再通过SqlSession实例获得Mapper对象并运行Mapper映射的SQL语句,完成对数据库的CRUD和事务提交,之后关闭SqlSession。

    说明:SqlSession是单线程对象,因为它是非线程安全的,是持久化操作的独享对象,类似jdbc中的Connection,底层就封装了jdbc连接。

    详细流程如下:

    1、加载mybatis全局配置文件(数据源、mapper映射文件等),解析配置文件,MyBatis基于XML配置文件生成Configuration,和一个个MappedStatement(包括了参数映射配置、动态SQL语句、结果映射配置),其对应着<select | update | delete | insert>标签项。

    2、SqlSessionFactoryBuilder通过Configuration对象生成SqlSessionFactory,用来开启SqlSession。

    3、SqlSession对象完成和数据库的交互:
    a、用户程序调用mybatis接口层api(即Mapper接口中的方法)
    b、SqlSession通过调用api的Statement ID找到对应的MappedStatement对象
    c、通过Executor(负责动态SQL的生成和查询缓存的维护)将MappedStatement对象进行解析,sql参数转化、动态sql拼接,生成jdbc Statement对象
    d、JDBC执行sql。

    e、借助MappedStatement中的结果映射关系,将返回结果转化成HashMap、JavaBean等存储结构并返回。

    mybatis层次图:

    原图:https://blog.csdn.net/xudan1010/article/details/53435018

    参考文章:

    Mybatis实现原理深入解析

    Mybatis之工作原理

    mybatis加载顺序

     

    展开全文
  • cache结构与工作原理

    万次阅读 多人点赞 2017-11-23 14:44:55
    在经历N次的阅读之后,终于明白了cache的结构和工作原理。 首先,要想理解cache,先理解内存。内存的简单表示如下图,内存里面的内容的查找是根据地址来进行的,也就是说内存包含两点①地址②内存的内容(存的数据...
  • HTTPS工作原理

    万次阅读 2020-11-23 16:57:07
    HTTPS工作原理 在传统的HTTP协议中,在网络上传播的信息有可能被窃听,篡改。而HTTPS的引入,就是为了解决这些安全问题,下面我们就来探究一下HTTPS的工作原理。 什么是HTTPS HTTPS是一种以安全为目标的HTTP协议,...
  • SpringMVC框架工作流程图及工作原理

    万次阅读 多人点赞 2018-07-10 09:13:39
    SpringMVC框架的工作原理图:SpringMVC的具体工作原理1、客户端用户发送请求至前端控制器DispatcherServlet。2、DispatcherServlet收到请求调用HandlerMapping处理器映射器。3、HandlerMapping处理器映射器找到具体...
  • Webservice工作原理及实例

    万次阅读 多人点赞 2016-04-04 23:12:08
    Web Service工作原理 一、Web Service基本概念 Web Service也叫XML Web Service WebService是一种可以接收从Internet或者Intranet上的其它系统中传递过来的请求,轻量级的独立的通讯技术。是:通过SOAP在Web上提供的...
  • RGB-D相机的TOF的工作原理是什么?

    万次阅读 多人点赞 2019-07-31 16:22:06
    TOF的工作原理
  • MyBatis工作原理

    千次阅读 多人点赞 2019-09-24 16:49:16
    在学习 MyBatis 程序之前,需要了解一下 MyBatis 工作原理,以便于理解程序。MyBatis 的工作原理如下图 1)读取 MyBatis 配置文件:mybatis-config.xml 为 MyBatis 的全局配置文件,配置了 MyBatis 的运行环境等...
  • Java虚拟机工作原理详解

    万次阅读 多人点赞 2012-12-21 15:03:32
     从这个框图很容易从大体上了解java程序工作原理。首先,你写好java代码,保存到硬盘当中。然后你在命令行中输入javac YourClassName.java此时,你的java代码就被编译成字节码(.class).如果你是在Eclipse IDE或者...
  • SpringCloudg工作原理

    千次阅读 2018-05-25 10:52:30
    服务注册发现组件Eureka工作原理服务网关组件Zuul工作原理跨域时序图Eureka与Ribbon整合工作原理解决分布式一致性级联故障流程断路器组件Hystrix工作原理分布式追踪Sleuth工作原理SpringBoot自动配置工作原理...
  • Hadoop_MapReduce_OutputFormat工作原理

    万次阅读 2020-05-04 22:13:28
    Hadoop_MapReduce_OutputFormat工作原理 OutputFormat 的作用: 校验job中指定输出路径是否存在 将结果写入输出文件 OutputFormat是一个抽象类,有以下几个子类: DBOutputFormat FileOutputFormat ...
  • MPU6050工作原理及STM32控制MPU6050

    万次阅读 多人点赞 2017-08-01 21:49:48
    要想知道MPU6050工作原理,得先了解下面俩个传感器:①陀螺仪传感器: 陀螺仪的原理就是,一个旋转物体的旋转轴所指的方向在不受外力影响时,是不会改变的。人们根据这个道理,用它来保持方向。然后用多种方法读取...
  • SpringMvc工作原理学习总结

    千次阅读 多人点赞 2020-11-07 10:42:47
    SpringMvc工作原理 了解SpringMvc之前先看看Mvc的工作原理 1、MVC工作原理 M:Model(完成业务逻辑 Service/dao/entity/) V:View(完成界面渲染 jsp/html) C:Controller(控制器->类似于CPU 接受请求->调用M...
  • gunicorn工作原理

    万次阅读 2017-11-10 09:46:14
    gunicorn工作原理 Gunicorn“绿色独角兽”是一个被广泛使用的高性能的Python WSGI UNIX HTTP服务器,移植自Ruby的独角兽(Unicorn )项目,使用pre-fork worker模式,具有使用非常简单,轻量级的资源消耗,以及高...
  • SpringMVC工作原理

    万次阅读 多人点赞 2013-11-25 11:19:08
    其主要工作有以下三项: 截获符合特定格式的URL请求。 初始化DispatcherServlet上下文对应的WebApplicationContext,并将其与业务层、持久化层的WebApplicationContext建立关联。 初始化Spring ...
  • springMVC工作原理

    千次阅读 2018-05-10 09:45:13
    不错的springMVC工作原理讲解,保存下,后续学习巩固:springMVC工作原理
  • 路由器工作原理

    万次阅读 多人点赞 2019-02-05 15:00:34
    路由:路由器控制层面的工作,决定数据包从来源端到目的端所经过的路由路径(host到host至今的最佳传输路径) 转发:路由器数据层面的工作,将路由器输入端的数据包移送至适当的路由器输出端...
  • 虚拟机工作原理

    千次阅读 2017-07-22 11:27:32
    Java虚拟机工作原理
  • 锁相环工作原理

    千次阅读 2019-06-17 09:12:50
    看了许多锁相环工作原理的资料,感觉讲得比较抽象,难以理解,多数时候我们只需要理解其基本原理和使用方法就可以了,下面结合一款单片机里面的锁相环来讲述其基本原理和使用方法: 一个芯片内部如果需要多个...
  • GPS工作原理

    千次阅读 2017-03-23 15:21:45
    GPS工作原理简介
  • dubbo的工作原理

    万次阅读 多人点赞 2019-03-08 10:34:01
    dubbo的工作原理 1、面试题 说一下的dubbo的工作原理?注册中心挂了可以继续通信吗?说说一次rpc请求的流程? 2、面试官心里分析 MQ、ES、Redis、Dubbo,上来先问你一些思考的问题,原理(kafka高可用架构原理、es...
  • Akka工作原理

    千次阅读 2015-11-12 11:50:34
    Akka工作原理
  • 三极管工作原理详解

    万次阅读 多人点赞 2019-05-09 19:06:35
    1、三极管工作原理详解 2、图说三极管的三个工作状态 3、图解三极管基本知识及电子电路图 半导体三极管,又称为双极结型晶体管(bipolar junction transistor, BJT)。 广义上,三极管有多种,常见如下图所示 。 ...
  • 多角度带你认清Kylin的工作原理

    万次阅读 多人点赞 2020-05-16 09:22:09
     ...文章目录Kylin的工作原理维度和度量Cube 和 Cuboid工作原理技术架构总结 Kylin的工作原理         Apache Kylin的工作原理本质上是 MOLAP(多维立方

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 193,952
精华内容 77,580
关键字:

工作原理