3.1 四种Java EE容器(Tomcat、JBoss、Resin、Glassfish)
1.NFS
1.1 NFS应用场景
1.1在企业集群架构的工作场景中,NFS网络文件系统一般被用来存储共享视频、图片、附件等静态资源文件。一般是把网站用户上传的文件都放在NFS共享里,例如,BBS产品的图片、附件、头像,注意网站BBS程序不要放在NFS共享里,然后前端所有的节点访问存储服务之一,特别是中小网站公司应用频率更高。
1.2NFS系统应用优缺点说明
作用:NFS服务可以让不同的客户端挂载使用同一目录,作为共享存储使用,这样可以保证不同节点客户端数据的一致性,在集群架构环境中经常会用到。如果windows+linux可以用samba。
优点:
- 1、简单,容易上手,容易掌握。
- 2、NFS文件系统内数据是在文件系统之上的,即数据能看见。
- 3、方便,部署快速,维护简单,可控且满足需求。
- 4、可靠,从软件层面上看,数据可靠性高,经久耐用。数据是在文件系统之上的
- 5、稳定。
局限:
- 1、局限性是存在单点故障,如果nfs server宕机了所有客户端都不能访问共享目录
- 可以通过负载均衡及高可用方案弥补。
- 2、在大数据高并发的场合,NFS效率、性能有限(一般几千万pv的网站不是瓶颈,除非网站架构太差,2千万pv/日)。
- 3、客户端认证是基于ip和主机名的,权限是根据ID识别,安全性一般(用于内外则问题不大)。
- 4、NFS数据是明文的,NFS本身对数据完整性不作验证。
- 5、多台客户机器挂载一个NFS服务器时,连接管理维护麻烦(耦合度高)。尤其NFS服务出现问题后,所有NFS客户端都挂掉状态(测试环境可以使用autofs自动挂载解决)。
- 6、大中小型网站(2千万PV以下)线上应用,都有用武之地。
1.3 客户端NFS和服务端NFS通讯过程
- 1)首先服务器端启动RPC服务,并开启111端口
- 2)启动NFS服务,并向RPC注册端口信息
- 3)客户端启动RPC(portmap服务),向服务端的RPC(portmap)服务请求服务端的NFS端口
- 4)服务端的RPC(portmap)服务反馈NFS端口信息给客户端。
- 5)客户端通过获取的NFS端口来建立和服务端的NFS连接并进行数据的传输。
2. FTP
2.1 FTP优缺点
2.1.1 FTP优点
- a)完全基于网络,覆盖范围广,操作更加灵活,能让更多的人知晓和获益。
- b)完善的用户权限管理,能指定每个登陆的用户能看到什么、做什么事情,
- 如某个用户只能查看和下载A目录,但是某个用户不仅可以查看、下载,
- 还可以删除、新建等。
- c)数据传输可以通过SSL、SSH2进行安全性加密,保证数据不被非法截取,安全性高。
- d)使用TCP/IP协议,保证数据的准确到达。
- e)传输速度快。当文件大于1M的时候,FTP的传输速率比HTTP更快,文件越大,速度越快。
2.1.2 FTP的缺点
- a. 数据传输模式不合理
- b. 工作方式设计不合理
- c. 与防火墙工作不协调
- d. 密码安全策略不完善
- e. FTP协议效率低下
2.2 FTP工作模式
FTP协议有两种工作方式:PORT方式和PASV方式,中文意思为主动式和被动式
主动模式:服务端从20端口主动向客户端发起连接
被动模式:服务端在指定范围内某个端口被动等待客户端连接
主动模式端口分配:控制端口 21 传输数据端口 20
被动模式端口分配:控制端口 21 传输数据端口 随机
3.Tomcat
3.1 四种Java EE容器(Tomcat、JBoss、Resin、Glassfish)
- a. Tomcat是Apache鼎力支持的Java Web应用服务器(注:servlet容器),由于它优秀的稳定性以及丰富的文档资料,广泛的使用人群,从而在开源领域受到最广泛的青睐。
- b. Jboss作为Java EE应用服务器,它不但是Servlet容器,而且是EJB容器,从而受到企业级开发人员的欢迎,从而弥补了Tomcat只是一个Servlet容器的缺憾。
- c. Resin也仅仅是一个Servlet容器,然而由于它优秀的运行速度,使得它在轻量级Java Web领域备受喜爱,特别是在互联网Web服务领域,众多知名公司都采用其作为他们的Java Web应用服务器,譬如163、ku6等。在商用应用服务器里主要有:Weblogic、Websphere,其中Weblogic我也使用过很长一段时间,当时也只用其当Servlet容器,然而就在同等条件下,在性能及易用性等方面,要比Tomcat优秀很多。
- d.glassfish是Sun公司推出的Java EE服务器(Java EE容器),一个比较活跃的开源社区,不断的通过社区的反馈来提高其的可用性,经过glassfish v1 glassfish v2 到今天的glassfish v3 ,它已经走向成熟。Glassfish是一个免费、开放源代码的应用服务,它实现了Java EE 5,Java EE 5 平台包括了以下最新技术:EJB 3.0、JSF 1.2、Servlet 2.5、JSP 2.1、JAX-WS 2.0、JAXB 2.0、 Java Persistence 1.0、Common Annonations 1.0、StAX 1.0等。
3.2 java一些相关概念
Java 拥有3个版本,分别为:J2EE、J2SE和J2ME(也就是说,J2EE、J2SE和J2ME是Java的不同版本)。以下是详细介绍:
- J2EE(Java 2 Platform Enterprise Edition)企业版
是为开发企业环境下的应用程序提供的一套解决方案。该技术体系中包含的技术如Servlet Jsp等,主要针对于Web应用程序开发。 - J2SE(Java 2 Platform Standard Edition)标准版
是为开发普通桌面和商务应用程序提供的解决方案。该技术体系是其他两者的基础,可以完成一些桌面应用程序的开发。比如Java版的扫雷。
平时所说的JDK其实就是指J2SE,这也是本教程所要讲解的。 - J2ME(Java 2 Platform Micro Edition)小型版
是为开发电子消费产品和嵌入式设备提供的解决方案。该技术体系主要应用于小型电子消费类产品,如手机中的应用程序等。
3.2.1 JDK、JRE、JVM区别
JDK——全称Java development toolkit,相当于是Java的库函数,是编译、运行java程序的工具包,是一切java应用程序的基础,所有java应用程序是构建在这个之上的。它是一组API,也可以说是一些java Class。JDK作为Java开发工具包,主要用于构建在Java平台上运行的应用程序、Applet 和组件等,目前ORACLE官网介绍看,JDK属于SDK的一部分,JDK和SDK一起发行的。
JRE——全称Java Runtime Environment,Java运行环境,也就是Java平台。所有的Java程序都要在JRE下才能运行。JDK的工具也是Java程序,也需要JRE才能运行。为了保持JDK的独立性和完整性,在JDK的安装过程中,JRE也是安装的一部分。所以,目前ORACLE官网介绍看,JRE则属于JDK的一部分,如果不想开发,只是想跑跑JAVA程序,官网可以下载到单独的JRE包,但如果要开发,还是需安装上面的JDK。
JVM——全称Java Virtual Machine,Java虚拟机,是JRE的一部分。它是一个虚构出来的计算机,是通过在实际的计算机上仿真模拟各种计算机功能来实现的。JVM有自己完 善的硬件架构,如处理器、堆栈、寄存器等,还具有相应的指令系统。Java语言最重要的特点就是跨平台运行。使用JVM就是为了支持与操作系统无关,实现跨平台。
所以,JAVA虚拟机JVM是属于JRE的,而现在我们安装JDK时也附带安装了JRE(当然也可以单独安装JRE)。
3.2.2 jsp和servlet的区别和联系:
1.jsp经编译后就变成了Servlet.
(JSP的本质就是Servlet,JVM只能识别java的类,不能识别JSP的代码,Web容器将JSP的代码编译成JVM能够识别的java类)
2.jsp更擅长表现于页面显示,servlet更擅长于逻辑控制.
3.Servlet中没有内置对象,Jsp中的内置对象都是必须通过HttpServletRequest对象,HttpServletResponse对象以及HttpServlet对象得到.
Jsp是Servlet的一种简化,使用Jsp只需要完成程序员需要输出到客户端的内容,Jsp中的Java脚本如何镶嵌到一个类中,由Jsp容器完成。
而Servlet则是个完整的Java类,这个类的Service方法用于生成对客户端的响应。
联系:
JSP是Servlet技术的扩展,本质上就是Servlet的简易方式。JSP编译后是“类servlet”。
Servlet和JSP最主要的不同点在于:
Servlet的应用逻辑是在Java文件中,并且完全从表示层中的HTML里分离开来。
而JSP的情况是Java和HTML可以组合成一个扩展名为.jsp的文件。
JSP侧重于视图,Servlet主要用于控制逻辑
Servlet更多的是类似于一个Controller,用来做控制。
3.3 tomcat的8005端口启动缓慢
直接配置jdk securerandom.source为urandom解决:
1.打开$JAVA_HOME/jre/lib/security/java.security这个文件,找到securerandom.source配置项
修改为:
securerandom.source=file:/dev/./urandom
注:dev/random的一个副本是/dev/urandom (”unlocked”,非阻塞的随机数发生器),它会重复使用熵池中的数据以产生伪随机数据。这表示对/dev/urandom的读取操作不会产生阻塞,但其输出的熵可能小于/dev/random的。它可以作为生成较低强度密码的伪随机数生成器,不建议用于生成高强度长期密码。
3.4 Tomcat主要目录
bin ——Tomcat执行脚本目录
conf ——Tomcat配置文件
lib ——Tomcat运行需要的库文件(JARS)
logs ——Tomcat执行时的LOG文件
temp ——Tomcat临时文件存放目录
webapps ——Tomcat的主要Web发布目录(存放我们自己的JSP,SERVLET,类)
work ——Tomcat的工作目录,Tomcat将翻译JSP文件到的Java文件和class文件放在这里。
(1) bin目录下的文件
catalina.sh 用于启动和关闭tomcat服务器
configtest.sh 用于检查配置文件
startup.sh 启动Tomcat脚本
shutdown.sh 关闭Tomcat脚本
(2) conf目录下的文件
server.xml Tomcat 的全局配置文件
web.xml 为不同的Tomcat配置的web应用设置缺省值的文件
tomcat-users.xml Tomcat用户认证的配置文件
(3) lib目录下的文件
包含被Tomcat使用的各种各样的jar文件。
(4) logs目录下的文件
localhost_access_log.2013-09-18.txt 访问日志
localhost.2013-09-18.log 错误和其它日志
manager.2013-09-18.log 管理日志
catalina.2013-09-18.log Tomcat启动或关闭日志文件
(5) webapps目录下的文件
含Web应用的程序(JSP、Servlet和JavaBean等)
(6) work目录下的文件
由Tomcat自动生成,这是Tomcat放置它运行期间的中间(intermediate)文件(诸如编译的JSP文件)地方。 如果当Tomcat运行时,你删除了这个目录那么将不能够执行包含JSP的页面。
3.5 server.xml配置详解
元素名
| 属性
| 解释
|
server | port | 指定一个端口,这个端口负责监听关闭tomcat的请求 |
shutdown | 指定向端口发送的命令字符串 | |
service | name | 指定service的名字 |
Connector(表示客户端和service之间的连接) | port | 指定服务器端要创建的端口号,并在这个断口监听来自客户端的请求 |
minProcessors | 服务器启动时创建的处理请求的线程数 | |
maxProcessors | 最大可以创建的处理请求的线程数 | |
enableLookups | 如果为true,则可以通过调用request.getRemoteHost()进行DNS查询来得到远程客户端的实际主机名,若为false则不进行DNS查询,而是返回其ip地址 | |
redirectPort | 指定服务器正在处理http请求时收到了一个SSL传输请求后重定向的端口号 | |
acceptCount | 指定当所有可以使用的处理请求的线程数都被使用时,可以放到处理队列中的请求数,超过这个数的请求将不予处理 | |
connectionTimeout | 指定超时的时间数(以毫秒为单位) | |
Engine(表示指定service中的请求处理机,接收和处理来自Connector的请求) | defaultHost | 指定缺省的处理请求的主机名,它至少与其中的一个host元素的name属性值是一样的 |
Context(表示一个web应用程序,通常为WAR文件,关于WAR的具体信息见servlet规范) | docBase | 应用程序的路径或者是WAR文件存放的路径 |
path | 表示此web应用程序的url的前缀,这样请求的url为http://localhost:8080/path/**** | |
reloadable | 这个属性非常重要,如果为true,则tomcat会自动检测应用程序的/WEB-INF/lib 和/WEB-INF/classes目录的变化,自动装载新的应用程序,我们可以在不重起tomcat的情况下改变应用程序 | |
host(表示一个虚拟主机) | name | 指定主机名 |
appBase | 应用程序基本目录,即存放应用程序的目录 | |
unpackWARs | 如果为true,则tomcat会自动将WAR文件解压,否则不解压,直接从WAR文件中运行应用程序 | |
Logger(表示日志,调试和错误信息) | className | 指定logger使用的类名,此类必须实现org.apache.catalina.Logger 接口 |
prefix | 指定log文件的前缀 | |
suffix | 指定log文件的后缀 | |
timestamp | 如果为true,则log文件名中要加入时间,如下例:localhost_log.001-10-04.txt | |
Realm(表示存放用户名,密码及role的数据库) | className | 指定Realm使用的类名,此类必须实现org.apache.catalina.Realm接口 |
Valve(功能与Logger差不多,其prefix和suffix属性解释和Logger 中的一样) | className | 指定Valve使用的类名,如用org.apache.catalina.valves.AccessLogValve类可以记录应用程序的访问信息 |
directory | 指定log文件存放的位置 | |
pattern | 有两个值,common方式记录远程主机名或ip地址,用户名,日期,第一行请求的字符串,HTTP响应代码,发送的字节数。combined方式比common方式记录的值更多 |
3.6 重定向web应用程序目录
WEB-INF下面的内容都是只能由服务器级别才能访问,客户端并不能访问。什么是客户端级别?什么是服务器级别呢?
转发就是服务器级别,浏览器的地址不会变,因为,客户端发送一个请求,服务器受理之后,发现要请求内容还要再去别的请求,那么转发就是服务器自己去处理完成。不麻烦客户端(浏览器)了,所以客户端上面的地址栏不会改变。
重定向:就是客户端级别的。服务器收到请求后,发现还要去请求别的内容,但是服务器自己不想处理,那么就告诉客户端,你自己去处理吧,那么客户端就去请求那个别的内容了。所以客户端(浏览器)地址栏就会改变了。
在web项目中,为了安全,可能需要把jsp文件放在WEB-INF目录下,这样如果我们的页面中出现超链接a标签或者js的location.href去直接转向到WEB-INF下的某一个jsp页面,那么就会引用不到,因为这样的请求方式是客户端的请求,而WEB-INF页面只对服务端开放,对客户端是不可见的。这时候我们可以使用action,来进行转向,我们先去请求一个action,然后由这个action分发到这个WEB-INF下的页面就可以了。我们可以自己定义一个类似struts1的DispatcherAction的一个action来分发页面。