Java面试题之中间件

消息中间件&RabbitMQ

1.为什么要使用MQ

核心：解耦,异步,削峰

1）解耦：A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃......A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，很多系统都需要 A 系统将这个数据发送过来。如果使用MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。

就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用 MQ 给它异步化解耦。

2）异步：A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 +450 + 200 = 953ms，接近 1s，用户感觉搞个什么东西，慢死了慢死了。用户通过浏览器发起请求。如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms。

3）削峰：减少高峰时期对服务器压力。

2.MQ有什么优缺点

优点上面已经说了，就是在特殊场景下有其对应的好处，解耦、异步、削峰。

缺点有以下几个：

系统可用性降低

系统引入的外部依赖越多，越容易挂掉。万一 MQ 挂了，MQ 一挂，整套系统崩溃，你不就完了？

系统复杂度提高

硬生生加个 MQ 进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？问题一大堆。

一致性问题

A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了。

3.Kafka、ActiveMQ、RabbitMQ，RocketMQ 都有什么区别？

对于吞吐量来说kafka和RocketMQ支撑高吞吐，ActiveMQ和RabbitMQ比他们低一个数量级。对于延迟量来说RabbitMQ是最低的。

1.从社区活跃度

按照目前网络上的资料，RabbitMQ 、activeM 、ZeroMQ 三者中，综合来看，RabbitMQ 是首选。

2.持久化消息比较

ActiveMq 和RabbitMq 都支持。持久化消息主要是指我们机器在不可抗力因素等情况下挂掉了，消息不会丢失的机制。

3.综合技术实现

可靠性、灵活的路由、集群、事务、高可用的队列、消息排序、问题追踪、可视化管理工具、插件系统等等。

RabbitMq / Kafka 最好，ActiveMq 次之，ZeroMq 最差。当然ZeroMq 也可以做到，不过自己必须手动写代码实现，代码量不小。尤其是可靠性中的：持久性、投递确认、发布者证实和高可用性。

4.高并发

毋庸置疑，RabbitMQ 最高，原因是它的实现语言是天生具备高并发高可用的erlang 语言。

5.比较关注的比较， RabbitMQ 和 Kafka

RabbitMq 比Kafka 成熟，在可用性上，稳定性上，可靠性上， RabbitMq 胜于 Kafka （理论上）。

另外，Kafka 的定位主要在日志等方面，因为Kafka 设计的初衷就是处理日志的，可以看做是一个日志（消息）系统一个重要组件，针对性很强，所以如果业务方面还是建议选择 RabbitMq 。

还有就是，Kafka 的性能（吞吐量、TPS ）比RabbitMq 要高出来很多。

4.如何保证高可用的？

RabbitMQ 是比较有代表性的，因为是基于主从（非分布式）做高可用性的，我们就以 RabbitMQ为例子讲解第一种 MQ 的高可用性怎么实现。

RabbitMQ 有三种模式：单机模式、普通集群模式、镜像集群模式。

单机模式，就是 Demo 级别的，一般就是你本地启动了玩玩儿的?，没人生产用单机模式

普通集群模式，意思就是在多台机器上启动多个 RabbitMQ 实例，每个机器启动一个。你创建的queue，只会放在一个 RabbitMQ 实例上，但是每个实例都同步 queue 的元数据（元数据可以认为是 queue 的一些配置信息，通过元数据，可以找到 queue 所在实例）。你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从 queue 所在实例上拉取数据过来。这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个 queue 的读写操作。

镜像集群模式：这种模式，才是所谓的 RabbitMQ 的高可用模式。跟普通集群模式不一样的是，在镜像集群模式下，你创建的 queue，无论元数据还是 queue 里的消息都会存在于多个实例上，就是说，每个 RabbitMQ 节点都有这个 queue 的一个完整镜像，包含 queue 的全部数据的意思。然后每次你写消息到 queue 的时候，都会自动把消息同步到多个实例的 queue 上。RabbitMQ 有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候是可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。这样的话，好处在于，你任何一个机器宕机了，没事儿，其它机器（节点）还包含了这个 queue 的完整数据，别的 consumer 都可以到其它节点上去消费数据。坏处在于，第一，这个性能开销也太大了吧，消息需要同步到所有机器上，导致网络带宽压力和消耗很重！RabbitMQ 一个 queue 的数据都是放在一个节点里的，镜像集群下，也是每个节点都放这个 queue 的完整数据。

Kafka 一个最基本的架构认识：由多个 broker 组成，每个 broker 是一个节点；你创建一个topic，这个 topic 可以划分为多个 partition，每个 partition 可以存在于不同的 broker 上，每个partition 就放一部分数据。这就是天然的分布式消息队列，就是说一个 topic 的数据，是分散放在多个机器上的，每个机器就放一部分数据。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，那么此时会从 follower 中重新选举一个新的 leader 出来，大家继续读写那个新的 leader 即可。这就有所谓的高可用性了。写数据的时候，生产者就写 leader，然后 leader 将数据落地写本地磁盘，接着其他 follower 自己主动从 leader 来 pull 数据。一旦所有 follower 同步好数据了，就会发送ack 给 leader，leader 收到所有 follower 的 ack 之后，就会返回写成功的消息给生产者。（当然，这只是其中一种模式，还可以适当调整这个行为）消费的时候，只会从 leader 去读，但是只有当一个消息已经被所有 follower 都同步成功返回 ack 的时候，这个消息才会被消费者读到。

5.如何保证消息的可靠传输？如果消息丢了怎么办

数据的丢失问题，可能出现在生产者、MQ、消费者中

生产者丢失：生产者将数据发送到 RabbitMQ 的时候，可能数据就在半路给搞丢了，因为网络问题啥的，都有可能。此时可以选择用 RabbitMQ 提供的事务功能，就是生产者发送数据之前开启RabbitMQ 事务channel.txSelect，然后发送消息，如果消息没有成功被 RabbitMQ 接收到，那么生产者会收到异常报错，此时就可以回滚事务channel.txRollback，然后重试发送消息；如果收到了消息，那么可以提交事务channel.txCommit。吞吐量会下来，因为太耗性能。所以一般来说，如果你要确保说写 RabbitMQ 的消息别丢，可以开启confifirm模式，在生产者那里设置开启confifirm模式之后，你每次写的消息都会分配一个唯一的 id，然后如果写入了 RabbitMQ 中，RabbitMQ 会给你回传一个ack消息，告诉你说这个消息 ok 了。如果 RabbitMQ 没能处理这个消息，会回调你一个nack接口，告诉你这个消息接收失败，你可以重试。而且你可以结合这个机制自己在内存里维护每个消息 id 的状态，如果超过一定时间还没接收到这个消息的回调，那么你可以重发。事务机制和cnofifirm机制最大的不同在于，事务机制是同步的，你提交一个事务之后会阻塞在那儿，但是confifirm机制是异步的，你发送个消息之后就可以发送下一个消息，然后那个消息RabbitMQ 接收了之后会异步回调你一个接口通知你这个消息接收到了。所以一般在生产者这块避免数据丢失，都是用confifirm机制的。

MQ中丢失：就是 RabbitMQ 自己弄丢了数据，这个你必须开启 RabbitMQ 的持久化，就是消息写入之后会持久化到磁盘，哪怕是 RabbitMQ 自己挂了，恢复之后会自动读取之前存储的数据，一般数据不会丢。设置持久化有两个步骤：创建 queue 的时候将其设置为持久化，这样就可以保证RabbitMQ 持久化 queue 的元数据，但是不会持久化 queue 里的数据。第二个是发送消息的时候将消息的 deliveryMode 设置为 2，就是将消息设置为持久化的，此时 RabbitMQ 就会将消息持久化到磁盘上去。必须要同时设置这两个持久化才行，RabbitMQ 哪怕是挂了，再次重启，也会从磁盘上重启恢复 queue，恢复这个 queue 里的数据。持久化可以跟生产者那边的confifirm机制配合起来，只有消息被持久化到磁盘之后，才会通知生产者ack了，所以哪怕是在持久化到磁盘之前，RabbitMQ 挂了，数据丢了，生产者收不到ack，你也是可以自己重发的。注意，哪怕是你给RabbitMQ 开启了持久化机制，也有一种可能，就是这个消息写到了RabbitMQ 中，但是还没来得及持久化到磁盘上，结果不巧，此时 RabbitMQ 挂了，就会导致内存里的一点点数据丢失。

消费端丢失：你消费的时候，刚消费到，还没处理，结果进程挂了，比如重启了，那么就尴尬了，RabbitMQ 认为你都消费了，这数据就丢了。这个时候得用 RabbitMQ 提供的ack机制，简单来说，就是你关闭 RabbitMQ 的自动ack，可以通过一个 api 来调用就行，然后每次你自己代码里确保处理完的时候，再在程序里ack一把。这样的话，如果你还没处理完，不就没有ack？那

RabbitMQ 就认为你还没处理完，这个时候 RabbitMQ 会把这个消费分配给别的 consumer 去处理，消息是不会丢的。

 

6.如何保证消息的顺序性

先看看顺序会错乱的场景：RabbitMQ：一个 queue，多个 consumer，这不明显乱了；

 

解决：

 

7.如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？

消息积压处理办法：

临时紧急扩容：先修复 consumer 的问题，确保其恢复消费速度，然后将现有 cnosumer 都停掉。新建一个topic，partition 是原来的 10 倍，临时建立好原先 10 倍的 queue 数量。然后写一个临时的分发数据的 consumer 程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的 10 倍数量的 queue。接着临时征用 10 倍的机器来部署 consumer，每一批 consumer 消费一个临时 queue 的数据。这种做法相当于是临时将 queue 资源和 consumer 资源扩大 10 倍，以正常的 10 倍速度来消费数据。等快速消费完积压数据之后，得恢复原先部署的架构，重新用原先的 consumer 机器来消费消息。

MQ中消息失效：假设你用的是 RabbitMQ，

RabbtiMQ 是可以设置过期时间的，也就是 TTL。如果消息在 queue 中积压超过一定的时间就会被RabbitMQ 给清理掉，这个数据就没了。那这就是第二个坑了。这就不是说数据会大量积压在 mq里，而是大量的数据会直接搞丢。我们可以采取一个方案，就是批量重导，这个我们之前线上也有类似的场景干过。就是大量积压的时候，我们当时就直接丢弃数据了，然后等过了高峰期以后，比如大家一起喝咖啡熬夜到晚上12点以后，用户都睡觉了。这个时候我们就开始写程序，将丢失的那批数据，写个临时程序，一点一点的查出来，然后重新灌入 mq 里面去，把白天丢的数据给他补回来。也只能是这样了。假设 1 万个订单积压在 mq 里面，没有处理，其中 1000 个订单都丢了，你只能手动写程序把那 1000 个订单给查出来，手动发到 mq 里去再补一次。

mq消息队列块满了：如果消息积压在 mq 里，你很长时间都没有处理掉，此时导致 mq 都快写满了，咋办？这个还有别的办法吗？没有，谁让你第一个方案执行的太慢了，你临时写程序，接入数据来消费，消费一个丢弃一个，都不要了，快速消费掉所有的消息。然后走第二个方案，到了晚上再补数据吧。

8.让你来设计一个消息队列，你会怎么设计

比如说这个消息队列系统，我们从以下几个角度来考虑一下：

首先这个 mq 得支持可伸缩性吧，就是需要的时候快速扩容，就可以增加吞吐量和容量，那怎么搞？设计个分布式的系统呗，参照一下 kafka 的设计理念，broker -> topic -> partition，每个partition 放一个机器，就存一部分数据。如果现在资源不够了，简单啊，给 topic 增加 partition，

然后做数据迁移，增加机器，不就可以存放更多数据，提供更高的吞吐量了？

其次你得考虑一下这个 mq 的数据要不要落地磁盘吧？那肯定要了，落磁盘才能保证别进程挂了数据就丢了。那落磁盘的时候怎么落啊？顺序写，这样就没有磁盘随机读写的寻址开销，磁盘顺序读写的性能是很高的，这就是 kafka 的思路。

其次你考虑一下你的 mq 的可用性啊？这个事儿，具体参考之前可用性那个环节讲解的 kafka 的高可用保障机制。多副本 -> leader & follower -> broker 挂了重新选举 leader 即可对外服务。

能不能支持数据 0 丢失啊？可以的，参考我们之前说的那个 kafka 数据零丢失方案。

Zookeeper篇

1.说说 Zookeeper是什么？

直译：从名字上直译就是动物管理员，动物指的是 Hadoop 一类的分布式软件，管理员三个字体现了 ZooKeeper 的特点：维护、协调、管理、监控。

简述：有些软件你想做成集群或者分布式，你可以用 ZooKeeper 帮你来辅助实现。

特点：

最终一致性：客户端看到的数据最终是一致的。

可靠性：服务器保存了消息，那么它就一直都存在。

实时性：ZooKeeper 不能保证两个客户端同时得到刚更新的数据。

独立性（等待无关）：不同客户端直接互不影响。

原子性：更新要不成功要不失败，没有第三个状态。

注意：回答面试题，切忌只是简单一句话回答，可以将你对概念的理解，特点等多个方面描述一下，哪怕你自己认为不完全切中题意的也可以说说，面试官不喜欢会打断你的，你的目的是让面试官认为你是好沟通的。当然了，如果不会可别装作会，说太多不专业的想法。

2.ZooKeeper 有哪些应用场景？

数据发布与订阅

发布与订阅即所谓的配置管理，顾名思义就是将数据发布到ZooKeeper节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，地址列表等就非常适合使用。数据发布/订阅的一个常见的场景是配置中心，发布者把数据发布到 ZooKeeper 的一个或一系列的节点上，供订阅者进行数据订阅，达到动态获取数据的目的。

配置信息一般有几个特点:

1. 数据量小的KV

2. 数据内容在运行时会发生动态变化

3. 集群机器共享，配置一致

 

ZooKeeper 采用的是推拉结合的方式。

1. 推: 服务端会推给注册了监控节点的客户端 Wathcer 事件通知

2. 拉: 客户端获得通知后，然后主动到服务端拉取最新的数据

命名服务

作为分布式命名服务，命名服务是指通过指定的名字来获取资源或者服务的地址，利用ZooKeeper创建一个全局的路径，这个路径就可以作为一个名字，指向集群中的集群，提供的服务的地址，或者一个远程的对象等等。

统一命名服务的命名结构图如下所示：

 

1、在分布式环境下，经常需要对应用/服务进行统一命名，便于识别不同服务。

类似于域名与IP之间对应关系，IP不容易记住，而域名容易记住。

通过名称来获取资源或服务的地址，提供者等信息。

2、按照层次结构组织服务/应用名称。

可将服务名称以及地址信息写到ZooKeeper上，客户端通过ZooKeeper获取可用服务列表类。

配置管理

程序分布式的部署在不同的机器上，将程序的配置信息放在ZooKeeper的znode下，当有配置发生改变时，也就是znode发生变化时，可以通过改变zk中某个目录节点的内容，利用watch通知给各个客户端 从而更改配置。

ZooKeeper配置管理结构图如下所示：

 

1、分布式环境下，配置文件管理和同步是一个常见问题。一个集群中，所有节点的配置信息是一致的，比如 Hadoop 集群。对配置文件修改后，希望能够快速同步到各个节点上。

2、配置管理可交由ZooKeeper实现。

可将配置信息写入ZooKeeper上的一个Znode。

各个节点监听这个Znode。

一旦Znode中的数据被修改，ZooKeeper将通知各个节点。

集群管理

所谓集群管理就是：是否有机器退出和加入、选举master。

集群管理主要指集群监控和集群控制两个方面。前者侧重于集群运行时的状态的收集，后者则是对集群进行操作与控制。开发和运维中，面对集群，经常有如下需求:

1. 希望知道集群中究竟有多少机器在工作

2. 对集群中的每台机器的运行时状态进行数据收集

3. 对集群中机器进行上下线的操作

集群管理结构图如下所示：

 

1、分布式环境中，实时掌握每个节点的状态是必要的，可根据节点实时状态做出一些调整。

2、可交由ZooKeeper实现。

可将节点信息写入ZooKeeper上的一个Znode。

监听这个Znode可获取它的实时状态变化。

3、典型应用Hbase中Master状态监控与选举。

利用ZooKeeper的强一致性，能够保证在分布式高并发情况下节点创建的全局唯一性，即：同时有多个客户端请求创建 /currentMaster 节点，最终一定只有一个客户端请求能够创建成功

分布式通知与协调

1、分布式环境中，经常存在一个服务需要知道它所管理的子服务的状态。

a）NameNode需知道各个Datanode的状态。

b）JobTracker需知道各个TaskTracker的状态。

2、心跳检测机制可通过ZooKeeper来实现。

3、信息推送可由ZooKeeper来实现，ZooKeeper相当于一个发布/订阅系统。

分布式锁

处于不同节点上不同的服务，它们可能需要顺序的访问一些资源，这里需要一把分布式的锁。

分布式锁具有以下特性：写锁、读锁、时序锁。

写锁：在zk上创建的一个临时的无编号的节点。由于是无序编号，在创建时不会自动编号，导致只能客户端有一个客户端得到锁，然后进行写入。

读锁：在zk上创建一个临时的有编号的节点，这样即使下次有客户端加入是同时创建相同的节点时，他也会自动编号，也可以获得锁对象，然后对其进行读取。

时序锁：在zk上创建的一个临时的有编号的节点根据编号的大小控制锁。

分布式队列

分布式队列分为两种：

1、当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达，这种是同步队列。

a）一个job由多个task组成，只有所有任务完成后，job才运行完成。

b）可为job创建一个/job目录，然后在该目录下，为每个完成的task创建一个临时的Znode，一旦临时节点数目达到task总数，则表明job运行完成。

2、队列按照FIFO方式进行入队和出队操作，例如实现生产者和消费者模型。

3.说说Zookeeper的工作原理？

Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们 分别是恢复模式（选主）和广播模式（同步）。

Zab协议 的全称是 Zookeeper Atomic Broadcast** （Zookeeper原子广播）。Zookeeper 是通过Zab 协议来保证分布式事务的最终一致性。Zab协议要求每个 Leader 都要经历三个阶段：发现，同步，广播。

当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加 上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一 个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。

epoch：可以理解为皇帝的年号，当新的皇帝leader产生后，将有一个新的epoch年号。

每个Server在工作过程中有三种状态：

LOOKING：当前Server不知道leader是谁，正在搜寻。

LEADING：当前Server即为选举出来的leader。

FOLLOWING：leader已经选举出来，当前Server与之同步。

4.请描述一下 Zookeeper 的通知机制是什么？

Zookeeper 允许客户端向服务端的某个 znode 注册一个 Watcher 监听，当服务端的一些指定事件触发了这个 Watcher ，服务端会向指定客户端发送一个事件通知来实现分布式的通知功能，然后客户端根据 Watcher 通知状态和事件类型做出业务上的改变。

大致分为三个步骤：

客户端注册 Watcher

1、调用 getData、getChildren、exist 三个 API ，传入Watcher 对象。 2、标记请求request ，封装 Watcher 到 WatchRegistration 。

3、封装成 Packet 对象，发服务端发送request 。

4、收到服务端响应后，将 Watcher 注册到 ZKWatcherManager 中进行管理。

5、请求返回，完成注册。

服务端处理 Watcher

1、服务端接收 Watcher 并存储。 2、Watcher 触发 3、调用 process 方法来触发 Watcher 。

客户端回调 Watcher

1，客户端 SendThread 线程接收事件通知，交由 EventThread 线程回调Watcher 。

2，客户端的 Watcher 机制同样是一次性的，一旦被触发后，该 Watcher 就失效了。

client 端会对某个 znode 建立一个 watcher 事件，当该 znode 发生变化时，这些 client 会收到 zk 的通知，然后 client 可以根据 znode 变化来做出业务上的改变等。

5.Zookeeper对节点的watch 监听通知是永久的吗？

不是，一次性的。无论是服务端还是客户端，一旦一个 Watcher 被触发， Zookeeper 都会将其从相应的存储中移除。这样的设计有效的减轻了服务端的压力，不然对于更新非常频繁的节点，服务端会不断的向客户端发送事件通知，无论对于网络还是服务端的压力都非常大。

6.Zookeeper 集群中有哪些角色？

 

在一个集群中，最少需要 3 台。或者保证 2N + 1 台，即奇数。为什么保证奇数？主要是为了选举算法。

7.Zookeeper 集群中Server有哪些工作状态？

LOOKING

寻找 Leader 状态；当服务器处于该状态时，它会认为当前集群中没有 Leader ，因此需要进入Leader 选举状态

FOLLOWING

跟随者状态；表明当前服务器角色是 Follower

LEADING

领导者状态；表明当前服务器角色是 Leader

OBSERVING

观察者状态；表明当前服务器角色是 Observer

8.Zookeeper 集群中是怎样选举leader的？

当Leader崩溃了，或者失去了大多数的Follower，这时候 Zookeeper 就进入恢复模式，恢复模式需要重新选举出一个新的Leader，让所有的Server都恢复到一个状态LOOKING 。

Zookeeper 有两种选举算法：基于 basic paxos 实现和基于 fast paxos 实现。默认为 fast paxos

9.Zookeeper 是如何保证事务的顺序一致性的呢？

Zookeeper 采用了递增的事务 id 来识别，所有的 proposal （提议）都在被提出的时候加上了zxid 。zxid 实际上是一个 64 位数字。

高 32 位是 epoch 用来标识 Leader 是否发生了改变，如果有新的 Leader 产生出来， epoch 会自增。低 32 位用来递增计数。当新产生的 proposal 的时候，会依据数据库的两阶段过程，首先会向其他的 Server 发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就会开始执行。

10.ZooKeeper 集群中个服务器之间是怎样通信的？

Leader 服务器会和每一个 Follower/Observer 服务器都建立 TCP 连接，同时为每个Follower/Observer 都创建一个叫做 LearnerHandler 的实体。

LearnerHandler 主要负责 Leader 和 Follower/Observer 之间的网络通讯，包括数据同步，请求转发和 proposal 提议的投票等。

Leader 服务器保存了所有 Follower/Observer 的 LearnerHandler 。

11.ZooKeeper 分布式锁怎么实现的？

如果有客户端1、客户端2等N个客户端争抢一个 Zookeeper 分布式锁。大致如下：

1. 大家都是上来直接创建一个锁节点下的一个接一个的临时有序节点

2. 如果自己不是第一个节点，就对自己上一个节点加监听器

3. 只要上一个节点释放锁，自己就排到前面去了，相当于是一个排队机制。而且用临时顺序节点的另外一个用意就是，如果某个客户端创建临时顺序节点之后，不小心自己宕机了也没关系， Zookeeper 感知到那个客户端宕机，会自动删除对应的临时顺序节点，相当于自动释放锁，或者是自动取消自己的排队。

本地锁，可以用 JDK 实现，但是分布式锁就必须要用到分布式的组件。比如 ZooKeeper、Redis。

网上代码一大段，面试一般也不要写，我这说一些关键点。

几个需要注意的地方如下。

死锁问题：锁不能因为意外就变成死锁，所以要用 ZK 的临时节点，客户端连接失效了，锁就自动释放了。

锁等待问题：锁有排队的需求，所以要 ZK 的顺序节点。

锁管理问题：一个使用使用释放了锁，需要通知其他使用者，所以需要用到监听。

监听的羊群效应：比如有 1000 个锁竞争者，锁释放了，1000 个竞争者就得到了通知，然后判断，最终序号最小的那个拿到了锁。其它 999 个竞争者重新注册监听。这就是羊群效应，出点事，就会惊动整个羊群。应该每个竞争者只监听自己前面的那个节点。比如 2 号释放了锁，那么只有 3 号得到了通知。

12.了解Zookeeper的系统架构吗？

ZooKeeper 的架构图中我们需要了解和掌握的主要有：

 

（1）ZooKeeper分为服务器端（Server）和客户端（Client），客户端可以连接到整个ZooKeeper服务的任意服务器上（除非 leaderServes 参数被显式设置， leader 不允许接受客户端连接）。

（2）客户端使用并维护一个 TCP 连接，通过这个连接发送请求、接受响应、获取观察的事件以及发送心跳。如果这个 TCP 连接中断，客户端将自动尝试连接到另外的 ZooKeeper服务器。客户端第一次连接到 ZooKeeper服务时，接受这个连接的 ZooKeeper服务器会为这个客户端建立一个会话。当这个客户端连接到另外的服务器时，这个会话会被新的服务器重新建立。

（3）上图中每一个Server代表一个安装Zookeeper服务的机器，即是整个提供Zookeeper服务的集群（或者是由伪集群组成）；

（4）组成ZooKeeper服务的服务器必须彼此了解。它们维护一个内存中的状态图像，以及持久存储中的事务日志和快照，只要大多数服务器可用，ZooKeeper服务就可用；（5）ZooKeeper 启动时，将从实例中选举一个 leader，Leader 负责处理数据更新等操作，一个更新操作成功的标志是当且仅当大多数Server在内存中成功修改数据。每个Server 在内存中存储了一份数据。

（6）Zookeeper是可以集群复制的，集群间通过Zab协议（Zookeeper Atomic Broadcast）来保持数据的一致性；

（7）Zab协议包含两个阶段：leader election阶段和Atomic Brodcast阶段。

a) 集群中将选举出一个leader，其他的机器则称为follower，所有的写操作都被传送给leader，并通过brodcast将所有的更新告诉给follower。

b) 当leader崩溃或者leader失去大多数的follower时，需要重新选举出一个新的leader，让所有的服务器都恢复到一个正确的状态。

c) 当leader被选举出来，且大多数服务器完成了 和leader的状态同步后，leadder election 的过程就结束了，就将会进入到Atomic brodcast的过程。

d) Atomic Brodcast同步leader和follower之间的信息，保证leader和follower具有形同的系统状态。

13.讲解一下 ZooKeeper 的持久化机制

什么是持久化？

• 数据，存到磁盘或者文件当中。
• 机器重启后，数据不会丢失。内存 -> 磁盘的映射，和序列化有些像。

ZooKeeper 的持久化：

• SnapShot 快照，记录内存中的全量数据
• TxnLog 增量事务日志，记录每一条增删改记录（查不是事务日志，不会引起数据变化）

为什么持久化这么麻烦，一个不可用吗？

快照的缺点，文件太大，而且快照文件不会是最新的数据。增量事务日志的缺点，运行时间长了，日志太多了，加载太慢。二者结合最好。

快照模式：

将 ZooKeeper 内存中以 DataTree 数据结构存储的数据定期存储到磁盘中。

由于快照文件是定期对数据的全量备份，所以快照文件中数据通常不是最新的。

见图片：

 

Tomcat篇

1、Tomcat是什么？

Tomcat 服务器Apache软件基金会项目中的一个核心项目，是一个免费开源的轻量级 Web 应用服务器，在中小型系统和并发访问用户不大的场合下被普遍使用，是开发和调试 JSP 程序的首选。

2、Tomcat类加载

Tomcat整体的类加载图

 

 

我们在这张图中看到很多类加载器，除了Jdk自带的类加载器，我们尤其关心Tomcat自身持有的类加载器。仔细一点我们很容易发现：Catalina类加载器和Shared类加载器，他们并不是父子关系，而是兄弟关系。为啥这样设计，我们得分析一下每个类加载器的用途，才能知晓。

1. Common类加载器，负责加载Tomcat和Web应用的通用类
2. Catalina类加载器，负责加载Tomcat专用的类，而这些被加载的类在Web应用中将不可见
3. Shared类加载器，负责加载Tomcat下所有的Web应用程序的类，而这些被加载的类在Tomcat容器将不可见
4. WebApp类加载器，负责加载具体的某个Web应用程序的类，而这些被加载的类在Tomcat和其他的Web应用程序都将不可见
5. Jsp类加载器，每个jsp页面一个类加载器，不同的jsp页面有不同的类加载器，方便实现jsp页面的热插拔

 

双亲委派模型：如果收到一个类加载的请求，本身不会先加载此类，而是会先将此请求委派给父类加载器去完成，每个层次都是如此，直到启动类加载器中，只有父类都没有加载此文件，那么子类才会尝试自己去加载。

双亲委派模型的好处：保证核心类库不被覆盖。如果没有使用双亲委派模型，由各个类加载器自行加载的话，如果用户自己编写了一个称为java.lang.Object的类，并放在程序的ClassPath中，那系统将会出现多个不同的Object类， Java类型体系中最基础的行为就无法保证。应用程序也将会变得一片混乱。

那么Tomcat为什么要自定义类加载器呢？

• 隔离不同应用：部署在同一个Tomcat中的不同应用A和B，例如A用了Spring2.5。B用了Spring3.5，那么这两个应用如果使用的是同一个类加载器，那么Web应用就会因为jar包覆盖而无法启动。
• 隔离服务器与不同应用：服务器需要尽可能地保证自身的安全不受部署的Web应用程序影响。一般来说，服务器所使用的类库应该与应用程序的类库互相独立。
• 性能：部署在同一服务上的两个Web应用程序所使用的Java类库可以互相共享。

Tomcat自定义了WebAppClassLoader类加载器。打破了双亲委派的机制，即如果收到类加载的请求，会尝试自己去加载，如果找不到再交给父加载器去加载，目的就是为了优先加载Web应用自己定义的类。我们知道ClassLoader默认的loadClass方法是以双亲委派的模型进行加载类的，那么Tomcat既然要打破这个规则，就要重写loadClass方法，我们可以看WebAppClassLoader类中重写的loadClass方法。

Web应用默认的类加载顺序（打破了双亲委派规则）：

1. 从本地缓存中查找是否加载过此类，如果已经加载即返回，否则继续下一步。
2. 检查 JVM 的缓存中是否已经加载，防止Web应用覆盖JRE的核心类
3. 从AppClassLoader中查找是否加载过此类，如果加载到即返回，否则继续下一步。
4. 判断是否设置了delegate属性，如果设置为true那么就按照双亲委派机制加载类
5. 默认是设置delegate是false的，那么就会先用WebAppClassLoader进行加载
6. 如果此时在WebAppClassLoader没找到类，那么就委托父类加载器(Common ClassLoader)去加载

3、Tomcat的基本架构是什么？

 

Tomcat中只有一个Server，一个Server可以有多个Service，一个Service可以有多个Connector和一个Container；

Server掌管着整个Tomcat的生死大权；

Service 是对外提供服务的；

Connector用于接受请求并将请求封装成Request和Response来具体处理；

Container用于封装和管理Servlet，以及具体处理request请求

4、Tomcat请求的处理流程

给定一个客户端访问的URL：
http://localhost:8080/TestWeb/index.jsp.详细说一下该请求的处理流程.

1. 首先是请求发送给本机8080,被在那里监听HTTP/Connector获得.
2. Connector将该请求发给它本身所在的 Service所在的Engine来处理,并等待Engine来回应.
3. Engine匹配对应的Host和Context,并将请求交给对应的Servlet
4. 构造HttpServletRequest对象和HttpServletResponse对象作为参数,调用Servlet的doGet()方法和doPost()方法.
5. Context把执行完后的HttpServletResponse对象返回给Host,再返回给Engine,Connector
6. Connector把HttpServletResponse对象返回给浏览器的Browser.

Dubbo 篇

1、Dubbo 是什么？

Dubbo 是一款高性能、轻量级的开源 RPC 框架，提供服务自动注册、自动发现等高效服务治理方案， 可以和 Spring 框架无缝集成。

2、Dubbo 的使用场景有哪些？

• 透明化的远程方法调用：就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。
• 软负载均衡及容错机制：可在内网替代 F5 等硬件负载均衡器，降低成本，减少单点。
• 服务自动注册与发现：不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

3、Dubbo 服务器注册与发现的流程？

 

服务容器Container负责启动，加载，运行服务提供者。

服务提供者Provider在启动时，向注册中心注册自己提供的服务。

服务消费者Consumer在启动时，向注册中心订阅自己所需的服务。

注册中心Registry返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

服务消费者Consumer，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

服务消费者Consumer和提供者Provider，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心Monitor。

4、Dubbo 和 Spring Cloud 有什么关系？Dubbo 和 Spring Cloud 有什么哪些区别？

Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。

而 Spring Cloud 诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托了 Spring、Spring Boot 的优势，两个框架在目标就不一致，Dubbo 定位服务治理、Spring Cloud 是打造一个分布式的生态。

Dubbo 底层是使用 Netty 这样的 NIO 框架，是基于 TCP 协议传输的，配合以 Hession 序列化完成 RPC 通信。

Spring Cloud 是基于 Http 协议 Restful 接口调用远程过程的通信，相对来说 Http 请求会有更大的报文，占的带宽也会更多。但是 Restful 相比 RPC 更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更为合适，至于注重通信速度还是方便灵活性，具体情况具体分析。

5、Dubbo集群提供了哪些负载均衡策略？

Dubbo内置了4种负载均衡策略

1. RandomLoadBalance：随机负载均衡。随机的选择一个。是Dubbo的默认负载均衡策略。
2. RoundRobinLoadBalance：轮询负载均衡。轮询选择一个。
3. LeastActiveLoadBalance：最少活跃调用数，相同活跃数的随机。每收到一个请求，活跃数加1，完成请求后则将活跃数减1。活跃调用数越小，表明该服务提供者效率越高，单位时间内可处理更多的请求。
4. ConsistentHashLoadBalance：一致性哈希负载均衡。相同参数的请求总是落在同一台机器上。

6、Dubbo的集群容错方案有哪些？

• Failover Cluster：失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。
• Failfast Cluster：快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
• Failsafe Cluster：失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
• Failback Cluster：失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
• Forking Cluster：并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks=”2″ 来设置最大并行数。
• Broadcast Cluster：广播调用所有提供者，逐个调用，任意一台报错则报错 。通常用于通知所有提供者更新缓存或日志等本地资源信息。

默认的容错方案是 Failover Cluster。

权限管理

权限管理，一般指根据系统设置的安全规则或者安全策略，用户可以访问而且只能访问自己被授权的资源，不多不少。

认证授权

权限管理包括身份认证和授权两部分，简称认证授权。对于需要访问控制的资源用户首先经过身份认证，认证通过后用户具有该资源的访问权限方可访问。

身份认证

判断一个用户是否为合法用户的处理过程。最常用的简单身份认证方式是系统通过核对用户输入的用户名和密码，看其是否与系统中存储的该用户的用户名和密码一致，来判断用户身份是否正确。对于采用指纹等系统，则出示指纹；对于硬件Key等刷卡系统，则需要刷卡。

认证关键对象

• Subject：主体
• 访问系统的用户，主体可以是用户、程序等，进行认证的都称为主体；
• Principal：身份信息
• 是主体（subject）进行身份认证的标识，标识必须具有唯一性，如用户名、手机号、邮箱地址等，一个主体可以有多个身份，但是必须有一个主身份（Primary Principal）。
• credential：凭证信息
• 是只有主体自己知道的安全信息，如密码、证书等。

授权

授权，即访问控制，控制谁能访问哪些资源。主体进行身份认证后需要分配权限方可访问系统的资源，对于某些资源没有权限是无法访问的。

授权关键对象

授权可简单理解为 who 对 what(which) 进行 How 操作：

• Who，即主体（Subject），主体需要访问系统中的资源。
• What，即资源（Resource），如系统菜单、页面、按钮、类方法、系统商品信息等。资源包括资源类型和资源实例，比如商品信息为资源类型，类型为t01的商品为资源实例，编号为001的商品信息也属于资源实例。
• How，权限/许可（Permission），规定了主体对资源的操作许可，权限离开资源是没有意义，如用户查询权限、用户添加权限、某个类方法的调用权限、编号为001用户的修改权限等，通过权限可知主体对哪些资源都有哪些操作许可。
• 权限分为粗颗粒和细颗粒，粗颗粒权限是指对资源类型的权限，细颗粒权限是对资源实例的权限。

权限模型

主体、资源、权限的数据模型表示。

• 主体（账号、密码）
• 角色（角色名称）
• 主体和角色关系（主体id、角色id）
• 权限（权限名称、资源id）
• 角色和权限关系（角色id、权限id）
• 资源（资源id、访问地址）

 

权限控制

基于角色的访问控制

RBAC基于角色的访问控制（Role-Based Access Control）是以角色为中心进行访问控制，比如：主体的角色为总经理可以查询企业运营报表，查询员工工资信息等，访问控制流程如下：

图中的判断逻辑代码可以理解为：

if(主体.hasRole("总经理角色id")){
   查询工资
}

缺点：以角色进行访问控制粒度较粗，如果上图中查询工资所需要的角色变化为总经理和部门经理，此时就需要修改判断逻辑为“判断主体的角色是否是总经理或部门经理”，系统可扩展性差。

修改代码如下：

if(主体.hasRole("总经理角色id") ||  主体.hasRole("部门经理角色id")){
   查询工资
}

基于资源的访问控制

RBAC基于资源的访问控制（Resource-Based Access Control）是以资源为中心进行访问控制，比如：主体必须具有查询工资权限才可以查询员工工资信息等，访问控制流程如下：

 

上图中的判断逻辑代码可以理解为：

if(主体.hasPermission("wage:query")){
   查询工资
}

优点：系统设计时定义好查询工资的权限标识，即使查询工资所需要的角色变化为总经理和部门经理也只需要将“查询工资信息权限”添加到“部门经理角色”的权限列表中，判断逻辑不用修改，系统可扩展性强。

基于url的访问控制

基于url拦截是企业中常用的权限管理方法，实现思路是：将系统操作的每个url配置在权限表中，将权限对应到角色，将角色分配给用户，用户访问系统功能通过Filter进行过虑，过虑器获取到用户访问的url，只要访问的url是用户分配角色中的url则放行继续访问。

粗颗粒度和细颗粒度

什么是粗颗粒度和细颗粒度

对资源类型的管理称为粗颗粒度权限管理，即只控制到菜单、按钮、方法，粗粒度的例子比如：用户具有用户管理的权限，具有导出订单明细的权限。

对资源实例的控制称为细颗粒度权限管理，即控制到数据级别的权限，比如：用户只允许修改本部门的员工信息，用户只允许导出自己创建的订单明细。

如何实现粗颗粒度和细颗粒度

• 对于粗颗粒度的权限管理可以很容易做系统架构级别的功能，即系统功能操作使用统一的粗颗粒度的权限管理。
• 对于细颗粒度的权限管理不建议做成系统架构级别的功能，因为对数据级别的控制是系统的业务需求，随着业务需求的变更业务功能变化的可能性很大，建议对数据级别的权限控制在业务层个性化开发，比如：用户只允许修改自己创建的商品信息可以在service接口添加校验实现，service接口需要传入当前操作人的标识，与商品信息创建人标识对比，不一致则不允许修改商品信息。

Shiro

Apache Shiro 是一个功能强大，使用简单的Java安全框架，它为开发人员提供一个直观而全面的认证，授权，加密及会话管理的解决方案。

Shiro能做什么呢？

• 验证用户身份
• 用户访问权限控制
• 在非 web 或 EJB 容器的环境下可以任意使用Session API
• 可以响应认证、访问控制，或者 Session 生命周期中发生的事件
• 可将一个或以上用户安全数据源数据组合成一个复合的用户 "view"(视图)
• 支持单点登录(SSO)功能
• 支持提供“Remember Me”服务，获取用户关联信息而无需登录

Shiro基本功能

Apache Shiro是一个全面的、蕴含丰富功能的安全框架。

 

Authentication（认证）, Authorization（授权）, Session Management（会话管理）, Cryptography（加密）被 Shiro 框架的开发团队称之为应用安全的四大基石。

• Authentication（认证）：身份认证/登录，验证用户是不是拥有相应的身份。
• Authorization（授权）：授权，即权限验证，验证某个已认证的用户是否拥有某个权限
• Session Management（会话管理）：会话管理，即用户登录后就是一次会话，在没有退出之前，它的所有信息都在会话中
• Cryptography（加密）：加密，保护数据的安全性，如密码加密存储到数据库，而不是明文存储。

还有其他的功能来支持和加强这些不同应用环境下安全领域的关注点。特别是对以下的功能支持：

• Web Support：Web支持，可以非常容易的集成到 web 环境。
• Caching：缓存，比如用户登录后，其用户信息、拥有的角色/权限不必每次去查，这样可以提高效率。
• Concurrency：shiro 支持多线程应用的并发验证，即如在一个线程中开启另一个线程，能把权限自动传播过去。
• Testing：提供测试支持。
• Run As：允许一个用户假装为另一个用户（如果他们允许）的身份进行访问。
• Remember Me：记住我，这个是非常常见的功能，即一次登录后，下次再来的话不用登录了。

注意：Shiro不会去维护用户、维护权限；这些需要我们自己去设计/提供，然后通过相应的接口注入给Shiro即可。

Shiro运行原理

从应用程序角度的来观察如何使用Shiro完成工作

 

• Subject：主体，任何与应用交互的用户。
• SecurityManager：相当于 SpringMVC 中的 DispatcherServlet 或者 Struts2 中的 StrutsPreparedAndExcutorFilter。它是 Shiro 的核心，所有具体的交互都通过 SecurityManager 进行控制。它管理着所有 Subject、且负责进行认证和授权、及会话、缓存的管理。
• Realm：可以有1个或多个 Realm，可以认为是安全实体数据源，即用于获取安全实体的。

我们需要实现Realms的Authentication 和 Authorization。其中 Authentication 是用来验证用户身份，Authorization 是权限验证

也就是说对于我们而言，最简单的一个Shiro应用：

• 应用代码通过Subject来进行认证和授权，而Subject又委托给SecurityManager；
• 我们需要给Shiro的SecurityManager注入Realm，从而让SecurityManager能得到合法的用户及其权限进行判断。

从以上也可以看出，Shiro不提供维护用户权限，而是通过Realm让开发人员自己注入。

Shiro内部架构

 

shiro组件如下：

1. Subject：主体，任何与应用交互的用户。
2. SecurityManager：相当于 SpringMVC 中的 DispatcherServlet 或者 Struts2 中的 StrutsPreparedAndExcutorFilter。它是 Shiro 的核心，所有具体的交互都通过 SecurityManager 进行控制。它管理着所有 Subject、且负责进行认证和授权、及会话、缓存的管理。
3. Authenticator：认证器，负责主体认证，用户可以自定义实现，自定义认证策略
4. Authrizer：授权器，或者叫访问控制器。它用来决定主体是否有权限进行相应的操作
5. Realm：可以有1个或多个 Realm，可以认为是安全实体数据源，即用于获取安全实体的。
6. SessionManager：会话管理器，管理session的生命周期（可以实现单点登录）
7. SessionDAO：数据访问对象，用于会话的 CRUD。
8. CacheManager：缓存管理器。它来管理如用户、角色、权限等的缓存的。
9. Cryptography：密码模块，Shiro 提供了一些常见的加密组件用于如密码加密/解密的。

通过上面的各个组件我们可以完成认证、授权、会话管理、加密/解密、记住我等安全相关功能。

Shiro认证授权流程

身份认证流程

 

流程如下：

1. 首先调用 Subject.login(token) 进行登录，其会自动委托给 Security Manager，调用之前必须通过 SecurityUtils.setSecurityManager() 设置；
2. SecurityManager 负责真正的身份验证逻辑；它会委托给 Authenticator 进行身份验证；
3. Authenticator 才是真正的身份验证者，Shiro API 中核心的身份认证入口点，此处可以自定义插入自己的实现；
4. Authenticator 可能会委托给相应的 AuthenticationStrategy 进行多 Realm 身份验证，默认 ModularRealmAuthenticator 会调用 AuthenticationStrategy 进行多 Realm 身份验证；
5. Authenticator 会把相应的 token 传入 Realm，从 Realm 获取身份验证信息，如果没有返回 / 抛出异常表示身份验证失败了。此处可以配置多个 Realm，将按照相应的顺序及策略进行访问。

授权流程

 

流程如下：

1. 首先调用 Subject.isPermitted*/hasRole*接口，其会委托给 SecurityManager，而 SecurityManager 接着会委托给 Authorizer；
2. Authorizer 是真正的授权者，如果我们调用如 isPermitted(“user:view”)，其首先会通过 PermissionResolver 把字符串转换成相应的 Permission 实例；
3. 在进行授权之前，Authorizer 会调用相应的 Realm 获取 Subject 相应的角色/权限用于匹配传入的角色/权限，如果有多个 Realm，会委托给 ModularRealmAuthorizer 进行循环判断，如果匹配如 isPermitted*/hasRole* 会返回 true，否则返回 false 表示授权失败。继承 AuthorizingRealm 而不是实现 Realm 接口；
4. 推荐继承 AuthorizingRealm，重写认证和授权方法：AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token)：表示获取用户认证信息；AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals)：表示根据用户身份获取授权信息。这种方式的好处是当只需要身份验证时只需要获取身份验证信息而不需要获取授权信息。

Shiro和Spring Security比较

shiro和spring security都是安全框架，都具有认证授权，加密等功能，主要区别如下：

1. Shiro 的配置和使用比较简单，Spring Security 上手复杂些
2. Spring Security 有更好的社区支持，社区资源相对比 Shiro 更加丰富
3. Shiro 依赖性低，不需要任何框架和容器，可以独立运行。Spring Security 依赖Spring容器，与Spring整合更加方便
4. Spring Security 功能比 Shiro 更加丰富些，例如安全维护方面

OAuth2 协议

什么是第三方登录

 

很多网站登录时，允许使用第三方网站的身份来进行登录，这称为“第三方登录”。比如知乎和慕课网等，可以使用微信，QQ，或微博来进行登录。一个网站想接入第三方登录，需要用到OAuth2这个协议。

什么是OAuth2

OAuth2是一个关于授权的开放网络标准，用来授权第三方应用，获取用户的数据。其最终的目的是为了给第三方应用颁发一个有时效性的令牌access_token，第三方应用根据这个access_token就可以去获取用户的相关资源，如头像，昵称，email这些信息。现在大家用的基本是2.0的版本。

协议流程

在详细介绍OAuth2协议流程之前，先来简单了解几个角色，方便后续的理解。

• Client，客户端，第三方应用，可以是浏览器、移动设备或者服务器；
• Resource Owner，资源所有者，拥有该资源的最终用户，他有访问资源的账号密码；
• Authorization Server，授权服务器，一般和资源服务器是同一家公司的应用，主要是用来处理授权，给客户端颁发令牌
• Resource Server，资源服务器，托管受保护资源的服务器
• User-agent，用户代理，一般为web浏览器，在手机上就是app

了解了上面这些角色之后，来看下OAuth2.0的运行流程是怎么样的。

+--------+                               +---------------+
|       |--(A)- Authorization Request ->|   Resource   |
|       |                               |     Owner     |
|       |<-(B)-- Authorization Grant ---|               |
|       |                               +---------------+
|       |
|       |                               +---------------+
|       |--(C)-- Authorization Grant -->| Authorization |
| Client |                               |     Server   |
|       |<-(D)----- Access Token -------|               |
|       |                               +---------------+
|       |
|       |                               +---------------+
|       |--(E)----- Access Token ------>|   Resource   |
|       |                               |     Server   |
|       |<-(F)--- Protected Resource ---|               |
+--------+                               +---------------+

(A). 客户端向用户(Resource Owner)发送一个授权请求

(B). 用户同意给客户端(Client)授权，并返回一个授权码（code）

(C). 客户端使用刚才的授权码（code）去向授权服务器(Authorization Server)授权

(D). 授权服务器校验通过后，会给客户端发放令牌(Access Token)

(E). 客户端拿着令牌(Access Token)，去向资源服务器(Resource Server)申请获取资源

(F). 资源服务器确认令牌之后，给客户端返回受保护的资源(Protected Resource)

授权方式

在OAuth2当中，定义了四种授权方式，针对不同的业务场景：

• Authorization Code（授权码模式）：正宗的OAuth2的授权模式，客户端先将用户导向授权服务器，登录后获取授权码，然后进行授权，最后根据授权码获取访问令牌；
• Implicit（简化模式）：和授权码模式相比，取消了获取授权码的过程，直接获取访问令牌；
• Resource Owner Password Credentials（密码模式）：客户端直接向用户获取用户名和密码，之后向授权服务器获取访问令牌；
• Client Credentials（客户端模式）：客户端直接通过客户端认证（比如client_id和client_secret）从授权服务器获取访问令牌。

授权码模式

OAuth2授权码模式完整流程图：

 

Netty 是什么？

Netty是一个异步事件驱动的网络应用程序框架，用于快速开发高性能通信的服务器和客户端。Netty是基于nio的，它封装了jdk的nio，让我们使用起来更加方便灵活。

Netty 高性能表现在哪些方面？Netty 的优势有哪些？

• 使用简单：封装了 NIO 的很多细节，提供了易于使用调用接口。
• 性能高，IO 线程模型：Netty 是一款基于 NIO开发的网络通信框架，对比BIO，并发性能得到了很大提高。通过与其他业界主流的 NIO 框架对比，Netty 的综合性能最优。
• 内存零拷贝：尽量减少不必要的内存拷贝，实现了更高效率的传输。
• 功能强大：预置了多种编解码功能，支持多种主流协议。支持 protobuf 等高性能序列化协议。
• 定制能力强：可以通过 ChannelHandler 对通信框架进行灵活地扩展。
• 稳定：Netty 修复了已经发现的所有 NIO 的 bug，让开发人员可以专注于业务本身。
• 社区活跃：Netty 是活跃的开源项目，版本迭代周期短，bug 修复速度快。

Netty的线程模型？

Netty通过Reactor模型基于多路复用器接收并处理用户请求，内部实现了两个线程池，boss线程池和work线程池，其中boss线程池的线程负责处理请求的accept事件，当接收到accept事件的请求时，把对应的socket封装到一个NioSocketChannel中，并交给work线程池，其中work线程池负责请求的read和write事件，由对应的Handler处理。

单线程模型：所有I/O操作都由一个线程完成，即多路复用、事件分发和处理都是在一个Reactor线程上完成的。既要接收客户端的连接请求,向服务端发起连接，又要发送/读取请求或应答/响应消息。一个NIO 线程同时处理成百上千的链路，性能上无法支撑，速度慢，若线程进入死循环，整个程序不可用，对于高负载、大并发的应用场景不合适。

多线程模型：有一个NIO 线程（Acceptor） 只负责监听服务端，接收客户端的TCP 连接请求；NIO 线程池负责网络IO 的操作，即消息的读取、解码、编码和发送；1 个NIO 线程可以同时处理N 条链路，但是1 个链路只对应1 个NIO 线程，这是为了防止发生并发操作问题。但在并发百万客户端连接或需要安全认证时，一个Acceptor 线程可能会存在性能不足问题。

主从多线程模型：Acceptor 线程用于绑定监听端口，接收客户端连接，将SocketChannel 从主线程池的Reactor 线程的多路复用器上移除，重新注册到Sub 线程池的线程上，用于处理I/O 的读写等操作，从而保证mainReactor只负责接入认证、握手等操作；

TCP 粘包/拆包的原因及解决方法？

TCP是以流的方式来处理数据，一个完整的包可能会被TCP拆分成多个包进行发送，也可能把小的封装成一个大的数据包发送。

TCP粘包/分包的原因

应用程序写入的字节大小大于套接字发送缓冲区的大小，会发生拆包现象，而应用程序写入数据小于套接字缓冲区大小，网卡将应用多次写入的数据发送到网络上，这将会发生粘包现象；

解决方法

• 消息定长：FixedLengthFrameDecoder类
• 包尾增加特殊字符分割：行分隔符类：LineBasedFrameDecoder；或自定义分隔符类 ：DelimiterBasedFrameDecoder
• 将消息分为消息头和消息体：LengthFieldBasedFrameDecoder类。分为有头部的拆包与粘包、长度字段在前且有头部的拆包与粘包、多扩展头部的拆包与粘包。

什么是 Netty 的零拷贝？

Netty 的零拷贝主要包含三个方面：

• Netty 的接收和发送 ByteBuffer 采用 DIRECT BUFFERS，使用堆外直接内存进行 Socket 读写，不需要进行字节缓冲区的二次拷贝。如果使用传统的堆内存（HEAP BUFFERS）进行 Socket 读写，JVM 会将堆内存 Buffer 拷贝一份到直接内存中，然后才写入 Socket 中，相比于堆外直接内存，消息在发送过程中多了一次缓冲区的内存拷贝。
• Netty 提供了组合 Buffer 对象，可以聚合多个 ByteBuffer 对象，用户可以像操作一个 Buffer 那样方便的对组合 Buffer 进行操作，避免了传统通过内存拷贝的方式将几个小 Buffer 合并成一个大的 Buffer。
• Netty 的文件传输采用了 transferTo 方法，它可以直接将文件缓冲区的数据发送到目标 Channel，避免了传统通过循环 write 方式导致的内存拷贝问题。

Netty常见使用场景

Netty常见的使用场景如下：

• 互联网行业 在分布式系统中，各个节点之间需要远程服务调用，高性能的RPC框架必不可少，Netty作为异步高新能的通信框架,往往作为基础通信组件被这些RPC框架使用。典型的应用有：阿里分布式服务框架Dubbo的RPC框架使用Dubbo协议进行节点间通信，Dubbo协议默认使用Netty作为基础通信组件，用于实现各进程节点之间的内部通信。
• 游戏行业 无论是手游服务端还是大型的网络游戏，Java语言得到了越来越广泛的应用。Netty作为高性能的基础通信组件，它本身提供了TCP/UDP和HTTP协议栈。非常方便定制和开发私有协议栈，账号登录服务器，地图服务器之间可以方便的通过Netty进行高性能的通信
• 大数据领域 经典的Hadoop的高性能通信和序列化组件Avro的RPC框架，默认采用Netty进行跨界点通信，它的Netty Service基于Netty框架二次封装实现

工作原理架构

初始化并启动Netty服务端过程如下：

public static void main(String[] args) {
   // 创建mainReactor
   NioEventLoopGroup boosGroup = new NioEventLoopGroup();
   // 创建工作线程组
   NioEventLoopGroup workerGroup = new NioEventLoopGroup();

   final ServerBootstrap serverBootstrap = new ServerBootstrap();
   serverBootstrap
       // 组装NioEventLoopGroup
      .group(boosGroup, workerGroup)
       // 设置channel类型为NIO类型
      .channel(NioServerSocketChannel.class)
       // 设置连接配置参数
      .option(ChannelOption.SO_BACKLOG, 1024)
      .childOption(ChannelOption.SO_KEEPALIVE, true)
      .childOption(ChannelOption.TCP_NODELAY, true)
       // 配置入站、出站事件handler
      .childHandler(new ChannelInitializer() {
           @Override
           protected void initChannel(NioSocketChannel ch) {
               // 配置入站、出站事件channel
               ch.pipeline().addLast(...);
               ch.pipeline().addLast(...);
          }
      });

   // 绑定端口
   int port = 8080;
   serverBootstrap.bind(port).addListener(future -> {
       if (future.isSuccess()) {
           System.out.println(new Date() + ": 端口[" + port + "]绑定成功!");
      } else {
           System.err.println("端口[" + port + "]绑定失败!");
      }
  });
}

• 基本过程如下：
• 1 初始化创建2个NioEventLoopGroup，其中boosGroup用于Accetpt连接建立事件并分发请求， workerGroup用于处理I/O读写事件和业务逻辑
• 2 基于ServerBootstrap(服务端启动引导类)，配置EventLoopGroup、Channel类型，连接参数、配置入站、出站事件handler
• 3 绑定端口，开始工作

结合上面的介绍的Netty Reactor模型，介绍服务端Netty的工作架构图：

 

WebSocket

为什么需要 WebSocket？

因为 HTTP 协议有一个缺陷：通信只能由客户端发起，服务器不能主动联系客户端。

举例来说，我们想了解今天的天气，只能是客户端向服务器发出请求，服务器返回查询结果。HTTP 协议做不到服务器主动向客户端推送信息。

这种单向请求的特点，注定了如果服务器有连续的状态变化，客户端要获知就非常麻烦。我们只能使用轮询：每隔一段时候，就发出一个询问，了解服务器有没有新的信息。

轮询的缺点：轮询的效率低，非常浪费资源（因为必须不停连接，或者 HTTP 连接始终打开）。因此，工程师们一直在思考，有没有更好的方法。WebSocket 就是这样发明的。

什么是WebSocket

WebSocket 协议在2008年诞生，2011年成为国际标准。所有浏览器都已经支持了。WebSocket是HTML5的一个新协议。

WebSocket最大的特点就是实现全双工通信：客户端能够实时推送消息给服务端，服务端也能够实时推送消息给客户端，属于服务器推送技术的一种。

 

其他特点包括：

（1）建立在 TCP 协议之上，服务器端的实现比较容易。

（2）与 HTTP 协议有着良好的兼容性。默认端口也是80和443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器完成。

（3）数据格式比较轻量，性能开销小，通信高效。

（4）可以发送文本，也可以发送二进制数据。

（5）没有同源限制，客户端可以与任意服务器通信。

（6）协议标识符是ws（如果加密，则为wss），服务器网址就是 URL。

WebSocket 底层原理

TCP是持久连接、全双工

TCP是持久连接，建立TCP连接是3次握手，关闭TCP连接是4次挥手。TCP连接是由通信双方（应用层）来决定什么时候关闭，其本身是一个持久连接。TCP连接可以进行全双工通信，因为双方都知道对方是谁

HTTP只能单向通信、无状态

Http协议只能单向通信的原因是：Server服务端没有保存Http客户端的信息（无状态的），想要通信的时候找不到人。而Http1.1协议新增的keep-alive Header之后，Server会保存连接，即长连接。但是每次都是http请求，一堆没用的信息（http head），浪费资源。而且本质没有变化，都需要客户端请求才能获得数据，增加了keep-alive请求头只是可以通过一条通道请求多次。

WebSocket 底层原理

WebSocket协议实现全双工通信、以及持久连接的一个前提是，它是基于TCP的。

WebSocket协议也需要通过已建立的TCP连接来传输数据。具体实现上是通过http协议建立通道，然后在此基础上用真正的WebSocket协议进行通信。

WebSocket 本质上跟 HTTP 完全不一样，只不过为了兼容性，WebSocket 的握手是以 HTTP 的形式发起的，

总结重点

WebSocket是一个网络上的应用层协议，它依赖于HTTP协议的第一次握手，握手成功后，数据就通过TCP/IP协议传输了。

WebSocket = “HTTP第1次握手” + TCP的“全双工“通信 的网络协议。

主要过程：

• 首先，通过HTTP第一次握手保证连接成功。
• 其次，再通过TCP实现浏览器与服务器全双工(full-duplex)通信。（通过不断发ping包、pang包保持心跳）

最终，使得 “服务端” 拥有 “主动” 发消息给 “客户端” 的能力。

WebSocket分为握手阶段和数据传输阶段，即进行了HTTP一次握手 + 双工的TCP连接。

1、握手阶段

首先，客户端发送消息：

GET /chat HTTP/1.1
Host: server.qishare.org
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://qishare.org
Sec-WebSocket-Version: 13

然后，服务端返回消息：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

• Sec-WebSocket-Version表明客户端所使用的协议版本
• 响应的状态码101，表示切换了协议，说明利用http建立传输层的TCP连接，之后便与http协议无关的
• Sec-WebSocket-Key是一个Base64编码值，由浏览器随机生成。是一种验证服务端支不支持websocket的算法
• Sec-Websocket-accept=base64(sha1(key)+常量)，如果返回的accept和算出来的相同，说明服务端支持
• 如果返回成功，Websocket就会回调onopen事件

2、传输阶段

WebSocket是以 frame 的形式传输数据的。比如会将一条消息分为几个frame，按照先后顺序传输出去。

这样做会有几个好处：

• 较大的数据可以分片传输，不用考虑到数据大小导致的长度标志位不足够的情况。
• 和HTTP的chunk一样，可以边生成数据边传递消息，即提高传输效率。

WebSocket协议的优缺点

优点：

• WebSocket协议一旦建议后，互相沟通所消耗的请求头是很小的
• 服务器可以主动向客户端推送消息了

缺点：

• 少部分浏览器不支持，浏览器支持的程度与方式有区别

WebSocket 应用场景

1. IM（即时通讯）

典型例子：微信、QQ等，当然，用户量如果非常大的话，仅仅依靠WebSocket肯定是不够的，各大厂应该也有自己的一些优化的方案与措施。但对于用户量不是很大的即时通讯需求，使用WebSocket是一种不错的方案。

2. 游戏（多人对战）

典型例子：王者荣耀等（应该都玩过）

3. 协同编辑（共享文档）

多人同时编辑同一份文档时，可以实时看到对方的操作。这时，就用上了WebSocket。

4. 直播/视频聊天

对音频/视频需要较高的实时性。

5. 股票/基金等金融交易平台

对于股票/基金的交易来说，每一秒的价格可能都会发生变化。

6. IoT（物联网 / 智能家居）

例如，我们的App需要实时的获取智能设备的数据与状态。这时，就需要用到WebSocket。

只要是一些对 “实时性” 要求比较高的需求，可能就会用到WebSocket。

其他

nginx请求转发策略

如果不用quartz这样的定时任务框架，怎么处理定时任务

jwt由什么组成，有什么优缺点

生成唯一id的方法