http://www.zhihu.com/search?q=%E9%AB%98%E5%B9%B6%E5%8F%91&type=question
http://storage.it168.com/a2012/0217/1313/000001313424_5.shtml
redis,nginx/Tengine,keeplive,DRBD,heartbeat这些小工具还是可以在虚拟机上面多开几台跑起来的.至于大业务场景,除了进大公司没有别的办法,因为有些工具运行的配置要求太高,必须多台服务器配合才能完成.
如果有精力,业内很喜欢用perl,python,C来写一些针对热点业务的负载脚本.这需要有http协议等网络封包的理论基础.
一些建议处理高并发要学习的东西实在太多.要在没有实际工作经验的情况下逐一了解太难,也很难深入.对于高并发的学习,我建议除了多阅读高并发架构的文档学习基本的方法论以外,自己要去深入学习网络基础,数据结构和算法.这些都是处理高并发热点的理论基础.
-----------------------------------------------------------------------------------------------------------------------
进程和线程模型，非阻塞IO，epoll/iocp这些不提，横向扩展和读写分离，
hot standby这些老生常谈的也不算，memcached/redis缓存也不算，
也不扯nodejs，twisted，gevent，tornado，erlang等等有助于高并发的工具，
这些都不算，有哪些秘密? 感觉做过高并发的都看不起同行了，到底有啥绝活?
SEDA or Actor这类的设计的东西？
-----------------------------------------------------------------------------------------------------------------------
业务数据库 -》 数据水平分割(分区分表分库)、读写分离
业务应用 -》 逻辑代码优化(算法优化)、公共数据缓存
应用服务器 -》 反向静态代理、配置优化、负载均衡(apache分发，多tomcat实例)
系统环境 -》 JVM调优
页面优化 -》 减少页面连接数、页面尺寸瘦身
应用服务器配置优化，如连接数的优化，每个请求都是独立的连接线程，所以优化此配置可以提高服务器接收HTTP并发请求的能力.当然，也不是支持的连接数越多越好。因为接收过多的HTTP请求，可能会导致服务器处理不了，宕机、瘫痪，类似铁路局购票网的状况。大部分的站点会根据服务器处理能力来设置连接数上限。
提升应用服务器的处理能力：
如多服务器集群，接收1000个请求分发多几个服务器去处理。同时，CPU主频，jvm，代码逻辑都不同程度影响业务计算能力。
如果业务有对数据库进行操作的，那么磁盘的IO读写速率是影响服务器的处理能力的最大因素。
因为无论配置的连接数再多，也需要数据库服务器执行SQL时进行的磁盘IO读写能力支撑才行。关于数据库服务器将读写压力分担。常用的方法我上面已经总结了。。。
-----------------------------------------------------------------------------------------------------------------------
用Java做一个大流量、高并发的网站应该怎么样进行底层构架？采用哪些框架技术比较适合？
通用措施：
1、动态资源和静态资源分离；
2、CDN；
3、负载均衡；
4、分布式缓存；
5、数据库读写分离或数据切分（垂直或水平）；
6、服务分布式部署。
没看到对业务的描述，业务不同面对的可能是相差很大的方案，太早介入性能方面的考虑未必是好事，有可能浪费太多时间在一些弯路上，如果实在担心的话，尽量采用一些扩展性强一点点的框架，还是那句话，不要太早走极端。
多台tomcat做负载均衡，即使你效率再高。对于高并发，单台tomcat能管理的thread pool的线程数也是有限的
tomcat使用apr/nio模式增加吞吐量
对于大流量，动静分离，tomcat处理静态资源的能力比较差,交给nginx
缓存是重要的，把实时性要求不高的，或者可以忍受一段时间内的实时，缓存起来。
使用cdn缓存
1：框架用最熟悉的；
2：优化从最上层的业务逻辑开始；
3：硬件舍得投入。
跟框架没必然联系，另外直接使用serverlet对性能提升微乎其微。关健还在于负载均衡的多层次使用，缓存的合理使用，数据垂直和水平切分，异步方案，多系统间的同步，最后千万别忘了可用性。
框架对性能影响还是很大的，如果部署到分布式架构上的话，系统不仅性能得到了提升，容错性和可扩展性都会大大改善。前台可以用Tuscany进行逻辑划分，子系统分布到不同的服务器上，后台可以使用Hadoop进行分布式存储。但是分布式需要面临很多的技术问题：分布式缓存，分布式数据库等等，对技术人员要求较高。此外，还可以使用nginx做负载均衡分发给tomcat。
框架对性能的影响微乎其微，Java的话挑熟悉的好用的就行了。更重要的是整体架构的设计、数据库的设计和优化、缓存系统等等。用Tomcat的话不要用Apache，小并发量还能用用，一旦请求多了会很麻烦，用Nginx。JVM特别是GC的调优也可以看看。
有几个常用的措施
1、对常用功能建立缓存模块
2、网页尽量静态化
3、使用单独的图片服务器，降低服务器压力，使其不会因为图片加载造成崩溃
4、使用镜像解决不同网络接入商和不同地域用户访问差异
5、数据库集群图表散列
6、加强网络层硬件配置，硬的不行来软的。
7、终极办法：负载均衡
大流量，高并发的网站主要考虑的是可伸缩性，当用户量，流量增大的时候，可以通过增加机器来分担压力。。至于直接用不用servlet，这个看你的架构。。性能和复杂性一般都不能兼得。。
个人认为框架并不能为系统的性能得到多大的提升，框架能够帮助开发人员提高开发效率，滥用框架反而会导致系统性能的下降。
建议使用开发团队最熟悉的框架，关注代码本身，防止出现内存溢出的情况。
大流量，高并发的网站主要的压力应该是在数据库的io操作上，尽量避免系统频繁请求数据库，优化查询语句，合理使用索引，减少sql语句执行的时间。
可以使用一些缓存技术，如memcache，将频繁读取，不经常变化的数据放入缓存中。
面对大流量，高并发的问题，最好的方法是增加硬件投入。另外，我不认为servlet去处理底层数据是个明智的选择。servlet玩的就是request和response，处理和响应客户端请求为主。推荐一本书《构建高性能WEB站点》。
底层架构是指服务器吗？
服务器上的集群优化很重要的。
尝试下 Apache + Tomcat 吧。多个Tomcat集群，Apache做前端，负责静态内容。再加几台服务器，分别做memcached（多台）、数据库服务器。
Apache和Tomcat之间的沟通采用AJP协议，据说效率很高。
这么下来，这么多台服务器，足够撑很多用户了。
http://www.zhihu.com/question/19809311
-----------------------------------------------------------------------------------------------------------------------
先学测试吧。不是那种业务功能的测试，是系统的测试。因为要解决大数据量、高并发的问题，我个人的知识与经验是：
1、先用单机测试。用工具产生大并发量去轰击服务器，直至服务器缓慢，甚至接近崩溃；
2、在服务器艰难地工作的时候，用工具测试服务器，仔细分析，是什么使得服务器如此艰难，是 cpu ？ 是网络？ 还是硬盘 io ？又或者是你的应用？数据库？
3、找到系统瓶颈后，优化，解决这个瓶颈，然后再循环测试。这时你又会发现新的瓶颈，再解决。循环1 - 3步，直到各方面基本平衡为止。
4、当单机无法解决问题的时候，接着开始考虑负载均衡，考虑分布式方案，然后再用 1 - 3 的步骤分析与测试。
最后，你的问题是，要学什么？答案就是：学要完成上述的步骤，解决其中产生的问题所涉及的各种知识。这不是一两本书可以讲得完的。
-----------------------------------------------------------------------------------------------------------------------
大流量: Varnish, Nginx, HAproxy
高并发: Node.js, Nginx, Redis, No-SQL
静态化，CDN
-----------------------------------------------------------------------------------------------------------------------
你需要了解大数据高并发的瓶颈在哪里，一般都是数据库层面的，机械硬盘承载不起非常快速的读写操作，cpu承载不起大量的逻辑运算，所以最基本的解决思路就是：
1.换固态硬盘加快硬盘的读写效率。
2.建立缓存中间件降低对硬盘的读写次数，缓存不用多说了，最最最基本和重要的优化策略。
3.将硬盘的读写或者数据的计算分摊到多台机器上，也就是集群。hadoop就是基于这个层面的。
4.良好的查询算法，降低读的次数，分表，分库，索引等都是基于这层面的。
理论上来讲，在带宽充裕的情况下，只要遵循上面的4个思路进行延伸就可以解决大部分的高并发问题。
-----------------------------------------------------------------------------------------------------------------------
这个问题完全可以重定向到如何处理高并发业务场景. 以下只是我工作一年多接触到的一些基础,也许有偏差,要具备高并发的经验确实需要有实际项目,因为业务逻辑其实很容易理清,但是要在高并发的情况下如何找到业务繁忙的热点并进行优化,完全只能凭经验.
假如没有靠谱的公司,接触不到高并发的业务场景怎么办? 从处理技巧上,可以通过大牛学习高并发的架构,比如张宴:张宴的博客 - Web系统架构与底层研发.至少你可以知道处理高并发的业务逻辑是:
- 前端:异步请求+资源静态化+cdn
- 后端:请求队列+轮询分发+负载均衡+共享缓存
- 数据层:redis缓存+数据分表+写队列
- 存储:raid阵列+热备
- 网络:dns轮询+DDOS攻击防护
对于高并发并没有什么通用解决方案,必须根据业务场景进行分析,不同的业务场景对于架构的取舍是不一样的.但万变不离其宗,掌握这些处理高并发的分析方法还是很有必要的.
如何学习高并发的工具?
处理高并发的开源轮子其实很多.很多高并发的架构分享都会提及使用的工具,自己多留心,再看看手册,有条件自己搭起来跑一跑.
redis,nginx/Tengine,keeplive,DRBD,heartbeat这些小工具还是可以在虚拟机上面多开几台跑起来的.至于大业务场景,除了进大公司没有别的办法,因为有些工具运行的配置要求太高,必须多台服务器配合才能完成.
如何模拟高并发场景?
并不是只有实际生产环境才能测试高并发,其实模拟高并发的轮子也很多,最常用的apache
benchmark,winrunner,loadrunner,这些教程很多,用来模拟基本的高并发业务绰绰有余,自己安装试用版,学学如何用,模拟些常用的业务.
如果有精力,业内很喜欢用perl,python,C来写一些针对热点业务的负载脚本.这需要有http协议等网络封包的理论基础.
一些建议 处理高并发要学习的东西实在太多.要在没有实际工作经验的情况下逐一了解太难,也很难深入.对于高并发的学习,我建议除了多阅读高并发架构的文档学习基本的方法论以外,自己要去深入学习网络基础,数据结构和算法.这些都是处理高并发热点的理论基础.
刘天斯：一例千万级pv高性能高并发网站架构
一个支撑千万级PV的网站是非常考验一个架构是否成熟、健壮(本文不涉及软件架构的层面，有兴趣也可以讨论)。现抛出一个系统层面的架构，不保证是最优的方案，但也许适合你。理由是再优秀的架构都不具备通用性，需要根据每种应用特点针对性来设计。希望起到抛砖引玉的作用。
架构说明：
1、架构中直接引入软件名称的模块，是个人推荐使用的，如Haproxy、Hadoop等；
2、关于全局负载均衡，看成本投入情况，可以使用商业的产品，如F5-GTM，开源方案便是自搭智能DNS；
3、本地负载均衡方案，可以考虑F5-LTM或成熟的开源解决方案LVS；
4、代理层为什么推荐大家使用Haproxy？Haproxy是一个非常优秀的反向代理软件，十分高效、稳定。国内top 10的互联网公司都有在使用；
5、缓存层可以使用Squid或Varnish，个人更倾向Varnish。配置灵活、运行稳定，提供非常便利的管理接口。为啥在缓存层前面加一层代理？优点非常多，列举如下：
- 根据应用配置URI路由规则，集中热点来提高后端缓存的命中率；
- 轻松划分网站频道、版块，更好对应用进步组织、规划；
- 对URI进行一般性安全过滤，抵御注入攻击；
- 弹性调配硬件资源，应对突发事件产生大流量；
- 可回收宝贵的公网IP资源；
6、应用层开源技术方案非常多且成熟，在此不详细描述；
7、数据库层主流开源解决方案Mysql是首选，主从复制（一主对多从）是目前比较靠谱的模式；
8、关于Nosql，应用场景不多说，可参考“给部门做的Mongodb技术交流PPT”文章，redis、memcached等作为热点数据存储、数据库缓存都非常理想；
9、内网DNS扮演的角色非常重要，一定要消灭code中出现的内网IP地址，很大程度减少因IP变更、服务器故障而修改源码的情况，同时也便于维护；
10、内网LB适用在内部WEB接口、多台数据库Slave、多台Nosql Slave、公共服务等应用的负载均衡，可以使用LVS、Haproxy来实现，可用性要求不高的应用可行直接使用Localhost DNS轮询；
11、hadoop适合海量数据的存储与处理，如做网站日志分析、用户数据挖掘等；
12、管理集群，平台的核心，运维的阵地；
http://www.springload.cn/springload/detail/356
