SpringMVC:
简单的介绍一下Spring Mvc的工作原理？
1、用户向服务器发送请求，请求被SpringMVC的前端控制器DispatcherServlet截获。
2、DispatcherServlet对请求的URL（统一资源定位符）进行解析，得到URI(请求资源标识符)，然后根据该URI，调用HandlerMapping获得该Handler配置的所有相关的对象，包括Handler对象以及Handler对象对应的拦截器，这些对象都会被封装到一个HandlerExecutionChain对象当中返回。
3、DispatcherServlet根据获得的Handler，选择一个合适的HandlerAdapter。HandlerAdapter的设计符合面向对象中的单一职责原则，代码结构清晰，便于维护，最为重要的是，代码的可复制性高。HandlerAdapter会被用于处理多种Handler，调用Handler实际处理请求的方法。
4、提取请求中的模型数据，开始执行Handler(Controller)。在填充Handler的入参过程中，根据配置，spring将帮助做一些额外的工作消息转换：将请求的消息，如json、xml等数据转换成一个对象，将对象转换为指定的响应信息。数据转换：对请求消息进行数据转换，如String转换成Integer、Double等。 数据格式化：对请求的消息进行数据格式化，如将字符串转换为格式化数字或格式化日期等。数据验证：验证数据的有效性如长度、格式等，验证结果存储到BindingResult或Error中。
5、Handler执行完成后，向DispatcherServlet返回一个ModelAndView对象，ModelAndView对象中应该包含视图名或视图模型。
6、根据返回的ModelAndView对象，选择一个合适的ViewResolver(视图解析器)返回给DispatcherServlet。
7、ViewResolver结合Model和View来渲染视图。
8、将视图渲染结果返回给客户端。
url和uri的区别？
URI包括URL和URN两个类别，个人的身份证号就是URN，个人的家庭地址就是URL，URN可以唯一标识一个人，而URL可以告诉邮递员怎么把货送到你手里。
Springboot:
简单的介绍一下Springboot？
Springboot用来简化spring应用的初始搭建以及开发过程 使用特定的方式来进行配置（properties或yml文件）
可以创建独立的spring引用程序 main方法运行
Springboot嵌入的Tomcat 无需部署war文件
简化maven配置
starters自动依赖与版本控制
Mybatis:
1、什么是mybatis？
（1）mybatis是一个优秀的基于java的持久层框架，它内部封装了jdbc，使开发者只需要关注sql语句本身，而不需要花费精力去处理加载驱动、创建连接、创建statement等繁杂的过程。
（2）mybatis通过xml或注解的方式将要执行的各种statement配置起来，并通过java对象和statement中sql的动态参数进行映射生成最终执行的sql语句，最后由mybatis框架执行sql并将结果映射为java对象并返回。
（3）MyBatis 支持定制化 SQL、存储过程以及高级映射。MyBatis 避免了几乎所有的 JDBC 代码和手动设置参数以及获取结果集。MyBatis 可以使用简单的 XML 或注解来配置和映射原生信息，将接口和 Java 的 POJO映射成数据库中的记录。
2、Mybait的优点：
（1）简单易学，容易上手（相比于Hibernate） —- 基于SQL编程；
（2）JDBC相比，减少了50%以上的代码量，消除了JDBC大量冗余的代码，不需要手动开关连接；
（3）很好的与各种数据库兼容（因为MyBatis使用JDBC来连接数据库，所以只要JDBC支持的数据库MyBatis都支持，而JDBC提供了可扩展性，所以只要这个数据库有针对Java的jar包就可以就可以与MyBatis兼容），开发人员不需要考虑数据库的差异性。
（4）提供了很多第三方插件（分页插件 / 逆向工程）；
（5）能够与Spring很好的集成；
（6）MyBatis相当灵活，不会对应用程序或者数据库的现有设计强加任何影响，SQL写在XML里，从程序代码中彻底分离，解除sql与程序代码的耦合，便于统一管理和优化，并可重用。
（7）提供XML标签，支持编写动态SQL语句。
（8） 提供映射标签，支持对象与数据库的ORM字段关系映射。
（9）提供对象关系映射标签，支持对象关系组建维护。
3、MyBatis框架的缺点：
（1）SQL语句的编写工作量较大，尤其是字段多、关联表多时，更是如此，对开发人员编写SQL语句的功底有一定要求。
（2）SQL语句依赖于数据库，导致数据库移植性差，不能随意更换数据库。
4、MyBatis框架适用场合：
（1）MyBatis专注于SQL本身，是一个足够灵活的DAO层解决方案。
（2）对性能的要求很高，或者需求变化较多的项目，如互联网项目，MyBatis将是不错的选择。
5、#{}和${}的区别是什么？
#{}是预编译处理，${}是字符串替换。
Mybatis在处理#{}时，会将sql中的#{}替换为?号，调用PreparedStatement的set方法来赋值；
Mybatis在处理${}时，就是把${}替换成变量的值。
使用#{}可以有效的防止SQL注入，提高系统安全性。
Dubbo:
简单的介绍一下Dubbo？(Dubbo是什么)
dubbo就是个服务调用的东东。
为什么怎么说呢？
因为Dubbo是由阿里开源的一个RPC分布式框架
那么RPC是什么呢？
就是不同的应用部署到不同的服务器上，应用之间想要调用没有办法直接调用，因为不在一个内存空间，需要通过网络通讯来调用，或者传达调用的数据。而且RPC会将远程调用的细节隐藏起来，让调用远程服务像调用本地服务一样简单。
dubbo有哪些组件？
主要有五个角色/核心组件，分为是Container（容器）、Provider（服务的提供方）、Registry（注册中心）、Consumer（服务的消费方）、Monitor（监控中心）。
容器：主要负责启动、加载、运行服务提供者；
注册中心：注册中心只负责地址的注册和查找
监控中心：监控中心负责统计各服务调用次数、调用时间
Dubbo支持什么协议？
Dubbo协议：缺省协议、采用了单一长连接和NIO异步通讯、使用线程池并发处理请求，能减少握手和加大并发效率
Zookeeper:
Zookeeper的实现原理？（工作原理）
Zookeeper会维护一个类似于标准的文件系统的具有层次关系的数据结构。这个文件系统中每个子目录项都被称为znode节点，这个znode节点也可以有子节点，每个节点都可以存储数据，客户端也可以对这些node节点进行getChildren，getData,exists方法，同时也可以在znode tree路径上设置watch（类似于监听），当watch路径上发生节点create、delete、update的时候，会通知到client。client可以得到通知后，再获取数据，执行业务逻辑操作。Zookeeper 的作用主要是用来维护和监控存储的node节点上这些数据的状态变化，通过监控这些数据状态的变化，从而达到基于数据的集群管理。
为什么要用zookeeper作为dubbo的注册中心？能选择其他的吗？
Zookeeper的数据模型是由一系列的Znode数据节点组成，和文件系统类似。zookeeper的数据全部存储在内存中，性能高；zookeeper也支持集群，实现了高可用；同时基于zookeeper的特性，也支持事件监听（服务的暴露方发生变化，可以进行推送），所以zookeeper适合作为dubbo的注册中心区使用。redis、Simple也可以作为dubbo的注册中心来使用。
项目中主要用zookeeper做了什么？（作用）
作为注册中心用；主要是在服务器上搭建zookeeper，其次在spring管理的dubbo的配置文件中配置（暴露方和消费方都需要配置）
Redis:
简单介绍一个redis？
redis是内存中的数据结构存储系统，一个key-value类型的非关系型数据库，可持久化的数据库，相对于关系型数据库（数据主要存在硬盘中），性能高，因此我们一般用redis来做缓存使用；并且redis支持丰富的数据类型，比较容易解决各种问题，因此redis可以用来作为注册中心，数据库、缓存和消息中间件。Redis的Value支持5种数据类型，string、hash、list、set、zset（sorted set）;
String类型：一个key对应一个value
Hash类型：它的key是string类型，value又是一个map（key-value），适合存储对象。
List类型：按照插入顺序的字符串链表（双向链表），主要命令是LPUSH和RPUSH，能够支持反向查找和遍历
Set类型：用哈希表类型的字符串序列，没有顺序，集合成员是唯一的，没有重复数据，底层主要是由一个value永远为null的hashmap来实现的。
zset类型：和set类型基本一致，不过它会给每个元素关联一个double类型的分数（score），这样就可以为成员排序，并且插入是有序的。
你还用过其他的缓存吗？这些缓存有什么区别？都在什么场景下去用？
对于缓存了解过redis和memcache
Memcache和redis的区别：
数据支持的类型：redis不仅仅支持简单的k/v类型的数据，同时还支持list、set、zset、hash等数据结构的存储；memcache只支持简单的k/v类型的数据，key和value都是string类型
可靠性：memcache不支持数据持久化，断电或重启后数据消失，但其稳定性是有保证的；redis支持数据持久化和数据恢复，允许单点故障，但是同时也会付出性能的代价
性能上：对于存储大数据，memcache的性能要高于redis
应用场景：
Memcache：适合多读少写，大数据量的情况（一些官网的文章信息等）
Redis：适用于对读写效率要求高、数据处理业务复杂、安全性要求较高的系统
案例：分布式系统，存在session之间的共享问题，因此在做单点登录的时候，我们利用redis来模拟了session的共享，来存储用户的信息，实现不同系统的session共享；
对redis的持久化了解不？
redis的持久化方式有两种：
RDB（半持久化方式）：按照配置不定期的通过异步的方式、快照的形式直接把内存中的数据持久化到磁盘的一个dump.rdb文件（二进制的临时文件）中，redis默认的持久化方式，它在配置文件（redis.conf）中。
优点：只包含一个文件，将一个单独的文件转移到其他存储媒介上，对于文件备份、灾难恢复而言，比较实用。
缺点：系统一旦在持久化策略之前出现宕机现象，此前没有来得及持久化的数据将会产生丢失
RDB持久化配置：
Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息：
save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。
AOF（全持久化的方式）：把每一次数据变化都通过write()函数将你所执行的命令追加到一个appendonly.aof文件里面，Redis默认是不支持这种全持久化方式的，需要在配置文件（redis.conf）中将appendonly no改成appendonly yes
优点：数据安全性高，对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机问题，也不会破坏日志文件中已经存在的内容；
缺点：对于数量相同的数据集来说，aof文件通常要比rdb文件大，因此rdb在恢复大数据集时的速度大于AOF；
AOF持久化配置:
在Redis的配置文件中存在三种同步方式，它们分别是：
appendfsync always #每次有数据修改发生时都会都调用fsync刷新到aof文件，非常慢，但是安全；
appendfsync everysec #每秒钟都调用fsync刷新到aof文件中，很快，但是可能丢失一秒内的数据，推荐使用，兼顾了速度和安全；
appendfsync no #不会自动同步到磁盘上，需要依靠OS（操作系统）进行刷新，效率快，但是安全性就比较差；
二种持久化方式区别：
AOF在运行效率上往往慢于RDB，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效；
如果缓存数据安全性要求比较高的话，用aof这种持久化方式（比如项目中的购物车）；
如果对于大数据集要求效率高的话，就可以使用默认的。而且这两种持久化方式可以同时使用。
做过redis的集群吗？你们做集群的时候搭建了几台，都是怎么搭建的？
Redis的数据是存放在内存中的，不适合存储大数据，大数据存储一般公司常用hadoop中的Hbase或者MogoDB。redis主要用来处理高并发的，用我们的项目来说，电商项目如果并发大的话，一台单独的redis是不能足够支持我们的并发，这就需要我们扩展多台设备协同合作，即用到集群。
Redis搭建集群的方式有多种，例如：客户端分片、Twemproxy、Codis等，但是redis3.0之后就支持redis-cluster集群，这种方式采用的是无中心结构，每个节点保存数据和整个集群的状态，每个节点都和其他所有节点连接。如果使用的话就用redis-cluster集群。集群这块是公司运维搭建的，具体怎么搭建不是太了解。
我们项目中redis集群主要搭建了6台，3主（为了保证redis的投票机制）3从（高可用），每个主服务器都有一个从服务器，作为备份机。所有的节点都通过PING-PONG机制彼此互相连接；客户端与redis集群连接，只需要连接集群中的任何一个节点即可；Redis-cluster中内置了16384个哈希槽，Redis-cluster把所有的物理节点映射到【0-16383】slot上，负责维护。
redis有事务吗？
Redis是有事务的，redis中的事务是一组命令的集合，这组命令要么都执行，要不都不执行，保证一个事务中的命令依次执行而不被其他命令插入。redis的事务是不支持回滚操作的。redis事务的实现，需要用到MULTI（事务的开始）和EXEC（事务的结束）命令 ;
缓存穿透
缓存查询一般都是通过key去查找value，如果不存在对应的value，就要去数据库中查找。如果这个key对应的value在数据库中也不存在，并且对该key并发请求很大，就会对数据库产生很大的压力，这就叫缓存穿透
解决方案：
1.对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃。
2.将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
3.如果一个查询返回的数据为空（不管是数 据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。
缓存雪崩
当缓存服务器重启或者大量缓存集中在一段时间内失效，发生大量的缓存穿透，这样在失效的瞬间对数据库的访问压力就比较大，所有的查询都落在数据库上，造成了缓存雪崩。 这个没有完美解决办法，但可以分析用户行为，尽量让失效时间点均匀分布。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。
解决方案：
1.在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。
2.可以通过缓存reload机制，预先去更新缓存，再即将发生大并发访问前手动触发加载缓存
3.不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀
4.做二级缓存，或者双缓存策略。A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期。
redis的安全机制（你们公司redis的安全这方面怎么考虑的？）
漏洞介绍：redis默认情况下，会绑定在bind 0.0.0.0:6379，这样就会将redis的服务暴露到公网上，如果在没有开启认证的情况下，可以导致任意用户在访问目标服务器的情况下，未授权就可访问redis以及读取redis的数据，攻击者就可以在未授权访问redis的情况下可以利用redis的相关方法，成功在redis服务器上写入公钥，进而可以直接使用私钥进行直接登录目标主机；
解决方案：
禁止一些高危命令。修改redis.conf文件，用来禁止远程修改DB文件地址，比如 rename-command FLUSHALL "" 、rename-command CONFIG"" 、rename-command EVAL “”等；
以低权限运行redis服务。为redis服务创建单独的用户和根目录，并且配置禁止登录；
为redis添加密码验证。修改redis.conf文件，添加requirepass mypassword；
禁止外网访问redis。修改redis.conf文件，添加或修改 bind 127.0.0.1，使得redis服务只在当前主机使用；
做log监控，及时发现攻击；
redis的哨兵机制（redis2.6以后出现的）
哨兵机制：
监控：监控主数据库和从数据库是否正常运行；
提醒：当被监控的某个redis出现问题的时候，哨兵可以通过API向管理员或者其他应用程序发送通知；
自动故障迁移：主数据库出现故障时，可以自动将从数据库转化为主数据库，实现自动切换；
具体的配置步骤参考的网上的文档。要注意的是，如果master主服务器设置了密码，记得在哨兵的配置文件（sentinel.conf）里面配置访问密码
redis中对于生存时间的应用
Redis中可以使用expire命令设置一个键的生存时间，到时间后redis会自动删除；
应用场景：
设置限制的优惠活动的信息；
一些及时需要更新的数据，积分排行榜；
手机验证码的时间；
限制网站访客访问频率；
