apache有几种工作模式，分别简述两种工作模式及其优缺点？
apache主要有两种工作模式：
prefork(apache的默认安装模式)和worker(可以在编译的时候添加--with-mpm=worker选项)
prefork的特点是：(预派生)
1.这种模式可以不必在请求到来时再产生新的进程，从而减小了系统开销
2.可以防止意外的内存泄漏
3.在服务器负载下降的时候会自动减少子进程数
worker的特点是：支持混合的多线程多进程的多路处理模块
如果对于一个高流量的HTTP服务器，worker MPM是一个比较好的选择，因为worker MPM占用的内存要比prefork要小。

有两个int型数组，已排序，判断是否有元素同时存在于a和b中
var arr1 = [1,2,4,5]

var arr2 = [3,4,6,7,8]

function checkOwnSameItem(arr1,arr2) {

    var len1 = arr1.length;
    var len2 = arr2.length;

    var indexA = indexB = 0;

    while (indexA < len1 && indexB < len2) {
    var itemA = arr1[indexA];
    var itemB = arr2[indexB];

    if (itemA == itemB )
    {
        console.log("====find the first same item:"+itemA+",....in arr1 index:"+indexA+",...arr2 index:"+indexB);
        return true ;
    }
    else if(itemA < itemB) {
        indexA ++;
    }
    else
    {
        indexB ++;
    }


    }
}

checkOwnSameItem(arr1,arr2);

前言

动态代理应用非常的广泛，在各种开源的框架中都能看到他们的身影，比如spring中的aop使用动态代理增强，mybatis中使用动态代理生成mapper，动态代理主要有JDK和CGLIB两种方式，今天来学习下这两种方式的实现，以及它们的优缺点

动态代理：是使用反射和字节码的技术，在运行期创建指定接口或类的子类，以及其实例对象的技术，通过这个技术可以无侵入的为代码进行增强

一、JDK实现的动态代理

1、解析

jdk实现的动态代理由两个重要的成员组成，分别是Proxy、InvocationHandler

Proxy：是所有动态代理的父类，它提供了一个静态方法来创建动态代理的class对象和实例

InvocationHandler：每个动态代理实例都有一个关联的InvocationHandler，在代理实例上调用方法是，方法调用将被转发到InvocationHandler的invoke方法

2、简单看下jdk的动态代理的原理图



 3、代码实现

现在模拟一个用户注册的功能，动态代理对用户的注册功能进行增强，会判断用户名和密码的长度，如果用户名<=1和密码<6则会抛出异常

User.java

package com.taolong;

public class User {

	private String name;
	
	private Integer age;
	
	private String password;

	public String getName() {
		return name;
	}

	public void setName(String name) {
		this.name = name;
	}


	public Integer getAge() {
		return age;
	}

	public void setAge(Integer age) {
		this.age = age;
	}

	public String getPassword() {
		return password;
	}

	public void setPassword(String password) {
		this.password = password;
	}

	@Override
	public String toString() {
		return "User [name=" + name + ", age=" + age + ", password=" + password + "]";
	}
	
	
}

 UserService.java

package com.taolong.jdk;

import com.taolong.User;

public interface UserService {
	
	void addUser(User user);
}

 UserServiceImpl.java

package com.taolong.jdk;

import com.taolong.User;

public class UserServiceImpl implements UserService {

	@Override
	public void addUser(User user) {
		System.out.println("jdk...正在注册用户，用户信息为："+user);
	}

}

 UserServiceInterceptor.java

package com.taolong.jdk;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

import com.taolong.User;

public class UserServiceInterceptor implements InvocationHandler {

	private Object realObj;
	
	public UserServiceInterceptor(Object realObject) {
		super();
		this.realObj = realObject;
	}
	
	@Override
	public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
		if (args!=null && args.length > 0 && args[0] instanceof User) {
			User user = (User)args[0];
			//进行增强判断
			if (user.getName().length() <= 1) {
				throw new RuntimeException("用户名长度必须大于1");
			}
			if (user.getPassword().length() <= 6) {
				throw new RuntimeException("密码长度必须大于6");
			}
		}
		Object result = method.invoke(realObj, args);
		System.out.println("用户注册成功...");
		return result;
	}

	public Object getRealObj() {
		return realObj;
	}

	public void setRealObj(Object realObj) {
		this.realObj = realObj;
	}
	
}

 ClientTest.java

package com.taolong.jdk;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Proxy;

import com.taolong.User;

public class ClientTest {

	public static void main(String[] args) {
		User user = new User();
		user.setName("hongtaolong");
		user.setPassword("hong");
		user.setAge(23);
		//被代理类
		UserService delegate = new UserServiceImpl();
		InvocationHandler userServiceInterceptor = new UserServiceInterceptor(delegate);
		//动态代理类
		UserService userServiceProxy = (UserService)Proxy.newProxyInstance(delegate.getClass().getClassLoader(),
				delegate.getClass().getInterfaces(), userServiceInterceptor);
		System.out.println("动态代理类："+userServiceProxy.getClass());
		userServiceProxy.addUser(user);
	}
}

 运行结果：当密码的长度小于6时



这里就起到了动态增强的作用，mybatis的使用中我们知道不需要创建dao中的mapper接口的子类，也能调用到相应的方法，其实就是生成的实现了mapper接口的动态的代理类，我们可以去看看它的这个方法

 

 接下来我们看下cglib的使用

二、CGLIB动态代理

1、解析

CGLIB（Code Generation Library）是一个基于ASM的字节码生成库，它允许我们在运行时对字节码进行修改和动态生成。CGLIB通过继承的方式实现代理（最后这部分我们深思一下，它可能有哪些局限，final方法是不能够被重写，所以它不能增强被final修饰的方法，这个等下我们来验证）

CGLIB的实现也有两个重要的成员组成，Enhancer、MethodInterceptor，其实这两个的使用和jdk实现的动态代理的Proxy、InvocationHandler非常相似

Enhancer：来指定要代理的目标对象，实际处理代理逻辑的对象，最终通过调用create（）方法得到代理对象、对这个对象所有的非final方法的调用都会转发给MethodInterceptor

MethodInterceptor：动态代理对象的方法调用都会转发到intercept方法进行增强

2、图解



3、代码的实现

还是上面的场景，注册用户进行拦截增强，部分代码如下

UserServiceCglibInterceptor.java

package com.taolong.cglib;

import java.lang.reflect.Method;

import com.taolong.User;

import net.sf.cglib.proxy.MethodInterceptor;
import net.sf.cglib.proxy.MethodProxy;

public class UserServiceCglibInterceptor implements MethodInterceptor {

	private Object realObject;
	
	public UserServiceCglibInterceptor(Object realObject) {
		super();
		this.realObject = realObject;
	}
	
	@Override
	public Object intercept(Object object, Method method, Object[] args, MethodProxy proxy) throws Throwable {
		if (args!=null && args.length > 0 && args[0] instanceof User) {
			User user = (User)args[0];
			//进行增强判断
			if (user.getName().length() <= 1) {
				throw new RuntimeException("用户名长度必须大于1");
			}
			if (user.getPassword().length() <= 6) {
				throw new RuntimeException("密码长度必须大于6");
			}
		}
		Object result = method.invoke(realObject, args);
		System.out.println("用户注册成功...");
		return result;
	}

}

 ClientTest.java

package com.taolong.cglib;

import com.taolong.User;

import net.sf.cglib.proxy.Enhancer;

public class ClientTest {

	public static void main(String[] args) {
		User user = new User();
		user.setName("hongtaolong");
		user.setPassword("hong");
		user.setAge(23);
		//被代理的对象
		UserServiceImplCglib delegate = new UserServiceImplCglib();
		UserServiceCglibInterceptor serviceInterceptor = new UserServiceCglibInterceptor(delegate);
		Enhancer enhancer = new Enhancer();
		enhancer.setSuperclass(delegate.getClass());
		enhancer.setCallback(serviceInterceptor);
		//动态代理类
		UserServiceImplCglib cglibProxy = (UserServiceImplCglib)enhancer.create();
		System.out.println("动态代理类父类："+cglibProxy.getClass().getSuperclass());
		cglibProxy.addUser(user);
	}
}

运行结果：

 这里顺便打印了动态代理类的父类，接下来我们将它的父类UserServiceImplCglib的addUser方法用final修饰，看看是否会被增强

UserServiceImplCglib.java

package com.taolong.cglib;

import com.taolong.User;

public class UserServiceImplCglib {

	final void addUser(User  user) {
		System.out.println("cglib...正在注册用户，用户信息为："+user);
	}
}

 运行结果：



 

总结一下

1、JDK原声动态代理时java原声支持的、不需要任何外部依赖、但是它只能基于接口进行代理（因为它已经继承了proxy了，java不支持多继承）

2、CGLIB通过继承的方式进行代理、无论目标对象没有没实现接口都可以代理，但是无法处理final的情况（final修饰的方法不能被覆写）

好了，就暂时先写到这里了，感兴趣的朋友可以具体看一下实现的源码，如有错误欢迎指正，谢谢！

 





 

Redis 持久化之RDB和AOF

Redis 有两种持久化方案，RDB （Redis DataBase）和 AOF （Append Only File）。如果你想快速了解和使用RDB和AOF，可以直接跳到文章底部看总结。本章节通过配置文件，触发快照的方式，恢复数据的操作，命令操作演示，优缺点来学习 Redis 的重点知识持久化。
RDB 详解

RDB 是 Redis 默认的持久化方案。在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载dump.rdb文件恢复数据。
从配置文件了解RDB

打开 redis.conf 文件，找到 SNAPSHOTTING 对应内容

1 RDB核心规则配置（重点）
save  
save “”
save 900 1

save 300 10

save 60 10000

解说：save <指定时间间隔> <执行指定次数更新操作>，满足条件就将内存中的数据同步到硬盘中。官方出厂配置默认是 900秒内有1个更改，300秒内有10个更改以及60秒内有10000个更改，则将内存中的数据快照写入磁盘。

若不想用RDB方案，可以把 save “” 的注释打开，下面三个注释。
2 指定本地数据库文件名，一般采用默认的 dump.rdb
dbfilename dump.rdb

3 指定本地数据库存放目录，一般也用默认配置
dir ./

4 默认开启数据压缩
rdbcompression yes

解说：配置存储至本地数据库时是否压缩数据，默认为yes。Redis采用LZF压缩方式，但占用了一点CPU的时间。若关闭该选项，但会导致数据库文件变的巨大。建议开启。
触发RDB快照

1 在指定的时间间隔内，执行指定次数的写操作

2 执行save（阻塞， 只管保存快照，其他的等待） 或者是bgsave （异步）命令

3 执行flushall 命令，清空数据库所有数据，意义不大。

4 执行shutdown 命令，保证服务器正常关闭且不丢失任何数据，意义…也不大。
通过RDB文件恢复数据

将dump.rdb 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。在实际开发中，一般会考虑到物理机硬盘损坏情况，选择备份dump.rdb 。可以从下面的操作演示中可以体会到。
RDB 的优缺点

优点：

1 适合大规模的数据恢复。

2 如果业务对数据完整性和一致性要求不高，RDB是很好的选择。
缺点：

1 数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。

2 备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。

所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。
操作演示
[root@itdragon bin]# vim redis.conf
save 900 1
save 120 5
save 60 10000
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set key1 value1
OK
127.0.0.1:6379> set key2 value2
OK
127.0.0.1:6379> set key3 value3
OK
127.0.0.1:6379> set key4 value4
OK
127.0.0.1:6379> set key5 value5
OK
127.0.0.1:6379> set key6 value6
OK
127.0.0.1:6379> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# cp dump.rdb dump_bk.rdb
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> FLUSHALL 
OK
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# cp dump_bk.rdb  dump.rdb
cp: overwrite `dump.rdb'? y
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
1) "key5"
2) "key1"
3) "key3"
4) "key4"
5) "key6"
6) "key2"

第一步：vim 修改持久化配置时间，120秒内修改5次则持久化一次。

第二步：重启服务使配置生效。

第三步：分别set 5个key，过两分钟后，在bin的当前目录下会自动生产一个dump.rdb文件。（set key6 是为了验证shutdown有触发RDB快照的作用）

第四步：将当前的dump.rdb 备份一份（模拟线上工作）。

第五步：执行FLUSHALL命令清空数据库数据（模拟数据丢失）。

第六步：重启Redis服务，恢复数据…咦？？？？( ′◔ ‸◔`)。数据是空的？？？？这是因为FLUSHALL也有触发RDB快照的功能。

第七步：将备份的 dump_bk.rdb 替换 dump.rdb 然后重新Redis。
注意点：SHUTDOWN 和 FLUSHALL 命令都会触发RDB快照，这是一个坑，请大家注意。
其他命令：
keys * 匹配数据库中所有 key

save 阻塞触发RDB快照，使其备份数据

FLUSHALL 清空整个 Redis 服务器的数据(几乎不用)

SHUTDOWN 关机走人（很少用）

AOF 详解

AOF ：Redis 默认不开启。它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
从配置文件了解AOF

打开 redis.conf 文件，找到 APPEND ONLY MODE 对应内容

1 redis 默认关闭，开启需要手动把no改为yes
appendonly yes

2 指定本地数据库文件名，默认值为 appendonly.aof
appendfilename "appendonly.aof"

3 指定更新日志条件
# appendfsync always
appendfsync everysec
# appendfsync no

4 配置重写触发机制
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

解说：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。一般都设置为3G，64M太小了。

触发AOF快照

根据配置文件触发，可以是每次执行触发，可以是每秒触发，可以不同步。

根据AOF文件恢复数据

正常情况下，将appendonly.aof 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。但在实际开发中，可能因为某些原因导致appendonly.aof 文件格式异常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复 。从下面的操作演示中体会。

AOF的重写机制

前面也说到了，AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多。所以聪明的 Redis 新增了重写机制。当AOF文件的大小超过所设定的阈值时，Redis就会对AOF文件的内容压缩。
重写的原理：Redis 会fork出一条新进程，读取内存中的数据，并重新写到一个临时文件中。并没有读取旧文件（你都那么大了，我还去读你？？？ o(ﾟДﾟ)っ傻啊！）。最后替换旧的aof文件。
触发机制：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。这里的“一倍”和“64M” 可以通过配置文件修改。

AOF 的优缺点

优点：数据的完整性和一致性更高

缺点：因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。

操作演示
[root@itdragon bin]# vim appendonly.aof
appendonly yes
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set keyAOf valueAof
OK
127.0.0.1:6379> FLUSHALL 
OK
127.0.0.1:6379> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
1) "keyAOf"
127.0.0.1:6379> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# vim appendonly.aof
fjewofjwojfoewifjowejfwf
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected> QUIT
[root@itdragon bin]# redis-check-aof --fix appendonly.aof 
'x              3e: Expected prefix '*', got: '
AOF analyzed: size=92, ok_up_to=62, diff=30
This will shrink the AOF from 92 bytes, with 30 bytes, to 62 bytes
Continue? [y/N]: y
Successfully truncated AOF
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
1) "keyAOf"

第一步：修改配置文件，开启AOF持久化配置。

第二步：重启Redis服务，并进入Redis 自带的客户端中。

第三步：保存值，然后模拟数据丢失，关闭Redis服务。

第四步：重启服务，发现数据恢复了。（额外提一点：有教程显示FLUSHALL 命令会被写入AOF文件中，导致数据恢复失败。我安装的是redis-4.0.2没有遇到这个问题）。

第五步：修改appendonly.aof，模拟文件异常情况。

第六步：重启 Redis 服务失败。这同时也说明了，RDB和AOF可以同时存在，且优先加载AOF文件。

第七步：校验appendonly.aof 文件。重启Redis 服务后正常。
补充点：aof 的校验是通过 redis-check-aof 文件，那么rdb 的校验是不是可以通过 redis-check-rdb 文件呢？？？
--------------------------------------------------------------------------------------------------------------------------------------------------------------------总结

1：Redis 默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。

2：RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。

3：Redis 需要手动开启AOF持久化方式，默认是每秒将写操作日志追加到AOF文件中。

4：AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。

5：Redis 针对 AOF文件大的问题，提供重写的瘦身机制。

6：若只打算用Redis 做缓存，可以关闭持久化。

7：若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份，留一后手。AOF出问题了，还有RDB。

到这里Redis 的持久化就介绍完了，有什么不对的地方可以指出