10万并发的配置
因业务需求类似抢购，我们需要搭建一个并发在10万左右的集群，初步方案如下。
最前面SLB，后面10台ECS(8C16G)，加上1个高配的RDS+几台只读RDS，
再加两个高配的ocs做cache。静态文件全部走cdn,ecs上配置的nginx+php-fpm。
大家看看这样的配置够不够，业务比较简单，手机页面。
展开
收起
34
条回答
写回答
写回答
-
-
-
Re10万并发的配置10万并发我觉得先从软件下手吧。
把各种请求分层。
静态请求CDN就能搞定。
动态部分可以把不同应用分类。然后架集群，分散需求。
不是你想的堆设备就能搞定的。
10万并发真正成功抢购的估计也就几千不到吧。
向楼上说的排队的方法就很好。过滤掉水分让那几千用户到后面环节。2015-02-27 22:54:08赞同 展开评论 打赏 -
Re10万并发的配置抢购本身就很麻烦,毕竟峰值时候要死,平常浪费得要命.
如果是类似小米一段时间抢购一次,可以用esc
部分ecs采用按量计费,做好自定义web镜像.需要的时候马上开,不需要的时候就删除.
如果每天或者没段时间就来一下抢购,估计麻烦了.
10w并发,10台esc 很充裕.2015-02-27 10:55:06赞同 展开评论 打赏 -
Re回12楼大韵科技的帖子那按你这么说的话，就算论坛，如果有keep-alive，长时持久连接的需求，这点服务器也不够10万流量塞牙缝的啊。
-------------------------
ReRe10万并发的配置10万并发得先看是读并发多还是写并发多，对于读并发，10万不算太大难度，增加多层次的缓存结构即可，特别是时效不敏感的数据，100万 1000万的并发都不是难事。
而对于10万级别的写并发，比如商品秒杀这种需求，如果你有10套服务器架构，可以预先将10万的秒杀商品随机平均分配到10套架构，每套架构只承担其中的1万商品秒杀，这样并发数一下子就分布了，性能就提高了。再大的量也基本上是这种原理。2015-02-19 12:57:26赞同 展开评论 打赏 -
Re10万并发的配置10万并发的服务本身就不合理。
一定要分流才能实现，单纯依靠增加服务器 配置或者SLB是不行的。
1、将不同区域的用户分到不同的服务器。
2、要从程序本身下手，根据业务需求将并发的细分到不同的服务器。
3、这么高的并发IO一定是瓶颈，所以服务器程序不能用一般服务器的程序了，可能要自己C++写服务器程序。
以抢购为例，一定是写在内存里的，所以用RDS是不合理的，即是是只读RDS也是不合理的，数据库写在内存里然后在内存里操作。当内存操作结束之后再将结果异步的写入RDS。
10万并发也要看在1秒钟并发还是在1分钟内并发。如果简单的可以考虑用Apache这类程序，复杂的还是自己用C++写服务器程序吧。毕竟Apache这类处理并发并不是强项。
另外10万并发的需求通常都含有一定的水分，通过过滤这些水分请求，有些不合理的请求就直接过滤掉，也就不会有这么多并发。
通过改进程序，建立取号排队机制，将看似10万并发，我们不直接读取这10万信息，我们只是先生成几个预先定义的号码，只让这些号码的用户进入窗口排队，这样10万并发一下子就压缩成几十个或者几百个并发。就像抽奖，不是把所有的用户信息都扔进抽奖滚筒里，而是经过计算而得到结果，然后寻找匹配的结果。通过程序的改进，解决问题。
我能想到的10万并发的唯一需求就是一个10万人同时在线的聊天室。可是如果有这样的程序存在，就算服务器吃得消，客户端也吃不消的。
通过优化程序，别说是10万人的并发，就算是100万人的并发，一台服务器也可以搞定。
-------------------------
Re10万并发的配置顺便提一下，像抢购什么的我从来不信。因为这里面的技术水分太大了，谁能绕过服务器的防御机制，谁就能抢到。像我这样善良的美男子，从来都抢不到~2015-02-15 21:25:59赞同 展开评论 打赏 -
-
Re10万并发的配置先明确你的业务场景，做个分析，比如平均每天多少，大型活动的时候，瞬时并发多少等等。。先明确。。2015-02-11 09:58:02赞同 展开评论 打赏
-
-
-
-
-
-
-
-
-
-
-
-
滑动查看更多
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
相关问答
问答排行榜
最热
最新
推荐问答
