java面试题：分布式

分布式分为分布式缓存(Redis)、分布式锁(Redis或Zookeeper)、分布式服务(Dubbo或SpringCloud)、分布式服务协调(Zookeeper)、分布式消息队列(Kafka、RabbitMq)、分布式Session、分布式事务、分布式搜索(elastaticSearch)等。 不可能全部分布式内容都熟悉，必定要在某个领域有所专长。 ###分布式理论 Q:分布式有哪些理论？ CAP、BASE。 分布式CAP理论，任何一个分布式系统都没法同时知足Consistency(一致性)、Availability(可用性)、Partition tolerance(分区容错性) 这三个基本需求。最多只能知足其中两项。 而Partition tolerance(分区容错性) 是必须的，所以通常是CP，或者AP。 Q:你怎么理解分布式一致性？ 数据一致性一般指关联数据之间的逻辑关系是否正确和完整。 在分布式系统中，数据一致性每每指的是因为数据的复制，不一样数据节点中的数据内容是否完整而且相同。 一致性还分为强一致性，弱一致性，还有最终一致性。 强一致性就是立刻就保持一致。 最终一致性是指通过一段时间后，能够保持一致。

分布式事务

Q:你怎么理解分布式事务？分布式事务的协议有哪些？ 分布式事务是指会涉及到操做多个数据库的事务。目的是为了保证分布式系统中的数据一致性。 分布式事务类型：二阶段提交2PC，三阶段提交3PC。 2PC：第一阶段：准备阶段(投票阶段)和第二阶段：提交阶段（执行阶段）。 3PC：三个阶段：CanCommit、PreCommit、DoCommit Q:分布式事务的解决方案有哪些？ 分布式事务解决方案：补偿机制TCC、XA、消息队列MQ。 详情见：https://www.cnblogs.com/expiator/p/9841703.html 面试题详细答案见：https://juejin.im/post/5d70b0535188251637727de8 Q:怎么保证分布式系统的幂等性？ ###Rpc Q:讲一下Dubbo 服务提供者提供服务，服务消费者能够经过Rpc进行服务消费。 Q:Dubbo支持哪些协议？ Dubbo支持Dubbo、rmi、hessian、http、webservice、thrift、Redis等多种协议 Q:Dubbo默认的协议是什么？ Dubbo协议。 Q:Dubbo的序列化有哪些方式？ Dubbo协议。
链接方式：长链接。默认协议：dubbo协议。序列化：hession二进制。
其余协议： rmi协议。链接方式：短链接。序列化：java自带的二进制 hessian。链接方式：短链接。序列化：表单序列化 Q:Dubbo和SpringCloud有哪些区别？ Dubbo是Soa(面向服务的架构)，SpringCloud是微服务架构，除了服务，还有注册中心、熔断、配置中心。 Dubbo基于Rpc(远程过程调用)，SpringCloud基于restFul，基于http协议。 Q:Soa和微服务架构，有哪些区别？ Q:除了Zookeeper，你用过哪些注册中心?有什么区别？ Zookeeper，Redis，Eureka Zookeeper，是分布式中的CP，可以更好地保证分布式一致性。 Redis基于发布/订阅模式。 Eureka在SpringCloud中应用较多。Eureka是分布式中的AP，也就是注重可用性。 Q:若是想实现一个Rpc框架，须要考虑哪些东西？ 动态代理、反射、序列化、反序列化、网络通讯(netty)、编解码、服务发现和注册、心跳与链路检测 Q:Dubbo的服务提供者、服务消费者须要配置哪些信息？ 服务提供者须要配置ip、端口、Dubbo协议、注册中心地址等 Q:Dubbo有哪些负载均衡策略？ 一致性Hash均衡算法、随机调用法、轮询法、最少活动调用法。 Q:讲一下Dubbo的SPI机制。 Q:大家用的是哪一个版本的Dubbo? Q:大家的服务划分了几个模块？分别是哪些模块？

###Redis Q:Redis有哪些优点？ 1.速度快，由于数据存在内存中 2.支持丰富数据类型，支持string，list，set，sorted set，hash 3.支持事务，操做都是原子性，所谓的原子性就是对数据的更改要么所有执行，要么所有不执行 4.丰富的特性：可用于缓存，消息，按key设置过时时间，过时后将会自动删除 5.单线程，单进程，采用IO多路复用技术。 Q:Redis支持哪些数据结构？ string(字符串),hash(哈希),list(队列),set(集合)及zset(sorted set:有序集合)。 Q:Redis的数据结构，有哪些应用场景？ string，简单地get/set缓存。 hash，能够缓存用户资料。好比命令： hmset user1 name "lin" sex "male" age "25" ，缓存用户user1的资料，姓名为lin，性别为男，年龄25。 list，能够作队列。往list队列里面push数据，而后再pop出来。 zset，能够用来作排行榜。 详情见：https://www.cnblogs.com/expiator/p/10274151.html Q:Redis的持久化方式有哪些？有哪些优缺点？ aof，就是备份操做记录。aof因为是备份操做命令，备份快，恢复慢。 rdb，就是备份全部数据，使用了快照。rdb恢复数据比较快。 Q:aof文件过大，怎么处理？ 会进行aof文件重写。 1.随着AOF文件愈来愈大，里面会有大部分是重复命令或者能够合并的命令 2.重写的好处：减小AOF日志尺寸，减小内存占用，加快数据库恢复时间。 执行一个 AOF文件重写操做，重写会建立一个当前 AOF 文件的体积优化版本。 详情见： https://blog.csdn.net/stevendbaguo/article/details/82855726 Q:讲一下Redis的事务 先以 MULTI 开始一个事务， 而后将多个命令入队到事务中， 最后由 EXEC 命令触发事务， 一并执行事务中的全部命令。若是想放弃这个事务，可使用DISCARD命令。 Redis事务没法回滚，那怎么处理？ Q:怎么设置Redis的key的过时时间？ key的的过时时间经过EXPIRE key seconds命令来设置数据的过时时间。返回1代表设置成功，返回0代表key不存在或者不能成功设置过时时间。 Q:Redis的过时策略有哪些？ Redis key过时的方式有三种： 被动删除：当读/写一个已通过期的key时，会触发惰性删除策略，直接删除掉这个过时key 主动删除：因为惰性删除策略没法保证冷数据被及时删掉，因此Redis会按期主动淘汰一批已过时的key 当前已用内存超过maxmemory限定时，触发主动清理策略，也就是Redis的内存回收策略。 Q:Redis 的内存回收机制都有哪些？ LRU、TTL。 noeviction：默认策略，不会删除任何数据，拒绝全部写入操做并返回客户端错误信息，此时Redis只响应读操做。 volatitle-lru：根据LRU算法删除设置了超时属性的键，知道腾出足够空间为止。若是没有可删除的键对象，回退到noeviction策略。 allkeys-lru：根据LRU算法删除键，无论数据有没有设置超时属性，直到腾出足够空间为止。 allkeys-random：随机删除全部键，知道腾出足够空间为止。 volatitle-random：随机删除过时键，知道腾出足够空间为止。 volatitle-ttl：根据键值对象的ttl属性，删除最近将要过时数据。若是没有，回退到noeviction策略 Q:手写一下LRU算法 。 Q:Redis如何实现分布式锁？ 使用setnx命令。 setnx key value，当key不存在时，将 key 的值设为 value ，返回1。若给定的 key 已经存在，则setnx不作任何动做，返回0。 当setnx返回1时，表示获取锁，作完操做之后del key，表示释放锁，若是setnx返回0表示获取锁失败。 **Q:Redis实现的分布式锁，若是某个系统获取锁后，宕机了怎么办？ ** Redis宕机的话，会经过Redis集群的哨兵模式，将某个从机变成新的主机。 系统模块宕机的话，能够经过设置过时时间(就是设置缓存失效时间)解决。系统宕机时锁阻塞，过时后锁释放。 Q:设置缓存失效时间，那若是前一个线程把这个锁给删除了呢？ Q:Redis作分布式锁，Redis作了主从，若是设置锁以后，主机在传输到从机的时候挂掉了，从机尚未加锁信息，如何处理？ 可使用开源框架Redisson，采用了redLock。(待补充) Q:讲一下Redis的redLock。 Q:Redis的搭建有哪些模式？ 主从模式、哨兵模式、Cluster（集群）模式。 最好是用集群模式。 详情见：https://new.qq.com/omn/20180126/20180126G00THE.html Q:你用过的Redis是多主多从的，仍是一主多从的？集群用到了多少节点？用到了多少个哨兵？ 集群模式。三主三从。 Q:Redis采用多主多从的集群模式，各个主节点的数据是否一致？ Q:Redis集群有哪些特性？ master和slaver。主从复制。读写分离。哨兵模式。 Q:Redis集群数据分片的原理是什么？ Redis数据分片原理是哈希槽。 Redis 集群有 16384 个哈希槽。 每个 Redis 集群中的节点都承担一个哈希槽的子集。 哈希槽让在集群中添加和移除节点很是容易。例如，若是我想添加一个新节点 D，我须要从节点 A，B， C 移动一些哈希槽到节点 D。一样地，若是我想从集群中移除节点 A，我只须要移动 A 的哈希槽到 B 和 C。 当节点 A 变成空的之后，我就能够从集群中完全删除它。 由于从一个节点向另外一个节点移动哈希槽并不须要中止操做，因此添加和移除节点，或者改变节点持有的哈希槽百分比，都不须要任何停机时间(downtime)。 Q:集群的拓扑结构有没有了解过？集群是怎么链接的？ 无中心结构。Redis-Cluster采用无中心结构，每一个节点保存数据和整个集群状态,每一个节点都和其余全部节点链接。 Q:讲一下Redis主从复制的过程。 从机发送SYNC(同步)命令，主机接收后会执行BGSAVE(异步保存)命令备份数据。 主机备份后，就会向从机发送备份文件。主机以后还会发送缓冲区内的写命令给从机。 当缓冲区命令发送完成后，主机执行一条写命令，就会往从机发送同步写入命令。 更详细的步骤见： https://www.cnblogs.com/expiator/p/9881989.html Q:讲一下Redis哨兵机制。 下面是Redis官方文档对于哨兵功能的描述： 监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运做正常。 自动故障转移（Automatic Failover）：当主节点不能正常工做时，哨兵会开始自动故障转移操做，它会将失效主节点的其中一个从节点升级为新的主节点，并让其余从节点改成复制新的主节点。 配置提供者（Configuration Provider）：客户端在初始化时，经过链接哨兵来得到当前Redis服务的主节点地址。 通知（Notification）：哨兵能够将故障转移的结果发送给客户端。 ##缓存 Q:缓存雪崩是什么？ 若是缓存数据设置的过时时间是相同的，而且Redis刚好将这部分数据所有删光了。这就会致使在这段时间内，这些缓存同时失效，所有请求到数据库中。这就是缓存雪崩。 怎么解决缓存雪崩？ 解决方法：在缓存的时候给过时时间加上一个随机值，这样就会大幅度的减小缓存在同一时间过时。 Q:缓存穿透是什么？ 缓存穿透是指查询一个必定不存在的数据。因为缓存不命中，而且出于容错考虑，若是从数据库查不到数据则不写入缓存，这将致使这个不存在的数据每次请求都要到数据库去查询，失去了缓存的意义。 怎么解决缓存穿透？ Q:什么是缓存与数据库双写一致问题？ 读的时候，先读缓存，缓存没有的话，就读数据库，而后取出数据后放入缓存，同时返回响应。 更新的时候，先更新数据库，而后再删除缓存。 Q:先更新数据库，再删除缓存。若是删除缓存失败了，那么会致使数据库中是新数据，缓存中是旧数据，数据就出现了不一致，怎么办？ 解答：先删除缓存，再更新数据库。若是数据库更新失败了，那么数据库中是旧数据，缓存中是空的，那么数据不会不一致。 由于读的时候缓存没有，因此去读了数据库中的旧数据，而后更新到缓存中。 ###Zookeeper Q:Zookeeper的原理是什么？ Q:Zookeeper是怎么保证一致性的？ zab协议。 zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，zab就进入了恢复模式，当领导者被选举出来，且大多数server完成了和 leader的状态同步之后，恢复模式就结束了。状态同步保证了leader和server具备相同的系统状态。

Q:Zookeeper有哪些应用场景？ Zookeeper能够做为服务协调的注册中心。还能够作分布式锁(若是没有用过度布式锁就不要说) Q:Zookeeper为何能作注册中心？ Zookeeper的数据模型是树型结构，由不少数据节点组成，zk将全量数据存储在内存中，可谓是高性能，并且支持集群，可谓高可用。 另外支持事件监听(watch命令)。 Zookeeper能够做为一个数据发布/订阅系统。 Q:Zookeeper的节点有哪些类型？有什么区别？ 临时节点，永久节点。 更加细分就是临时有序节点、临时无序节点、永久有序节点、永久无序节点。　　 临时节点： 当建立临时节点的程序停掉以后，这个临时节点就会消失，存储的数据也没有了。 Q:Zookeeper作为注册中心，主要存储哪些数据？存储在哪里？ ip、端口，还有心跳机制。 数据存储在Zookeeper的节点上面。 Q:心跳机制有什么用？ Q:Zookeeper的广播模式有什么缺陷？ 广播风暴。 Q:Zookeeper是怎么实现分布式锁的？ 分布式锁：基于Zookeeper一致性文件系统,实现锁服务。锁服务分为保存独占及时序控制两类。 保存独占：将Zookeeper上的一个znode看做是一把锁，经过createznode的方式来实现。全部客户端都去建立 /distribute_lock 节点，最终成功建立的那个客户端也即拥有了这把锁。用完删除本身建立的distribute_lock 节点就释放锁。 时序控制：基于/distribute_lock锁，全部客户端在它下面建立临时顺序编号目录节点，和选master同样，编号最小的得到锁，用完删除，依次方便。 更详细的回答以下： 其实基于Zookeeper，就是使用它的临时有序节点来实现的分布式锁。 原理就是：当某客户端要进行逻辑的加锁时，就在Zookeeper上的某个指定节点的目录下，去生成一个惟一的临时有序节点， 而后判断本身是不是这些有序节点中序号最小的一个，若是是，则算是获取了锁。若是不是，则说明没有获取到锁，那么就须要在序列中找到比本身小的那个节点，并对其调用exist()方法，对其注册事件监听，当监听到这个节点被删除了，那就再去判断一次本身当初建立的节点是否变成了序列中最小的。若是是，则获取锁，若是不是，则重复上述步骤。 当释放锁的时候，只需将这个临时节点删除便可。 Q:讲一下Zookeeper的读写机制。 Leader主机负责读和写。 Follower负责读，并将写操做转发给Leader。Follower还参与Leader选举投票，参与事务请求Proposal投票。 Observer充当观察者的角色。Observer和Follower的惟一区别在于：Observer不参与任何投票。 Q:讲一下Zookeeper的选举机制。 Leader不可用时，会从新选举Leader。超过半数的Follower选举投票便可，Observer不参与投票。 Q:大家的zookeeper集群配置了几个节点？ 3个节点。注意，zookeeper集群节点，最好是奇数个的。 集群中的zookeeper节点须要超过半数，整个集群对外才可用。 这里所谓的整个集群对外才可用，是指整个集群还能选出一个Leader来，zookeeper默认采用quorums来支持Leader的选举。 若是有2个zookeeper，那么只要有1个死了zookeeper就不能用了，由于1没有过半，因此2个zookeeper的死亡容忍度为0；同理，要是有3个zookeeper，一个死了，还剩下2个正常的，过半了，因此3个zookeeper的容忍度为1；同理你多列举几个：2->0;3->1;4->1;5->2;6->2会发现一个规律，2n和2n-1的容忍度是同样的，都是n-1，因此为了更加高效，何须增长那一个没必要要的zookeeper呢。 Q:zookeeper的集群节点，若是不是奇数的，可能会出现什么问题？ 可能会出现脑裂。 假死：因为心跳超时（网络缘由致使的）认为master死了，但其实master还存活着。 脑裂：因为假死会发起新的master选举，选举出一个新的master，但旧的master网络又通了，致使出现了两个master ，有的客户端链接到老的master 有的客户端连接到新的master。 详情见：https://my.oschina.net/wangen2009/blog/2994188 ###消息队列 Q:为何使用消息队列？消息队列有什么优势和缺点？Kafka、ActiveMQ、RabbitMq、RocketMQ 都有什么优势和缺点？ 消息队列解耦，削峰，限流。 Q:如何保证消息队列的高可用？ Q:如何保证消息不被重复消费？（如何保证消息消费的幂等性） Q:如何保证消息的可靠性传输？（如何处理消息丢失的问题） Q:如何保证消息的顺序性？ Q:如何解决消息队列的延时以及过时失效问题？消息队列满了之后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？ Q:若是让你写一个消息队列，该如何进行架构设计啊？说一下你的思路。

###Kafka
参考资料： Kafka 入门一篇文章就够了 Q:讲一下Kafka。 Kafka的简单理解 Q:Kafka相对其余消息队列，有什么特色？ 持久化：Kafka的持久化能力比较好，经过磁盘持久化。而RabbitMQ是经过内存持久化的。 吞吐量：Rocket的并发量很是高。 消息处理：RabbitMQ的消息不支持批量处理，而RocketMQ和Kafka支持批量处理。 高可用：RabbitMQ采用主从模式。Kafka也是主从模式，经过Zookeeper管理，选举Leader，还有Replication副本。 事务：RocketMQ支持事务，而Kafka和RabbitMQ不支持。 Q:Kafka有哪些模式？ 若是一个生产者或者多个生产者产生的消息可以被多个消费者同时消费的状况，这样的消息队列称为"发布订阅模式"的消息队列 Q:Kafka做为消息队列，有哪些优点？ 分布式的消息系统。 高吞吐量。即便存储了许多TB的消息，它也保持稳定的性能。 数据保留在磁盘上，所以它是持久的。 Q:Kafka为何处理速度会很快？ 零拷贝：Kafka 实现了"零拷贝"原理来快速移动数据，避免了内核之间的切换。 消息压缩、分批发送：Kafka 能够将数据记录分批发送，从生产者到文件系统（Kafka 主题日志）到消费者，能够端到端的查看这些批次的数据。 批处理可以进行更有效的数据压缩并减小 I/O 延迟。 顺序读写：Kafka 采起顺序写入磁盘的方式，避免了随机磁盘寻址的浪费。 Q:讲一下Kafka中的零拷贝。 数据的拷贝从内存拷贝到kafka服务进程那块，又拷贝到socket缓存那块，整个过程耗费的时间比较高，kafka利用了Linux的sendFile技术（NIO），省去了进程切换和一次数据拷贝，让性能变得更好。 Q:Kafka的偏移量是什么？ 消费者每次消费数据的时候，消费者都会记录消费的物理偏移量（offset）的位置。等到下次消费时，他会接着上次位置继续消费 Q:Kafka的生产者，是如何发送消息的？ 生产者的消息是先被写入分区中的缓冲区中，而后分批次发送给 Kafka Broker。 生产者的消息发送机制，有同步发送和异步发送。 同步发送消息都有个问题，那就是同一时间只能有一个消息在发送，这会形成许多消息没法直接发送，形成消息滞后，没法发挥效益最大化。 异步发送消息的同时可以对异常状况进行处理，生产者提供了Callback 回调。 Q:Kafka生产者发送消息，有哪些分区策略？ Kafka 的分区策略指的就是将生产者发送到哪一个分区的算法。 有顺序轮询、随机轮询、key-ordering 策略。 key-ordering 策略：Kafka 中每条消息都会有本身的key，一旦消息被定义了 Key，那么你就能够保证同一个 Key 的全部消息都进入到相同的分区里面，因为每一个分区下的消息处理都是有顺序的，故这个策略被称为按消息键保序策略。

Q:Kafka为何要分区？ 实现负载均衡和水平扩展。 Kafka能够将主题(Topic)划分为多个分区（Partition），会根据分区规则选择把消息存储到哪一个分区中，只要若是分区规则设置的合理，那么全部的消息将会被均匀的分布到不一样的分区中，这样就实现了负载均衡和水平扩展。另外，多个订阅者能够从一个或者多个分区中同时消费数据，以支撑海量数据处理能力。 Q:Kafka如何保证消息的顺序性？ Kafka 能够保证同一个分区里的消息是有序的。也就是说消息发送到一个Partition 是有顺序的。 Q:Kafka的消费者群组Consumer Group订阅了某个Topic，假如这个Topic接收到消息并推送，那整个消费者群组能收到消息吗？ http://kafka.apache.org/intro Kafka官网中有这样一句"Consumers label themselves with a consumer group name, and each record published to a topic is delivered to one consumer instance within each subscribing consumer group. " 表示推送到topic上的record，会被传递到已订阅的消费者群组里面的一个消费者实例。 Q:Kafka消息消费者宕机了，怎么确认有没有收到消息？ ack机制，若是接收方收到消息后，会返回一个确认字符。 Q:讲一下Kafka的ack机制。 acks 参数指定了要有多少个分区副本接收消息，生产者才认为消息是写入成功的。此参数对消息丢失的影响较大。 若是 acks = 0，就表示生产者也不知道本身产生的消息是否被服务器接收了，它才知道它写成功了。若是发送的途中产生了错误，生产者也不知道，它也比较懵逼，由于没有返回任何消息。这就相似于 UDP 的运输层协议，只管发，服务器接受不接受它也不关心。 若是 acks = 1，只要集群的 Leader 接收到消息，就会给生产者返回一条消息，告诉它写入成功。若是发送途中形成了网络异常或者 Leader 还没选举出来等其余状况致使消息写入失败，生产者会受到错误消息，这时候生产者每每会再次重发数据。由于消息的发送也分为 同步 和 异步，Kafka 为了保证消息的高效传输会决定是同步发送仍是异步发送。若是让客户端等待服务器的响应（经过调用 Future 中的 get() 方法），显然会增长延迟，若是客户端使用回调，就会解决这个问题。 若是 acks = all，这种状况下是只有当全部参与复制的节点都收到消息时，生产者才会接收到一个来自服务器的消息。不过，它的延迟比 acks =1 时更高，由于咱们要等待不仅一个服务器节点接收消息。 参考资料： https://juejin.im/post/5ddf5659518825782d599641 Q:Kafka如何避免消息丢失？ 1.生产者丢失消息的状况： 生产者(Producer) 调用send方法发送消息以后，消息可能由于网络问题并无发送过去。 因此，咱们不能默认在调用send方法发送消息以后消息消息发送成功了。为了肯定消息是发送成功，咱们要判断消息发送的结果。 能够采用为其添加回调函数的形式，获取回调结果。 若是消息发送失败的话，咱们检查失败的缘由以后从新发送便可！ 能够设置 Producer 的retries（重试次数）为一个比较合理的值，通常是 3 ，可是为了保证消息不丢失的话通常会设置比较大一点。 设置完成以后，当出现网络问题以后可以自动重试消息发送，避免消息丢失。 2.消费者丢失消息的状况： 当消费者拉取到了分区的某个消息以后，消费者会自动提交了 offset。自动提交的话会有一个问题， 试想一下，当消费者刚拿到这个消息准备进行真正消费的时候，忽然挂掉了，消息实际上并无被消费，可是 offset 却被自动提交了。 手动关闭闭自动提交 offset，每次在真正消费完消息以后以后再本身手动提交 offset 。 3.Kafka丢失消息： a.假如 leader 副本所在的 broker 忽然挂掉，那么就要从 follower 副本从新选出一个 leader ，可是 leader 的数据还有一些没有被 follower 副本的同步的话，就会形成消息丢失。 所以能够设置ack=all。 b.设置 replication.factor >= 3 为了保证 leader 副本能有 follower 副本能同步消息，咱们通常会为 topic 设置 replication.factor >= 3。这样就能够保证每一个 分区(partition) 至少有 3 个副本。虽然形成了数据冗余，可是带来了数据的安全性。 详情参考：https://blog.csdn.net/qq_34337272/article/details/104903388?fps=1&locationNum=2 Q:Kafka怎么保证可靠性？(存疑) 在Kafka中主要经过ISR机制来保证消息的可靠性。 ISR（in sync replica）：是Kafka动态维护的一组同步副本，在ISR中有成员存活时，只有这个组的成员才能够成为leader，内部保存的为每次提交信息时必须同步的副本（acks = all时），每当leader挂掉时，在ISR集合中选举出一个follower做为leader提供服务，当ISR中的副本被认为坏掉的时候，会被踢出ISR，当从新跟上leader的消息数据时，从新进入ISR。 详情见： https://www.jianshu.com/p/ebeaa7593d83 Q:Kafka怎么保证一致性？(存疑) 一致性定义：若某条消息对client可见，那么即便Leader挂了，在新Leader上数据依然能够被读到。 HW-HighWaterMark: client能够从Leader读到的最大msg offset，即对外可见的最大offset， HW=max(replica.offset) 对于Leader新收到的msg，client不能马上消费，Leader会等待该消息被全部ISR中的replica同步后，更新HW，此时该消息才能被client消费，这样就保证了若是Leader fail，该消息仍然能够重新选举的Leader中获取。 对于来自内部Broker的读取请求，没有HW的限制。同时，Follower也会维护一份本身的HW，Folloer.HW = min(Leader.HW, Follower.offset) 详情见：https://www.jianshu.com/p/f0449509fb11 Q:Kafka怎么处理重复消息？怎么避免重复消费？ 通常状况下，kafka重复消费都是因为未正常提交offset形成的。 使用的是spring-Kafka，因此把Kafka消费者的配置enable.auto.commit设为false，禁止Kafka自动提交offset，从而使用spring-Kafka提供的offset提交策略。 spring-Kafka中的offset提交策略能够保证一批消息数据没有完成消费的状况下，也能提交offset，从而避免了提交失败而致使永远重复消费的问题。

如何去重：将消息的惟一标识保存起来，每次消费时判断是否处理过便可。 Q:Kafka消息是采用pull模式，仍是push模式？ pull模式。 Q:pull模式和push模式，各有哪些特色？ pull模式，准确性？能够较大保证消费者能获取到消息。 push模式，即时性？能够在broker获取消息后立刻送达消费者。 Q:讲一下Kafka集群的Leader选举机制。 Kafka在Zookeeper上针对每一个Topic都维护了一个ISR（in-sync replica---已同步的副本）的集合，集合的增减Kafka都会更新该记录。若是某分区的Leader不可用，Kafka就从ISR集合中选择一个副本做为新的Leader。

###分库分表 Q:数据库如何处理海量数据？ 分库分表，主从架构，读写分离 Q:数据库分库分表，什么时候分？怎么分？ 水平分库/分表，垂直分库/分表 水平分库/表，各个库和表的结构如出一辙。 垂直分库/表，各个库和表的结构不同。 Q:读写分离怎么作？ 主机负责写，从机负责读。

###分布式、高并发场景 Q:在实践中，遇到过哪些并发的业务场景？ 秒杀。好比抢商品，抢红包。 Q:如何设计一个秒杀/抢券系统？ 能够经过队列配合异步处理实现秒杀。 使用redis的list，将商品push进队列，pop出队列。 异步操做不会阻塞，不会消耗太多时间。 Q:如何提升抢券系统的性能？ 使用多个list。 使用多线程从队列中拉取数据。 集群提升可用性。 MQ异步处理，削峰。 Q:秒杀怎么避免少卖或超卖？ redis是单进程单线程的，操做具备原子性，不会致使少卖或者超卖。 另外，也能够设置一个版本号version，乐观锁机制。

###系统架构与设计 Q:如何提升系统的并发能力？ 使用分布式系统。 部署多台服务器，并作负载均衡。 使用缓存(Redis)集群。 数据库分库分表 + 读写分离。 引入消息中间件集群。 Q:设计一个红包系统，须要考虑哪些问题，如何解决？(本质上也是秒杀系统) Q:若是让你设计一个消息队列，你会怎么设计？ ###SpringCloud(微服务) Q:你用过SpringCloud的哪些组件？ 服务协调，注册中心，熔断，降级，配置中心，网关。 Q:讲一下熔断和降级的区别？ Q:熔断有哪几种方隔离方式？ 线程池隔离。信号量隔离。 Q:Zuul网关，有什么功能？ Q:Zuul网关如何实现路由？ 参考资料： Java 工程师进阶知识彻底扫盲 【Java学习+面试指南】 石杉的架构笔记