1、这个题目问得不那么准确，你必须要精准计算出每秒查询时间（QPS）和事务时间（TPS），好比你感冒了，你说要配什么药，医生只能凭经验，你如果去抽象化验，知道是病毒还是细菌感染，数量是多少后，才能进一步诊断和配置服务器硬件。
2、接下来，你要了解常用发中间件和数据库的极限并发量。比如redis一般是11w左右（纯粹内存读写）、mysql每秒写8w左右，读10来万（单表，多表就不一定，得看SQL的写法），一般单表的存储极限是5千万左右，如果超出范围，那么配置再好也是慢。总的说来，要精确配置服务器，你需要尽可能地评估最复杂的业务每秒并发时间，同时要考虑最复杂的情况，比如数据库的数据规模、代码在最高并发下，所耗费的时间，同时对网络I/O也要有一个预估，知道带宽的大小，总之，需要具体问题具体分析。
3、如果以上情况不考虑，就是想知道一个简单粗暴的大概结果，一般8核、16G、256SSD，同时跑DB和web服务器的话，足够支持1w的并发量，而且还有很大的冗余。如果火力全开，满血跑，大概跑个8-10w都是有可能的。边压测，边优化，如果恰好旁边有高手，榨干每一个环节，你的并发量超出你的想象……
评论0
加载中...
场景很重要，比如一万并发的qps还是tps，这完全不同的概念。
服务器做做优化，现在通过epoll支撑百万连接十万并发没什么瓶颈。但是，这只是网络层，如果落到具体业务，那就另当别论了。比如redis可以几十万并发，因为只需要网络io和访问内存。但是如果有业务处理，挂上了数据库，走了kafka，并且再走redis，那就要具体问题具体分析了。
数据库单存qps，我们原来基准测试结果是可以支撑六万到八万左右，但是有事务的增删改绝对不是这个量级。
其实你需要的是一个基准测试的结果，例如tcp，http基准测试；tomcat基准测试；应用框架基准测试；redis基准测试；mysql基准测试等。
我们做过应用框架基准测试，基于springboot，测试接口没什么逻辑，就是直接查询sql并返回结果。基准测试结果是八核16G内存，跑两个实例，可以撑到8万并发左右，应该还有优化空间吧。
评论0
加载中...
首先你要知道, 1w并发是什么. 1w就是QPS, 1w请求/秒. 所以不是只是和系统配置(容量)相关, 如果要达到, 反而更应该和时间相关.
举个例子, 假设平均你的服务处理时间(RT)是1秒, 那么在这一秒钟内, 意味着有1w个线程同时执行. 而实际即使是8核单机, 也是压不上去的.
为什么? 因为你的服务太慢了, RT太长了. 那么把你的服务处理时间优化缩减到0.1秒, 即100ms, 那么达到1w并发(QPS=1w/秒), 同时只需1k个线程在并发执行就达到了.
以个人经验.对于Java来说, 1K大小的线程池不是什么大问题. 为了避免占GC时间过长, 配置500左右大小的线程池, 启动2个JVM实例就可以达到.
而以1秒RT为基础的1w线程池大小, 以个人经验, 在单机基本上压不到的.
所以, 答案就是, 你应该先关注RT, 缩小到平均100ms的经验值, 1w并发不是问题.
评论0
加载中...
可以了解一下serverless。函数计算就是其中的代表实现了免运维，自动伸缩。也就是说你只用专注业务 无需管理服务器配置管理 不管多大并发 都能抗住，无需担心服务器宕机，等一系列运维问题。你只需在适当的时候升级数据库即可。在解决业务问题之前没必要解决技术问题。之前也和你一样，开发之前总是担心服务器性能不够怎么办，虽然大部分情况下用户可能没有那么多，并发根本没有想象中的大。但是等到一些列问题出现的时候再去找解决方案，就会很被动，不管是对公司还是个人造成很大压力。所以建议了解serverless 函数计算完美解决了这一问题。最后安利一下ucloud云的函数计算，技术成熟，支持语言多，迁移项目方便。
评论0
加载中...
您好，光网络可能就不支持1w的并发了。
你说的这个配置是基础配置，一来就是1w的高并发支持不了的。
由于各个功能模块各个层次消耗不一样，所以要具体看后期运营使用情况再来调整服务器配置。
评论0
加载中...
要看性能要求了，如果只讨论并发数量，用异步网络模型，并发一万个链接没啥问题吧，只是数据处理不过来，大多数链接都是在等待结果而已。服务器配置1核8g差不多够了吧
评论0
加载中...
1m带宽，1万qps基本没可能，就算平均包长128字节好了，撑死1000pps，假设一次交互完成，那顶了天500tps。那你这环境只可能是1万活跃session了，应该随便搞台pc机都能顶住
评论0
加载中...0
回答0
回答5
回答5
回答9
回答0
回答10
回答0
回答0
回答0
回答
