1000个用户并发的网站服务器大概需要什么样的配置？

一般的提法是1000并发，指同时在线数，即1000个客户和服务器保持着连接。可能一整天都能保持这个状态，因此不带上具体多久。

如果每秒1K个请求，每个请求都是写入 *** 作，数据大小是4K，那么这是典型的数据库应用。每秒需要写入的数据量是1K4K=4M。单机下普通配置的mongodb可以应付这样的压力。可否找一下那些地方成为瓶颈了。看看磁盘忙不忙，mongo的CPU高不高。

20000的并发量需要150台服务器。

150台。Tomcat 默认配置的最大请求数是 150，也就是说同时支持 150 个并发，当然了，也可以将其改大。

如果是较大规模或者是，视频内容较多的网站，则会对服务器资源占用较高，推荐用双至强八核处理器，32G内存，1T硬盘的配置来放数据库，然后再用几台普通四核配置的机器放网站前端来做负载均衡即可，带宽需要根据你们的具体需求来决定。

易使用性：

服务器的功能相对于PC机来说复杂许多，不仅指其硬件配置，更多的是指其软件系统配置。服务器要实现如此多的功能，没有全面的软件支持是无法想象的。但是软件系统一多，又可能造成服务器的使用性能下降，管理人员无法有效 *** 纵。

所以许多服务器厂商在进行服务器的设计时，除了在服务器的可用性、稳定性等方面要充分考虑外，还必须在服务器的易使用性方面下足功夫。

服务器的易使用性主要体现在服务器是不是容易 *** 作，用户导航系统是不是完善，机箱设计是不是人性化，有没有关键恢复功能，是否有 *** 作系统备份，以及有没有足够的培训支持等方面。

蟹妖~~关注极迭代，和小伙伴一起看___4核8G+10M带宽属于比较好的机器了，能够满足大部分场景的需要。但要说能支持多少用户，就不能这样拍脑袋得到答案。用户支撑数量是由很多因素构成的，比如用的语言、架构、处理的业务类型、数据大小等等，这是一个不断调优的过程。

首先需要确定业务类型

不同的业务会有不同的特点，有些CPU占用比较高，比如内存计算类的；有些内存占用高，比如数据处理类的；有些需要大带宽，比如网络爬虫类的；有些磁盘占用高，比如和数据库类的。同样配置的机器跑不同的业务，效果就会天差地别，而且未用到的资源就大大的浪费了。根据自己的业务类型，调整机器的资源配比，是节省资金，提高支撑能力的好办法。

其次确定数据尺寸

网络传输的数据尺寸决定了带宽的占用程度，尺寸越小带宽越大，单位时间能够接入和处理的用户请求就更多。那么减少无效的数据传输，减少请求包的大小，是提高用户接入能力必须考虑的地方。

采用合理的语言架构

经过良好设计的系统，和随意堆砌的系统，接入能力是完全不同的。为了解决资源浪费问题，可以采用Docker之类的容器化，微服务化，能够有效的提高资源使用率，减少服务器压力。采用Nginx或Tengine、开启NIO、开启压缩、以及设置静态和局部缓存等，降低服务器负载采用MongoDB、NoSQL数据库，降低数据查询压力提高响应速度总之一句话：尽力减少前端无效请求，后端尽力将请求在靠近用户侧解决掉，避免业务过长，堆积在后端底层。

不断测算和调优

支撑的TPS数，是需要不断监控不断调优的。很多时候，一个微小的参数调整，都能带来成倍的性能提高。一个数十秒的业务请求，也许调优后就能在几十毫秒完成。真正的线上服务，持续监控和持续调优是长期进行的。

做网站的话，服务器要分前端和后端的，还有cache、负载平衡、网络带宽和存储系统等问题要考虑，不是单讲一台服务器就能说清楚的。
只讨论一台服务器的话，3650双路加4G内存支持到5万并发是容易达到的，即使针对业务流比较复杂的情况，也能满足很大程度的需要。
但是考虑到存储子系统，比如4块sas硬盘raid0，可能只能达到5000数量级的并发请求。如果是以另外的光纤盘阵来支持存储则可以显著提高硬盘传输带宽的性能。
最后还要考虑到你的网络带宽，对大多数网站来说，通常这才是最大的瓶颈所在。也就是说即使你的cpu、内存、硬盘都没问题，也会因为租用的网络带宽限制而影响最大的并发数。
还有一点，经过优化的网站程序对结果也有很大影响。事实上很多网站的访问体验很糟糕，其实不是因为硬件的原因，而是程序写的太烂。
很抱歉我本想以单台服务器来讲，但是说着说着又变成讲网站架构了。不如举个例子吧，如果你在这台服务器上运行discuz或动网之类的服务，在没有特别高峰的情况下，5万并发是没有问题的。

场景很重要，比如一万并发的qps还是tps，这完全不同的概念。

服务器做做优化，现在通过epoll支撑百万连接十万并发没什么瓶颈。但是，这只是网络层，如果落到具体业务，那就另当别论了。比如redis可以十万并发，因为只需要网络io和访问内存。但是如果有业务处理，挂上了数据库，走了kafka，并且再走redis，那就要具体问题具体分析了。

数据库单存qps，我们原来基准测试结果是可以支撑六万到八万左右，但是有事务的增删改绝对不是这个量级。

其实你需要的是一个基准测试的结果，例如tcp，>这个应该没有办法去做测试理论上来讲,一个高配置的至强处理器能支持的最大并发连接数是一两万个但在实际使用中服务器所能支持的并发数也与你的应用有关比如你服务器上面做网站做下载放OA系统等不同的应用也会支持不同的连接数
我的服务器用的是小鸟云的，性能稳定，访问很流畅。

本文先提供一个没有采用的方式--采用事务加select for update的形式

这么做呢就有个非常严重的问题,--- 同一时刻只有一个有效服务
如果A系统拿到了数据,开始了事务但是没提交,那么B系统同样的条件也会查到同一批还没处理好提交的数据,此时B系统该查询线程就会阻塞等待A提交事务这么看问题就来了,这里虽然保障了同一时刻只有一个服务可以拿到并处理一批数据,但是也导致了效率特别低,而且后面 无论扩展多少服务应用都没啥用

步骤解释:

我这里只写了大致的方案,一些redis高可用以及数据幂等性自己考虑去

这种方式是 我觉得最好的方案 了,完全保障了每个服务每次 处理 mysql的数据都是 互不相同的数据 ,完全 避免了竞争 问题

但是我们目前没有用这种方案,原因是目前我们redis内存只申请到一个比较小的内存,而 zset采用的跳跃表结构虽然保障了数据查询非常快速,但是也非常占用内存 ,预估了一下按照我们的数据量起码要存储300万数据,用到的内存量是 3~4G 之间,好家伙直接把我们所有内存都用了,其他服务还用个屁而且这玩意为了保障数据安全,不进行数据淘汰起码还要留个1G空闲安全空间那肯定就用不了了

如果你们的服务 数据量够小 或者 内存够大 ,redis又做到了 高可用,高可靠 ,那么我还是 十分推荐 用这种方案,毕竟很多服务都是 性能为王!

---