Linux CentOS 服务器搭建与初始化配置图文详解

# 定义 Nginx 运行的用户和用户组
user www www;

#nginx 进程数，建议设置为等于 CPU 总核心数。
worker_processes8;

# 全局错误日志定义类型，[debug| info | notice | warn | error | crit ]
error_log/usr/local/nginx/logs/error.log info;

# 进程 pid 文件
pid/usr/local/nginx/logs/nginx.pid;

# 指定进程可以打开的最大描述符：数目
# 工作模式与连接数上限
# 这个指令是指当一个 nginx 进程打开的最多文件描述符数目，理论值应该是最多打开文件数（ulimit-n）与 nginx 进程数相除，但是 nginx 分配请求并不是那么均匀，所以最好与 ulimit –n 的值保持一致。
# 现在在 linux2.6 内核下开启文件打开数为 65535，worker_rlimit_nofile 就相应应该填写 65535。
# 这是因为 nginx 调度时分配请求到进程并不是那么的均衡，所以假如填写 10240，总并发量达到 3 – 4 万时就有进程可能超过 10240 了，这时会返回 502 错误。
worker_rlimit_nofile65535;

events
{
    #参考事件模型，use [kqueue| rtsig | epoll | /dev/poll | select | poll ]; epoll 模型
    #是 Linux2.6 以上版本内核中的高性能网络 I / O 模型，linux 建议 epoll，如果跑在 FreeBSD 上面，就用 kqueue 模型。
    #补充说明：
    #与 apache 相类，nginx 针对不同的操作系统，有不同的事件模型
    #A）标准事件模型
    #Select、poll 属于标准事件模型，如果当前系统不存在更有效的方法，nginx 会选择 select 或 poll
    #B）高效事件模型
    #Kqueue：使用于 FreeBSD4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X. 使用双处理器的 MacOS X 系统使用 kqueue 可能会造成内核崩溃。
    #Epoll：使用于 Linux 内核 2.6 版本及以后的系统。
    #/dev/poll：使用于 Solaris 7 11/99+，HP/UX 11.22+ (eventport)，IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+。
    #Eventport：使用于 Solaris10。为了防止出现内核崩溃的问题，有必要安装安全补丁。
    use epoll;

    #单个进程最大连接数（最大连接数 = 连接数 * 进程数）
    #根据硬件调整，和前面工���进程配合起来用，尽量大，但是别把 cpu 跑到 100%就行。每个进程允许的最多连接数，理论上每台 nginx 服务器的最大连接数为。
    worker_connections65535;

    #keepalive 超时时间。
    keepalive_timeout60;

    #客户端请求头部的缓冲区大小。这个可以根据你的系统分页大小来设置，一般一个请求头的大小不会超过 1k，不过由于一般系统分页都要大于 1k，所以这里设置为分页大小。
    #分页大小可以用命令 getconf PAGESIZE 取得。
    #[root@web001~]# getconf PAGESIZE
    #4096
    #但也有 client_header_buffer_size 超过 4k 的情况，但是 client_header_buffer_size 该值必须设置为“系统分页大小”的整倍数。
    client_header_buffer_size 4k;

    #这个将为打开文件指定缓存，默认是没有启用的，max 指定缓存数量，建议和打开文件数一致，inactive 是指经过多长时间文件没被请求后删除缓存。
    open_file_cache max=65535 inactive=60s;

    #这个是指多长时间检查一次缓存的有效信息。
    #语法:open_file_cache_valid time 默认值:open_file_cache_valid60 使用字段:http, server, location 这个指令指定了何时需要检查 open_file_cache 中缓存项目的有效信息.
    open_file_cache_valid 80s;

    #open_file_cache 指令中的 inactive 参数时间内文件的最少使用次数，如果超过这个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个文件在 inactive 时间内一次没被使用，它将被移除。
    #语法:open_file_cache_min_uses number 默认值:open_file_cache_min_uses1 使用字段:http, server, location  这个指令指定了在 open_file_cache 指令无效的参数中一定的时间范围内可以使用的最小文件数, 如果使用更大的值, 文件描述符在 cache 中总是打开状态.
    open_file_cache_min_uses1;
   
    #语法:open_file_cache_errors on| off 默认值:open_file_cache_errors off 使用字段:http, server, location 这个指令指定是否在搜索一个文件是记录 cache 错误.
    open_file_cache_errors on;
}

# 设定 http 服务器，利用它的反向代理功能提供负载均衡支持
http
{
    #文件扩展名与文件类型映射表
    include mime.types;

    #默认文件类型
    default_type application/octet-stream;

    #默认编码
    #charset utf-8;

    #服务器名字的 hash 表大小
    #保存服务器名字的 hash 表是由指令 server_names_hash_max_size 和 server_names_hash_bucket_size 所控制的。参数 hash bucket size 总是等于 hash 表的大小，并且是一路处理器缓存大小的倍数。在减少了在内存中的存取次数后，使在处理器中加速查找 hash 表键值成为可能。如果 hash bucket size 等于一路处理器缓存的大小，那么在查找键的时候，最坏的情况下在内存中查找的次数为 2。第一次是确定存储单元的地址，第二次是在存储单元中查找键 值。因此，如果 Nginx 给出需要增大 hash max size 或 hash bucket size 的提示，那么首要的是增大前一个参数的大小.
    server_names_hash_bucket_size128;

    #客户端请求头部的缓冲区大小。这个可以根据你的系统分页大小来设置，一般一个请求的头部大小不会超过 1k，不过由于一般系统分页都要大于 1k，所以这里设置为分页大小。分页大小可以用命令 getconf PAGESIZE 取得。
    client_header_buffer_size 32k;

    #客户请求头缓冲大小。nginx 默认会用 client_header_buffer_size 这个 buffer 来读取 header 值，如果 header 过大，它会使用 large_client_header_buffers 来读取。
    large_client_header_buffers4 64k;

    #设定通过 nginx 上传文件的大小
    client_max_body_size 8m;

    #开启高效文件传输模式，sendfile 指令指定 nginx 是否调用 sendfile 函数来输出文件，对于普通应用设为 on，如果用来进行下载等应用磁盘 IO 重负载应用，可设置为 off，以平衡磁盘与网络 I / O 处理速度，降低系统的负载。注意：如果图片显示不正常把这个改成 off。
    #sendfile 指令指定 nginx 是否调用 sendfile 函数（zero copy 方式）来输出文件，对于普通应用，必须设为 on。如果用来进行下载等应用磁盘 IO 重负载应用，可设置为 off，以平衡磁盘与网络 IO 处理速度，降低系统 uptime。
    sendfile on;

    #开启目录列表访问，合适下载服务器，默认关闭。
    autoindex on;

    #此选项允许或禁止使用 socke 的 TCP_CORK 的选项，此选项仅在使用 sendfile 的时候使用
    tcp_nopush on;
   
    tcp_nodelay on;

    #长连接超时时间，单位是秒
    keepalive_timeout120;

    #FastCGI 相关参数是为了改善网站的性能：减少资源占用，提高访问速度。下面参数看字面意思都能理解。
    fastcgi_connect_timeout300;
    fastcgi_send_timeout300;
    fastcgi_read_timeout300;
    fastcgi_buffer_size 64k;
    fastcgi_buffers4 64k;
    fastcgi_busy_buffers_size 128k;
    fastcgi_temp_file_write_size 128k;

    #gzip 模块设置
    gzip on; #开启 gzip 压缩输出
    gzip_min_length 1k;    #最小压缩文件大小
    gzip_buffers4 16k;    #压缩缓冲区
    gzip_http_version1.0;    #压缩版本（默认 1.1，前端如果是 squid2.5 请使用 1.0）
    gzip_comp_level2;    #压缩等级
    gzip_types text/plain application/x-javascript text/css application/xml;    #压缩类型，默认就已经包含 textml，所以下面就不用再写了，写上去也不会有问题，但是会有一个 warn。
    gzip_vary on;

    #开启限制 IP 连接数的时候需要使用
    #limit_zone crawler $binary_remote_addr 10m;

    #负载均衡配置
    upstream piao.jd.com {
   
        #upstream 的负载均衡，weight 是权重，可以根据机器配置定义权重。weigth 参数表示权值，权值越高被分配到的几率越大。
        server192.168.80.121:80 weight=3;
        server192.168.80.122:80 weight=2;
        server192.168.80.123:80 weight=3;

        #nginx 的 upstream 目前支持 4 种方式的分配
        #1、轮询（默认）
        #每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器 down 掉，能自动剔除。
        #2、weight
        #指定轮询几率，weight 和访问比率成正比，用于后端服务器性能不均的情况。
        #例如：
        #upstream bakend {
        #    server192.168.0.14 weight=10;
        #    server192.168.0.15 weight=10;
        #}
        #2、ip_hash
        #每个请求按访问 ip 的 hash 结果分配，这样每个访客固定访问一个后端服务器，可以解决 session 的问题。
        #例如：
        #upstream bakend {
        #    ip_hash;
        #    server192.168.0.14:88;
        #    server192.168.0.15:80;
        #}
        #3、fair（第三方）
        #按后端服务器的响应时间来分配请求，响应时间短的优先分配。
        #upstream backend {
        #    server server1;
        #    server server2;
        #    fair;
        #}
        #4、url_hash（第三方）
        #按访问 url 的 hash 结果来分配请求，使每个 url 定向到同一个后端服务器，后端服务器为缓存时比较有效。
        #例：在 upstream 中加入 hash 语句，server 语句中不能写入 weight 等其他的参数，hash_method 是使用的 hash 算法
        #upstream backend {
        #    server squid1:3128;
        #    server squid2:3128;
        #    hash $request_uri;
        #    hash_method crc32;
        #}

        #tips:
        #upstream bakend{# 定义负载均衡设备的 Ip 及设备状态}{
        #    ip_hash;
        #    server127.0.0.1:9090 down;
        #    server127.0.0.1:8080 weight=2;
        #    server127.0.0.1:6060;
        #    server127.0.0.1:7070 backup;
        #}
        #在需要使用负载均衡的 server 中增加 proxy_pass http://bakend/;

        #每个设备的状态设置为:
        #1.down 表示单前的 server 暂时不参与负载
        #2.weight 为 weight 越大，负载的权重就越大。
        #3.max_fails：允许请求失败的次数默认为 1. 当超过最大次数时，返回 proxy_next_upstream 模块定义的错误
        #4.fail_timeout:max_fails 次失败后，暂停的时间。
        #5.backup：其它所有的非 backup 机器 down 或者忙的时候，请求 backup 机器。所以这台机器压力会最轻。