(转载)Nginx 负载均衡配置和策略

源地址:http://outofmemory.cn/code-snippet/3040/Nginx-load-junheng-configuration-strategy

 

Nginx 的 HttpUpstreamModule 提供对后端(backend)服务器的简单负载均衡。一个最简单的 upstream 写法如下:

upstream backend {
    server backend1.example.com;
    server backend2.example.com;
    server.backend3.example.com;
}

server {
    location /{
        proxy_pass http://backend;

    }
}

1、后端服务器

通过 upstream 可以设定后端服务器,指定的方式可以是 IP 地址与端口、域名、UNIX 套接字(socket)。其中如果域名可以被解析为多个地址,则这些地址都作为 backend。下面举例说明:

upstream backend {
    server blog.youkuaiyun.com/poechant;
    server 145.223.156.89:8090;
    server unix:/tmp/backend3;
}

第一个 backend 是用域名指定的。第二个 backend 是用 IP 和端口号指定的。第三个 backend 是用 UNIX 套接字指定的。

2、负载均衡策略

Nginx 提供轮询(round robin)、用户 IP 哈希(client IP)和指定权重 3 种方式。

默认情况下,Nginx 会为你提供轮询作为负载均衡策略。但是这并不一定能够让你满意。比如,某一时段内的一连串访问都是由同一个用户 Michael 发起的,那么第一次 Michael 的请求可能是 backend2,而下一次是 backend3,然后是 backend1、backend2、backend3…… 在大多数应用场景中,这样并不高效。当然,也正因如此,Nginx 为你提供了一个按照 Michael、Jason、David 等等这些乱七八糟的用户的 IP 来 hash 的方式,这样每个 client 的访问请求都会被甩给同一个后端服务器。具体的使用方式如下:

upstream backend {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
    server.backend3.example.com;
}

这种策略中,用于进行 hash 运算的 key,是 client 的 C 类 IP 地址(C 类 IP 地址就是范围在 192.0.0.0 到 223.255.255.255 之间,前三段号码表示子网,第四段号码为本地主机的 IP 地址类别)。这样的方式保证一个 client 每次请求都将到达同一个 backend。当然,如果所 hash 到的 backend 当前不可用,则请求会被转移到其他 backend。

再介绍一个和 ip_hash 配合使用的关键字:down。当某个一个 server 暂时性的宕机(down)时,你可以使用“down”来标示出来,并且这样被标示的 server 就不会接受请求去处理。具体如下:

upstream backend {
    server blog.youkuaiyun.com/poechant down;
    server 145.223.156.89:8090;
    server unix:/tmp/backend3;
}

还可以使用指定权重(weight)的方式,如下:

upstream backend {
    server backend1.example.com;
    server 123.321.123.321:456 weight=4;
}

默认情况下 weight 为 1,对于上面的例子,第一个 server 的权重取默认值 1,第二个是 4,所以相当于第一个 server 接收 20% 的请求,第二接收 80% 的。要注意的是 weight 与 ip_hash 是不能同时使用的,原因很简单,他们是不同且彼此冲突的策略。

3、重试策略

可以为每个 backend 指定最大的重试次数,和重试时间间隔。所使用的关键字是 max_fails 和 fail_timeout。如下所示:

upstream backend {
    server backend1.example.com weight=5;
    server 54.244.56.3:8081 max_fails=3 fail_timeout=30s;
}

在上例中,最大失败次数为 3,也就是最多进行 3 次尝试,且超时时间为 30秒。max_fails 的默认值为 1,fail_timeout 的默认值是 10s。传输失败的情形,由 proxy_next_upstream 或 fastcgi_next_upstream 指定。而且可以使用 proxy_connect_timeout 和 proxy_read_timeout 控制 upstream 响应时间。

有一种情况需要注意,就是 upstream 中只有一个 server 时,max_fails 和 fail_timeout 参数可能不会起作用。导致的问题就是 nginx 只会尝试一次 upstream 请求,如果失败这个请求就被抛弃了 : ( ……解决的方法,比较取巧,就是在 upstream 中将你这个可怜的唯一 server 多写几次,如下:

upstream backend {
    server backend.example.com max_fails fail_timeout=30s;
    server backend.example.com max_fails fail_timeout=30s;
    server backend.example.com max_fails fail_timeout=30s;
}

4、备机策略

从 Nginx 的 0.6.7 版本开始,可以使用“backup”关键字。当所有的非备机(non-backup)都宕机(down)或者繁忙(busy)的时候,就只使用由 backup 标注的备机。必须要注意的是,backup 不能和 ip_hash 关键字一起使用。举例如下:

upstream backend {
    server backend1.example.com;
    server backend2.example.com backup;
    server backend3.example.com;
}
<think>嗯,用户想了解主流J2EE应用服务器的配置方法性能调优技巧,特别是WebLogic、JBossTomcat。首先,我需要回忆一下这些应用服务器的基本区别各自的特性。根据引用内容,Tomcat主要支持ServletJSP,而JBossWebLogic是功能更全的应用服务器,支持EJB等J2EE特性。 接下来,配置方法方面,可能需要分每个服务器来说。比如Tomcat的配置通常涉及server.xmlweb.xml,调整线程池、连接器参数。而JBossWebLogic可能有更复杂的配置,比如子系统设置集群配置。调优的话,内存管理、线程池调整、缓存机制都是关键点。引用里提到JBossTomcat集成可以实现全部J2EE功能,这可能涉及到集群配置,如引用3中提到的群集技术对扩展性的重要性。 然后,性能调优需要考虑JVM参数,比如堆大小、垃圾回收策略。WebLogic可能有自己的调优工具,JBoss的子系统优化,比如EJB池大小。Tomcat作为轻量级服务器,可能需要优化连接器参数,比如maxThreadsacceptCount。另外,缓存策略也很重要,比如静态资源缓存会话复制。 用户可能还希望知道具体的最佳实践,比如如何监控服务器性能,使用哪些工具,或者常见的配置错误。需要确保每个服务器的调优方法分开说明,同时比较它们的异同。比如引用2提到Tomcat与JBoss集成,这可能是一个优化方案,而引用4的比较分析可能提供更多细节。 还要注意引用来源的可信度,比如引用4是转载的博客,可能需要谨慎处理。但其他引用如1、2、3看起来来自技术分析文章,比较可靠。最后,生成的相关问题要围绕配置、调优、监控比较,帮助用户深入理解。</think>### 主流 J2EE 应用服务器配置与调优实践 #### 一、WebLogic 配置与调优 1. **核心配置** - **内存分配**:通过修改 `setDomainEnv.sh`(Linux)或 `setDomainEnv.cmd`(Windows)调整 JVM 堆大小,例如: ```bash -Xms4096m -Xmx8192m -XX:MaxPermSize=2048m ``` - **线程池优化**:在管理控制台中调整“执行线程数”(默认 16),根据并发量设置 `MaxThreads` `MinThreads`,避免线程竞争[^3]。 - **数据源连接池**:配置 `Initial Capacity` `Max Capacity`,启用连接泄漏检测(`Test Connections on Reserve`)。 2. **性能调优** - **启用集群**:通过横向扩展提升负载能力,配置会话复制(如内存复制或数据库持久化)。 - **缓存优化**:启用 `WebLogic 二级缓存`,调整 `Cache Size` `Cache Timeout`。 - **垃圾回收策略**:使用 G1 或 CMS 垃圾收集器,减少 Full GC 频率。 --- #### 二、JBoss 配置与调优 1. **核心配置** - **子系统优化**:在 `standalone.xml` 中调整 `web` 子系统的 `max-connections` `worker线程池`。 - **内存管理**:修改 `standalone.conf` 设置堆内存,例如: ```bash -Xmx4g -XX:MetaspaceSize=256m ``` - **EJB 池配置**:调整 `ejb3` 子系统的 `max-pool-size`,避免资源耗尽。 2. **性能调优** - **分布式缓存**:集成 Infinispan 缓存,配置分布式会话存储[^1]。 - **JVM 参数优化**:启用压缩指针(`-XX:+UseCompressedOops`)分层编译(`-XX:+TieredCompilation`)。 - **日志优化**:关闭 DEBUG 日志级别,减少 I/O 开销。 --- #### 三、Tomcat 配置与调优 1. **核心配置** - **连接器优化**:在 `server.xml` 中调整 `Connector` 参数: ```xml <Connector port="8080" maxThreads="200" acceptCount="100" /> ``` - **内存设置**:修改 `catalina.sh` 设置堆内存: ```bash -Xms512m -Xmx2048m ``` - **会话持久化**:配置 `Manager` 组件实现会话存储(如 Redis)。 2. **性能调优** - **静态资源缓存**:启用 `DefaultServlet` 的 `cacheMaxSize` `cacheTTL`。 - **NIO 模式**:使用 `org.apache.coyote.http11.Http11NioProtocol` 提升并发处理能力[^2]。 - **关闭自动重载**:设置 `reloadable="false"` 避免类重复加载。 --- #### 四、通用优化原则 1. **监控工具**:使用 VisualVM、JConsole 或 Prometheus + Grafana 监控 JVM 状态。 2. **压测验证**:通过 JMeter 或 Gatling 模拟高并发场景,定位瓶颈。 3. **集群部署**:结合负载均衡(如 Nginx)实现横向扩展[^4]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值