5. 什么是webservice？Web Service技术， 能使得运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件， 就可相互交换数据或集成。依据WebService规范实施的应用之间， 无论它们所使用的语言、 平台或内部协议是什么， 都可以相互交换数据。Web Service是自描述、 自包含的可用网络模块， 可以执行具体的业务功能。WebService也很容易部署， 因为它们基于一些常规的产业标准以及已有的一些技术，诸如
标准通用标记语言下的子集
XML、HTTP。Web Service减少了应用接口的花费。Web Service为整个企业甚至多个组织之间的业务流程的集成提供了一个通用机制。
一般的情况下是使用cxf这是框架来实现webservice的功能。 在模块之间互相调用 。在开发当中我们经常使用注解的方式来实现cxf，传递的内容也是通过JSON来作为传输的内容。
6. Final,finally,finalize的区别？这三个关键字有些类似，但是作用完全不一致。
一、性质不同
（1）final为关键字；
（2）finalize()为方法；
（3）finally为为区块标志，用于try语句中；
二、作用
（1）final为用于标识常量的关键字，final标识的关键字存储在常量池中（在这里final常量的具体用法将在下面进行介绍）；
（2）finalize()方法在Object中进行了定义，用于在对象“消失”时，由JVM进行调用用于对对象进行垃圾回收，类似于C++中的析构函数；用户自定义时，用于释放对象占用的资源（比如进行I/0操作）；
（3）finally{}用于标识代码块，与try{}进行配合，不论try中的代码执行完或没有执行完（这里指有异常），该代码块之中的程序必定会进行；
三、final详解
1定义变量
1.1 final定义基本类型变量时，要求变量初始化必须在声明时或者构造函数中，不能用于其它地方。该关键字定义的常量，除了初始化阶段，不能更改常量的值。
1.2 final定义对象的引用，该引用的初始化与定义常量时的要求一致；该关键字定义的对象内容可以改变，但是引用指向的地址不能改变；
2定义参数
如果传入该参数定义的变量时，与定义变量的修改规则相同；java方法中传递基本类型时是传值的，java方法对于对象的传递是传参的；<归根结底，java中方法的传递是依靠传递“副本”：对于基本类型，首先建立一个Copy，并将传入的值赋值给Copy，然后对Copy进行操作；对于对象类型，首先建立一个引用Copy，并将传入的对象引用赋值给Copy>
比如：method（final int test）；
有些书上说，这里final定义参数，尤其是对象的参数很有作用，不能在方法内对于对象的内容进行改变，这样的说法是错误的！原来我也认为这样有些函数式编程的特点，不能对于对象的内容进行修改该，这里依旧可以对对象的内容进行修改。
？？定义该参数有什么用？？
String天生就是final类型的！
3定义方法
（1）使用final关键字定义的方法，不能被子类继承；
（2）允许编译器将所有对此方法的调用转化为inline（行内）行为，即可以将此方法直接复制在调用处，而不是进行例行的方法调用（保存断点、压栈），这样会使程序的效率升高。但是---------如果过多的话，这样会造成代码膨胀，反而会影响效率，所以该方法要慎用。。
4定义类
一个任何final类无法被任何人继承，这也就意味着此类在一个继承树中是一个叶子类，并且此类被认为是很完美的，不需要进行任何修改（总之是不推荐使用）
7. Redis的持久化Redis的应用已经是越来越广了，使用起来的技术难度也不高。持久化本身和运维相关了。但是很多公司没有专门的运维，他们需要的程序猿面面具道，不止是会简单的CRUD就行了。 还要能够解决一些突发性的问题。 甚至在架构设计上线的时候给一定的方案。
Redis是一个支持持久化的内存数据库，通过持久化机制把内存中的数据同步到硬盘文件来保证数据持久化。当Redis重启后通过把硬盘文件重新加载到内存，就能达到恢复数据的目的。
RDB
RDB是Redis默认的持久化方式。按照一定的时间周期策略把内存的数据以快照的形式保存到硬盘的二进制文件。即Snapshot快照存储，对应产生的数据文件为dump.rdb，通过配置文件中的save参数来定义快照的周期。
# 快照的文件名
dbfilename dump.rdb
# 存放快照的目录
dir /var/lib/redis
# 在进行镜像备份时,是否进行压缩。
# yes：压缩，但是需要一些cpu的消耗。
# no：不压缩，需要更多的磁盘空间。
rdbcompression yes
#900秒后且至少1个key发生变化时创建快照
save 900 1
#300秒后且至少10个key发生变化时创建快照
save 300 10
#60秒后且至少10000个key发生变化时创建快照
save 60 10000
一旦数据库出现问题，那么我们的RDB文件中保存的数据并不是全新的，从上次RDB文件生成到Redis停机这段时间的数据全部丢掉了。例如，每隔5分钟或者更长的时间来创建一次快照，Redis停止工作时（例如意外断电）就可能丢失最近几分钟的数据。
AOF
Redis会将每一个收到的写命令都通过Write函数追加到文件最后，类似于MySQL的binlog。当Redis重启是会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。
# 是否开启AOF，默认关闭（no）
appendonly yes
由于Linux会把对文件的写入操作通过buffer缓冲，因此Linux可能不是立即写入到文件，有对视数据的风险。Redis有三种不同的fsync策略供选择：no fsync at all、 fsync every second、 fsync at every query。默认为fsync every second此时的写性能仍然很好，且最坏的情况下可能丢失一秒钟的写操作。
# Redis支持三种不同的刷写模式：
#每次收到写命令就立即强制写入磁盘，是最有保证的完全的持久化，但速度也是最慢的，一般不推荐使用。
# appendfsync always
#每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，是受推荐的方式。
appendfsync everysec
#完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不被推荐。
# appendfsync no
AOF带来了另一个问题，持久化文件会变得越来越大。比如，我们调用INCR test命令100次，文件中就必须保存全部的100条命令，但其实99条都是多余的。因为要恢复数据库的状态其实文件中保存一条SET test 100就够了。为了合并重写AOF的持久化文件，Redis提供了bgrewriteaof命令。收到此命令后，Redis将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中，最后替换原来的文件，以此来实现控制AOF文件的合并重写。由于是模拟快照的过程，因此在重写AOF文件时并没有读取旧的AOF文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件。
# AOF文件名
appendfilename appendonly.aof
#当进程中BGSAVE或BGREWRITEAOF命令正在执行时不阻止主进程中的fsync()调用（默认为no，当存在延迟问题时需调整为yes）
no-appendfsync-on-rewrite no
#当AOF增长率为100%且达到了64mb时开始自动重写AOF
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
6666
赞赞赞赞赞赞赞赞
