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