这个太抽象了，没法回答，没人能预计你的应用如何才能撑起这个量，稍微有些细节的地方做得不好都会有一些问题的。

简单说来就是让你的应用可以很好的水平扩展，同时保证资源的合理利用，访问请求搞的页面足够的快速

我这边现在有个 Rails 项目，用户千万用户是没有，但是几百万是有的，每日 PV 最高的时候有几百万，还不算 API 的，API 算起来估计有千万/day 的级别了。

如果 1000 万用户数量还不能靠盈利请牛人加设备，快让你们的 Marketing 部门集体辞职吧

#3 楼 @nouse 对的，我看到这个问题，我首先想到的也是要钱，要人，要设备，呵呵。

根据以往做 SA 的经验，答案就是分布式，大量的机器去顶。

@jean 把@huacnlee @lgn21st 两位大大挖去就不成问题了 XD

抛开钱的问题不谈，如果需要技术方案，首先要明确目前的瓶颈。单机 500 个并发对 web server 是小 case，困难在于业务，是计算密集还是 io 密集？存储压力是在缓存上还是在数据库上？读写比例怎么样？数据是否可以简单的用分片方式来做？基本上调查工作做好以后解决方案也就很清楚了

#3 楼 @nouse 额，在理呀，我想，千万级数据上去了，一般都会对从数据库设备那边开始改造吧

#1 楼 @huacnlee 说实话，我没做过那种大点个开发，这次是有个项目，很无语的是，3 个月通过行政手段收集 600w 的用户数据，但我保守估计，能有 10~20w 人再次出现在网上都客观了， 所以这方面就是数据基数大，读取不频繁..

#4 楼 @lgn21st 职能部分里，不是没有钱，而是要磨死你，压榨你，还要少给钱...

#8 楼 @voodeng 数据库直接上 fusion-io，提升应该很明显，或者别的基于 PCI-E + SSD 的技术

硬件发展才是王道。

#7 楼 @fsword 提出的几个问题很实在，得先找到瓶颈在哪，再做下一步规划

如果不是 12306 那样的项目，1000 万的用户肯定不会突然出现的，你现在可以忘记这些数字，直接上路。在用户量增长的过程中，你会找到每一步的最佳方案。

#9 楼 @voodeng 多做静态化，多做缓存，少读数据库，大不了像 12306 做一个在线人数限制。 另外领导能让一个做前端的人做这件事，很可能是应付了事。