每秒1000条数据处理，每条记录处理需要10秒钟，请问需要部署伺服器？
有一个原有系统，每秒钟生成1000条订单记录；
现在需要开发一个新系统，需要将每条记录取出并推送给其它系统；系统使用http请求将记录通知给其他系统（注意：一条记录，需要按顺序发送3次http请求，每个请求处理需要3秒钟，按顺序执行，则该方法共需要9秒钟才能执行结束）；
请问？
问题一: 如此高的数据量， 一台4核的cpu伺服器，通常最大开启多少个线程用于http发送？问题二: 按上面的数据，可以开启多线程发送请求，那么一台机器每秒可以处理多少条记录？问题三: 部署多少台伺服器，可以应对每秒新增1000条记录的需求； 应该按什么思路计算？
问题四：如果是4核CPU，那么开100个线程和开5个线程的执行效果是不是一样，线程多了反而会造成频繁切换线程问题，反而更慢，对不？
如果没介绍清楚，请看图片！！
一个函数进行3次同步请求……每次请求等3秒。这个问题好大。
你想啊，你的负责分发请求的伺服器不做具体工作，就只是干等在那。真正解决任务的伺服器还是一样该算多少算多少。你的分发请求伺服器的意义在哪里？
本来是我忙三秒；现在我忙三秒，你等我三秒。人越多等待的人就越多。
你先别问那些复杂的问题，首先把任务派发做成非同步的，请求之后就去忙别的，之后再处理回应，才能迈出正确的第一步……
你把http的io处理模式从同步 阻塞换成非同步非阻塞方式应该可以搞定
补充回答一下
针对后段的业务系统如果是CPU密集型的，支持超线程技术的4核可以开8到16个线程，具体看有没有CPU空闲
如果是io密集型，换成非同步io非阻塞模式，线程数量可以开到50+，如果是java的，换成jvm自己管理线程可以开更高，如果是交由系统切换线程，linux下总进程+线程数量小于200可以忽略进程线程切换开销
问题1、每台机器所能支持的线程数需要根据具体的业务情况来进行实际测试，使用4核8G的伺服器做过测试，大约线程数1000时效果比较好，线程数达到1w时，伺服器出现无法响应的情况。具体的最优线程数，业务不同可能相差比较大，最好实际测试一下
问题2、每秒1000个订单，单个机器假设开启1000个线程，每个线程每次同步处理1个订单的3个请求，处理完毕需要10秒，则单个机器所能处理的订单速度为100/秒。
问题3、按照上面的逻辑，需要10台机器
问题4、线程过多确实会导致性能降低，但100个线程并不多，具体取多少线程数可以采用加倍折半测试的方式。先启动100线程，再启动200个看性能是提升或下降。若200线程性能提升了，那下次测试400个线程的性能，若200线程时性能反而下降了，那下次测试150线程的性能。依次测试，直到获取最优的线程数
我觉得问题应该是在于你的处理模式就有问题。对于这种操作，订阅发布或者任务队列模式可能会更适合一些。
你目前的设计完全没考虑到一条http请求失败怎么办，这么高的请求你的请求服务端受不受的了。你的http请求越高频，你的服务端越可能处理不了。
简单一点就用redis来实现，这样实现非同步处理会大量减少你伺服器的负荷。复杂一点像kafka这种。
先别管几个核的CPU，就按单核CPU处理的情况来分析。
首先，平均处理一个订单的平均时间周期（从请求到处理完，处理时延）是多少？要明确地表达出来。」每条记录处理需要10秒钟「，这是什么意思？是一个订单的整个处理时间周期，还是CPU处理时间？
其次，在一个订单的平均处理时间周期（处理时延）由几部分组成？假设是连续的不间断的依次的逐条处理。把操作系统的单道批处理拿出来看看。再把资料库的存储引擎和数据表的优化部分拿出来推一下，看看I/O次数能优化多少。
我们就不说什么请求到达率了。假设请求已经堆起来了，burst。
第三，线程的切换，你是指用户程序还是指内核？如果是用户程序，那么开销存在哪个地方？对於单核CPU来说，线程切换开销怎么评估。对于多核CPU来说，对于不同的操作系统来说，线程切换开销和用户程序又有所不同。
如果自己还搞不定，建议看论文，或者花钱。
你的系统瓶颈在http请求那里处理一条花9秒，堆开多少核开多少线程都救不了你。
要不真试试9000个并发。。。。你确定http的服务端受得了？
需要多少个线程才可以实现这个同时同步，计算并不困难，每秒1000，每条记录需要处理10秒，1000*10=10000个线程。
同时10000个线程在执行即可以实现对应你每秒产的订单数量
如何配置伺服器内存？
每个线程大概占2M的大小，10000*2=20000M，你大概需要购买24-32G内存的伺服器
如何配置CPU？
这个实话实说，不好计算你得自己去摸索，根据内存的大小你应该选配24-32G的内存服力器，可以尝试先选择16U的伺服器，如果在本地压力测试显示CPU指数过高，再进行升级即可。
那么开100个线程和开5个线程的执行效果是不是一样，线程多了反而会造成频繁切换线程问题，反而更慢，对不？
理论是这样的，但是这个数量级几乎可以忽略不计算，因操作系统本身就有几百个线程进执行，一台高性能WEB网站，假设是4U的每秒可以承受上千的并发是可以的，也就意味同时会有上千个线程。
线程过多的确会引起CPU的上下文切换，进行资源浪费，但是本身操作系统就是多道批的，是按时间分片进行线程切换的，也就是说CPU本身就是需要不断的切换线程，过多的线程只是增多的CPU的轮询的消耗。
并不需要提心性能的，因为即使16U，32G的内存也不过是1.8万/年的费用，比不上一个高级码农一个月的工资。推荐阅读：
