Tomcat

事件源于在服务器运行一个脚本程序… 好好的脚本突然报错,还以为脚本出现问题了。细看报错原因(具体报错信息已经忘记了)，是没有可用空间。从没遇见过这个情况，怎么办呢？ 一、确定是不是真的是磁盘空间不足 输入命令：df –lh 查看磁盘信息 很明显：Filesystem下的挂载点 /dev/xvda1 下的40G容量已经耗尽。 既然问题已经确定了，接下来就是处理了。 处理方法也很简单，就是删文件。 问：删除什么文件？ 答：删除占用磁盘空间大，但又无用的文件。 问：什么是无用的文件？ 答：如果对系统不熟悉的话，日志可能是你第一的下手目标。 二、如何定位最大文件目录 输入命令： cd / 进入根目录。 输入命令：du -h max-depth=1 寻找当前目录，哪个文件夹占用空间最大 以上两个命令之后，可以看到 /usr 此路径占用较大磁盘空间，占用了21G。眼尖的同学可能看到了最后一项显示24G，它表示当前目录所有文件占用磁盘空间总和容量是24G。 如法炮制，几番判断后，定位到tomcat的日志文件。 由上图可以判断，17G文件在当前目录(tomcat日志目录)文件中。 三、如何定位最大文件 输入命令：ls –lhS 将文件以从大到小顺序展现 最终定位文件为：catalina.out 这个日志文件。 四、确认文件未被占用 删除文件谁都会：rm –f catalina.out 但是

一、确定是不是真的是磁盘空间不足 输入命令：df –lh 查看磁盘信息 很明显：Filesystem下的挂载点 /dev/xvda1 下的40G容量已经耗尽。 既然问题已经确定了，接下来就是处理了。 处理方法也很简单，就是删文件。 问：删除什么文件？ 答：删除占用磁盘空间大，但又无用的文件。 问：什么是无用的文件？ 答：如果对系统不熟悉的话，日志可能是你第一的下手目标。 二、如何定位最大文件目录 输入命令： cd / 进入根目录。 输入命令：du -h --max-depth=1 寻找当前目录，哪个文件夹占用空间最大 以上两个命令之后，可以看到 /usr 此路径占用较大磁盘空间，占用了21G。眼尖的同学可能看到了最后一项显示24G，它表示当前目录所有文件占用磁盘空间总和容量是24G。 如法炮制，几番判断后，定位到tomcat的日志文件。 由上图可以判断，17G文件在当前目录(tomcat日志目录)文件中。 三、如何定位最大文件 输入命令：ls –lhS 将文件以从大到小顺序展现 最终定位文件为：catalina.out 这个日志文件。 四、确认文件未被占用 删除文件谁都会：rm –f catalina.out 但是，最好确认下是否要下载下来让开发人员分析日志。 辛苦一阵找到文件，删除了很开心，输入命令：df –lh 发现磁盘空间仍是满的状态。跟图一完全没有区别

一、基础 　　 集合类，并发包，IO/NIO，JVM，内存模型，泛型，异常，反射，等有深入了解，最好是看过源码了解底层的设计。 二、需要全面的互联网主流技术相关知识 　　　　深入了解mysql，redis，mongodb，nginx，tomcat，rpc，jms等方面的知识。你要问需要了解到什么程度，我可以给你说个大慨。 　　　　首先对于MySQL，你要知道常见的参数设置，存储引擎怎么去选择，还需要了解常见的索引引擎，知道怎么去选择。知道怎么去设计表，怎么优化sql，怎么根 据执行计划去调优。 　　　　 高级的你需要去做分库分表的设计和优化，一般互联网企业的数据库都是读写分离，还会垂直与水平拆分，所以这个也有经验的成分在里面。然后redis， 　　mongodb都是需要了解原理，需要会调整参数的，而nginx和tomcat几乎都是JAVA互联网方面必配，其实很阿里的技术栈选择有点关系。 　　　　至于rpc相关的就多的去，必须各种网络协议，序列化技术，SOA等等，你要有一个深入的理解。现在应用比较广的rpc框架，在国内就是dubbo了，可以自行搜 　　索。至于jms相关的起码得了解原理吧，一般情况下不是专门开发中间件系统和支撑系统的不需要了解太多细节，国内企业常用的主要是activeMQ和kafka。 第三、编程能力，编程思想，算法和架构能力 　　　　

背景 随着业务不断发展，用户量不断增加，系统负载越来越高。为了解决系统负载问题，我们是不是直接大量增加机器就可以了？ 同时，公司业务开展需要，可能需要开展各种营销活动，目前系统是否能够支持那么多用户也是个未知数，如何解决呢？ 答案就是今天要讲的压测。 目的 验证单个业务及整个的处理能力及响应时间等 验证系统的性能瓶颈 合理的容量规划，而不是大量增加 分类 单接口压测 全链路压测 性能测试指标 业务类 TPS 相应时间 - 平均响应时间、最小响应时间、最大响应时间、90%响应时间等 - 百分位数是一个统计学名词。99% 的百分位响应时间，指的是 99% 的请求响应时间都处在这个值以下。 - 如果99%响应时间跟平均响应时间相差很大，那么说明是抗不住这么大量的，需要做相应调整及优化 业务成功率 - 压测前要确定压测的业务成功率，不能把报错的数据当做压测结果，一般可以定业务成功率最少为1% 系统资源指标 CPU使用率 内存使用率 磁盘繁忙率 网络IO 全链路压测 目的 只做单系统压测是不够的，因为在活动开始的瞬间，各系统都面临自身服务的巨大的压力，而系统之间是有互相依赖关系的，单机压测没有考虑到依赖环节压力都比较大的情况。一个系统出现故障，故障会在链路流转过程中层层累加，会造成无法评估的影响。 为什么选择线上环境做全链路压测

概述 本文以淘宝作为例子，介绍从一百个到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。 特别说明：本文以淘宝为例仅仅是为了便于说明演进过程可能遇到的问题，并非是淘宝真正的技术演进路径 基本概念 在介绍架构之前，为了避免部分读者对架构设计中的一些概念不了解，下面对几个最基础的概念进行介绍： 分布式 系统中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署在不同的服务器上，或两个相同功能的Tomcat分别部署在不同服务器上 高可用 系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有高可用性 集群 一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务，这个整体称为集群。如Zookeeper中的Master和Slave分别部署在多台服务器上，共同组成一个整体提供集中配置服务。在常见的集群中，客户端往往能够连接任意一个节点获得服务，并且当集群中一个节点掉线时，其他节点往往能够自动的接替它继续提供服务，这时候说明集群具有高可用性 负载均衡 请求发送到系统时，通过某些方式把请求均匀分发到多个节点上，使系统中每个节点能够均匀的处理请求负载，则可认为系统是负载均衡的 正向代理和反向代理 系统内部要访问外部网络时

前言： 这篇文章主要介绍了Spring Boot如何支持嵌入式Servlet容器,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下。如果需要其他学习资料或教程的，可以 点击进入，暗号：csyy ，绝对免费提供！因为资料太多无法全部展示，这只是其中的一点点，需要学习的朋友，可以进来和其他小伙伴一起探讨学习！ Spring Boot支持Tomcat、Jetty和Undertow三种Servlet容器嵌入到Web应用程序中，开发者使用starter即可方便嵌入，默认情况下，嵌入服务器的访问端口为8080。 1、Servlets、Filters & Listeners 这些组件可以同组件扫描注册，即把他们定义为Spring Bean。 默认情况下，如果只有一个servlet，则把它映射到/；如果有多个servlet，则加上bean name作为前缀然后映射到/*。 如果默认策略不能满足你，你可以通过ServletRegistrationBean、FilterRegistrationBean和ServletListenerRegistrationBean来完全控制。 如果Filter需要按顺序执行，则可以通过@Order注解定义Filter的顺序，或者实现Ordered接口。 容器初始化 嵌入式容器不会直接执行Servlet 3.0+ javax.servlet

STEP1: 选择创建Maven项目，勾选Create from archetype中的org.apache.maven.archetype:maven archetype-webapp 选择maven settings.xml文件的位置 构建好的项目结构如下图所示： STEP2 在pom.xml文件中添加tomcatc插件 <plugin> <groupId>org.apache.tomcat.maven</groupId> <artifactId>tomcat7-maven-plugin</artifactId> <version>2.1</version> <configuration> <port>8080</port> <path>/</path> <uriEncoding>UTF-8</uriEncoding> <server>tomcat7</server> </configuration> </plugin> 除此以外，添加上servlet的jar包 <dependency> <groupId>javax.servlet</groupId> <artifactId>servlet-api</artifactId> <version>2.5</version> <scope>provided</scope> </dependency> <dependency>