并发是指一秒数据库收到的4K数据个数。需要什么样的硬件和带宽才能稳定达到1秒1000以上？
观点1
首先，服务器硬件条件要达到要求。网卡带宽是否够；是否有写磁盘，若有，读写速度是否超过磁盘IO带宽；是否有耗时计算，CPU是否会称为瓶颈。 其次，硬件都满足的情况下。你需要使你的软件系统充分利用硬件性能。这个时候就需要合理设计方案，实现。 然后，再你达到了预定的并发量后。再想想能否优化，在更少的资源下完成同样的事情，或者现有资源下完成更多的事情。最后，还有一个重中之重就是，是否易运维，易扩展。这个是很值得你投入精力去做的。
观点2
首先1秒1000并发并不高，题主没说几个关键点：数据量多大，单台机器还是分布式。
如果是分布式有架构的话应该也不会问这种问题。如果是单台机器没有架构 直接裸奔的话最简单做法就是分表分库分机器加缓存。
另外不要用云主机，目前的云主机io性能都不好，还是直接自己弄服务器靠谱
如果数据量小的话就全部加载到内存中。重点是要知道性能瓶颈在哪。
观点3
一般的提法是1000并发，指同时在线数，即1000个客户和服务器保持着连接。可能一整天都能保持这个状态，因此不带上具体多久。
从题主前后文看，题主其实想指的是qps，即每秒的请求数。
如果每秒1K个请求，每个请求都是写入操作，数据大小是4K，那么这是典型的数据库应用。每秒需要写入的数据量是1K*4K=4M。单机下普通配置的mongodb可以应付这样的压力。可否找一下那些地方成为瓶颈了。看看磁盘忙不忙，mongo的CPU高不高。
观点4
如果只是读请求就简单多了，MongoDB RS架构完全够用。我们目前的业务场景，业务用MongoDB只读，每分钟几百万的请求完全跟服务器数量是线形增长的。
至于写的话，假设你们很有钱，就买SSD吧，简单粗暴。
通用的做法是：缓存+数据库(redis+mongodb)，自己实现缓存中的任务队列并用某个固定服务flush/merge这些队列。这个队列就复杂到业务逻辑了，缓存是永远避免不了的。
此外，可以从业务逻辑方面考虑优化。（是的，我又一次提到了业务逻辑）或许你们可以将业务分离，解藕数据之间的关联。
我们学到的一个教训是分离数据库，提高单台服务器的处理能力。
