面试：第八章：SpringMVC、Springboot、Mybatis、Dubbo、Zookeeper、Redis、Elasticsearch、Nginx 、Fastdfs、ActiveMQ

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会自动删除；

  应用场景：

    设置限制的优惠活动的信息；
    一些及时需要更新的数据，积分排行榜；
    手机验证码的时间；
    限制网站访客访问频率；

Elasticsearch:

简单介绍一个Elasticsearch？

ElasticSearch是一个基于Lucene的搜索服务器。通过HTTP使用JSON进行数据索引，用于分布式全文检索，解决人们对于搜索的众多要求。

lucene与elasticsearch（solr）有什么区别？

lucene只是一个提供全文搜索功能类库的核心工具包，而真正使用它还需要一个完善的服务框架搭建起来的应用。好比lucene是类似于jdk，而搜索引擎软件就是tomcat 的。elasticsearch和solr,这两款都是基于lucene的搭建的，可以独立部署启动的搜索引擎服务软件。

基本概念：

 

与MySQL对比

 

利用kibana学习 elasticsearch restful api (DSL)

Kibana 是一个开源分析和可视化平台，可视化操作 Elasticsearch 。Kibana可以用来搜索，查看和与存储在 Elasticsearch 索引中的数据进行交互。可以轻松地进行高级数据分析，并可在各种图表，表格和地图中显示数据。

ES提供了基于JSON的query DSL查询语言
es中保存的数据结构

public class  Movie {

 String id;

     String name;

     Double doubanScore;

     List<Actor> actorList;

}

public class Actor{

String id;

String name;

}

这两个对象如果放在关系型数据库保存，会被拆成2张表，但是elasticsearch是用一个json来表示一个document。

所以它保存到es中应该是：

{

  “id”:”1”,

  “name”:”operation red sea”,

  “doubanScore”:”8.5”,

  “actorList”:[  

{“id”:”1”,”name”:”zhangyi”},

{“id”:”2”,”name”:”haiqing”},

{“id”:”3”,”name”:”zhanghanyu”}

]

}
es 的java 客户端的选择

目前市面上有两类客户端

一类是TransportClient 为代表的ES原生客户端，不能执行原生dsl语句必须使用它的Java api方法。

另外一种是以Rest Api为主的missing client，最典型的就是jest。 这种客户端可以直接使用dsl语句拼成的字符串，直接传给服务端，然后返回json字符串再解析。

两种方式各有优劣，但是最近elasticsearch官网，宣布计划在7.0以后的版本中废除TransportClient。以RestClient为主。在官方的RestClient 基础上，进行了简单包装的Jest客户端，就成了首选，而且该客户端也与springboot完美集成。
中文分词

elasticsearch本身自带的中文分词，就是单纯把中文一个字一个字的分开，根本没有词汇的概念。
问题：

1、 es大量的写操作会影响es 性能，因为es需要更新索引，而且es不是内存数据库，会做相应的io操作。

2、而且修改某一个值，在高并发情况下会有冲突，造成更新丢失，需要加锁，而es的乐观锁会恶化性能问题。
解决思路：

用redis做精确计数器，redis是内存数据库读写性能都非常快，利用redis的原子性的自增可以解决并发写操作。

 redis每计100次数（可以被100整除）我们就更新一次es ，这样写操作就被稀释了100倍，这个倍数可以根据业务情况灵活设定。
增量同步索引库

推荐使用MQ（RabbitMQ）

原理：使用MQ做增量同步，即当修改数据之后就将此数据发送至MQ，由MQ将此数据同步到ES上
Nginx:

1、请解释一下什么是Nginx?

nginx本是一个web服务器和反向代理服务器，但由于丰富的负载均衡策略，常常被用于客户端可真实的服务器之间，作为负载均衡的实现。用于HTTP、HTTPS、SMTP、POP3和IMAP协议。

2、请列举Nginx的一些特性？

1）反向代理/L7负载均衡器

2）嵌入式Perl解释器

3）动态二进制升级

4）可用于重新编写URL，具有非常好的PCRE支持

3、nginx和apache的区别？

1）轻量级，同样起web 服务，比apache 占用更少的内存及资源

2）抗并发，nginx 处理请求是异步非阻塞的，而apache 则是阻塞型的，在高并发下nginx 能保持低资源低消耗高性能

3）高度模块化的设计，编写模块相对简单

4）最核心的区别在于apache是同步多进程模型，一个连接对应一个进程；nginx是异步的，多个连接（万级别）可以对应一个进程

4.nginx是如何实现高并发的？

一个主进程，多个工作进程，每个工作进程可以处理多个请求，每进来一个request，会有一个worker进程去处理。但不是全程的处理，处理到可能发生阻塞的地方，比如向上游（后端）服务器转发request，并等待请求返回。那么，这个处理的worker继续处理其他请求，而一旦上游服务器返回了，就会触发这个事件，worker才会来接手，这个request才会接着往下走。由于web server的工作性质决定了每个request的大部份生命都是在网络传输中，实际上花费在server机器上的时间片不多。这是几个进程就解决高并发的秘密所在。即@skoo所说的webserver刚好属于网络io密集型应用，不算是计算密集型。

5、请解释Nginx如何处理HTTP请求？

Nginx使用反应器模式。主事件循环等待操作系统发出准备事件的信号，这样数据就可以从套接字读取，在该实例中读取到缓冲区并进行处理。单个线程可以提供数万个并发连接。

6、在Nginx中，如何使用未定义的服务器名称来阻止处理请求?

只需将请求删除的服务器就可以定义为：Server {listen 80; server_name “ “ ;return 444;}这里，服务器名被保留为一个空字符串，它将在没有“主机”头字段的情况下匹配请求，而一个特殊的Nginx的非标准代码444被返回，从而终止连接。7、 使用“反向代理服务器”的优点是什么?答：反向代理服务器可以隐藏源服务器的存在和特征。它充当互联网云和web服务器之间的中间层。这对于安全方面来说是很好的，特别是当您使用web托管服务时。

8、请列举Nginx服务器的最佳用途?

Nginx服务器的最佳用法是在网络上部署动态HTTP内容，使用SCGI、WSGI应用程序服务器、用于脚本的FastCGI处理程序。它还可以作为负载均衡器。

9、请解释Nginx服务器上的Master和Worker进程分别是什么?

Master进程：读取及评估配置和维持Worker进程：处理请求

10、请解释你如何通过不同于80的端口开启Nginx?

为了通过一个不同的端口开启Nginx，你必须进入/etc/Nginx/sites-enabled/，如果这是默认文件，那么你必须打开名为“default”的文件。编辑文件，并放置在你想要的端口：Like server {listen 81;}

11、请解释是否有可能将Nginx的错误替换为502错误、503?

502 =错误网关 503 =服务器超载 有可能，但是您可以确保fastcgi_intercept_errors被设置为ON，并使用错误页面指令。Location / { fastcgi_pass 127.0.01:9001; fastcgi_intercept_errors on; error_page 502 =503/error_page.html; #… }

12、在Nginx中，解释如何在URL中保留双斜线?答：要在URL中保留双斜线，就必须使用merge_slashes_off;语法:merge_slashes [on/off]默认值: merge_slashes on环境: http，server

13、请解释ngx_http_upstream_module的作用是什么?

ngx_http_upstream_module用于定义可通过fastcgi传递、proxy传递、uwsgi传递、memcached传递和scgi传递指令来引用的服务器组。

14、请解释什么是C10K问题?C10K问题是指无法同时处理大量客户端(10,000)的网络套接字。

15、请陈述stub_status和sub_filter指令的作用是什么?

1）Stub_status指令：该指令用于了解Nginx当前状态的当前状态，如当前的活动连接，接受和处理当前读/写/等待连接的总数   2）Sub_filter指令：它用于搜索和替换响应中的内容，并快速修复陈旧的数据

16、解释Nginx是否支持将请求压缩到上游?

您可以使用Nginx模块gunzip将请求压缩到上游。gunzip模块是一个过滤器，它可以对不支持“gzip”编码方法的客户机或服务器使用“内容编码:gzip”来解压缩响应。

17、解释如何在Nginx中获得当前的时间?要获得Nginx的当前时间，必须使用SSI模块、$date_gmt和$date_local的变量。Proxy_set_header THE-TIME $date_gmt;

18、用Nginx服务器解释-s的目的是什么?用于运行Nginx -s参数的可执行文件。

19、解释如何在Nginx服务器上添加模块?在编译过程中，必须选择Nginx模块，因为Nginx不支持模块的运行时间选择。

20、什么是反向代理和正向代理?

正向代理：被代理的是客户端，比如通过XX代理访问国外的某些网站，实际上客户端没有权限访问国外的网站，客户端请求XX代理服务器，XX代理服务器访问国外网站，将国外网站返回的内容传给真正的用户。用户对于服务器是隐藏的，服务器并不知道真实的用户。

反向代理：被代理的是服务器，也就是客户端访问了一个所谓的服务器，服务器会将请求转发给后台真实的服务器，真实的服务器做出响应，通过代理服务器将结果返给客户端。服务器对于用户来说是隐藏的，用户不知道真实的服务器是哪个。

关于正向代理和反向代理，听起来比较绕，仔细理解，体会也不难明白到底是什么意思。

用nginx做实现服务的高可用，nginx本身可能成为单点，遇见的两种解决方案，一种是公司搭建自己的DNS，将请求解析到不同的NGINX，另一只是配合keepalive实现服务的存活检测。
Fastdfs:

简单介绍一下FastDFS？

1.开源的分布式文件系统，主要对文件进行存储、同步、上传、下载，有自己的容灾备份、负载均衡、线性扩容机制；

2.FastDFS架构主要包含Tracker（跟踪） server和Storage（组，卷） server。客户端请求Tracker server进行文件上传、下载的时候，通过Tracker server调度最终由Storage server完成文件上传和下载。

3.Tracker server：跟踪器或者调度器，主要起负载均衡和调度作用。通过Tracker server在文件上传时可以根据一些策略找到Storage server提供文件上传服务。

Storage server：存储服务器，作用主要是文件存储，完成文件管理的所有功能。客户端上传的文件主要保存在Storage server上，Storage server没有实现自己的文件系统而是利用操作系统的文件系统去管理文件。

存储服务器采用了分组/分卷的组织方式。

整个系统由一个组或者多个组组成；

组与组之间的文件是相互独立的；

所有组的文件容量累加就是整个存储系统的文件容量；

一个组可以由多台存储服务器组成，一个组下的存储服务器中的文件都是相同的，组中的多台存储服务器起到了冗余备份和负载均衡的作用；

在组内增加服务器时，如果需要同步数据，则由系统本身完成，同步完成之后，系统自动将新增的服务器切换到线上提供使用；

当存储空间不足或者耗尽时，可以动态的添加组。只需要增加一台服务器，并为他们配置一个新的组，即扩大了存储系统的容量。

我们在项目中主要使用fastdfs来存储整个项目的图片。

为什么要使用FastDFS作为你们的图片服务器？

首先基于fastDFS的特点：存储空间可扩展、提供了统一的访问方式、访问效率高、容灾性好  等特点，再结合我们项目中图片的容量大、并发大等特点，因此我们选择了FastDFS作为我们的图片服务器；

Nginx也可以作为一台图片服务器来使用，因为nginx可以作为一台http服务器来使用，作为网页静态服务器，通过location标签配置；在公司中有的时候也用ftp作为图片服务器来使用。

FastDFS中文件上传下载的具体流程？

 

客户端上传文件后生成一个file_id，返回给客户端，客户端利用这个file_id结合ip地址，生成一个完成图片的url，保存在数据库中。生成的那个file_id用于以后访问该文件的索引信息。

FastDFS文件下载的流程

 

ActiveMQ:

什么是activemq

activeMQ是一种开源的，面向消息的中间件，用来系统之间进行通信的

activemq的原理

 原理就是生产者生产消息， 把消息发送给activemq。 Activemq 接收到消息， 然后查看有多少个消费者， 然后把消息转发给消费者， 此过程中生产者无需参与。 消费者接收到消息后做相应的处理和生产者没有任何关系

对比RabbitMQ

RabbitMQ的协议是AMQP，而ActiveMQ使用的是JMS协议。顾名思义JMS是针对Java体系的传输协议，队列两端必须有JVM，所以如果开发环境都是java的话推荐使用ActiveMQ，可以用Java的一些对象进行传递比如Map、Blob（二进制大数据）、Stream等。而AMQP通用行较强，非java环境经常使用，传输内容就是标准字符串。

另外一点就是RabbitMQ用Erlang开发，安装前要装Erlang环境，比较麻烦。ActiveMQ解压即可用不用任何安装。

对比KafKa

Kafka性能超过ActiveMQ等传统MQ工具，集群扩展性好。

弊端是：

在传输过程中可能会出现消息重复的情况，

不保证发送顺序

一些传统MQ的功能没有，比如消息的事务功能。

 所以通常用Kafka处理大数据日志。

对比Redis

其实Redis本身利用List可以实现消息队列的功能，但是功能很少，而且队列体积较大时性能会急剧下降。对于数据量不大、业务简单的场景可以使用。

如何解决消息重复问题

所谓消息重复,就是消费者接收到了重复的消息,一般来说我们对于这个问题的处理要把握下面几点,

①.消息不丢失(上面已经处理了)

②.消息不重复执行

一般来说我们可以在业务段加一张表,用来存放消息是否执行成功,每次业务事物commit之后,告知服务端,已经处理过该消息,

这样即使你消息重发了,也不会导致重复处理

大致流程如下:

        业务端的表记录已经处理消息的id,每次一个消息进来之前先判断该消息是否执行过,如果执行过就放弃,如果没有执行就开始执行消息,消息执行完成之后存入这个消息的id

关于事务控制

获取session链接的时候 设置参数 默认不开启

 

持久化与非持久化

通过producer.setDeliveryMode(DeliveryMode.PERSISTENT) 进行设置

持久化的好处就是当activemq宕机的话，消息队列中的消息不会丢失。非持久化会丢失。但是会消耗一定的性能。