「java中slave」java中M
今天给各位分享java中slave的知识，其中也会对java中M进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文目录一览：
- 1、Java分布式系统处理分布式事务有哪些经典解决方
- 2、spring事务中查询主库还是从库
- 3、java框架有哪些常用框架
- 4、redis集群角色切换java调用异常
- 5、jenkins通过Java web start来启动slave时一直出现超时的错误
- 6、java里测试添加的命令语句是什么
Java分布式系统处理分布式事务有哪些经典解决方
当我们在生产线上用一台服务器来提供数据服务的时候，我会遇到如下的两个问题：
1）一台服务器的性能不足以提供足够的能力服务于所有的网络请求。
2）我们总是害怕我们的这台服务器停机，造成服务不可用或是数据丢失。
于是我们不得不对我们的服务器进行扩展，加入更多的机器来分担性能上的问题，以及来解决单点故障问题。 通常，我们会通过两种手段来扩展我们的数据服务：
1）数据分区：就是把数据分块放在不同的服务器上（如：uid % 16，一致性哈希等）。
2）数据镜像：让所有的服务器都有相同的数据，提供相当的服务。
对于第一种情况，我们无法解决数据丢失的问题，单台服务器出问题时，会有部分数据丢失。所以，数据服务的高可用性只能通过第二种方法来完成——数据的冗余存储（一般工业界认为比较安全的备份数应该是3份，如：Hadoop和Dynamo）。 但是，加入更多的机器，会让我们的数据服务变得很复杂，尤其是跨服务器的事务处理，也就是跨服务器的数据一致性。这个是一个很难的问题。 让我们用最经典的Use Case：“A帐号向B帐号汇钱”来说明一下，熟悉RDBMS事务的都知道从帐号A到帐号B需要6个操作：
从A帐号中把余额读出来。
对A帐号做减法操作。
把结果写回A帐号中。
从B帐号中把余额读出来。
对B帐号做加法操作。
把结果写回B帐号中。
为了数据的一致性，这6件事，要么都成功做完，要么都不成功，而且这个操作的过程中，对A、B帐号的其它访问必需锁死，所谓锁死就是要排除其它的读写操作，不然会有脏数据的问题，这就是事务。那么，我们在加入了更多的机器后，这个事情会变得复杂起来：
1）在数据分区的方案中：如果A帐号和B帐号的数据不在同一台服务器上怎么办？我们需要一个跨机器的事务处理。也就是说，如果A的扣钱成功了，但B的加钱不成功，我们还要把A的操作给回滚回去。这在跨机器的情况下，就变得比较复杂了。
2）在数据镜像的方案中：A帐号和B帐号间的汇款是可以在一台机器上完成的，但是别忘了我们有多台机器存在A帐号和B帐号的副本。如果对A帐号的汇钱有两个并发操作（要汇给B和C），这两个操作发生在不同的两台服务器上怎么办？也就是说，在数据镜像中，在不同的服务器上对同一个数据的写操作怎么保证其一致性，保证数据不冲突？
同时，我们还要考虑性能的因素，如果不考虑性能的话，事务得到保证并不困难，系统慢一点就行了。除了考虑性能外，我们还要考虑可用性，也就是说，一台机器没了，数据不丢失，服务可由别的机器继续提供。 于是，我们需要重点考虑下面的这么几个情况：
1）容灾：数据不丢、节点的Failover
2）数据的一致性：事务处理
3）性能：吞吐量 、 响应时间
前面说过，要解决数据不丢，只能通过数据冗余的方法，就算是数据分区，每个区也需要进行数据冗余处理。这就是数据副本：当出现某个节点的数据丢失时可以从副本读到，数据副本是分布式系统解决数据丢失异常的唯一手段。所以，在这篇文章中，简单起见，我们只讨论在数据冗余情况下考虑数据的一致性和性能的问题。简单说来：
1）要想让数据有高可用性，就得写多份数据。
2）写多份的问题会导致数据一致性的问题。
3）数据一致性的问题又会引发性能问题
这就是软件开发，按下了葫芦起了瓢。
一致性模型
说起数据一致性来说，简单说有三种类型（当然，如果细分的话，还有很多一致性模型，如：顺序一致性，FIFO一致性，会话一致性，单读一致性，单写一致性，但为了本文的简单易读，我只说下面三种）：
1）Weak 弱一致性：当你写入一个新值后，读操作在数据副本上可能读出来，也可能读不出来。比如：某些cache系统，网络游戏其它玩家的数据和你没什么关系，VOIP这样的系统，或是百度搜索引擎（呵呵）。
2）Eventually 最终一致性：当你写入一个新值后，有可能读不出来，但在某个时间窗口之后保证最终能读出来。比如：DNS，电子邮件、Amazon S3，Google搜索引擎这样的系统。
3）Strong 强一致性：新的数据一旦写入，在任意副本任意时刻都能读到新值。比如：文件系统，RDBMS，Azure Table都是强一致性的。
从这三种一致型的模型上来说，我们可以看到，Weak和Eventually一般来说是异步冗余的，而Strong一般来说是同步冗余的，异步的通常意味着更好的性能，但也意味着更复杂的状态控制。同步意味着简单，但也意味着性能下降。 好，让我们由浅入深，一步一步地来看有哪些技术：
Master-Slave
首先是Master-Slave结构，对于这种加构，Slave一般是Master的备份。在这样的系统中，一般是如下设计的：
1）读写请求都由Master负责。
2）写请求写到Master上后，由Master同步到Slave上。
从Master同步到Slave上，你可以使用异步，也可以使用同步，可以使用Master来push，也可以使用Slave来pull。 通常来说是Slave来周期性的pull，所以，是最终一致性。这个设计的问题是，如果Master在pull周期内垮掉了，那么会导致这个时间片内的数据丢失。如果你不想让数据丢掉，Slave只能成为Read-Only的方式等Master恢复。
当然，如果你可以容忍数据丢掉的话，你可以马上让Slave代替Master工作（对于只负责计算的节点来说，没有数据一致性和数据丢失的问题，Master-Slave的方式就可以解决单点问题了） 当然，Master Slave也可以是强一致性的， 比如：当我们写Master的时候，Master负责先写自己，等成功后，再写Slave，两者都成功后返回成功，整个过程是同步的，如果写Slave失败了，那么两种方法，一种是标记Slave不可用报错并继续服务（等Slave恢复后同步Master的数据，可以有多个Slave，这样少一个，还有备份，就像前面说的写三份那样），另一种是回滚自己并返回写失败。（注：一般不先写Slave，因为如果写Master自己失败后，还要回滚Slave，此时如果回滚Slave失败，就得手工订正数据了）你可以看到，如果Master-Slave需要做成强一致性有多复杂。
Master-Master
Master-Master，又叫Multi-master，是指一个系统存在两个或多个Master，每个Master都提供read-write服务。这个模型是Master-Slave的加强版，数据间同步一般是通过Master间的异步完成，所以是最终一致性。 Master-Master的好处是，一台Master挂了，别的Master可以正常做读写服务，他和Master-Slave一样，当数据没有被复制到别的Master上时，数据会丢失。很多数据库都支持Master-Master的Replication的机制。
另外，如果多个Master对同一个数据进行修改的时候，这个模型的恶梦就出现了——对数据间的冲突合并，这并不是一件容易的事情。看看Dynamo的Vector Clock的设计（记录数据的版本号和修改者）就知道这个事并不那么简单，而且Dynamo对数据冲突这个事是交给用户自己搞的。就像我们的SVN源码冲突一样，对于同一行代码的冲突，只能交给开发者自己来处理。（在本文后后面会讨论一下Dynamo的Vector Clock）
Two/Three Phase Commit
这个协议的缩写又叫2PC，中文叫两阶段提交。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。
spring事务中查询主库还是从库
可以给所有读的方法添加一个参数，来控制读从库还是主库。
2、数据源如何路由？
spring-jdbc 包中提供了一个抽象类：AbstractRoutingDataSource，实现了javax.sql.DataSource接口，我们用这个类来作为数据源类，重点是这个类可以用来做数据源的路由，可以在其内部配置多个真实的数据源，最终用哪个数据源，由开发者来决定。
AbstractRoutingDataSource中有个map，用来存储多个目标数据源
private MapObject, DataSource resolvedDataSources;
比如主从库可以这么存储
resolvedDataSources.put("master",主库数据源);
resolvedDataSources.put("salave",从库数据源);
AbstractRoutingDataSource中还有抽象方法determineCurrentLookupKey，将这个方法的返回值作为key到上面的resolvedDataSources中查找对应的数据源，作为当前操作db的数据源
protected abstract Object determineCurrentLookupKey();
3、读写分离在哪控制？
读写分离属于一个通用的功能，可以通过spring的aop来实现，添加一个拦截器，拦截目标方法的之前，在目标方法执行之前，获取一下当前需要走哪个库，将这个标志存储在ThreadLocal中，将这个标志作为AbstractRoutingDataSource.determineCurrentLookupKey()方法的返回值，拦截器中在目标方法执行完毕之后，将这个标志从ThreadLocal中清除。
3、代码实现
3.1、工程结构图
3.2、DsType
表示数据源类型，有2个值，用来区分是主库还是从库。
package com.javacode2018.readwritesplit.base;
public enum DsType {
MASTER, SLAVE;
}
3.3、DsTypeHolder
内部有个ThreadLocal，用来记录当前走主库还是从库，将这个标志放在dsTypeThreadLocal中
package com.javacode2018.readwritesplit.base;
public class DsTypeHolder {
private static ThreadLocalDsType dsTypeThreadLocal = new ThreadLocal();
public static void master() {
dsTypeThreadLocal.set(DsType.MASTER);
}
public static void slave() {
dsTypeThreadLocal.set(DsType.SLAVE);
}
public static DsType getDsType() {
return dsTypeThreadLocal.get();
}
public static void clearDsType() {
dsTypeThreadLocal.remove();
}
}
3.4、IService接口
这个接口起到标志的作用，当某个类需要启用读写分离的时候，需要实现这个接口，实现这个接口的类都会被读写分离拦截器拦截。
package com.javacode2018.readwritesplit.base;
//需要实现读写分离的service需要实现该接口
public interface IService {
}
3.5、ReadWriteDataSource
读写分离数据源，继承ReadWriteDataSource，注意其内部的determineCurrentLookupKey方法，从上面的ThreadLocal中获取当前需要走主库还是从库的标志。
package com.javacode2018.readwritesplit.base;
import org.springframework.jdbc.datasource.lookup.AbstractRoutingDataSource;
import org.springframework.lang.Nullable;
public class ReadWriteDataSource extends AbstractRoutingDataSource {
@Nullable
@Override
protected Object determineCurrentLookupKey() {
return DsTypeHolder.getDsType();
}
}
3.6、ReadWriteInterceptor
读写分离拦截器，需放在事务拦截器前面执行，通过@1代码我们将此拦截器的顺序设置为Integer.MAX_VALUE - 2，稍后我们将事务拦截器的顺序设置为Integer.MAX_VALUE - 1，事务拦截器的执行顺序是从小到达的，所以，ReadWriteInterceptor会在事务拦截器org.springframework.transaction.interceptor.TransactionInterceptor之前执行。
由于业务方法中存在相互调用的情况，比如service1.m1中调用service2.m2，而service2.m2中调用了service2.m3，我们只需要在m1方法执行之前，获取具体要用哪个数据源就可以了，所以下面代码中会在第一次进入这个拦截器的时候，记录一下走主库还是从库。
下面方法中会获取当前目标方法的最后一个参数，最后一个参数可以是DsType类型的，开发者可以通过这个参数来控制具体走主库还是从库。
package com.javacode2018.readwritesplit.base;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;
import org.springframework.core.annotation.Order;
import org.springframework.stereotype.Component;
import java.util.Objects;
@Aspect
@Order(Integer.MAX_VALUE - 2) //@1
@Component
public class ReadWriteInterceptor {
@Pointcut("target(IService)")
public void pointcut() {
}
//获取当前目标方法的最后一个参数
private Object getLastArgs(final ProceedingJoinPoint pjp) {
Object[] args = pjp.getArgs();
if (Objects.nonNull(args) args.length 0) {
return args[args.length - 1];
} else {
return null;
}
}
@Around("pointcut()")
public Object around(final ProceedingJoinPoint pjp) throws Throwable {
//判断是否是第一次进来,用于处理事务嵌套
boolean isFirst = false;
try {
if (DsTypeHolder.getDsType() == null) {
isFirst = true;
}
if (isFirst) {
Object lastArgs = getLastArgs(pjp);
if (DsType.SLAVE.equals(lastArgs)) {
DsTypeHolder.slave();
} else {
DsTypeHolder.master();
}
}
return pjp.proceed();
} finally {
//退出的时候，清理
if (isFirst) {
DsTypeHolder.clearDsType();
}
}
}
}
3.7、ReadWriteConfiguration
spring配置类，作用
1、@3：用来将com.javacode2018.readwritesplit.base包中的一些类注册到spring容器中，比如上面的拦截器ReadWriteInterceptor
2、@1：开启spring aop的功能
3、@2：开启spring自动管理事务的功能，@EnableTransactionManagement的order用来指定事务拦截器org.springframework.transaction.interceptor.TransactionInterceptor顺序，在这里我们将order设置为Integer.MAX_VALUE - 1，而上面ReadWriteInterceptor的order是Integer.MAX_VALUE - 2，所以ReadWriteInterceptor会在事务拦截器之前执行。
package com.javacode2018.readwritesplit.base;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.EnableAspectJAutoProxy;
import org.springframework.transaction.annotation.EnableTransactionManagement;
@Configuration
@EnableAspectJAutoProxy //@1
@EnableTransactionManagement(proxyTargetClass = true, order = Integer.MAX_VALUE - 1) //@2
@ComponentScan(basePackageClasses = IService.class) //@3
public class ReadWriteConfiguration {
}
3.8、@EnableReadWrite
这个注解用来开启读写分离的功能，@1通过@Import将ReadWriteConfiguration导入到spring容器了，这样就会自动启用读写分离的功能。业务中需要使用读写分离，只需要在spring配置类中加上@EnableReadWrite注解就可以了。
package com.javacode2018.readwritesplit.base;
import org.springframework.context.annotation.Import;
import java.lang.annotation.*;
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Import(ReadWriteConfiguration.class) //@1
public @interface EnableReadWrite {
}
4、案例
读写分离的关键代码写完了，下面我们来上案例验证一下效果。
4.1、执行sql脚本
下面准备2个数据库：javacode2018_master(主库)、javacode2018_slave(从库)
2个库中都创建一个t_user表，分别插入了一条数据，稍后用这个数据来验证走的是主库还是从库。
DROP DATABASE IF EXISTS javacode2018_master;
CREATE DATABASE IF NOT EXISTS javacode2018_master;
USE javacode2018_master;
DROP TABLE IF EXISTS t_user;
CREATE TABLE t_user (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(256) NOT NULL DEFAULT ''
COMMENT '姓名'
);
INSERT INTO t_user (name) VALUE ('master库');
DROP DATABASE IF EXISTS javacode2018_slave;
CREATE DATABASE IF NOT EXISTS javacode2018_slave;
USE javacode2018_slave;
DROP TABLE IF EXISTS t_user;
CREATE TABLE t_user (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(256) NOT NULL DEFAULT ''
COMMENT '姓名'
);
INSERT INTO t_user (name) VALUE ('slave库');
4.2、spring配置类
@1：启用读写分离
masterDs()方法：定义主库数据源
slaveDs()方法：定义从库数据源
dataSource()：定义读写分离路由数据源
后面还有2个方法用来定义JdbcTemplate和事务管理器，方法中都通过@Qualifier(“dataSource”)限定了注入的bean名称为dataSource：即注入了上面dataSource()返回的读写分离路由数据源。
package com.javacode2018.readwritesplit.demo1;
import com.javacode2018.readwritesplit.base.DsType;
import com.javacode2018.readwritesplit.base.EnableReadWrite;
import com.javacode2018.readwritesplit.base.ReadWriteDataSource;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.jdbc.datasource.DataSourceTransactionManager;
import org.springframework.transaction.PlatformTransactionManager;
import javax.sql.DataSource;
import java.util.HashMap;
import java.util.Map;
@EnableReadWrite //@1
@Configuration
@ComponentScan
public class MainConfig {
//主库数据源
@Bean
public DataSource masterDs() {
org.apache.tomcat.jdbc.pool.DataSource dataSource = new org.apache.tomcat.jdbc.pool.DataSource();
dataSource.setDriverClassName("com.mysql.jdbc.Driver");
dataSource.setUrl("jdbc:mysql://localhost:3306/javacode2018_master?characterEncoding=UTF-8");
dataSource.setUsername("root");
dataSource.setPassword("root123");
dataSource.setInitialSize(5);
return dataSource;
}
//从库数据源
@Bean
public DataSource slaveDs() {
org.apache.tomcat.jdbc.pool.DataSource dataSource = new org.apache.tomcat.jdbc.pool.DataSource();
dataSource.setDriverClassName("com.mysql.jdbc.Driver");
dataSource.setUrl("jdbc:mysql://localhost:3306/javacode2018_slave?characterEncoding=UTF-8");
dataSource.setUsername("root");
dataSource.setPassword("root123");
dataSource.setInitialSize(5);
return dataSource;
}
//读写分离路由数据源
@Bean
public ReadWriteDataSource dataSource() {
ReadWriteDataSource dataSource = new ReadWriteDataSource();
//设置主库为默认的库，当路由的时候没有在datasource那个map中找到对应的数据源的时候，会使用这个默认的数据源
dataSource.setDefaultTargetDataSource(this.masterDs());
//设置多个目标库
MapObject, Object targetDataSources = new HashMap();
targetDataSources.put(DsType.MASTER, this.masterDs());
targetDataSources.put(DsType.SLAVE, this.slaveDs());
dataSource.setTargetDataSources(targetDataSources);
return dataSource;
}
//JdbcTemplate，dataSource为上面定义的注入读写分离的数据源
@Bean
public JdbcTemplate jdbcTemplate(@Qualifier("dataSource") DataSource dataSource) {
return new JdbcTemplate(dataSource);
}
//定义事务管理器，dataSource为上面定义的注入读写分离的数据源
@Bean
public PlatformTransactionManager transactionManager(@Qualifier("dataSource") DataSource dataSource) {
return new DataSourceTransactionManager(dataSource);
}
}
4.3、UserService
这个类就相当于我们平时写的service，我是为了方法，直接在里面使用了JdbcTemplate来操作数据库，真实的项目操作db会放在dao里面。
getUserNameById方法：通过id查询name。
insert方法：插入数据，这个内部的所有操作都会走主库，为了验证是不是查询也会走主库，插入数据之后，我们会调用this.userService.getUserNameById(id, DsType.SLAVE)方法去执行查询操作，第二个参数故意使用SLAVE，如果查询有结果，说明走的是主库，否则走的是从库，这里为什么需要通过this.userService来调用getUserNameById？
this.userService最终是个代理对象，通过代理对象访问其内部的方法，才会被读写分离的拦截器拦截。
package com.javacode2018.readwritesplit.demo1;
import com.javacode2018.readwritesplit.base.DsType;
import com.javacode2018.readwritesplit.base.IService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.stereotype.Component;
import org.springframework.transaction.annotation.Propagation;
import org.springframework.transaction.annotation.Transactional;
import java.util.List;
@Component
public class UserService implements IService {
@Autowired
private JdbcTemplate jdbcTemplate;
@Autowired
private UserService userService;
@Transactional(propagation = Propagation.SUPPORTS, readOnly = true)
public String getUserNameById(long id, DsType dsType) {
String sql = "select name from t_user where id=?";
ListString list = this.jdbcTemplate.queryForList(sql, String.class, id);
return (list != null list.size() 0) ? list.get(0) : null;
}
//这个insert方法会走主库，内部的所有操作都会走主库
@Transactional
public void insert(long id, String name) {
System.out.println(String.format("插入数据{id:%s, name:%s}", id, name));
this.jdbcTemplate.update("insert into t_user (id,name) values (?,?)", id, name);
String userName = this.userService.getUserNameById(id, DsType.SLAVE);
System.out.println("查询结果：" + userName);
}
}
4.4、测试用例
package com.javacode2018.readwritesplit.demo1;
import com.javacode2018.readwritesplit.base.DsType;
import org.junit.Before;
import org.junit.Test;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
public class Demo1Test {
UserService userService;
@Before
public void before() {
AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();
context.register(MainConfig.class);
context.refresh();
this.userService = context.getBean(UserService.class);
}
@Test
public void test1() {
System.out.println(this.userService.getUserNameById(1, DsType.MASTER));
System.out.println(this.userService.getUserNameById(1, DsType.SLAVE));
}
@Test
public void test2() {
long id = System.currentTimeMillis();
System.out.println(id);
this.userService.insert(id, "张三");
}
}
test1方法执行2次查询，分别查询主库和从库，输出：
master库
slave库
是不是很爽，由开发者自己控制具体走主库还是从库。
test2执行结果如下，可以看出查询到了刚刚插入的数据，说明insert中所有操作都走的是主库。
1604905117467
插入数据{id:1604905117467, name:张三}
查询结果：张三
5、案例源码
java框架有哪些常用框架
十大常用框架：
一、SpringMVC
二、Spring
三、Mybatis
四、Dubbo
五、Maven
六、RabbitMQ
七、Log4j
八、Ehcache
九、Redis
十、Shiro
延展阅读：
一、SpringMVC
Spring Web MVC是一种基于Java的实现了Web MVC设计模式的请求驱动类型的轻量级Web框架，即使用了MVC架构模式的思想，将web层进行职责解耦，基于请求驱动指的就是使用请求-响应模型，框架的目的就是帮助我们简化开发，Spring Web MVC也是要简化我们日常Web开发的。
模型（Model ）封装了应用程序的数据和一般他们会组成的POJO。
视图（View）是负责呈现模型数据和一般它生成的HTML输出，客户端的浏览器能够解释。
控制器（Controller ）负责处理用户的请求，并建立适当的模型，并把它传递给视图渲染。
Spring的web模型 - 视图 - 控制器（MVC）框架是围绕着处理所有的HTTP请求和响应的DispatcherServlet的设计。
Spring Web MVC处理请求的流程
具体执行步骤如下：
1、 首先用户发送请求————前端控制器，前端控制器根据请求信息（如URL）来决定选择哪一个页面控制器进行处理并把请求委托给它，即以前的控制器的控制逻辑部分；图2-1中的1、2步骤；
2、 页面控制器接收到请求后，进行功能处理，首先需要收集和绑定请求参数到一个对象，这个对象在Spring Web MVC中叫命令对象，并进行验证，然后将命令对象委托给业务对象进行处理；处理完毕后返回一个ModelAndView（模型数据和逻辑视图名）；图2-1中的3、4、5步骤；
3、 前端控制器收回控制权，然后根据返回的逻辑视图名，选择相应的视图进行渲染，并把模型数据传入以便视图渲染；图2-1中的步骤6、7；
4、 前端控制器再次收回控制权，将响应返回给用户，图2-1中的步骤8；至此整个结束。
二、Spring
2.1、IOC容器：
IOC容器就是具有依赖注入功能的容器，IOC容器负责实例化、定位、配置应用程序中的对象及建立这些对象间的依赖。应用程序无需直接在代码中new相关的对象，应用程序由IOC容器进行组装。在Spring中BeanFactory是IOC容器的实际代表者。
2.2、AOP：
简单地说，就是将那些与业务无关，却为业务模块所共同调用的逻辑或责任封装起来，便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可操作性和可维护性。AOP代表的是一个横向的关系
AOP用来封装横切关注点，具体可以在下面的场景中使用:
Authentication 权限
Caching 缓存
Context passing 内容传递
Error handling 错误处理
Lazy loading 懒加载
Debugging调试
logging, tracing, profiling and monitoring 记录跟踪 优化 校准
Performance optimization 性能优化
Persistence持久化
Resource pooling 资源池
Synchronization 同步
Transactions 事务
三、Mybatis
MyBatis 是支持普通 SQL查询，存储过程和高级映射的优秀持久层框架。MyBatis 消除了几乎所有的JDBC代码和参数的手工设置以及结果集的检索。MyBatis 使用简单的 XML或注解用于配置和原始映射，将接口和 Java 的POJOs（Plain Old Java Objects，普通的 Java对象）映射成数据库中的记录。
总体流程：
(1)加载配置并初始化
触发条件：加载配置文件
将SQL的配置信息加载成为一个个MappedStatement对象（包括了传入参数映射配置、执行的SQL语句、结果映射配置），存储在内存中。
(2)接收调用请求
触发条件：调用Mybatis提供的API
传入参数：为SQL的ID和传入参数对象
处理过程：将请求传递给下层的请求处理层进行处理。
(3)处理操作请求 触发条件：API接口层传递请求过来
传入参数：为SQL的ID和传入参数对象
处理过程：
(A)根据SQL的ID查找对应的MappedStatement对象。
(B)根据传入参数对象解析MappedStatement对象，得到最终要执行的SQL和执行传入参数。
(C)获取数据库连接，根据得到的最终SQL语句和执行传入参数到数据库执行，并得到执行结果。
(D)根据MappedStatement对象中的结果映射配置对得到的执行结果进行转换处理，并得到最终的处理结果。
(E)释放连接资源。
(4)返回处理结果将最终的处理结果返回。
MyBatis 最强大的特性之一就是它的动态语句功能。如果您以前有使用JDBC或者类似框架的经历，您就会明白把SQL语句条件连接在一起是多么的痛苦，要确保不能忘记空格或者不要在columns列后面省略一个逗号等。动态语句能够完全解决掉这些痛苦。
四、Dubbo
Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC（远程过程调用协议）远程服务调用方案，以及SOA服务治理方案。简单的说，dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架。
1、透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。
2、软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。
3、 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。
节点角色说明：
Provider: 暴露服务的服务提供方。
Consumer: 调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心。
Monitor: 统计服务的调用次调和调用时间的监控中心。
Container: 服务运行容器。
五、Maven
Maven这个个项目管理和构建自动化工具，越来越多的开发人员使用它来管理项目中的jar包。但是对于我们程序员来说，我们最关心的是它的项目构建功能。
六、RabbitMQ
消息队列一般是在项目中，将一些无需即时返回且耗时的操作提取出来，进行了异步处理，而这种异步处理的方式大大的节省了服务器的请求响应时间，从而提高了系统的吞吐量。
RabbitMQ是用Erlang实现的一个高并发高可靠AMQP消息队列服务器。
Erlang是一门动态类型的函数式编程语言。对应到Erlang里，每个Actor对应着一个Erlang进程，进程之间通过消息传递进行通信。相比共享内存，进程间通过消息传递来通信带来的直接好处就是消除了直接的锁开销(不考虑Erlang虚拟机底层实现中的锁应用)。
AMQP(Advanced Message Queue Protocol)定义了一种消息系统规范。这个规范描述了在一个分布式的系统中各个子系统如何通过消息交互。
七、Log4j
日志记录的优先级，分为OFF、FATAL、ERROR、WARN、INFO、DEBUG、ALL或者您定义的级别。
八、Ehcache
EhCache 是一个纯Java的进程内缓存框架，具有快速、精干等特点，是Hibernate中默认的CacheProvider。Ehcache是一种广泛使用的开源Java分布式缓存。主要面向通用缓存,Java EE和轻量级容器。它具有内存和磁盘存储，缓存加载器,缓存扩展，缓存异常处理程序，一个gzip缓存servlet过滤器，支持REST和SOAP api等特点。
优点：
1、 快速
2、 简单
3、 多种缓存策略
4、缓存数据有两级：内存和磁盘，因此无需担心容量问题
5、 缓存数据会在虚拟机重启的过程中写入磁盘
6、可以通过RMI、可插入API等方式进行分布式缓存
7、 具有缓存和缓存管理器的侦听接口
8、支持多缓存管理器实例，以及一个实例的多个缓存区域
9、提供Hibernate的缓存实现
缺点：
1、使用磁盘Cache的时候非常占用磁盘空间：这是因为DiskCache的算法简单，该算法简单也导致Cache的效率非常高。它只是对元素直接追加存储。因此搜索元素的时候非常的快。如果使用DiskCache的，在很频繁的应用中，很快磁盘会满。
2、 不能保证数据的安全：当突然kill掉java的时候，可能会产生冲突，EhCache的解决方法是如果文件冲突了，则重建cache。这对于Cache数据需要保存的时候可能不利。当然，Cache只是简单的加速，而不能保证数据的安全。如果想保证数据的存储安全，可以使用Bekeley DB Java Edition版本。这是个嵌入式数据库。可以确保存储安全和空间的利用率。
九、Redis
redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set –有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。
Redis数据库完全在内存中，使用磁盘仅用于持久性。相比许多键值数据存储，Redis拥有一套较为丰富的数据类型。Redis可以将数据复制到任意数量的从服务器。
1.2、Redis优点：
（1）异常快速：Redis的速度非常快，每秒能执行约11万集合，每秒约81000+条记录。
（2）支持丰富的数据类型：Redis支持最大多数开发人员已经知道像列表，集合，有序集合，散列数据类型。这使得它非常容易解决各种各样的问题，因为我们知道哪些问题是可以处理通过它的数据类型更好。
（3）操作都是原子性：所有Redis操作是原子的，这保证了如果两个客户端同时访问的Redis服务器将获得更新后的值。
（4）多功能实用工具：Redis是一个多实用的工具，可以在多个用例如缓存，消息，队列使用(Redis原生支持发布/订阅)，任何短暂的数据，应用程序，如Web应用程序会话，网页命中计数等。
1.3、Redis缺点：
（1）单线程
（2）耗内存
十、Shiro
Apache Shiro是Java的一个安全框架，旨在简化身份验证和授权。Shiro在JavaSE和JavaEE项目中都可以使用。它主要用来处理身份认证，授权，企业会话管理和加密等。Shiro的具体功能点如下：
（1）身份认证/登录，验证用户是不是拥有相应的身份；
（2）授权，即权限验证，验证某个已认证的用户是否拥有某个权限；即判断用户是否能做事情，常见的如：验证某个用户是否拥有某个角色。或者细粒度的验证某个用户对某个资源是否具有某个权限；
（3）会话管理，即用户登录后就是一次会话，在没有退出之前，它的所有信息都在会话中；会话可以是普通JavaSE环境的，也可以是如Web环境的；
（4）加密，保护数据的安全性，如密码加密存储到数据库，而不是明文存储；
（5）Web支持，可以非常容易的集成到Web环境；
Caching：缓存，比如用户登录后，其用户信息、拥有的角色/权限不必每次去查，这样可以提高效率；
（6）shiro支持多线程应用的并发验证，即如在一个线程中开启另一个线程，能把权限自动传播过去；
（7）提供测试支持；
（8）允许一个用户假装为另一个用户（如果他们允许）的身份进行访问；
（9）记住我，这个是非常常见的功能，即一次登录后，下次再来的话不用登录了。
redis集群角色切换java调用异常
redis集群角色切换java调用异常
一、Redis状态检查
唯一标记一个redis实例的是ip和端口，前端是用tcp方式来访问redis的，我们提供给应用访问的是一个ip+63379(一般使用63379) 端口。因此我们执行如下命令检查redis状态:
上面的role这个值一定是master的，只要保证vip在master上我们的Padis cache服务就是没有问题的，如果不通或者role的角色是slave，那就得继续查看是什么问题.
二、两个redis的角色都是slave的问题
当两个主机都挂了或者我们自己不小心将两个redis停了，并且我们用下面的命令检查
/wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} info replication
发现无论是vip还是另外的两个ip都是role:slave 的角色，这个时候需要对vip所在的主机执行slaveof no one 的操作,将vip 所在的redis变成master,如:
/wls/wls81/redis/bin/redis-cli -h {vip} -p {port} -a {password} slaveof no one
三、sentinel的配置参数
我们的sentinel 配置文件里面有两个重要的配置
sentinel monitor pds_jks-core-prd 10.33.94.65 63379 1 -----------配置的ip和端口任何时候都需要是master的ip端口,切换的时候程序自动会改 。另外，红色所示部分pds_jks-core-prd为redis对外提供的主机名，一般Jedis在调用redis时会用到此名称。如果配置多个哨兵则一般要求此名称唯一标识
sentinel down-after-milliseconds pds_jks-core-prd 15000 ----------这个是sentinel连接master的超时时间，超过这个时间就认为master挂了，实现自动切换。这个默认是30秒，这个时间得调节好，大了会在真正出现故障的时候切换时间会长，小了有时候master由于持久化数据，繁忙不响应，会导致自动切换，实际只是瞬间不可用，现在认为设置为15秒为宜.
四、AOF日志
这个日志记录了每一个写入命令或者删除命令的，这个对于我们审计功能是有用的，由于占用很多磁盘，默认我们是关闭的
如果开启会生成一个.aof的文件在data文件中. 如: /wls/apache/servers/pds_jks-core-prd/data
在redis运行中中开启：
/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} config set appendonly yes
开启了可以查看日志，记录每一个命令，如有必要可以开启查完问题后关闭. 同时说明一下
/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} config set 可以在redis运行的时候设置多个它的参数
五、空闲连接的timeout
redis服务端不会自动断开客户端来的连接，redis服务端有设置客户端空闲连接超时时间，可用命令
/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} config get timeout
查看当前timeout时间，默认是0，就是不断开空闲的连接，如果不断开空闲的连接，就会造成redis连接过多
所以一般情况下可以设置为3600秒:
/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} config set timeout 3600
也就是3600秒后将空闲的连接关闭掉. 可以用下面的命令查看某个连接空闲了多久:
/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} client list
六、监控redis执行的命令
/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} monitor
上述这个monitor命令可以查看redis执行了什么命令，有时候查问题很有必要用到，我们可以知道那段时间redis执行了什么，从而进行我们的问题诊断。
七、key的查找与执行
/wls/wls81/redis-icore/bin/redis-cli -h {ip} -p {port} -a {password} keys "*"
keys这个命令查找所有的key，但是最好慎用，因为它很耗redis的性能，每个key都遍历一遍. 也可以进行模糊匹配如： keys "send*"
千万记住在生产环境上不能随便乱用，因为它会将redis性能耗尽，导致其他连接获取不到响应.
/wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} dbsize
dbsize 这个命令可以看到整一个redis里面有多少个key，当然和keys "*" | wc -l结果是一样的。
当我们需要批量删除key值时可以用如下命令即可:
/wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} keys "send*" | xargs /wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} del
我们需要将整个db都flush掉可以用:
/wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} -a MamcCorePrd flushdb
/wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} -a flushall
八、由于连接redis的客户端使用jedisPool
如果设置了
redis.pool.testOnBorrow.REL=true
redis.pool.testOnReturn.REL=true
这两个参数是说在或者pool中的连接和返回连接给pool的时候都需要检查一下连接的有用性，也就是ping一下这个redis是不是好的，
这样在高并发的时候，由于并发线程太多，ping操作相对线程启动来说很慢，因此，应用会堵在类似如下线程dump的地方
"[ACTIVE] ExecuteThread: '19' for queue: 'weblogic.kernel.Default (self-tuning)'" id=33 idx=0x9c tid=273669 prio=5 alive, native_blocked, daemon
at jrockit/net/SocketNativeIO.readBytesPinned(Ljava/io/FileDescriptor;[BIII)I(Native Method)
at jrockit/net/SocketNativeIO.socketRead(SocketNativeIO.java:32)
at java/net/SocketInputStream.socketRead0(Ljava/io/FileDescriptor;[BIII)I(SocketInputStream.java)
at java/net/SocketInputStream.read(SocketInputStream.java:129)
at java/net/SocketInputStream.read(SocketInputStream.java:90)
at redis/clients/util/RedisInputStream.fill(RedisInputStream.java:109)
at redis/clients/util/RedisInputStream.readByte(RedisInputStream.java:45)
at redis/clients/jedis/Protocol.process(Protocol.java:64)
at redis/clients/jedis/Protocol.read(Protocol.java:131)
at redis/clients/jedis/Jedis.ping(Jedis.java:35)
at redis/clients/jedis/JedisPool$JedisFactory.validateObject(JedisPool.java:104)
at org/apache/commons/pool/impl/GenericObjectPool.addObjectToPool(GenericObjectPool.java:922)
at org/apache/commons/pool/impl/GenericObjectPool.returnObject(GenericObjectPool.java:917)
^-- Holding lock: org/apache/commons/pool/impl/GenericObjectPool@0xb8513338[fat lock]
at redis/clients/util/Pool.returnResourceObject(Pool.java:29)
at redis/clients/util/Pool.returnResource(Pool.java:41)
at com/paic/icore/mams/common/jedis/util/RedisPoolCacheTools.release(RedisPoolCacheTools.java:43)
虽然后面会自动恢复，不过导致应用响应缓慢.解决方法是将该两个参数设置为false，并且定期检查：
testOnBorrow.REL=false
testOnReturn.REL=false
timeBetweenEvictionRunsMillis=60000 -------每隔60秒定期检查空闲连接
minEvictableIdleTimeMillis=120000 ---------连接在池中保持空闲而不被空闲连接回收器线程回收的最小时间值,单位毫秒
numTestsPerEvictionRun=-1 ----------空闲连接扫描时，每次最多扫描的连接数,一般设置为-1，全部扫描
设置成这样之后就不用每次都测试了，这样就提高了应用的性能
有时候由于持久化导致master变得缓慢，所以建议关闭master的持久化，让slave持久化
关闭持久化 /wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} config set save ""
开通持久化 /wls/wls81/redis/bin/redis-cli -h {ip} -p {port} -a {password} config set save "900 1 300 10 60 10000"
关闭持久化后如果发生主备切换了，请将master的持久化关闭，slave的持久化开启
九、查询每秒执行的命令个数
十、单位时间内Redis执行的命令次数
jenkins通过Java web start来启动slave时一直出现超时的错误
点击：开始→运行→cmd→复制/粘贴以下命令（可以每次一条也可以全部复制粘贴进去）
netsh winsock reset
regsvr32 Mshtml.dll
regsvr32 Urlmon.dll
regsvr32 Msjava.dll
regsvr32 Browseui.dll
regsvr32 Oleaut32.dll
regsvr32 Shell32.dll
regsvr32 jscript.dll
regsvr32 vbscript.dll
regsvr32 Shdocvw.dll
regsvr32 Actxprxy.dll
跳出的10个提示点→确定→然后重新启动计算机。
快速修复浏览器方案(鉴于系统环境不同→请活学活用以下方法→根据具体情况决定做哪些→并非都做到)
1、打开浏览器，点“工具”→“管理加载项”那里禁用所有可疑插件,或者你能准确知道没问题的保留。然后→工具→INTERNET选项→常规页面→删除cookies→删除文件→钩选删除所有脱机内容→确定→设置使用的磁盘空间为：8MB或以下(我自己使用1MB)→确定→清除历史纪录→网页保存在历史记录中的天数：3以下→应用确定（我自己使用的设置是0天）。
2、还原浏览器高级设置默认值：工具→INTERNET选项→高级→还原默认设置。
3、恢复默认浏览器的方法“工具”→Internet选项→程序→最下面有个“检查Internet Explorer是否为默认的浏览器”把前面的钩选上,确定。
4、设置主页：“工具”→Internet选项→常规→可以更改主页地址→键入你喜欢的常用网址→应用。
5、如果浏览器中毒就使用卡卡助手4.0版本修复,然后做插件免疫：全部钩选→免疫。然后→全部去掉钩选→找到“必备”一项，把能用到的插件重新钩选→取消免疫。能用到的就是FLASH和几种播放器的，其余的不要取消免疫。完成所有操作以后，你的浏览器就不会出问题了 。
6、运行→regedit→进入注册表, 在→
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellExecuteHooks
这个位置有一个正常的键值{AEB6717E-7E19-11d0-97EE-00C04FD91972}, 将其他的删除（默认项也保留无法删除）。
7、检查你的浏览器是否被某种（游戏或其它）安装程序恶意附加了某种插件→卸载清理掉它。
java里测试添加的命令语句是什么
ava性能调试命令
java性能调试命令_性能测试--十个命令迅速发现性能问题
投机启示录
原创
关注
0点赞·85人阅读
十个命令迅速发现性能问题
uptime
dmesg | tail
vmstat 1
mpstat -P ALL 1
pidstat 1
iostat -xz 1
free -m
sar -n DEV 1
sar -n TCP,ETCP 1
top
1. uptime
$ uptime
23:51:26 up 21:31, 1 user, load average: 30.02, 26.43, 19.02
这是一种用来快速查看系统平均负载的方法，它表明了系统中有多少要运行的任务(进程)。在 Linux 系统中，这些数字包含了需要在 CPU 中运行的进程以及正在等待 I/O(通常是磁盘 I/O)的进程。它仅仅是对系统负载的一个粗略展示，稍微看下即可。你还需要其他工具来进一步了解具体情况。
这三个数字展示的是一分钟、五分钟和十五分钟内系统的负载总量平均值按照指数比例压缩得到的结果。从中我们可以看到系统的负载是如何随时间变化的。比方你在检查一个问题，然后看到 1 分钟对应的值远小于 15 分钟的值，那么可能说明这个问题已经过去了，你没能及时观察到。
在上面这个例子中，系统负载在随着时间增加，因为最近一分钟的负载值超过了 30，而 15 分钟的平均负载则只有 19。这样显著的差距包含了很多含义，比方 CPU 负载。若要进一步确认的话，则要运行 vmstat 或 mpstat 命令。
2. dmesg | tail
$ dmesg | tail
[1880957.563150] perl invoked oom-killer: gfp_mask=0x280da, order=0, oom_score_adj=0
[...]
[1880957.563400] Out of memory: Kill process 18694 (perl) score 246 or sacrifice child
[1880957.563408] Killed process 18694 (perl) total-vm:1972392kB, anon-rss:1953348kB, file-rss:0kB
[2320864.954447] TCP: Possible SYN flooding on port 7001. Dropping request. Check SNMP counters.
这条命令显式了最近的 10 条系统消息，如果它们存在的话。查找能够导致性能问题的错误。上面的例子包含了 oom-killer，以及 TCP 丢弃一个请求。
千万不要错过这一步！dmesg 命令永远值得一试
3. vmstat 1
$ vmstat 1
procs ---------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
34 0 0 200889792 73708 591828 0 0 0 5 6 10 96 1 3 0 0
32 0 0 200889920 73708 591860 0 0 0 592 13284 4282 98 1 1 0 0
32 0 0 200890112 73708 591860 0 0 0 0 9501 2154 99 1 0 0 0
32 0 0 200889568 73712 591856 0 0 0 48 11900 2459 99 0 0 0 0
32 0 0 200890208 73712 591860 0 0 0 0 15898 4840 98 1 1 0 0
vmstat(8) 是虚拟内存统计的简称，其是一个常用工具(几十年前为了 BSD 所创建)。其在每行打印一条关键的服务器的统计摘要。
vmstat 命令指定一个参数 1 运行，来打印每一秒的统计摘要。(这个版本的 vmstat)输出的第一行的那些列，显式的是开机以来的平均值，而不是前一秒的值。现在，我们跳过第一行，除非你想要了解并记住每一列。
检查这些列：
r：CPU 中正在运行和等待运行的进程的数量。其提供了一个比平均负载更好的信号来确定 CPU 是否饱和，因为其不包含 I/O。解释：“r”的值大于了 CPU 的数量就表示已经饱和了。
free：以 kb 为单位显式的空闲内存。如果数字位数很多，说明你有足够的空闲内存。“free -m” 命令，是下面的第七个命令，其可以更好的说明空闲内存的状态。
si, so：Swap-ins 和 swap-outs。如果它们不是零，则代表你的内存不足了。
us, sy, id, wa, st：这些都是平均了所有 CPU 的 CPU 分解时间。它们分别是用户时间(user)、系统时间(内核)(system)、空闲(idle)、等待 I/O(wait)、以及占用时间(stolen)(被其他访客，或使用 Xen，访客自己独立的驱动域)。
CPU 分解时间将会通过用户时间加系统时间确认 CPU 是否为忙碌状态。等待 I/O 的时间一直不变则表明了一个磁盘瓶颈；这就是 CPU 的闲置，因为任务都阻塞在等待挂起磁盘 I/O 上了。你可以把等待 I/O 当成是 CPU 闲置的另一种形式，其给出了为什么 CPU 闲置的一个线索。
对于 I/O 处理来说，系统时间是很重要的。一个高于 20% 的平均系统时间，可以值得进一步的探讨：也许内核在处理 I/O 时效率太低了。
在上面的例子中，CPU 时间几乎完全花在了用户级，表明应用程序占用了太多 CPU 时间。而 CPU 的平均使用率也在 90% 以上。这不一定是一个问题；检查一下“r”列中的饱和度。
4. mpstat -P ALL 1
$ mpstat -P ALL 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
07:38:49 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
07:38:50 PM all 98.47 0.00 0.75 0.00 0.00 0.00 0.00 0.00 0.00 0.78
07:38:50 PM 0 96.04 0.00 2.97 0.00 0.00 0.00 0.00 0.00 0.00 0.99
07:38:50 PM 1 97.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 2.00
07:38:50 PM 2 98.00 0.00 1.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00
07:38:50 PM 3 96.97 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 3.03
[...]
这个命令打印每个 CPU 的 CPU 分解时间，其可用于对一个不均衡的使用情况进行检查。一个单独 CPU 很忙碌则代表了正在运行一个单线程的应用程序。
5. pidstat 1
$ pidstat 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
07:41:02 PM UID PID %usr %system %guest %CPU CPU Command
07:41:03 PM 0 9 0.00 0.94 0.00 0.94 1 rcuos/0
07:41:03 PM 0 4214 5.66 5.66 0.00 11.32 15 mesos-slave
07:41:03 PM 0 4354 0.94 0.94 0.00 1.89 8 java
07:41:03 PM 0 6521 1596.23 1.89 0.00 1598.11 27 java
07:41:03 PM 0 6564 1571.70 7.55 0.00 1579.25 28 java
07:41:03 PM 60004 60154 0.94 4.72 0.00 5.66 9 pidstat
07:41:03 PM UID PID %usr %system %guest %CPU CPU Command
07:41:04 PM 0 4214 6.00 2.00 0.00 8.00 15 mesos-slave
07:41:04 PM 0 6521 1590.00 1.00 0.00 1591.00 27 java
07:41:04 PM 0 6564 1573.00 10.00 0.00 1583.00 28 java
07:41:04 PM 108 6718 1.00 0.00 0.00 1.00 0 snmp-pass
07:41:04 PM 60004 60154 1.00 4.00 0.00 5.00 9 pidstat
pidstat 命令有点像 top 命令对每个进程的统计摘要，但循环打印一个滚动的统计摘要来代替 top 的刷屏。其可用于实时查看，同时也可将你所看到的东西(复制粘贴)到你的调查记录中。
上面的例子表明两个 Java 进程正在消耗 CPU。%CPU 这列是所有 CPU 合计的；1591% 表示这个 Java 进程消耗了将近 16 个 CPU。
6. iostat -xz 1
$ iostat -xz 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
73.96 0.00 3.73 0.03 0.06 22.21
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
xvda 0.00 0.23 0.21 0.18 4.52 2.08 34.37 0.00 9.98 13.80 5.42 2.44 0.09
xvdb 0.01 0.00 1.02 8.94 127.97 598.53 145.79 0.00 0.43 1.78 0.28 0.25 0.25
xvdc 0.01 0.00 1.02 8.86 127.79 595.94 146.50 0.00 0.45 1.82 0.30 0.27 0.26
dm-0 0.00 0.00 0.69 2.32 10.47 31.69 28.01 0.01 3.23 0.71 3.98 0.13 0.04
dm-1 0.00 0.00 0.00 0.94 0.01 3.78 8.00 0.33 345.84 0.04 346.81 0.01 0.00
dm-2 0.00 0.00 0.09 0.07 1.35 0.36 22.50 0.00 2.55 0.23 5.62 1.78 0.03
[...]
这是用于查看块设备(磁盘)情况的一个很棒的工具，无论是对工作负载还是性能表现来说。查看个列：
r/s, w/s, rkB/s, wkB/s：这些分别代表该设备每秒的读次数、写次数、读取 kb 数，和写入 kb 数。这些用于描述工作负载。性能问题可能仅仅是由于施加了过大的负载。
await：以毫秒为单位的 I/O 平均消耗时间。这是应用程序消耗的实际时间，因为它包括了排队时间和处理时间。比预期更大的平均时间可能意味着设备的饱和，或设备出了问题。
avgqu-sz：向设备发出的请求的平均数量。值大于 1 说明已经饱和了(虽说设备可以并行处理请求，尤其是由多个磁盘组成的虚拟设备。)
%util：设备利用率。这个值是一个显示出该设备在工作时每秒处于忙碌状态的百分比。若值大于 60％，通常表明性能不佳(可以从 await 中看出)，虽然它取决于设备本身。值接近 100% 通常意味着已饱和。
如果该存储设备是一个面向很多后端磁盘的逻辑磁盘设备，则 100% 利用率可能只是意味着当前正在处理某些 I/O 占用，然而，后端磁盘可能远未饱和，并且可能能够处理更多的工作。
请记住，磁盘 I/O 性能较差不一定是程序的问题。许多技术通常是异步 I/O，使应用程序不会被阻塞并遭受延迟(例如，预读，以及写缓冲)。
7. free -m
$ free -m
total used free shared buffers cached
Mem: 245998 24545 221453 83 59 541
-/+ buffers/cache: 23944 222053
Swap: 0 0 0
右边的两列显式：
buffers：用于块设备 I/O 的缓冲区缓存。
cached：用于文件系统的页面缓存。
我们只是想要检查这些不接近零的大小，其可能会导致更高磁盘 I/O(使用 iostat 确认)，和更糟糕的性能。上面的例子看起来还不错，每一列均有很多 M 个大小。
比起第一行，-/+ buffers/cache 提供的内存使用量会更加准确些。Linux 会把暂时用不上的内存用作缓存，一旦应用需要的时候就立刻重新分配给它。所以部分被用作缓存的内存其实也算是空闲的内存。为了解释这一点， 甚至有人专门建了个网站： linuxatemyram。
如果你在 Linux 上安装了 ZFS，这一点会变得更加困惑，因为 ZFS 它自己的文件系统缓存不算入free -m。有时候发现系统已经没有多少空闲内存可用了，其实内存却都待在 ZFS 的缓存里。
8. sar -n DEV 1
$ sar -n DEV 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
12:16:48 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
12:16:49 AM eth0 18763.00 5032.00 20686.42 478.30 0.00 0.00 0.00 0.00
12:16:49 AM lo 14.00 14.00 1.36 1.36 0.00 0.00 0.00 0.00
12:16:49 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
12:16:49 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
12:16:50 AM eth0 19763.00 5101.00 21999.10 482.56 0.00 0.00 0.00 0.00
12:16:50 AM lo 20.00 20.00 3.25 3.25 0.00 0.00 0.00 0.00
12:16:50 AM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
这个工具可以被用来检查网络接口的吞吐量：rxkB/s 和 txkB/s，以及是否达到限额。上面的例子中，eth0 接收的流量达到 22Mbytes/s，也即 176Mbits/sec(限额是 1Gbit/sec)
我们用的版本中还提供了 %ifutil 作为设备使用率(接收和发送的最大值)的指标。我们也可以用 Brendan 的 nicstat 工具计量这个值。一如 nicstat，sar 显示的这个值是很难精确取得的，在这个例子里面，它就没在正常的工作(0.00)。
9. sar -n TCP,ETCP 1
$ sar -n TCP,ETCP 1
Linux 3.13.0-49-generic (titanclusters-xxxxx) 07/14/2015 _x86_64_ (32 CPU)
12:17:19 AM active/s passive/s iseg/s oseg/s
12:17:20 AM 1.00 0.00 10233.00 18846.00
12:17:19 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
12:17:20 AM 0.00 0.00 0.00 0.00 0.00
12:17:20 AM active/s passive/s iseg/s oseg/s
12:17:21 AM 1.00 0.00 8359.00 6039.00
12:17:20 AM atmptf/s estres/s retrans/s isegerr/s orsts/s
12:17:21 AM 0.00 0.00 0.00 0.00 0.00
这是一些关键的 TCP 指标的汇总视图。这些包括：
active/s：每秒本地发起 TCP 连接数(例如，通过 connect())。
passive/s：每秒远程发起的 TCP 连接数(例如，通过 accept())。
retrans/s：每秒重传 TCP 次数。
active 和 passive 的连接数往往对于描述一个粗略衡量服务器负载是非常有用的：新接受的连接数(passive)，下行连接数(active)。可以理解为 active 连接是对外的，而 passive 连接是对内的，虽然严格来说并不完全正确(例如，一个 localhost 到 localhost 的连接)。
重传是出现一个网络和服务器问题的一个征兆。其可能是由于一个不可靠的网络(例如，公网)造成的，或许也有可能是由于服务器过载并丢包。上面的例子显示了每秒只有一个新的 TCP 连接。
10. top
$ top
top - 00:15:40 up 21:56, 1 user, load average: 31.09, 29.87, 29.92
Tasks: 871 total, 1 running, 868 sleeping, 0 stopped, 2 zombie
%Cpu(s): 96.8 us, 0.4 sy, 0.0 ni, 2.7 id, 0.1 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 25190241+total, 24921688 used, 22698073+free, 60448 buffers
KiB Swap: 0 total, 0 used, 0 free. 554208 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20248 root 20 0 0.227t 0.012t 18748 S 3090 5.2 29812:58 java
4213 root 20 0 2722544 64640 44232 S 23.5 0.0 233:35.37 mesos-slave
66128 titancl+ 20 0 24344 2332 1172 R 1.0 0.0 0:00.07 top
5235 root 20 0 38.227g 547004 49996 S 0.7 0.2 2:02.74 java
4299 root 20 0 20.015g 2.682g 16836 S 0.3 1.1 33:14.42 java
1 root 20 0 33620 2920 1496 S 0.0 0.0 0:03.82 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:05.35 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
6 root 20 0 0 0 0 S 0.0 0.0 0:06.94 kworker/u256:0
8 root 20 0 0 0 0 S 0.0 0.0 2:38.05 rcu_sched
top 命令包含了很多我们之前已经检查过的指标。可以方便的执行它来查看相比于之前的命令输出的结果有很大不同，这表明负载是可变的。
top 的一个缺点是，很难看到数据随时间变动的趋势。vmstat 和 pidstat 提供的滚动输出会更清楚一些。如果你不以足够快的速度暂停输出(Ctrl-S 暂停，Ctrl-Q 继续)，一些间歇性问题的线索也可能由于被清屏而丢失。
java中slave的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于java中M、java中slave的信息别忘了在本站进行查找喔。