分布式锁

《林老师带你学编程》知识星球是由多个工作10年以上的一线大厂开发人员联合创建，希望通过我们的分享，帮助大家少走弯路，可以在技术的领域不断突破和发展。

🔥 具体的加入方式：

直接访问链接：https://t.zsxq.com/14F2uGap7
微信扫码下图：

为什么要使用分布式锁

在单机环境下，当存在多个线程可以同时改变某个变量（可变共享变量）时，就会出现线程安全问题。这个问题可以通过 JAVA 提供的 volatile、ReentrantLock、synchronized 以及 concurrent 并发包下一些线程安全的类等来避免。

而在多机部署环境，需要在多进程下保证线程的安全性，Java提供的这些API仅能保证在单个JVM进程内对多线程访问共享资源的线程安全，已经不满足需求了。这时候就需要使用分布式锁来保证线程安全。通过分布式锁，可以保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行。

# 分布式锁应该具备哪些条件

在分析分布式锁的三种实现方式之前，先了解一下分布式锁应该具备哪些条件：

互斥性。在任意时刻，只有一个客户端能持有锁。
不会死锁。具备锁失效机制，防止死锁。即使有客户端在持有锁的期间崩溃而没有主动解锁，也要保证后续其他客户端能加锁。
加锁和解锁必须是同一个客户端。客户端a不能将客户端b的锁解开，即不能误解锁。
高性能、高可用的获取锁与释放锁。
具备可重入特性。
具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败。

# 分布式锁的三种实现方式

基于数据库实现分布式锁；
基于缓存（Redis等）实现分布式锁；
基于Zookeeper实现分布式锁。

# 基于数据库的实现方式

悲观锁

创建一张锁表，然后通过操作该表中的数据来实现加锁和解锁。当要锁住某个方法或资源时，就向该表插入一条记录，表中设置方法名为唯一键，这样多个请求同时提交数据库时，只有一个操作可以成功，判定操作成功的线程获得该方法的锁，可以执行方法内容；想要释放锁的时候就删除这条记录，其他线程就可以继续往数据库中插入数据获取锁。

乐观锁

每次更新操作，都觉得不会存在并发冲突，只有更新失败后，才重试。

扣减余额就可以使用这种方案。

具体实现：增加个version字段，每次更新修改，都会自增加一，然后去更新余额时，把查出来的那个版本号，带上条件去更新，如果是上次那个版本号，就更新，如果不是，表示别人并发修改过了，就继续重试。

# 基于Redis的实现方式

# 简单实现

Redis 2.6.12 之前的版本中采用 setnx + expire 方式实现分布式锁，在 Redis 2.6.12 版本后 setnx 增加了过期时间参数：

SET lockKey value NX PX expire-time

所以在Redis 2.6.12 版本后，只需要使用setnx就可以实现分布式锁了。

加锁逻辑：

setnx争抢key的锁，如果已有key存在，则不作操作，过段时间继续重试，保证只有一个客户端能持有锁。
value设置为 requestId（可以使用机器ip拼接当前线程名称），表示这把锁是哪个请求加的，在解锁的时候需要判断当前请求是否持有锁，防止误解锁。比如客户端A加锁，在执行解锁之前，锁过期了，此时客户端B尝试加锁成功，然后客户端A再执行del()方法，则将客户端B的锁给解除了。
再用expire给锁加一个过期时间，防止异常导致锁没有释放。

解锁逻辑：

首先获取锁对应的value值，检查是否与requestId相等，如果相等则删除锁。使用lua脚本实现原子操作，保证线程安全。

下面我们通过Jedis（基于java语言的redis客户端）来演示分布式锁的实现。

Jedis实现分布式锁

查看更多

RPC远程调用介绍

🔥 具体的加入方式：

直接访问链接：https://t.zsxq.com/14F2uGap7
微信扫码下图：

RPC简介

RPC，英文全名remote procedure call，即远程过程调用。就是说一个应用部署在A服务器上，想要调用B服务器上应用提供的方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。

可以这么说，RPC就是要像调用本地的函数一样去调远程函数。

RPC是一个完整的远程调用方案，它通常包括通信协议和序列化协议。

其中，通信协议包含http协议（如gRPC使用http2）、自定义报文的tcp协议（如dubbo）。序列化协议包含基于文本编码的xml、json，基于二进制编码的protobuf、hessian等。

protobuf 即 Protocol Buffers，是一种轻便高效的结构化数据存储格式，与语言、平台无关，可扩展可序列化。protobuf 性能和效率大幅度优于 JSON、XML 等其他的结构化数据格式。protobuf 是以二进制方式存储，占用空间小，但也带来了可读性差的缺点（二进制协议，因为不可读而难以调试，不好定位问题）。
Protobuf序列化协议相比JSON有什么优点？
1：序列化后体积相比Json和XML很小，适合网络传输
2：支持跨平台多语言
3：序列化反序列化速度很快，快于Json的处理速速

一个完整的RPC过程，都可以用下面这张图来描述：

stub说的都是“一小块代码”，通常是有个caller要调用callee的时候，中间需要一些特殊处理的逻辑，就会用这种“小块代码”去做。

服务消费端（client）以本地调用的方式调用远程服务；
客户端 Stub（client stub）接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体（序列化）：RpcRequest；
客户端 Stub（client stub）找到远程服务的地址，并将消息发送到服务提供端；
服务端 Stub（桩）收到消息将消息反序列化为Java对象: RpcRequest；
服务端 Stub（桩）根据RpcRequest中的类、方法、方法参数等信息调用本地的方法；
服务端 Stub（桩）得到方法执行结果并将组装成能够进行网络传输的消息体：RpcResponse（序列化）发送至消费方；
客户端 Stub（client stub）接收到消息并将消息反序列化为Java对象:RpcResponse ，这样也就得到了最终结果。

# RPC 解决了什么问题？

让分布式或者微服务系统中不同服务之间的调用像本地调用一样简单。

# 常见的 RPC 框架有哪些?

Dubbo: Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。目前 Dubbo 已经成为 Spring Cloud Alibaba 中的官方组件。
gRPC ：基于HTTP2。gRPC是可以在任何环境中运行的现代开源高性能RPC框架。它可以通过可插拔的支持来有效地连接数据中心内和跨数据中心的服务，以实现负载平衡，跟踪，运行状况检查和身份验证。它也适用于分布式计算的最后一英里，以将设备，移动应用程序和浏览器连接到后端服务。
Hessian： Hessian是一个轻量级的remoting on http工具，使用简单的方法提供了RMI的功能。采用的是二进制RPC协议，因为采用的是二进制协议，所以它很适合于发送二进制数据。
Thrift： Apache Thrift是Facebook开源的跨语言的RPC通信框架，目前已经捐献给Apache基金会管理，由于其跨语言特性和出色的性能，在很多互联网公司得到应用，有能力的公司甚至会基于thrift研发一套分布式服务框架，增加诸如服务注册、服务发现等功能。

# 有了HTTP ，为啥还要用RPC进行服务调用?

首先，RPC是一个完整的远程调用方案，它通常包括通信协议和序列化协议。而HTTP只是一个通信协议，不是一个完整的远程调用方案。这两者不是对等的概念，用来比较不太合适。

RPC框架可以使用 HTTP协议作为传输协议或者直接使用自定义的TCP协议作为传输协议，使用不同的协议一般也是为了适应不同的场景。

HTTP+Restful，其优势很大。它可读性好，且应用广、跨语言的支持。

但是使用该方案也有其缺点，这是与其优点相对应的：

首先是有用信息占比少，毕竟HTTP工作在第七层，包含了大量的HTTP头等信息。
其次是效率低，还是因为第七层的缘故，必须按照HTTP协议进行层层封装。

而使用自定义tcp协议的话，可以极大地精简了传输内容，这也是为什么有些后端服务之间会采用自定义tcp协议的rpc来进行通信的原因。

# 各种序列化技术

查看更多

限流算法介绍

🔥 具体的加入方式：

直接访问链接：https://t.zsxq.com/14F2uGap7
微信扫码下图：

大多数情况下，我们不需要自己实现一个限流系统，但限流在实际应用中是一个非常微妙、有很多细节的系统保护手段，尤其是在高流量时，了解你所使用的限流系统的限流算法，将能很好地帮助你充分利用该限流系统达到自己的商业需求和目的，并规避一些使用限流系统可能带来的大大小小的问题。

# 令牌桶算法

令牌桶（token bucket）算法，指的是设计一个容器（即“桶”），由某个组件持续运行往该容器中添加令牌（token），令牌可以是简单的数字、字符或组合，也可以仅仅是一个计数，然后每个请求进入系统时，需要从桶中领取一个令牌，所有请求都必须有令牌才能进入后端系统。当令牌桶空时，拒绝请求；当令牌桶满时，不再往其中添加新的令牌。令牌桶算法的架构如图1所示：

令牌桶算法的实现逻辑如下：

首先会有一个定义的时间窗口的访问次数阈值，例如每天1000人，每秒5个请求之类，限流系统一般最小粒度是秒，再小就会因为实现和性能的原因而变得不准确或不稳定，假设是T秒内允许N个请求，那么令牌桶算法则会使令牌添加组件每T秒往令牌桶中添加N个令牌。

其次，令牌桶需要有一个最大值M，当令牌添加组件检测到令牌桶中已经有M个令牌时，剩余的令牌会被丢弃。反映到限流系统中，可以认为是当前系统允许的瞬时最大流量，但不是持续最大流量。例如令牌桶中的令牌最大数量是100个，每秒钟会往其中添加10个新令牌，当令牌满的时候，突然出现100 TPS的流量，这时候是可以承受的，但是假如连续两秒的100 TPS流量就不行，因为令牌添加速度是一秒10个，添加速度跟不上使用速度。

因此，凡是使用令牌桶算法的限流系统，我们都会注意到它在配置时要求两个参数：

平均阈值（rate或average）
高峰阈值（burst或peak）

通过笔者的介绍，读者应该意识到，令牌桶算法的高峰阈值是有特指的，并不是指当前限流系统允许的最高流量。因为这一描述可能会使人认为只要低于该阈值的流量都可以，但事实上不是这样，因为只要高于添加速度的流量持续一段时间都会出现问题。

反过来说，令牌桶算法的限流系统不容易计算出它支持的最高流量，因为它能实时支持的最高流量取决于那整个时间段内的流量变化情况即令牌存量，而不是仅仅取决于一个瞬时的令牌量。

最后，当有组件请求令牌的时候，令牌桶会随机挑选一个令牌分发出去，然后将该令牌从桶中移除。注意，此时令牌桶不再做别的操作，令牌桶永远不会主动要求令牌添加组件补充新的令牌。

令牌桶算法有一个同一思想、方向相反的变种，被称为漏桶（leaky bucket）算法，它是令牌桶的一种改进，在商业应用中非常广泛。

漏桶算法的基本思想，是将请求看作水流，用一个底下有洞的桶盛装，底下的洞漏出水的速率是恒定的，所有请求进入系统的时候都会先进入这个桶，并慢慢由桶流出交给后台服务。桶有一个固定大小，当水流量超过这个大小的时候，多余的请求都会被丢弃。

漏桶算法的架构如图所示：

漏桶算法的实现逻辑如下：

首先会有一个容器存放请求，该容器有一个固定大小M，所有请求都会被先存放到该容器中。
该容器会有一个转发逻辑，该转发以每T秒N个请求的速率循环发生。
当容器中请求数已经达到M个时，拒绝所有新的请求。

因此同样地，漏桶算法的配置也需要两个值：平均值（rate）和峰值（burst）。只是平均值这时候是用来表示漏出的请求数量，峰值则是表示桶中可以存放的请求数量。

注意：漏桶算法和缓冲的限流思想不是一回事！

同样是将请求放在一个容器中，漏桶算法和缓冲不是一个用途，切不可搞混，它们的区别如下：

漏桶算法中，存在桶中的请求会以恒定的速率被漏给后端业务服务器，而缓冲思想中，放在缓冲区域的请求只有等到后端服务器空闲下来了，才会被发出去。
漏桶算法中，存在桶中的请求是原本就应该被系统处理的，是系统对外界宣称的预期，不应该被丢失，而缓冲思想中放在缓冲区域的请求仅仅是对意外状况的尽量优化，并没有任何强制要求这些请求可以被处理。

漏桶算法和令牌桶算法在思想上非常接近，而实现方向恰好相反，它们有如下的相同和不同之处：

令牌桶算法以固定速率补充可以转发的请求数量（令牌），而漏桶算法以固定速率转发请求；
令牌桶算法限制数量的是预算数，漏桶算法限制数量的是实际请求数；
令牌桶算法在有爆发式增长的流量时可以一定程度上接受，漏桶算法也是，但当流量爆发时，令牌桶算法会使业务服务器直接承担这种流量，而漏桶算法的业务服务器感受到的是一样的速率变化。

因此，通过以上比较，我们会发现漏桶算法略优于令牌桶算法，因为漏桶算法对流量控制更平滑，而令牌桶算法在设置的数值范围内，会将流量波动忠实地转嫁到业务服务器头上。

漏桶算法在Nginx和分布式的限流系统例如Redis的限流功能中都有广泛应用，是目前业界最流行的算法之一。

# 时间窗口算法

查看更多

高可用之负载均衡

🔥 具体的加入方式：

直接访问链接：https://t.zsxq.com/14F2uGap7
微信扫码下图：

一、什么是负载均衡？

什么是负载均衡？

记得第一次接触 Nginx 是在实验室，那时候在服务器部署网站需要用 Nginx 。Nginx 是一个服务组件，用来反向代理、负载平衡和 HTTP 缓存等。那么这里的负载均衡是什么？

负载均衡（LB，Load Balance），是一种技术解决方案。用来在多个资源（一般是服务器）中分配负载，达到最优化资源使用，避免过载。

资源，相当于每个服务实例的执行操作单元，负载均衡就是将大量的数据处理操作分摊到多个操作单元进行执行，用来解决互联网分布式系统的大流量、高并发和高可用的问题。那什么是高可用呢？

# 二、什么是高可用？

首先了解什么是高可用？

这是 CAP 定理是分布式系统的基础，也是分布式系统的 3 个指标：

Consistency（一致性）
Availability（可用性）
Partition tolerance（分区容错性）

那高可用（High Availability）是什么？高可用，简称 HA，是系统一种特征或者指标，通常是指，提供一定性能上的服务运行时间，高于平均正常时间段。反之，消除系统服务不可用的时间。

衡量系统是否满足高可用，就是当一台或者多台服务器宕机的时候，系统整体和服务依然正常可用。

举个例子，一些知名的网站保证 4 个 9 以上的可用性，也就是可用性超过 99.99%。那 0.01% 就是所谓故障时间的百分比。比如电商网站有赞，服务不可用会造成商家损失金钱和用户。那么在提高可用性基础上同时，对系统宕机和服务不可用会有补偿。

比如下单服务，可以使用带有负载均衡的多个下单服务实例，代替单一的下单服务实例，即使用冗余的方式来提高可靠性。

总而言之，负载均衡（Load Balance）是分布式系统架构设计中必须考虑的因素之一。一般通过负载均衡，冗余同一个服务实例的方式，解决分布式系统的大流量、高并发和高可用的问题。负载均衡核心关键：在于是否分配均匀。

# 三、常见的负载均衡案例

场景1：微服务架构中，网关路由到具体的服务实例 hello：

两个相同的服务实例 hello service ，一个端口 8000 ，另一个端口 8082
通过 Kong 的负载均衡 LB 功能，让请求均匀的分发到两个 hello 服务实例
Kong 的负载均衡策略算法很多：默认 weighted-round-robin 算法，还有 consumer: consumer id 作为 hash 算法输入值等

场景2：微服务架构中，A 服务调用 B 服务的集群。通过了 Ribbon 客户端负载均衡组件：

负载均衡策略算法并不高级，最简单的是随机选择和轮循

查看更多

消息队列常见面试题总结

🔥 具体的加入方式：

直接访问链接：https://t.zsxq.com/14F2uGap7
微信扫码下图：

为什么要使用消息队列？

总结一下，主要三点原因：解耦、异步、削峰。

1、解耦。比如，用户下单后，订单系统需要通知库存系统，假如库存系统无法访问，则订单减库存将失败，从而导致订单操作失败。订单系统与库存系统耦合，这个时候如果使用消息队列，可以返回给用户成功，先把消息持久化，等库存系统恢复后，就可以正常消费减去库存了。

2、异步。将消息写入消息队列，非必要的业务逻辑以异步的方式运行，不影响主流程业务。

3、削峰。消费端慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。比如秒杀活动，一般会因为流量过大，从而导致流量暴增，应用挂掉。这个时候加上消息队列，服务器接收到用户的请求后，首先写入消息队列，如果消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面。

# 使用了消息队列会有什么缺点

系统可用性降低。引入消息队列之后，如果消息队列挂了，可能会影响到业务系统的可用性。
系统复杂性增加。加入了消息队列，要多考虑很多方面的问题，比如：一致性问题、如何保证消息不被重复消费、如何保证消息可靠性传输等。

# 常见的消息队列对比

对比方向	概要
吞吐量	万级的 ActiveMQ 和 RabbitMQ 的吞吐量（ActiveMQ 的性能最差）要比十万级甚至是百万级的 RocketMQ 和 Kafka 低一个数量级。
可用性	都可以实现高可用。ActiveMQ 和 RabbitMQ 都是基于主从架构实现高可用性。RocketMQ 基于分布式架构。 kafka 也是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
时效性	RabbitMQ 基于 erlang 开发，所以并发能力很强，性能极其好，延时很低，达到微秒级。其他三个都是 ms 级。
功能支持	除了 Kafka，其他三个功能都较为完备。 Kafka 功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用，是事实上的标准
消息丢失	ActiveMQ 和 RabbitMQ 丢失的可能性非常低， RocketMQ 和 Kafka 理论上不会丢失。

总结：

ActiveMQ 的社区算是比较成熟，但是较目前来说，ActiveMQ 的性能比较差，而且版本迭代很慢，不推荐使用。
RabbitMQ 在吞吐量方面虽然稍逊于 Kafka 和 RocketMQ ，但是由于它基于 erlang 开发，所以并发能力很强，性能极其好，延时很低，达到微秒级。但是也因为 RabbitMQ 基于 erlang 开发，所以国内很少有公司有实力做 erlang 源码级别的研究和定制。如果业务场景对并发量要求不是太高（十万级、百万级），那这四种消息队列中，RabbitMQ 一定是你的首选。如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。
RocketMQ 阿里出品，Java 系开源项目，源代码我们可以直接阅读，然后可以定制自己公司的 MQ，并且 RocketMQ 有阿里巴巴的实际业务场景的实战考验。RocketMQ 社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些，然后接口这块不是按照标准 JMS 规范走的有些系统要迁移需要修改大量代码。还有就是阿里出台的技术，你得做好这个技术万一被抛弃，社区黄掉的风险，那如果你们公司有技术实力我觉得用 RocketMQ 挺好的
Kafka 的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms 级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展。同时 kafka 最好是支撑较少的 topic 数量即可，保证其超高吞吐量。kafka 唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略这个特性天然适合大数据实时计算以及日志收集。

# 如何保证消息队列的高可用？

RabbitMQ：镜像集群模式

RabbitMQ 是基于主从做高可用性的，Rabbitmq有三种模式：单机模式、普通集群模式、镜像集群模式。单机模式一般在生产环境中很少用，普通集群模式只是提高了系统的吞吐量，让集群中多个节点来服务某个 Queue 的读写操作。那么真正实现 RabbitMQ 高可用的是镜像集群模式。

镜像集群模式跟普通集群模式不一样的是，创建的 Queue，无论元数据还是Queue 里的消息都会存在于多个实例上，然后每次你写消息到 Queue 的时候，都会自动和多个实例的 Queue 进行消息同步。这样设计，好处在于：任何一个机器宕机不影响其他机器的使用。坏处在于：1. 性能开销太大：消息同步所有机器，导致网络带宽压力和消耗很重；2. 扩展性差：如果某个 Queue 负载很重，即便加机器，新增的机器也包含了这个 Queue 的所有数据，并没有办法线性扩展你的 Queue。

Kafka：partition 和 replica 机制

Kafka 基本架构是多个 broker 组成，每个 broker 是一个节点。创建一个 topic 可以划分为多个 partition，每个 partition 可以存在于不同的 broker 上，每个 partition 就放一部分数据，这就是天然的分布式消息队列。就是说一个 topic 的数据，是分散放在多个机器上的，每个机器就放一部分数据。

Kafka 0.8 以前，是没有 HA 机制的，任何一个 broker 宕机了，它的 partition 就没法写也没法读了，没有什么高可用性可言。

Kafka 0.8 以后，提供了 HA 机制，就是 replica 副本机制。每个 partition 的数据都会同步到其他机器上，形成自己的多个 replica 副本。然后所有 replica 会选举一个 leader 出来，生产和消费都跟这个 leader 打交道，然后其他 replica 就是 follower。写的时候，leader 会负责把数据同步到所有 follower 上去，读的时候就直接读 leader 上数据即可。Kafka 会均匀的将一个 partition 的所有 replica 分布在不同的机器上，这样才可以提高容错性。

# MQ常用协议

AMQP协议 AMQP即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言等条件的限制。优点：可靠、通用
MQTT协议 MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议。优点：格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统
STOMP协议 STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息协议，是一种为MOM(Message Oriented Middleware，面向消息的中间件)设计的简单文本协议。STOMP提供一个可互操作的连接格式，允许客户端与任意STOMP消息代理（Broker）进行交互。优点：命令模式（非topic/queue模式）
XMPP协议 XMPP（可扩展消息处理现场协议，Extensible Messaging and Presence Protocol）是基于可扩展标记语言（XML）的协议，多用于即时消息（IM）以及在线现场探测。适用于服务器之间的准即时操作。核心是基于XML流传输，这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其操作系统和浏览器不同。优点：通用公开、兼容性强、可扩展、安全性高，但XML编码格式占用带宽大
其他基于TCP/IP自定义的协议：有些特殊框架（如：redis、kafka、zeroMq等）根据自身需要未严格遵循MQ规范，而是基于TCP\IP自行封装了一套协议，通过网络socket接口进行传输，实现了MQ的功能。

# MQ的通讯模式

点对点通讯：点对点方式是最为传统和常见的通讯方式，它支持一对一、一对多、多对多、多对一等多种配置方式，支持树状、网状等多种拓扑结构。
多点广播：MQ适用于不同类型的应用。其中重要的，也是正在发展中的是”多点广播”应用，即能够将消息发送到多个目标站点(Destination List)。可以使用一条MQ指令将单一消息发送到多个目标站点，并确保为每一站点可靠地提供信息。MQ不仅提供了多点广播的功能，而且还拥有智能消息分发功能，在将一条消息发送到同一系统上的多个用户时，MQ将消息的一个复制版本和该系统上接收者的名单发送到目标MQ系统。目标MQ系统在本地复制这些消息，并将它们发送到名单上的队列，从而尽可能减少网络的传输量。
发布/订阅(Publish/Subscribe)模式：发布/订阅功能使消息的分发可以突破目的队列地理指向的限制，使消息按照特定的主题甚至内容进行分发，用户或应用程序可以根据主题或内容接收到所需要的消息。发布/订阅功能使得发送者和接收者之间的耦合关系变得更为松散，发送者不必关心接收者的目的地址，而接收者也不必关心消息的发送地址，而只是根据消息的主题进行消息的收发。在MQ家族产品中，MQ Event Broker是专门用于使用发布/订阅技术进行数据通讯的产品，它支持基于队列和直接基于TCP/IP两种方式的发布和订阅。
集群(Cluster)：为了简化点对点通讯模式中的系统配置，MQ提供 Cluster 的解决方案。集群类似于一个域(Domain) ，集群内部的队列管理器之间通讯时，不需要两两之间建立消息通道，而是采用 Cluster 通道与其它成员通讯，从而大大简化了系统配置。此外，集群中的队列管理器之间能够自动进行负载均衡，当某一队列管理器出现故障时，其它队列管理器可以接管它的工作，从而大大提高系统的高可靠性

# 如何保证消息的顺序性？

查看更多

Netty面试题

🔥 具体的加入方式：

直接访问链接：https://t.zsxq.com/14F2uGap7
微信扫码下图：

曾经使用 Netty 写过一个 RPC 框架，对 Netty 有一点点研究。这篇回答可以带你入门 Netty，即使你没有网络编程基础应该也能看懂。

老套路，学习某一门技术或者框架的时候，第一步当然是要了解下面这几样东西。

是什么？
有哪些特点？
有哪些应用场景？
有哪些成功使用的案例？
…..

为了让你更好地了解 Netty 以及它诞生的原因，先从传统的网络编程说起吧！

还是要从 BIO 说起

传统的阻塞式通信流程

早期的 Java 网络相关的 API(java.net包) 使用 Socket(套接字)进行网络通信，不过只支持阻塞函数使用。

要通过互联网进行通信，至少需要一对套接字：

运行于服务器端的 Server Socket。
运行于客户机端的 Client Socket

Socket 网络通信过程如下图所示：

Socket 网络通信过程简单来说分为下面 4 步：

建立服务端并且监听客户端请求
客户端请求，服务端和客户端建立连接
两端之间可以传递数据
关闭资源

对应到服务端和客户端的话，是下面这样的。

服务器端：

创建 ServerSocket 对象并且绑定地址（ip）和端口号(port)： server.bind(new InetSocketAddress(host, port))
通过 accept()方法监听客户端请求
连接建立后，通过输入流读取客户端发送的请求信息
通过输出流向客户端发送响应信息
关闭相关资源

客户端：

创建Socket 对象并且连接指定的服务器的地址（ip）和端口号(port)：socket.connect(inetSocketAddress)
连接建立后，通过输出流向服务器端发送请求信息
通过输入流获取服务器响应的信息
关闭相关资源

一个简单的 demo

为了便于理解，我写了一个简单的代码帮助各位小伙伴理解。

服务端：

public class HelloServer {
    private static final Logger logger = LoggerFactory.getLogger(HelloServer.class);

    public void start(int port) {
        //1.创建 ServerSocket 对象并且绑定一个端口
        try (ServerSocket server = new ServerSocket(port);) {
            Socket socket;
            //2.通过 accept()方法监听客户端请求， 这个方法会一直阻塞到有一个连接建立
            while ((socket = server.accept()) != null) {
                logger.info("client connected");
                try (ObjectInputStream objectInputStream = new ObjectInputStream(socket.getInputStream());
                     ObjectOutputStream objectOutputStream = new ObjectOutputStream(socket.getOutputStream())) {
                   //3.通过输入流读取客户端发送的请求信息
                    Message message = (Message) objectInputStream.readObject();
                    logger.info("server receive message:" + message.getContent());
                    message.setContent("new content");
                    //4.通过输出流向客户端发送响应信息
                    objectOutputStream.writeObject(message);
                    objectOutputStream.flush();
                } catch (IOException | ClassNotFoundException e) {
                    logger.error("occur exception:", e);
                }
            }
        } catch (IOException e) {
            logger.error("occur IOException:", e);
        }
    }

    public static void main(String[] args) {
        HelloServer helloServer = new HelloServer();
        helloServer.start(6666);
    }
}

ServerSocket 的 accept（） 方法是阻塞方法，也就是说 ServerSocket 在调用 accept（)等待客户端的连接请求时会阻塞，直到收到客户端发送的连接请求才会继续往下执行代码，因此我们需要要为每个 Socket 连接开启一个线程（可以通过线程池来做）。

上述服务端的代码只是为了演示，并没有考虑多个客户端连接并发的情况。

客户端：

/**
 * @author shuang.kou
 * @createTime 2020年05月11日 16:56:00
 */
public class HelloClient {

    private static final Logger logger = LoggerFactory.getLogger(HelloClient.class);

    public Object send(Message message, String host, int port) {
        //1. 创建Socket对象并且指定服务器的地址和端口号
        try (Socket socket = new Socket(host, port)) {
            ObjectOutputStream objectOutputStream = new ObjectOutputStream(socket.getOutputStream());
            //2.通过输出流向服务器端发送请求信息
            objectOutputStream.writeObject(message);
            //3.通过输入流获取服务器响应的信息
            ObjectInputStream objectInputStream = new ObjectInputStream(socket.getInputStream());
            return objectInputStream.readObject();
        } catch (IOException | ClassNotFoundException e) {
            logger.error("occur exception:", e);
        }
        return null;
    }

    public static void main(String[] args) {
        HelloClient helloClient = new HelloClient();
        helloClient.send(new Message("content from client"), "127.0.0.1", 6666);
        System.out.println("client receive message:" + message.getContent());
    }
}

发送的消息实体类：

/**
 * @author shuang.kou
 * @createTime 2020年05月11日 17:02:00
 */
@Data
@AllArgsConstructor
public class Message implements Serializable {

    private String content;
}

首先运行服务端，然后再运行客户端，控制台输出如下：

查看更多

Nacos面试题

🔥 具体的加入方式：

直接访问链接：https://t.zsxq.com/14F2uGap7
微信扫码下图：

Nacos中的保护阈值的作用是什么？

假如现在有一个服务，本来有10个实例，但是现在挂掉了8个，剩下2个正常实例，此时本来由10个实例处理的流量，就全部交给这个两个正常实例来处理了，此时这两个实例很有可能是处理不过来的，最终导致被压垮，为了应对这种情况，Nacos提供了保护阈值这个功能，我们可以给某个服务设置一个0-1的阈值，比如0.5，那就表示，一旦实例中只剩下一半的健康实例了，比如10个实例，只剩下5个健康实例了，那么消费者在进行服务发现时，则会把该服务的所有实例，也包括不健康的实例都拉取到本地，然后再从所有实例中进行负载均衡，选出一个实例进行调用，在这种情况下，选出来的即可能是一个健康的实例，也可能是挂掉的实例，但是通过这种方式，很好的保护的剩下的健康实例，至少保证了一部分请求能正常的访问，而不至于所有请求都不能正常访问，这就是Nacos中的保护阈值，同时，这个功能在Spring Cloud Tencent中叫全死全活。

Nacos中的负载均衡是怎么样的？

Nacos的负载均衡指的是，在进行服务发现时进行负载均衡，正常情况下，在进行服务发现时，会根据服务名从Nacos中拉取所有的实例信息，但是Nacos中提供了一个功能，就是可以在拉取实例时，可以根据随机策略只拉取到所有实例中的某一个，这就是Nacos中的负载均衡，它跟Ribbon的负载均衡并不冲突，可以理解为Ribbon的负载均衡是发生在Nacos的负载均衡之后的。

Nacos的就近访问是什么意思？

首先，在Nacos中，一个服务可以有多个实例，并且可以给实例设置cluster-name，就是可以再进一步的给所有实例划分集群，那如果现在某个服务A想要调用服务B，那么Naocs会看调用服务A的实例是属于哪个集群的，并且调用服务B时，那就会调用同样集群下的服务B实例，根据cluster-name来判断两个实例是不是同一个集群，这就是Nacos的就近访问。

你是怎么理解CAP理论的？

CAP理论是分布式领域中最为重要的理论，CAP理论可以理解为目前硬件条件下对于分布式架构的一种限制，就是对于一个分布式系统，只能保证AP或CP，而不能同时保证CAP，首先对于一个分布式系统，P，也就是分区容错性是一定要保证的，对于一个分布式系统，得保证在网络出现分区后，分布式系统仍然能工作，所以得保证P，只不过当出现网络分区后，整个分布式系统如果想要保证数据一致性，那么就要损耗系统可用性，或者如果想要保证系统的可用性，就不能保证系统的一致性，这里说的是强一致性，因为如果网络出现问题，分布式系统中的数据就无法进行及时的同步，如果要求强一致性，那么就只能等网络好了之后，数据同步好了之后，才能提供给用户使用，同理，如果要求网络出现后问题，系统要能使用，那就可能数据会不一致，所以对于一个分布式系统，目前来说只能保证CP或AP。

Nacos中保证的是CP还是AP？

通常我们说，Nacos技能保证CP，也能保证AP，具体看如何配置，但其实只不过是Nacos中的注册中心能保证CP或AP，Nacos中的配置中心其实没什么CP或AP，因为配置中心的数据是存在一个Mysql中的，只有注册中心的数据需要进行集群节点之间的同步，从而涉及到是CP还是AP，如果注册的节点是临时节点，那么就是AP，如果是非临时节点，那么就是CP，默认是临时节点。

如何理解Nacos中的命名空间？

命名空间，也就是namespace，其实这个概念并不是Nacos中独有的，在Nacos中，不管是配置还是服务，都是属于某一个命名空间中的，默认情况下都是属于pulibc这个命名空间中的，我们可以在Nacos中新增命名空间，也就相当于开辟了另外一套存放服务和配置的地方，命名空间之间是独立的，完全不冲突的，所以我们可以利用Nacos中的命名空间来实现不同环境、不同租户之间的服务注册和配置。

你觉得注册中心应该是CP还是AP？

我觉得大部分情况下，注册中心应该是AP，如果注册中心是CP的，那么表示，当我们向注册中心注册实例或移除实例时，都要等待注册中心集群中的数据达到一致后，才算注册或移除成功，而这是比较耗时的，随着业务应用规模的增大，应用频繁的上下线，那么就会导致注册中心的压力比较大，会影响到服务发现的效率以及服务调用了，而如果注册中心是AP的，那么注册中心集群不管出现了什么情况，都是可以提供服务的，就算集群节点之间数据出现了不一致，对于业务应用而言，可能拉取到了一个已经下线了的服务节点，但是现在一般的微服务框架或组件都提供了服务容错和重试功能，也可以避免这个问题，而如果是AP，对于注册中心而言就不需要消耗太多的资源来实时的保证数据一致性了，保证最终一致性就可以了，这样注册中心的压力会小一点，另外像Zookeeper来作为注册中心，因为Zookeeper保证的就是CP，但是如果集群中如果大多数节点挂掉了，就算还剩下一些Zookeeper节点，这些节点也是不能提供服务的，所以这个也不太合适，所以综合来看，注册中心应该保证AP会更好，就像Euraka、Nacos他们默认保证的就是AP。

nacos 作为配置中心要配置什么

Nacos作为配置中心，需要配置以下内容：

数据源配置：包括数据库连接信息、用户名、密码等。这些信息将用于Nacos存储配置数据的数据库。
配置项：定义需要在Nacos中管理和存储的配置项。可以根据业务需求自定义配置项的名称、类型、默认值等。
集群配置：如果需要使用Nacos作为分布式配置中心，需要配置集群信息，包括集群节点的IP地址、端口号等。
权限配置：根据需求设置不同用户或角色的权限，以保证配置数据的安全性。
监控配置：可以配置Nacos的监控指标，包括监控数据的收集周期、存储方式等。
通知配置：可以配置Nacos在配置变更时发送通知的方式，比如邮件、短信等。
注册中心配置：如果需要将Nacos用作服务注册中心，需要配置相关信息，如注册中心的地址、端口等。

为什么要将服务注册到nacos?

将服务注册到Nacos有以下几个重要原因：

服务发现与负载均衡：Nacos可以作为服务注册中心，帮助应用实现服务发现和负载均衡。通过在Nacos上注册服务，其他应用可以方便地发现和调用该服务，提高了应用的可用性和可扩展性。
动态配置管理：Nacos提供了动态配置管理功能，可以动态地修改应用的配置信息，而无需重启应用。这样可以方便地对应用进行配置调整，提高了配置的灵活性和可管理性。
服务健康检查：Nacos可以定期检查已注册的服务的健康状态，及时发现故障或不可用的服务，并对其进行下线或重启操作。这样可以提高服务的稳定性和可靠性。
跨区域部署：Nacos支持多区域的服务注册和发现，可以方便地将服务部署到不同的区域，实现跨区域的服务调用和负载均衡。这对于构建分布式系统和实现高可用架构非常有价值。

总而言之，将服务注册到Nacos可以提供服务发现、负载均衡、动态配置管理、服务健康检查等功能，帮助应用实现高可用、可扩展和灵活的架构。

Nacos服务是如何判定服务实例的状态？

Nacos服务通过以下几个步骤来判定服务实例的状态：

心跳检测：Nacos会定期向每个注册的服务实例发送心跳请求，以检测其是否存活。如果Nacos在一段时间内没有收到实例的心跳回复，就会将该实例标记为不可用。
健康检查：Nacos可以配置一些健康检查的规则，例如HTTP接口的返回状态码、响应时间等。Nacos会定期调用这些接口，根据返回结果来判断服务实例的健康状况。如果实例返回的结果不符合预期的健康规则，Nacos会将其标记为不可用。
负载均衡：Nacos还会根据实例的负载情况来判定其状态。如果某个实例的负载过高，超过了一定的阈值，Nacos可能会将其标记为不可用，以避免过多的请求落在该实例上，导致服务质量下降。

需要注意的是，Nacos的状态判定是基于一定的策略和规则进行的，具体的判定方式可以根据实际需求进行配置和扩展。以上是一般情况下Nacos服务判定服务实例状态的方式，避免了敏感内容的提及。

查看更多

Shiro面试题

🔥 具体的加入方式：

直接访问链接：https://t.zsxq.com/14F2uGap7
微信扫码下图：

一、Shiro框架介绍
是一个轻量级的安全框架，主要提供了授权、认证、加密、会话管理这几个功能。

二、shiro安全数据源有哪些
1.数据库
2.静态ini文件
3.session

三、Shiro运行流程
比如一个登陆流程：
1、首先调用Subject.login(token)进行登录，他会委托给SecurityManager
2、SecurityManager负责真正的身份验证逻辑；它会委托给Authenticator进行身份验证；
3、Authenticator会把相应的token传入Realm，从Realm获取身份验证信息，如果没有就返回认证失败，有的话就继续执行操作。

四、Shiro 的优点
1、简单的身份认证, 支持多种数据源；非常简单的加密 API；
2、对角色的简单的授权, 支持细粒度的授权(方法级)；
3、支持一级缓存，以提升应用程序的性能；

4、内置的基于 POJO 企业会话管理, 适用于 Web 以及非 Web 的环境；
5、不跟任何的框架或者容器捆绑, 可以独立运行。

五、比较 SpringSecurity 和 Shiro
1、相比 Spring Security, Shiro 在保持强大功能的同时, 使用简单性和灵活性；
2、SpringSecurity: 即使是一个一个简单的请求，最少得经过它的 8 个Filter；
3、SpringSecurity 必须在 Spring 的环境下使用；

4、初学 Spring Security, 曲线还是较大, 需要深入学习其源码和框架, 配置起来也较费力。

六、简述 Shiro 的3个核心组件
1.Subject
正与系统进行交互的人, 或某一个第三方服务。
所有 Subject 实例都被绑定到一个SecurityManager 上。

2.SecurityManager
Shiro 架构的心脏, 用来协调内部各安全组件, 管理内部组件实例, 并通过它来提供安全管理的各种服务。
当 Shiro 与一个 Subject 进行交互时, 实质上是幕后的 SecurityManager 处理所有繁重的 Subject 安全操作。

3.Realms
本质上是一个特定安全的 DAO. 当配置 Shiro 时, 必须指定至少一个 Realm 用来进行身份验证和授权。
Shiro 提供了多种可用的 Realms 来获取安全相关的数据. 例如关系数据库(JDBC), INI 及属性文件等。
可以定义自己 Realm 实现来代表自定义的数据源。

七、Shiro认证过程
1、应用程序代码调用 Subject.login 方法，传递创建好的包含终端用户的 Principals(身份)和 Credentials(凭证)的 AuthenticationToken 实例；
2、Subject 实例委托应用程序的 SecurityManager 通过调用securityManager.login(token) 开始真正的验证；
Subject 实例（通常为 DelegatingSubject或它的子类）
3、SubjectManager 接收 token，调用内部的 Authenticator 实例调用 authenticator.authenticate(token).Authenticator 通常是一个 ModularRealmAuthenticator 实例, 支持在身份验证中协调一个或多个Realm 实例；
4、如果应用程序中配置了一个以上的 Realm, ModularRealmAuthenticator 实例将利用配置好的AuthenticationStrategy 来启动 Multi-Realm 认证尝试。在Realms 被身份验证调用之前、调用期间、调用之后，AuthenticationStrategy 被调用使其能够对每个Realm 的结果作出反应。（AuthenticationStrategy都会被调用，对每个Realm 的结果作出反应）；
5、每个配置的 Realm 用来帮助看它是否支持提交的 AuthenticationToken. 如果支持, 那么支持 Realm 的 getAuthenticationInfo 方法将会伴随着提交的 token 被调用. getAuthenticationInfo 方法有效地代表一个特定 Realm 的单一的身份验证尝试。

八、Shiro授权过程
1、应用程序或框架代码调用任何 Subject 的hasRole*, checkRole*, isPermitted*,或者checkPermission*方法的变体, 传递任何所需的权限；
2、Subject 的实例调用securityManager 的对应的方法。
Subject 实例（通常为 DelegatingSubject或它的子类）
3、SecurityManager 调用 org.apache.shiro.authz.Authorizer 接口的对应方法.默认情况下，authorizer 实例是一个 ModularRealmAuthorizer 实例, 它支持协调任何授权操作过程中的一个或多个Realm 实例；
4、每个配置好的 Realm 被检查是否实现了相同的 Authorizer 接口. 如果是, Realm 各自的 hasRole*, checkRole*,isPermitted*，或 checkPermission* 方法将被调用。

九、Shiro 如何自实现认证

查看更多

面试常见的几个问题如何回答才能最得体？

🔥 具体的加入方式：

直接访问链接：https://t.zsxq.com/14F2uGap7
微信扫码下图：

1. 自我介绍

关于自我介绍，要从如下几个方面组织内容：姓名、毕业院校、专业（如果专业不匹配就略过）、工作经验、过往工作经历以及相对应的成绩、投递这份工作的原因。

我当时整理的话术是这样的：

Xx您好，我叫徐策，2014年毕业于Xx大学经理管理学院（因为专业不匹配所以略过专业），拥有2年PM经验和1年互联网运营经验。
2014年7月毕业后，开始我的第一份工作，入职Xx集团，任PM岗位，在2年多的工作当中，我主责完成Xx（工作业绩）。
2017年初，我从Xx集团离职，入职Xx有限公司，任运营岗，主要负责用户运营和内容运营方向。在一年的工作期间，我完成了Xx（工作业绩）。
我是在咱们公司官网上看到的该岗位的招聘，感觉我的工作经验和工作能力和该岗位很匹配，所以来投递了简历。
以上，谢谢。

我在这个问题最后提到了“自己和这个岗位很匹配”，是为了引导面试官可以顺着这个问题继续问下去。我一直认为，如果有能力引导面试官，总比被面试官牵着鼻子走要好很多。

上面的话术要提前准备，多练习几遍，面试的时候会说的很顺口。

如果有可能的话，要准备1分钟、3分钟和5分钟的版本，面试官如果规定时间，就拿出对应时间的版本来说。上面我的话术差不多是3分钟左右，如果要延长至5分钟，可以在每份工作后添加上离职原因，这个后续是一定会被问到的。

2. 自己与这份工作的匹配点

通过刚才的自我介绍的部分，很大程度上会把面试官引导到这个问题上来。既然是有意引导，那这个问题当然也应该提前准备。

我会从这么几个方面来回答“自己与工作匹配”的问题：工作经验、个人能力、个人职业规划、公司文化、兴趣爱好。

举一个例子，一般我组织的话术会是这样的：

我觉得我在如下几个方面与这份工作比较匹配：
第一，我有2年多PM的工作经验，咱们公司招聘的岗位也是PM；
第二，这份工作除了PM外，还需要用到一些运营的相关知识，而我也有这方面的工作经验；
第三，我在以往工作中表现出来的思维能力比较强，包括系统思维、逻辑性思维等，我认为咱们这份工作也是需要这些思维能力的（要在面试过程中表现出罗辑思维来）；
第四，我看到咱们的岗位职责中有培训相关的内容，而我在之前工作经历中有超过100小时的培训经历（此时可以拿出之前做过培训的课件）；
第五，咱们这份工作会有很多活动策划等相关内容，而我自己做PPT的能力比较强，相信在这方面会有所帮助（此时拿出之前做过的PPT）；
第六，我给自己规划的职业发展是互金行业，之后我会一直在这个行业中发展，这个和咱们公司是匹配的；
第七，咱们公司应该是一个初创公司，而我上一份工作也是在初创公司，我认为我对初创公司的高强度工作和部门间相互配合的工作模式是很熟悉的；
第八，我的兴趣匹配。我之前就有投资理财的习惯，这份工作也有相关的内容。
所以，基于以上这些，我认为我和这份工作匹配度比较高。

上面这两个问题回答完，基本就会给面试官留下一个“专业、靠谱”的印象了。

3. 为什么离职

查看更多

Kubernetes面试题

🔥 具体的加入方式：

直接访问链接：https://t.zsxq.com/14F2uGap7
微信扫码下图：

docker的工作原理是什么，讲一下

docker是一个Client-Server结构的系统，docker守护进程运行在宿主机上，守护进程从客户端接受命令并管理运行在主机上的容器，容器是一个运行时环境，这就是我们说的集装箱。

docker的组成包含哪几大部分

一个完整的docker有以下几个部分组成： 1、docker client，客户端，为用户提供一系列可执行命令，用户用这些命令实现跟 docker daemon 交互；

2、docker daemon，守护进程，一般在宿主主机后台运行，等待接收来自客户端的请求消息；

3、docker image，镜像，镜像run之后就生成为docker容器；

4、docker container，容器，一个系统级别的服务，拥有自己的ip和系统目录结构；运行容器前需要本地存在对应的镜像，如果本地不存在该镜像则就去镜像仓库下载。

docker 使用客户端-服务器 (C/S) 架构模式，使用远程api来管理和创建docker容器。docker 容器通过 docker 镜像来创建。容器与镜像的关系类似于面向对象编程中的对象与类。

docker与传统虚拟机的区别什么？

1、传统虚拟机是需要安装整个操作系统的，然后再在上面安装业务应用，启动应用，通常需要几分钟去启动应用，而docker是直接使用镜像来运行业务容器的，其容器启动属于秒级别；

2、Docker需要的资源更少，Docker在操作系统级别进行虚拟化，Docker容器和内核交互，几乎没有性能损耗，而虚拟机运行着整个操作系统，占用物理机的资源就比较多;

3、Docker更轻量，Docker的架构可以共用一个内核与共享应用程序库，所占内存极小;同样的硬件环境，Docker运行的镜像数远多于虚拟机数量，对系统的利用率非常高;

4、与虚拟机相比，Docker隔离性更弱，Docker属于进程之间的隔离，虚拟机可实现系统级别隔离;

5、Docker的安全性也更弱，Docker的租户root和宿主机root相同，一旦容器内的用户从普通用户权限提升为root权限，它就直接具备了宿主机的root权限，进而可进行无限制的操作。虚拟机租户root权限和宿主机的root虚拟机权限是分离的，并且虚拟机利用如Intel的VT-d和VT-x的ring-1硬件隔离技术，这种技术可以防止虚拟机突破和彼此交互，而容器至今还没有任何形式的硬件隔离;

6、Docker的集中化管理工具还不算成熟，各种虚拟化技术都有成熟的管理工具，比如：VMware vCenter提供完备的虚拟机管理能力;

7、Docker对业务的高可用支持是通过快速重新部署实现的，虚拟化具备负载均衡，高可用、容错、迁移和数据保护等经过生产实践检验的成熟保障机制，Vmware可承诺虚拟机99.999%高可用，保证业务连续性;

8、虚拟化创建是分钟级别的，Docker容器创建是秒级别的，Docker的快速迭代性，决定了无论是开发、测试、部署都可以节省大量时间;

9、虚拟机可以通过镜像实现环境交付的一致性，但镜像分发无法体系化，Docker在Dockerfile中记录了容器构建过程，可在集群中实现快速分发和快速部署。

docker技术的三大核心概念是什么？

镜像：镜像是一种轻量级、可执行的独立软件包，它包含运行某个软件所需的所有内容，我们把应用程序和配置依赖打包好形成一个可交付的运行环境(包括代码、运行时需要的库、环境变量和配置文件等)，这个打包好的运行环境就是image镜像文件。

容器：容器是基于镜像创建的，是镜像运行起来之后的一个实例，容器才是真正运行业务程序的地方。如果把镜像比作程序里面的类，那么容器就是对象。

镜像仓库：存放镜像的地方，研发工程师打包好镜像之后需要把镜像上传到镜像仓库中去，然后就可以运行有仓库权限的人拉取镜像来运行容器了。

centos镜像几个G，但是docker centos镜像才几百兆，这是为什么？

一个完整的Linux操作系统包含Linux内核和rootfs根文件系统，即我们熟悉的/dev、/proc/、/bin等目录。我们平时看到的CentOS除了rootfs，还会选装很多软件，服务，图形桌面等，所以CentOS镜像有好几个G也不足为奇。

而对于容器镜像而言，所有容器都是共享宿主机的Linux 内核的，而对于docker镜像而言，docker镜像只需要提供一个很小的rootfs即可，只需要包含最基本的命令，工具，程序库即可，所有docker镜像才会这么小。

讲一下镜像的分层结构以及为什么要使用镜像的分层结构？

一个新的镜像其实是从 base 镜像一层一层叠加生成的。每安装一个软件，dockerfile中使用RUN指令，就会在现有镜像的基础上增加一层，这样一层一层的叠加最后构成整个镜像。所以我们docker pull拉取一个镜像的时候会看到docker是一层层拉去的。

分层机构最大的一个好处就是：共享资源。比如：有多个镜像都从相同的 base 镜像构建而来，那么 Docker Host 只需在磁盘上保存一份 base 镜像；同时内存中也只需加载一份 base 镜像，就可以为所有容器服务了。而且镜像的每一层都可以被共享。

讲一下容器的copy-on-write特性，修改容器里面的内容会修改镜像吗？

我们知道，镜像是分层的，镜像的每一层都可以被共享，同时，镜像是只读的。当一个容器启动时，一个新的可写层被加载到镜像的顶部，这一层通常被称作“容器层”，“容器层”之下的都叫“镜像层”。

所有对容器的改动 – 无论添加、删除、还是修改文件，都只会发生在容器层中，因为只有容器层是可写的，容器层下面的所有镜像层都是只读的。镜像层数量可能会很多，所有镜像层会联合在一起组成一个统一的文件系统。如果不同层中有一个相同路径的文件，比如/a，上层的 /a 会覆盖下层的/a，也就是说用户只能访问到上层中的文件 /a。在容器层中，用户看到的是一个叠加之后的文件系统。

添加文件时：在容器中创建文件时，新文件被添加到容器层中。

读取文件：在容器中读取某个文件时，Docker 会从上往下依次在各镜像层中查找此文件。一旦找到，立即将其复制到容器层，然后打开并读入内存。

修改文件：在容器中修改已存在的文件时，Docker 会从上往下依次在各镜像层中查找此文件。一旦找到，立即将其复制到容器层，然后修改之。

删除文件：在容器中删除文件时，Docker 也是从上往下依次在镜像层中查找此文件。找到后，会在容器层中记录下此删除操作。

只有当需要修改时才复制一份数据，这种特性被称作 Copy-on-Write。可见，容器层保存的是镜像变化的部分，不会对镜像本身进行任何修改。

简单描述一下Dockerfile的整个构建镜像过程

1、首先，创建一个目录用于存放应用程序以及构建过程中使用到的各个文件等；

2、然后，在这个目录下创建一个Dockerfile文件，一般建议Dockerfile的文件名就是Dockerfile；

3、编写Dockerfile文件，编写指令，如，使用FORM指令指定基础镜像，COPY指令复制文件，RUN指令指定要运行的命令，ENV设置环境变量，EXPOSE指定容器要暴露的端口，WORKDIR设置当前工作目录，CMD容器启动时运行命令，等等指令构建镜像；

4、Dockerfile编写完成就可以构建镜像了，使用docker build -t 镜像名:tag .命令来构建镜像，最后一个点是表示当前目录，docker会默认寻找当前目录下的Dockerfile文件来构建镜像，如果不使用默认，可以使用-f参数来指定dockerfile文件，如：docker build -t 镜像名:tag -f /xx/xxx/Dockerfile；

5、使用docker build命令构建之后，docker就会将当前目录下所有的文件发送给docker daemon，顺序执行Dockerfile文件里的指令，在这过程中会生成临时容器，在临时容器里面安装RUN指定的命令，安装成功后，docker底层会使用类似于docker commit命令来将容器保存为镜像，然后删除临时容器，以此类推，一层层的构建镜像，运行临时容器安装软件，直到最后的镜像构建成功。

为什么要使用分布式锁

# 分布式锁应该具备哪些条件

# 分布式锁的三种实现方式

# 基于数据库的实现方式

# 基于Redis的实现方式

# 简单实现

RPC简介

# RPC 解决了什么问题？

# 常见的 RPC 框架有哪些?

# 有了HTTP ，为啥还要用RPC进行服务调用?

# 各种序列化技术

# 令牌桶算法

# 时间窗口算法

一、 什么是负载均衡？

# 二、什么是高可用？

# 三、常见的负载均衡案例

为什么要使用消息队列？

# 使用了消息队列会有什么缺点

# 常见的消息队列对比

# 如何保证消息队列的高可用？

# MQ常用协议

# MQ的通讯模式

# 如何保证消息的顺序性？

还是要从 BIO 说起

传统的阻塞式通信流程

一个简单的 demo

Nacos中的保护阈值的作用是什么？

Nacos中的负载均衡是怎么样的？

Nacos的就近访问是什么意思？

你是怎么理解CAP理论的？

Nacos中保证的是CP还是AP？

如何理解Nacos中的命名空间？

你觉得注册中心应该是CP还是AP？

nacos 作为配置中心要配置什么

为什么要将服务注册到nacos?

Nacos服务是如何判定服务实例的状态？

docker的工作原理是什么，讲一下

docker的组成包含哪几大部分

docker与传统虚拟机的区别什么？

docker技术的三大核心概念是什么？

centos镜像几个G，但是docker centos镜像才几百兆，这是为什么？

讲一下镜像的分层结构以及为什么要使用镜像的分层结构？

讲一下容器的copy-on-write特性，修改容器里面的内容会修改镜像吗？

简单描述一下Dockerfile的整个构建镜像过程

Dockerfile构建镜像出现异常，如何排查？

一、什么是负载均衡？