1秒1000并发，高并发需要什么样的服务器？

硬件层面需要根据数据量，业务复杂度一起综合评估的，建议先买两台云主机（4核8g内存）搭建集群环境就行。后继再根据实际需要扩展。软件层面：

一、如果是写入操作的，应该：1.1使用消息队列来异步处理（如activemq等），避免消息堵塞1.2使用MongoDB的批量写入功能，比如每条数据才写入一次

二、MongoDB部署为集群模式，可以分散压力

三、如果是读取操作，可以考虑加入redis，将热点数据进行一级缓存

一、服务器配置优化首先我们知道几个概念：MongoDB是NoSQL面向文档型存储数据库，属于重内存的类型，特别是在MongoDB3.2默认的WiredTiger引擎下，默认会占用大量的内存来保证自身性能。因此MongoDB所需要的服务器，以题主使用的云主机为例，选型思路主要是重存储型云主机，为了保证Mongo集群的读写性能，需要以SSD云盘前提下尽可能大内存的主机，同时vCPU也不能太低会影响压缩存储效率。如果技术储备不够，在参数调优、版本升级、数据迁移中有问题怕踩坑，可以采用一些成熟的云服务提供商的基于容器的云原生MongoOperator产品，这样可以少踩许多坑。参考网易轻舟这类商业化中间件

二、软件层优化简单介绍下我在MongoDB优化中的思路：MongoDB主要包括mongod和mongo两个进程。mongod是处理MongoDB系统的主要进程。它处理数据请求，管理数据存储，和执行后台管理操作。当我们运行mongod命令意味着正在启动MongoDB进程，并且在后台运行。mongo则是一个命令行工具用于连接一个特定的mongod实例。当我们没有带参数运行mongo命令它将使用默认的端口号和localhost连接

1、参数调优操作系统OS层面连接数优化要提供高并发的响应能力，首先要考虑提升MongoDB本身的服务能力，mongod进程的连接数主要是受到操作系统的默认文件描述符和进程/线程数限制。以centos为例，需要通过ulimit-a查看openfiles是否够大，如果太小可以通过以下命令设置用户/进程允许打开的文件句柄数。ulimit-nulimit-u参考资料：点————看

脱离实际业务谈高并发都是纸上谈兵，不切实际！尽管我们聊到高并发时候一定要结合实际业务场景去设计、去优化，但是高并发的设计是有方法论的。首先我们要区分当前的业务是读多写少还是写多读少的场景。读多写少如果是读多写少的业务场景，其实qps是不高的，更不需要什么高端的服务器，我18年负责的一个业务，典型的读多写少，高峰期并发达到QPS，也只是用了4台2C4G的云服务器 16G的Redis集群就扛住了，不需要做额外的开发，一个旁路缓存策略就搞定。仅是Redis单机模式就能达到理论的10万QPS，所以并发算啥？旁路缓存原理合理的运用缓存提高程序的访问性能只是特定场景下的一种手段，实际上针对读多写少是有很多手段的，很多时候在网络这块就可以解决掉大部分的流量，比如CDN技术、4层负载、7层负载。读少写多上面我说了读多写少的场景，这种场景相对比较简单，与之相对应的就是读少写多的场景了，这种场景因为要大量的写数据，大部分的业务场景数据最终都会写入数据库或者文件，这时候流量无法前置处理，数据所在服务器最终成为压力的一方，因此在高并发情况下，为了保证高可用（数据不丢失、不脏读、不错误），还是有一定的挑战的。常见的一种手段就是利用队列排队写入，削峰填谷以均衡服务器的压力。这是在放弃一定的并发性能来获取高可用的折衷手段。这个时候一定要结合具体的业务场景来做设计，并发量级有多大，哪些地方可以牺牲部分的性能，哪些地方可以牺牲一定的高可用，哪些地方可以不用强一致性，只要最终一致性即可等等。一个经典的场景是采用kafka来应对高并发的数据写入，kafka可以采用分区的技术多台机器消费生产者的消息。kafka最后尽管并发不算高，但是在实际开发中我们还是要小心面对这种具有“一定量级”的业务，在保证服务正常运行的前提下，还要注意并发读写带来的一系列问题，例如幂等性保证、数据的一致性保证等等。我是“Java架构设计”，欢迎关注，持续为您分享优质技术内容。

首先思路不能完全固化在服务器硬件上提升，你可以从软件上，比如数据库缓存技术，然后到服务器层面上你可以使用负载均衡技术，总之一个原则把你的并发请求拦截到上层然后去想办法解决！

1秒的并发不是太高，只要简单优化一下就行了，现在一般的服务器应该都能够支撑。首先看看线程池分配，看看linux系统的io数限制。当然不建议让数据库去抗频繁的高并发，应该在整体架构上面作优化，在数据库上层是不是可以考虑架构缓存服务器，还有针对具体业务做些优化。