Java 面试题之并发与性能

并发与性能调优

1. 有个每秒钟5k个请求,查询手机号所属地的笔试题,如何设计算法?请求再多,比如5w,如何设计整个系统?

认清系统的高并发由3个层面导致:

  1. 传输层:大量用户对系统请求后,将会造成网络带宽和Web服务器的I/O瓶颈。
  2. 计算层:接收大量用户请求进行计算,将会造成业务服务器和业务支撑服务器的瓶颈。
  3. 存储层:传输层和计算层将会产生大量的数据,数据量暴增,将会导致数据库和储存上的瓶颈。

高并发的解决方法有两种,一种是使用缓存、另一种是使用生成静态页面;

  • 用分布式应用设计
  • 分布式缓存数据库
  • 代码优化
    • 不要频繁的new对象,对于在整个应用中只需要存在一个实例的类使用单例模式。对于String的连接操作,使用StringBuffer或者StringBuilder。对于utility类型的类通过静态方法来访问。
    • 避免使用错误的方式,如Exception可以控制方法推出,但是Exception要保留stacktrace消耗性能,除非必要不要使用 instanceof 做条件判断,尽量使用比的条件判断方式。使用JAVA中效率高的类,比如ArrayList比Vector性能好。

使用静态页面

补充:页面静态化

2. 高并发情况下,我们系统是如何支撑大量的请求的

(1)分析一

优化程序,优化服务配置,优化系统配置

几点需要注意:

  • 尽量使用缓存,包括用户缓存,信息缓存等,多花点内存来做缓存,可以大量减少与数据库的交互,提高性能。
  • 用jprofiler等工具找出性能瓶颈,减少额外的开销。
    优化数据库查询语句,减少直接使用hibernate等工具的直接生成语句(仅耗时较长的查询做优化)。
  • 优化数据库结构,多做索引,提高查询效率。
  • 统计的功能尽量做缓存,或按每天一统计或定时统计相关报表,避免需要时进行统计的功能。
  • 能使用静态页面的地方尽量使用,减少容器的解析(尽量将动态内容生成静态html来显示)。
  • 解决以上问题后,使用服务器集群来解决单台的瓶颈问题。

基本上以上述问题解决后,达到系统最优。

(2)分析二

在面对大量用户访问、高并发请求方面,基本的解决方案集中在这样几个环节:
使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。但是除了这几个方面,还没法根本解决大型网站面临的高负载和高并发问题。

上面提供的几个解决思路在一定程度上也意味着更大的投入,并且这样的解决思路具备瓶颈,没有很好的扩展性,下面我从低成本、高性能和高扩张性的角度来说说我的一些经验。

1)、HTML静态化

其实大家都知道,效率最高、消耗最小的就是纯静态化的html页面,所以我们尽可能使我们的网站上的页面采用静态页面来实现,这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站,我们无法全部手动去挨个实现,于是出现了我们常见的信息发布系统CMS,像我们常访问的各个门户站点的新闻频道,甚至他们的其他频道,都是通过信息发布系统来管理和实现的,信息发布系统可以实现最简单的信息录入自动生成静态页面,还能具备频道管理、权限管理、自动抓取等功能,对于一个大型网站来说,拥有一套高效、可管理的CMS是必不可少的。

2)、图片服务器分离

大家知道,对于Web服务器来说,不管是Apache、IIS还是其他容器,图片是最消耗资源的,于是我们有必要将图片与页面进行分离,这是基本上大型网站都会采用的策略,他们都有独立的图片服务器,甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力,并且可以保证系统不会因为图片问题而崩溃,在应用服务器和图片服务器上,可以进行不同的配置优化,比如apache在配置ContentType的时候可以尽量少支持,尽可能少的LoadModule,保证更高的系统消耗和执行效率。 这一实现起来是比较容易的一现,如果服务器集群操作起来更方便,如果是独立的服务器,新手可能出现上传图片只能在服务器本地的情况下,可以在令一台服务器设置的IIS采用网络路径来实现图片服务器,即不用改变程序,又能提高性能,但对于服务器本身的IO处理性能是没有任何的改变。

3)、数据库集群和库表散列

大型网站都有复杂的应用,这些应用必须使用数据库,那么在面对大量访问的时候,数据库的瓶颈很快就能显现出来,这时一台数据库将很快无法满足应用,于是我们需要使用数据库集群或者库表散列。

在数据库集群方面,很多数据库都有自己的解决方案,Oracle、Sybase等都有很好的方案,常用的MySQL提供的Master/Slave也是类似的方案,您使用了什么样的DB,就参考相应的解决方案来实施即可。

上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制,于是我们需要从应用程序的角度来考虑改善系统架构,库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离,不同的模块对应不同的数据库或者表,再按照一定的策略对某个页面或者功能进行更小的数据库散列,比如用户表,按照用户ID进行表散列,这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构,将论坛的用户、设置、帖子等信息进行数据库分离,然后对帖子、用户按照板块和ID进行散列数据库和表,最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。

4)、缓存

缓存一词搞技术的都接触过,很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。
架构方面的缓存,对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块,也可以使用外加的Squid模块进行缓存,这两种方式均可以有效的提高Apache的访问响应能力。
网站程序开发方面的缓存,Linux上提供的Memory Cache是常用的缓存接口,可以在web开发中使用,比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享,一些大型社区使用了这样的架构。
在使用web语言开发的时候,各种语言基本都有自己的缓存模块和方法,PHP有Pear的Cache模块,Java就更多了,.net不是很熟悉,相信也肯定有。

5)、镜像

镜像是大型网站常采用的提高性能和数据安全性的方式,镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异,比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点,数据进行定时更新或者实时更新。在镜像的细节技术方面,这里不阐述太深,有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路,比如Linux上的rsync等工具。

6)、负载均衡
负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。

硬件四层交换

第四层交换使用第三层和第四层信息包的报头信息,根据应用区间识别业务流,将整个区间段的业务流分配到合适的应用服务器进行处理。 第四层交换功能就像是虚IP,指向物理服务器。它传输的业务服从的协议多种多样,有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上,需要复杂的载量平衡算法。在IP世界,业务类型由终端TCP或UDP端口地址来决定,在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。
在硬件四层交换产品领域,有一些知名的产品可以选择,比如Alteon、F5等,这些产品很昂贵,但是物有所值,能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。

软件四层交换

了解了硬件四层交换机的原理后,基于OSI模型来实现的软件四层交换也就应运而生,这样的解决方案实现的原理一致,不过性能稍差。但是满足一定量的压力还是游刃有余的,有人说软件实现方式其实更灵活,处理能力完全看你配置的熟悉能力。
软件四层交换我们可以使用Linux上常用的LVS来解决,LVS就是Linux Virtual Server,他提供了基于心跳线heartbeat的实时灾难应对解决方案,提高系统的鲁棒性,同时可供了灵活的虚拟VIP配置和管理功能,可以同时满足多种应用需求,这对于分布式的系统来说必不可少。

一个典型的使用负载均衡的策略就是,在软件或者硬件四层交换的基础上搭建squid集群,这种思路在很多大型网站包括搜索引擎上被采用,这样的架构低成本、高性能还有很强的扩张性,随时往架构里面增减节点都非常容易。这样的架构我准备空了专门详细整理一下和大家探讨。

对于大型网站来说,前面提到的每个方法可能都会被同时使用到,我这里介绍得比较浅显,具体实现过程中很多细节还需要大家慢慢熟悉和体会,有时一个很小的squid参数或者apache参数设置,对于系统性能的影响就会很大

具体参考:

3. 集群如何同步会话状态

事实上,网站总是有状态的。每一个登录信息、用户信息常常被存储在session内部。而当一个网站被部署在不止一台服务器的时候,就会遇到session同步的问题。事实上即使一个很小的网站,也要至少有两台服务器互为备份,分单流量是必须得,更重要的是无缝切流量升级。为了保证服务的不间断又要进行网站的维护升级,切流量是最简单的。那么如何保证切流量的时候session也会跟着同步过去呢?在集群环境下,大致有以下几种手段:

(1)Session复制

这是一种在早期应用系统中使用较多的服务器session管理方式。应用服务器开启Web容器的session的复制功能,在集群中的几台服务器之间同步session对象,这样一台服务器宕机不会导致session数据丢失。即每一台服务器都持有集群中所有的session,每次访问仅从本机获取就可以了。其工作形式如下所示:

从session复制的几条线就可以看出,这种方式仅适用用小型集群。当服务集群规模很大时,集群服务器间的复制就需要大量的通讯,占用大量网络资源,甚至会出现内存不够的情况。

(2)Session绑定

Session绑定可以利用负载均衡的源地址Hash算法实现,负载均衡服务器总是将来自同一个IP地址的访问分发到同一台服务器上。这样整个会话期间,用户所有的请求都来自一台服务器,保证了Session总是从这台服务器获取。其工作形式如下图所示:

但是这样的系统显然不符合我们对系统的需求。如果一台服务器宕机,那么其处理的所有请求Session会话全部丢失,用户因为切换服务器后没有Session而导致无法完成业务。

(3)利用Cookie记录Session

这种管理方式将Session记录在客户端,每次请求服务器的时候,将Session放在请求中发送给服务器,服务器处理完成后再将修改后的Session响应给客户端。

利用Cookie记录当然也有缺点,比如Cookie大小限制,能记录的信息也有限,因为很多时候我们在Session中储存的也并非String类型的记录。每次请求都需要传输Cookie,影响性能;另外如果用户关闭Cookie功能就不能用了。但是这种方式因此高可用性、支持服务器的线性伸缩,许多网站都在使用这种方式。我的学校网站也应用了这种技术。

(4)Session服务器

如果有这样一个服务器,可用性高、伸缩性好、性能也不错,对信息大小又没有限制,那它就是Session服务器。利用独立部署的Session服务器统一管理Session,应用服务器每次读写Session时,都访问Session服务器。其工作形式如下所示:

这种方式实际上是将应用服务器的状态分离,分为无状态的应用服务器和有状态的Session服务器,然后针对这两种服务器的不同特性分别设计其架构。

对于有状态的Session服务器,一种比较简单的方式是利用分布式缓存、数据库等。

具体请看:

4. 负载均衡的原理

5 .如果有一个特别大的访问量,到数据库上,怎么做优化(DB设计,DBIO,SQL优化,Java优化)

6. 如果出现大面积并发,在不增加服务器的基础上,如何解决服务器响应不及时问题。

7. 假如你的项目出现性能瓶颈了,你觉得可能会是哪些方面,怎么解决问题。

8. 如何查找 造成 性能瓶颈出现的位置,是哪个位置照成性能瓶颈。

9. 你的项目中使用过缓存机制吗?有没用用户非本地缓存

文章目录
  1. 1. 并发与性能调优
|