以下问题均来自网络,答案以及笔记也是自己去查阅总结的,技术能力有限,如有错误,请联系改正
文章中涉及到的图片：
链接：https://pan.baidu.com/s/1BHZ1XcLK0O6Ftf042SLU-A
提取码：xhvd
1、java 初级、中级、高级工程师有什么区别？
技术不同，简单的可以理解为:初级中级的只关注代码，编程。高级的就要考虑系统的架构，整体框架。
一、初级工程师
1、首先要学java的基础知识。不要被新技术迷惑，所谓万变不离其宗，新技术都是基于java的基础之上，如果基础不扎实，对于这些新技术的理解也是一知半解，学不到根源。
2、做一个java项目在学习完java的基础知识之后，做一个java项目来巩固一下，在项目中会发现很多问题，通过解决问题，加深基础知识的掌握。
3、学习数据库的基础知识和开发应用软件开发离不了数据库，掌握几种流行的数据库：Oracle、SQL、server、MySQL等。
4、JEE基础在这里首先要学习网站基础，包括HTML、DHTML、JavaScript；接着要学习XML，XML JAXP；然后学习JEE基础，包括JEE开发环境，RMI/IIOP、JNDI；最后学习JDBC 数据库的应用开发。
5、web开发全面的JEE的web开发知识：Servlet JSP javaBean TagLib，到这里做一个完整的web应用项目开发。
6、EJB开发包含全面的EJB知识：1）EJB入门和无状态会话Bean；2）有状态会话Bean；3）BMP和CMP是实体Bean；4）jms和MessageDrivenBean；5）事物和安全（JTA、JTS和 JAAS）；6）WebService的开发和应用。
7、开源框架的学习学习几种现在流行的开源框架：Struts、Spring、Hibernian、Webwork等。完整的学习这些框架的开发和应用。如果有兴趣还可以学习Ibati框架、AJAX技术 和DWR框架的开发和应用。
8、JEE项目综合应用JEE的知识来开发一个完整的应用。
9、面向对象分析与设计java是一种面向对象的语言，所以要深入学习面向对象的分析与设计，另外还要学习UML统一建模语言。
10、接下来就是系统设计与架构这里要学习的是Java设计模式、EJB设计模式、JEE核心设计模式、JEE应用程序框架设计。
11、软件工程软件工程基本理论知识的学习，还有Rup和极限编程。
12、技术研究学习搜索引擎技术：如Lucene等、工作流技术：包含Shark、JBPM等、SOA架构和应用
13、综合项目实战实现一个企业级的应用。每个阶段在做项目的基础上牢固的掌握应用到的知识，只有在实际的应用中发现问题，加深所学的知识。
二、中级工程师
1、对于Java基础技术体系（包括JVM、类装载机制、多线程并发、IO、网络）有一定的掌握和应用经验。
2、掌握JVM内存分配、JVM垃圾回收；类装载机制； 性能优化； 反射机制；多线程；IO/NIO； 网络编程；常用数据结构和相关算法。
3、对面向对象的软件开发思想有清晰的认识、熟悉掌握常用的设计模式；设计模式；单例模式；工厂模式；代理模式；模板方法模式；责任链模式等。
4、熟练掌握目前流行开源框架(spring/springmvc/ibatis)，并且对其核心思想、实现原理有一定认知；开源框架：spring；hibernate。
5、熟悉Oracle、MySQL等数据库开发与设计以及缓存系统Redis或 Memcached的设计和研发；关系数据库：oracle；PostgreSQL 缓存系统：Redis（Nosql）缓存系统： Memcached。
6、熟悉底层中间件、分布式技术（包括缓存、消息系统、热部署、JMX等）、底层中间件：应用服务器：Jetty(Tomcat)、 消息中间件：ActiveMQ、RabbitMQ、事务处理中间 件：数据访问中间件：ODBC、工作流中间件：JBPM，分布式技术：缓存系统、消息系统、Restful、热部署、JMX。
7、至少一种Java 应用服务器如tomcat、Jetty。
8、精通shell编程，熟练应用awk、sed、grep、strace、tcudump、gdb等常用命令。
9、有大型分布式、高并发、高负载（大数据量）、高可用性系统设计开发经验，分布式：（多节点部署）、高并发、高负载（大数据量）、高稳定、高可用。
10、对配置管理和敏捷研发模式有所了解，配置管理工具：SVN、Github。
11、业务能力：系统升级、双机、部署、容灾、备份恢复、DFX。
12、加分技术：脚本语言：Python，远程调用，精通Internet基本协议（如TCP/IP、HTTP等）内容及相关应用。有一定安全意识并了解常见的安全问题解决方案。熟悉常见的一 些解决方案及其原理：单点登录、分布式缓存、SOA、全文检索、消息中间件，负载均衡、连接池、nosql、流计算等。
三、高级工程师
1、JAVA。要想成为JAVA（高级）工程师肯定要学习JAVA。一般的程序员或许只需知道一些JAVA的语法结构就可以应付了。但要成为JAVA（高级）工程师，您要对JAVA做比较深入 的研究。您应该多研究一下JDBC、IO包、Util包、Text包、JMS、EJB、RMI、线程。如果可能，希望您对JAVA的所有包都浏览一下，知道大概的API，这样您就发现其实您想实 现的很多功能，通过JAVA的API都可以实现了，就不必自己费太多的脑经了。
2、设计模式。其实写代码是很容易的事情，我相信您也有同感。但如何写得好就比较难了。这个“好”字包括代码可重用性，可维护性，可扩展性等。如何写出好的代码往往要借助 一些设计模式。当然长期的代码经验积累，只要您用心，会使您形成自己代码风格。相信您的代码也比较符合代码的可重用性，可维护性，可扩展性。但既然前人已经给我们总 结出了经验，我们何不踩着前人的肩膀前进？
3、XML。现在的系统中不使用XML几乎是不可能的。XML的功能非常强大，它可以做数据转换、做系统的配置、甚至可保存您的系统业务数据。因此您必须了解XML，包括它的语法， 结构。您还需要比较熟练的使用解析XML的一些API，比如JDOM，SAX等，因为在我们一般的项目中，XML往往担当系统配置信息的作用，您需要用这些API解析这些配置信息，开 发完美的项目。
4、精通使用一种或两种框架。“框架都会有许多可重用的代码，良好的层次关系和业务控制逻辑，基于框架的开发使你可以省出很多的开发成本”。但我这里希望您能精通，更多的 是希望您能通过框架的使用了解框架的思想。这样您在开发一个项目时思路会开阔一些，比如您会想到把SQL语句与您的JAVA代码分开，再比如您会考虑把您的业务逻辑配置到 XML或者数据库中，这样整个项目就很容易扩张了。
5、熟悉主流数据库。其实真正比较大的项目都是有人专门做数据库的，但往往很多项目要求作为（高级）工程师的您也参与数据库的设计以及SQL的编写。所以为了更好的为国家做 贡献，建议您还是多了解一些主流数据库，比如SQLSERVER，ORACLE，多连接SQL和存储过程以及触发器。如果您不是“科班”出身，您还需要补充一些数据库原理方面的知识。
6、精通一种或两种WEBServer。我还是要强调您要精通一种或两种。因为作为JAVA工程师，特别时想成为高级JAVA工程师的您，您不可避免地要部署您的项目到WebServer上，而 且只有当您精通一种WebServer，您才可能最大限度地使用它的资源，这往往可以节省很多时间和精力。
7、UML。我知道您肯定想成为高级工程师，因此您有必要了解或熟练或精通UML，这取决于您有多大决心想成为高级工程师和项目经理。在比较正规的开发团队中，UML是讨论项目 的交流工具，您要想做一个软件工程师，您至少要能看懂，您要想做高级工程师，您要能通过它来描述您对项目的理解，尽管这不是必须，但却很重要。
8、站在高度分析问题：这不是一个知识点，也不是通过书本就能学得到的。只所以提到这一点，是因为我比您还着急，我希望您更快的成为一个高级的软件工程师，而不是一个一 般的软件工程师。希望您在工作中多向您的系统分析员、需求分析员、系统设计员学习，多站在他们角度上去看您在开发的项目。在最好在项目之初先在您的脑海里对项目有个大 致的分析、设计，然后和他们进行比较，找找差别，想想缺点。
9、工具。您在这个阶段可能接触到不同的工具了，尽管您还需要使用JB或者IDEA，但能可能对ROSE，Together要多了解一些，因为您要画UML了。不要再对Dreamweaver等HTML 编辑器情有独钟了，那些JSP页面让初级程序员去写吧。
-------------------以下面试题来自网络,答案均是自己查阅而来
2、java基础
1、JAVA中的几种基本数据类型是什么，各自占用多少字节。
第一类：整型
byte(1个字节)
short(2个字节)
int(4个字节)
long(8个字节)
第二类：浮点型
float(4个字节)
double(8个字节)
第三类：布尔型
boolean(它只有两个值可取true false)(1个字节)
第四类：字符型
char(2个字节)
2、String类能被继承吗，为什么。
不能被继承，因为String类有final修饰符，而final修饰的类是不能被继承的。
3、String，Stringbuffer，StringBuilder的区别。
1.String 类不可变，内部维护的char[] 数组长度不可变，为final修饰，String类也是final修饰，不存在扩容。字符串拼接，截取，都会生成一个新的对象。频繁操作字符串效率低下，因为每次都会生成新的对象。
2.StringBuilder 类内部维护可变长度char[] ， 初始化数组容量为16，存在扩容， 其append拼接字符串方法内部调用System的native方法，进行数组的拷贝，不会重新生成新的StringBuilder对象。它是非线程安全的字符串操作类， 其每次调用 toString方法而重新生成的String对象，不会共享StringBuilder对象内部的char[]，会进行一次char[]的copy操作。
3.StringBuffer 类内部维护可变长度char[]， 基本上与StringBuilder一致，但其为线程安全的字符串操作类，大部分方法都采用了Synchronized关键字修饰，以此来实现在多线程下的操作字符串的安全性。其toString方法而重新生成的String对象，会共享StringBuffer对象中的toStringCache属性（char[]），但是每次的StringBuffer对象修改，都会置null该属性值。
String：适用于少量的字符串操作的情况
StringBuilder：适用于单线程下在字符缓冲区进行大量操作的情况
StringBuffer：适用多线程下在字符缓冲区进行大量操作的情况
4、ArrayList和LinkedList有什么区别。
1.ArrayList:底层数据结构是数组结构，线程不安全。所以ArrayList的出现替代了Vector，但是查询的速度很快，增加和删除非常慢。这个是因为ArrayList的增加和删除需要新建立一个数组去实现，就把定义一个新集合，把要增加的元素添加在新集合相应的位置以后，再把原来的旧集合内的元素复制过来，然后再返回新集合的地址，删除和添加的步骤差不多。
2.LinkedList：底层结构是链表数据结构，线程不安全的，同时对元素的增删操作效率很高。LinkedList 采用的将对象存放在独立的空间中，而且在每个空间中还保存下一个链接的索引 但是缺点就是查找非常麻烦 要丛第一个索引开始然后依次向后去查找，直到找到所查找的元素。
使用：
如果查找比较多，建议用ArrayList。
如果增删比较多，建议用LinkedList。
5、讲讲类的实例化顺序，比如父类静态数据，构造函数，字段，子类静态数据，构造函数，字段，当new的候，他们的执行顺序。
父类静态变量、
父类静态代码块、
子类静态变量、
子类静态代码块、
父类非静态变量（父类实例成员变量）、
父类构造函数、
子类非静态变量（子类实例成员变量）、
子类构造函数。
先父后子,先静态,后非静态,然后才是构造函数
先静态、先父后子。 先静态：父静态 > 子静态 。优先级：父类 > 子类 ， 静态代码块 > 非静态代码块 > 构造函数。
6、用过哪些Map类，都有什么区别，HashMap是线程安全的吗,并发下使用的Map是什么，他们内部原理分别是什么，比如存储方式，hashcode，扩容，默认容量等。
HashMap、HashTable、LinkedHashMap和TreeMap。
HashMap 是一个最常用的Map，它根据键的HashCode值存储数据，根据键可以直接获取它的值，具有很快的访问速度。
1.遍历时，取得数据的顺序是完全随机的。
2.HashMap最多只允许一条记录的键为Null；允许多条记录的值为 Null
3.HashMap不支持线程的同步，是非线程安全的，即任一时刻可以有多个线程同时写HashMap，可能会导致数据的不一致。如果需要同步，可以用 Collections和synchronizedMap方法使HashMap具有同步能力，或者使用 ConcurrentHashMap。
Hashtable与 HashMap类似，它继承自Dictionary类，不同的是：
1.它不允许记录的键或者值为空。
2.它支持线程的同步，即任一时刻只有一个线程能写Hashtable，因此也导致了 Hashtable在写入时会比较慢。
LinkedHashMap 保存了记录的插入顺序，在用Iterator遍历LinkedHashMap时，先得到的记录肯定是先插入的。在遍历的时候会比HashMap慢，不过有种情况例外，当HashMap容量很大，实际数据较少时，遍历起来可能会比LinkedHashMap慢，因为LinkedHashMap的遍历速度只和实际数据有关，和容量无关，而HashMap的遍历速度和容量有关。
TreeMap实现SortMap接口，能够把它保存的记录根据键排序，默认是按键值的升序排序，也可以指定排序的比较器，当用Iterator 遍历TreeMap时，得到的记录是排过序的。
区别:
一般情况下，我们用的最多的是HashMap，HashMap里面存入的键值对在取出的时候是随机的，它根据键的HashCode值存储数据，根据键可以直接获取它的值，具有很快的访问速度。在Map中插入、删除和定位元素，HashMap 是最好的选择。
TreeMap取出来的是排序后的键值对。但如果要按自然顺序或自定义顺序遍历键，那么TreeMap会更好。
LinkedHashMap是HashMap的一个子类，如果需要输出的顺序和输入的相同，那么用LinkedHashMap可以实现，它还可以按读取顺序来排列，像连接池中可以应用。
7、JAVA8的ConcurrentHashMap为什么放弃了分段锁，有什么问题吗，如果你来设计，你如何设计。
jdk8 放弃了分段锁而是用了Node锁，减低锁的粒度，提高性能，并使用CAS操作来确保Node的一些操作的原子性，取代了锁。
但是ConcurrentHashMap的一些操作使用了synchronized锁，而不是ReentrantLock, 虽然说jdk8的synchronized的性能进行了优化，但是我觉得还是使用ReentrantLock锁能更多的提高性能
8、有没有有顺序的Map实现类，如果有，他们是怎么保证有序的。
- Map的实现类有LinkedHashMap和TreeMap。
- LinkedHashMap和TreeMap都是有序的（LinkedHashMap记录了添加数据的顺序；TreeMap默认是自然升序）。
- LinkedHashMap底层存储结构是哈希表+链表，链表记录了添加数据的顺序。
- TreeMap底层存储结构是二叉树，二叉树的中序遍历保证了数据的有序性。
9、抽象类和接口的区别，类可以继承多个类么，接口可以继承多个接口么,类可以实现多个接口么,抽象类和接口都是什么时候用
抽象类和接口的区别:
1、抽象类和接口都不能直接实例化，如果要实例化，抽象类变量必须指向实现所有抽象方法的子类对象，接口变量必须指向实现所有接口方法的类对象。
2、抽象类要被子类继承，接口要被类实现。
3、接口只能做方法申明，抽象类中可以做方法申明，也可以做方法实现
4、接口里定义的变量只能是公共的静态的常量，抽象类中的变量是普通变量。
5、抽象类里的抽象方法必须全部被子类所实现，如果子类不能全部实现父类抽象方法，那么该子类只能是抽象类。同样，一个实现接口的时候，如不能全部实现接口方法，那么该类也只能为抽象类。
6、抽象方法只能申明，不能实现。abstract void abc();不能写成abstract void abc(){}。
7、抽象类里可以没有抽象方法
8、如果一个类里有抽象方法，那么这个类只能是抽象类
9、抽象方法要被实现，所以不能是静态的，也不能是私有的。
10、接口可继承接口，并可多继承接口，但类只能单根继承。
类不能继承多个类
接口可以继承多个接口
类可以实现多个接口
**抽象类和接口都是什么时候用
如果要创建一个模型，这个模型将由一些紧密相关的对象采用，就可以使用抽象类。如果要创建将由一些不相关对象采用的功能，就使用接口。
如果必须从多个来源继承行为，就使用接口。
如果知道所有类都会共享一个公共的行为实现，就使用抽象类，并在其中实现该行为。
10、继承和聚合的区别在哪。
继承指的是一个类继承另外的一个类的功能，并可以增加它自己的新功能的能力，继承是类与类或者接口与接口之间最常见的关系；在Java中此类关系通过关键字extends明确标识。
聚合体现的是整体与部分、拥有的关系，此时整体与部分之间是可分离的，他们可以具有各自的生命周期；比如计算机与CPU、公司与员工的关系等；
11、IO模型有哪些，讲讲你理解的nio ，他和bio，aio的区别是啥，谈谈reactor模型。
1、什么是BIO,NIO,AIO
JAVA BIO：同步并阻塞，服务器实现模式为一个连接一个线程，即客户端有连接请求时服务器端就需要启动一个线程并处理，如果这个连接不做任何事情会造成不必要的开销，当然可以通过线程池机制改善
JAVA NIO：同步非阻塞，服务器实现模式为一个请求一个线程，即客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有IO请求时才启动一个线程进行处理
JAVA AIO(NIO2)：异步非阻塞，服务器实现模式为一个有效请求一个线程，客户端的I/O请求都是由OS先完成了再通知服务器应用去启动线程进行处理
2、使用场景
BIO方式适用于连接数目比较小且固定的架构，这种方式对服务器资源要求比较高，并发局限于应用中，JDK1.4以前的唯一选择，但程序直观简单易理解。
NIO方式适用于连接数目多且连接比较短（轻操作）的架构，比如聊天服务器，并发局限于应用中，编程比较复杂，JDK1.4开始支持。
AIO方式使用于连接数目多且连接比较长（重操作）的架构，比如相册服务器，充分调用OS参与并发操作，编程比较复杂，JDK7开始支持。
3、BIO 同步并阻塞
tomcat采用的传统的BIO（同步阻塞IO模型）+线程池模式，对于十万甚至百万连接的时候，传统BIO模型是无能为力的：
①线程的创建和销毁成本很高，在linux中，线程本质就是一个进程，创建销毁都是重量级的系统函数
②线程本身占用较大的内存，像java的线程栈一般至少分配512K-1M的空间，如果系统线程过高，内存占用是个问题
③线程的切换成本高，操作系统发生线程切换的时候，需要保留线程的上下文，然后执行系统调用，如果线程数过高可能执行线程切换的时间甚至大于线程执行的时间，这时候带来的表现是系统load偏高，CPUsy使用率很高
④容易造成锯齿状的系统负载。系统负载是用活动线程数或CPU核心数，一旦线程数量高但外部网络环境不是很稳定，就很容易造成大量请求的结果同时返回，激活大量阻塞线程从而使系统负载压力过大。
4、NIO同步非阻塞
NIO基于Reactor，当socket有流可读或可写入socket，操作系统会相应的通知引用程序进行处理，应用再将流读取到缓冲区或写入操作系统。也就是，不是一个链接就要对应一个处理线程，而是一个有效请求对应一个线程，当连接没有数据时，是没有工作线程来处理的,nio只有acceptor的服务线程是堵塞进行的，其他读写线程是通过注册事件的方式，有读写事件激活时才调用线程资源区执行，不会一直堵塞等着读写操作，Reactor的瓶颈主要在于acceptor的执行，读写事件也是在这一块分发
5、AIO需要一个链接注册读写事件和回调方法，当进行读写操作时，只须直接调用API的read或write方法即可，这两种方法均为异步，对于读操作而言，当有流可读取时，操作系统会将可读的流传入read方法的缓冲区，并通知应用程序；对于写操作而言，当操作系统将write方法传递的流写入完毕时，操作系统主动通知应用程序,即read/write方法都是异步的，完成后会主动调用回调函数
区别:
1.BIO以流的方式处理数据,而NIO以块的方式处理数据,块I/O的效率比流I/O高很多
2.BIO是阻塞的,NIO则是非阻塞的
3.BIO基于字节流和字符流进行操作,而NIO基于channel(通道)和buffer(缓冲区)进行操作,数据总是从通道读取到缓冲区中,或者从缓冲区写入到通道中。selector(选择器)用于监听多个通道的事件(比如:链接请求,数据到达等),因此使用单个线程就可以监听多个客户通道
6、reactor:
是什么:
事件驱动（event handling）,可以处理一个或多个输入源（one or more inputs）,通过Service Handler同步的将输入事件（Event）采用多路复用分发给相应的Request Handler（多个）处理
处理方式:
同步的等待多个事件源到达（采用select()实现）
将事件多路分解以及分配相应的事件服务进行处理，这个分派采用server集中处理（dispatch）
分解的事件以及对应的事件服务应用从分派服务中分离出去（handler）
为什么要用reactor
常见的网络服务中，如果每一个客户端都维持一个与登陆服务器的连接。那么服务器将维护多个和客户端的连接以出来和客户端的contnect 、read、write ，特别是对于长链接的服务，有多少个c端，就需要在s端维护同等的IO连 接。这对服务器来说是一个很大的开销。
12、反射的原理，反射创建类实例的三种方式是什么。
首先我们需要了解java程序运行的过程，该过程包含两个阶段编译期和运行期。首先java代码会通过jdk编译成.class字节码文件，程序运行的时候，jvm会去调用业务逻辑对应需要的字节码文件，生成对应的Class对象，并调用其中的属性方法完成业务逻辑。而java反射则是在运行期时，主动让jvm去加载某个.class文件生成Class对象，并调用其中的方法属性。
jvm中分别有堆、栈、方法区
1.硬盘中存有.class字节码文件
2.将.class字节码加载进方法区中
3.方法区中就存在了类的所有信息(方法,属性,修饰符,注解等)了
4.将方法区中的字节码信息,封装成一个Class对象,放到堆内存中,使用Class.forName("类全名");就可以在堆中创建一个Class对象的引了。注意:该对象由JVM自动创建,不需要开发人员去手动创建。对于同类型的Class对象来说,有且只有一个该Class对象在类加载的时候
5.栈的一个对象引用指向了堆内存中的Class对象的引用
第一种是对象调用getClass方法，即如果传输过来一个Object对象，我并不知道这个类具体是什么类，则可以通过getClass获取该类的信息。
第二种方式：知道类名，直接用类名.class方式获取。此种方式性能最优。
第三种方式：知道类的全限定名，使用Class对象的静态方法forName方法获取，此时会抛出ClassNotFoundException。此种方式在大多数的框架中使用，使用的最多。
13、反射中，Class.forName和ClassLoader区别。
（1）class.forName()除了将类的.class文件加载到jvm中之外，还会对类进行解释，执行类中的static块。当然还可以指定是否执行静态块。
（2）classLoader只干一件事情，就是将.class文件加载到jvm中，不会执行static中的内容,只有在newInstance才会去执行static块。
14、描述动态代理的几种实现方式，分别说出相应的优缺点。
1、定义接口和实现
2、jdk动态代理实现
jdk动态代理是jdk原生就支持的一种代理方式，它的实现原理，就是通过让target类和代理类实现同一接口，代理类持有target对象，来达到方法拦截的作用，这样通过接口的方式有两个弊端，一个是必须保证target类有接口，第二个是如果想要对target类的方法进行代理拦截，那么就要保证这些方法都要在接口中声明，实现上略微有点限制。
3、cglib动态代理实现
Cglib是一个优秀的动态代理框架，它的底层使用ASM在内存中动态的生成被代理类的子类，使用CGLIB即使代理类没有实现任何接口也可以实现动态代理功能。CGLIB具有简单易用，它的运行速度要远远快于JDK的Proxy动态代理：
cglib有两种可选方式，继承和引用。第一种是基于继承实现的动态代理，所以可以直接通过super调用target方法，但是这种方式在spring中是不支持的，因为这样的话，这个target对象就不能被spring所管理，所以cglib还是才用类似jdk的方式，通过持有target对象来达到拦截方法的效果。
速度比较:
//创建代理的速度
Create JDK Proxy: 13 ms
Create CGLIB Proxy: 217 ms //较慢
//运行的速度
Run JDK Proxy: 2224 ms, 634,022 t/s //很慢，jdk生成的字节码考虑了太多的条件，所以字节码非常多，大多都是用不到的
Run CGLIB Proxy: 1123 ms, 1,255,623 t/s //较慢，也是因为字节码稍微多了点
15、动态代理与cglib实现的区别。
java动态代理是利用反射机制生成一个实现代理接口的匿名类，在调用具体方法前调用InvokeHandler来处理。
而cglib动态代理是利用asm开源包，对代理对象类的class文件加载进来，通过修改其字节码生成子类来处理。
1、如果目标对象实现了接口，默认情况下会采用JDK的动态代理实现AOP
2、如果目标对象实现了接口，可以强制使用CGLIB实现AOP
3、如果目标对象没有实现了接口，必须采用CGLIB库，spring会自动在JDK动态代理和CGLIB之间转换
16、为什么CGlib方式可以对接口实现代理。
CGLIB是通过生成java 字节码从而动态的产生代理对象
17、final的用途。
1、被final修饰的类不可以被继承
2、被final修饰的方法不可以被重写
3、被final修饰的变量不可以被改变(被final修饰不可变的是变量的引用，而不是引用指向的内容，引用指向的内容是可以改变的)
拓展：
1、被final修饰的方法，JVM会尝试为之寻求内联，这对于提升Java的效率是非常重要的。因此，假如能确定方法不会被继承，那么尽量将方法定义为final的，具体参见运行期优化技术的方法内联部分
2、被final修饰的常量，在编译阶段会存入调用类的常量池中，具体参见类加载机制最后部分和Java内存区域
18、写出三种单例模式实现。
单例模式：在整个系统的生命周期中，有且只有一个实例。在某些场景下，处于多线程、资源方面的考虑，我们需要限制某个类只能创建一个实例，这是就要使用单例设计模式。
单例设计模式也是spring中应用最广泛的设计模式之一。spring的bean管理提供了一个全局访问的BeanFactory，通过BeanFactory提供一个默认的全局Bean的单例模式，不过没有从构造器级别控制单例，是因为Spring管理的是任意的Java对象。
/**
- 单例模式：饿汉式
- 在类加载时，就创建单例对象
- 执行效率高，但是占空间，以空间换时间
- 线程安全
*/
public class Hungry {
private static final Hungry hungry = new Hungry();
private Hungry(){}
public static Hungry getInstance(){
return hungry;
}
/**
- 单例模式：懒汉式 双重判断
- 对象使用的时候，才去创建
- 有线程安全的风险，需要加锁
*/
public class Lazy1 {
private Lazy1(){}
private static Lazy1 instance = null;
public static Lazy1 getInstance(){
if(instance == null){
synchronized (Lazy1.class){
if(instance == null){
instance = new Lazy1();
}
}
}
return instance;
}
}
/**
*单例模式：懒汉式 静态内部类
- 静态内部类在使用时，才加载
- 此种模式，既是懒加载，又没有加锁影响性能
*/
public class Lazy2 {
private Lazy2(){}
public static final Lazy2 getInstance(){
return LazyLoad.instance;
}
private static class LazyLoad{
private static final Lazy2 instance = new Lazy2();
}
}
/**
- 懒汉式的变种
- spring IOC容器就是使用的这种注册式的单例模式
*/
public class BeanFactory {
public static Map<String,Object> ioc = new ConcurrentHashMap<String,Object>();
public static Object getBean(String className){
if(!ioc.containsKey(className)){
try {
Object instance = Class.forName(className).newInstance();
ioc.put(className, instance);
return instance;
} catch (Exception e) {
e.printStackTrace();
}
}
return ioc.get(className);
}
}
19、如何在父类中为子类自动完成所有的hashcode和equals实现？这么做有何优劣。
父类的equals不一定满足子类的equals需求。比如所有的对象都继承Object，默认使用的是Object的equals方法，在比较两个对象的时候，是看他们是否指向同一个地址。但是我们的需求是对象的某个属性相同，就相等了，而默认的equals方法满足不了当前的需求，所以我们要重写equals方法。
如果重写了equals 方法就必须重写hashcode方法，否则就会降低map等集合的索引速度。
20、请结合OOP设计理念，谈谈访问修饰符public、private、protected、default在应用设计中的作用。
OO设计理念：封装、继承、多态
封装，也就是把客观事物封装成抽象的类，并且类可以把自己的数据和方法只让可信的类或者对象操作，对不可信的进行信息隐藏。所以我们可以通过public、private、protected、default 来进行访问控制
21、深拷贝和浅拷贝区别。
浅拷贝：复制基本类型的属性；引用类型的属性复制，复制栈中的变量 和 变量指向堆内存中的对象的指针，不复制堆内存中的对象。
深拷贝：复制基本类型的属性；引用类型的属性复制，复制栈中的变量 和 变量指向堆内存中的对象的指针和堆内存中的对象。
22、数组和链表数据结构描述，各自的时间复杂度。
数组是将元素在内存中连续存放，由于每个元素占用内存相同，可以通过下标迅速访问数组中任何元素。但是如果要在数组中增加一个元素，需要移动大量元素，在内存中空出一个元素的空间，然后将要增加的元素放在其中。同样的道理，如果想删除一个元素，同样需要移动大量元素去填掉被移动的元素。如果应用需要快速访问数据，很少或不插入和删除元素，就应该用数组。
链表恰好相反，链表中的元素在内存中不是顺序存储的，而是通过存在元素中的指针联系到一起。比如：上一个元素有个指针指到下一个元素，以此类推，直到最后一个元素。如果要访问链表中一个元素，需要从第一个元素开始，一直找到需要的元素位置。但是增加和删除一个元素对于链表数据结构就非常简单了，只要修改元素中的指针就可以了。如果应用需要经常插入和删除元素你就需要用链表数据结构了。
1、从逻辑结构角度来看：
数组必须事先定义固定的长度（元素个数），不能适应数据动态地增减的情况。当数据增加时，可能超出原先定义的元素个数；当数据减少时，造成内存浪费。
链表动态地进行存储分配，可以适应数据动态地增减的情况，且可以方便地插入、删除数据项。（数组中插入、删除数据项时，需要移动其它数据项）
2、数组元素在栈区，链表元素在堆区；
3、从内存存储角度来看：
(静态)数组从栈中分配空间, 对于程序员方便快速,但自由度小。
链表从堆中分配空间, 自由度大但申请管理比较麻烦。
数组利用下标定位，时间复杂度为O(1)，链表定位元素时间复杂度O(n)；
数组插入或删除元素的时间复杂度O(n)，链表的时间复杂度O(1)。
23、error和exception的区别，CheckedException，RuntimeException的区别。
Error（错bai误）表示系统级的错误du和程序不必处理的异常，是java运行环境中的zhi内部错误或者硬件问dao题。比如：内存资源不足等。对于这种错误，程序基本无能为力，除了退出运行外别无选择，它是由Java虚拟机抛出的。
Exception（违例）表示需要捕捉或者需要程序进行处理的异常，它处理的是因为程序设计的瑕疵而引起的问题或者在外的输入等引起的一般性问题，是程序必须处理的。
Exception又分为运行时异常，受检查异常。
运行时异常，表示无法让程序恢复的异常，导致的原因通常是因为执行了错误的操作，建议终止程序，因此，编译器不检查这些异常。
检查时异常，是表示程序可以处理的异常，也即表示程序可以修复（由程序自己接受异常并且做出处理）， 所以称之为受检查异常。
Error：Error类对象由 Java 虚拟机生成并抛出，大多数错误与代码编写者所执行的操作无关。例如，Java虚拟机运行错误（Virtual MachineError），当JVM不再有继续执行操作所需的内存资源时，将出现 OutOfMemoryError。这些异常发生时，Java虚拟机（JVM）一般会选择线程终止；还有发生在虚拟机试图执行应用时，如类定义错误（NoClassDefFoundError）、链接错误（LinkageError）。这些错误是不可查的，因为它们在应用程序的控制和处理能力之 外，而且绝大多数是程序运行时不允许出现的状况。对于设计合理的应用程序来说，即使确实发生了错误，本质上也不应该试图去处理它所引起的异常状况。在Java中，错误通常是使用Error的子类描述。
Exception：在Exception分支中有一个重要的子类RuntimeException（运行时异常），该类型的异常自动为你所编写的程序定义ArrayIndexOutOfBoundsException（数组下标越界）、NullPointerException（空指针异常）、ArithmeticException（算术异常）、MissingResourceException（丢失资源）、ClassNotFoundException（找不到类）等异常，这些异常是不检查异常，程序中可以选择捕获处理，也可以不处理。这些异常一般是由程序逻辑错误引起的，程序应该从逻辑角度尽可能避免这类异常的发生；而RuntimeException之外的异常我们统称为非运行时异常，类型上属于Exception类及其子类，从程序语法角度讲是必须进行处理的异常，如果不处理，程序就不能编译通过。如IOException、SQLException等以及用户自定义的Exception异常，一般情况下不自定义检查异常。
在程序的运行过程中一个checked exception被抛出的时候，只有能够适当处理这个异常的调用方才应该用try/catch来捕获它。而对于runtime exception，则不应当在程序中捕获它。如果你要捕获它的话，你就会冒这样一个风险:程序代码的错误(bug)被掩盖在运行当中无法被察觉。因为在程序测试过程中，系统打印出来的调用堆栈路径(StackTrace)往往使你更快找到并修改代码中的错误。有些程序员建议捕获runtime exception并纪录在log中，我反对这样做。这样做的坏处是你必须通过浏览log来找出问题，而用来测试程序的测试系统(比如Unit Test)却无法直接捕获问题并报告出来。
在程序中捕获runtime exception还会带来更多的问题:要捕获哪些runtime exception?什么时候捕获?runtime exception是不需要声明的，你怎样知道有没有runtime exception要捕获?你想看到在程序中每一次调用方法时，都使用try/catch程序块吗?
Runtime exceptions:
在定义方法时不需要声明会抛出runtime exception;
在调用这个方法时不需要捕获这个runtime exception;
runtime exception是从java.lang.RuntimeException或java.lang.Error类衍生出来的。
Checked exceptions:
定义方法时必须声明所有可能会抛出的checked exception;
在调用这个方法时，必须捕获它的checked exception，不然就得把它的exception传递下去;
checked exception是从java.lang.Exception类衍生出来的。
24、请列出5个运行时异常。
ClassCastException(类转换异常)
IndexOutOfBoundsException(数组越界)
NullPointerException(空指针)
ArrayStoreException(数据存储异常，操作数组时类型不一致)
还有IO操作的BufferOverflowException异常
25、在自己的代码中，如果创建一个java.lang.String类，这个类是否可以被类加载器加载？为什么。
一、双亲委派模型
类加载器可分为两类：一是启动类加载器(Bootstrap ClassLoader)，是C++实现的，是JVM的一部分；另一种是其它的类加载器，是Java实现的，独立于JVM，全部都继承自抽象类java.lang.ClassLoader。jdk自带了三种类加载器，分别是启动类加载器（Bootstrap ClassLoader），扩展类加载器（Extension ClassLoader），应用程序类加载器（Application ClassLoader）。后两种加载器是继承自抽象类java.lang.ClassLoader。
一般是： 自定义类加载器 >> 应用程序类加载器 >> 扩展类加载器 >> 启动类加载器
上面的层次关系被称为双亲委派模型(Parents Delegation Model)。除了最顶层的启动类加载器外，其余的类加载器都有对应的父类加载器。
再简单说下双亲委托机制：如果一个类加载器收到了类加载的请求，它首先不会自己尝试去加载这个类，而是把这个请求委派给父类加载器，每一个层次的类加载器都是加此，因此所有的加载请求最终到达顶层的启动类加载器，只有当父类加载器反馈自己无法完成加载请求时（指它的搜索范围没有找到所需的类），子类加载器才会尝试自己去加载。
各个类加载器之间是组合关系，并非继承关系。
双亲委派模型可以确保安全性，可以保证所有的Java类库都是由启动类加载器加载。如用户编写的java.lang.Object，加载请求传递到启动类加载器，启动类加载的是系统中的Object对象，而用户编写的java.lang.Object不会被加载。如用户编写的java.lang.virus类，加载请求传递到启动类加载器，启动类加载器发现virus类并不是核心Java类，无法进行加载，将会由具体的子类加载器进行加载，而经过不同加载器进行加载的类是无法访问彼此的。由不同加载器加载的类处于不同的运行时包。所有的访问权限都是基于同一个运行时包而言的。
二、为什么要使用这种双亲委托模式呢？
因为这样可以避免重复加载，当父亲已经加载了该类的时候，就没有必要子ClassLoader再加载一次。
考虑到安全因素，我们试想一下，如果不使用这种委托模式，那我们就可以随时使用自定义的String来动态替代java核心api中定义类型，这样会存在非常大的安全隐患，而双亲委托的方式，就可以避免这种情况，因为String已经在启动时被加载，所以用户自定义类是无法加载一个自定义的ClassLoader。
思考：假如我们自己写了一个java.lang.String的类，我们是否可以替换调JDK本身的类？
答案是否定的。我们不能实现。为什么呢？我看很多网上解释是说双亲委托机制解决这个问题，其实不是非常的准确。因为双亲委托机制是可以打破的，你完全可以自己写一个classLoader来加载自己写的java.lang.String类，但是你会发现也不会加载成功，具体就是因为针对java.*开头的类，jvm的实现中已经保证了必须由bootstrp来加载。
因加载某个类时，优先使用父类加载器加载需要使用的类。如果我们自定义了java.lang.String这个类， 加载该自定义的String类，该自定义String类使用的加载器是AppClassLoader，根据优先使用父类加载器原理， AppClassLoader加载器的父类为ExtClassLoader，所以这时加载String使用的类加载器是ExtClassLoader， 但是类加载器ExtClassLoader在jre/lib/ext目录下没有找到String.class类。然后使用ExtClassLoader父类的加载器BootStrap， 父类加载器BootStrap在JRE/lib目录的rt.jar找到了String.class，将其加载到内存中。这就是类加载器的委托机制。
三、定义自已的ClassLoader
既然JVM已经提供了默认的类加载器，为什么还要定义自已的类加载器呢？
因为Java中提供的默认ClassLoader，只加载指定目录下的jar和class，如果我们想加载其它位置的类或jar时，比如：我要加载网络上的一个class文件，通过动态加载到内存之后，要调用这个类中的方法实现我的业务逻辑。在这样的情况下，默认的ClassLoader就不能满足我们的需求了，所以需要定义自己的ClassLoader。
定义自已的类加载器分为两步：
1、继承java.lang.ClassLoader
2、重写父类的findClass方法
读者可能在这里有疑问，父类有那么多方法，为什么偏偏只重写findClass方法？
因为JDK已经在loadClass方法中帮我们实现了ClassLoader搜索类的算法，当在loadClass方法中搜索不到类时，loadClass方法就会调用findClass方法来搜索类，所以我们只需重写该方法即可。如没有特殊的要求，一般不建议重写loadClass搜索类的算法。
26、说一说你对java.lang.Object对象中hashCode和equals方法的理解。在什么场景下需要重新实现这两个方法。
hashCode是jdk根据对象的地址或者字符串或者数字算出来的int类型的数值，也就是哈希码，哈希码并不是完全唯一的，它是一种算法，让同一个类的对象按照自己不同的特征尽量的有不同的哈希码，但不表示不同的对象哈希码完全不同。在Java中，哈希码代表对象的特征。
在Object这个类里面提供的Equals()方法默认的实现是比较当前对象的引用和你要比较的那个引用它们指向的是否是同一个对象
1）对于equals()与hashcode()，比较通用的规则：
①两个obj，如果equals()相等，hashCode()一定相等
②两个obj，如果hashCode()相等，equals()不一定相等
2）在设计一个类的时候往往需要重写equals方法，比如String类，在重写equals方法的同时，必须重写hashCode方法。
如果我们对一个对象重写了euqals，意思是只要对象的成员变量值都相等那么euqals就等于true，但不重写hashcode，那么我们再new一个新的对象，当原对象.equals（新对象）等于true时，两者的hashcode却是不一样的，由此将产生了理解的不一致，如在存储散列集合时（如Set类），将会存储了两个值一样的对象，导致混淆，因此，就也需要重写hashcode()。
27、在jdk1.5中，引入了泛型，泛型的存在是用来解决什么问题。
泛型是Java SE 1.5的新特性，泛型的本质是参数化类型，也就是说所操作的数据类型被指定为一个参数。
好处：
1、类型安全，提供编译期间的类型检测
2、前后兼容
3、泛化代码,代码可以更多的重复利用
4、性能较高，用GJ(泛型JAVA)编写的代码可以为java编译器和虚拟机带来更多的类型信息，这些信息对java程序做进一步优化提供条件。
泛型的本质是参数化类型，这种参数类型可以用在类、接口和方法的创建中，分别称为泛型类、泛型接口、泛型方法。
在 Java SE 1.5 之前没有泛型的情况的下只能通过对类型 Object 的引用来实现参数的任意化，其带来的缺点是要做显式强制类型转换，而这种强制转换编译期是不做检查的，容易把问题留到运行时，
所以 泛型的好处是在编译时检查类型安全，并且所有的强制转换都是自动和隐式的，提高了代码的重用率，避免在运行时出现 ClassCastException。
28.这样的a.hashcode() 有什么用，与a.equals(b)有什么关系。
获取对象的哈希值,用一个数字来标识对象,方法提供了对象的hashCode值，是一个native方法，返回的默认值与System.identityHashCode(obj)一致。通常这个值是对象头部的一部分二进制位组成的数字，具有一定的标识对象的意义存在，但绝不定于地址。
equals相等两个对象，则hashcode一定要相等。但是hashcode相等的两个对象不一定equals相等。
29、有没有可能2个不相等的对象有相同的hashcode。
有可能
因为:
Equals()方法默认的实现是比较当前对象的引用和你要比较的那个引用它们指向的是否是同一个对象。
hashCode是jdk根据对象的地址或者字符串或者数字算出来的int类型的数值，也就是哈希码，哈希码并不是完全唯一的，它是一种算法，让同一个类的对象按照自己不同的特征尽量的有不同的哈希码，但不表示不同的对象哈希码完全不同。在Java中，哈希码代表对象的特征。
30、Java中的HashSet内部是如何工作的。
HashSet：
实现了Set接口
HashSet依赖的数据结构是哈希表
因为实现的是Set接口，所以不允许有重复的值
插入到HashSet中的对象不保证与插入的顺序保持一致。对象的插入是根据它的hashcode
HashSet中允许有NULL值
HashSet也实现了Searlizable和Cloneable两个接口
初始化容量就是当创建哈希表（HashSet内部用哈希表的数据结构）的时候容器（buckets）的数量。如果当前的容器已经满了，那么容器的数量会自动增长。
装载因子衡量的是在HashSet自动增长之前允许有多满。当哈希表中实体的数量已经超出装载因子与当前容量的积，那么哈希表就会再次进行哈希（也就是内部数据结构重建），这样哈希表大致有两倍容器的数量。
装载因子和初始化容量是影响HashSet操作的两个主要因素。装载因子为0.75的时候可以提供关于时间和空间复杂度方面更有效的性能。如果我们加大这个装载因子，那么内存的上限就会减小（因为它减少了内部重建的操作），但是将影响哈希表中的add与查询的操作。为了减少再哈希操作，我们应该选择一个合适的初始化大小。如果初始化容量大于实体的最大数量除以装载因子，那么就不会有再哈希的动作发生了。
31、什么是序列化，怎么序列化，为什么序列化，反序列化会遇到什么问题，如何解决。
什么是序列化
Java对象序列化是指将Java对象转化为字节序列的过程而反序列化则是将字节序列转化为Java对象的过程
为什么需要序列化
我们知道不同线程/进程进行远程通信时可以相互发送各种数据，包括文本图片音视频等，Java对象不能直接传输，所以需要转化为二进制序列传输，所以需要序列化
怎么序列化
实现Serializable接口实现这个接口就会添加一个serialVersionUID
的版本号，这个版本号的作用是用来验证反序列化时是否用的是同一个类
序列化是通过ObjectOutputStream类的writeObject()方法将对象直接写出
反序列化时通过ObjectInputStream类的readObject()方法从流中读取数据
反序列化会遇到什么问题
可能会导致InvalidClassException(无效类异常)
如果没有显式声明序列版本UID，对对象的需求进行了改动，那么兼容性将会遭到破坏，在运行时导致InvalidClassException
32、java8的新特性。
一.接口内允许添加默认实现的方法
在原来的定义中接口中只能有方法声明，不能有方法体。在Java8中，接口也可以有自己带有实现的方法啦。具体来说是要用default来修饰的方法，其可以像类中的方法一样有执行语句。在实现接口时，可以不实现其default方法，并且实现类对象可以调用其接口的default方法。当然也可以在实现类中覆盖default方法。
二.Lambda表达式
Lambda简化了匿名内部类的写法。Java8中可以通过类型推断来判断出用户的意图，不必将类型等信息写全。特别是方法实现体中只有一句语句的实现类，更能加大简化力度。
Lambda解决了将一个方法作为参数传值的问题。解决了一个函数是否可以独立存在的问题。是Java向函数式编程的一种靠拢。
一般在某个方法只使用一次的地方使用Lambda表达式；如果方法没有入参，则只写一个()->{语句}；当只有一个参数，且类型可推断时，()可省略；如果方法体中只有一条语句花括号可以省略；
三.Lambda访问外部变量及接口默认方法
访问局部变量可以访问局部的final变量，但不能修改。与匿名内部类不同的是，外部变量不需要显示地声明为final，但却要有final的特点，不能被修改，在Lambda之后被修改也不行。
访问成员变量和静态变量,可以任意读写
访问接口的默认方法,在匿名类中可以访问接口定义的默认方法，在Lambda中不可以访问。
3、JVM知识
1、什么情况下会发生栈内存溢出。
1.栈溢出(StackOverflowError异常)
栈是线程私有的，他的生命周期与线程相同，每个方法在执行的时候都会创建一个栈帧，用来存储局部变量表，操作数栈，动态链接，方法出口等信息。局部变量表又包含基本数据类型，对象引用类型（局部变量表编译器完成，运行期间不会变化）,所以我们可以理解为栈溢出就是方法执行时创建的栈帧超过了栈的深度。那么最有可能的就是方法递归调用产生这种结果。
可以在eclipse中的JVM Test中使用-Xss去调整JVM栈的大小
2.堆溢出(OutOfMemoryError:Java heap space)
heap space表示堆空间，堆中主要存储的是对象。如果不断的new对象则会导致堆中的空间溢出
可以通过 -Xmx4096M 调整堆的总大小
2、JVM的内存结构，Eden和Survivor比例。
JVM内存的结构为
堆：存放对象
栈：运行时存放栈帧
程序计数器
方法区：存放类和常量
Jdk 1.8之后好像取消了方法区，直接将永久代放到了本地内存里面。
Eden区是一块，Survivor区是两块。
Eden区和Survivor区的比例是8：1：1
3、JVM内存为什么要分成新生代，老年代，持久代。新生代中为什么要分为Eden和Survivor。
【截图见 笔记中的 年轻代GC原理.png】
1.为什么分代
不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。
在Java程序运行的过程中，会产生大量的对象，其中有些对象是与业务信息相关，比如Http请求中的Session对象、线程、Socket连接，这类对象跟业务直接挂钩，因此生命周期比较长。但是还有一些对象，主要是程序运行过程中生成的临时变量，这些对象生命周期会比较短，比如：String对象，由于其不变类的特性，系统会产生大量的这些对象，有些对象甚至只用一次即可回收。试想，在不进行对象存活时间区分的情况下，每次垃圾回收都是对整个堆空间进行回收，花费时间相对会长，同时，因为每次回收都需要遍历所有存活对象，但实际上，对于生命周期长的对象而言，这种遍历是没有效果的，因为可能进行了很多次遍历，但是他们依旧存在。因此，分代垃圾回收采用分治的思想，进行代的划分，把不同生命周期的对象放在不同代上，不同代上采用最适合它的垃圾回收方式进行回收。
2.哪几代
一：新生代:
主要是用来存放新生的对象。一般占据堆的1/3空间。由于频繁创建对象，所以新生代会频繁触发MinorGC进行垃圾回收。
新生代又分为 Eden区、ServivorFrom、ServivorTo三个区。
Eden区：Java新对象的出生地（如果新创建的对象占用内存很大，则直接分配到老年代）。当Eden区内存不够的时候就会触发MinorGC，对新生代区进行一次垃圾回收。
ServivorTo：保留了一次MinorGC过程中的幸存者。
ServivorFrom：上一次GC的幸存者，作为这一次GC的被扫描者。
MinorGC的过程：MinorGC采用复制算法。首先，把Eden和ServivorFrom区域中存活的对象复制到ServicorTo区域（如果有对象的年龄以及达到了老年的标准，则赋值到老年代区），同时把这些对象的年龄+1（如果ServicorTo不够位置了就放到老年区）；然后，清空Eden和ServicorFrom中的对象；最后，ServicorTo和ServicorFrom互换，原ServicorTo成为下一次GC时的ServicorFrom区。
HotSpot JVM把年轻代分为了三部分：1个Eden区和2个Survivor区（分别叫from和to）。默认比例为8：1,为啥默认会是这个比例，接下来我们会聊到。一般情况下，新创建的对象都会被分配到Eden区(一些大对象特殊处理),这些对象经过第一次Minor GC后，如果仍然存活，将会被移到Survivor区。对象在Survivor区中每熬过一次Minor GC，年龄就会增加1岁，当它的年龄增加到一定程度时，就会被移动到年老代中。因为年轻代中的对象基本都是朝生夕死的(80%以上)，所以在年轻代的垃圾回收算法使用的是复制算法，复制算法的基本思想就是将内存分为两块，每次只用其中一块，当这一块内存用完，就将还活着的对象复制到另外一块上面。复制算法不会产生内存碎片。在GC开始的时候，对象只会存在于Eden区和名为“From”的Survivor区，Survivor区“To”是空的。紧接着进行GC，Eden区中所有存活的对象都会被复制到“To”，而在“From”区中，仍存活的对象会根据他们的年龄值来决定去向。年龄达到一定值(年龄阈值，可以通过-XX:MaxTenuringThreshold来设置)的对象会被移动到年老代中，没有达到阈值的对象会被复制到“To”区域。经过这次GC后，Eden区和From区已经被清空。这个时候，“From”和“To”会交换他们的角色，也就是新的“To”就是上次GC前的“From”，新的“From”就是上次GC前的“To”。不管怎样，都会保证名为To的Survivor区域是空的。Minor GC会一直重复这样的过程，直到“To”区被填满，“To”区被填满之后，会将所有对象移动到年老代中。
二：老年代：主要存放应用程序中生命周期长的内存对象。
老年代的对象比较稳定，所以MajorGC不会频繁执行。在进行MajorGC前一般都先进行了一次MinorGC，使得有新生代的对象晋身入老年代，导致空间不够用时才触发。当无法找到足够大的连续空间分配给新创建的较大对象时也会提前触发一次MajorGC进行垃圾回收腾出空间。MajorGC采用标记—清除算法：首先扫描一次所有老年代，标记出存活的对象，然后回收没有标记的对象。MajorGC的耗时比较长，因为要扫描再回收。MajorGC会产生内存碎片，为了减少内存损耗，我们一般需要进行合并或者标记出来方便下次直接分配。当老年代也满了装不下的时候，就会抛出OOM（Out of Memory）异常。
三：永久代
指内存的永久保存区域，主要存放Class和Meta（元数据）的信息,Class在被加载的时候被放入永久区域. 它和存放实例的区域不同,GC不会在主程序运行期对永久区域进行清理。所以这也导致了永久代的区域会随着加载的Class的增多而胀满，最终抛出OOM异常。在Java8中，永久代已经被移除，被一个称为“元数据区”（元空间）的区域所取代。元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。因此，默认情况下，元空间的大小仅受本地内存限制。类的元数据放入 native memory, 字符串池和类的静态变量放入java堆中. 这样可以加载多少类的元数据就不再由MaxPermSize控制, 而由系统的实际可用空间来控制.
采用元空间而不用永久代的几点原因：（参考：http://www.cnblogs.com/paddix/p/5309550.html）
1、为了解决永久代的OOM问题，元数据和class对象存在永久代中，容易出现性能问题和内存溢出。
2、类及方法的信息等比较难确定其大小，因此对于永久代的大小指定比较困难，太小容易出现永久代溢出，太大则容易导致老年代溢出（因为堆空间有限，此消彼长）。
3、永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。
4、Oracle 可能会将HotSpot 与 JRockit 合二为一。
3.为什么要分为Eden和Survivor
如果没有Survivor，Eden区每进行一次Minor GC，存活的对象就会被送到老年代。 老年代很快被填满，触发Major GC.老年代的内存空间远大于新生代，进行一次Full GC消耗的时间比Minor GC长得多,所以需要分为Eden和Survivor。Survivor的存在意义，就是减少被送到老年代的对象，进而减少Full GC的发生，Survivor的预筛选保证，只有经历16次Minor GC还能在新生代中存活的对象，才会被送到老年代。
4.为什么要设置两个Survivor区
设置两个Survivor区最大的好处就是解决了碎片化，刚刚新建的对象在Eden中，经历一次Minor GC，Eden中的存活对象就会被移动到第一块survivor space S0，Eden被清空； 等Eden区再满了，就再触发一次Minor GC，Eden和S0中的存活对象又会被复制送入第二块survivor space S1（这个过程非常重要，因为这种复制算法保证了S1中来自S0和Eden两部分的存活对象占用连续的内存空间，避免了碎片化的发生）
4、JVM中一次完整的GC流程是怎样的，对象如何晋升到老年代，说说你知道的几种主要的JVM参数。
GC流程详见笔记 GC执行流程.png 参数详细见笔记 JVM参数.jpg
解说1:
1、现在有一个新对象产生，那么对象一定需要内存空间，于是现在需要为该对象进行内存空间的申请。
2、首先会判断Eden区是否有内存空间，如果此时有充足内存空间，则直接将新对象保存到Eden区。
3、但是如果此时Eden区的内存空间不足，那么会自动执行Minor GC操作，将Eden区无用的内存空间进行清理。清理之后会继续判断Eden区空间是否充足？如果充足，则将新的对象直接在Eden区进行内存空间分配。
4、如果执行Minor GC之后Eden区空间依然不足，那么这个时候会进行存活区判断，如果存活区有剩余空间，则将Eden区的部分活跃对象保存在存活区，随后继续判断Eden区的内存空间是否充足，如果充足，则进行内存空间分配。
5、如果此时存活区也没有内存空间了，则继续判断老年区，如果此时老年区的空间充足，则将存活区中的活跃对象保存到老年区，而后存活区应付出现空余空间，随后Eden区将部分活跃对象保存地存活区中，最后在Eden区为新对象分配内存空间。
6、如果这个时候老年代内存空间也满了，那么这个时候将产生Major GC（Full GC）。然后再将存活区中的活跃对象保存到老年区，从而腾出空间，然后再将Eden区的部分活跃对象保存到存活区，最后在Eden区为新对象分配内存空间。
7、如果老年代执行Full GC之后依然空间依然不足，应付产生OOM（OutOfMemoryError）异常。
解说2:
Java堆 = 老年代 + 新生代
新生代 = Eden + S0 + S1
当 Eden 区的空间满了， Java虚拟机会触发一次 Minor GC，以收集新生代的垃圾，存活下来的对象，则会转移到 Survivor区。大对象（需要大量连续内存空间的Java对象，如那种很长的字符串） 直接进入老年态 ；如果对象在Eden出生，并经过第一次Minor GC后仍然存活，并且被Survivor容纳的话，年龄设为1，每熬过一次Minor GC，年龄+1， 若年龄超过一定限制（15），则被晋升到老年态 。即 长期存活的对象进入老年态 。老年代满了而 无法容纳更多的对象 ，Minor GC 之后通常就会进行Full GC，Full GC 清理整个内存堆 – 包括年轻代和年老代 。Major GC 发生在老年代的GC ， 清理老年区 ，经常会伴随至少一次Minor GC， 比Minor GC慢10倍以上 。
-Xms 初始堆大小
-Xmx 最大堆大小
-XX:newSize 表示新生代初始内存的大小，应该小于 -Xms的值
-Xss 每个线程的堆栈大小
5、你知道哪几种垃圾收集器，各自的优缺点，重点讲下cms和G1，包括原理，流程，优缺点。
1.Serial收集器：单线程的收集器，收集垃圾时，必须stop the world，使用复制算法。
2.ParNew收集器：Serial收集器的多线程版本，也需要stop the world，复制算法。
3.Parallel Scavenge收集器： 新生代收集器，复制算法的收集器，并发的多线程收集器，目标是达到一个可控的吞吐量。 如果虚拟机总共运行100分钟，其中垃圾花掉1分钟，吞吐量就是99%。
4.Serial Old收集器：是Serial收集器的老年代版本，单线程收集器，使用标记整理算法。
5.Parallel Old收集器：是Parallel Scavenge收集器的老年代版本，使用多线程，标记-整理算法。
CMS(Concurrent Mark Sweep) 收集器：是一种以获得最短回收停顿时间为目标的收集器， 标记清除算法，运作过程：初始标记，并发标记，重新标记，并发清除 ，收集结束会产生大量空间碎片。
G1收集器： 标记整理算法实现， 运作流程主要包括以下：初始标记，并发标记，最终标记，筛选标记 。 不会产生空间碎片，可以精确地控制停顿。
CMS收集器和G1收集器的区别：
CMS收集器是老年代的收集器，可以配合新生代的Serial和ParNew收集器一起使用；
G1收集器收集范围是老年代和新生代，不需要结合其他收集器使用；
CMS收集器以最小的停顿时间为目标的收集器；
G1收集器可预测垃圾回收的停顿时间
CMS收集器是使用“标记-清除”算法进行的垃圾回收，容易产生内存碎片
G1收集器使用的是“标记-整理”算法，进行了空间整合，降低了内存空间碎片。
6、垃圾回收算法的实现原理。
1.复制算法
复制算法将可用内存按容量划分为相等的两部分，然后每次只使用其中的一块，当一块内存用完时，就将还存活的对象复制到第二块内存上，然后一次性清楚完第一块内存，再将第二块上的对象复制到第一块。但是这种方式，内存的代价太高，每次基本上都要浪费一半的内存。
2.标记清除算法
是JVM垃圾回收算法中最古老的一个，该算法共分成两个阶段，第一阶段从引用根节点开始标记所有被引用的对象，第二阶段遍历整个堆，清除未被标记的对象。该算法的缺点是需要暂停整个应用，并且在回收以后未使用的空间是不连续，即内存碎片，会影响到存储。
3.标记整理算法
此算法结合了标记-清楚算法和复制算法的优点，也分为两个阶段，第一阶段从引用根节点开始标记所有被引用的对象，第二阶段遍历整个堆，在回收不存活的对象占用的空间后，会将所有的存活对象往左端空闲空间移动，并更新对应的指针。标记-整理算法是在标记-清除算法的基础上，又进行了对象的移动，因此成本更高，但是却解决了内存碎片的问题，按顺序排放，同时解决了复制算法所需内存空间过大的问题。
4.分代收集
分代收集算法是目前大部分JVM的垃圾收集器采用的算法。它的核心思想是根据对象存活的生命周期将内存划分为若干个不同的区域。一般情况下将堆区划分为老年代（Tenured Generation）和新生代（Young Generation），在堆区之外还有一个代就是永久代（Permanet Generation）。老年代的特点是每次垃圾收集时只有少量对象需要被回收，而新生代的特点是每次垃圾回收时都有大量的对象需要被回收，那么就可以根据不同代的特点采取最适合的收集算法。
a.年轻代回收算法（核心其实就是复制算法）
HotSpot将新生代划分为三块，-块较大的Eden空间和两块较小的Survivor空间，默认比例为8: 1: 1。划分的目的是因为HotSpot采用复制算法来回收新生代，设置这个比例是为了充分利用内存空间，减少浪费。新生成的对象在Eden区分配(大对象除外，大对象直接进入老年代) ,当Eden区没有足够的空间进行分配时,虚拟机将发起一次Minor GC。GC开始时,对象只会存在于Eden区和From Survivor区，To Survivor区是空的(作为保留区域)。GC进行时，Eden区中所有存活的对象都会被复制到To Survivor区,而在FromSurvivor区中,仍存活的对象会根据它们的年龄值决定去向，年龄值达到阀值(默认为15 ,新生代中的对象每熬过一轮垃圾回收年龄值就加1 ,GC分代年龄存储在对象的header中)的对象会被移到老年代中,没有达到阀值的对象会被复制到To Survivor区。接着清空Eden区和From Survivor区，新生代中存活的对象都在To Survivor区。接着, From Survivor区和To Survivor区会交换它们的角色，也就是新的To Survivor区就是上次GC清空的FromSurvivor区，新的From Survivor区就是.上次GC的To Survivor区，总之，不管怎样都会保证To Survivor区在一轮GC后是空（其实这就是分代收集算法中的年轻代回收算法，稍后我们会看到）。GC时当To Survivor区没有足够的空间存放上一次新生代收集下来的存活对象时，需要依赖老年代进行分配担保，将这些对象存放在老年代中。
b.老年代回收算法（回收主要以标记-整理为主）
1)在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。
2)内存比新生代也大很多(大概比例是1:2)，当老年代内存满时触发Major GC即Full GC，Full GC发生频率比较低，老年代对象存活时间比较长，存活率标记高。
c. 持久代（Permanent Generation）的回收算法
用于存放静态文件，如Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate 等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。在该区内很少发生垃圾回收，但是并不代表不发生GC，在这里进行的GC主要是对持久代里的常量池和对类型的卸载。
条件：
1)该类所有的实例都已经被回收，即Java堆中不存在该类的任何实例；
2)加载该类的ClassLoader已经被回收；
3)该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
虚拟机可以对满足上述3个条件的无用类进行回收，此处仅仅是“可以”，而并不是和对象一样，不使用了就必然回收！
7、当出现了内存溢出，你怎么排错。
首先分析是什么类型的内存溢出，对应的调整参数或者优化代码。
内存溢出是由于没被引用的对象（垃圾）过多造成JVM没有及时回收，造成的内存溢出。如果出现这种现象可行代码排查：
一）是否App中的类中和引用变量过多使用了Static修饰 如public staitc Student s；在类中的属性中使用 static修饰的最好只用基本类型或字符串。如public static int i = 0; //public static String str;
二）是否App中使用了大量的递归或无限递归（递归中用到了大量的建新的对象）
三）是否App中使用了大量循环或死循环（循环中用到了大量的新建的对象）
四）检查App中是否使用了向数据库查询所有记录的方法。即一次性全部查询的方法，如果数据量超过10万多条了，就可能会造成内存溢出。所以在查询时应采用“分页查询”。
五）检查是否有数组，List，Map中存放的是对象的引用而不是对象，因为这些引用会让对应的对象不能被释放。会大量存储在内存中。
六）检查是否使用了“非字面量字符串进行+”的操作。因为String类的内容是不可变的，每次运行"+"就会产生新的对象，如果过多会造成新String对象过多，从而导致JVM没有及时回收而出现内存溢出。
举例:
堆栈溢出异常：java.lang.StackOverflowError
一般就是递归没返回，或者循环调用造成
年老代堆空间被占满异常： java.lang.OutOfMemoryError: Java heap space
这是最典型的内存泄漏方式，简单说就是所有堆空间都被无法回收的垃圾对象占满，虚拟机无法再在分配新空间。这种情况一般来说是因为内存泄漏或者内存不足造成的。某些情况因为长期的无法释放对象，运行时间长了以后导致对象数量增多，从而导致的内存泄漏。另外一种就是因为系统的原因，大并发加上大对象，Survivor Space区域内存不够，大量的对象进入到了老年代,然而老年代的内存也不足时，从而产生了Full GC，但是这个时候Full GC也无发回收。这个时候就会产生java.lang.OutOfMemoryError: Java heap space
解决方案如下：
代码内的内存泄漏可以通过一些分析工具进行分析，然后找出泄漏点进行改善。
第二种原因导致的OutOfMemoryError可以通过，优化代码和增加Survivor Space等方式去优化。
8、JVM内存模型的相关知识了解多少，比如重排序，内存屏障，happen-before，主内存，工作内存等。
内存屏障：为了保障执行顺序和可见性的一条cpu指令
重排序：为了提高性能，编译器和处理器会对执行进行重拍
happen-before：操作间执行的顺序关系。有些操作先发生。
主内存：共享变量存储的区域即是主内存
工作内存：每个线程copy的本地内存，存储了该线程以读/写共享变量的副本 xxxxxxxxxx
9、简单说说你了解的类加载器，可以打破双亲委派么，怎么打破。
类加载器 就是根据指定全限定名称将class文件加载到JVM内存，转为Class对象。
1.启动类加载器（Bootstrap ClassLoader）：由C++语言实现（针对HotSpot）,负责将存放在\lib目录或-Xbootclasspath参数指定的路径中的类库加载到内存中。
2.其他类加载器：由Java语言实现，继承自抽象类ClassLoader。
3.扩展类加载器（Extension ClassLoader）：负责加载\lib\ext目录或java.ext.dirs系统变量指定的路径中的所有类库。
4.应用程序类加载器（Application ClassLoader）。负责加载用户类路径（classpath）上的指定类库，我们可以直接使用这个类加载器。一般情况，如果我们没有自定义类加载器默认就是用这个加载器。
打破: 线程上下文加载器(Thread Context ClassLoader)打破双亲委派机制则不仅要继承ClassLoader类，还要重写loadClass和findClass方法。
1：自己写一个类加载器
2：重写loadclass方法
3：重写findclass方法
10、讲讲JAVA的反射机制。
首先我们需要了解java程序运行的过程，该过程包含两个阶段编译期和运行期。首先java代码会通过jdk编译成.class字节码文件，程序运行的时候，jvm会去调用业务逻辑对应需要的的字节码文件，生成对应的Class对象，并调用其中的属性方法完成业务逻辑。而java反射则是在运行期时，主动让jvm去加载某个.class文件生成Class对象，并调用其中的方法属性。
jvm中分别有堆、栈、方法区
1.硬盘中存有.class字节码文件
2.将.class字节码加载进方法区中
3.方法区中就存在了类的所有信息(方法,属性,修饰符,注解等)了
4.将方法区中的字节码信息,封装成一个Class对象,放到堆内存中,使用Class.forName("类全名");就可以在堆中创建一个Class对象的引了。注意:该对象由JVM自动创建,不需要开发人员去手动创建。对于同类型的Class对象来说,有且只有一个该Vlass对象在类加载的时候
5.栈的一个对象引用指向了堆内存中的Class对象的引用
11、你们线上应用的JVM参数有哪些。
-server -Xmx2g -Xms2g -Xmn256m -XX:PermSize=128m -Xss256k -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX
:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSI
nitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70
-Xms2g JVM初始分配的内存由-Xms指定，默认是物理内存的1/64但小于1G。
-Xmx2g JVM最大分配的内存由-Xmx指定，默认是物理内存的1/4但小于1G。
-XX:PermSize=128m 装载Class信息等基础数据，默认64M
-Xss256k 设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K
-XX:DisableExplicitGC禁止调用代码System.gc()
-XX:+UseConcMarkSweepGC 指定在 Old Generation 使用 concurrent cmark sweep gc,gc thread 和 app thread 并行 ( 在 init-mark 和 remark 时 pause app thread). app pause 时间较短 , 适合交互性强的系统 , 如 web server
-XX:+CMSParallelRemarkEnabled 在使用 UseParNewGC 的情况下 , 尽量减少 mark 的时间
XX:+UseCMSCompactAtFullCollection 在使用 concurrent gc 的情况下 , 防止 memory fragmention, 对 live object 进行整理 , 使 memory 碎片减少
-XX:LargePageSizeInBytes=128m 指定 Java heap 的分页页面大小 , 如 :-XX:LargePageSizeInBytes=128m
-XX:+UseFastAccessorMethods get,set 方法转成本地代码
-XX:+UseCMSInitiatingOccupancyOnly 指示只有在 old generation 在使用了初始化的比例后 concurrent collector 启动收集
XX:CMSInitiatingOccupancyFraction=70 指示在 old generation 在使用了 n% 的比例后 , 启动 concurrent collector, 默认值是 68, 如 :-XX:CMSInitiatingOccupancyFraction=70
12、g1和cms区别,吞吐量优先和响应优先的垃圾收集器选择。
CMS收集器：一款以获取最短回收停顿时间为目标的收集器，是基于“标记-清除”算法实现的，分为4个步骤：初始标记、并发标记、重新标记、并发清除。
G1收集器：面向服务端应用的垃圾收集器，过程：初始标记；并发标记；最终标记；筛选回收。整体上看是“标记-整理”，局部看是“复制”，不会产生内存碎片。
吞吐量优先的并行收集器：以到达一定的吞吐量为目标，适用于科学技术和后台处理等。
响应时间优先的并发收集器：保证系统的响应时间，减少垃圾收集时的停顿时间。适用于应用服务器、电信领域等。
13、怎么打出线程栈信息。
jstack可以得知当前线程的运行情况
安装jstack等命令集，jstack是开发版本jdk的一部分，不是开发版的有可能找不到
yum install -y java-1.8.0-openjdk-devel
查看要打印堆栈的java进程ID
jps -l
打印堆栈
sudo -u admin jstack pid > jstack.txt
特别要注意的是jstack需要使用与进程一致的用户才能正确导出堆栈，否则会报错如下
Unable to open socket file: target process not responding or HotSpot VM not loaded
14、请解释如下jvm参数的含义：-server -Xms512m -Xmx512m -Xss1024K,-XX:PermSize=256m -XX:MaxPermSize=512m -XX:MaxTenuringThreshold=20XX:CMSInitiatingOccupancyFraction=80 -
4、操作系统
1、Linux系统下你关注过哪些内核参数，说说你知道的。
Tcp/ip io cpu memory
net.ipv4.tcp_syncookies = 1
#启用syncookies
net.ipv4.tcp_max_syn_backlog = 8192
#SYN队列长度
net.ipv4.tcp_synack_retries=2
#SYN ACK重试次数
net.ipv4.tcp_fin_timeout = 30
#主动关闭方FIN-WAIT-2超时时间
net.ipv4.tcp_keepalive_time = 1200
#TCP发送keepalive消息的频度
net.ipv4.tcp_tw_reuse = 1
#开启TIME-WAIT重用
net.ipv4.tcp_tw_recycle = 1
#开启TIME-WAIT快速回收
net.ipv4.ip_local_port_range = 1024 65000
#向外连接的端口范围
net.ipv4.tcp_max_tw_buckets = 5000
#最大TIME-WAIT数量，超过立即清除
net.ipv4.tcp_syn_retries = 2
#SYN重试次数
echo “fs.file-max=65535” >> /etc/sysctl.conf
sysctl -p
2、Linux下IO模型有几种，各自的含义是什么。
五种IO模型包括：阻塞IO、非阻塞IO、IO多路复用、信号驱动IO、异步IO。
1、阻塞IO模型
场景描述：
在饭店领完号后，前面还有n桌，不知道什么时候到我们，但是又不能离开，因为过号之后必须重新取号。只好在饭店里等，一直等到叫号到我们才吃完晚饭，然后去逛街。中间等待的时间什么事情都不能做。
网络模型：
在这个模型中，应用程序为了执行这个read操作，会调用相应的一个system call，将系统控制权交给内核，然后就进行等待（这个等待的过程就是被阻塞了），内核开始执行这个system call，执行完毕后会向应用程序返回响应，应用程序得到响应后，就不再阻塞，并进行后面的工作。
优点：
能够及时返回数据，无延迟。
缺点：
对用户来说处于等待就要付出性能代价。
2、非阻塞IO
场景描述：
等待过程是在太无聊，于是我们就去逛商场，每隔一段时间就回来询问服务员，叫号是否到我们了，整个过程来来回回好多次。这就是非阻塞，但是需要不断的询问。
网络模型：
当用户进程发出read操作时，调用相应的system call，这个system call会立即从内核中返回。但是在返回的这个时间点，内核中的数据可能还没有准备好，也就是说内核只是很快就返回了system call，只有这样才不会阻塞用户进程，对于应用程序，虽然这个IO操作很快就返回了，但是它并不知道这个IO操作是否真的成功了，为了知道IO操作是否成功，应用程序需要主动的循环去问内核。
优点：
能够在等待的时间里去做其他的事情。
缺点：
任务完成的响应延迟增大了，因为每过一段时间去轮询一次read操作，而任务可能在两次轮询之间的任意时间完成，这对导致整体数据吞吐量的降低。
3、IO多路复用
场景描述：
与第二个经常类似，饭店安装了电子屏幕，显示叫号的状态，所以在逛街的时候，就不用去询问服务员，而是看下大屏幕就可以了。（不仅仅是我们不用询问服务员，其他所有的人都可以不用询问服务员）
网络模型：
和第二种一样，调用system call之后，并不等待内核的返回结果而是立即返回。虽然返回结果的调用函数是一个异步的方式，但应用程序会被像select、poll和epoll等具有多个文件描述符的函数阻塞住，一直等到这个system call有结果返回了，再通知应用程序。这种情况，从IO操作的实际效果来看，异步阻塞IO和第一种同步阻塞IO是一样的，应用程序都是一直等到IO操作成功之后（数据已经被写入或者读取），才开始进行下面的工作。不同点在于异步阻塞IO用一个select函数可以为多个文件描述符提供通知，提供了并发性。举个例子：例如有一万个并发的read请求，但是网络上仍然没有数据，此时这一万个read会同时各自阻塞，现在用select、poll、epoll这样的函数来专门负责阻塞同时监听这一万个请求的状态，一旦有数据到达了就负责通知，这样就将一万个等待和阻塞转化为一个专门的函数来负责与管理。
多路复用技术应用于JAVA NIO的核心类库多路复用器Selector中，目前支持I/O多路复用的系统调用有select、pselect、poll、epoll，在linux编程中有一段时间一直在使用select做轮询和网络事件通知的，但是select支持一个进程打开的socket描述符（FD）收到了限制，一般为1024，由于这一限制，现在使用了epoll代替了select，而epoll支持一个进程打开的FD不受限制。
异步IO与同步IO的区别在于：同步IO是需要应用程序主动地循环去询问是否有数据，而异步IO是通过像select等IO多路复用函数来同时检测多个事件句柄来告知应用程序是否有数据。
了解了前面三种IO模式，在用户进程进行系统调用的时候，他们在等待数据到来的时候，处理的方式是不一样的，直接等待、轮询、select或poll轮询，两个阶段过程：
第一个阶段有的阻塞，有的不阻塞，有的可以阻塞又可以不阻塞。
第二个阶段都是阻塞的。
从整个IO过程来看，他们都是顺序执行的，因此可以归为同步模型，都是进程自动等待且向内核检查状态。
高并发的程序一般使用同步非阻塞模式，而不是多线程+同步阻塞模式。要理解这点，先弄明白并发和并行的区别：比如去某部门办事需要依次去几个窗口，办事大厅的人数就是并发数，而窗口的个数就是并行度。就是说并发是同时进行的任务数（如同时服务的http请求），而并行数就是可以同时工作的物理资源数量（如cpu核数）。通过合理调度任务的不同阶段，并发数可以远远大于并行度。这就是区区几个CPU可以支撑上万个用户并发请求的原因。在这种高并发的情况下，为每个用户请求创建一个进程或者线程的开销非常大。而同步非阻塞方式可以把多个IO请求丢到后台去，这样一个CPU就可以服务大量的并发IO请求。
IO多路复用究竟是同步阻塞还是异步阻塞模型，这里来展开说说：
同步是需要主动等待消息通知，而异步则是被动接受消息通知，通过回调、通知、状态等方式来被动获取消息。IO多路复用在阻塞到select阶段时，用户进程是主动等待并调用select函数来获取就绪状态消息，并且其进程状态为阻塞。所以IO多路复用是同步阻塞模式。
4、信号驱动式IO
应用程序提交read请求，调用system call，然后内核开始处理相应的IO操作，而同时，应用程序并不等内核返回响应，就会开始执行其他的处理操作（应用程序没有被IO阻塞），当内核执行完毕，返回read响应，就会产生一个信号或执行一个基于线程的回调函数来完成这次IO处理过程。在这里IO的读写操作是在IO事件发生之后由应用程序来完成。异步IO读写操作总是立即返回，而不论IO是否阻塞，因为真正的读写操作已经有内核掌管。也就是说同步IO模型要求用户代码自行执行IO操作（将数据从内核缓冲区移动用户缓冲区或者相反），而异步操作机制则是由内核来执行IO操作（将数据从内核缓冲区移动用户缓冲区或者相反）。可以这样认为，同步IO向应用程序通知的是IO就绪事件，而异步IO向应用程序通知的是IO完成事件。
5、异步IO
异步IO与上面的异步概念是一样的， 当一个异步过程调用发出后，调用者不能立刻得到结果，实际处理这个调用的函数在完成后，通过状态、通知和回调来通知调用者的输入输出操作。异步IO的工作机制是：告知内核启动某个操作，并让内核在整个操作完成后通知我们，这种模型与信号驱动的IO区别在于，信号驱动IO是由内核通知我们何时可以启动一个IO操作，这个IO操作由用户自定义的信号函数来实现，而异步IO模型是由内核告知我们IO操作何时完成。
3、epoll和poll有什么区别。
select poll每次循环调用时，都需要将描述符和文件拷贝到内核空间；epoll 只需要拷贝一次；
对于这种情况对于描述符数量不大还可以，但是当描述符的数量达到十几万甚至上百万的时候，效率就会急速降低，因为每一次轮询的时候都需要将这些所有的socket文件从用户态拷贝到内核态，会造成大量的浪费和资源开销；
select每次返回后，都需要遍历所有的描述文件才能找到就绪的，时间复杂度为O(n)，而epoll则需要O(1)；
select poll内核是通过内核方式来完成的，时间复杂度O(n)；epoll在每个描述文件上设置回调函数，时间复杂度为O(1)；
select相比poll没有太大的改进，唯一的区别就是使用链表来保存fd，使的能监听的数量远远大于1024，但对于将用户数据拷贝到内存空间，线性遍历fd这两个没有太大的改变。
1、epoll处理是事件触发，而poll是轮训方式；
2、打开的FDset限制：poll是1024.，epoll无限制；
3、poll系统调用数目增大时性能下降快
4、平时用到哪些Linux命令。
cd /root/Docements # 切换到目录/root/Docements
-a ：列出全部的文件，连同隐藏文件（开头为.的文件）一起列出来（常用）
-d ：仅列出目录本身，而不是列出目录的文件数据
-R ：连同子目录的内容一起列出（递归列出），等于该目录下的所有文件都会显示出来
cp -a file1 file2 #连同文件的所有特性把文件file1复制成文件file2
cp file1 file2 file3 dir #把文件file1、file2、file3复制到目录dir中
mv file1 file2 file3 dir # 把文件file1、file2、file3移动到目录dir中
mv file1 file2 # 把文件file1重命名为file2
rm -i file # 删除文件file，在删除之前会询问是否进行该操作
rm -fr dir # 强制删除目录dir中的所有文件
压缩：tar -jcv -f filename.tar.bz2 要被处理的文件或目录名称
查询：tar -jtv -f filename.tar.bz2
解压：tar -jxv -f filename.tar.bz2 -C 欲解压缩的目录
cat text | less # 查看text文件中的内容
5、用一行命令查看文件的最后五行。
Tail -n 5 filename
6、用一行命令输出正在运行的java进程。
ps -ef|grep java
7、介绍下你理解的操作系统中线程切换过程。
处理器总处于以下状态中的一种：
１、内核态，运行于进程上下文，内核代表进程运行于内核空间；
２、内核态，运行于中断上下文，内核代表硬件运行于内核空间；
３、用户态，运行于用户空间；
一个进程的上下文可以分为三个部分:用户级上下文、寄存器上下文以及系统级上下文。
用户级上下文: 正文、数据、用户堆栈以及共享存储区；
寄存器上下文: 通用寄存器、程序寄存器(IP)、处理器状态寄存器(EFLAGS)、栈指针(ESP)；
系统级上下文: 进程控制块task_struct、内存管理信息(mm_struct、vm_area_struct、pgd、pte)、内核栈。
当发生进程调度时，进行进程切换就是上下文切换(context switch).操作系统必须对上面提到的全部信息进行切换，新调度的进程才能运行。而系统调用进行的模式切换(mode switch)。模式切换与进程切换比较起来，容易很多，而且节省时间，因为模式切换最主要的任务只是切换进程寄存器上下文的切换。系统中的每一个进程都有自己的上下文。一个正在使用处理器运行的进程称为当前进程(current)。当前进程因时间片用完或者因等待某个事件而阻塞时，进程调度需要把处理器的使用权从当前进程交给另一个进程，这个过程叫做进程切换。此时，被调用进程成为当前进程。在进程切换时系统要把当前进程的上下文保存在指定的内存区域（该进程的任务状态段TSS中），然后把下一个使用处理器运行的进程的上下文设置成当前进程的上下文。当一个进程经过调度再次使用CPU运行时，系统要恢复该进程保存的上下文。所以，进程的切换也就是上下文切换。在系统内核为用户进程服务时，通常是进程通过系统调用执行内核代码，这时进程的执行状态由用户态转换为内核态。但是，此时内核的运行是为用户进程服务，也可以说内核在代替当前进程执行某种服务功能。在这种情况下，内核的运行仍是进程运行的一部分，所以说这时内核是运行在进程上下文中。内核运行在进程上下文中时可以访问和修改进程的系统数据。此外，若内核运行在进程上下文中需要等待资源和设备时，系统可以阻塞当前进程。
Linux下的线程实质上是轻量级进程(light weighted process),线程生成时会生成对应的进程控制结构，只是该结构与父线程的进程控制结构共享了同一个进程内存空间。 同时新线程的进程控制结构将从父线程（进程）处复制得到同样的进程信息，如打开文件列表和信号阻塞掩码等。创建线程比创建新进程成本低，因为新创建的线程使用的是当前进程的地址空间。相对于在进程之间切换，在线程之间进行切换所需的时间更少，因为后者不包括地址空间之间的切换。
线程切换上下文切换的原理与此类似，只是线程在同一地址空间中，不需要MMU等切换，只需要切换必要的CPU寄存器，因此，线程切换比进程切换快的多。
8、进程和线程的区别。
根本区别：进程是操作系统资源分配的基本单位，而线程是任务调度和执行的基本单位
在开销方面：每个进程都有独立的代码和数据空间（程序上下文），程序之间的切换会有较大的开销；线程可以看做轻量级的进程，同一类线程共享代码和数据空间，每个线程都有自己独立的运行栈和程序计数器（PC），线程之间切换的开销小。
所处环境：在操作系统中能同时运行多个进程（程序）；而在同一个进程（程序）中有多个线程同时执行（通过CPU调度，在每个时间片中只有一个线程执行）
内存分配方面：系统在运行的时候会为每个进程分配不同的内存空间；而对线程而言，除了CPU外，系统不会为线程分配内存（线程所使用的资源来自其所属进程的资源），线程组之间只能共享资源。
包含关系：没有线程的进程可以看做是单线程的，如果一个进程内有多个线程，则执行过程不是一条线的，而是多条线（线程）共同完成的；线程是进程的一部分，所以线程也被称为轻权进程或者轻量级进程。
9、top 命令之后有哪些内容，有什么作用。
1.系统的负载
2.进程的状态
3.cpu各个状态的百分比
4.内存的使用状况
5.swap(交换区)的使用状况
10、线上CPU爆高，请问你如何找到问题所在。
1、命令：top
说明：输入大写P，对占用cpu的进程进行排序，查看哪个进程占用的cpu最高，找到占用cpu最高的进程pid。
2、命令：jps
说明：查看占用cpu最高的进程对应的哪个服务
3、命令：top -Hp pid
说明：找到这个进程中占用cpu最高的线程
4、命令：printf %x tid
说明：将线程id转换成16进制，前面再加上0x
5、命令：jstack pid<开始的进程id> | grep 0xtid<0x加上上一步转换出来的线程id>
说明：打印出这个线程的信息，有线程的名称，线程id(tid)，操作系统对应的线程id(nid)
总结：
对于jstack日志，我们要着重关注如下关键信息
Deadlock：表示有死锁
Waiting on condition：等待某个资源或条件发生来唤醒自己。具体需要结合jstacktrace来分析，比如线程正在sleep，网络读写繁忙而等待
Blocked：阻塞
Waiting on monitor entry：在等待获取锁
如果说系统慢，那么要特别关注Blocked,Waiting on condition
如果说系统的cpu耗的高，那么肯定是线程执行有死循环，那么此时要关注下Runable状态。
5、多线程
1、多线程的几种实现方式，什么是线程安全。
1.继承Thread类，重写run方法
2.实现Runnable接口，重写run方法，实现Runnable接口的实现类的实例对象作为Thread构造函数的target
3.通过Callable和FutureTask创建线程
4.通过线程池创建线程
前面两种可以归结为一类：无返回值，原因很简单，通过重写run方法，run方式的返回值是void，所以没有办法返回结果
后面两种可以归结成一类：有返回值，通过Callable接口，就要实现call方法，这个方法的返回值是Object，所以返回的结果可以放在Object对象中
线程安全就是多线程访问时，采用了加锁机制，当一个线程访问该类的某个数据时，进行保护，其他线程不能进行访问直到该线程读取完，其他线程才可使用。不会出现数据不一致或者数据污染。
2、volatile的原理，作用，能代替锁么。
作用：保持内存可见性防止指定重排序
原理：
每次变量读取前必须先从主内存刷新最新值，每次写入后必须同步回主内存中。
编译器在生成字节码时，会在指令排序中插入内存屏障来禁止特定类型的处理器重排序。
volatile不能代替锁，其不具有 原子性操作。例如：变量自增操作。
3、画一个线程的生命周期状态图。
生命周期图详见笔记中 线程生命周期图.jpg
1、新建状态（New）
用new关键字和Thread类或其子类建立一个线程对象后，该线程对象就处于新生状态。处于新生状态的线程有自己的内存空间，通过调用start方法进入就绪状态（runnable）。
注意：不能对已经启动的线程再次调用start()方法，否则会出现java.lang.IllegalThreadStateException异常。
2、就绪状态（Runnable）
处于就绪状态的线程已经具备了运行条件，但还没有分配到CPU，处于线 程就绪队列（尽管是采用队列形式，事实上，把它称为可运行池而不是可运行队列。因为cpu的调度不一定是按照先进先出的顺序来调度的），等待系统为其分配 CPU。等待状态并不是执行状态，当系统选定一个等待执行的Thread对象后，它就会从等待执行状态进入执行状态，系统挑选的动作称之为“cpu调 度”。一旦获得CPU，线程就进入运行状态并自动调用自己的run方法。
提示：如果希望子线程调用start()方法后立即执行，可以使用Thread.sleep()方式使主线程睡眠一伙儿，转去执行子线程。
3、运行状态（Running）
处于运行状态的线程最为复杂，它可以变为阻塞状态、就绪状态和死亡状态。
处于就绪状态的线程，如果获得了cpu的调度，就会从就绪状态变为运行状态，执行run()方法中的任务。如果该线程失去了cpu资源，就会又从运 行状态变为就绪状态。重新等待系统分配资源。也可以对在运行状态的线程调用yield()方法，它就会让出cpu资源，再次变为就绪状态。
当发生如下情况是，线程会从运行状态变为阻塞状态：
①、线程调用sleep方法主动放弃所占用的系统资源
②、线程调用一个阻塞式IO方法，在该方法返回之前，该线程被阻塞
③、线程试图获得一个同步监视器，但更改同步监视器正被其他线程所持有
④、线程在等待某个通知（notify）
⑤、程序调用了线程的suspend方法将线程挂起。不过该方法容易导致死锁，所以程序应该尽量避免使用该方法。
当线程的run()方法执行完，或者被强制性地终止，例如出现异常，或者调用了stop()、desyory()方法等等，就会从运行状态转变为死亡状态。
4、阻塞状态（Blocked）
处于运行状态的线程在某些情况下，如执行了sleep（睡眠）方法，或等待I/O设备等资源，将让出CPU并暂时停止自己的运行，进入阻塞状态。阻塞的情况分三种：
（一）、等待阻塞：运行的线程执行wait()方法，JVM会把该线程放入等待池中。
（二）、同步阻塞：运行的线程在获取对象的同步锁时，若该同步锁（synchronized）被别的线程占用，则JVM会把该线程放入锁池中。
（三）、其他阻塞：运行的线程执行sleep()或join()方法，或者发出了I/O请求时，JVM会把该线程置为阻塞状态。当sleep()状态超时、join()等待线程终止或者超时、或者I/O处理完毕时，线程重新转入就绪状态。
在阻塞状态的线程不能进入就绪队列。只有当引起阻塞的原因消除时，如睡眠时间已到，或等待的I/O设备空闲下来，线程便转入就绪状态，重新到就绪队列中排队等待，被系统选中后从原来停止的位置开始继续运行。有三种方法可以暂停Threads执行。
5、死亡状态（Dead）
需要说明的是，synchronized锁和调用wait()的对象应为同一对象！否则会报java.lang.IllegalMonitorStateException错误。
4、sleep和wait的区别。
sleep是线程方法，wait是Object 方法
sleep不释放lock， wait会释放
sleep不依赖同步方法，wait需要
sleep不需要被唤醒，wait需要
5、sleep和sleep(0)的区别。
在线程没退出之前，线程有三个状态，就绪态，运行态，等待态。当线程调用sleep(n)的时候，线程是由运行态转入等待态，线程被放入等待队列中，等待定时器n秒后的中断事件，当到达n秒计时后，线程才重新由等待态转入就绪态，被放入就绪队列中，等待队列中的线程是不参与cpu竞争的，只有就绪队列中的线程才会参与cpu竞争
而sleep(0)之所以马上回去参与cpu竞争，是因为调用sleep(0)后，因为0的原因，线程直接回到就绪队列，而非进入等待队列，只要进入就绪队列，那么它就参与cpu竞争
6、Lock与Synchronized的区别 。
synchronized是java内置关键字，在jvm层面，Lock是个java类；
synchronized无法判断是否获取锁的状态，Lock可以判断
sysnchronized会自动释放锁，Lock需要在finally中手工释放锁
sysnchronized 的锁可重入、不可中断、非公平，Lock锁可重入、可中断、可公平（两者皆可）
7、synchronized的原理是什么，一般用在什么地方(比如加在静态方法和非静态方法的区别，静态方法和非静态方法同时执行的时候会有影响吗)，解释以下名词：重排序，自旋锁，偏向锁，轻量级锁，可重入锁，公平锁，非公平锁，乐观锁，悲观锁。
原理
在java中任何一个对象都有一个监视器(Monitor)与之对应,当一个Monitor被持有后，该对象处于锁定状态。synchronized在JVM里的实现都是基于进入和退出monitor对象来实现方法的同步和代码块同步
1)MonitorEnter指令：插入在同步代码块开始位置，当代码执行到该指令时，将会尝试获取该对象monitor的所有权，即尝试获得该对象的锁。
2)MonitorExit指令：插入在方法结束处和异常处，jvm保证每个MonitorEnter必须有对应的MonitorExit.
影响
synchronized 加在静态方法上是锁住整个类的，针对的是类。synchronized加在非静态方法上是锁住类的对象上，是针对对象的，对象之间没有影响。静态方法和非静态方法同时执行的时候会产生互斥，是有影响的。
名词解释：
重排序：不改变单线程程序语义前提下，重新安排执行顺序
自旋锁：当一个线程在获取锁时，如果锁已经被其他线程获取，那么该线程将循环等待，然后不断的判断锁是否能够被成功获取，直到获取到锁才推出循环。
轻量级锁：线程在执行同步块之前，JVM会先在当前线程的栈帧中穿件用于存储锁记录的空间，并将锁对象的Mark Word复制到锁记录中。然后线程尝试用CAS将对象头中的Mark Work替换为指向锁记录的指针。如果成功，当先线程获得锁，如果失败自旋获取锁。再失败锁升级。
偏向锁：在轻量级锁的基础上继续优化无资源竞争的情况。偏向锁的目标是，减少无竞争且只有一个线程使用锁的情况下，使用轻量级锁产生的性能消耗。偏向锁只有在初始化时需要一次CAS，将Mark Word中记录ower,如果记录成功，则偏向锁获取成功，记录状态为偏向锁，以后当前线程等于owner就可以直接获取锁。否做，索命有其他线程竞争，升级为轻量级锁。
可重入锁：可重入就是说某个线程已经获得某个锁，可以再次获取锁而不会出现死锁
公平锁：加锁前先查看是否有排队等待的线程，优先处理排在前边的线程
非公平锁：线程加锁时直接尝试获取锁，获取不到自动到队尾等待
乐观锁：假设不会发生并发冲突，直接不加锁去操作，如果冲突直接返回(CAS)
悲观锁：假设一定会发生并发冲突，通过阻塞其他线程来保证数据完整性
8、用过哪些原子类，他们的原理是什么。
java.util.concurrent 包下提供了一些原子类：AtomicInteger、AtomicLong
原子类中通过引入CAS机制，结束属性偏移量计算预期值。并配合volatile,保证属性原子性。
基本原子类
布尔型：AtomicBoolean
整型：AtomicInteger
长整形：AtomicLong
Java使用锁机制和CAS来实现原子操作。
1.锁机制实现原子操作，JVM内部实现了很多锁，比如偏向锁，轻量级锁，重量级锁和互斥锁。
2.CAS来实现原子操作，实现原理就是通过循环执行CAS操作直到成功为止。Java的并发包中提供了一些Atomic类来支持原子操作。其实CAS操作有些问题，比如ABA问题，循环时间长和共享变了的原子操作。
1）ABA问题，可以通过AtomicStampedReference类解决，思路就是加版本号或者时间戳。
2）共享变了的原子操作。CAS可以实现一个变量的原子操作，但是不能保证多个共享变量的原子操作。自从Java 1.5起，提供了一个AtomicReference类来实现对象之间的原子性，多个共享变量可以放到一个对象里面实现原子性。
9、JUC下研究过哪些并发工具，讲讲原理。
CountDownLatch :通过基数阻塞线程等待，内部通过lock实现。
CyclicBarrier： 循环栅栏，一组线程到达临界点后恢复执行
Exchange: 线程交换器。用于两个线程的数据交换，当Exchange只有一个线程时，该线程会阻塞直到有别的线程调用exchange缓冲区，当前线程与新线交换数据后同时恢复运行。
Semaphore：信号量。类似生产消费模式。
10、用过线程池吗，如果用过，请说明原理，并说说newCache和newFixed有什么区别，构造函数的各个参数的含义是什么，比如coreSize，maxsize等。
原理:
线程池刚创建时，里面没有一个线程。任务队列是作为参数传进来的。不过，就算队列里面有任务，线程池也不会马上执行它们。
当调用 execute() 方法添加一个任务时，线程池会做如下判断
1、如果正在运行的线程数量小于 corePoolSize，那么马上创建线程运行这个任务
2、如果正在运行的线程数量大于或等于 corePoolSize，那么将这个任务放入队列
3、如果这时候队列满了，而且正在运行的线程数量小于 maximumPoolSize，那么还是要创建非核心线程立刻运行这个任务
4、如果队列满了，而且正在运行的线程数量大于或等于 maximumPoolSize，那么线程池会抛出异常RejectExecutionException
当一个线程完成任务时，它会从队列中取下一个任务来执行。
当一个线程无事可做，超过一定的时间（keepAliveTime）时，线程池会判断，如果当前运行的线程数大于 corePoolSize，那么这个线程就被停掉。所以线程池的所有任务完成后，它最终会收缩到 corePoolSize 的大小。
newCache和newFixed的区别:
newCache创建一个可缓存线程池，如果线程池长度超过处理需要，可灵活回收空闲线程，若无可回收，则新建线程。
newFixed创建一个定长线程池，可控制线程最大并发数，超出的线程会在队列中等待。
coreSize:线程池维护线程的最少数量
maxsize:线程池维护线程的最大数量
11、线程池的关闭方式有几种，各自的区别是什么。
shutdown:
1、调用之后不允许继续往线程池内继续添加线程;
2、线程池的状态变为SHUTDOWN状态;
3、所有在调用shutdown()方法之前提交到ExecutorSrvice的任务都会执行;
4、一旦所有线程结束执行当前任务，ExecutorService才会真正关闭。
shutdownNow():
1、该方法返回尚未执行的 task 的 List;
2、线程池的状态变为STOP状态;
3、阻止所有正在等待启动的任务, 并且停止当前正在执行的任务。
简单点来说，就是:
shutdown()调用后，不可以再 submit 新的 task，已经 submit 的将继续执行
shutdownNow()调用后，试图停止当前正在执行的 task，并返回尚未执行的 task 的 list
12、假如有一个第三方接口，有很多个线程去调用获取数据，现在规定每秒钟最多有10个线程同时调用它，如何做到。
借助Executors的计划线程池ScheduledThreadPoolExecutor 设置定时，进行调度。
public ScheduledThreadPoolExecutor(int corePoolSize,ThreadFactory threadFactory) {
super(corePoolSize, Integer.MAX_VALUE, 0, TimeUnit.NANOSECONDS,new DelayedWorkQueue(), threadFactory);
}
13、spring的controller是单例还是多例，怎么保证并发的安全。
controller默认是单例的，不要使用非静态的成员变量，否则会发生数据逻辑混乱。正因为单例所以不是线程安全的。
解决方案
1、不要在controller中定义成员变量。
2、万一必须要定义一个非静态成员变量时候，则通过注解@Scope(“prototype”)，将其设置为多例模式。
3、在Controller中使用ThreadLocal变量
14、用三个线程按顺序循环打印abc三个字母，比如abcabcabc。
基本思路
使用同步块和wait、notify的方法控制三个线程的执行次序。具体方法如下：从大的方向上来讲，该问题为三线程间的同步唤醒操作，主要的目的就是ThreadA->ThreadB->ThreadC->ThreadA循环执行三个线程。为了控制线程执行的顺序，那么就必须要确定唤醒、等待的顺序，所以每一个线程必须同时持有两个对象锁，才能进行打印操作。一个对象锁是prev，就是前一个线程所对应的对象锁，其主要作用是保证当前线程一定是在前一个线程操作完成后（即前一个线程释放了其对应的对象锁）才开始执行。还有一个锁就是自身对象锁。主要的思想就是，为了控制执行的顺序，必须要先持有prev锁（也就前一个线程要释放其自身对象锁），然后当前线程再申请自己对象锁，两者兼备时打印。之后首先调用self.notify()唤醒下一个等待线程（注意notify不会立即释放对象锁，只有等到同步块代码执行完毕后才会释放），再调用prev.wait()立即释放prev对象锁，当前线程进入休眠，等待其他线程的notify操作再次唤醒。
方法1:synchronized 搭配wait/notify实现
public class ABC_Synch {
public static class ThreadPrinter implements Runnable {
private String name;
private Object prev;
private Object self;
private ThreadPrinter(String name, Object prev, Object self) {
this.name = name;
this.prev = prev;
this.self = self;
}
@Override
public void run() {
int count = 10;
while (count > 0) {// 多线程并发，不能用if，必须使用whil循环
synchronized (prev) { // 先获取 prev 锁
synchronized (self) {// 再获取 self 锁
System.out.print(name);//打印
count--;
self.notifyAll();// 唤醒其他线程竞争self锁，注意此时self锁并未立即释放。
}
//此时执行完self的同步块，这时self锁才释放。
try {
prev.wait(); // 立即释放 prev锁，当前线程休眠，等待唤醒
/**
* JVM会在wait()对象锁的线程中随机选取一线程，赋予其对象锁，唤醒线程，继续执行。
*/
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
}
public static void main(String[] args) throws Exception {
Object a = new Object();
Object b = new Object();
Object c = new Object();
ThreadPrinter pa = new ThreadPrinter("A", c, a);
ThreadPrinter pb = new ThreadPrinter("B", a, b);
ThreadPrinter pc = new ThreadPrinter("C", b, c);
new Thread(pa).start();
Thread.sleep(10);//保证初始ABC的启动顺序
new Thread(pb).start();
Thread.sleep(10);
new Thread(pc).start();
Thread.sleep(10);
}
}
方法2:lock锁方式
public class ThreadPrintType2 {
static Lock lock = new ReentrantLock();
static int state = 0;
static class ThreadA extends Thread{
@Override
public void run() {
for (int i= 0;i<3;){
try {
lock.lock();
while (state%3 == 0){
System.out.print("a");
state++;
i++;
}
}finally {
lock.unlock();
}
}
}
}
static class ThreadB extends Thread{
@Override
public void run() {
for (int i= 0;i<3;){
try {
lock.lock();
while (state%3 == 1){
System.out.print("b");
state++;
i++;
}
}finally {
lock.unlock();
}
}
}
}
static class ThreadC extends Thread{
@Override
public void run() {
for (int i= 0;i<3;){
try {
lock.lock();
while (state%3 == 2){
System.out.print("c");
state++;
i++;
}
}finally {
lock.unlock();
}
}
}
}
public static void main(String[] args) {
new ThreadA().start();
new ThreadB().start();
new ThreadC().start();
}
15、ThreadLocal用过么，用途是什么，原理是什么，用的时候要注意什么。
实例变量如果涉及到多线程操作导致线程安全问题，可以借助ThreadLocal,其提供线程变量副本，隔离线程之间的影响。其常用来解决数据库连接、session管理的问题。
Thread为每个线程维护了一个map:ThreadLocalMap.该map的key是LocalThread,value则是要存储的对象。ThreadLocal本身并不存储值，它只是作为一个key来让线程从ThreadLocalMap获取value
ThreadLocalMap使用的是ThreadLocal的弱引用作为key，如果一个ThreadLocal没有外部引用，待系统gc时，该弱引用被回收，map中key值为null,而与之对应的value会一致维持一个强引用链无法回收，造成内存泄漏。使用时应该注意调用remove函数，手动清除。
16、如果让你实现一个并发安全的链表，你会怎么做。
在链表实现的基础上加锁，所有设计到链表结构变化的地点加锁，例如，新增，删除等操作。例如：借助ReentrantLock()可重入锁对新增结点加锁，避免冲突。
public class ConcurrentSingleLinedList{
final static Lock lock = new ReentrantLock();
Node head = null;
static class Node {
Node next = null;
int data;
public Node(int data){
this.data = data;
}
}
public void add(int data) {
try {
lock.lock();
Node newNode = new Node(data);
if(head == null){
head = newNode;
return;
}
Node temp = head;
while(temp.next != null){
temp = temp.next;
}
temp.next = newNode;
}finally {
lock.unlock();
}
}
}
17、有哪些无锁数据结构，他们实现的原理是什么。
java.util.concurrent.atomic 提供了AtomicInteger、AtomicLong、AtomicIntegerArray 等一系列的类，提供了一系列的原子操作。其实现借助于CAS：对比变量的值和expect是否相等，如果相等则将变量的值更新为update。
18、讲讲java同步机制的wait和notify。
wait()：使调用该方法的线程释放共享资源锁，然后从运行状态退出，进入等待队列，直到被再次唤醒。
notify()：随机唤醒等待队列中等待同一共享资源的一个线程，并使该线程退出等待队列，进入可运行状态，也就是notify()方法仅通知一个线程。
java中 wait()和notify()方法都是Object方法。从功能上来说wait就是说线程在获取对象锁后，主动释放对象锁，同时本线程休眠。知道有其他线程调用对象notify()唤醒该线程，才能继续获取对象所，并继续执行。相应的notify()就是对象锁的唤醒操作。wait()和notify()需要在同步锁中。
19、CAS机制是什么，如何解决ABA问题。
CAS有3个操作数，内存值V，旧的预期值A，要修改的新值B。当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则什么都不做。
其实CAS是Java乐观锁的一种实现机制，在Java并发包中，大部分类就是通过CAS机制实现的线程安全，它不会阻塞线程，如果更改失败则可以自旋重试，但是它也存在很多问题：
1：ABA问题，也就是说从A变成B，然后就变成A，但是并不能说明其他线程并没改变过它，利用CAS就发现不了这种改变。
2：由于CAS失败后会继续重试，导致一致占用着CPU。
CAS：当需要更新一个变量的值得时候，只有当变量的预期值和内存地址中实际值相同的时候，才会把内存地址对应的值替换。
ABA：CAS比较的是两个时间节点的变量值变化，而在这两个时间节点内的变化并不关心，由此引发了目标值时A，但是过程有可能是 A-B-A。结果一样，过程不一定一致。解决该问题可以给操作添加版本号，jdk的atomic包里提供了一个类AtomicStampedReference来接榫ABA问题。
20、多线程如果线程挂住了怎么办。
如果是wait()方法使线程过期，可以使用notify（）和notifyAll()唤醒
如果是suspend挂起，可以通过resume方法唤醒。
根据具体情况（sleep,wait），酌情选择notifyAll，notify进行线程唤醒。
sleep()：使当前线程睡眠一段时间，没有释放锁，睡眠时间到了会继续执行，例如sleep（600）,使线程睡眠6秒。不释放资源，可以使用在任何方法中，sleep必须捕获异常。
wait()：释放锁。其他线程可以使用此同步块或方法。不必捕获异常。
notify():唤醒一个处于等待的线程，但是不确定唤醒哪一个。
notifyall():唤醒在此对象监视器上等待的所有线程。
21、countdowlatch和cyclicbarrier的内部原理和用法，以及相互之间的差别(比如countdownlatch的await方法和是怎么实现的)。
1、CountDownLatch
一个非常典型的应用场景是：有一个任务想要往下执行，但必须要等到其他的任务执行完毕后才可以继续往下执行。假如我们这个想要继续往下执行的任务调用一个CountDownLatch对象的await()方法，其他的任务执行完自己的任务后调用同一个CountDownLatch对象上的countDown()方法，这个调用await()方法的任务将一直阻塞等待，直到这个CountDownLatch对象的计数值减到0为止。
CountDownLatch强调的是一个线程（或多个）需要等待另外的n个线程干完某件事情之后才能继续执行。 上述例子，main线程是裁判，5个AWorker是跑步的。运动员先准备，裁判喊跑，运动员才开始跑（这是第一次同步，对应begin）。5个人谁跑到终点了，countdown一下，直到5个人全部到达，裁判喊停（这是第二次同步，对应end），然后算时间。
2、使用cyclicbarrier
定义：是一个同步辅助类，它允许一组线程互相等待，直到到达某个公共的屏障点，所有线程一起继续执行或者返回。一个特性就是CyclicBarrier支持一个可选的Runnable命令，在一组线程中的最后一个线程到达之后，该命令只在每个屏障点运行一次。若在继续所有参与线程之前更新此共享状态，此屏障操作很有用。
用法：用计数 N 初始化CyclicBarrier, 每调用一次await，线程阻塞，并且计数+1（计数起始是0），当计数增长到指定计数N时，所有阻塞线程会被唤醒。继续调用await也将迅速返回。
CyclicBarrier强调的是n个线程，大家相互等待，只要有一个没完成，所有人都得等着。正如上例，只有5个人全部跑到终点，大家才能开喝，否则只能全等着。
这样应该就清楚一点了，对于CountDownLatch来说，重点是那个“一个线程”, 是它在等待， 而另外那N的线程在把“某个事情”做完之后可以继续等待，可以终止。而对于CyclicBarrier来说，重点是那N个线程，他们之间任何一个没有完成，所有的线程都必须等待。
简单来说:
CountDownLatch: 一个线程等待其他多个线程完成一件事，才可以继续执行。
CyclicBarrier:线程之间相互等待，当所有线程都await之后，这些线程才继续执行。
CountDownLatch减计数，CyclicBarrier加计数。CountDownLatch是一次性的，CyclicBarrier可以重用。
await() 方法，初始化一个队列，将需要等待的线程加入队列中，并用waitStatus标记后继节点的线程状态。
22、对AbstractQueuedSynchronizer了解多少，讲讲加锁和解锁的流程，独占锁和公平所加锁有什么不同。
独占锁和共享锁：独占锁模式下，每次只能有一个线程能持有锁，如：ReetrantLock。共享锁：允许多个线程同时获取锁，并发访问共享资源，如：ReadWriteLock.
公平锁和非公平锁：在公平锁上，线程将按他们发出请求的顺序来获得锁；而非公平锁则允许在线程发出请求后立即尝试获取锁，如果可用则直接获取锁，尝试失败才进行排队等待。
AQS是一个双向链表。其每个节点中都包含了一个线程和一个类型变量，表示当前节点是独占节点还是共享节点，头节点中的线程为正在占有锁的线程，而后的所有节点的线程表示为正在等待获取锁的线程。
23、使用synchronized修饰静态方法和非静态方法有什么区别。
在Java中，synchronized是用来表示同步的，我们可以synchronized来修饰一个方法。也可以synchronized来修饰方法里面的一个语句块。那么，在static方法和非static方法前面加synchronized到底有什么不同呢？大家都知道，static的方法属于类方法，它属于这个Class（注意：这里的Class不是指Class的某个具体对象），那么static获取到的锁，是属于类的锁。而非static方法获取到的锁，是属于当前对象的锁。所以，他们之间不会产生互斥。
-
当synchronized修饰一个static方法时，多线程下，获取的是类锁（即Class本身，注意：不是实例），作用范围是整个静态方法，作用的对象是这个类的所有对象。
-
当synchronized修饰一个非static方法时，多线程下，获取的是对象锁（即类的实例对象），作用范围是整个方法，作用对象是调用该方法的对象。
结论：类锁和对象锁不同，他们之间不会产生互斥。
简单的说:
对于类锁synchronized static，是通过该类直接调用加类锁的方法，而对象锁是创建对象调用加对象锁的方法，两者访问是不冲突的
24、简述ConcurrentLinkedQueue和LinkedBlockingQueue的用处和不同之处。
LinkedBlockingQueue 是阻塞队列。实现是线程安全的，实现了先进先出等特性，是作为生产者消费者的首选
ConcurrentLinkedQueue 是非阻塞队列。当许多线程共享访问一个公共集合时时一个好的选择，其采用CAS操作保证元素一致性。
25、导致线程死锁的原因？怎么解除线程死锁。
原因
多个线程同时被阻塞，它们中的一个或者全部都在等待某个资源被释放，而该资源又被其他线程锁定，从而导致每一个线程都得等其它线程释放其锁定的资源，造成了所有线程都无法正常结束。这是从网上其他文档看到的死锁产生的四个必要条件：
1、互斥使用，即当资源被一个线程使用(占有)时，别的线程不能使用。
2、不可抢占，资源请求者不能强制从资源占有者手中夺取资源，资源只能由资源占有者主动释放。
3、请求和保持，即当资源请求者在请求其他的资源的同时保持对原有资源的占有。
4、循环等待，即存在一个等待队列：P1占有P2的资源，P2占有P3的资源，P3占有P1的资源。这样就形成了一个等待环路。
如何避免死锁
1）加锁顺序(线程按照一定的顺序加锁
2）加锁时限(线程获取锁的时候加上一定的时限，超过时限则放弃对该锁的请求，并释放自己占有的锁)
死锁的解决办法
如果发生了死锁，那么只要破坏死锁 4 个必要条件之一中的任何一个，死锁问题就能被解决。下面就是对于上面这些必要条件所作出的推想
（1）如果想要打破互斥条件，我们需要允许进程同时访问某些资源，这种方法受制于实际场景，不太容易实现条件；
（2）打破不可抢占条件，这样需要允许进程强行从占有者那里夺取某些资源，或者简单一点理解，占有资源的进程不能再申请占有其他资源，必须释放手上的资源之后才能发起申请，这个其实也很难找到适用场景；
（3）进程在运行前申请得到所有的资源，否则该进程不能进入准备执行状态。这个方法看似有点用处，但是它的缺点是可能导致资源利用率和进程并发性降低；
（4）避免出现资源申请环路，即对资源事先分类编号，按号分配。这种方式可以有效提高资源的利用率和系统吞吐量，但是增加了系统开销，增大了进程对资源的占用时间。
如果我们在死锁检查时发现了死锁情况，那么就要努力消除死锁，使系统从死锁状态中恢复过来。消除死锁的几种方式：
（1）最简单、最常用的方法就是进行系统的重新启动，不过这种方法代价很大，它意味着在这之前所有的进程已经完成的计算工作都将付之东流，包括参与死锁的那些进程，以及未参与死锁的进程；
（2）撤消进程，剥夺资源。终止参与死锁的进程，收回它们占有的资源，从而解除死锁。这时又分两种情况：一次性撤消参与死锁的全部进程，剥夺全部资源；或者逐步撤消参与死锁的进程，逐步收回死锁进程占有的资源。一般来说，选择逐步撤消的进程时要按照一定的原则进行，目的是撤消那些代价最小的进程，比如按进程的优先级确定进程的代价；考虑进程运行时的代价和与此进程相关的外部作业的代价等因素；
（3）进程回退策略，即让参与死锁的进程回退到没有发生死锁前某一点处，并由此点处继续执行，以求再次执行时不再发生死锁。虽然这是个较理想的办法，但是操作起来系统开销极大，要有堆栈这样的机构记录进程的每一步变化，以便今后的回退，有时这是无法做到的。
26、非常多个线程（可能是不同机器），相互之间需要等待协调，才能完成某种工作，问怎么设计这种协调方案。
个人认为可以参考countdownlatch中await实现，借助队列协调线程之间状态。
27、用过读写锁吗，原理是什么，一般在什么场景下用。
对于多个线程共享同一个资源的时候，多个线程同时对共享资源做读操作是不会发生线程安全性问题的，但是一旦有一个线程对共享数据做写操作其他的线程再来读写共享资源的话，就会发生数据安全性问题，所以出现了读写锁ReentrantReadWriteLock。
原理：如果有线程想申请读锁的话，首先会判断写锁是否被持有，如果写锁被持有且当前线程并不是持有写锁的线程，那么就会返回-1，获取锁失败，进入到等待队列等待。如果写锁未被线程所持有或者当前线程和持有写锁的线程是同一线程的话就会开始获取读锁。借助CAS来实现。
场景：大量读操作下，可以使用读写锁来并发处理。
28、开启多个线程，如果保证顺序执行，有哪几种实现方式，或者如何保证多个线程都执行完再拿到结果。
1、信号量Sephmore
public class SyncThreadTest {
private static Semaphore A = new Semaphore(1);
private static Semaphore B = new Semaphore(1);
private static Semaphore C = new Semaphore(1);
public static void main(String[] args) {
ThreadA a = new ThreadA();
ThreadB b = new ThreadB();
ThreadC c = new ThreadC();
try {
B.acquire();
C.acquire();
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
a.start();
b.start();
c.start();
System.out.print("over\n");
}
static class ThreadA extends Thread {
@Override
public void run() {
// TODO Auto-generated method stub
super.run();
try {
for(int i = 0; i < 10; i++) {
A.acquire();
System.out.print("thread a run" + i + "\n");
B.release();
}
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
static class ThreadB extends Thread {
@Override
public void run() {
// TODO Auto-generated method stub
super.run();
try {
for(int i = 0; i < 10; i++) {
B.acquire();
System.out.print("thread b run" + i + "\n");
C.release();
}
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
static class ThreadC extends Thread {
@Override
public void run() {
// TODO Auto-generated method stub
super.run();
try {
for(int i = 0; i < 10; i++) {
C.acquire();
System.out.print("thread c run" + i + "\n");
A.release();
}
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
}
2、使用ReentrantLock
public class SyncThreadTestReentrantLock {
private static Lock lock = new ReentrantLock();
private static int state = 0;
public static void main(String[] args) {
ThreadA a = new ThreadA();
ThreadB b = new ThreadB();
ThreadC c = new ThreadC();
a.start();
b.start();
c.start();
/*try {
a.join();
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
try {
b.join();
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
try {
c.join();
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}*/
System.out.print("over\n");
}
static class ThreadA extends Thread {
@Override
public void run() {
// TODO Auto-generated method stub
super.run();
int i = 0;
while(i < 10) {
//System.out.print("thread a begin \n");
lock.lock();
//System.out.print("thread a lock \n");
if (state % 3 == 0) {
System.out.print("thread a run" + "\n");
state++;
i++;
}
lock.unlock();
//System.out.print("thread a end \n");
}
}
}
static class ThreadB extends Thread {
@Override
public void run() {
// TODO Auto-generated method stub
super.run();
int i = 0;
while(i < 10) {
//System.out.print("thread b begin \n");
lock.lock();
//System.out.print("thread b lock \n");
if (state % 3 == 1) {
System.out.print("thread b run" + i + "\n");
state++;
i++;
}
lock.unlock();
//System.out.print("thread b end \n");
}
}
}
static class ThreadC extends Thread {
@Override
public void run() {
// TODO Auto-generated method stub
super.run();
int i = 0;
while(i < 10) {
//System.out.print("thread c begin \n");
lock.lock();
//System.out.print("thread c lock \n");
if (state % 3 == 2) {
System.out.print("thread c run" + i + "\n");
state++;
i++;
}
lock.unlock();
//System.out.print("thread c end \n");
}
}
}
}
3、ReetrantLock和Condition的组合
还可以使用condition, condition的效率可能会更高一些, await会释放lock锁, condition的await和signal与object的wait和notify方法作用类似
public class SyncThreadTestReentrantLock {
private static Lock lock = new ReentrantLock();
private static int state = 0;
private static Condition A = lock.newCondition();
private static Condition B = lock.newCondition();
private static Condition C = lock.newCondition();
public static void main(String[] args) {
ThreadA a = new ThreadA();
ThreadB b = new ThreadB();
ThreadC c = new ThreadC();
a.start();
b.start();
c.start();
/*try {
a.join();
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
try {
b.join();
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
try {
c.join();
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}*/
System.out.print("over\n");
}
static class ThreadA extends Thread {
@Override
public void run() {
// TODO Auto-generated method stub
super.run();
int i = 0;
lock.lock();
try {
while(i < 10) {
//System.out.print("thread a begin \n");
//System.out.print("thread a lock \n");
if (state % 3 == 0) {
System.out.print("thread a run" + "\n");
state++;
i++;
B.signal();
} else {
A.await();
}
//lock.unlock();
//System.out.print("thread a end \n");
}
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} finally {
lock.unlock();
}
}
}
static class ThreadB extends Thread {
@Override
public void run() {
// TODO Auto-generated method stub
super.run();
int i = 0;
lock.lock();
try {
while(i < 10) {
//System.out.print("thread a begin \n");
//System.out.print("thread a lock \n");
if (state % 3 == 1) {
System.out.print("thread b run" + "\n");
state++;
i++;
C.signal();
} else {
B.await();
}
//lock.unlock();
//System.out.print("thread a end \n");
}
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} finally {
lock.unlock();
}
}
}
static class ThreadC extends Thread {
@Override
public void run() {
// TODO Auto-generated method stub
super.run();
int i = 0;
lock.lock();
try {
while(i < 10) {
//System.out.print("thread a begin \n");
//System.out.print("thread a lock \n");
if (state % 3 == 2) {
System.out.print("thread c run" + "\n");
state++;
i++;
A.signal();
} else {
C.await();
}
//lock.unlock();
//System.out.print("thread a end \n");
}
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} finally {
lock.unlock();
}
}
}
}
保证多个线程都执行完再拿结果可以使用countdownlatch.
29、延迟队列的实现方式，delayQueue和时间轮算法的异同。
DelayQueue:位于java.util.concurrent包下,DelayQueue本质是封装了一个PriorityQueue，使之线程安全，加上Delay功能，也就是说，消费者线程只能在队列中的消息“过期”之后才能返回数据获取到消息，不然只能获取到null。其数据结构采用最小堆，插入和获取时，时间复杂度都为O(logN)
时间轮：是一种数据结构，其主体是一个循环列表（circular buffer），每个列表中包含一个称之为槽（slot）的结构。这个数据结构最重要的是两个指针，一个是触发任务的函数指针，另外一个是触发的总第几圈数。时间轮可以用简单的数组或者是环形链表来实现。相比DelayQueue的数据结构，时间轮在算法复杂度上有一定优势。DelayQueue由于涉及到排序，需要调堆，插入和移除的复杂度是O(lgn)，而时间轮在插入和移除的复杂度都是O(1)。
6、TCP与HTTP
1、http1.0和http1.1有什么区别。
在 HTTP/1.0 中,大多实现为每个请求/响应交换使用新的连接。在 HTTP/1.1 中,一个连接可用于一次或多次请求/响应交换,尽管连接可能由于各种原因被关闭.这是他们之间最大的分别.
1.http1.1提供身份认证（HTTP1.1提供一个基于口令的基本认证方式，）
2.http1.1提供永久性连接（即1.0使用非持久连接，一个tcp连接只传输一个web对象，服务器完成完请求后立即断开tcp连接，服务器不跟踪每个客户也记录过去的请求，显然，这就造成访问一个包含许多图像文件的网页文件的整个过程包含了多次请求和响应，每次请求和响应需要建立一个单独的连接。客户端每次建立和关闭建立都特别费时，而且会严重影响客户与服务器的性能。HTTP1.1采用持久连接，在一个tcp连接上传输多个HTTP请求和响应，减少建立连接和关闭连接的延时。一个包含很多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件和请求应答需要使用各自的连接，HTTP1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接受到客户端请求的先后顺序依次送回相应结果，以保证客户端能区分每次请求的相应内容。）
3.http1.1增加host头（HTTP1.0不支持host请求头字段，web浏览器无法使用主机头来明确表示服务器的哪个web站点。HTTP1.1增加Host请求头字段后，web浏览器可以使用主机头来明确表示要访问服务器上的那个web站点，这才实现了一台web服务器上可以在同一个IP地址和端口号上使用不同的主机名来创建多个虚拟的web站点）
4.还提供了身份认证，状态管理和cache缓存机制等相关的请求头和响应头。
HTTP / 1.1通过引入块传输编码解决了分隔消息正文的问题。发送者将消息主体分成任意长度的块，每个块都以其长度为前缀发送；它使用零长度的块标记消息的结尾。发送方使用Transfer-Encoding：分块标题来表示分块的使用。这种机制允许发送者在不增加太多复杂性或开销的情况下，缓冲消息的小片段而不是整个消息。所有HTTP / 1.1实现都必须能够接收分块的消息。块传输编码解决了另一个与性能无关的问题。在HTTP / 1.0中，如果发送方不包括Content-Length标头，则接收方无法确定由于传输问题消息是否已被截断。这种歧义会导致错误，尤其是当截断的响应存储在缓存中时。它使用零长度的块标记消息的结尾
2、TCP三次握手和四次挥手的流程，为什么断开连接要4次,如果握手只有两次，会出现什么。
【1】TCP三次握手：为了对每次发送的数据量进行跟踪与协商，确保数据段的发送和接收同步，根据所接收到的数据量而确认数据发送、接收完毕后何时撤消联系，并建立虚连接。
第一次握手：建立连接时，客户端发送 syn（Synchronize Sequence Numbers：同步序列编号）包（seq=j）到服务器，并进入SYN_SEND（请求连接）状态，等待服务器确认。
第二次握手：服务器接收到 syn包，必须确认客户的 SYN（ack=j+1）（ack：确认字符，表示发来的数据已确认接收无误），同时自己也发送一个 syn包（seq=k），既 SYN+ACK 包，此时服务器进入SYN_RECV（发送了ACK）状态。
第三次握手：客户端收到服务端发送的 SYN+ACK 包，向服务端发送确认包 ACK（ack=k+1），包发送完毕，客户端与服务器进入 ESTABLISHED（TCP连接成功）状态，完成三次握手。
【2】TCP四次挥手（连接终止协议，性质为终止协议）：
第一次挥手：TCP客户端发送一个FIN+ACK+SEQ，用来传输关闭客户端到服务端的数据。进入FIN_WAIT1状态。
第二次挥手：服务端收到FIN，被动发送一个ACK（SEQ+1），进入CLOSE_WAIT状态，客户端收到服务端发送的ACK，进入FIN_WAIT2状态。
第三次挥手：服务器关闭客户端连接，发送一个 FIN+ACK+SEQ 给客户端。进入 LAST_ACK 状态。
第四次挥手：客户端发送 ACK（ACK=SQE序号+1）报文确认，客户端进入 TIME_WAIT 状态，服务端收到 ACK 进入 CLOSE状态。
【3】由于TCP连接是双向的，因此每个方向都需要单独进行关闭。原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个FIN只意味着这一个方向上没有数据流动，一个 TCP连接到一个 FIN后仍能发送数据。首次执行FIN的一方主动关闭，另一方则执行被动关闭。当只握手两次时，就只会关闭主动发起的一端，另一个仍能发送数据。
3、TIME_WAIT和CLOSE_WAIT的区别。
CLOSE_WAIT：等待关闭，是被动关闭连接形成的，也就是第二次挥手时产生的状态。也就是当对方 Close 一个 SOCKET 后发送 FIN 报文给自己，系统会回应一个 ACK 报文给对方，此时进入CLOSE_WAIT状态。接着，我们需要考虑的事情是查看是否还有数据发送给对方，如果没有就可以 Close 这个链接，发送 FIN 给对方，也既关闭连接。所以在 CLOSE_WAIT 状态时，需要查看自己是否需要关闭连接。
TIME_WAIT：是主动关闭连接方形成的，表示收到了对方的 FIN 报文，并发送 ACK 报文，等待 2MSL（Maximum Segment Lifetime：报文最大生存时间）约4分钟时间后进入 CLOSE 状态。主要是防止最后一个 ACK 丢失，由于 TIME_WAIT 等待时间较长，因此 server 端尽量减少关闭。
4、说说你知道的几种HTTP响应码，比如200, 302, 404。
1xx：信息，请求收到，继续处理
2xx：成功，行为被成功地接受、理解和采纳
3xx：重定向，为了完成请求，必须进一步执行的动作
4xx：客户端错误，请求包含语法错误或者请求无法实现
5xx：服务器错误，服务器不能实现一种明显无效的请求
200 ok 一切正常
302 Moved Temporatily 文件临时移出
404 not found
5、当你用浏览器打开一个链接（如：http://www.javastack.cn）的时候，计算机做了哪些工作步骤。
1）、解析域名。
2）、发起 TCP 的 3 次握手。
3）、建立 TCP 请求后发起 HTTP 请求。
4）、服务器相应 HTTP 请求。
5）、浏览器得到 HTML 代码，进行解析和处理 JSON 数据，并请求 HTML 代码中的静态资源（JS、CSS、图片等）。
6）、浏览器对页面进行渲染。
6、TCP/IP如何保证可靠性，说说TCP头的结构。
1）、三次握手。
2）、将数据截断为合理的长度。应用数据被分割成 TCP 认为最合适发送的数据块。
3）、超时重发。
4）、对于收到的请求，给予确认响应。
5）、如果校验出数据包有错，则丢弃报文段，不响应。
6）、对失序数据进行重新排序，发送于客户端。
7）、能够丢弃重复数据。
8）、流量控制。TCP连接的两端都有缓存大小控制，接收端只允许发送端发送自己缓存剩余大小的数据。有效防止缓存溢出。
9）、拥塞控制。当网络阻塞时，减少数据的发送。
【TCP头结构】：
1）、源端口（source port）16 位的字段，定义了发送这个报文段的主机中的应用程序的端口号。
2）、目的端口（destination port）16 位的字段，定义了接收这个报文段的主机中的应用程序的端口号。
3）、序列号（sequence number）32 位的字段，定义了指派给本报文段第一个数据字节的编号。为了保证连接性，要发送的每一个字节都要编上号。序号可以告诉终点，报文段中的第一个字节是这个序列中的哪一个字节。在建立连接时，双方使用各自的随机数生成器生产一个初始序号（inital squence number，ISN），通常两个方向上的 ISN 是不同的。
4）、确认号（acknowledgment nimber）32 位字段定义了报文段的接收方期望从对方接收的字节编码。如果报文段的接收方成功地接收了对方发来的编号为x的字节，那么它就返回x+1作为确认号，确认可以和数据捎带在一起发送。
5）、头部长度（Hlen）（header length）这个4字节字段指出TCP段的头部长度，以32位字段来衡量，头部长度并不规定并可以根据选项字段中设置的参数面改变。
6）、保留（reserved）这个保留字段占用6位，它被保留以提供将来使用。
7）、URG 紧急数据（urgent data）—这是一条紧急信息。
8）、ACK 确认已收到段
9）、PSH 请求在缓冲区尚未填满时发送消息，注意TCP可以等待缓冲区填满之后再发送段，如果需要立即传送，应用程序必须利用push参数来通知协议。
10）、RST 申请重置连接。
11）、SYN 此消息用于在建立连接时同步传输数据的计时器。
12）、FIN 该属性申明发送端已经发送出被传输数据的最后一个字节。
13）、窗口大小（window）16位字段，这个字段定义的是发送TCP的窗口大小，以字节为单位。窗口最大长度是65535字节，这个值通常被称为接收窗口（rwnd）,并由接收方来决定。这种情况下，发送方必须服从接收方的指示。
14）、校验和（checksum）16位字段包含的是检验和，检验和是差错控制的手段之一。
15）、紧急指针（urgent point）该字段占用2字节，与URG代码位一起使用并且申明及时使存在着缓冲区溢出也必须紧急接收的数据末端。因此，如果有些数据需要不按照顺序被送往目的应用程序，那么发送端的应用程序必须利用紧急数据参数通知TCP。
16）、选项（option）该字段为变长且可以忽略。他的最大长度为3字节，用于解决一些辅助任务----比如，选择最大段长。选项可以位于TCP头部的末端，其长度必须是8的倍数。
17）、填充（padding）该字段长度不固定，这是个用于补充头部字段使得它的长度为32位字的整数倍的一个伪字段9
7、如何避免浏览器缓存。
缓存原理
浏览器第一次请求，服务器返回200，浏览器将服务器Response返回的缓存表识、缓存时间、数据保存。
第二次请求资源会在Request中携带缓存标识，先比较强缓存中cache-control的参数信息（不同参数不同请求）。
一般情况是设置的max-age，判断时间是否过期，没有过期直接读取（浏览器不支持HTTP1.1，则用expires判断是否过期），时间过期就使用对比缓存。
如果cache-control设置为no-cache，就直接使用对比缓存。
服务器在收到对比缓存的请求时，优先根据Etag值判断请求文件是否被修改，一致返回200，反之304。如果请求没有Etag，则将If-Modified-Since和被请求文件的最后修改时间做比对。
1、Cache-Control/Pragma这个HTTP Head字段用于指定所有缓存机制在整个请求/响应链中必须服从的指令，如果知道该页面是否为缓存，不仅可以控制浏览器，还可以控制和HTTP协议相关的缓存或代理服务器。
Cache-Control请求字段被各个浏览器支持得较好，而且它的优先级也比较高，它和其他一些请求字段（如Expires）同时出现时，Cache-Control会覆盖其他字段。Pragma字段的作用和Cache-Control有点类似，它也是在HTTP头中包含一个特殊的指令，使相关的服务器来遵守，最常用的就是Pragma:no-cache，它和Cache-Control:no-cache的作用是一样的。
2、Expires
Expires通常的使用格式是Expires:Sat,25Feb201212:22:17GMT，后面跟着一个日期和时间，超过这个时间值后，缓存的内容将失效，也就是浏览器在发出请求之前检查这个页面的这个字段，看该页面是否已经过期了，过期了就重新向服务器发起请求。
3、Last-Modified/EtagLast-Modified字段一般用于表示一个服务器上的资源的最后修改时间，资源可以是静态（静态内容自动加上Last-Modified字段）或者动态的内容（如Servlet提供了一个getLastModified方法用于检查某个动态内容是否已经更新），通过这个最后修改时间可以判断当前请求的资源是否是最新的。一般服务端在响应头中返回一个Last-Modified字段，告诉浏览器这个页面的最后修改时间，如Last-Modified:Sat,25Feb201212:55:04GMT，浏览器再次请求时在请求头中增加一个If-Modified-Since:Sat,25Feb 201212:55:04GMT字段，询问当前缓存的页面是否是最新的，如果是最新的就返回304状态码，告诉浏览器是最新的，服务器也不会传输新的数据。
4、与Last-Modified字段有类似功能的还有一个Etag字段，这个字段的作用是让服务端给每个页面分配一个唯一的编号，然后通过这个编号来区分当前这个页面是否是最新的。这种方式比使用Last-Modified更加灵活，但是在后端的Web服务器有多台时比较难处理，因为每个Web服务器都要记住网站的所有资源，否则浏览器返回这个编号就没有意义了。
8、如何理解HTTP协议的无状态性。
HTTP协议是无状态的，指的是HTTP协议对于事务处理没有记忆功能，服务器不知道客户端是什么状态。相当于，打开一个服务器上的网页与上一次打开这个服务器上的网页之间没有任何联系。HTTP是一个无状态的面向连接的协议，无状态不代表HTTP不能保持TCP连接，更不代表HTTP使用的是UDP协议（无连接）。
9、简述Http请求get和post的区别以及数据包格式。
【1】GET请求可被缓存，POST请求不能被缓存。
【2】GET请求被保留着浏览器历史记录中，POST请求不会被保留。
【3】GET请求能被收藏至书签中，POST请求不能被收藏至书签。
【4】GET请求不应在处理敏感数据时使用，POST可以用户处理敏感数据。
【5】 GET请求有长度限制，POST请求没有长度限制。
【6】POST不限制提交的数据类型，所以POST可以提交文件到服务器。
10、HTTP有哪些method
★ GET：获取资源。
★ POST：表单提交。
★ HEAD：获取报头信息，HEAD 方法与 GET 方法类似，但并不会返回响应主体。
★ PUT 与 PATCH：更新资源，PUT 对后台来说 PUT 方法的参数是一个完整的资源对象，它包含了对象的所有字段，PATCH 对后台来说 PATCH 方法的参数只包含我们需要修改的资源对象的字段。
★ DELETE：删除资源。
★ OPTIONS：获取目标资源所支持的通信选项,使用 OPTIONS 方法对服务器发起请求，以检测服务器支持哪些 HTTP 方法。
11、简述HTTP请求的报文格式。
【报文截图见笔记截图 POST请求报文.png、GET请求报文.png、响应报文.png】
客户端与服务端通信时传输的内容我们称之为报文。
客户端发送给服务器的称为”请求报文“，服务器发送给客户端的称为”响应报文“。
12、HTTP的长连接是什么意思。
长连接是指客户端与服务端建立连接后，不会因完成了一次请求后，它们之间的连接主动关闭。后续的读写操作会继续使用这个链接。 如果一个连接两小时内都没有任何动作，服务器会向客户端发送一个探测报文段、根据客户端主机相应探测4个客户端状态:
①、客户端正常时，且服务器可达。此时客户端TCP响应正常，服务器将定时器复位。
②、客户端已经崩溃，并且关闭或正在重启，客户端不能响应TCP，服务器将无法收到客户端对探测器的响应。服务器总共发送10个这样的探测，每间隔75秒。如服务器没有收到任何响应，他就认为客户端已经关闭并终止连接。
③、客户端崩溃，但已重启。服务器将对其保持探测响应，这个响应是一个复位，使得服务器终止这个连接。
④、 客户机正常运行，但是服务器不可达。这种与②类似。
由上可以看出，长连接可以省去较多的TCP建立和关闭操作，减少浪费，节约时间。对于频繁请求资源的客户端适合使用长连接。在长连接的应用场景下，client 端一般不会主动关闭连接，当 client 与 server 之间的连接一直不关闭，随着客户端连接越来越多，server 会保持过多连接。这时候 server 端需要采取一些策略，如关闭一些长时间没有请求发生的连接，这样可以避免一些恶意连接导致 server 端服务受损；如果条件允许则可以限制每个客户端的最大长连接数，这样可以完全避免恶意的客户端拖垮整体后端服务，例如：数据库的连接用长连接。
13、HTTPS的加密方式是什么，讲讲整个加密解密流程。
加密方式：
【1】对称密码算法：指加密和解密使用相同的密钥，速度高，可加密内容较大，用来加密会话过程中的消息。典型算法 DES、AES、RC5、IDEA（分组加密）RC4。
【2】非对称密码算法：又称为公钥加密算法，是指加密和解密使用不同的密钥，加密速度较慢，但能提供更好的身份认证技术，用来加密对称加密的密钥（公开的密钥用于加密，私有的密钥用于解密）典型的算法RSA、DSA、DH。
【3】散列算法：将文件内容通过此算法加密变成固定长度的值（散列值），这个过程可以使用密钥也可以不使用。这种散列变化是不可逆的，也就是说不能从散列值编程原文，因此散列变化通道常用语验证原文是否被篡改。典型的算法MD5、SHA、BASE64、CRC等。
注意：SSL协议在建立链路时，SSL首先对对称加密的密钥进行对公加密，链路建立好之后，SSL对传输内容使用对称加密。SSL加密过程：参考笔记 【单项认证.png】双向认证： 单向认证作为了解加密过程简化流程。
第三步：客户端使用服务端返回的信息验证服务器的合法性，包括：
1）、证书是否过期。
2）、发布服务器证书的CA是否可靠。
3）、返回的公钥是否能正确解开返回证书中的数字签名。
4）、服务器证书上的域名是否和服务器实际域名相匹配。
14、Http和https的三次握手有什么区别。
【截图详见笔记 Http握手流程.png】
题目2中所说的握手为 HTTP 握手的流程，Https 在 Http 的基础上加入了 SSL/TSL 协议，SSL 依靠证书来验证服务器的身份，并为服务器与浏览器之间的通信加密
15、什么是分块传送。
1）、分块传送是超文本协议HTTP中的一种传输机制，允许HTTP由网页服务器发送给客户端应用（通常是网页浏览器）的数据可以分成多个部分。分块传送只在HTTP/1.1中提供。HTTP应答消息中发送的数据是整个发送的，Content-Length消息头字段表示数据的长度。数据的长度很重要，因为客户端需要知道哪里是应答消息的结束，以及后续应答消息的开始。然而，使用分块传输编码，数据分解成一系列数据块，并以一个或多个块发送，这样服务器可以发送数据而不需要预先知道发送内容的总大小。通常数据块的大小是一致的，但也不总是这种情况。
2）、对于在发送HTTP头部前，无法计算出 Content-Length 的 HTTP 请求及回复（例如 WEB 服务端产生的动态内容），可以使用分块传输，使得不至于等待所有数据产生后，再发送带有 Content-Length 的 HTTP 头部，而是将已经产生的数据一块一块发送出去。
3）、HTTP BODY 数据成连续的块传输，每块数据的最开始处，指明了该数据块的大小，随后则是CRLF，数据，及结尾CRLF。可见每块数据都是包含在两个CRLF之间，最后一块数据则是0CRLFCRLF，两个CRLF之间没有任何数据；数据大小以16进制字符串表示（不是二进制）。
4）、客户端发送请求时，也可以使用分块传输，但是一般客户端发送请求前，不知道服务端是否支持分块传输，所以，客户端可以发送HTTP头部，表明使用分块传输，假如服务端不支持，将会回复 411(Length Required) 错误，中断请求。
16、Session和cookie的区别。
【1】Cookie 保存在客户端，未设置存储时间的 Cookie，关闭浏览器会话 Cookie 就会被删除；设置了存储时间的 Cookie 保存在用户设备的磁盘中直到过期，同时 Cookie 在客户端所以可以伪造，不是十分安全，敏感数据不易保存。Session 保存在服务器端，存储在 IIS 的进程开辟的内存中，而 Session 过多会消耗服务器资源，所以尽量少使用 Session。
【2】Session 是服务器用来跟踪用户的一种手段，每个 Session都有一个唯一标识：session ID。当服务端生成一个 Session 时就会向客户端发送一个 Cookie 保存到客户端，这个 Cookie 保存的是 Session 的 SessionID 这样才能保证客户端发起请求后，用户能够与服务器端成千上万的 Session 进行匹配，同时也保证了不同页面之间传值的正确性。
【3】存储数据类型不同：Session 能够存储任意的 Java 对象，Cookie 只能存储 String 类型的对象。
【4】大于10K 的数据，不要用到 Cookies。
7、架构设计与分布式
1、用java自己实现一个LRU。
【LRU结构图.png】
LRU（Least Recently Used：最近最少使用）：简单的说，就是保证基本的Cache容量，如果超过容量则必须丢掉最不常用的缓存数据，再添加最新的缓存。每次读取缓存都会改变缓存的使用时间，将缓存的存在时间重新刷新。其实，就是清理缓冲的一种策略。我们可以通过双向链表的数据结构实现 LRU Cache，链表头（head）保存最新获取和存储的数据值，链表尾（tail）既为最不常使用的值，当需要清理时，清理链表的 tail 即可，并将前一个元素设置为tail。结构图详见笔记LRU结构图.png
Java 代码实现：1）、通过原理的分析，我们可以维护一个双向链表结构，如下：LRUNode 实体类，主要理解 prev 和 next 属性，结合上面的链表结构图，就可以理解为，当此对象为 3 时 ， prev 应指向 2 ， next 应指向 4 。此类为下面类的类种类。
/**
* @ClassName: LRUNode
* @Description: 定义一个链表类，包含head(指针的上一个对象)，tail(指针的下一个对象)类种类
* @author: zzx
* @date: 2019年3月4日 下午10:32:58
*/
class LRUNode {
private String key;
private Object value;
//当前对象的上一个对象
LRUNode prev;
//当前对象的下一个对象
LRUNode next;
/**
* @param key value
* @desc 带有参数的构造器
*/
public LRUNode(String key,Object value) {
this.key=key;
this.value=value;
}
}
2）、我们通过 HashMap 实现一个缓存类 LRUCache ，我们通过逻辑处理，对最少使用的数据进行删除。代码如下：
/**
* @ClassName: LRUCache
* @Description: 实现 LRU策略 清除缓存（当缓存大小>=指定大小时）
* @author: zzx
* @date: 2019年3月4日 下午11:42:11
*/
public class LRUCache {
private int capacity;
/**
* @desc 用来存储 key 和 LRUNode对象 充当缓存，且 hashmap 中的数据不会自动清理，需要我们手动清理
*/
private HashMap<String, LRUNode> hashMap;
//数据链表 第一个对象
private LRUNode head;
//数据链表 最后一个对象
private LRUNode tail;
//带参数 capacity 缓存打下的构造器
public LRUCache(int capacity) {
this.capacity=capacity;
//创建对象时，创建一个hashmap 充当缓存
hashMap = new HashMap<String,LRUNode>();
}
/**
* @Description: 向链表中插入数据
* @return: void
*/
public void set(String key , Object value) {
//通过 key 查询链表中是否存在此对象
LRUNode lruNode = hashMap.get(key);
//缓存中有值时
if(lruNode != null) {
//为key 附新值，替换就值
lruNode.value = value;
//更新链表指针
appendTail(lruNode,false);
//缓存中无值时
}else {
//新对象
lruNode = new LRUNode(key, value);
//判断 hashMap 是否大于缓存大小
if(hashMap.size() >= capacity) {
appendTail(tail,true);
}
//存取新值
hashMap.put(key, lruNode);
}
//将新值设置为 head
setHead(lruNode);
}
/**
* @Title: appendTail
* @Description: 更新链表的前后指针，新增数据公用
*/
public void appendTail(LRUNode lNode,boolean flag) {
//存在上一个对象 prev
if(lNode.prev != null) {
//当前对象的上一个对象指向，当前对象的下一个对象。例如：2<-3(当前对象)->4 更新后： 2——>4
lNode.prev.next = lNode.next;
//如果不存在，下一个对象为 head 对象（暂不考虑更改对象）
}else {
head=lNode.next;
}
//存在下一个对象 next
if(lNode.next != null) {
// 4——>2
lNode.next.prev=lNode.prev;
}else {
//如果当前对象是最后一个对象，则上一个对象就为最后一个对象
tail=lNode.prev;
}
lNode.prev=null;
lNode.next=null;
//如果内存不足，需要删除tail
if(flag) {
hashMap.remove(lNode.key);
}
}
/**
* @Title: setHead
* @Description: 设置链表的 头 节点
* @param: node
* @return: void
*/
public void setHead(LRUNode node) {
if(head != null) {
node.next=head;
head.prev=node;
}
head=node;
if(tail == null) {
tail=node;
}
}
}
2、分布式集群下如何做到唯一序列号。
【序列号结构.png】
分布式架构下，生成唯一序列号是设计系统常常会遇到的一个问题。例如，数据库使用分库分表的时候，当分成若干个 sharding 表后，如何能够快速拿到一个唯一序列号，是经常遇到的问题。实现思路如下：
【1】数据库自增长序列或字段：全数据库唯一。
【优点】：简单，代码方便，性能可以接受。数字ID天然排序，对分页后者需要排序的结果很有帮组。适合小应用，无需分表，么有高并发性能要求。
【缺点】：不同数据库实现不同，在水平分表时，使用自增ID时可能会出现ID冲突。同时在高并发的情况下需要使用事务。在性能达不到要求的情况下，比较难于扩展。如果多个系统需要合并或者设计到数据迁移会相当痛苦。
【优化】：针对主库单点，如果有多个Master库，则每个Master库设置的起始数字不一样，步长一样，可以是Master的个数。比如：Master1 生成的是 1，4，7，10，Master2生成的是2,5,8,11 Master3生成的是 3,6,9,12。这样就可以有效生成集群中的唯一ID，也可以大大降低ID生成数据库操作的负载。
【2】UUID：常见的方式。可以利用数据库也可以利用程序生成32位的16进制格式的字符串，唯一性很高。
【优点】：简单，方便，生产ID性能非常好且全球基本唯一，在数据迁移和系统后期合并，或数据库变更等情况下都可应对。
【缺点】：没有排序，无法保证趋势递增。UUID使用字符串存储，查询效率低。存储空间较大，如果数据海量就绪考虑存储量问题，传输数据量大。
【3】Redis生成ID：当使用数据库来生成ID性能不够要求的时候，我们可以尝试使用 Redis来生成ID。这主要依赖于Redis是单线程的，所以也可以用生成全局唯一的ID。可以用 Redis的原子操作 INCR和INCRBY来实现。可以使用Redis集群来获取更高的吞吐量。假如一个集群中有5台Redis。可以初始化每台 Redis的值分别是1,2,3,4,5，然后步长都是5。各个Redis生成的ID为：
A：1,6,11,16,21
B：2,7,12,17,22
C：3,8,13,18,23
D：4,9,14,19,24
E：5,10,15,20,25
这个，随便负载到哪个机器确定好，未来很难做修改。但是3-5台服务器基本能够满足器上，都可以获得不同的ID。但是步长和初始值一定需要事先需要了。使用 Redis集群也可以防止单点故障（系统中一点失效，就会让整个系统无法运作的部件）的问题。另外，比较适合使用 Redis来生成每天从0开始的流水号。比如订单号=日期+当日自增长号。可以每天在 Redis中生成一个 Key，使用 INCR进行累加。
【优点】：不依赖于数据库，灵活方便，且性能优于数据库。数字ID天然排序，对分页或者需要排序的结果很有帮助。
【缺点】：如果系统中没有Redis，还需要引入新的组件，增加系统复杂度。需要编码和配置的工作量比较大。
【4】Twitter（推特） 的 snowflake 算法：twitter 在把存储系统从 MySQL 迁移到 Cassandra（一套开源分布式NoSQL数据库系统）的过程中由于 Cassandra 没有顺序 ID 生成机制，于是自己开发了一套全局唯一 ID 生成服务：Snowflake。
● 41位的时间序列（精确到毫秒，41位的长度可以使用69年）
● 10位的机器标识（10位的长度最多支持部署1024个节点）
● 12位的计数顺序号（12位的计数顺序号支持每个节点每毫秒产生4096个ID序号） 最高位是符号位，始终为0
Snowflake 的结构如下(每部分用-分开)：一共加起来刚好64位，为一个Long型。(转换成字符串后长度最多19)
0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000
snowflake 生成的ID整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞（由datacenter和workerId作区分），并且效率较高。经测试 snowflake每秒能够产生26万个ID。
【优点】：高性能，低延迟；独立的应用；按时间有序。
【缺点】：需要独立的开发和部署。在单机上是递增的，但是由于涉及到分布式环境，每台机器上的时钟不可能完全同步，也许有时候也会出现不是全局递增的情况。
【5】MongoDB 的 ObjectId：MongoDB 的 ObjectId 和 snowflake 算法类似。它设计成轻量型的，不同的机器都能用全局唯一的同种方法方便地生成它。MongoDB 从一开始就设计用来作为分布式数据库，处理多个节点是一个核心要求。使其在分片环境中要容易生成得多。
此处有图,详见笔记序列号结构.png
前4 个字节是从标准纪元开始的时间戳，单位为秒。时间戳，与随后的5 个字节组合起来，提供了秒级别的唯一性。由于时间戳在前，这意味着ObjectId 大致会按照插入的顺序排列。这对于某些方面很有用，如将其作为索引提高效率。这4 个字节也隐含了文档创建的时间。绝大多数客户端类库都会公开一个方法从ObjectId 获取这个信息。
接下来的3 字节是所在主机的唯一标识符。通常是机器主机名的散列值。这样就可以确保不同主机生成不同的ObjectId，不产生冲突。
为了确保在同一台机器上并发的多个进程产生的ObjectId 是唯一的，接下来的两字节来自产生ObjectId 的进程标识符（PID）。
前9 字节保证了同一秒钟不同机器不同进程产生的ObjectId 是唯一的。后3 字节就是一个自动增加的计数器，确保相同进程同一秒产生的ObjectId 也是不一样的。同一秒钟最多允许每个进程拥有2563（16 777 216）个不同的ObjectId。
【6】其他一些方案：比如京东淘宝等电商的订单号生成。因为订单号和用户id 在业务上的区别，订单号尽可能要多些冗余的业务信息，比如：滴滴：时间+起点编号+车牌号 淘宝订单：时间戳+用户ID 其他电商：时间戳+下单渠道+用户ID，有的会加上订单第一个商品的ID。而用户ID，则要求含义简单明了，包含注册渠道即可，尽量短。
3、设计一个秒杀系统，30分钟没付款就自动关闭交易。
【秒杀架构设计理念】：限流： 鉴于只有少部分用户能够秒杀成功，所以要限制大部分流量，只允许少部分流量进入服务后端。
削峰：对于秒杀系统瞬时会有大量用户涌入，所以在抢购一开始会有很高的瞬间峰值。高峰值流量是压垮系统很重要的原因，所以如何把瞬间的高流量变成一段时间平稳的流量也是设计秒杀系统很重要的思路。实现削峰的常用的方法有利用缓存和消息中间件等技术。
异步处理：秒杀系统是一个高并发系统，采用异步处理模式可以极大地提高系统并发量，其实异步处理就是削峰的一种实现方式。
内存缓存：秒杀系统最大的瓶颈一般都是数据库读写，由于数据库读写属于磁盘IO，性能很低，如果能够把部分数据或业务逻辑转移到内存缓存，效率会有极大地提升。
可拓展：当然如果我们想支持更多用户，更大的并发，最好就将系统设计成弹性可拓展的，如果流量来了，拓展机器就好了。像淘宝、京东等双十一活动时会增加大量机器应对交易高峰。
【设计思路】：将请求拦截在系统上游，降低下游压力：秒杀系统特点是并发量极大，但实际秒杀成功的请求数量却很少，所以如果不在前端拦截很可能造成数据库读写锁冲突，甚至导致死锁，最终请求超时。
充分利用缓存：利用缓存可极大提高系统读写速度。
消息队列：消息队列可以削峰，将拦截大量并发请求，这也是一个异步处理过程，后台业务根据自己的处理能力，从消息队列中主动的拉取请求消息进行业务处理。
【前端方案】：页面静态化：将活动页面上的所有可以静态的元素全部静态化，并尽量减少动态元素。通过CDN来抗峰值。
禁止重复提交：用户提交之后按钮置灰，禁止重复提交。
用户限流：在某一时间段内只允许用户提交一次请求，比如可以采取IP限流。
【后端方案】：服务端控制器层(网关层)：限制uid（UserID）访问频率：我们上面拦截了浏览器访问的请求，但针对某些恶意攻击或其它插件，在服务端控制层需要针对同一个访问uid，限制访问频率。
【服务层】：上面只拦截了一部分访问请求，当秒杀的用户量很大时，即使每个用户只有一个请求，到服务层的请求数量还是很大。比如我们有100W用户同时抢100台手机，服务层并发请求压力至少为100W。
采用消息队列缓存请求：既然服务层知道库存只有100台手机，那完全没有必要把100W个请求都传递到数据库啊，那么可以先把这些请求都写到消息队列缓存一下，数据库层订阅消息减库存，减库存成功的请求返回秒杀成功，失败的返回秒杀结束。
利用缓存应对读请求：对类似于12306等购票业务，是典型的读多写少业务，大部分请求是查询请求，所以可以利用缓存分担数据库压力。
利用缓存应对写请求：缓存也是可以应对写请求的，比如我们就可以把数据库中的库存数据转移到Redis缓存中，所有减库存操作都在Redis中进行，然后再通过后台进程把Redis中的用户秒杀请求同步到数据库中。
【数据库层】：数据库层是最脆弱的一层，一般在应用设计时在上游就需要把请求拦截掉，数据库层只承担“能力范围内”的访问请求。所以，上面通过在服务层引入队列和缓存，让最底层的数据库高枕无忧。
30分钟没付款就自动关闭交易：要看你取消订单后需不需要恢复库存了，不需要的话可以插入个结束时间来做标识，如果需要恢复库存的话可使用 swoole 里面的毫秒定时器 swoole_timer_after 来实现，如果使用的是 laravel 框架的话也可以使用延时队列来实现。我们公司在页面上会有倒计时刷新，其实也是通过页面定时器（setTiemout、setInterval）定时向后台发送请求。当超时后会进行订单状态的修改，达到自动关闭。
4、如何使用redis和zookeeper实现分布式锁？有什么区别优缺点，会有什么问题，分别适用什么场景。（延 伸：如果知道redlock，讲讲他的算法实现，争议在哪里）
Redis实现分布式锁思路：基于Redis实现分布式锁（setnx）setnx也可以存入key，如果存入 key成功返回1，如果存入的 key已经存在了，返回0。
Zookeeper实现分布式锁思路：基于Zookeeper实现分布式锁 Zookeeper是一个分布式协调工具，在分布式解决方案中。多个客户端（jvm），同时在 zookeeper 上创建相同的一个临时节点，因为临时节点路径是保证唯一，只要谁能够创建节点成功，谁就能够获取到锁，没有创建成功节点，就会进行等待，当释放锁的时候，采用事件通知给客户端重新获取锁的资源。
Redis实现分布式锁与Zookeeper实现分布式锁区别：相同点：在集群环境下，保证只允许有一个 jvm进行执行。
不同点：Redis 是nosql数据，主要特点缓存； Zookeeper是分布式协调工具，主要用于分布式解决方案。
实现思路：主要通过获取锁、释放锁、死锁三方面进行说明：
【1】获取锁：Zookeeper：多个客户端（jvm），会在 Zookeeper上创建同一个临时节点，因为 Zookeeper节点命名路径保证唯一，不允许出现重复，只要谁能够先创建成功，谁能够获取到锁。
Redis：多个客户端（jvm），会在Redis使用setnx命令创建相同的一个key，因为Redis的key保证唯一，不允许出现重复，只要谁能够先创建成功，谁能够获取到锁。
【2】释放锁：Zookeeper：使用直接关闭临时节点 session 会话连接，因为临时节点生命周期与 session 会话绑定在一块，如果 session 会话连接关闭的话，该临时节点也会被删除。这时候客户端使用事件监听，如果该临时节点被删除的话，重新进入盗获取锁的步骤。
Redis：在释放锁的时候，为了确保是锁的一致性问题，在删除的 redis 的 key 时候，需要判断同一个锁的 id，才可以删除。
【3】共同特征：如何解决死锁现象问题：Zookeeper：使用会话有效期方式解决死锁现象。Redis：是对 key 设置有效期解决死锁现象。
【4】性能角度考虑：因为 Redis 是 NoSQL 数据库，相对比来说 Redis 比 Zookeeper 性能要好。
【5】可靠性：从可靠性角度分析，Zookeeper可靠性比Redis更好。因为Redis有效期不是很好控制，可能会产生有效期延迟；Zookeeper 就不一样，因为 Zookeeper 临时节点先天性可控的有效期，所以相对来说 Zookeeper 比 Redis 更好。
5、如果有人恶意创建非法连接，怎么解决。
通过Filter进行拦截处理。
6、分布式事务的原理，优缺点，如何使用分布式事务，2pc 3pc 的区别，解决了哪些问题，还有哪些问题没解 决，如何解决，你自己项目里涉及到分布式事务是怎么处理的。
【分1.png、分2.png、分3.png、分4.png、分5.png、分6.png、分7.png】
分布式事物的原理：从广义上来看，分布式事务其实也是事务，只是由于业务上的定义以及微服务架构设计的问题，所以需要在多个服务之间保证业务的事务性，也就是 ACID 四个特性；从单机的数据库事务变成分布式事务时，原有单机中相对可靠的方法调用以及进程间通信方式已经没有办法使用，同时由于网络通信经常是不稳定的，所以服务之间信息的传递会出现障碍。
【分1.png】
模块（或服务）之间通信方式的改变是造成分布式事务复杂的最主要原因，在同一个事务之间的执行多段代码会因为网络的不稳定造成各种奇怪的问题，当我们通过网络请求其他服务的接口时，往往会得到三种结果：正确、失败和超时，无论是成功还是失败，我们都能得到唯一确定的结果，超时代表请求的发起者不能确定接受者是否成功处理了请求，这也是造成诸多问题的诱因。
【分2.png】
系统之间的通信可靠性从单一系统中的可靠变成了微服务架构之间的不可靠，分布式事务其实就是在不可靠的通信下实现事务的特性。无论是事务还是分布式事务实现原子性都无法避免对持久存储的依赖，事务使用磁盘上的日志记录执行的过程以及上文，这样无论是需要回滚还是补偿都可以通过日志追溯，而分布式事务也会依赖数据库、Zookeeper 或者 ETCD 等服务追踪事务的执行过程，总而言之，各种形式的日志是保证事务几大特性的重要手段。
2PC与3PC：两阶段提交是一种使分布式系统中所有节点在进行事务提交时保持一致性而设计的一种协议；在一个分布式系统中，所有的节点虽然都可以知道自己执行操作后的状态，但是无法知道其他节点执行操作的状态，在一个事务跨越多个系统时，就需要引入一个作为协调者的组件来统一掌控全部的节点并指示这些节点是否把操作结果进行真正的提交，想要在分布式系统中实现一致性的其他协议都是在两阶段提交的基础上做的改进。
【分3.png】
两阶段提交的执行过程就跟它的名字一样分为两个阶段，投票阶段 和 提交阶段，在投票阶段中，协调者（Coordinator）会向事务的参与者（Cohort）询问是否可以执行操作的请求，并等待其他参与者的响应，参与者会执行相对应的事务操作并记录重做和回滚日志，所有执行成功的参与者会向协调者发送 AGREEMENT 或者 ABORT 表示执行操作的结果。
【分4.png】
当所有的参与者都返回了确定的结果（同意或者终止）时，两阶段提交就进入了提交阶段，协调者会根据投票阶段的返回情况向所有的参与者发送提交或者回滚的指令。
【分5.png】
当事务的所有参与者都决定提交事务时，协调者会向参与者发送 COMMIT 请求，参与者在完成操作并释放资源之后向协调者返回完成消息，协调者在收到所有参与者的完成消息时会结束整个事务；与之相反，当有参与者决定 ABORT 当前事务时，协调者会向事务的参与者发送回滚请求，参与者会根据之前执行操作时的回滚日志对操作进行回滚并向协调者发送完成的消息，在提交阶段，无论当前事务被提交还是回滚，所有的资源都会被释放并且事务也一定会结束。
两阶段提交协议是一个阻塞协议，也就是说在两阶段提交的执行过程中，除此之外，如果事务的执行过程中协调者永久宕机，事务的一部分参与者将永远无法完成事务，它们会等待协调者发送 COMMIT 或者 ROLLBACK 消息，甚至会出现多个参与者状态不一致的问题。
【分6.png】
3PC 为了解决两阶段提交在协议的一些问题，三阶段提交引入了 超时机制 和 准备阶段，如果协调者或者参与者在规定的时间内没有接受到来自其他节点的响应，就会根据当前的状态选择提交或者终止整个事务，准备阶段的引入其实让事务的参与者有了除回滚之外的其他选择。
【分7.png】
当参与者向协调者发送 ACK 后，如果长时间没有得到协调者的响应，在默认情况下，参与者会自动将超时的事务进行提交，不会像两阶段提交中被阻塞住；上述的图片非常清楚地说明了在不同阶段，协调者或者参与者的超时会造成什么样的行为。
7、什么是一致性hash。
一致性Hash算法也是使用取模的方法，只是，刚才描述的取模法是对服务器的数量进行取模，而一致性Hash算法是对232取模，什么意思呢？简单来说，一致性Hash算法将整个哈希值空间组织成一个虚拟的圆环，如假设某哈希函数H的值空间为0-232-1（即哈希值是一个32位无符号整形），整个哈希环如下：
【hash1.png】
整个空间按顺时针方向组织，圆环的正上方的点代表0，0点右侧的第一个点代表1，以此类推，2、3、4、5、6……直到232-1，也就是说0点左侧的第一个点代表232-1， 0和232-1在零点中方向重合，我们把这个由232个点组成的圆环称为Hash环。
下一步将各个服务器使用Hash进行一个哈希，具体可以选择服务器的IP或主机名作为关键字进行哈希，这样每台机器就能确定其在哈希环上的位置，这里假设将上文中四台服务器使用IP地址哈希后在环空间的位置如下：
【hash2.png】
接下来使用如下算法定位数据访问到相应服务器：将数据key使用相同的函数 Hash 计算出哈希值，并确定此数据在环上的位置，从此位置沿环顺时针“行走”，第一台遇到的服务器就是其应该定位到的服务器！
例如我们有Object A、Object B、Object C、Object D四个数据对象，经过哈希计算后，在环空间上的位置如下：
【hash3.png】
根据一致性Hash算法，数据A会被定为到Node A上，B被定为到Node B上，C被定为到Node C上，D被定为到Node D上。
8、什么是restful，讲讲你理解的restful。
RESTful是一种架构的规范与约束、原则(无状态原则)，符合这种规范的架构就是RESTful架构。
无状态请求易于实现负载均衡, 在分布式web系统下，有多个可用服务器，每个服务器都可以处理客户端请求, 传统的有状态请求，因为状态信息只保存在第一次发起请求的那台服务器上，之后的请求都只能由这台服务器来处理，服务器无法自由调度请求。无状态请求则完全没有这个限制。其次，无状态请求有较强的容错性和可伸缩性。如果一台服务器宕机，无状态请求可以透明地交由另一台可用服务器来处理，而有状态的请求则会因为存储请求状态信息的服务器宕机而承担状态丢失的风险
Restful使用http动词有哪些， 分别代表什么意思？
GET（SELECT）: 从服务器取出资源（一项或多项）。
POST（CREATE）: 在服务器新建一个资源。
PUT（UPDATE）: 在服务器更新资源（客户端提供改变后的完整资源）。
DELETE（DELETE）: 从服务器删除资源。
PATCH（UPDATE）: 在服务器更新资源（客户端提供改变的属性）。
HEAD: 获取资源的元数据。
OPTIONS: 获取信息，关于资源的哪些属性是客户端可以改变的。
CONNECT: 通常用于SSL加密服务器的链接（经由非加密的HTTP代理服务器）
风格:
客户-服务器
在 REST 风格中，最基本的要求就是对于一个程序来说，应当分离用户接口和数据存储，改善用户接口跨平台迁移的可移植性，同时简化服务器组件，改善系统的可伸缩性。
对于这一点，目前我们所接触到的大多数应用都已经使用了这一模式，无论是浏览器，还是自主开发的客户端程序，其根本的实现方式都是采用了 客户-服务器 模式。客户端负责与用户之间的交互处理，而服务器端则实现数据存储以及相关的业务逻辑。
同时，对于服务器端，完整的系统大部分情况下都会包含多个不同的模块，这些模块之间的调用也应当遵循 客户-服务器 的模式，模块之间通过接口进行互相访问。
无状态
服务端在设计接口时，应当设计为无状态接口。也就是说，服务器端不保存任何与客户端相关的状态上下文信息，客户端在每次调用服务端接口时，需要提供足够的信息，以供服务端完成操作。
在无状态的设计中，服务端减少了保存客户端相关上下文数据，因此，一方面服务端能够更加容易的实现动态扩展，而不至于影响客户端使用；另一方面则减少了服务端从故障中恢复的任务量。
但无状态也会带来额外的问题。客户端将需要保存完整的用户状态信息，在每次与服务端交互时可能需要增加与用户状态相关的上下文信息，这样将导致请求数据的重复和增大。
缓存
根据接口的实际情况，应当在接口设计中增加缓存策略，服务端可以决定是否可以缓存当前返回的数据。通过此种方式，可以在一定程度上减少实际到达服务端请求，从而提高网络访问性能。
但缓存需要谨慎使用，缓存哪些数据，缓存过期时间都是需要根据实际情况进行设计。适当的缓存可以有效的提高系统效率，但是如果设计不当，将有可能导致大量的过期数据，进而影响系统运行。
一般而言，数据字典类数据、修改频率非常低的数据、实时性要求很低的数据等，这些数据可以设计一定的缓存策略，以提高系统运行效率。
系统分层
在设计系统，尤其是大型系统，通常需要将系统按照不同的功能进行横向和纵向的分层。例如横向分层一般可分为交互层、服务层、数据层等，而纵向分层则通常会按照不同的业务功能对系统进行切分。经过分层后，系统将划分为不同的模块进行独立开发部署运行。系统分层后，不同的模块可以独立进化，实现功能解耦，提高整个系统的可扩展性。
统一接口
统一接口，即是不同系统模块之间的调用接口统一规范，使用统一的调用协议，统一的数据格式等。统一接口带来的是系统交互的规范化，接口调用与业务解耦，各模块独立进化。
以上即是对于 REST 风格的解释说明。REST 本身是一种系统架构设计风格，因此其更加偏向理论性。以下的内容将专注于实际场景中运用 REST 风格。
9、如何设计一个良好的API。
【要明确】
这也许是最重要一点。如果你有一个方法getUser，如果不明确它可能引起一些副作用，最终会导致很多问题。比如getUser明确的只是返回一个用户，不会对用户的id进行增加。
尽可能多的提供更多的行为。不要指望用户会潜水你的源码，以发现隐藏的行为。
【让api表面积尽可能小】
没有人喜欢臃肿的程序，如果你能够暴露更少的api就能完成工作，这对于每个人都是一个很好的体验。
是否人们真的要求你写这个新的api？一直到它是一个真正需要有人去解决的问题的时候，你才可以去做它。
【减少样板】
尽可能的在内部处理各种细节，以减少客户端的负担。客户端调用的时候做的越少，漏洞才可能越少。
喜欢干净的代码?那就保持你的api很干净，那么，你的api的客户调用就会很简洁。
【降低依赖】
尽可能的保证你的代码人自我封闭，你有更多的依赖，就意味着潜在的问题会影响到下游代码。
如果你希望从另外一个模块里，获取一块功能，那么尽可能的只提取你需要的。在代码重用和紧耦合和之间有一个平衡，如果功能比较小，那么就值得你自己重新实现它。
【返回有意义的错误状态】
返回null是毫无意义的，他什么也意味不了。错误信息要能够有可以进行改善的提示。Error.USER_NOT_CREATED 或Error.USER_DELETED都是有意义的。
【异常应该有真正的含义】
如果你使用的语言没有异常，祝贺你，函数式语言在提供有意义的错误状态方面会做的更好。
一场已经在java领域被滥用，getUser时如果没有发现用户，不要抛UserNotFoundException,而是返回一个正常的错误状态。
比一个蹦溃的程序更坏的事情是，不要因为一个不确定的状态导致崩溃。
【对所有的事情要建立文档】
文档是无聊的，但必不可少，良好的文档会保存你的理智思考，会避免api消费的很多问题。
一个好的文档包括：
1.有关模块是如何工作的高层次概述
2.公共方法和接口的javadoc
3.如何使用api的案例
不是所有的抽象都需要文档的,一些小类就不需要案例代码。
文档必须是演进，如果有很多问题问同样的事情，你就可能需要把它加到文档里。
太多的文档也是浪费时间，因为你必须保持不断的更新，但是如果仍没有人使用，它就没有什么价值，所以要保证足够的重点和适当的文档。
【编写测试】
这是是正确性的证明，文档和示例代码都可以包括进去。它为中国提供了巨大的价值，能够让你在事情改变时候，很自信的快速移动。
那些想对你的api实现深入研究的人总是，通过阅读测试实现的，能够更多的了解你的代码行为和意图。这些都是文档无法实现的。
【变得可测试】
测试你的代码是一回事儿，让人们对你的api更容易地编写测试代码又是另外一回事儿。
你需要有针对调试和产品环境的不同配置。
【允许用户选择】
不是每一个客户端都以同样的方式调用你的api，有些人可能喜欢同步调用，而另外一些人更喜欢一部回调。
让用户选择他们自己喜欢的方式，你的api就更容易集成到他们现有的编程环境中，更可能地被使用。
【不要给用户太多的选择】
不要给用户太多的选择，否则他们就有选择障碍，总是提供合理的默认行为，也就是你的api默认的使用方式。
api应该鼓励规范行为，不要让消费者修改内部状态，如果你无意中暴露一些怪异的行为，它会产生一些不可预见的后果。
10、如何设计建立和保持100w的长连接。
服务器内核调优(tcp，文件数)，客户端调优，框架选择(netty)
11、解释什么是MESI协议(缓存一致性)。
MESI是四种缓存段状态的首字母缩写，任何多核系统中的缓存段都处于这四种状态之一。我将以相反的顺序逐个讲解，因为这个顺序更合理：
失效（Invalid）缓存段，要么已经不在缓存中，要么它的内容已经过时。为了达到缓存的目的，这种状态的段将会被忽略。一旦缓存段被标记为失效，那效果就等同于它从来没被加载到缓存中。
共享（Shared）缓存段，它是和主内存内容保持一致的一份拷贝，在这种状态下的缓存段只能被读取，不能被写入。多组缓存可以同时拥有针对同一内存地址的共享缓存段，这就是名称的由来。
独占（Exclusive）缓存段，和S状态一样，也是和主内存内容保持一致的一份拷贝。区别在于，如果一个处理器持有了某个E状态的缓存段，那其他处理器就不能同时持有它，所以叫“独占”。这意味着，如果其他处理器原本也持有同一缓存段，那么它会马上变成“失效”状态。
已修改（Modified）缓存段，属于脏段，它们已经被所属的处理器修改了。如果一个段处于已修改状态，那么它在其他处理器缓存中的拷贝马上会变成失效状态，这个规律和E状态一样。此外，已修改缓存段如果被丢弃或标记为失效，那么先要把它的内容回写到内存中——这和回写模式下常规的脏段处理方式一样。
12、说说你知道的几种HASH算法，简单的也可以。
哈希(Hash)算法,即散列函数。 它是一种单向密码体制,即它是一个从明文到密文的不可逆的映射,只有加密过程,没有解密过程。 同时,哈希函数可以将任意长度的输入经过变化以后得到固定长度的输出
MD4 MD5 SHA
13、什么是paxos算法， 什么是zab协议。
Paxos算法是莱斯利·兰伯特（Leslie Lamport，就是 LaTeX 中的"La"，此人现在在微软研究院）于1990年提出的一种基于消息传递的一致性算法
ZAB 是 Zookeeper 原子广播协议的简称
整个ZAB协议主要包括消息广播和崩溃恢复两个过程，进一步可以分为三个阶段，分别是：
发现 Discovery
同步 Synchronization
广播 Broadcast
组成ZAB协议的每一个分布式进程，都会循环执行这三个阶段，将这样一个循环称为一个主进程周期。
14、一个在线文档系统，文档可以被编辑，如何防止多人同时对同一份文档进行编辑更新。
点击编辑的时候，利用redis进行加锁setNX完了之后 expire 一下
也可以用版本号进行控制
15、线上系统突然变得异常缓慢，你如何查找问题。
逐级排查（网络，磁盘，内存，cpu），数据库，日志，中间件等也可通过监控工具排查。
16、说说你平时用到的设计模式。
策略模式( Strategy )
定义个策略接口，不同的实现类提供不同的具体策略算法, 同时它们之间可以互相替换.
简单工厂模式( Simple Factory )
定义一个用以创建对象的工厂, 根据不同的条件生成不同的对象
工厂模式( Factory )
针对每一种产品提供一个工厂类，通过不同的工厂实例来创建不同的产品实例,与简单工厂模式不同点是它要为每一种产品提供一个工厂类，不同工厂类实现同一个工厂接口，返回不同产品
抽象工厂模式( Abstract Factory )
应对产品族概念而生,与工厂模式相比，抽象工厂模式是为了应对产品族
装饰者模式( Decorator )
动态的给一个对象添加一些额外的功能
代理模式( Proxy )
封装被代理对象并限制外界对被代理对象的访问
观察者模式( Observer )
定义了一种一对多的依赖关系,让多个观察者对象同时监听某一主题对象,在它的状态发生变化时,会通知所有的观察者.
单例模式( Singleton )
保证一个类仅有一个实例,并提供一个访问它的全局控制点.
17、Dubbo的原理，有看过源码么，数据怎么流转的，怎么实现集群，负载均衡，服务注册和发现，重试转发，快速失败的策略是怎样的 。
原理
Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。
dubbo作为rpc框架，实现的效果就是调用远程的方法就像在本地调用一样。如何做到呢？就是本地有对远程方法的描述，包括方法名、参数、返回值，在dubbo中是远程和本地使用同样的接口；然后呢，要有对网络通信的封装，要对调用方来说通信细节是完全不可见的，网络通信要做的就是将调用方法的属性通过一定的协议（简单来说就是消息格式）传递到服务端；服务端按照协议解析出调用的信息；执行相应的方法；在将方法的返回值通过协议传递给客户端；客户端再解析；在调用方式上又可以分为同步调用和异步调用；简单来说基本就这个过程
Cluster 实现集群
在集群负载均衡时，Dubbo提供了多种均衡策略，缺省为random随机调用。
Random LoadBalance：随机，按权重比率设置随机概率。
RoundRobin LoadBalance：轮循，按公约后的权重比率设置轮循比率。
LeastActive LoadBalance：最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
ConsistentHash LoadBalance：一致性Hash，相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
快速失败，只发起一次调用，失败立即报错。
18、一次RPC请求的流程是什么。
1）服务消费方（client）调用以本地调用方式调用服务；
2）client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；
3）client stub找到服务地址，并将消息发送到服务端；
4）server stub收到消息后进行解码；
5）server stub根据解码结果调用本地的服务；
6）本地服务执行并将结果返回给server stub；
7）server stub将返回结果打包成消息并发送至消费方；
8）client stub接收到消息，并进行解码；
9）服务消费方得到最终结果。
19、自己实现过rpc么，原理可以简单讲讲。Rpc要解决什么问题。
RPC（Remote Procedure Call）远程过程调用，简单的理解是一个节点请求另一个节点提供的服务
(1) 客户端（client）以本地调用方式（即以接口的方式）调用服务；
(2) 客户端存根（client stub）接收到调用后，负责将方法、参数等组装成能够进行网络传输的消息体（将消息体对象序列化为二进制）；
(3) 客户端通过sockets将消息发送到服务端；
(4) 服务端存根( server stub）收到消息后进行解码（将消息对象反序列化）；
(5) 服务端存根( server stub）根据解码结果调用本地的服务；
(6) 本地服务执行并将结果返回给服务端存根( server stub）；
(7) 服务端存根( server stub）将返回结果打包成消息（将结果消息对象序列化）；
(8) 服务端（server）通过sockets将消息发送到客户端；
(9) 客户端存根（client stub）接收到结果消息，并进行解码（将结果消息发序列化）；
(10) 客户端（client）得到最终结果。
RPC的目标是要把2、3、4、7、8、9这些步骤都封装起来。
注意：无论是何种类型的数据，最终都需要转换成二进制流在网络上进行传输，数据的发送方需要将对象转换为二进制流，而数据的接收方则需要把二进制流再恢复为对象。
为什么需要RPC
1、首先要明确一点：RPC可以用HTTP协议实现，并且用HTTP是建立在 TCP 之上最广泛使用的 RPC，但是互联网公司往往用自己的私有协议，比如鹅厂的JCE协议，私有协议不具备通用性为什么还要用呢？因为相比于HTTP协议，RPC采用二进制字节码传输，更加高效也更加安全。
2、现在业界提倡“微服务“的概念，而服务之间通信目前有两种方式，RPC就是其中一种。RPC可以保证不同服务之间的互相调用。即使是跨语言跨平台也不是问题，让构建分布式系统更加容易。
3、RPC框架都会有服务降级、流量控制的功能，保证服务的高可用。
20、异步模式的用途和意义。
意义
异步方法的意义就是保证一个进程使用多线程多次执行一个方法时，不会因为其中某一次执行阻塞调用进程
应用
1、不涉及共享资源，或对共享资源只读，即非互斥操作
2、没有时序上的严格关系
3、不需要原子操作，或可以通过其他方式控制原子性
4、常用于IO操作等耗时操作，因为比较影响客户体验和使用性能
5、不影响主线程逻辑
21、编程中自己都怎么考虑一些设计原则的，比如开闭原则，以及在工作中的应用。
开闭原则（Open Close Principle）
一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
里氏代换原则（Liskov Substitution Principle）
子类型必须能够替换掉它们的父类型。
依赖倒转原则（Dependence Inversion Principle）
高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。即针对接口编程，不要针对实现编程
接口隔离原则（Interface Segregation Principle）
建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少
组合/聚合复用原则
说要尽量的使用合成和聚合，而不是继承关系达到复用的目的
迪米特法则（Law Of Demeter）
迪米特法则其根本思想，是强调了类之间的松耦合，类之间的耦合越弱,越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成影响，也就是说，信息的隐藏促进了软件的复用。
单一职责原则（Single Responsibility Principle）
一个类只负责一项职责，应该仅有一个引起它变化的原因
22、设计一个社交网站中的“私信”功能，要求高并发、可扩展等等。 画一下架构图。
23、MVC模式，即常见的MVC框架。
MVC框架模式
MVC是三个单词的首字母缩写，它们是Model（模型）、View（视图）和Controller（控制）。
所谓MVC模型就是将数据、逻辑处理、用户界面分离的一种方法。
M(Model, 模型)：用于数据处理、逻辑处理。
V(View，视图)：用于显示用户界面。
C(Controller，控制器)：根据客户端的请求控制逻辑走向和画面。
而在Java中，MVC这三个部分则分别对应于 JavaBeans、JSP和Servlet。
M = JavaBeans：用于传递数据，拥有与数据相关的逻辑处理。
V = JSP：从Model接收数据并生成HTML
C = Servlet：接收HTTP请求并控制Model和View
24、聊下曾经参与设计的服务器架构并画图，谈谈遇到的问题，怎么解决的。
25、应用服务器怎么监控性能，各种方式的区别。
1.监控网络状态
常见的网络状态有四种，ESTABLISHED 表示正在通信，TIME_WAIT 表示主动关闭，CLOSE_WAIT 表示被动关闭，LISTEN侦听来自远方的TCP端口的连接请求；其中CLOSE_WAIT状态必须要监控，表示端口被动关闭，可使用如下的语句记录下ClOSE_WAIT状态的个数，如下：
netstat -n|grep 1521|awk ‘/^tcp/ {++S[$NF]} END {for(a in S) if(a == “CLOSE_WAIT”) print a,S[a]}’
监控ClOSE_WAIT状态的个数，当超过一定的值，系统告警
2.应用日志的最后修改时间监控
有时候进程出现假死，无法对外提供服务，如果只监控基础环境无法知道交易是否正常，可以监控日志最后修改时间，可使用如下的语句
'stat “${file}”|awk ‘$1 -eq “Modify:”{print $2" "$3}’
file为日志文件，上面的语句会输出modify的最后时间，与系统时间比较，如果超过多长时间未更新，报警提示。
应用日志的监控还可更进一步，实时查看应用日志是否有输出交易成功的日志，可以取日志最新输出几行进行分析。
26、如何设计一套高并发支付方案，架构如何设计。
27、如何实现负载均衡，有哪些算法可以实现。
1、轮询调度
轮询调度算法就是以轮询的方式依次将请求调度到不同的服务器，即每次调度执行i = (i + 1) mod n，并选出第i台服务器。算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。
2、最小连接调度
最小连接调度算法是把新的连接请求分配7a64e4b893e5b19e31333363383462到当前连接数最小的服务器。最小连接调度是一种动态调度算法，它通过服务器当前所活跃的连接数来估计服务器的负载情况。
在实际实现过程中，一般会为每台服务器设定一个权重值，这就是加权最小连接
3、 基于局部性的最少链接(LBLC)
基于局部性的最少链接调度(以下简称为LBLC)算法是针对请求报文的目标IP地址的负载均衡调度，目前主要用于Cache集群系统，因为在Cache集群中客户请求报文的目标IP地址是变化的。
LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器; 若服务器不存在，或服务器超载或有服务器处于其一半的工作负载，则用“最少链接”的原则选出一个可用的服务器，将请求发送到该服务器。
4、带复制的基于局部性最少链接(LBLCR)
带复制的基于局部性最少链接调度以下简称为LBLCR)算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。
LBLCR调度算法将“热门”站点映射到一组Cache服务器(服务器集合)，当该“热门”站点的请求负载增加时，会增加集合里的Cache服务器，来处理不断增长的负载; 当该“热门”站点的请求负载降低时，会减少集合里的Cache服务器数目。
5、目标地址散列调度
目标地址散列调度算法是针对目标IP地址的负载均衡，但它是一种静态映射算法，通过一个散列(Hash)函数将一个目标IP地址映射到一台服务器。
目标地址散列调度算法先根据请求的目标IP地址，作为散列从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
6、 源地址散列调度
和目标地址散列调度类似，唯一的区别是按照源地址为散列函数的散列键。
28、Zookeeper的用途，选举的原理是什么。
Zookeeper 从设计模式角度来看，是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper 就将负责通知已经在 Zookeeper 上注册的那些观察者做出相应的反应。
场景一：有一组服务器向客户端提供某种服务（例如：我前面做的分布式网站的服务端，就是由四台服务器组成的集群，向前端集群提供服务），我们希望客户端每次请求服务端都可以找到服务端集群中某一台服务器，这样服务端就可以向客户端提供客户端所需的服务。对于这种场景，我们的程序中一定有一份这组服务器的列表，每次客户端请求时候，都是从这份列表里读取这份服务器列表。那么这分列表显然不能存储在一台单节点的服务器上，否则这个节点挂掉了，整个集群都会发生故障，我们希望这份列表时高可用的。高可用的解决方案是：这份列表是分布式存储的，它是由存储这份列表的服务器共同管理的，如果存储列表里的某台服务器坏掉了，其他服务器马上可以替代坏掉的服务器，并且可以把坏掉的服务器从列表里删除掉，让故障服务器退出整个集群的运行，而这一切的操作又不会由故障的服务器来操作，而是集群里正常的服务器来完成。这是一种主动的分布式数据结构，能够在外部情况发生变化时候主动修改数据项状态的数据机构。Zookeeper框架提供了这种服务。这种服务名字就是：统一命名服务，它和javaEE里的JNDI服务很像。
场景二：分布式锁服务。当分布式系统操作数据，例如：读取数据、分析数据、最后修改数据。在分布式系统里这些操作可能会分散到集群里不同的节点上，那么这时候就存在数据操作过程中一致性的问题，如果不一致，我们将会得到一个错误的运算结果，在单一进程的程序里，一致性的问题很好解决，但是到了分布式系统就比较困难，因为分布式系统里不同服务器的运算都是在独立的进程里，运算的中间结果和过程还要通过网络进行传递，那么想做到数据操作一致性要困难的多。Zookeeper提供了一个锁服务解决了这样的问题，能让我们在做分布式数据运算时候，保证数据操作的一致性。
场景三：配置管理。在分布式系统里，我们会把一个服务应用分别部署到n台服务器上，这些服务器的配置文件是相同的（例如：我设计的分布式网站框架里，服务端就有4台服务器，4台服务器上的程序都是一样，配置文件都是一样），如果配置文件的配置选项发生变化，那么我们就得一个个去改这些配置文件，如果我们需要改的服务器比较少，这些操作还不是太麻烦，如果我们分布式的服务器特别多，比如某些大型互联网公司的hadoop集群有数千台服务器，那么更改配置选项就是一件麻烦而且危险的事情。这时候zookeeper就可以派上用场了，我们可以把zookeeper当成一个高可用的配置存储器，把这样的事情交给zookeeper进行管理，我们将集群的配置文件拷贝到zookeeper的文件系统的某个节点上，然后用zookeeper监控所有分布式系统里配置文件的状态，一旦发现有配置文件发生了变化，每台服务器都会收到zookeeper的通知，让每台服务器同步zookeeper里的配置文件，zookeeper服务也会保证同步操作原子性，确保每个服务器的配置文件都能被正确的更新。
场景四：为分布式系统提供故障修复的功能。集群管理是很困难的，在分布式系统里加入了zookeeper服务，能让我们很容易的对集群进行管理。集群管理最麻烦的事情就是节点故障管理，zookeeper可以让集群选出一个健康的节点作为master，master节点会知道当前集群的每台服务器的运行状况，一旦某个节点发生故障，master会把这个情况通知给集群其他服务器，从而重新分配不同节点的计算任务。Zookeeper不仅可以发现故障，也会对有故障的服务器进行甄别，看故障服务器是什么样的故障，如果该故障可以修复，zookeeper可以自动修复或者告诉系统管理员错误的原因让管理员迅速定位问题，修复节点的故障。大家也许还会有个疑问，master故障了，那怎么办了？zookeeper也考虑到了这点，zookeeper内部有一个“选举领导者的算法”，master可以动态选择，当master故障时候，zookeeper能马上选出新的master对集群进行管理。
原理
一、首先开始选举阶段，每个Server读取自身的zxid。
二、发送投票信息
a、首先，每个Server第一轮都会投票给自己。
b、投票信息包含 ：所选举leader的Serverid，Zxid，Epoch。Epoch会随着选举轮数的增加而递增。
三、接收投票信息
1、如果服务器B接收到服务器A的数据（服务器A处于选举状态(LOOKING 状态)
1）首先，判断逻辑时钟值：
a）如果发送过来的逻辑时钟Epoch大于目前的逻辑时钟。首先，更新本逻辑时钟Epoch，同时清空本轮逻辑时钟收集到的来自其他server的选举数据。然后，判断是否需要更新当前自己的选举leader Serverid。判断规则rules judging：保存的zxid最大值和leader Serverid来进行判断的。先看数据zxid,数据zxid大者胜出;其次再判断leader Serverid,leader Serverid大者胜出；然后再将自身最新的选举结果(也就是上面提到的三种数据（leader Serverid，Zxid，Epoch）广播给其他server)
b）如果发送过来的逻辑时钟Epoch小于目前的逻辑时钟。说明对方server在一个相对较早的Epoch中，这里只需要将本机的三种数据（leader Serverid，Zxid，Epoch）发送过去就行。
c）如果发送过来的逻辑时钟Epoch等于目前的逻辑时钟。再根据上述判断规则rules judging来选举leader ，然后再将自身最新的选举结果(也就是上面提到的三种数据（leader Serverid，Zxid，Epoch）广播给其他server)。
2）其次，判断服务器是不是已经收集到了所有服务器的选举状态：若是，根据选举结果设置自己的角色(FOLLOWING还是LEADER)，退出选举过程就是了。
最后，若没有收到没有收集到所有服务器的选举状态：也可以判断一下根据以上过程之后最新的选举leader是不是得到了超过半数以上服务器的支持,如果是,那么尝试在200ms内接收一下数据,如果没有新的数据到来,说明大家都已经默认了这个结果,同样也设置角色退出选举过程。
2、 如果所接收服务器A处在其它状态（FOLLOWING或者LEADING）。
a)逻辑时钟Epoch等于目前的逻辑时钟，将该数据保存到recvset。此时Server已经处于LEADING状态，说明此时这个server已经投票选出结果。若此时这个接收服务器宣称自己是leader, 那么将判断是不是有半数以上的服务器选举它，如果是则设置选举状态退出选举过程。
b) 否则这是一条与当前逻辑时钟不符合的消息，那么说明在另一个选举过程中已经有了选举结果，于是将该选举结果加入到outofelection集合中，再根据outofelection来判断是否可以结束选举,如果可以也是保存逻辑时钟，设置选举状态，退出选举过程。
简单地说
目前有5台服务器，每台服务器均没有数据，它们的编号分别是1,2,3,4,5,按编号依次启动，它们的选择举过程如下：
服务器1启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于Looking(选举状态)。
服务器2启动，给自己投票，同时与之前启动的服务器1交换结果，由于服务器2的编号大所以服务器2胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是LOOKING。
服务器3启动，给自己投票，同时与之前启动的服务器1,2交换信息，由于服务器3的编号最大所以服务器3胜出，此时投票数正好大于半数，所以服务器3成为领导者，服务器1,2成为小弟。
服务器4启动，给自己投票，同时与之前启动的服务器1,2,3交换信息，尽管服务器4的编号大，但之前服务器3已经胜出，所以服务器4只能成为小弟。
服务器5启动，后面的逻辑同服务器4成为小弟。
29、Zookeeper watch机制原理。
【Zookeeperwatch机制原理.png】
原理:client 端连接后会注册一个事件，然后客户端会保存这个事件，通过zkWatcherManager 保存客户端的事件注册，通知服务端 Watcher 为 true，然后服务端会通过WahcerManager 会绑定path对应的事件
机制:ZooKeeper 的 Watcher 机制，总的来说可以分为三个过程：客户端注册 Watcher、服务器处理 Watcher 和客户端回调 Watcher客户端。注册 watcher 有 3 种方式，getData、exists、getChildren；
30、Mybatis的底层实现原理。
mybatis底层原理.png
MyBatis的主要成员
Configuration MyBatis所有的配置信息都保存在Configuration对象之中，配置文件中的大部分配置都会存储到该类中
SqlSession 作为MyBatis工作的主要顶层API，表示和数据库交互时的会话，完成必要数据库增删改查功能
Executor MyBatis执行器，是MyBatis 调度的核心，负责SQL语句的生成和查询缓存的维护
StatementHandler 封装了JDBC Statement操作，负责对JDBC statement 的操作，如设置参数等
ParameterHandler 负责对用户传递的参数转换成JDBC Statement 所对应的数据类型
ResultSetHandler 负责将JDBC返回的ResultSet结果集对象转换成List类型的集合
TypeHandler 负责java数据类型和jdbc数据类型(也可以说是数据表列类型)之间的映射和转换
MappedStatement MappedStatement维护一条<select|update|delete|insert>节点的封装
SqlSource 负责根据用户传递的parameterObject，动态地生成SQL语句，将信息封装到BoundSql对象中，并返回
BoundSql 表示动态生成的SQL语句以及相应的参数信息
以上主要成员在一次数据库操作中基本都会涉及，在SQL操作中重点需要关注的是SQL参数什么时候被设置和结果集怎么转换为JavaBean对象的，这两个过程正好对应StatementHandler和ResultSetHandler类中的处理逻辑。
底层原理:
1.MyBatis的初始化解析配置文件和初始化Configuration
2.首先会创建SqlSessionFactory建造者对象，然后由它进行创建SqlSessionFactory。这里用到的是建造者模式，建造者模式最简单的理解就是不手动new对象，而是由其他类来进行对象的创建。
3.XMLConfigBuilder对象会进行XML配置文件的解析，实际为configuration节点的解析操作。
4.在configuration节点下会依次解析properties/settings/…/mappers等节点配置。在解析environments节点时，会根据transactionManager的配置来创建事务管理器，根据dataSource的配置来创建DataSource对象，这里面包含了数据库登录的相关信息。在解析mappers节点时，会读取该节点下所有的mapper文件，然后进行解析，并将解析后的结果存到configuration对象中。
5.解析完MyBatis配置文件后，configuration就初始化完成了，然后根据configuration对象来创建SqlSession，到这里时，MyBatis的初始化的征程已经走完了。
6.SQL语句的执行才是MyBatis的重要职责，该过程就是通过封装JDBC进行操作，然后使用Java反射技术完成JavaBean对象到数据库参数之间的相互转换，这种映射关系就是有TypeHandler对象来完成的，在获取数据表对应的元数据时，会保存该表所有列的数据库类型
7.创建sqlSession的过程其实就是根据configuration中的配置来创建对应的类，然后返回创建的sqlSession对象。调用selectOne方法进行SQL查询，selectOne方法最后调用的是selectList，在selectList中，会查询configuration中存储的MappedStatement对象，mapper文件中一个sql语句的配置对应一个MappedStatement对象，然后调用执行器进行查询操作。
8.执行器在query操作中，优先会查询缓存是否命中，命中则直接返回，否则从数据库中查询。
9.真正的doQuery操作是由SimplyExecutor代理来完成的，该方法中有2个子流程，一个是SQL参数的设置，另一个是SQL查询操作和结果集的封装。
10.首先获取数据库connection连接，然后准备statement，然后就设置SQL查询中的参数值。打开一个connection连接，在使用完后不会close，而是存储下来，当下次需要打开连接时就直接返回。
11.ResultSetWrapper是ResultSet的包装类，调用getFirstResultSet方法获取第一个ResultSet，同时获取数据库的MetaData数据，包括数据表列名、列的类型、类序号等，这些信息都存储在ResultSetWrapper类中了。然后调用handleResultSet方法来来进行结果集的封装。调用handleRowValues方法进行结果值的设置。
12.mapping.typeHandler.getResult会获取查询结果值的实际类型，比如我们user表中id字段为int类型，那么它就对应Java中的Integer类型，然后通过调用statement.getInt(“id”)来获取其int值，其类型为Integer。13.metaObject.setValue方法会把获取到的Integer值设置到Java类中的对应字段。
14metaValue.setValue方法最后会调用到Java类中对应数据域的set方法，这样也就完成了SQL查询结果集的Java类封装过程。
MyBatis提供查询缓存，用于减轻数据库压力，提高性能。MyBatis提供了一级缓存和二级缓存
一级缓存是SqlSession级别的缓存，每个SqlSession对象都有一个哈希表用于缓存数据，不同SqlSession对象之间缓存不共享。同一个SqlSession对象对象执行2遍相同的SQL查询，在第一次查询执行完毕后将结果缓存起来，这样第二遍查询就不用向数据库查询了，直接返回缓存结果即可。MyBatis默认是开启一级缓存的。
二级缓存是mapper级别的缓存，二级缓存是跨SqlSession的，多个SqlSession对象可以共享同一个二级缓存。不同的SqlSession对象执行两次相同的SQL语句，第一次会将查询结果进行缓存，第二次查询直接返回二级缓存中的结果即可。MyBatis默认是不开启二级缓存的，可以在配置文件中使用如下配置来开启二级缓存：
当SQL语句进行更新操作(删除/添加/更新)时，会清空对应的缓存，保证缓存中存储的都是最新的数据。MyBatis的二级缓存对细粒度的数据级别的缓存实现不友好，比如如下需求：对商品信息进行缓存，由于商品信息查询访问量大，但是要求用户每次都能查询最新的商品信息，此时如果使用mybatis的二级缓存就无法实现当一个商品变化时只刷新该商品的缓存信息而不刷新其它商品的信息，因为mybaits的二级缓存区域以mapper为单位划分，当一个商品信息变化会将所有商品信息的缓存数据全部清空。解决此类问题需要在业务层根据需求对数据有针对性缓存，具体业务具体实现。
31、请思考一个方案，实现分布式环境下的countDownLatch。
32、后台系统怎么防止请求重复提交。
方案一：利用Session防止表单重复提
具体的做法：
1、获取用户填写用户名和密码的页面时向后台发送一次请求，这时后台会生成唯一的随机标识号，专业术语称为Token(令牌)。
2、将Token发送到客户端的Form表单中，在Form表单中使用隐藏域来存储这个Token，表单提交的时候连同这个Token一起提交到服务器端。
3、服务器端判断客户端提交上来的Token与服务器端生成的Token是否一致，如果不一致，那就是重复提交了，此时服务器端就可以不处理重复提交的表单。如果相同则处理表单提交，处理完后清除当前用户的Session域中存储的标识号。
方案二：判断请求url和数据是否和上一次相同
推荐，非常简单，页面不需要任何传入，只需要在验证的controller方法上写上自定义注解即可
方案三：利用Spring AOP和redis的锁来实现防止表单重复提交
主要是利用了redis的分布式锁机制,第一次点击提交表单，判断到当前的token还没有上锁，即给该token上锁。如果连续点击提交，则提示不能重复提交，当上锁的那次操作执行完，redis释放了锁之后才能继续提交。
33、描述一个服务从发布到被消费的详细过程。
34、讲讲你理解的服务治理。
35、如何做到接口的幂等性。
1.唯一索引： 场景->新增数据，如注册用户(username/id_card_no->unique key)
通过数据库唯一索引，防止用户重复提交造成数据重复插入。
2.联合索引：
原理同唯一索引，有时唯一索引无法满足，可考虑联合索引；
3.Token校验：
此处声明的token并非用户登陆所留下的token，而是对于请求指定的一个随机口令，如uuid。在用户进入创建页面或修改页面时，调用查询接口，将token返回前端并同时保存到redis中，前端在调用创建与修改操作时，将token放入header，请求进入接口，判断两份token是否一致
注：增加第三方插件，势必会增加系统耦合度，此处不考虑redis服务宕掉；若单Jvm情况，选择一个map容器，去进行相应操作也是可行的。
4.乐观锁： mybatis-plus 支持乐观锁插件，详情可查看https://mp.baomidou.com/guide/optimistic-locker-plugin.html#_1-%E6%8F%92%E4%BB%B6%E9%85%8D%E7%BD%AE
该场景适用于 更新操作，只有在更新操作时锁表，性能较高。
5.分布式锁 ：即限制了分布式系统，按照顺序依次去执行请求——>效果等同单Jvm下 synchronized .
构建场景举例：文章评论点赞。此时可以通过分布式锁限制分布式服务中执行按顺序，并且通过select 查询该用户是否已点，来判断该操作是否有效。
36、如何做限流策略，令牌桶和漏斗算法的使用场景。
37、什么叫数据一致性，你怎么理解数据一致性。
在数据有多分副本的情况下，如果网络、服务器或者软件出现故障，会导致部分副本写入成功，部分副本写入失败。这就造成各个副本之间的数据不一致，数据内容冲突。 实践中，导致数据不一致的情况有很多种，表现样式也多种多样，比如数据更新返回操作失败，事实上数据在存储服务器已经更新成功。
38、分布式服务调用方，不依赖服务提供方的话，怎么处理服务方挂掉后，大量无效资源请求的浪费，如果只是 服务提供方吞吐不高的时候该怎么做，如果服务挂了，那么一会重启，该怎么做到最小的资源浪费，流量半 开的实现机制是什么。
39、dubbo的泛化调用怎么实现的，如果是你，你会怎么做。
40、远程调用会有超时现象，如果做到优雅的控制，JDK自带的超时机制有哪些，怎么实现的。
一、串行超时处理
串行超时处理是指程序只有一个线程，调用者调用任务方法，完全由执行任务的方法本身进行超时处理。
这种方案通常要求任务需要循环执行，每个循环内的计算较复杂，执行时间较长或者不确定。执行任务的方法在规划任务算法代码的同时还要考虑超时的时候能够退出。通常的代码框架如下：
public void runTask(long timeout){
long beginTime=System.currentTimeMillis();
//任务执行准备
//如下为任务算法执行
while((System.currentTimeMillis()-beginTime<timeout)&&(任务自身的逻辑判断)){
//执行循环体内的任务片段和算法
}
}
通过这种方案实现的任务超时处理最大的优点是方案简单，因为不会引入新的线程，完全串行操作，但是这种方案也有两大缺点：
1、代码混乱，因为方法除了实现任务，还要考虑超时，违反了方法的职责单一原则
2、该方案无法处理因阻塞引起的超时情况
第二个缺点是这个方案的最大限制。如果循环体内出现诸如IO阻塞而引起的程序执行挂起，比如socket.accept()，或者inputstream.read()，这样方法在因阻塞引起的超时发生后将不会返回，因为这时根本无法执行到下次循环的判断条件处。
为了能够处理阻塞超时的情况，只能借助异步多线程方式来完成。
二、利用wait/notify实现异步超时处理
利用多线程机制实现任务方法的异步执行很简单，只需要创建一个类实现Runnable接口，把任务放在重写的run方法中，run方法即为处理任务的方法。在主线程中使用Thread类创建并启动新任务线程即可。
但是，如果需要处理任务线程可能的超时情况，就需要wait/notify机制让主线程和任务线程同步了。具体思路是：让主线程在启动任务线程之后进行带超时参数的wait操作，如果任务线程超时，则wait不再等待，wait返回后主动中断任务线程；如果在超时时间内任务线程执行完毕，则通过notify方法通知主线程，这样主线程的wait方法也可以返回。
主线程代码框架如下，假设任务线程为TaskThread：
public void caller(){
Object monitor=new Object();
TaskThread task=new TaskThread();
Thread thread=new Thread(task);
//对task对象进行各种set操作以初始化任务
try{
synchronized(monitor){
thread.start();
while(线程没有顺利完成){
monitor.wait(timeout);
}
//线程顺利结束，获取并处理结果
}
}
catch(InterruptException e){
//等待已经被超时或者其他原因中断，终止线程thread
}
finally{
//进行资源回收等收尾工作
}
}
任务线程TaskThread通过run方法实现任务，代码框架如下：
@Override
public void run(){
//各种任务执行准备
while((任务没有被要求停止)&&(任务本身的各种判断条件)){
//本次循环中的子任务处理
//包括各种可能的IO阻塞和挂起等待操作
}
synchronized(monitor){ //此处的monitor引用必须主线程中的monitor对象
monitor.notify() //任务执行完毕，唤醒主线程的wait操作
}
}
这种方案可以处理因为IO或其他原因阻塞而引起任务执行超时的情况，当主线程因为wait超时抛出异常时，可以中断任务线程。但是需要注意的是，调用thread.stop()停止线程这种简单暴力的方法是不提倡使用的，而要用其他方法停止线程，而且停止一个处于阻塞状态的线程尤其复杂。
这种方案也存在如下缺点：
1、使用线程间同步操作，增加代码复杂度
2、Runnable接口的run方法没用返回值，不允许抛出异常，不便于任务完后了结果的返回
3、终止未完成的任务线程操作复杂
三、利用Callable接口实现异步超时处理
为了去掉线程间的同步操作，以及能够让任务线程方法有返回值和抛出异常，可以使用Callable接口来替代Runnable接口，相应的主线程也需要相应变动。
Callable接口位于java.utils.concurrent包中，其抽象方法call()有返回值，可以抛出异常。调用Callable接口需要ExecutorService接口实例，而获取call方法的返回值需要Future接口实例。
主线程代码框架如下：
public void caller() throws InterruptedExceptio,TimeoutExceptio,ExecutorException{
TaskThread task=new TaskThread(); //实现Callable接口的任务线程类
ExecutorService exec=Executors.newFixedThreadPool(1);
//对task对象进行各种set操作以初始化任务
Future future=exec.submit(task);
try{
return future.get(this.timeout, TimeUnit.MILLISECONDS);
}
finally{
if(任务线程没有顺利结束){
//终止线程task
}
exec.shutdownNow();
}
}
TaskThread由实现Runnable接口变成了实现Callable接口，call方法的代码和run方法类似，只不过不需要notify方法的调用了。代码框架如下：
@Override
public String call() throws AnyException{
//各种任务执行准备
while((任务没有被要求停止)&&(任务本身的各种判断条件)){
//本次循环中的子任务处理
//包括各种可能的IO阻塞和挂起等待操作
}
}
通过比较可以看出，这种方案的代码更为简洁方便，虽然当任务超时时，终止任务线程的方法依然复杂，但是相比于前一种更简洁，而且比第一种串行方案更具有通用性。
需要指出的是，如何停止一个线程是一个比较复杂而有一定技巧的工作（千万别说用Thread stop方法），因此并没有在本文中论述具体方法，这方面的知识可以参考资料[1,2]，也可以参考我写的专门论述如何停止线程的文章http://blog.csdn.net/mikeszhang/article/details/8751355。
8、算法
1、10亿个数字里里面找最小的10个。
1、首先一点，对于海量数据处理，思路基本上是确定的，必须分块处理，然后再合并起来。
2、对于每一块必须找出10个最大的数，因为第一块中10个最大数中的最小的，可能比第二块中10最大数中的最大的还要大。
3、分块处理，再合并。也就是Google MapReduce 的基本思想。Google有很多的服务器，每个服务器又有很多的CPU，因此，100亿个数分成100块，每个服务器处理一块，1亿个数分成100块，每个CPU处理一块。然后再从下往上合并。注意：分块的时候，要保证块与块之间独立，没有依赖关系，否则不能完全并行处理，线程之间要互斥。另外一点，分块处理过程中，不要有副作用，也就是不要修改原数据，否则下次计算结果就不一样了。
4、上面讲了，对于海量数据，使用多个服务器，多个CPU可以并行，显著提高效率。对于单个服务器，单个CPU有没有意义呢？
也有很大的意义。如果不分块，相当于对100亿个数字遍历，作比较。这中间存在大量的没有必要的比较。可以举个例子说明，全校高一有100个班，我想找出全校前10名的同学，很傻的办法就是，把高一100个班的同学成绩都取出来，作比较，这个比较数据量太大了。应该很容易想到，班里的第11名，不可能是全校的前10名。也就是说，不是班里的前10名，就不可能是全校的前10名。因此，只需要把每个班里的前10取出来，作比较就行了，这样比较的数据量就大大地减少了。
2、有1亿个数字，其中有2个是重复的，快速找到它，时间和空间要最优。
3、2亿个随机生成的无序整数,找出中间大小的值。
4、给一个不知道长度的（可能很大）输入字符串，设计一种方案，将重复的字符排重。
5、遍历二叉树。
6、有3n+1个数字，其中3n个中是重复的，只有1个是不重复的，怎么找出来。
7、写一个字符串（如：www.javastack.cn）反转函数。
8、常用的排序算法，快排，归并、冒泡。 快排的最优时间复杂度，最差复杂度。冒泡排序的优化方案。
9、二分查找的时间复杂度，优势。
10、一个已经构建好的TreeSet，怎么完成倒排序。
11、什么是B+树，B-树，列出实际的使用场景。
12、一个单向链表，删除倒数第N个数据。
13、200个有序的数组，每个数组里面100个元素，找出top20的元素。
14、单向链表，查找中间的那个元素。
9、数据库知识
1、数据库隔离级别有哪些，各自的含义是什么，MYSQL默认的隔离级别是是什么。
·未提交读(Read Uncommitted)：允许脏读，也就是可能读取到其他会话中未提交事务修改的数据
·提交读(Read Committed)：只能读取到已经提交的数据。Oracle等多数数据库默认都是该级别 (不重复读)
·可重复读(Repeated Read)：可重复读。在同一个事务内的查询都是事务开始时刻一致的，InnoDB默认级别。在SQL标准中，该隔离级别消除了不可重复读，但是还存在幻象读
·串行读(Serializable)：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞
MYSQL默认是RepeatedRead级别
2、什么是幻读。
不可重复读的重点是修改 :
同样的条件,你读取过的数据,再次读取出来发现值不一样了
幻读的重点在于新增或者删除
同样的条件,第 1 次和第 2 次读出来的记录数不一样
3、MYSQL有哪些存储引擎，各自优缺点。
MyISAM： 拥有较高的插入，查询速度，但不支持事务
InnoDB ：5.5版本后Mysql的默认数据库，事务型数据库的首选引擎，支持ACID事务，支持行级锁定
BDB： 源自Berkeley DB，事务型数据库的另一种选择，支持COMMIT和ROLLBACK等其他事务特性
Memory ：所有数据置于内存的存储引擎，拥有极高的插入，更新和查询效率。但是会占用和数据量成正比的内存空间。并且其内容会在Mysql重新启动时丢失
Merge ：将一定数量的MyISAM表联合而成一个整体，在超大规模数据存储时很有用
Archive ：非常适合存储大量的独立的，作为历史记录的数据。因为它们不经常被读取。Archive拥有高效的插入速度，但其对查询的支持相对较差
Federated： 将不同的Mysql服务器联合起来，逻辑上组成一个完整的数据库。非常适合分布式应用
Cluster/NDB ：高冗余的存储引擎，用多台数据机器联合提供服务以提高整体性能和安全性。适合数据量大，安全和性能要求高的应用
CSV： 逻辑上由逗号分割数据的存储引擎。它会在数据库子目录里为每个数据表创建一个.CSV文件。这是一种普通文本文件，每个数据行占用一个文本行。CSV存储引擎不支持索引。
BlackHole ：黑洞引擎，写入的任何数据都会消失，一般用于记录binlog做复制的中继
另外，Mysql的存储引擎接口定义良好。有兴趣的开发者通过阅读文档编写自己的存储引擎。
4、高并发下，如何做到安全的修改同一行数据。
使用悲观锁 悲观锁本质是当前只有一个线程执行操作，结束了唤醒其他线程进行处理。
也可以缓存队列中锁定主键。
5、乐观锁和悲观锁是什么，INNODB的标准行级锁有哪2种，解释其含义。
乐观锁是设定每次修改都不会冲突，只在提交的时候去检查，悲观锁设定每次修改都会冲突，持有排他锁。
行级锁分为共享锁和排他锁两种 共享锁又称读锁 排他锁又称写锁
6、SQL优化的一般步骤是什么，怎么看执行计划，如何理解其中各个字段的含义。
查看慢日志（show [session|gobal] status ），定位慢查询，查看慢查询执行计划 根据执行计划确认优化方案
查看执行计划:Explain sql
select_type:表示select类型。常见的取值有SIMPLE（简单表，即不使用连接或者子查询）、PRIMARY（主查询，即外层的查询）、UNION（union中的第二个或者后面的查询语句）、SUBQUERY（子查询中的第一个SELECT）等。
talbe：输出结果集的表。
type:表的连接类型。性能由高到底：system（表中仅有一行）、const（表中最多有一个匹配行）、eq_ref、ref、ref_null、index_merge、unique_subquery、index_subquery、range、idnex等
possible_keys:查询时，可能使用的索引
key:实际使用的索引
key_len:索引字段的长度
rows：扫描行的数量
Extra：执行情况的说明和描述
7、数据库会死锁吗，举一个死锁的例子，mysql怎么解决死锁。
产生死锁的原因主要是：
（1）系统资源不足。
（2） 进程运行推进的顺序不合适。
（3）资源分配不当等。
如果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则就会因争夺有限的资源而陷入死锁。其次，进程运行推进顺序与速度不同，也可能产生死锁。
产生死锁的四个必要条件：
（1） 互斥条件：一个资源每次只能被一个进程使用。
（2） 请求与保持条件：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
（3） 不剥夺条件:进程已获得的资源，在末使用完之前，不能强行剥夺。
（4） 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。
这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。
这里提供两个解决数据库死锁的方法：
1）重启数据库（谁用谁知道）
2）杀掉抢资源的进程：
先查哪些进程在抢资源：SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;
杀掉它们：Kill trx_mysql_thread_id；
8、MYsql的索引原理，索引的类型有哪些，如何创建合理的索引，索引如何优化。
索引是通过复杂的算法，提高数据查询性能的手段。从磁盘io到内存io的转变
普通索引，主键，唯一，单列/多列索引建索引的几大原则
1.最左前缀匹配原则，非常重要的原则，mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配，比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整。
2.=和in可以乱序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序，mysql的查询优化器会帮你优化成索引可以识别的形式
3.尽量选择区分度高的列作为索引,区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，比例越大我们扫描的记录数越少，唯一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就是0，那可能有人会问，这个比例有什么经验值吗？使用场景不同，这个值也很难确定，一般需要join的字段我们都要求是0.1以上，即平均1条扫描10条记录
4.索引列不能参与计算，保持列“干净”，比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很简单，b+树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，显然成本太大。所以语句应该写成create_time = unix_timestamp(’2014-05-29’);
5.尽量的扩展索引，不要新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可
9、聚集索引和非聚集索引的区别。
“聚簇”就是索引和记录紧密在一起。
非聚簇索引 索引文件和数据文件分开存放，索引文件的叶子页只保存了主键值，要定位记录还要去查找相应的数据块。
聚集还是非聚集指的是 B+Tree 叶节点存的是指针还是数据记录
MyISAM 索引和数据分离，使用的是非聚集索引
InnoDB 数据文件就是索引文件，主键索引就是聚集索引
10、select for update 是什么含义，会锁表还是锁行或是其他。
每次拿数据的时候都认为别的线程会修改数据，所以每次拿数据的时候都会给数据上锁。上锁之后，当别的线程想要拿数据时，就会阻塞。直到给数据上锁的线程将事务提交或者回滚。传统的关系数据库里面很多用了这种锁机制，比如行锁，表锁，共享锁，排他锁等，都是在做操作之前先上锁。
(1)、 左边的线程，在事务中通过select for update语句给sid=1的数据行上了锁，右边的线程此时可以使用select语句读取数据，但是如果也使用select for update语句就会阻塞，使用update, add, delete也会阻塞。 而当左边的线程将事务提交(或者回滚)，右边的线程就会获取锁，线程不再阻塞
(2) 、此时右边的线程获取锁，左边的线程执行此类操作，也会被阻塞。
(3) 、当然，select都不行，update等写操作也要阻塞等待。for update是排他锁。
11、为什么要用Btree实现，它是怎么分裂的，什么时候分裂，为什么是平衡的。
B+是btree的变种，本质都是btree，btree+与B-Tree相比，B+Tree有以下不同点：
每个节点的指针上限为2d而不是2d+1。
内节点不存储data，只存储key；叶子节点不存储指针。
http://lcbk.net/9602.html
Btree 怎么分裂的，什么时候分裂，为什么是平衡的。
Key 超过1024才分裂B树为甚会分裂？ 因为随着数据的增多，一个结点的key满了，为了保持B树的特性，就会产生分裂，就向
红黑树和AVL树为了保持树的性质需要进行旋转一样！
12、数据库的ACID是什么。
ACID 是什么。
A，atomic，原子性，要么都提交，要么都失败，不能一部分成功，一部分失败。
C，consistent，一致性，事物开始及结束后，数据的一致性约束没有被破坏
I，isolation，隔离性，并发事物间相互不影响，互不干扰。
D，durability,持久性，已经提交的事物对数据库所做的更新必须永久保存。即便发生崩溃，也不能被回滚或数据丢失。
13、某个表有近千万数据，CRUD比较慢，如何优化。
数据千万级别之多，占用的存储空间也比较大，可想而知它不会存储在一块连续的物理空间上，而是链式存储在多个碎片的物理空间上。可能对于长字符串的比较，就用更多的时间查找与比较，这就导致用更多的时间。
可以做表拆分，减少单表字段数量，优化表结构。
在保证主键有效的情况下，检查主键索引的字段顺序，使得查询语句中条件的字段顺序和主键索引的字段顺序保持一致。
**主要两种拆分 垂直拆分，水平拆分。
1.垂直分表
根据数据库里面数据表的相关性进行拆分。 例如，用户表中既有用户的登录信息又有用户的基本信息，可以将用户表拆分成两个单独的表，甚至放到单独的库做分库。简单来说垂直拆分是指数据表列的拆分，把一张列比较多的表拆分为多张表。
垂直拆分的优点： 可以使得行数据变小，在查询时减少读取的Block数，减少I/O次数。此外，垂直分区可以简化表的结构，易于维护。
垂直拆分的缺点： 主键会出现冗余，需要管理冗余列，并会引起Join操作，可以通过在应用层进行Join来解决。此外，垂直分区会让事务变得更加复杂；
2.水平分表
水平拆分是指数据表行的拆分，表的行数超过200万行时，就会变慢，这时可以把一张的表的数据拆成多张表来存放。举个例子：我们可以将用户信息表拆分成多个用户信息表，这样就可以避免单一表数据量过大对性能造成影响
3.水平分库分表
水平拆分可以支持非常大的数据量。需要注意的一点是:分表仅仅是解决了单一表数据过大的问题，但由于表的数据还是在同一台机器上，其实对于提升MySQL并发能力没有什么意义，所以水平拆分最好分库 。
水平拆分能够 支持非常大的数据量存储，应用端改造也少，但 分片事务难以解决 ，跨界点Join性能较差，逻辑复杂。《Java工程师修炼之道》的作者推荐 尽量不要对数据进行分片，因为拆分会带来逻辑、部署、运维的各种复杂度 ，一般的数据表在优化得当的情况下支撑千万以下的数据量是没有太大问题的。如果实在要分片，尽量选择客户端分片架构，这样可以减少一次和中间件的网络I/O。
水平分库分表切分规则
RANGE划分：RANGE从0到10000一个表，10001到20000一个表；
HASH取模：一个商场系统，一般都是将用户，订单作为主表，然后将和它们相关的作为附表，这样不会造成跨库事务之类的问题。 取用户id，然后hash取模，分配到不同的数据库上。
地理区域：比如按照华东，华南，华北这样来区分业务，七牛云应该就是如此。
时间：按照时间切分，就是将6个月前，甚至一年前的数据切出去放到另外的一张表，因为随着时间流逝，这些表的数据 被查询的概率变小，所以没必要和“热数据”放在一起，这个也是“冷热数据分离”。
分库分表后面临的问题
1.事务支持
分库分表后，就成了分布式事务了。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价； 如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。
2.跨库join
只要是进行切分，跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。
3.跨节点的count,order by,group by以及聚合函数问题
这些是一类问题，因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。解决方案：与解决跨节点join问题的类似，分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多。但如果结果集很大，对应用程序内存的消耗是一个问题。
4.数据迁移，容量规划，扩容等问题
来自淘宝综合业务平台团队，它利用对2的倍数取余具有向前兼容的特性（如对4取余得1的数对2取余也是1）来分配数据，避免了行级别的数据迁移，但是依然需要进行表级别的迁移，同时对扩容规模和分表数量都有限制。总得来说，这些方案都不是十分的理想，多多少少都存在一些缺点，这也从一个侧面反映出了Sharding扩容的难度。
5.ID问题
一旦数据库被切分到多个物理结点上，我们将不能再依赖数据库自身的主键生成机制。一方面，某个分区数据库自生成的ID无法保证在全局上是唯一的；另一方面，应用程序在插入数据之前需要先获得ID,以便进行SQL路由.
下面补充一下数据库分片的两种常见方案：
客户端代理： 分片逻辑在应用端，封装在jar包中，通过修改或者封装JDBC层来实现。 当当网的Sharding-JDBC 、阿里的TDDL是两种比较常用的实现。
中间件代理： 在应用和数据中间加了一个代理层。分片逻辑统一维护在中间件服务中。 我们现在谈的 Mycat 、360的Atlas、网易的DDB等等都是这种架构的实现。
14、Mysql怎么优化table scan的。
避免在where子句中对字段进行is null判断
应尽量避免在where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。
避免在where 子句中使用or 来连接条件
in 和not in 也要慎用
Like查询（非左开头）
使用NUM=@num参数这种
where 子句中对字段进行表达式操作num/2=XX
在where子句中对字段进行函数操作
15、如何写sql能够有效的使用到复合索引。
由于复合索引的组合索引，类似多个木板拼接在一起，如果中间断了就无法用了，所以要能用到复合索引，首先开头(第一列)要用上，比如index(a,b) 这种，我们可以select table tname where a=XX 用到第一列索引 如果想用第二列 可以 and b=XX 或者and b like‘TTT%
第一个字段必须使用，坚持最左前缀匹配原则，尽量不要再前面使用范围查询
16、mysql中in 和exists 区别。
mysql 中 in 和 exists 区别。
mysql中的in语句是把外表和内表作hash 连接，而exists语句是对外表作loop循环，每次loop循环再对内表进行查询。一直大家都认为exists比in语句的效率要高，这种说法其实是不准确的。这个是要区分环境的。
如果查询的两个表大小相当，那么用in和exists差别不大。
如果两个表中一个较小，一个是大表，则子查询表大的用exists，子查询表小的用in：
not in 和not exists如果查询语句使用了not in 那么内外表都进行全表扫描，没有用到索引；而not extsts 的子查询依然能用到表上的索引。所以无论那个表大，用not exists都比not in要快。
1.EXISTS只返回TRUE或FALSE，不会返回UNKNOWN。
2.IN当遇到包含NULL的情况，那么就会返回UNKNOWN。
17、数据库自增主键可能的问题。
1.主键重复问题。导致数据库为单点，不可进行拆库。
2.表锁导致阻塞的性能问题。
3.自增主键不连续。
当innodb_autoinc_lock_mode为0时候， 自增id都会连续，但是会出现表锁的情况，解决该问题可以把innodb_autoinc_lock_mode 设置为1，甚至是2。会提高性能，但是会在一定的条件下导致自增id不连续。
18、MVCC的含义，如何实现的。
MVCC(Multi Version Concurrency Control的简称)，代表多版本并发控制。与MVCC相对的，是基于锁的并发控制，Lock-Based Concurrency Control)。
MVCC最大的优势：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能
MVCC是为了解决什么问题?
大多数的MYSQL事务型存储引擎,如,InnoDB，Falcon以及PBXT都不使用一种简单的行锁机制.事实上,他们都和MVCC–多版本并发控制来一起使用。
大家都应该知道,锁机制可以控制并发操作,但是其系统开销较大,而MVCC可以在大多数情况下代替行级锁,使用MVCC,能降低其系统开销。
MVCC是通过在每行记录后面保存两个隐藏的列来实现的。这两个列，一个保存了行的创建时间，一个保存行的过期时间（或删除时间）。当然存储的并不是实际的时间值，而是系统版本号（system version number)。每开始一个新的事务，系统版本号都会自动递增。事务开始时刻的系统版本号会作为事务的版本号，用来和查询到的每行记录的版本号进行比较。
下面看一下在REPEATABLE READ隔离级别下，MVCC具体是如何操作的。
SELECT
InnoDB会根据以下两个条件检查每行记录：
1、InnoDB只查找版本早于当前事务版本的数据行（也就是，行的系统版本号小于或等于事务的系统版本号），这样可以确保事务读取的行，要么是在事务开始前已经存在的，要么是事务自身插入或者修改过的。
2、行的删除版本要么未定义，要么大于当前事务版本号。这可以确保事务读取到的行，在事务开始之前未被删除。
只有符合上述两个条件的记录，才能返回作为查询结果。
INSERT
InnoDB为新插入的每一行保存当前系统版本号作为行版本号。
DELETE
InnoDB为删除的每一行保存当前系统版本号作为行删除标识。
UPDATE
InnoDB为插入一行新记录，保存当前系统版本号作为行版本号，同时保存当前系统版本号到原来的行作为行删除标识。
保存这两个额外系统版本号，使大多数读操作都可以不用加锁。这样设计使得读数据操作很简单，性能很好，并且也能保证只会读取到符合标准的行，不足之处是每行记录都需要额外的存储空间，需要做更多的行检查工作，以及一些额外的维护工作
19、你做过的项目里遇到分库分表了吗，怎么做的，有用到中间件么，比如sharding jdbc等,他们的原理知道么。
国网项目中:
分库: 根据项目分库,比如营销系统一个库,采集系统一个库,档案系统一个库,公共资源一个库
分表:
1.同库分表：所有的分表都在一个数据库中，由于数据库中表名不能重复，因此需要把数据表名起成不同的名字。
优点：由于都在一个数据库中，公共表，不必进行复制，处理更简单
缺点：由于还在一个数据库中，CPU、内存、文件IO、网络IO等瓶颈还是无法解决，只能降低单表中的数据记录数。
2.不同库分表：由于分表在不同的数据库中，这个时候就可以使用同样的表名。
优点：CPU、内存、文件IO、网络IO等瓶颈可以得到有效解决，表名相同，处理起来相对简单
缺点：公共表由于在所有的分表都要使用，因此要进行复制、同步
举例:比如采集系统中,一条采集数据包含了采集时间,协议类型,DTU ID,DTU地址,采集命令,采集数据,A相电压,B相电压,C相电压,A相电流,B相电流,C相电流,A相功率因数,B相功率因数,C相功率因数等等五六十个字段,将他们分成DTU表,命令表,数据表等几个表,进行关联查询
Sharding-JDBC
定位为轻量级Java框架，在Java的JDBC层提供的额外服务。 它使用客户端直连数据库，以jar包形式提供服务，无需额外部署和依赖，可理解为增强版的JDBC驱动，完全兼容JDBC和各种ORM框架。
适用于任何基于Java的ORM框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。
基于任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP等。
支持任意实现JDBC规范的数据库。目前支持MySQL，Oracle，SQLServer和PostgreSQL。
原理
Sharding jdbc是基于JDBC协议实现的，当我们获得dataSource时，这个dataSource是Sharding jdbc自己定义的一个SpringShardingDataSource类型的数据源，该数据源在返回getConnection()及prepareStatement()时，分别返回ShardingConnection和ShardingPreparedStatement的实例对象。然后在executeQuery()时，ShardingPreparedStatement做了这样的一件事：
根据逻辑sql，经过分库分表策略逻辑计算，获得分库分表的路由结果SQLRouteResult； SQLRouteResult中包含真实的数据源以及转换后的真正sql，利用真实的数据源去执行获得ResultSet； 将ResultSet列表封装成一个可以顺序读的ResultSet对象IteratorReducerResultSet。
准备环境。由于Sharding jdbc分库分表中ShardingRule这个类是贯穿整个路由过程，我们在Spring中写好Sharding jdbc的配置，利用反射获取一个这个对象。（Sharding jdbc版本以及配置，在文章最后列出，方便debug这个过程） sql解析。Sharding jdbc使用阿里的Druid库解析sql。在这个过程中，Sharding jdbc实现了一个自己的sql解析内容缓存容器SqlBuilder。当语法分析中解析到一个表名的时候，在SqlBuilder中缓存一个sql相关的逻辑表名的token。并且，Sharding jdbc会将sql按照语义解析为多个segment。例如，"select id, name, price, publish, intro from book where id = ？"将解析为，“select id, name, price, publish, intro | from | book | where | id = ?”。 分库分表路由。根据ShardingRule中指定的分库分表列的参数值，以及分库分表策略，实行分库分表，得到一个RoutingResult 。RoutingResult 中包含一个真实数据源，以及逻辑表名和实际表名。 sql改写。在SqlBuilder中，查找sql中解析的segment，将和逻辑表名一致的segment替换成实际表名。（segment中可以标注该地方是不是表名）
https://blog.csdn.net/wenyuan65/article/details/83715471
20、MYSQL的主从延迟怎么解决。
从库同步延迟情况出现的
● show slave status显示参数Seconds_Behind_Master不为0，这个数值可能会很大
● show slave status显示参数Relay_Master_Log_File和Master_Log_File显示bin-log的编号相差很大，说明bin-log在从库上没有及时同步，所以近期执行的bin-log和当前IO线程所读的bin-log相差很大
● mysql的从库数据目录下存在大量mysql-relay-log日志，该日志同步完成之后就会被系统自动删除，存在大量日志，说明主从同步延迟很厉害
MySQL数据库主从同步延迟是怎么产生的？当主库的TPS并发较高时，产生的DDL数量超过slave一个sql线程所能承受的范围，那么延时就产生了，当然还有就是可能与slave的大型query语句产生了锁等待。首要原因：数据库在业务上读写压力太大，CPU计算负荷大，网卡负荷大，硬盘随机IO太高次要原因：读写binlog带来的性能影响，网络传输延迟。
1)、架构方面
1.业务的持久化层的实现采用分库架构，mysql服务可平行扩展，分散压力。
2.单个库读写分离，一主多从，主写从读，分散压力。这样从库压力比主库高，保护主库。
3.服务的基础架构在业务和mysql之间加入memcache或者redis的cache层。降低mysql的读压力。
4.不同业务的mysql物理上放在不同机器，分散压力。
5.使用比主库更好的硬件设备作为slave总结，mysql压力小，延迟自然会变小。
10、消息队列
1、消息队列的使用场景。
解耦(项目解耦):多个系消费一个系统提供的数据,没有mq之前,调用之后,都需要提供数据的那个系统修改代码,使用了mq之后,提供数据的系统只需要把数据发送到mq里,谁需要,谁就去里面拉取
异步(异步通知):A系统接收一个请求，需要在自己本地写库，还需要在BCD三个系统写库，自己本地写库要3ms，BCD三个系统分别写库要300ms、450ms、200ms。最终请求总延时是3 + 300 + 450 + 200 = 953ms，接近1s，用户感觉搞个什么东西，慢死了慢死了。使用mq异步之后,接收到请求就直接返回了,时间很快,剩余的后台逻辑只需要在后台慢慢执行就可以了
削峰(多客户访问):每秒5000用户的去请求系统,数据库并发能力也就2000,肯定会挂掉,可以在中间加一个mq,每次请求到达的时候,不用直接操作数据库,而是放在了队列里,然后数据操作层每秒只需要拉取2000个就行了,每秒进来5000个消费2000个,也就是说每秒会积压3000,等高峰期过了之后,请求也就几十个,继续慢慢消费,仍然是每秒2000个的消费,很快的就会消费完
2、消息的重发，补充策略。
1、发送端MQ-client(消息生产者：Producer)将消息发送给MQ-server；
2、MQ-server将消息落地；
3、MQ-server回ACK给MQ-client（Producer）；
4、MQ-server将消息发送给消息接受端MQ-client(消息消费者：Customer)；
5、MQ-client（Customer）消费接受到消息后发送ACK给MQ-server；
6、MQ-server将落地消息删除
二、消息重复发送原因
为了保证消息必达，MQ使用了消息超时、重传、确认机制。使得消息可能被重复发送，如上图中，由于网络不可达原因：3和5中断，可能导致消息重发。消息生产者a收不到MQ-server的ACK，重复向MQ-server发送消息。MQ-server收不到消息消费者c的ACK，重复向消息消费者c发消息。
三、消息重复发送产生的后果
举个例子：购买会员卡，上游支付系统负责给用户扣款，下游系统负责给用户发卡，通过MQ异步通知。不管是上半场的ACK丢失，导致MQ收到重复的消息，还是下半场ACK丢失，导致购卡系统收到重复的购卡通知，都可能出现，上游扣了一次钱，下游发了多张卡。
四、MQ内部如何做到幂等性的
对于每条消息，MQ内部生成一个全局唯一、与业务无关的消息ID：inner-msg-id。当MQ-server接收到消息时，先根据inner-msg-id判断消息是否重复发送，再决定是否将消息落地到DB中。这样，有了这个inner-msg-id作为去重的依据就能保证一条消息只能一次落地到DB。
五、消息消费者应当如何做到幂等性
1、对于非幂等性业务且要求实现幂等性业务：生成一个唯一ID标记每一条消息，将消息处理成功和去重日志通过事物的形式写入去重表。
2、对于非幂等性业务可不实现幂等性的业务：权衡去重所花的代价决定是否需要实现幂等性，如：购物会员卡成功，向用户发送通知短信，发送一次或者多次影响不大。不做幂等性可以省掉写去重日志的操作。
3、如何保证消息的有序性。
先看看顺序会错乱的俩场景
（1）rabbitmq：一个queue，多个consumer，这不明显乱了
（2）kafka：一个topic，一个partition，一个consumer，内部多线程，这不也明显乱了
那如何保证消息的顺序性呢？简单简单
（1）rabbitmq：拆分多个queue，每个queue一个consumer，就是多一些queue而已，确实是麻烦点；或者就一个queue但是对应一个consumer，然后这个consumer内部用内存队列做排队，然后分发给底层不同的worker来处理
（2）kafka：一个topic，一个partition，一个consumer，内部单线程消费，写N个内存queue，然后N个线程分别消费一个内存queue即可
4、用过哪些MQ，和其他mq比较有什么优缺点，MQ的连接是线程安全的吗，你们公司的MQ服务架构怎样的。
ActiveMQ
单机吞吐量：万级
topic数量都吞吐量的影响：
时效性：ms级
可用性：高，基于主从架构实现高可用性
消息可靠性：有较低的概率丢失数据
功能支持：MQ领域的功能极其完备
总结：
非常成熟，功能强大，在早些年业内大量的公司以及项目中都有应用
偶尔会有较低概率丢失消息
现在社区以及国内应用都越来越少，官方社区现在对ActiveMQ 5.x维护越来越少，几个月才发布一个版本
主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用
RabbitMQ
单机吞吐量：万级
topic数量都吞吐量的影响：
时效性：微秒级，延时低是一大特点。
可用性：高，基于主从架构实现高可用性
消息可靠性：
功能支持：基于erlang开发，所以并发能力很强，性能极其好，延时很低
总结：
erlang语言开发，性能极其好，延时很低；
吞吐量到万级，MQ功能比较完备
开源提供的管理界面非常棒，用起来很好用
社区相对比较活跃，几乎每个月都发布几个版本分
在国内一些互联网公司近几年用rabbitmq也比较多一些 但是问题也是显而易见的，RabbitMQ确实吞吐量会低一些，这是因为他做的实现机制比较重。
erlang开发，很难去看懂源码，基本职能依赖于开源社区的快速维护和修复bug。
rabbitmq集群动态扩展会很麻烦，不过这个我觉得还好。其实主要是erlang语言本身带来的问题。很难读源码，很难定制和掌控。
RocketMQ
单机吞吐量：十万级
topic数量都吞吐量的影响：topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降。可支持大量topic是一大优势。
时效性：ms级
可用性：非常高，分布式架构
消息可靠性：经过参数优化配置，消息可以做到0丢失
功能支持：MQ功能较为完善，还是分布式的，扩展性好
总结：
接口简单易用，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，社区维护还可以，可靠性和可用性都是ok的，还可以支撑大规模的topic数量，支持复杂MQ业务场景
而且一个很大的优势在于，源码是java，我们可以自己阅读源码，定制自己公司的MQ，可以掌控
社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些，然后接口这块不是按照标准JMS规范走的有些系统要迁移需要修改大量代码
Kafka
单机吞吐量：十万级，最大的优点，就是吞吐量高。
topic数量都吞吐量的影响：topic从几十个到几百个的时候，吞吐量会大幅度下降。所以在同等机器下，kafka尽量保证topic数量不要过多。如果要支撑大规模topic，需要增加更多的机器资源
时效性：ms级
可用性：非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性：经过参数优化配置，消息可以做到0丢失
功能支持：功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用
总结：
kafka的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展
同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量
kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略
最后
一般的业务系统要引入MQ，最早大家都用ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃
后来大家开始用RabbitMQ，但是确实erlang语言阻止了大量的java工程师去深入研究和掌控他，对公司而言，几乎处于不可控的状态，但是确实人家是开源的，比较稳定的支持，活跃度也高；
不过现在确实越来越多的公司，会去用RocketMQ，确实很不错，但是要想好社区万一突然黄掉的风险
所以中小型公司，技术实力较为一般，技术挑战不是特别高，用RabbitMQ是不错的选择；大型公司，基础架构研发实力较强，用RocketMQ是很好的选择
如果是大数据领域的实时计算、日志采集等场景，用Kafka是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范
5、MQ系统的数据如何保证不丢失
rabbitmq
1）生产者弄丢了数据
生产者将数据发送到rabbitmq的时候，可能数据就在半路给搞丢了，因为网络啥的问题，都有可能。
此时可以选择用rabbitmq提供的事务功能，就是生产者发送数据之前开启rabbitmq事务（channel.txSelect），然后发送消息，如果消息没有成功被rabbitmq接收到，那么生产者会收到异常报错，此时就可以回滚事务（channel.txRollback），然后重试发送消息；如果收到了消息，那么可以提交事务（channel.txCommit）。但是问题是，rabbitmq事务机制一搞，基本上吞吐量会下来，因为太耗性能。
所以一般来说，如果你要确保说写rabbitmq的消息别丢，可以开启confirm模式，在生产者那里设置开启confirm模式之后，你每次写的消息都会分配一个唯一的id，然后如果写入了rabbitmq中，rabbitmq会给你回传一个ack消息，告诉你说这个消息ok了。如果rabbitmq没能处理这个消息，会回调你一个nack接口，告诉你这个消息接收失败，你可以重试。而且你可以结合这个机制自己在内存里维护每个消息id的状态，如果超过一定时间还没接收到这个消息的回调，那么你可以重发。
事务机制和cnofirm机制最大的不同在于，事务机制是同步的，你提交一个事务之后会阻塞在那儿，但是confirm机制是异步的，你发送个消息之后就可以发送下一个消息，然后那个消息rabbitmq接收了之后会异步回调你一个接口通知你这个消息接收到了。
所以一般在生产者这块避免数据丢失，都是用confirm机制的。
2）rabbitmq弄丢了数据
就是rabbitmq自己弄丢了数据，这个你必须开启rabbitmq的持久化，就是消息写入之后会持久化到磁盘，哪怕是rabbitmq自己挂了，恢复之后会自动读取之前存储的数据，一般数据不会丢。除非极其罕见的是，rabbitmq还没持久化，自己就挂了，可能导致少量数据会丢失的，但是这个概率较小。
设置持久化有两个步骤，第一个是创建queue的时候将其设置为持久化的，这样就可以保证rabbitmq持久化queue的元数据，但是不会持久化queue里的数据；第二个是发送消息的时候将消息的deliveryMode设置为2，就是将消息设置为持久化的，此时rabbitmq就会将消息持久化到磁盘上去。必须要同时设置这两个持久化才行，rabbitmq哪怕是挂了，再次重启，也会从磁盘上重启恢复queue，恢复这个queue里的数据。
而且持久化可以跟生产者那边的confirm机制配合起来，只有消息被持久化到磁盘之后，才会通知生产者ack了，所以哪怕是在持久化到磁盘之前，rabbitmq挂了，数据丢了，生产者收不到ack，你也是可以自己重发的。
哪怕是你给rabbitmq开启了持久化机制，也有一种可能，就是这个消息写到了rabbitmq中，但是还没来得及持久化到磁盘上，结果不巧，此时rabbitmq挂了，就会导致内存里的一点点数据会丢失。
3）消费端弄丢了数据
rabbitmq如果丢失了数据，主要是因为你消费的时候，刚消费到，还没处理，结果进程挂了，比如重启了，那么就尴尬了，rabbitmq认为你都消费了，这数据就丢了。
这个时候得用rabbitmq提供的ack机制，简单来说，就是你关闭rabbitmq自动ack，可以通过一个api来调用就行，然后每次你自己代码里确保处理完的时候，再程序里ack一把。这样的话，如果你还没处理完，不就没有ack？那rabbitmq就认为你还没处理完，这个时候rabbitmq会把这个消费分配给别的consumer去处理，消息是不会丢的。
kafka
1）消费端弄丢了数据
唯一可能导致消费者弄丢数据的情况，就是说，你那个消费到了这个消息，然后消费者那边自动提交了offset，让kafka以为你已经消费好了这个消息，其实你刚准备处理这个消息，你还没处理，你自己就挂了，此时这条消息就丢咯。
这不是一样么，大家都知道kafka会自动提交offset，那么只要关闭自动提交offset，在处理完之后自己手动提交offset，就可以保证数据不会丢。但是此时确实还是会重复消费，比如你刚处理完，还没提交offset，结果自己挂了，此时肯定会重复消费一次，自己保证幂等性就好了。
生产环境碰到的一个问题，就是说我们的kafka消费者消费到了数据之后是写到一个内存的queue里先缓冲一下，结果有的时候，你刚把消息写入内存queue，然后消费者会自动提交offset。
然后此时我们重启了系统，就会导致内存queue里还没来得及处理的数据就丢失了
2）kafka弄丢了数据
这块比较常见的一个场景，就是kafka某个broker宕机，然后重新选举partiton的leader时。大家想想，要是此时其他的follower刚好还有些数据没有同步，结果此时leader挂了，然后选举某个follower成leader之后，他不就少了一些数据？这就丢了一些数据啊。
生产环境也遇到过，我们也是，之前kafka的leader机器宕机了，将follower切换为leader之后，就会发现说这个数据就丢了
所以此时一般是要求起码设置如下4个参数：
给这个topic设置replication.factor参数：这个值必须大于1，要求每个partition必须有至少2个副本
在kafka服务端设置min.insync.replicas参数：这个值必须大于1，这个是要求一个leader至少感知到有至少一个follower还跟自己保持联系，没掉队，这样才能确保leader挂了还有一个follower吧
在producer端设置acks=all：这个是要求每条数据，必须是写入所有replica(副本/follower)之后，才能认为是写成功了
在producer端设置retries=MAX（很大很大很大的一个值，无限次重试的意思）：这个是要求一旦写入失败，就无限重试，卡在这里了
我们生产环境就是按照上述要求配置的，这样配置之后，至少在kafka broker端就可以保证在leader所在broker发生故障，进行leader切换时，数据不会丢失
3）生产者会不会弄丢数据
如果按照上述的思路设置了ack=all，一定不会丢，要求是，你的leader接收到消息，所有的follower都同步到了消息之后，才认为本次写成功了。如果没满足这个条件，生产者会自动不断的重试，重试无限次。
6、rabbitMq如何实现集群高可用。kafka的高可用性
rabbitMq
rabbitmq有三种模式：单机模式，普通集群模式，镜像集群模式
1）单机模式
就是demo级别的，一般就是你本地启动了玩玩儿的，没人生产用单机模式
2）普通集群模式
意思就是在多台机器上启动多个rabbitmq实例，每个机器启动一个。但是你创建的queue，只会放在一个rabbtimq实例上，但是每个实例都同步queue的元数据。完了你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从queue所在实例上拉取数据过来。
这种方式确实很麻烦，也不怎么好，没做到所谓的分布式，就是个普通集群。因为这导致你要么消费者每次随机连接一个实例然后拉取数据，要么固定连接那个queue所在实例消费数据，前者有数据拉取的开销，后者导致单实例性能瓶颈。
而且如果那个放queue的实例宕机了，会导致接下来其他实例就无法从那个实例拉取，如果你开启了消息持久化，让rabbitmq落地存储消息的话，消息不一定会丢，得等这个实例恢复了，然后才可以继续从这个queue拉取数据。
所以这个事儿就比较尴尬了，这就没有什么所谓的高可用性可言了，这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个queue的读写操作。
3）镜像集群模式
这种模式，才是所谓的rabbitmq的高可用模式，跟普通集群模式不一样的是，你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。
这样的话，好处在于，你任何一个机器宕机了，没事儿，别的机器都可以用。坏处在于，第一，这个性能开销也太大了吧，消息同步所有机器，导致网络带宽压力和消耗很重！第二，这么玩儿，就没有扩展性可言了，如果某个queue负载很重，你加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue
那么怎么开启这个镜像集群模式呢？我这里简单说一下，避免面试人家问你你不知道，其实很简单rabbitmq有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候可以要求数据同步到所有节点的，也可以要求就同步到指定数量的节点，然后你再次创建queue的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。
kafka
kafka一个最基本的架构认识：多个broker组成，每个broker是一个节点；你创建一个topic，这个topic可以划分为多个partition，每个partition可以存在于不同的broker上，每个partition就放一部分数据。
这就是天然的分布式消息队列，就是说一个topic的数据，是分散放在多个机器上的，每个机器就放一部分数据。
实际上rabbitmq之类的，并不是分布式消息队列，他就是传统的消息队列，只不过提供了一些集群、HA的机制而已，因为无论怎么玩儿，rabbitmq一个queue的数据都是放在一个节点里的，镜像集群下，也是每个节点都放这个queue的完整数据。
kafka 0.8以前，是没有HA机制的，就是任何一个broker宕机了，那个broker上的partition就废了，没法写也没法读，没有什么高可用性可言。
kafka 0.8以后，提供了HA机制，就是replica副本机制。每个partition的数据都会同步到吉他机器上，形成自己的多个replica副本。然后所有replica会选举一个leader出来，那么生产和消费都跟这个leader打交道，然后其他replica就是follower。写的时候，leader会负责把数据同步到所有follower上去，读的时候就直接读leader上数据即可。只能读写leader？很简单，要是你可以随意读写每个follower，那么就要care数据一致性的问题，系统复杂度太高，很容易出问题。kafka会均匀的将一个partition的所有replica分布在不同的机器上，这样才可以提高容错性。
这么搞，就有所谓的高可用性了，因为如果某个broker宕机了，没事儿，那个broker上面的partition在其他机器上都有副本的，如果这上面有某个partition的leader，那么此时会重新选举一个新的leader出来，大家继续读写那个新的leader即可。这就有所谓的高可用性了。
写数据的时候，生产者就写leader，然后leader将数据落地写本地磁盘，接着其他follower自己主动从leader来pull数据。一旦所有follower同步好数据了，就会发送ack给leader，leader收到所有follower的ack之后，就会返回写成功的消息给生产者。（当然，这只是其中一种模式，还可以适当调整这个行为）
消费的时候，只会从leader去读，但是只有一个消息已经被所有follower都同步成功返回ack的时候，这个消息才会被消费者读到。
实际上这块机制，讲深了，是可以非常之深入的，但是我还是回到我们这个课程的主题和定位，聚焦面试，至少你听到这里大致明白了kafka是如何保证高可用机制的了，对吧？不至于一无所知，现场还能给面试官画画图。要遇上面试官确实是kafka高手，深挖了问，那你只能说不好意思，太深入的你没研究过。
但是大家一定要明白，这个事情是要权衡的，你现在是要快速突击常见面试题体系，而不是要深入学习kafka，要深入学习kafka，你是没那么多时间的。你只能确保，你之前也许压根儿不知道这块，但是现在你知道了，面试被问到，你大概可以说一说。然后很多其他的候选人，也许还不如你，没看过这个，被问到了压根儿答不出来，相比之下，你还能说点出来，大概就是这个意思了。
7、kafka吞吐量高的原因。
8、kafka 主从同步怎么实现。
许多分布式的消息系统自动的处理失败的请求，它们对一个节点是否
着（alive）”有着清晰的定义。Kafka判断一个节点是否活着有两个条件：
节点必须可以维护和ZooKeeper的连接，Zookeeper通过心跳机制检查每个节点的连接。
如果节点是个follower,他必须能及时的同步leader的写操作，延时不能太久。
9、利用mq怎么实现最终一致性。
数据不一致可能原因:
1.消息丢失:参考下一题中 rabbitmq(消息丢失)、kafka(消息丢失)
2.消息顺序错乱:可以创建多个队列,有循序性的数据都放在一个队列里,让一个消费者来消费,但是还会有一种可能,就是这个消费者开启了多线程,仍然不能保证消息的顺序性,就需要消费者内部使用内存队列进行排队了,然后分发给底层不同的worker来处理
10、使用MQ有没有遇到什么问题，怎么解决的。
消息顺序错乱
可以创建多个队列,有循序性的数据都放在一个队列里,让一个消费者来消费,但是还会有一种可能,就是这个消费者开启了多线程,仍然不能保证消息的顺序性,就需要消费者内部使用内存队列进行排队了,然后分发给底层不同的worker来处理
rabbitmq(消息丢失)
1）生产者弄丢了数据
生产者将数据发送到rabbitmq的时候，可能数据就在半路给搞丢了，因为网络啥的问题，都有可能。
此时可以选择用rabbitmq提供的事务功能，就是生产者发送数据之前开启rabbitmq事务（channel.txSelect），然后发送消息，如果消息没有成功被rabbitmq接收到，那么生产者会收到异常报错，此时就可以回滚事务（channel.txRollback），然后重试发送消息；如果收到了消息，那么可以提交事务（channel.txCommit）。但是问题是，rabbitmq事务机制一搞，基本上吞吐量会下来，因为太耗性能。
所以一般来说，如果你要确保说写rabbitmq的消息别丢，可以开启confirm模式，在生产者那里设置开启confirm模式之后，你每次写的消息都会分配一个唯一的id，然后如果写入了rabbitmq中，rabbitmq会给你回传一个ack消息，告诉你说这个消息ok了。如果rabbitmq没能处理这个消息，会回调你一个nack接口，告诉你这个消息接收失败，你可以重试。而且你可以结合这个机制自己在内存里维护每个消息id的状态，如果超过一定时间还没接收到这个消息的回调，那么你可以重发。
事务机制和cnofirm机制最大的不同在于，事务机制是同步的，你提交一个事务之后会阻塞在那儿，但是confirm机制是异步的，你发送个消息之后就可以发送下一个消息，然后那个消息rabbitmq接收了之后会异步回调你一个接口通知你这个消息接收到了。
所以一般在生产者这块避免数据丢失，都是用confirm机制的。
2）rabbitmq弄丢了数据
就是rabbitmq自己弄丢了数据，这个你必须开启rabbitmq的持久化，就是消息写入之后会持久化到磁盘，哪怕是rabbitmq自己挂了，恢复之后会自动读取之前存储的数据，一般数据不会丢。除非极其罕见的是，rabbitmq还没持久化，自己就挂了，可能导致少量数据会丢失的，但是这个概率较小。
设置持久化有两个步骤，第一个是创建queue的时候将其设置为持久化的，这样就可以保证rabbitmq持久化queue的元数据，但是不会持久化queue里的数据；第二个是发送消息的时候将消息的deliveryMode设置为2，就是将消息设置为持久化的，此时rabbitmq就会将消息持久化到磁盘上去。必须要同时设置这两个持久化才行，rabbitmq哪怕是挂了，再次重启，也会从磁盘上重启恢复queue，恢复这个queue里的数据。
而且持久化可以跟生产者那边的confirm机制配合起来，只有消息被持久化到磁盘之后，才会通知生产者ack了，所以哪怕是在持久化到磁盘之前，rabbitmq挂了，数据丢了，生产者收不到ack，你也是可以自己重发的。
哪怕是你给rabbitmq开启了持久化机制，也有一种可能，就是这个消息写到了rabbitmq中，但是还没来得及持久化到磁盘上，结果不巧，此时rabbitmq挂了，就会导致内存里的一点点数据会丢失。
3）消费端弄丢了数据
rabbitmq如果丢失了数据，主要是因为你消费的时候，刚消费到，还没处理，结果进程挂了，比如重启了，那么就尴尬了，rabbitmq认为你都消费了，这数据就丢了。
这个时候得用rabbitmq提供的ack机制，简单来说，就是你关闭rabbitmq自动ack，可以通过一个api来调用就行，然后每次你自己代码里确保处理完的时候，再程序里ack一把。这样的话，如果你还没处理完，不就没有ack？那rabbitmq就认为你还没处理完，这个时候rabbitmq会把这个消费分配给别的consumer去处理，消息是不会丢的。
kafka(消息丢失)
1）消费端弄丢了数据
唯一可能导致消费者弄丢数据的情况，就是说，你那个消费到了这个消息，然后消费者那边自动提交了offset，让kafka以为你已经消费好了这个消息，其实你刚准备处理这个消息，你还没处理，你自己就挂了，此时这条消息就丢咯。
这不是一样么，大家都知道kafka会自动提交offset，那么只要关闭自动提交offset，在处理完之后自己手动提交offset，就可以保证数据不会丢。但是此时确实还是会重复消费，比如你刚处理完，还没提交offset，结果自己挂了，此时肯定会重复消费一次，自己保证幂等性就好了。
生产环境碰到的一个问题，就是说我们的kafka消费者消费到了数据之后是写到一个内存的queue里先缓冲一下，结果有的时候，你刚把消息写入内存queue，然后消费者会自动提交offset。
然后此时我们重启了系统，就会导致内存queue里还没来得及处理的数据就丢失了
2）kafka弄丢了数据
这块比较常见的一个场景，就是kafka某个broker宕机，然后重新选举partiton的leader时。大家想想，要是此时其他的follower刚好还有些数据没有同步，结果此时leader挂了，然后选举某个follower成leader之后，他不就少了一些数据？这就丢了一些数据啊。
生产环境也遇到过，我们也是，之前kafka的leader机器宕机了，将follower切换为leader之后，就会发现说这个数据就丢了
所以此时一般是要求起码设置如下4个参数：
给这个topic设置replication.factor参数：这个值必须大于1，要求每个partition必须有至少2个副本
在kafka服务端设置min.insync.replicas参数：这个值必须大于1，这个是要求一个leader至少感知到有至少一个follower还跟自己保持联系，没掉队，这样才能确保leader挂了还有一个follower吧
在producer端设置acks=all：这个是要求每条数据，必须是写入所有replica(副本/follower)之后，才能认为是写成功了
在producer端设置retries=MAX（很大很大很大的一个值，无限次重试的意思）：这个是要求一旦写入失败，就无限重试，卡在这里了
我们生产环境就是按照上述要求配置的，这样配置之后，至少在kafka broker端就可以保证在leader所在broker发生故障，进行leader切换时，数据不会丢失
3）生产者会不会弄丢数据
如果按照上述的思路设置了ack=all，一定不会丢，要求是，你的leader接收到消息，所有的follower都同步到了消息之后，才认为本次写成功了。如果没满足这个条件，生产者会自动不断的重试，重试无限次。
11、MQ有可能发生重复消费，如何避免，如何做到幂等。
（1）比如你拿个数据要写库，你先根据主键查一下，如果这数据都有了，你就别插入了，update一下好吧
（2）比如你是写redis，那没问题了，反正每次都是set，天然幂等性
（3）比如你不是上面两个场景，那做的稍微复杂一点，你需要让生产者发送每条数据的时候，里面加一个全局唯一的id，类似订单id之类的东西，然后你这里消费到了之后，先根据这个id去比如redis里查一下，之前消费过吗？如果没有消费过，你就处理，然后这个id写redis。如果消费过了，那你就别处理了，保证别重复处理相同的消息即可。
还有比如基于数据库的唯一键来保证重复数据不会重复插入多条，我们之前线上系统就有这个问题，就是拿到数据的时候，每次重启可能会有重复，因为kafka消费者还没来得及提交offset，重复数据拿到了以后我们插入的时候，因为有唯一键约束了，所以重复数据只会插入报错，不会导致数据库中出现脏数据
12、MQ的消息延迟了怎么处理，消息可以设置过期时间么，过期了你们一般怎么处理。
13、kafka的工作原理
多个broker组成，每个broker是一个节点；你创建一个topic，这个topic可以划分为多个partition，每个partition可以存在于不同的broker上，每个partition就放一部分数据。这就是天然的分布式消息队列，就是说一个topic的数据，是分散放在多个机器上的，每个机器就放一部分数据。kafka 0.8以前，是没有HA机制的，就是任何一个broker宕机了，那个broker上的partition就废了，没法写也没法读，没有什么高可用性可言。kafka 0.8以后，提供了HA机制，就是replica副本机制。每个partition的数据都会同步到吉他机器上，形成自己的多个replica副本。然后所有replica会选举一个leader出来，那么生产和消费都跟这个leader打交道，然后其他replica就是follower。写的时候，leader会负责把数据同步到所有follower上去，读的时候就直接读leader上数据即可。只能读写leader？很简单，要是你可以随意读写每个follower，那么就要care数据一致性的问题，系统复杂度太高，很容易出问题。kafka会均匀的将一个partition的所有replica分布在不同的机器上，这样才可以提高容错性。如果某个broker宕机了，没事儿，那个broker上面的partition在其他机器上都有副本的，如果这上面有某个partition的leader，那么此时会重新选举一个新的leader出来，大家继续读写那个新的leader即可。这就有所谓的高可用性了。
14、rabbitmq的工作原理
1）单机模式
就是demo级别的，一般就是你本地启动了玩玩儿的，没人生产用单机模式
2）普通集群模式
意思就是在多台机器上启动多个rabbitmq实例，每个机器启动一个。但是你创建的queue，只会放在一个rabbtimq实例上，但是每个实例都同步queue的元数据。完了你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从queue所在实例上拉取数据过来。
这种方式确实很麻烦，也不怎么好，没做到所谓的分布式，就是个普通集群。因为这导致你要么消费者每次随机连接一个实例然后拉取数据，要么固定连接那个queue所在实例消费数据，前者有数据拉取的开销，后者导致单实例性能瓶颈。
而且如果那个放queue的实例宕机了，会导致接下来其他实例就无法从那个实例拉取，如果你开启了消息持久化，让rabbitmq落地存储消息的话，消息不一定会丢，得等这个实例恢复了，然后才可以继续从这个queue拉取数据。
所以这个事儿就比较尴尬了，这就没有什么所谓的高可用性可言了，这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个queue的读写操作。
3）镜像集群模式
这种模式，才是所谓的rabbitmq的高可用模式，跟普通集群模式不一样的是，你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。
这样的话，好处在于，你任何一个机器宕机了，没事儿，别的机器都可以用。坏处在于，第一，这个性能开销也太大了吧，消息同步所有机器，导致网络带宽压力和消耗很重！第二，这么玩儿，就没有扩展性可言了，如果某个queue负载很重，你加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue
那么怎么开启这个镜像集群模式呢？我这里简单说一下，避免面试人家问你你不知道，其实很简单rabbitmq有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候可以要求数据同步到所有节点的，也可以要求就同步到指定数量的节点，然后你再次创建queue的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。
11、缓存
1.RDB：快照形式是直接把内存中的数据保存到一个 dump 文件中，定时保存，保存策略。
AOF：把所有的对Redis的服务器进行修改的命令都存到一个文件里，命令的集合。
redis哨兵机制
1.主要功能：
（1）集群监控，负责监控redis master和slave进程是否正常工作
（2）消息通知，如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员
（3）故障转移，如果master node挂掉了，会自动转移到slave node上,故障转移时，判断一个master node是宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题
（4）配置中心，如果故障转移发生了，通知client客户端新的master地址
注意：即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了
2.哨兵的核心知识：
（1）哨兵至少需要3个实例，来保证自己的健壮性
（2）哨兵 + redis主从的部署架构，是不会保证数据零丢失的，只能保证redis集群的高可用性
（3）对于哨兵 + redis主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练
3.为什么redis哨兵集群只有2个节点无法正常工作？
如果哨兵集群仅仅部署了个2个哨兵实例，quorum=1，master宕机，s1和s2中只要有1个哨兵认为master宕机就可以还行切换，同时s1和s2中会选举出一个哨兵来执行故障转移，同时这个时候，需要majority，也就是大多数哨兵都是运行的，2个哨兵的majority就是2（2的majority=2，3的majority=2，5的majority=3，4的majority=2），2个哨兵都运行着，就可以允许执行故障转移，但是如果整个M1和S1运行的机器宕机了，那么哨兵只有1个了，此时就没有majority来允许执行故障转移，虽然另外一台机器还有一个R1，但是故障转移不会执行
缓存为什么效率高/支持高并发
因为缓存是走内存的，内存天然就可以支撑高并发
redis丢失数据的情况，以及解决的方法
主备切换的过程，可能会导致数据丢失
（1）异步复制导致的数据丢失
【原因】：因为master -> slave的复制是异步的，所以可能有部分数据还没复制到slave，master就宕机了，此时这些部分数据就丢失了
【解决】：要求至少有1个slave，数据复制和同步的延迟不能超过10秒，如果说一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了，上面两个配置可以减少异步复制和脑裂导致的数据丢失，有了min-slaves-max-lag这个配置，就可以确保说，一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内
（2）脑裂导致的数据丢失
【原因】：脑裂，也就是说，某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着，此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master，这个时候，集群里就会有两个master，也就是所谓的脑裂，此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了，因此旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据
【解决】：如果一个master出现了脑裂，跟其他slave丢了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的slave发送数据，而且slave超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求，这样脑裂后的旧master就不会接受client的新数据，也就避免了数据丢失，上面的配置就确保了，如果跟任何一个slave丢了连接，在10秒后发现没有slave给自己ack，那么就拒绝新的写请求，因此在脑裂场景下，最多就丢失10秒的数据
我往redis里写的数据怎么没了？我的数据明明都过期了，怎么还占用着内存啊？
1、redis是缓存，不是存储。缓存就是用内存当缓存，内存是很宝贵而且有限的，磁盘是廉价而且是大量的。可能一台机器就几十个G的内存，但是可以有几个T的硬盘空间。redis主要是基于内存来进行高性能、高并发的读写操作的。那既然内存是有限的，比如redis就只能用10个G，你要是往里面写了20个G的数据，会咋办？当然会干掉10个G的数据，然后就保留10个G的数据了。那干掉哪些数据？保留哪些数据？当然是干掉不常用的数据，保留常用的数据了。第二种可能就是你写的数据太多，内存满了，或者触发了什么条件，redis LRU，自动给你清理掉了一些最近很少使用的数据
【LRU是Least Recently Used的缩写，即最近最少使用，是一种常用的页面置换算法，选择最近最久未使用的页面予以淘汰】
2、比如redis 内存一共是10g，你现在往里面写了5g的数据，结果这些数据明明你都设置了过期时间，要求这些数据1小时之后都会过期，结果1小时之后，你回来一看，redis机器，怎么内存占用还是50%呢？5g数据过期了，我从redis里查，是查不到了，结果过期的数据还占用着redis的内存。因为redis的删除机制是定期删除+惰性删除，就是说，你的过期key，靠定期删除没有被删除掉，还停留在内存里，占用着你的内存呢，除非你的系统去查一下那个key，才会被redis给删除掉。
定期删除：指的是redis默认是每隔100ms就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。假设redis里放了10万个key，都设置了过期时间，你每隔几百毫秒，就检查10万个key，那redis基本上就死了，cpu负载会很高的，消耗在你的检查过期key上了。注意，这里可不是每隔100ms就遍历所有的设置过期时间的key，那样就是一场性能上的灾难。实际上redis是每隔100ms随机抽取一些key来检查和删除的。
惰性删除：在你获取某个key的时候，redis会检查一下 ，这个key如果设置了过期时间那么是否过期了，如果过期了此时就会删除，不会给你返回任何东西。并不是key到时间就被删除掉，而是你查询这个key的时候，redis再懒惰的检查一下
3、即使定期删除和惰性删除配合使用，还是会有问题出现的，比如：如果定期删除漏掉了很多过期key，然后你也没及时去查，也就没走惰性删除，此时会怎么样？如果大量过期key堆积在内存里，导致redis内存块耗尽了，咋整？
走内存淘汰机制，有以下几个策略：
1）noeviction：当内存不足以容纳新写入数据时，新写入操作会报错，这个一般没人用吧，实在是太恶心了
2）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）
3）allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key，这个一般没人用吧，为啥要随机，肯定是把最近最少使用的key给干掉啊
4）volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key（这个一般不太合适）
5）volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key
6）volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除
1、常见的缓存策略有哪些，如何做到缓存(比如redis)与DB里的数据一致性，你们项目中用到了什么缓存系统，如何设计的。
1.由于不同系统的数据访问模式不同，同一种缓存策略很难在不同的数据访问模式下取得满意的性能，研究人员提出不同缓存策略以适应不同的需求。
缓存策略的分类：
1）、基于访问的时间：此类算法按各缓存项被访问时间来组织缓存队列，决定替换对象。如LRU
2）、基于访问频率：此类算法用缓存项的被访问频率来组织缓存。如LFU、LRU2、2Q、LIRS。
3）、访问时间与频率兼顾：通过兼顾访问时间和频率。使得数据模式在变化时缓存策略仍有较好性能。如FBR、LRUF、ALRFU。多数此类算法具有一个可调或自适应参数，通过该参数的调节使缓存策略在基于访问时间与频率间取得一个平衡。
4）、基于访问模式：某些应用有较明确的数据访问特点，进而产生与其相适应的缓存策略。如专用的VoD系统设计的A&L缓存策略，同时适应随机、顺序两种访问模式的SARC策略。
1.1、如何做到缓存(比如redis)与DB里的数据一致性
数据不一致性产生的原因：
【1】、先操作缓存，再写数据库成功之前，如果有读请求发生，可能导致旧数据入缓存，引发数据不一致。在分布式环境下，数据的读写都是并发的，一个服务多机器部署，对同一个数据进行读写，在数据库层面并不能保证完成顺序，就有可能后读的操作先完成（读取到的是脏数据），如果不采用给缓存设置过期时间策略，该数据永远都是脏数据。
【解决办法】：
1）、可采用更新前后双删除缓存策略。
2）、可以通过“串行化”解决，保证同一个数据的读写落在同一个后端服务上。
【2】、先操作数据库，再清除缓存。如果删缓存失败了，就会出现数据不一致问题。
【解决办法】：
1.方案一:将删除失败的key值存入队列中重复删除，如学习截图中 catch1.jpg：
（1）更新数据库数据。
（2）缓存因为种种问题删除失败。
（3）将需要删除的key发送至消息队列。
（4）自己消费消息，获得需要删除的key。
（5）继续重试删除操作，直到成功。
缺点：对业务线代码造成大量的侵入。于是有了方案二。
2.方案二：通过订阅binlog获取需要重新删除的Key值数据。在应用程序中，另起一段程序，获得这个订阅程序传来的消息，进行删除缓存操作。
如学习截图中 catch2.jpg：
（1）更新数据库数据
（2）数据库会将操作信息写入binlog日志当中
（3）订阅程序提取出所需要的数据以及key
（4）另起一段非业务代码，获得该信息
（5）尝试删除缓存操作，发现删除失败
（6）将这些信息发送至消息队列
（7）重新从消息队列中获得该数据，重试操作。
2、如何防止缓存击穿和雪崩。
【1】、缓存穿透：缓存穿透是说收到一个请求，但是该请求缓存中不存在，只能去数据库中查询，然后放进缓存。但当有好多请求同时访问同一个数据时，业务系统把这些请求全发到了数据库；或者恶意构造一个逻辑上不存在的数据，然后大量发送这个请求，这样每次都会被发送到数据库，最总导致数据库挂掉。
解决的办法：对于恶意访问，一种思路是先做校验，对恶意数据直接过滤掉，不要发送至数据库层；第二种思路是缓存空结果，就是对查询不存在的数据也记录在缓存中，这样就可以有效的减少查询数据库的次数。非恶意访问，结合缓存击穿说明。
【2】、缓存击穿：上面提到的某个数据没有，然后好多请求查询数据库，可以归为缓存击穿的范畴：对于热点数据，当缓存失效的一瞬间，所有的请求都被下放到数据库去请求更新缓存，数据库被压垮。
解决的办法：防范此类问题，一种思路是加全局锁，就是所有访问某个数据的请求都共享一个锁，获得锁的那个才有资格去访问数据库，其他线程必须等待。但现在大部分系统都是分布式的，本地锁无法控制其他服务器也等待，所以要用到全局锁，比如Redis的setnx实现全局锁。另一种思想是对即将过期的数据进行主动刷新，比如新起一个线程轮询数据，或者比如把所有的数据划分为不同的缓存区间，定期分区间刷新数据。第二个思路与缓存雪崩有点关系。
【3】、缓存雪崩：缓存雪崩是指当我们给所有的缓存设置了同样的过期时间，当某一时刻，整个缓存的数据全部过期了，然后瞬间所有的请求都被抛向了数据库，数据库就崩掉了。
解决的办法：解决思路要么是分治，划分更小的缓存区间，按区间过期；要么给每个key的过期时间加一个随机值，避免同时过期，达到错峰刷新缓存的目的。
【4】、缓存刷新：既清空缓存 ，一般在insert、update、delete操作后就需要刷新缓存，如果不执行就会出现脏数据。但当缓存请求的系统蹦掉后，返回给缓存的值为null。
3、缓存数据过期后的更新如何设计。
除了缓存服务器自带的缓存失效策略之外（Redis默认的有6中策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种：
（1）定时去清理过期的缓存；
（2）当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。
两者比较的优缺点:
性能上第二种优越于第一种,定时更新的话,在没有进行读写操作的时候,也回去定时更新,对系统资源也是一种浪费,第二种,当缓存过期后,第一个客户请求数据的时候才会去更新,这样查询出数据直接返回给客户,并且顺带着放进缓存里,提高了性能
两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，大家可以根据自己的应用场景来权衡。
4、redis的list结构相关的操作。
【1】、PUSH操作：是从队列头部和尾部增加节点的操作。
①、RPUSH KEY VALUE [VALUE …] ：从队列的右端入队一个或者多个数据，如果key值不存在，会自动创建一个空的列表。如果对应的key不是一个List，则会返回一个错误。
②、LPUSH KEY VALUE [VALUE…] ：从队列的左边入队一个或多个元素。复杂度O(1)。
③、RPUSHX KEY VALUE：从队列的右边入队一个元素，仅队列存在时有效，当队列不存在时，不进行任何操作。
④、LPUSHX KEY VALUE：从队列的左边入队一个元素，仅队列存在时有效。当队列不存在时，不进行任何操作。
【2】、POP操作：获取并删除头尾节点的操作。
①、LPOP KEY：从队列左边出队一个元素，复杂度O(1)。如果list为空，则返回nil。
②、RPOP KEY：从队列的右边出队一个元素，复杂度O(1)。如果list为空，则返回nil。
③、BLPOP KEY[KEY…] TIMEOUT：删除&获取KEY中最左边的第一个元素，当队列为空时，阻塞TIMEOUT时间，单位是秒（这个时间内尝试获取KEY中的数据），超过TIMEOUT后如果仍未数据则返回(nil)。
1 redis> BLPOP queue 1
2 (nil)
3 (1.10s)
④、BRPOP KEY[KEY...] TIMEOUT：删除&获取KEY中最后一个元素，或阻塞TIMEOUT。如上↑
【3】、POP and PUSH
①、RPOPLPUSH KEY1 KEY2：删除KEY1中最后一个元素，将其追加到KEY2的最左端。
②、BRPOPLPUSH KEY1 KEY2 TIMEOUT：弹出KEY1列表的值，将它推到KEY2列表，并返回它;或阻塞TIMEOUT时间，直到有一个可用。
【4】、其他
①、LLEN KEY：获取队列（List）的长度。
②、LRANG KEY START STOP：从列表中获取指定（START-STOP）长度的元素。负数表示从右向左数。需要注意的是，超出范围的下标不会产生错误：如果start>end，会得到空列表，如果end超过队尾，则Redis会将其当做列表的最后一个元素。
1 redis> rpush q1 a b c d f e g
2 (integer) 7
3 redis> lrange q1 0 -1
4 1) "a"
5 2) "b"
6 3) "c"
7 4) "d"
8 5) "f"
9 6) "e"
10 7) "g"
③、 LINDEX KEY INDEX：获取一个元素，通过其索引列表。我们之前介绍的操作都是对list的两端进行的，所以算法复杂度都只有O(1)。而这个操作是指定位置来进行的，每次操作，list都得找到对应的位置，因此算法复杂度为O(N)。list的下表是从0开始的，index为负的时候是从右向左数。-1表示最后一个元素。当下标超出的时候，会返回nul。所以不用像操作数组一样担心范围越界的情况。
④、LSET KEY INDEX：重置队列中INDEX位置的值。当index越界的时候，这里会报异常。
⑤、LREM KEY COUNT VALUE：从列表中删除COUNT个VALUE元素。COUNT参数有三种情况：
☛ count > 0: 表示从头向尾（左到右）移除值为value的元素。
☛ count < 0: 表示从尾向头（右向左）移除值为value的元素。
☛ count = 0: 表示移除所有值为value的元素。
⑥、LTRIM KEY START STOP：修剪到指定范围内的清单，相当与截取，只保留START-STOP之间的数据。
1 redis> rpush q a b c d e f g
2 (integer) 7
3 redis> lrange q 0 -1
4 1) "a"
5 2) "b"
6 3) "c"
7 4) "d"
8 5) "e"
9 6) "f"
10 7) "g"
11 redis> ltrim q 1 4
12 OK
13 redis> lrange q 0 -1
14 1) "b"
15 2) "c"
16 3) "d"
17 4) "e"
⑦、LINSERT KEY BEFORE|AFTER 元素 VALUE：在列表中的另一个元素之前或之后插入VAULE。当key不存在时，这个List被视为空列表，任何操作都不会发生。当key存在，但保存的不是List，则会报error。该命令会返回修改之后的List的长度，如果找不到元素，则会返回-1。
5、Redis的数据结构都有哪些。
1】、String：可以是字符串，整数或者浮点数，对整个字符串或者字符串中的一部分执行操作，对整个整数或者浮点执行自增(increment)或者自减(decrement)操作。
2】、List：一个链表，链表上的每个节点都包含了一个字符串，链表的两端推入或者弹出元素，根据偏移量对链表进行修剪(trim)，读取单个或者多个元素，根据值查找或者移除元素。可参考5
3】、Set：包含字符串的无序收集器(unordered collection)、并且被包含的每个字符串都是独一无二的。添加，获取，移除单个元素，检查一个元素是否存在于集合中，计算交集（sinter），并集（suion），差集（sdiff），从集合里面随机获取元素。
4】、SortSet：是一个排好序的Set，它在Set的基础上增加了一个顺序属性score，这个属性在添加修改元素时可以指定，每次指定后，SortSet会自动重新按新的值排序。sorted set的内部使用HashMap和跳跃表(SkipList)来保证数据的存储和有序，HashMap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是HashMap里存的score。
192.168.2.129:6379> zadd myzset 1 "one" 2 "two" 3 "three" //添加元素
(integer) 3
192.168.2.129:6379> zrange myzset 0 -1
1) "one"
2) "two"
3) "three"
192.168.2.129:6379> zrange myzset 0 -1 withscores
1) "one"
2) "1"
3) "two"
4) "2"
5) "three"
6) "3"
192.168.2.129:6379> zrem myzset one //删除元素
(integer) 1
192.168.2.129:6379> zrange myzset 0 -1 withscores
1) "two"
2) "2"
3) "three"
4) "3"
192.168.2.129:6379>
5】、hash：Hash是一个String类型的field和value之间的映射表，即redis的Hash数据类型的key（hash表名称）对应的value实际的内部存储结构为一个HashMap，因此Hash特别适合存储对象。相对于把一个对象的每个属性存储为String类型，将整个对象存储在Hash类型中会占用更少内存。
192.168.2.129:6379> hset myhash name zhangsan
(integer) 1
192.168.2.129:6379> hset myhash age 20
(integer) 1
192.168.2.129:6379> hget myhash name
"zhangsan"
192.168.2.129:6379> hget myhash age
"20"
192.168.2.129:6379>
6、Redis的使用要注意什么，讲讲持久化方式，内存设置，集群的应用和优劣势，淘汰策略等。
使用阶段我们从数据存储和数据获取两个方面来说明开发时的注意事项：
1）、数据存储：因为内存空间的局限性，注定了能存储的数据量有限，如何在有限的空间内存储更多的数据信息是我们应该关注的。Redis内存储的都是键值对，那么如何减小键值对所占据的内存空间就是空间优化的本质。在能清晰表达业务含义的基础上尽可能缩减Key的字符长度，比如一个键是user:{id}:logintime ，可以使用业务属性的简写来u:{id}:lgt,只要能清晰表达业务意义，使用简写形式是有其必要性的。在不影响使用的情况下，缩减Value的数据大小。如果Value是较大的数据信息，比如图片，大文本等，可以使用压缩工具压缩过后再存入Redis；如果Value是对象序列化或者gson信息，可以考虑去除非必要的业务属性。
减少键值对的数量，对于大量的String类型的小对象，可以尝试使用Hash的形式组合他们，在Hash对象内Field数量少于1000，且Value的字符长度小于40时，内部使用ziplist的编码形式，能够极大的降低小对象占据的内存空间。
Redis内维护了一个[0-9999]的整数对象池，类似Java内的运行时常量池，只创建一个常量，使用时都去引用这个常量，所以当存储的value是这个范围内的数字时均是引用向都一个内存地址，所以能够降低一些内存空间耗费。但是共享对象池和maxmemory+LRU的内存回收策略冲突，因为共享Value对象的lru值也共享，难以通过lru知道哪个Key的最后引用时间，所以永远也不能回收内存。如果多次数据操作要求原子性，可使用Multi来实现Redis的事务。
2）、数据查询：Redis是一种数据库，和其他数据库一样，操作时也需要有连接对象，连接对象的创建和销毁也需要耗费资源，复用连接对象很有必要，所以推荐使用连接池来管理连接。Redis数据存储在内存中，查询很快，但不代表连接也很快。一次Redis查询可能IO部分占据了请求时间的绝大部分比例，缩短IO时间是开发过程中很需要注意的一点。对于一个业务内的多次查询，考虑使用Pipeline，将多次查询合并为一次查询，命令会被执行多次，但是只有一个IO传输，能够有效的提高响应速度。
对于多次String类型的查询，使用mget，将多次请求合并为一次，同时命令和会被合并为一次，能有效提高响应速度，对于Hash内多个Field查询，使用hmget，起到和mget同样的效果。Redis是单线程执行的，也就是说同一时间只能执行一条命令，如果一条命令执行的时间较长，其他线程在此期间均会被阻塞，所以在操作Redis时要注意操作指令的涉及的数据量，尽量降低单次操作的执行时间。
持久化方式：RDB时间点快照 AOF记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。可参考14深度解析
内存设置：maxmemory used_memory
虚拟内存： vm-enabled yes
集群的应用和优劣势参考9
淘汰策略，有以下几个策略：
1）noeviction：当内存不足以容纳新写入数据时，新写入操作会报错，这个一般没人用吧，实在是太恶心了
2）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）
3）allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key，这个一般没人用吧，为啥要随机，肯定是把最近最少使用的key给干掉啊
4）volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key（这个一般不太合适）
5）volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key
6）volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除
内存优化：http://www.infoq.com/cn/articles/tq-redis-memory-usage-optimization-storage
7、redis2和redis3的区别，redis3内部通讯机制。
集群方式的区别：Redis3采用Cluster，Redis2采用客户端分区方案和代理方案
通信过程说明：
1） 集群中的每个节点都会单独开辟一个TCP通道， 用于节点之间彼此通信， 通信端口号在基础端口上加10000。
2） 每个节点在固定周期内通过特定规则选择几个节点发送ping消息。
3） 接收到ping消息的节点用pong消息作为响应。
8、当前redis集群有哪些玩法，各自优缺点，场景。
1）、数据共享：Redis提供多个节点实例间的数据共享，也就是Redis A,B,C,D彼此之间的数据是同步的，同样彼此之间也可以通信，而对于客户端操作的keys是由Redis系统自行分配到各个节点中。
2）、主从复制：Redis的多个实例间通信时，一旦其中的一个节点故障，那么Redis集群就不能继续正常工作，所以需要一种复制机制（Master-Slave）机制，做到一旦节点A故障了，那么其从节点A1和A2就可以接管并继续提供与A同样的工作服务，当然如果节点A,A1,A2节点都出现问题，那么同样这个集群不会继续保持工作，但是这种情况比较罕见，即使出现了，也会及时发现并修复使用。建议：部署主从复制机制（Master-Slave）。
3）、哈希槽值：Redis集群中使用哈希槽来存储客户端的keys，而在Redis中，目前存在16384个哈希槽，它们被全部分配给所有的节点，正如上图所示，所有的哈希槽值被节点A，B，C分配完成了。
参考：https://www.cnblogs.com/RENQIWEI1995/p/8931678.html
9、Memcache的原理，哪些数据适合放在缓存中。
首先要说明一点，MemCache的数据存放在内存中，存放在内存中个人认为意味着几点：
1）、访问数据的速度比传统的关系型数据库要快，因为Oracle、MySQL这些传统的关系型数据库为了保持数据的持久性，数据存放在硬盘中，IO操作速度慢
2）、MemCache的数据存放在内存中同时意味着只要MemCache重启了，数据就会消失
3）、既然MemCache的数据存放在内存中，那么势必受到机器位数的限制，这个之前的文章写过很多次了，32位机器最多只能使用2GB的内存空间，64位机器可以认为没有上限。
然后我们来看一下MemCache的原理，MemCache最重要的莫不是内存分配的内容了，MemCache采用的内存分配方式是固定空间分配，还是自己画一张图说明：
这张图片里面涉及了slab_class、slab、page、chunk四个概念，它们之间的关系是：
【1】、MemCache将内存空间分为一组slab
【2】、每个slab下又有若干个page，每个page默认是1M，如果一个slab占用100M内存的话，那么这个slab下应该有100个page
【3】、每个page里面包含一组chunk，chunk是真正存放数据的地方，同一个slab里面的chunk的大小是固定的
【4】、有相同大小chunk的slab被组织在一起，称为slab_class
MemCache内存分配的方式称为allocator，slab的数量是有限的，几个、十几个或者几十个，这个和启动参数的配置相关。
MemCache中的value过来存放的地方是由value的大小决定的，value总是会被存放到与chunk大小最接近的一个slab中，比如slab[1]的chunk大小为80字节、slab[2]的chunk大小为100字节、slab[3]的chunk大小为128字节（相邻slab内的chunk基本以1.25为比例进行增长，MemCache启动时可以用-f指定这个比例），那么过来一个88字节的value，这个value将被放到2号slab中。放slab的时候，首先slab要申请内存，申请内存是以page为单位的，所以在放入第一个数据的时候，无论大小为多少，都会有1M大小的page被分配给该slab。申请到page后，slab会将这个page的内存按chunk的大小进行切分，这样就变成了一个chunk数组，最后从这个chunk数组中选择一个用于存储数据。
如果这个slab中没有chunk可以分配了怎么办，如果MemCache启动没有追加-M（禁止LRU，这种情况下内存不够会报Out Of Memory错误），那么MemCache会把这个slab中最近最少使用的chunk中的数据清理掉，然后放上最新的数据。针对MemCache的内存分配及回收算法，总结三点：
【1】、MemCache的内存分配chunk里面会有内存浪费，88字节的value分配在128字节（紧接着大的用）的chunk中，就损失了30字节，但是这也避免了管理内存碎片的问题
【2】、MemCache的LRU算法不是针对全局的，是针对slab的
【3】、应该可以理解为什么MemCache存放的value大小是限制的，因为一个新数据过来，slab会先以page为单位申请一块内存，申请的内存最多就只有1M，所以value大小自然不能大于1M了。
再总结MemCache的特性和限制：
¤上面已经对于MemCache做了一个比较详细的解读，这里再次总结MemCache的限制和特性：
1】、MemCache中可以保存的item数据量是没有限制的，只要内存足够
2】、MemCache单进程在32位机中最大使用内存为2G，这个之前的文章提了多次了，64位机则没有限制
3】、Key最大为250个字节，超过该长度无法存储
4】、单个item最大数据是1MB，超过1MB的数据不予存储
5】、MemCache服务端是不安全的，比如已知某个MemCache节点，可以直接telnet过去，并通过flush_all让已经存在的键值对立即失效
6】、不能够遍历MemCache中所有的item，因为这个操作的速度相对缓慢且会阻塞其他的操作
7】、MemCache的高性能源自于两阶段哈希结构：第一阶段在客户端，通过Hash算法根据Key值算出一个节点；第二阶段在服务端，通过一个内部的Hash算法，查找真正的item并返回给客户端。从实现的角度看，MemCache是一个非阻塞的、基于事件的服务器程序
8】、MemCache设置添加某一个Key值的时候，传入expiry为0表示这个Key值永久有效，这个Key值也会在30天之后失效。
MemCache适合存储：变化频繁，具有不稳定性的数据,不需要实时入库, (比如用户在线状态、在线人数…)门户网站的新闻等，觉得页面静态化仍不能满足要求，可以放入到memcache中.(配合jquey的ajax请求)。
10、redis和memcached 的内存管理的区别。
应该说Memcached和Redis都能很好的满足解决我们的问题，它们性能都很高，总的来说，可以把Redis理解为是对Memcached的拓展，是更加重量级的实现，提供了更多更强大的功能。具体来说：
1.性能上：
性能上都很出色，具体到细节，由于Redis只使用单核，而Memcached可以使用多核，所以平均每一个核上Redis在存储小数据时比
Memcached性能更高。而在100k以上的数据中，Memcached性能要高于Redis，虽然Redis最近也在存储大数据的性能上进行优化，但是比起 Memcached，还是稍有逊色。
2.内存空间和数据量大小：
MemCached可以修改最大内存，采用LRU算法。Redis增加了VM的特性，突破了物理内存的限制。
3.操作便利上：
MemCached数据结构单一，仅用来缓存数据，而Redis支持更加丰富的数据类型，也可以在服务器端直接对数据进行丰富的操作,这样可以减少网络IO次数和数据体积。
4.可靠性上：
MemCached不支持数据持久化，断电或重启后数据消失，但其稳定性是有保证的。Redis支持数据持久化和数据恢复，允许单点故障，但是同时也会付出性能的代价。
5.应用场景：
Memcached：动态系统中减轻数据库负载，提升性能；做缓存，适合多读少写，大数据量的情况（如人人网大量查询用户信息、好友信息、文章信息等）。
Redis：适用于对读写效率要求都很高，数据处理业务复杂和对安全性要求较高的系统（如新浪微博的计数和微博发布部分系统，对数据安全性、读写要求都很高）。
需要慎重考虑的部分
1.Memcached单个key-value大小有限，一个value最大只支持1MB，而Redis最大支持512MB
2.Memcached只是个内存缓存，对可靠性无要求；而Redis更倾向于内存数据库，因此对对可靠性方面要求比较高
3.从本质上讲，Memcached只是一个单一key-value内存Cache；而Redis则是一个数据结构内存数据库，支持五种数据类型，因此Redis除单纯缓存作用外，还可以处理一些简单的逻辑运算，Redis不仅可以缓存，而且还可以作为数据库用
4.新版本（3.0）的Redis是指集群分布式，也就是说集群本身均衡客户端请求，各个节点可以交流，可拓展行、可维护性更强大。
11、Redis的并发竞争问题如何解决，了解Redis事务的CAS操作吗。
Redis为单进程单线程模式，采用队列模式将并发访问变为串行访问。Redis本身没有锁的概念，Redis对于多个客户端连接并不存在竞争，但是在Jedis客户端对Redis进行并发访问时会发生连接超时、数据转换错误、阻塞、客户端关闭连接等问题，这些问题均是由于客户端连接混乱造成。对此有2种解决方法：
【1】客户端角度，为保证每个客户端间正常有序与Redis进行通信，对连接进行池化，同时对客户端读写Redis操作采用内部锁synchronized。
【2】服务器角度，利用setnx实现锁。MULTI，EXEC，DISCARD，WATCH 四个命令是 Redis 事务的四个基础命令。其中：
☆ MULTI，告诉 Redis 服务器开启一个事务。注意，只是开启，而不是执行
☆ EXEC，告诉 Redis 开始执行事务
☆ DISCARD，告诉 Redis 取消事务
☆ WATCH，监视某一个键值对，它的作用是在事务执行之前如果监视的键值被修改，事务会被取消。
*事务以及CAS操作
和众多其它数据库一样，Redis作为NoSQL数据库也同样提供了事务机制。在Redis中，MULTI/EXEC/DISCARD/WATCH这四个命令是我们实现事务的基石。相信对有关系型数据库开发经验的开发者而言这一概念并不陌生，即便如此，我们还是会简要的列出
Redis中
事务的实现特征：
1). 在事务中的所有命令都将会被串行化的顺序执行，事务执行期间，Redis不会再为其它客户端的请求提供任何服务，从而保证了事物中的所有命令被原子的执行。
2). 和关系型数据库中的事务相比，在Redis事务中如果有某一条命令执行失败，其后的命令仍然会被继续执行。
3). 我们可以通过MULTI命令开启一个事务，有关系型数据库开发经验的人可以将其理解为"BEGIN TRANSACTION"语句。在该语句之后执行的命令都将被视为事务之内的操作，最后我们可以通过执行EXEC/DISCARD命令来提交/回滚该事务内的所有操作。这两个Redis命令可被视为等同于关系型数据库中的COMMIT/ROLLBACK语句。
4). 在事务开启之前，如果客户端与服务器之间出现通讯故障并导致网络断开，其后所有待执行的语句都将不会被服务器执行。然而如果网络中断事件是发生在客户端执行EXEC命令之后，那么该事务中的所有命令都会被服务器执行。
5). 当使用Append-Only模式时，Redis会通过调用系统函数write将该事务内的所有写操作在本次调用中全部写入磁盘。然而如果在写入的过程中出现系统崩溃，如电源故障导致的宕机，那么此时也许只有部分数据被写入到磁盘，而另外一部分数据却已经丢失。
Redis服务器会在重新启动时执行一系列必要的一致性检测，一旦发现类似问题，就会立即退出并给出相应的错误提示。此时，我们就要充分利用Redis工具包中提供的redis-check-aof工具，该工具可以帮助我们定位到数据不一致的错误，并将已经写入的部
分数据进行回滚。修复之后我们就可以再次重新启动Redis服务器了。
12、Redis的选举算法和流程是怎样的。
Raft采用心跳机制触发Leader选举。系统启动后，全部节点初始化为Follower，term为0.节点如果收到了RequestVote或者AppendEntries，就会保持自己的Follower身份。如果一段时间内没收到AppendEntries消息直到选举超时，说明在该节点的超时时间内还没发现Leader，Follower就会转换成Candidate，自己开始竞选Leader。一旦转化为Candidate，该节点立即开始下面几件事情：
1）、增加自己的term。
2）、启动一个新的定时器。
3）、给自己投一票。
4）、向所有其他节点发送RequestVote，并等待其他节点的回复。
✔如果在这过程中收到了其他节点发送的AppendEntries，就说明已经有Leader产生，自己就转换成Follower，选举结束。
✔如果在计时器超时前，节点收到多数节点的同意投票，就转换成Leader。同时向所有其他节点发送AppendEntries，告知自己成为了Leader。
✔每个节点在一个term内只能投一票，采取先到先得的策略，Candidate前面说到已经投给了自己，Follower会投给第一个收到RequestVote的节点。每个Follower有一个计时器，在计时器超时时仍然没有接受到来自Leader的心跳RPC, 则自己转换为Candidate, 开始请求投票，就是上面的的竞选Leader步骤。
✔如果多个Candidate发起投票，每个Candidate都没拿到多数的投票（Split Vote），那么就会等到计时器超时后重新成为Candidate，重复前面竞选Leader步骤。
✔Raft协议的定时器采取随机超时时间，这是选举Leader的关键。每个节点定时器的超时时间随机设置，随机选取配置时间的1倍到2倍之间。由于随机配置，所以各个Follower同时转成Candidate的时间一般不一样，在同一个term内，先转为Candidate的节点会先发起投票，从而获得多数票。多个节点同时转换为Candidate的可能性很小。即使几个Candidate同时发起投票，在该term内有几个节点获得一样高的票数，只是这个term无法选出Leader。由于各个节点定时器的超时时间随机生成，那么最先进入下一个term的节点，将更有机会成为Leader。连续多次发生在一个term内节点获得一样高票数在理论上几率很小，实际上可以认为完全不可能发生。一般1-2个term类，Leader就会被选出来。
Sentinel的选举流程：
Sentinel集群正常运行的时候每个节点epoch相同，当需要故障转移的时候会在集群中选出Leader执行故障转移操作。Sentinel采用了Raft协议实现了Sentinel间选举Leader的算法，不过也不完全跟论文描述的步骤一致。Sentinel集群运行过程中故障转移完成，所有Sentinel又会恢复平等。Leader仅仅是故障转移操作出现的角色。
选举流程：
1）、某个Sentinel认定master客观下线的节点后，该Sentinel会先看看自己有没有投过票，如果自己已经投过票给其他Sentinel了，在2倍故障转移的超时时间自己就不会成为Leader。相当于它是一个Follower。
2）、如果该Sentinel还没投过票，那么它就成为Candidate。
3）、和Raft协议描述的一样，成为Candidate，Sentinel需要完成几件事情
【1】更新故障转移状态为start
【2】当前epoch加1，相当于进入一个新term，在Sentinel中epoch就是Raft协议中的term。
【3】更新自己的超时时间为当前时间随机加上一段时间，随机时间为1s内的随机毫秒数。
【4】向其他节点发送is-master-down-by-addr命令请求投票。命令会带上自己的epoch。
【5】给自己投一票，在Sentinel中，投票的方式是把自己master结构体里的leader和leader_epoch改成投给的Sentinel和它的epoch。
4）、其他Sentinel会收到Candidate的is-master-down-by-addr命令。如果Sentinel当前epoch和Candidate传给他的epoch一样，说明他已经把自己master结构体里的leader和leader_epoch改成其他Candidate，相当于把票投给了其他Candidate。投过票给别的Sentinel后，在当前epoch内自己就只能成为Follower。
5）、Candidate会不断的统计自己的票数，直到他发现认同他成为Leader的票数超过一半而且超过它配置的quorum（quorum可以参考《redis sentinel设计与实现》）。Sentinel比Raft协议增加了quorum，这样一个Sentinel能否当选Leader还取决于它配置的quorum。
6）、如果在一个选举时间内，Candidate没有获得超过一半且超过它配置的quorum的票数，自己的这次选举就失败了。
7）、如果在一个epoch内，没有一个Candidate获得更多的票数。那么等待超过2倍故障转移的超时时间后，Candidate增加epoch重新投票。
8）、如果某个Candidate获得超过一半且超过它配置的quorum的票数，那么它就成为了Leader。
9）、与Raft协议不同，Leader并不会把自己成为Leader的消息发给其他Sentinel。其他Sentinel等待Leader从slave选出master后，检测到新的master正常工作后，就会去掉客观下线的标识，从而不需要进入故障转移流程。
13、redis的持久化的机制，aof和rdb的区别。
Redis的持久化机制：Redis提供两种方式进行持久化，一种是RDB持久化（原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化），另外一种是AOF（append only file）持久化（原理是将Reids的操作日志以追加的方式写入文件）。
AOF和RDB的区别：RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。
AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。
二者优缺点：RDB存在哪些优势：
1）、一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。
2）、对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。
3）、性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
4）、相比于AOF机制，如果数据集很大，RDB的启动效率会更高。
RDB又存在哪些劣势：
1）、如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
2）、由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。
AOF的优势有哪些：
1）、该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。
2）、由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
3）、如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
4）、AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。
AOF的劣势有哪些：
1）、对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
2）、根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。
二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。rdb这个就更有些 eventually consistent的意思了。
14、redis的集群怎么同步的数据的。主从架构的核心原理
主从复制：
1、redis的复制功能是支持多个数据库之间的数据同步。一类是主数据库（master）一类是从数据库（slave），主数据库可以进行读写操作，当发生写操作的时候自动将数据同步到从数据库，而从数据库一般是只读的，并接收主数据库同步过来的数据，一个主数据库可以有多个从数据库，而一个从数据库只能有一个主数据库。
2、通过redis的复制功能可以很好的实现数据库的读写分离，提高服务器的负载能力。主数据库主要进行写操作，而从数据库负责读操作。
1：当一个从数据库启动时，会向主数据库发送sync命令，
2：主数据库接收到sync命令后会开始在后台保存快照（执行rdb操作），并将保存期间接收到的命令缓存起来
3：当快照完成后，redis会将快照文件和所有缓存的命令发送给从数据库。
4：从数据库收到后，会载入快照文件并执行收到的缓存的命令。
主从架构的核心原理
1）、当启动一个slave node的时候，它会发送一个PSYNC命令给master node
2）、如果这是slave node重新连接master node，那么master node仅仅会复制给slave部分缺少的数据; 如果是slave node第一次连接master node，那么会触发一次full resynchronization（全量复制）
3）、开始full resynchronization的时候，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令缓存在内存中。RDB文件生成完毕之后，master会将这个RDB发送给slave，slave会先写入本 地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中缓存的写命令发送给slave，slave也会同步这些数据。
4）、slave node如果跟master node有网络故障，断开了连接，会自动重连。master如果发现有多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node。
15、知道哪些redis的优化操作。
1、尽量使用短的key
当然在精简的同时，不要为了key的“见名知意”。对于value有些也可精简，比如性别使用0、1。
2、避免使用keys *
keys *, 这个命令是阻塞的，即操作执行期间，其它任何命令在你的实例中都无法执行。当redis中key数据量小时到无所谓，数据量大就很糟糕了。所以我们应该避免去使用这个命令。可以去使用SCAN,来代替。
3、在存到Redis之前先把你的数据压缩下
redis为每种数据类型都提供了两种内部编码方式，在不同的情况下redis会自动调整合适的编码方式。
4、设置key有效期
我们应该尽可能的利用key有效期。比如一些临时数据（短信校验码），过了有效期Redis就会自动为你清除！
5、选择回收策略(maxmemory-policy)
当Redis的实例空间被填满了之后，将会尝试回收一部分key。根据你的使用方式，强烈建议使用 volatile-lru（默认） 策略——前提是你对key已经设置了超时。但如果你运行的是一些类似于 cache 的东西，并且没有对 key 设置超时机制，可以考虑使用 allkeys-lru 回收机制，具体讲解查看 。maxmemory-samples 3 是说每次进行淘汰的时候 会随机抽取3个key 从里面淘汰最不经常使用的（默认选项）。
maxmemory-policy 六种方式 :
volatile-lru：只对设置了过期时间的key进行LRU（默认值）
allkeys-lru ： 是从所有key里 删除 不经常使用的key
volatile-random：随机删除即将过期key
allkeys-random：随机删除
volatile-ttl ： 删除即将过期的
noeviction ： 永不过期，返回错误
6、使用bit位级别操作和byte字节级别操作来减少不必要的内存使用
bit位级别操作：GETRANGE, SETRANGE, GETBIT and SETBITbyte字节级别操作：GETRANGE and SETRANGE
7、尽可能地使用hashes哈希存储
8、当业务场景不需要数据持久化时，关闭所有的持久化方式可以获得最佳的性能
数据持久化时需要在持久化和延迟/性能之间做相应的权衡.
9、想要一次添加多条数据的时候可以使用管道
10、限制redis的内存大小（64位系统不限制内存，32位系统默认最多使用3GB内存）
数据量不可预估，并且内存也有限的话，尽量限制下redis使用的内存大小，这样可以避免redis使用swap分区或者出现OOM错误。（使用swap分区，性能较低，如果限制了内存，当到达指定内存之后就不能添加数据了，否则会报OOM错误。可以设置maxmemory-policy，内存不足时删除数据）
11、SLOWLOG [get/reset/len]
slowlog-log-slower-than 它决定要对执行时间大于多少微秒(microsecond，1秒 = 1,000,000 微秒)的命令进行记录。slowlog-max-len 它决定 slowlog 最多能保存多少条日志，当发现redis性能下降的时候可以查看下是哪些命令导致的。
12、系统内存OOM优化
vm.overcommit_memory
Redis会占用非常大内存，所以通常需要关闭系统的OOM，方法为将“/proc/sys/vm/overcommit_memory”的值设置为1（通常不建议设置为2）也可以使用命令sysctl设置，如：sysctl vm.overcommit_memory=1，但注意一定要同时修改文件/etc/sysctl.conf，执行“sysctl -p”，以便得系统重启后仍然生效。
可选值：0、1、2。
0： 表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。
1： 表示内核允许分配所有的物理内存，而不管当前的内存状态如何。
2： 表示内核允许分配超过所有物理内存和交换空间总和的内存
cat /proc/sys/vm/overcommit_memory
0
echo vm.overcommit_memory = 1 >> /etc/sysctl.conf
sysctl -p
16、Reids的主从复制机制原理。
1.当启动一个slave node的时候，它会发送一个PSYNC命令给master node
2.如果这是slave node重新连接master node，那么master node仅仅会复制给slave部分缺少的数据; 否则如果是slave node第一次连接master node，那么会触发一次full resynchronization
3.开始full resynchronization的时候，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令缓存在内存中。RDB文件生成完毕之后，master会将这个RDB发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中缓存的写命令发送给slave，slave也会同步这些数据。
4.slave node如果跟master node有网络故障，断开了连接，会自动重连。master如果发现有多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node。
全量复制
概念：
（1）master执行bgsave，在本地生成一份rdb快照文件
（2）master node将rdb快照文件发送给salve node，如果rdb复制时间超过60秒（repl-timeout），那么slave node就会认为复制失败，可以适当调节大这个参数
（3）对于千兆网卡的机器，一般每秒传输100MB，6G文件，很可能超过60s
（4）master node在生成rdb时，会将所有新的写命令缓存在内存中，在salve node保存了rdb之后，再将新的写命令复制给salve node
（5）client-output-buffer-limit slave 256MB 64MB 60，如果在复制期间，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，那么停止复制，复制失败
（6）slave node接收到rdb之后，清空自己的旧数据，然后重新加载rdb到自己的内存中，同时基于旧的数据版本对外提供服务
（7）如果slave node开启了AOF，那么会立即执行BGREWRITEAOF，重写AOF
rdb生成、rdb通过网络拷贝、slave旧数据的清理、slave aof rewrite，很耗费时间，如果复制的数据量在4G~6G之间，那么很可能全量复制时间消耗到1分半到2分钟
过程：
1.Redis内部会发出一个同步命令，刚开始是Psync命令，Psync ? -1表示要求master主机同步数据
2.主机会向从机发送run_id和offset，因为slave并没有对应的 offset，所以是全量复制
3.从机slave会保存主机master的基本信息
4.主节点收到全量复制的命令后，执行bgsave（异步执行），在后台生成RDB文件（快照），并使用一个缓冲区（称为复制缓冲区）记录从现在开始执行的所有写命令
5.主机发送RDB文件给从机
6.发送缓冲区数据
7.刷新旧的数据。从节点在载入主节点的数据之前要先将老数据清除
8.加载RDB文件将数据库状态更新至主节点执行bgsave时的数据库状态和缓冲区数据的加载。
部分复制：
1.如果网络抖动（连接断开 connection lost）
2.主机master 还是会写 repl_back_buffer（复制缓冲区）
3.从机slave 会继续尝试连接主机
4.从机slave 会把自己当前 run_id 和偏移量传输给主机 master，并且执行 pysnc 命令同步
5.如果master发现你的偏移量是在缓冲区的范围内，就会返回 continue命令
6.同步了offset的部分数据，所以部分复制的基础就是偏移量 offset。
开发运维常见的问题
1.读写分离
复制数据存在延迟（如果从节点发生阻塞）
从节点可能发生故障
2.主从配置不一致
例如maxmemory不一致，可能会造成丢失数据
例如数据结构优化参数不一致：造成主从内存不一致
3.规避全量复制
第一次全量复制不可避免，所以分片的maxmemory减小，同时选择在低峰（夜间）时，做全量复制。
复制积压缓冲区不足
增大复制缓冲区配置rel_backlog_size
例如如果网络中断的平均时间是60s，而主节点平均每秒产生的写命令(特定协议格式)所占的字节数为100KB，则复制积压缓冲区的平均需求为6MB，保险起见，可以设置为12MB，来保证绝大多数断线情况都可以使用部分复制。
4.复制风暴
master节点重启，master节点生成一份rdb文件，但是要给所有从节点发送rdb文件。对cpu，内存，带宽都造成很大的压力
17、Redis的线程模型是什么。
客户端 socket01 向 redis 的 server socket 请求建立连接，此时 server socket 会产生一个 AE_READABLE 事件，IO 多路复用程序监听到 server socket 产生的事件后，将该事件压入队列中。文件事件分派器从队列中获取该事件，交给连接应答处理器。连接应答处理器会创建一个能与客户端通信的 socket01，并将该 socket01 的 AE_READABLE 事件与命令请求处理器关联。
假设此时客户端发送了一个 set key value 请求，此时 redis 中的 socket01 会产生 AE_READABLE 事件，IO 多路复用程序将事件压入队列，此时事件分派器从队列中获取到该事件，由于前面 socket01 的 AE_READABLE 事件已经与命令请求处理器关联，因此事件分派器将事件交给命令请求处理器来处理。命令请求处理器读取 socket01 的 key value 并在自己内存中完成 key value 的设置。操作完成后，它会将 socket01 的 AE_WRITABLE 事件与命令回复处理器关联。
如果此时客户端准备好接收返回结果了，那么 redis 中的 socket01 会产生一个 AE_WRITABLE 事件，同样压入队列中，事件分派器找到相关联的命令回复处理器，由命令回复处理器对 socket01 输入本次操作的一个结果，比如 ok，之后解除 socket01 的 AE_WRITABLE 事件与命令回复处理器的关联。
18、请思考一个方案，设计一个可以控制缓存总体大小的自动适应的本地缓存。
19、如何看待缓存的使用（本地缓存，集中式缓存），简述本地缓存和集中式缓存和优缺点。本地缓存在并发使用时的注意事项。
本地缓存，本地缓存没有成熟的超时机制；其次本地缓存使用的是jvm的内存；各个进程间的缓存不可以共享；这种缓存没有持久化机制，随着服务的重启，缓存所占用的空间会释放掉；
集中式缓存（如redis），他们一般由成熟的expire超时机制；是和业务分离的独立的服务，使用的是redis本进程分配的缓存，不是jvm的缓存；这种缓存也叫分布式缓存，各个进程间可以共享，不需要在各个进程本地都缓存一份，可以保证各个进程间的缓存一致；支持持久化,可以提供丰富的数据结构,而本地缓存不可以；
读写速度，不考虑并发问题，本地缓存自然是最快的。但是如果本地缓存不加锁，那应并发了咋办呢？所以，我们以加锁方式再比较一次。
场景使用，同一数据，从数据库取出来，放到redis只要一次，而放到本地缓存，则需要n个集群次
本地缓存无法用于重复点击，重复点击会分发请求到多台服务器，而用本地缓存只能防止本机重复点击，redis则可以防止，但是时间间隔也需要在redis的读写差之外。
redis内存可能n多扩充，而本地扩大堆内存代价是很大的。
本地缓存需要自己实现过期功能，实现不好可能导致极其严重的后果，而redis经过大量的流量验证，许多漏洞无需考试，安全。
本地缓存无法提供丰富的数据结构，redis可以。
redis可以写磁盘，持久化，本地缓存不可以或者说很麻烦要考虑的东西太多。
各位开发同学水平差别大，使用本地缓存极有可能导致严重的线程安全问题，并发考虑严重。
加本地缓存后，代码复杂度急剧上升，后面进来的开发很难一下领会原有开发想法。间接提升维护成本。
其实在map和redis取值这里省的时间，可能在我们写得乱七八糟的代码里，早都不算啥了，所以有时候咱们真的没必要较那几毫秒的真！
一、缓存一致性问题
当数据时效性要求很高时，需要保证缓存中的数据与数据库中的保持一致，而且需要保证缓存节点和副本中的数据也保持一致，不能出现差异现象。这就比较依赖缓存的过期和更新策略。一般会在数据发生更改的时，主动更新缓存中的数据或者移除对应的缓存。
二、缓存并发问题
缓存过期后将尝试从后端数据库获取数据，这是一个看似合理的流程。但是，在高并发场景下，有可能多个请求并发的去从数据库获取数据，对后端数据库造成极大的冲击，甚至导致 “雪崩”现象。此外，当某个缓存key在被更新时，同时也可能被大量请求在获取，这也会导致一致性的问题。那如何避免类似问题呢？我们会想到类似“锁”的机制，在缓存更新或者过期的情况下，先尝试获取到锁，当更新或者从数据库获取完成后再释放锁，其他的请求只需要牺牲一定的等待时间，即可直接从缓存中继续获取数据。
三、缓存穿透问题
缓存穿透在有些地方也称为“击穿”。很多朋友对缓存穿透的理解是：由于缓存故障或者缓存过期导致大量请求穿透到后端数据库服务器，从而对数据库造成巨大冲击。
这其实是一种误解。真正的缓存穿透应该是这样的：
在高并发场景下，如果某一个key被高并发访问，没有被命中，出于对容错性考虑，会尝试去从后端数据库中获取，从而导致了大量请求达到数据库，而当该key对应的数据本身就是空的情况下，这就导致数据库中并发的去执行了很多不必要的查询操作，从而导致巨大冲击和压力。
可以通过下面的几种常用方式来避免缓存传统问题：
-
缓存空对象
对查询结果为空的对象也进行缓存，如果是集合，可以缓存一个空的集合（非null），如果是缓存单个对象，可以通过字段标识来区分。这样避免请求穿透到后端数据库。同时，也需要保证缓存数据的时效性。这种方式实现起来成本较低，比较适合命中不高，但可能被频繁更新的数据。 -
单独过滤处理
对所有可能对应数据为空的key进行统一的存放，并在请求前做拦截，这样避免请求穿透到后端数据库。这种方式实现起来相对复杂，比较适合命中不高，但是更新不频繁的数据。
四、缓存颠簸问题
缓存的颠簸问题，有些地方可能被成为“缓存抖动”，可以看做是一种比“雪崩”更轻微的故障，但是也会在一段时间内对系统造成冲击和性能影响。一般是由于缓存节点故障导致。业内推荐的做法是通过一致性Hash算法来解决。这里不做过多阐述，可以参照其他资料。
五、缓存的雪崩现象
缓存雪崩就是指由于缓存的原因，导致大量请求到达后端数据库，从而导致数据库崩溃，整个系统崩溃，发生灾难。导致这种现象的原因有很多种，上面提到的“缓存并发”，“缓存穿透”，“缓存颠簸”等问题，其实都可能会导致缓存雪崩现象发生。这些问题也可能会被恶意攻击者所利用。还有一种情况，例如某个时间点内，系统预加载的缓存周期性集中失效了，也可能会导致雪崩。为了避免这种周期性失效，可以通过设置不同的过期时间，来错开缓存过期，从而避免缓存集中失效。
从应用架构角度，我们可以通过限流、降级、熔断等手段来降低影响，也可以通过多级缓存来避免这种灾难。
此外，从整个研发体系流程的角度，应该加强压力测试，尽量模拟真实场景，尽早的暴露问题从而防范。
六、缓存无底洞现象
该问题由 facebook 的工作人员提出的， facebook 在 2010 年左右，memcached 节点就已经达3000 个，缓存数千 G 内容。
他们发现了一个问题—memcached 连接频率，效率下降了，于是加 memcached 节点，添加了后，发现因为连接频率导致的问题，仍然存在，并没有好转，称之为”无底洞现象”。
主要可以从如下几个方面避免和优化：
- 数据分布方式
有些业务数据可能适合Hash分布，而有些业务适合采用范围分布，这样能够从一定程度避免网络IO的开销。
- IO优化
可以充分利用连接池，NIO等技术来尽可能降低连接开销，增强并发连接能力。
- 数据访问方式
一次性获取大的数据集，会比分多次去获取小数据集的网络IO开销更小。
当然，缓存无底洞现象并不常见。在绝大多数的公司里可能根本不会遇到。
12、搜索
1、你对elasticsearch了解多少，说说你们公司es的集群架构，索引数据大小，分片有多少，以及一些调优手段 。elasticsearch的倒排索引是什么。
如实结合自己的实践场景回答即可。
比如：
es生产集群我们部署了5台机器，每台机器是6核64G的，集群总内存是320G
我们es集群的日增量数据大概是2000万条，每天日增量数据大概是500MB，每月增量数据大概是6亿，15G。目前系统已经运行了几个月，现在es集群里数据总量大概是100G左右。
目前线上有5个索引（这个结合你们自己业务来，看看自己有哪些数据可以放es的），每个索引的数据量大概是20G，所以这个数据量之内，我们每个索引分配的是8个shard，比默认的5个shard多了3个shard。
仅索引层面调优手段：
1、设计阶段调优
1）根据业务增量需求，采取基于日期模板创建索引，通过roll over API滚动索引；
2）使用别名进行索引管理；
3）每天凌晨定时对索引做force_merge操作，以释放空间；
4）采取冷热分离机制，热数据存储到SSD，提高检索效率；冷数据定期进行shrink操作，以缩减存储；
5）采取curator进行索引的生命周期管理；
6）仅针对需要分词的字段，合理的设置分词器；
7）Mapping阶段充分结合各个字段的属性，是否需要检索、是否需要存储等。 …
2、写入调优
1）写入前副本数设置为0；
2）写入前关闭refresh_interval设置为-1，禁用刷新机制；
3）写入过程中：采取bulk批量写入；
4）写入后恢复副本数和刷新间隔；
5）尽量使用自动生成的id。
3、查询调优
1）禁用wildcard；
2）禁用批量terms（成百上千的场景）；
3）充分利用倒排索引机制，能keyword类型尽量keyword；
4）数据量大时候，可以先基于时间敲定索引再检索；
5）设置合理的路由机制。
1.4、其他调优
1）部署调优，业务调优等。
上面的提及一部分，面试者就基本对你之前的实践或者运维经验有所评估了。
倒排索引：
概念：倒排索引实际上由于应用中需要根据属性值来查找记录，这种索引表中的每一项都包含一个属性值和具有该属性值的各记录的地址。由于不是由记录来确定属性值，而是由属性值来确定记录的位置，因而称之为倒排索引(inverted index),带有倒排索引的文件称之为倒排（倒排索引是类似于哈希表一样的数据结构，完成由词条（也称为term/token）到文档id的映射。可以根据搜索词条快速找到该词条对应的所有文档id，然后根据id直接获取文档。）
使用场景：
1、全文搜索（搜索引擎）
在一组文档中查找某一单词所在文档及位置
2、模糊匹配
通过用户的输入去匹配词库中符合条件的词条
3、商品搜索
通过商品的关键字去数据源中查找符合条件的商品
倒排索引还需要亟待解决的问题：
1、大小写转化的问题，如python和PYTHON应该为一个词
2、词干抽取的问题,比如 look 和 looking 这两个词结果都处理成了look
3、分词，“屏蔽系统”这个词 应该是 分词为 “屏蔽“ ， “系统” 两个词还是 “屏蔽系统” 这样一个词
4、倒排索引文件过大 — 需要压缩进行编码
2、elasticsearch 索引数据多了怎么办，如何调优，部署。
索引数据的规划，应在前期做好规划，正所谓“设计先行，编码在后”，这样才能有效的避免突如其来的数据激增导致集群处理能力不足引发的线上客户检索或者其他业务受到影响。
如何调优，正如问题1所说，这里细化一下：
3.1 动态索引层面
基于模板+时间+rollover api滚动创建索引，举例：设计阶段定义：blog索引的模板格式为：blog_index_时间戳的形式，每天递增数据。
这样做的好处：不至于数据量激增导致单个索引数据量非常大，接近于上线2的32次幂-1，索引存储达到了TB+甚至更大。
一旦单个索引很大，存储等各种风险也随之而来，所以要提前考虑+及早避免。
3.2 存储层面
冷热数据分离存储，热数据（比如最近3天或者一周的数据），其余为冷数据。
对于冷数据不会再写入新数据，可以考虑定期force_merge加shrink压缩操作，节省存储空间和检索效率。
3.3 部署层面
一旦之前没有规划，这里就属于应急策略。
结合ES自身的支持动态扩展的特点，动态新增机器的方式可以缓解集群压力，注意：如果之前主节点等规划合理，不需要重启集群也能完成动态新增的。
3、elasticsearch是如何实现master选举的。
1、选举前提条件
1)该master-eligible（候选节点）节点的当前状态不是master。
2)该master-eligible节点通过ZenDiscovery模块的ping操作询问其已知的集群其他节点，没有任何节点连接到master。
3)包括本节点在内，当前已有超过minimum_master_nodes个节点没有连接到master。
2、选举
先根据节点的clusterStateVersion比较，clusterStateVersion越大，优先级越高。clusterStateVersion相同时，进入compareNodes，其内部按照节点的Id比较(Id为节点第一次启动时随机生成)。
1>当clusterStateVersion越大，优先级越高。这是为了保证新Master拥有最新的clusterState(即集群的meta)，避免已经commit的meta变更丢失。因为Master当选后，就会以这个版本的clusterState为基础进行更新。(一个例外是集群全部重启，所有节点都没有meta，需要先选出一个master，然后master再通过持久化的数据进行meta恢复，再进行meta同步)。
2>当clusterStateVersion相同时，节点的Id越小，优先级越高。即总是倾向于选择Id小的Node，这个Id是节点第一次启动时生成的一个随机字符串。之所以这么设计，应该是为了让选举结果尽可能稳定，不要出现都想当master而选不出来的情况。
3>当一个master-eligible node(我们假设为Node_A)发起一次选举时，它会按照上述排序策略选出一个它认为的master。
【1】设Node_A选Node_B当Master：
Node_A会向Node_B发送join请求，那么此时：
(1) 如果Node_B已经成为Master，Node_B就会把Node_A加入到集群中，然后发布最新的cluster_state, 最新的cluster_state就会包含Node_A的信息。相当于一次正常情况的新节点加入。对于Node_A，等新的cluster_state发布到Node_A的时候，Node_A也就完成join了。
(2) 如果Node_B在竞选Master，那么Node_B会把这次join当作一张选票。对于这种情况，Node_A会等待一段时间，看Node_B是否能成为真正的Master，直到超时或者有别的Master选成功。
(3) 如果Node_B认为自己不是Master(现在不是，将来也选不上)，那么Node_B会拒绝这次join。对于这种情况，Node_A会开启下一轮选举。
【2】假设Node_A选自己当Master：
此时NodeA会等别的node来join，即等待别的node的选票，当收集到超过半数的选票时，认为自己成为master，然后变更cluster_state中的master node为自己，并向集群发布这一消息。
4、详细描述一下Elasticsearch索引文档的过程。
这里的索引文档应该理解为文档写入ES，创建索引的过程。
文档写入包含：单文档写入和批量bulk写入，这里只解释一下：单文档写入流程。
第一步：客户写集群某节点写入数据，发送请求。（如果没有指定路由/协调节点，请求的节点扮演路由节点的角色。）
第二步：节点1接受到请求后，使用文档_id来确定文档属于分片0。请求会被转到另外的节点，假定节点3。因此分片0的主分片分配到节点3上。
第三步：节点3在主分片上执行写操作，如果成功，则将请求并行转发到节点1和节点2的副本分片上，等待结果返回。所有的副本分片都报告成功，节点3将向协调节点（节点1）报告成功，节点1向请求客户端报告写入成功。
如果面试官再问：第二步中的文档获取分片的过程？
回答：借助路由算法获取，路由算法就是根据路由和文档id计算目标的分片id的过程。
shard = hash(_routing) % (num_of_primary_shards)
5、详细描述一下Elasticsearch搜索的过程。
1）搜索被执行成一个两阶段过程，我们称之为 Query Then Fetch；
（2）在初始查询阶段时，查询会广播到索引中每一个分片拷贝（主分片或者副本分片）。 每个分片在本地执行搜索并构建一个匹配文档的大小为 from + size 的优先队列。
PS：在搜索的时候是会查询 Filesystem Cache 的，但是有部分数据还在 MemoryBuffer，所以搜索是近实时的。
（3）每个分片返回各自优先队列中 所有文档的 ID 和排序值 给协调节点，它合并这些值到自己的优先队列中来产生一个全局排序后的结果列表。
（4）接下来就是 取回阶段，协调节点辨别出哪些文档需要被取回并向相关的分片提交多个 GET 请求。每个分片加载并 丰 富 文档，如果有需要的话，接着返回文档给协调节点。一旦所有的文档都被取回了，协调节点返回结果给客户端。
（5）补充：Query Then Fetch 的搜索类型在文档相关性打分的时候参考的是本分片的数据，这样在文档数量较少的时候可能不够准确，DFS Query Then Fetch 增加了一个预查询的处理，询问 Term 和 Document frequency，这个评分更准确，但是性能会变差。
6、Elasticsearch在部署时，对Linux的设置有哪些优化方法？
（1）64 GB 内存的机器是非常理想的， 但是 32 GB 和 16 GB 机器也是很常见的。少于 8 GB 会适得其反。
（2）如果你要在更快的 CPUs 和更多的核心之间选择，选择更多的核心更好。多个内核提供的额外并发远胜过稍微快一点点的时钟频率。
（3）如果你负担得起 SSD，它将远远超出任何旋转介质。 基于 SSD 的节点，查询和索引性能都有提升。如果你负担得起，SSD 是一个好的选择。
（4）即使数据中心们近在咫尺，也要避免集群跨越多个数据中心。绝对要避免集群跨越大的地理距离。
（5）请确保运行你应用程序的 JVM 和服务器的 JVM 是完全一样的。 在Elasticsearch 的几个地方，使用 Java 的本地序列化。
（6）通过设置 gateway.recover_after_nodes、gateway.expected_nodes、gateway.recover_after_time 可以在集群重启的时候避免过多的分片交换，这可能会让数据恢复从数个小时缩短为几秒钟。
（7）Elasticsearch 默认被配置为使用单播发现，以防止节点无意中加入集群。只有在同一台机器上运行的节点才会自动组成集群。最好使用单播代替组播。
（8）不要随意修改垃圾回收器（CMS）和各个线程池的大小。
（9）把你的内存的（少于）一半给 Lucene（但不要超过 32 GB！），通过ES_HEAP_SIZE 环境变量设置。
（10）内存交换到磁盘对服务器性能来说是致命的。如果内存交换到磁盘上，一个100 微秒的操作可能变成 10 毫秒。 再想想那么多 10 微秒的操作时延累加起来。 不难看出 swapping 对于性能是多么可怕。
（11）Lucene 使用了大 量 的文件。同时，Elasticsearch 在节点和 HTTP 客户端之间进行通信也使用了大量的套接字。 所有这一切都需要足够的文件描述符。你应该增加你的文件描述符，设置一个很大的值，如 64,000。
补充：索引阶段性能提升方法
（1）使用批量请求并调整其大小：每次批量数据 5–15 MB 大是个不错的起始点。
（2）存储：使用 SSD
（3）段和合并：Elasticsearch 默认值是 20 MB/s，对机械磁盘应该是个不错的设置。如果你用的是 SSD，可以考虑提高到 100–200 MB/s。如果你在做批量导入，完全不在意搜索，你可以彻底关掉合并限流。另外还可以增加index.translog.flush_threshold_size 设置，从默认的 512 MB 到更大一些的值，比如 1 GB，这可以在一次清空触发的时候在事务日志里积累出更大的段。
（4）如果你的搜索结果不需要近实时的准确度，考虑把每个索引的index.refresh_interval 改到 30s。
（5）如果你在做大批量导入，考虑通过设置 index.number_of_replicas: 0 关闭副本。
7、lucence内部结构是什么。
索引(Index)： 在Lucene中一个索引是放在一个文件夹中的。
段(Segment)： 一个索引可以包含多个段，段与段之间是独立的，添加新文档可以生成新的段，不同的段可以合并。segments.gen和segments_X是段的元数据文件，也即它们保存了段的属性信息。
文档(Document)： 文档是我们建索引的基本单位，不同的文档是保存在不同的段中的，一个段可以包含多篇文档。 新添加的文档是单独保存在一个新生成的段中，随着段的合并，不同的文档合并到同一个段中。
域(Field)： 一篇文档包含不同类型的信息，可以分开索引，比如标题，时间，正文，作者等，都可以保存在不同的域里。 不同域的索引方式可以不同，在真正解析域的存储的时候，我们会详细解读。
词(Term)： 词是索引的最小单位，是经过词法分析和语言处理后的字符串。
8、Elasticsearch能够实现快速搜索的原因
ES的核心是倒排索引(其他搜索引擎也类似)；并且基于倒排索引，充分利用了缓存。这是可以快速搜索的主要原因。
另外对于搜索请求是分布式执行的，由多台机器同时执行，然后汇总，这也是可以快速搜索的一个主要原因。
9、详细描述一下 Elasticsearch 更新和删除文档的过程。
（1）删除和更新也都是写操作，但是 Elasticsearch 中的文档是不可变的，因此不能被删除或者改动以展示其变更；
（2）磁盘上的每个段都有一个相应的.del 文件。当删除请求发送后，文档并没有真的被删除，而是在.del 文件中被标记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。当段合并时，在.del 文件中被标记为删除的文档将不会被写入新段。
（3）在新的文档被创建时，Elasticsearch 会为该文档指定一个版本号，当执行更新时，旧版本的文档在.del 文件中被标记为删除，新版本的文档被索引到一个新段。旧版本的文档依然能匹配查询，但是会在结果中被过滤掉。
10、对于 GC 方面，在使用 Elasticsearch 时要注意什么？
（1）倒排词典的索引需要常驻内存，无法 GC，需要监控 data node 上 segmentmemory 增长趋势。
（2）各类缓存，field cache, filter cache, indexing cache, bulk queue 等等，要设置合理的大小，并且要应该根据最坏的情况来看 heap 是否够用，也就是各类缓存全部占满的时候，还有 heap 空间可以分配给其他任务吗？避免采用 clear cache等“自欺欺人”的方式来释放内存。
（3）避免返回大量结果集的搜索与聚合。确实需要大量拉取数据的场景，可以采用scan & scroll api 来实现。
（4）cluster stats 驻留内存并无法水平扩展，超大规模集群可以考虑分拆成多个集群通过 tribe node 连接。
（5）想知道 heap 够不够，必须结合实际应用场景，并对集群的 heap 使用情况做持续的监控。
（6）根据监控数据理解内存需求，合理配置各类circuit breaker，将内存溢出风险降低到最低
11、在并发情况下，Elasticsearch 如果保证读写一致？
（1）可以通过版本号使用乐观并发控制，以确保新版本不会被旧版本覆盖，由应用层来处理具体的冲突；
（2）另外对于写操作，一致性级别支持 quorum/one/all，默认为 quorum，即只有当大多数分片可用时才允许写操作。但即使大多数可用，也可能存在因为网络等原因导致写入副本失败，这样该副本被认为故障，分片将会在一个不同的节点上重建。
（3）对于读操作，可以设置 replication 为 sync(默认)，这使得操作在主分片和副本分片都完成后才会返回；如果设置 replication 为 async 时，也可以通过设置搜索请求参数_preference 为 primary 来查询主分片，确保文档是最新版本。
12、es在数据量很大的情况下（数十亿级别）如何提高查询效率啊
1、走os cache操作系统的缓存
你往es里写的数据，实际上都写到磁盘文件里去了，磁盘文件里的数据操作系统会自动将里面的数据缓存到os cache里面去。es的搜索引擎严重依赖于底层的filesystem cache，你如果给filesystem cache更多的内存,因为他是先走os cache,然后在进入file system cache,os case中的数据会做成一个类似于备份，尽量让内存可以容纳所有的indx segment file索引数据文件，那么你搜索的时候就基本都是走内存的，性能会非常高。
你存储的是据量要有一大半存储在缓存中，这样搜索是走内存的，性能会有所提高，存储的时候，一行数据如果有30个字段，那么只需要存储必须用于索引的几个字段就行了，就不会有那么大的数据量了，从缓存中搜索到id，然后在根据id到数据库里进行查询，最好是写入es的数据小于等于，或者是略微大于es的filesystem cache的内存容量
2、数据预热
对于那些你觉得比较热的，经常会有人访问的数据，最好做一个专门的缓存预热子系统，就是对热数据，每隔一段时间，你就提前访问一下，让数据进入filesystem cache里面去。这样期待下次别人访问的时候，一定性能会好一些
3、冷热分离
es可以做类似于mysql的水平拆分，就是说将大量的访问很少，频率很低的数据，单独写一个索引，然后将访问很频繁的热数据单独写一个索引，这样可以确保热数据在被预热之后，尽量都让他们留在filesystem os cache里，别让冷数据给冲刷掉
4、document模型设计
如果是多张表关联查询到话，尽量是先将数据关联查询出来，组成一个新的实体，然后在写入es中，这样就不需要利用es的搜索语法来完成关联了
5、分页性能优化
假如你每页是10条数据，你现在要查询第100页，实际上是会把每个shard上存储的前1000条数据都查到一个协调节点上，如果你有个5个shard，那么就有5000条数据，接着协调节点对这5000条数据进行一些合并、处理，再获取到最终第100页的10条数据。你翻页的时候，翻的越深，每个shard返回的数据就越多，而且协调节点处理的时间越长。所以用es做分页的时候，你会发现越翻到后面，就越是慢。可以使用类似于app里的推荐商品不断下拉出来一页一页的
13、es读写底层原理
es写数据过程
1）客户端选择一个node发送请求过去，这个node就是coordinating node（协调节点）
2）coordinating node，对document进行路由，将请求转发给对应的node（有primary shard）
3）实际的node上的primary shard处理请求，然后将数据同步到replica node
4）coordinating node，如果发现primary node和所有replica node都搞定之后，就返回响应结果给客户端
es读数据过程
1）客户端发送请求到任意一个node，成为coordinate node
2）coordinate node对document进行路由，将请求转发到对应的node，此时会使用round-robin随机轮询算法，在primary shard以及其所有replica中随机选择一个，让读请求负载均衡
3）接收请求的node返回document给coordinate node
4）coordinate node返回document给客户端
es搜索数据过程
1）客户端发送请求到一个coordinate node
2）协调节点将搜索请求转发到所有的shard对应的primary shard或replica shard也可以
3）query phase：每个shard将自己的搜索结果（其实就是一些doc id），返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果
4）fetch phase：接着由协调节点，根据doc id去各个节点上拉取实际的document数据，最终返回给客户端
写数据底层原理
1）先写入buffer，在buffer里的时候数据是搜索不到的；同时将数据写入translog日志文件
2）如果buffer快满了，或者到一定时间，就会将buffer数据refresh到一个新的segment file中，但是此时数据不是直接进入segment file的磁盘文件的，而是先进入os cache的。这个过程就是refresh。操作系统里面，磁盘文件其实都有一个东西，叫做os cache
每隔1秒钟，es将buffer中的数据写入一个新的segment file，每秒钟会产生一个新的磁盘文件，segment file，这个segment file中就存储最近1秒内buffer中写入的数据
但是如果buffer里面此时没有数据，那当然不会执行refresh操作咯，每秒创建换一个空的segment file，如果buffer里面有数据，默认1秒钟执行一次refresh操作，刷入一个新的segment file中
操作系统里面，磁盘文件其实都有一个东西，叫做os cache，操作系统缓存，就是说数据写入磁盘文件之前，会先进入os cache，先进入操作系统级别的一个内存缓存中去
只要buffer中的数据被refresh操作，刷入os cache中，就代表这个数据就可以被搜索到了
为什么叫es是准实时的？NRT，near real-time，准实时。默认是每隔1秒refresh一次的，所以es是准实时的，因为写入的数据1秒之后才能被看到。
可以通过es的restful api或者java api，手动执行一次refresh操作，就是手动将buffer中的数据刷入os cache中，让数据立马就可以被搜索到。
只要数据被输入os cache中，buffer就会被清空了，因为不需要保留buffer了，数据在translog里面已经持久化到磁盘去一份了
3）只要数据进入os cache，此时就可以让这个segment file的数据对外提供搜索了
4）重复1~3步骤，新的数据不断进入buffer和translog，不断将buffer数据写入一个又一个新的segment file中去，每次refresh完buffer清空，translog保留。随着这个过程推进，translog会变得越来越大。当translog达到一定长度的时候，就会触发commit操作。
buffer中的数据，倒是好，每隔1秒就被刷到os cache中去，然后这个buffer就被清空了。所以说这个buffer的数据始终是可以保持住不会填满es进程的内存的。
每次一条数据写入buffer，同时会写入一条日志到translog日志文件中去，所以这个translog日志文件是不断变大的，当translog日志文件大到一定程度的时候，就会执行commit操作。
5）commit操作发生第一步，就是将buffer中现有数据refresh到os cache中去，清空buffer
6）将一个commit point写入磁盘文件，里面标识着这个commit point对应的所有segment file
7）强行将os cache中目前所有的数据都fsync到磁盘文件中去
translog日志文件的作用是什么？就是在你执行commit操作之前，数据要么是停留在buffer中，要么是停留在os cache中，无论是buffer还是os cache都是内存，一旦这台机器死了，内存中的数据就全丢了。
所以需要将数据对应的操作写入一个专门的日志文件，translog日志文件中，一旦此时机器宕机，再次重启的时候，es会自动读取translog日志文件中的数据，恢复到内存buffer和os cache中去。
commit操作：1、写commit point；2、将os cache数据fsync强刷到磁盘上去；3、清空translog日志文件
8）将现有的translog清空，然后再次重启启用一个translog，此时commit操作完成。默认每隔30分钟会自动执行一次commit，但是如果translog过大，也会触发commit。整个commit的过程，叫做flush操作。我们可以手动执行flush操作，就是将所有os cache数据刷到磁盘文件中去。
不叫做commit操作，flush操作。es中的flush操作，就对应着commit的全过程。我们也可以通过es api，手动执行flush操作，手动将os cache中的数据fsync强刷到磁盘上去，记录一个commit point，清空translog日志文件。
9）translog其实也是先写入os cache的，默认每隔5秒刷一次到磁盘中去，所以默认情况下，可能有5秒的数据会仅仅停留在buffer或者translog文件的os cache中，如果此时机器挂了，会丢失5秒钟的数据。但是这样性能比较好，最多丢5秒的数据。也可以将translog设置成每次写操作必须是直接fsync到磁盘，但是性能会差很多。
实际上你在这里，如果面试官没有问你es丢数据的问题，你可以在这里给面试官炫一把，你说，其实es第一是准实时的，数据写入1秒后可以搜索到；可能会丢失数据的，你的数据有5秒的数据，停留在buffer、translog os cache、segment file os cache中，有5秒的数据不在磁盘上，此时如果宕机，会导致5秒的数据丢失。
如果你希望一定不能丢失数据的话，你可以设置个参数，官方文档，百度一下。每次写入一条数据，都是写入buffer，同时写入磁盘上的translog，但是这会导致写性能、写入吞吐量会下降一个数量级。本来一秒钟可以写2000条，现在你一秒钟只能写200条，都有可能。
10）如果是删除操作，commit的时候会生成一个.del文件，里面将某个doc标识为deleted状态，那么搜索的时候根据.del文件就知道这个doc被删除了
11）如果是更新操作，就是将原来的doc标识为deleted状态，然后新写入一条数据
12）buffer每次refresh一次，就会产生一个segment file，所以默认情况下是1秒钟一个segment file，segment file会越来越多，此时会定期执行merge
13）每次merge的时候，会将多个segment file合并成一个，同时这里会将标识为deleted的doc给物理删除掉，然后将新的segment file写入磁盘，这里会写一个commit point，标识所有新的segment file，然后打开segment file供搜索使用，同时删除旧的segment file。
es里的写流程，有4个底层的核心概念，refresh、flush、translog、merge
当segment file多到一定程度的时候，es就会自动触发merge操作，将多个segment file给merge成一个segment file。
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
