连接数

前言 像我这样的菜鸟，总会有各种疑问，刚开始是对 JDK API 的疑问，对 NIO 的疑问，对 JVM 的疑问，当工作几年后，对服务的可用性，可扩展性也有了新的疑问，什么疑问呢？其实是老生常谈的话题：服务的扩容问题。 正常情况下的服务演化之路 让我们从最初开始。 单体应用 每个创业公司基本都是从类似 SSM 和 SSH 这种架构起来的，没什么好讲的，基本每个程序员都经历过。 RPC 应用 当业务越来越大，我们需要对服务进行水平扩容，扩容很简单，只要保证服务是无状态的就可以了，如下图： 当业务又越来越大，我们的服务关系错综复杂，同时，有很多服务访问都是不需要连接 DB 的，只需要连接缓存即可，那么就可以做成分离的，减少 DB 宝贵的连接。如下图： 我相信大部分公司都是在这个阶段。Dubbo 就是为了解决这个问题而生的。 如果你的公司产品很受欢迎，业务继续高速发展，数据越来越多，SQL 操作越来越慢，那么数据库就会成为瓶颈，那么你肯定会想到分库分表，不论通过 ID hash 或者 range 的方式都可以。如下图： 这下应该没问题了吧。任凭你用户再多，并发再高，我只要无限扩容数据库，无限扩容应用，就可以了。 这也是本文的标题，分库分表就能解决无限扩容吗？ 实际上，像上面的架构，并不能解决。 其实，这个问题和 RPC 的问题有点类似：数据库连接过多！！！ 通常，我们的 RPC

#运行用户 #user nobody; #启动进程，通常设置成和cpu的数量相等或者2倍于cpu的个数(具体结合cpu和内存)。默认为1 worker_processes 1; #全局的错误日志和日志级别[ debug | info | notice | warn | error | crit ] #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; #pid进程文件 #pid logs/nginx.pid; #一个nginx进程打开的最多文件描述符数目，理论值应该是最多打开文件数（系统的值ulimit -n） #与nginx进程数相除，但是nginx分配请求并不均匀，所以建议与ulimit -n的值保持一致。 #默认不需设置 #worker_rlimit_nofile 65535; #工作模式以及连接数上限 events { #epoll是多路复用IO(I/O Multiplexing)中的一种方式， #仅用于linux2.6以上内核，可以大大的提高nginx的性能 #参考事件模型，use [ kqueue | rtsig | epoll | /dev/poll | select | poll ]; #在FreeBSD上面，就用kqueue模型

1、查看apache当前并发访问数： #对比httpd.conf中MaxClients的数字差距多少。 netstat -an | grep ESTABLISHED | wc -l 2、查看httpd进程数（即prefork模式下Apache能够处理的并发请求数）： ps aux|grep httpd|wc -l 3、可以使用如下参数查看数据 ps -ef|grep httpd|wc -l #1388 #统计httpd进程数，连个请求会启动一个进程，使用于Apache服务器。 #表示Apache能够处理1388个并发请求，这个值Apache可根据负载情况自动调整。 netstat -nat|grep -i "80"|wc -l #4341 #netstat -an会打印系统当前网络链接状态，而grep -i "80"是用来提取与80端口有关的连接的，wc -l进行连接数统计。 #最终返回的数字就是当前所有80端口的请求总数。 netstat -na|grep ESTABLISHED|wc -l #376 #netstat -an会打印系统当前网络链接状态，而grep ESTABLISHED 提取出已建立连接的信息。 然后wc -l统计。 #最终返回的数字就是当前所有80端口的已建立连接的总数。 netstat -nat||grep ESTABLISHED|wc