精华内容
下载资源
问答
  • 最近整理了分布式面试题,一共有121道,后面会不断增加,争取做到全网最全的分布式面试题。大部分题目都是来自小伙伴们在面试中被问到后,反馈到我这里的。也由此可知,下一个被问到的估计就是你。分...

    最近整理了分布式面试题,一共有121道,后面会不断增加,争取做到全网最全的分布式面试题。大部分题目都是来自小伙伴们在面试中被问到后,反馈到我这里的。也由此可知,下一个被问到的估计就是你。

    分布式事务

    分布式事务相关面试题一共17道,后面不断完善。

    请说说你对分布式系统 CAP 理论的理解,CAP 分别代表什么含义?

    什么是二阶段提交?

    什么是三阶段提交?

    什么是补偿事务?

    你知道哪些分布式事务解决方案?

    为什么分布式系统的一致性和可用性不能同时满足?

    你是如何理解数据一致性的?数据一致性有哪几种模型?

    你在做系统设计时,如何选择实现强一致性还是弱一致性?

    在你的项目里,是如何设计分布式事务,实现最终一致性的?

    Sagas事务模型是什么?

    熟悉哪些分布式锁实现方案?

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

    哪种分布式锁实现方案更好?

    你了解数据库的 binlog 和 redolog 吗?是如何实现一致性的呢?

    分布式幂等性如何设计?

    简单一次完整的 HTTP 请求所经历的步骤?

    如何提高系统的并发能力?

    分布式微服务

    微服务模块一共搜集到面试题共42道,基本上已经覆盖完成,后期对这些题目做进步优化。

    为什么需要 Dubbo?

    Dubbo 的主要应用场景?

    Dubbo 的核心功能?

    Dubbo 服务注册与发现的流程?

    Dubbo 的服务调用流程?

    Dubbo 支持哪些协议,每种协议的应用场景、优缺点?

    Dubbo 有些哪些注册中心?

    Dubbo 如何实现服务治理?

    Dubbo 的注册中心集群挂掉,如何正常消费?

    Dubbo 集群提供了哪些负载均衡策略?

    Dubbo 的集群容错方案有哪些?

    Dubbo 支持哪些序列化方式?

    说说一次 Dubbo 服务请求流程?

    说说 Dubbo 工作原理

    注册中心挂了,consumer 还能不能调用 provider?

    怎么实现动态感知服务下线的呢?

    服务提供者没挂,但在注册中心里看不到?

    说说Dubbo的优先级配置

    负载平衡的意义什么?

    常见负载均衡算法有哪些?

    你知道哪些限流算法?

    说说什么是计数器(固定窗口)算法

    说说什么是滑动窗口算法

    说说什么是漏桶算法

    说说什么是令牌桶算法

    什么是微服务?

    Spring Cloud 的核心组件有哪些?

    Spring Cloud有什么优势?

    什么是服务熔断?什么是服务降级?

    Eureka和Zookeeper,作为注册中心,有什么区别

    Spring Boot和Spring Cloud的区别?

    什么是Hystrix?它如何实现容错?

    说说 RPC 的实现原理

    Eureka自我保护机制是什么?

    什么是Ribbon?

    什么是Feigin?它的优点是什么?

    Ribbon和Feign的区别?

    说说微服务之间是如何独立通讯的?

    Spring Cloud如何实现服务的注册?

    说说 Dubbo 与 Spring Cloud 的区别?

    简述一下什么是Nginx,它有什么优势和功能?

    Nginx是如何处理一个HTTP请求的呢?

    分布式存储

    共10道

    当高并发系统设计时,为什么要分库分表?

    用过哪些分库分表中间件?

    不同的分库分表中间件都有什么优点和缺点?

    如何对数据库进行垂直拆分或水平拆分?

    如果要设计一个可以动态扩容缩容的分库分表方案,应该如何做?

    数据库分库分表以后,如何处理设计主键生成器?

    不同的主键生成方式有什么区别?

    分布式ID生成有几种方案?

    分库分表第三方框架有哪些?

    分布式消息队列

    共27道

    为什么要使用消息队列?

    消息队列有什么缺点?

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

    如何保证消息不被重复消费?

    如何保证消费的时候是幂等?

    如何保证消息的可靠性传输?

    传输过程出现消息丢失了怎么办?

    如何保证消息的顺序性?

    如何解决消息队列的延时问题?

    如何解决消息队列的过期失效问题?

    消息队列满了以后该怎么处理?

    有几百万消息持续积压几小时,应该怎么解决?

    如果让你写一个消息队列,该如何进行架构设计?

    以 Kafka 为例,可以提出以下的问题:

    描述一下 Kafka 的设计架构?

    Kafka、ActiveMQ、RabbitMQ、RocketMQ 之间都有什么区别?

    Kafka 消费端是否可能出现重复消费问题?

    Kafka 为什么会分区?

    Kafka 如何保证数据一致性?

    Kafka 中 ISR、OSR、AR 是什么?

    Kafka 在什么情况下会出现消息丢失?

    Kafka 消息是采用 Pull 模式,还是 Push 模式?

    Kafka 如何和 ZooKeeper 进行交互?

    Kafka 是如何实现高吞吐率的?

    如果是 RocketMQ,很多问题都是类似的,可以从以下的问题出发进行考察:

    RocketMQ 和 ActiveMQ 有哪些区别?

    为什么 RocketMQ 不会丢失消息?

    RocketMQ 的事务消息都有哪些应用?

    RocketMQ 是怎么保证系统高可用的?

    分布式缓存

    共25道

    缓存雪崩、缓存穿透如何理解?

    如何在业务中避免相关问题?

    如何保证数据库与缓存的一致性?

    如何进行缓存预热?

    缓存集群如何失效?

    一致性哈希有哪些应用?

    缓存如何监控和优化热点 key?

    Redis 有哪些数据结构?

    Redis 和 Memcached 有哪些区别?

    单线程的 Redis 如何实现高性能读写?

    Redis 支持事务吗?

    Redis 的管道如何实现?

    Redis 有哪些失效策略?

    Redis 的主从复制如何实现?

    Redis 的 Sentinel 有哪些应用?

    Redis 集群有哪几种方式?

    Redis 和 memcached 什么区别?

    Redis 的集群模式如何实现?

    Redis 的 key 是如何寻址的?

    Redis 的持久化底层如何实现?

    Redis 过期策略都有哪些?

    缓存与数据库不一致怎么办?

    Redis 常见的性能问题和解决方案?

    使用 Redis 如何实现异步队列?

    Redis 如何实现延时队列?

    总结

    目前就整理这5大模块,后面还会继续完善,赶紧关注起来。

    获取方式

    进入下方公众号,回复“0531”即可获取。

    展开全文
  • 分布式分为分布式缓存(Redis)、分布式锁(Redis 或 Zookeeper)、分布式服务(Dubbo 或 SpringCloud)、分布式服务协调(Zookeeper)、分布式消息队列(Kafka 、RabbitMq)、分布式 Session 、分布式事务、分布式搜索...

    分布式分为分布式缓存(Redis)、分布式锁(Redis 或 Zookeeper)、分布式服务(Dubbo 或 SpringCloud)、分布式服务协调(Zookeeper)、分布式消息队列(Kafka 、RabbitMq)、分布式 Session 、分布式事务、分布式搜索(Elasticsearch)等。不可能所有分布式内容都熟悉,一定要在某个领域有所专长。

    一、分布式理论

    问:分布式有哪些理论?

    CAP 、BASE。分布式 CAP 理论,任何一个分布式系统都无法同时满足 Consistency(一致性)、Availability(可用性)、Partition tolerance(分区容错性) 这三个基本需求。最多只能满足其中两项。而 Partition tolerance(分区容错性) 是必须的,因此一般是 CP ,或者 AP。

    问:你怎么理解分布式一致性?

    数据一致性通常指关联数据之间的逻辑关系是否正确和完整。在分布式系统中,数据一致性往往指的是由于数据的复制,不同数据节点中的数据内容是否完整并且相同。

    一致性还分为强一致性,弱一致性,还有最终一致性。强一致性就是马上就保持一致。

    最终一致性是指经过一段时间后,可以保持一致。

    二、分布式事务

    问:你怎么理解分布式事务?分布式事务的协议有哪些?

    分布式事务是指会涉及到操作多个数据库的事务。目的是为了保证分布式系统中的数据一致性。分布式事务类型:二阶段提交 2PC ,三阶段提交 3PC。

    2PC :第一阶段:准备阶段(投票阶段)和第二阶段:提交阶段(执行阶段)。

    3PC :三个阶段:CanCommit 、PreCommit 、DoCommit。

    问:分布式事务的解决方案有哪些?

    分布式事务解决方案:补偿机制 TCC 、XA 、消息队列 MQ。

    问:讲一下 TCC。

    T(Try)锁资源:锁定某个资源,设置一个预备类的状态,冻结部分数据。

    比如,订单的支付状态,先把状态修改为"支付中(PAYING)"。

    比如,本来库存数量是 100 ,现在卖出了 2 个,不要直接扣减这个库存。在一个单独的冻结库存的字段,比如 prepare _ remove _ stock 字段,设置一个 2。也就是说,有 2 个库存是给冻结了。

    积分服务的也是同理,别直接给用户增加会员积分。你可以先在积分表里的一个预增加积分字段加入积分。

    比如:用户积分原本是 1190 ,现在要增加 10 个积分,别直接 1190 + 10 = 1200 个积分啊!你可以保持积分为 1190 不变,在一个预增加字段里,比如说 prepare _ add _ credit 字段,设置一个 10 ,表示有 10 个积分准备增加。

    C(Confirm):在各个服务里引入了一个 TCC 分布式事务的框架,事务管理器可以感知到各个服务的 Try 操作是否都成功了。假如都成功了, TCC 分布式事务框架会控制进入 TCC 下一个阶段,第一个 C 阶段,也就是 Confirm 阶段。此时,需要把 Try 阶段锁住的资源进行处理。

    比如,把订单的状态设置为“已支付(Payed)”。

    比如,扣除掉相应的库存。

    比如,增加用户积分。

    C(Cancel):在 Try 阶段,假如某个服务执行出错,比如积分服务执行出错了,那么服务内的 TCC 事务框架是可以感知到的,然后它会决定对整个 TCC 分布式事务进行回滚。

    TCC 分布式事务框架只要感知到了任何一个服务的 Try 逻辑失败了,就会跟各个服务内的 TCC 分布式事务框架进行通信,然后调用各个服务的 Cancel 逻辑。也就是说,会执行各个服务的第二个 C 阶段, Cancel 阶段。

    比如,订单的支付状态,先把状态修改为" closed "状态。

    比如,冻结库存的字段, prepare _ remove _ stock 字段,将冻结的库存 2 清零。

    比如,预增加积分的字段, prepare _ add _ credit 字段,将准备增加的积分 10 清零。

    问:事务管理器宕掉了,怎么办?

    做冗余,设置多个事务管理器,一个宕掉了,其他的还可以用。

    问:怎么保证分布式系统的幂等性?

    状态机制。版本号机制。

    三、Redis

    问:Redis 有哪些优势?

    速度快,因为数据存在内存中。

    支持丰富数据类型,支持 string、list、set 、sorted set、hash。

    支持事务,操作都是原子性,所谓的原子性就是对数据的更改要么全部执行,要么全部不执行。

    丰富的特性:可用于缓存,消息,按 key 设置过期时间,过期后将会自动删除。

    单线程,单进程,采用 IO 多路复用技术。

    问:Redis 的存储结构是怎样的?

    key-value 键值对。

    问:Redis 支持哪些数据结构?

    string(字符串), hash(哈希), list(队列), set(集合)及 zset(sorted set 有序集合)。

    问:Redis 的数据结构,有哪些应用场景?

    string:简单地 get / set 缓存。

    hash:可以缓存用户资料。比如命令:hmset user1 name "lin" sex "male" age "25" ,缓存用户 user1 的资料,姓名为 lin ,性别为男,年龄 25。

    list:可以做队列。往 list 队列里面 push 数据,然后再 pop 出来。

    zset:可以用来做排行榜。

    问:Redis 的数据结构,底层分别是由什么实现的?

    Redis 字符串,却不是 C 语言中的字符串(即以空字符 ’\0’ 结尾的字符数组),它是自己构建了一种名为 简单动态字符串(simple dynamic string , SDS)的抽象类型,并将 SDS 作为 Redis 的默认字符串表示。

    Redi List ,底层是 ZipList ,不满足 ZipList 就使用双向链表。ZipList 是为了节约内存而开发的。和各种语言的数组类似,它是由连续的内存块组成的,这样一来,由于内存是连续的,就减少了很多内存碎片和指针的内存占用,进而节约了内存。

    问:Redis 怎么保证可靠性?Redis 的持久化方式有哪些?有哪些优缺点?

    一个可靠安全的系统,肯定要考虑数据的可靠性,尤其对于内存为主的 Redis ,就要考虑一旦服务器挂掉,启动之后,如何恢复数据的问题,也就是说数据如何持久化的问题。

    AOF 就是备份操作记录。AOF 由于是备份操作命令,备份快、恢复慢。

    AOF 的优点:AOF 更好保证数据不会被丢失,最多只丢失一秒内的数据。另外重写操作保证了数据的有效性,即使日志文件过大也会进行重写。AOF 的日志文件的记录可读性非常的高。

    AOF 的缺点:对于相同数量的数据集而言, AOF 文件通常要大于 RDB 文件。

    RDB 就是备份所有数据,使用了快照。RDB 恢复数据比较快。

    问:AOF 文件过大,怎么处理?

    会进行 AOF 文件重写。

    随着 AOF 文件越来越大,里面会有大部分是重复命令或者可以合并的命令。

    重写的好处:减少 AOF 日志尺寸,减少内存占用,加快数据库恢复时间。

    执行一个 AOF 文件重写操作,重写会创建一个当前 AOF 文件的体积优化版本。

    问:讲一下 Redis 的事务。

    先以 MULTI 开始一个事务, 然后将多个命令入队到事务中, 最后由 EXEC 命令触发事务, 一并执行事务中的所有命令。如果想放弃这个事务,可以使用 DISCARD 命令。

    问:Redis 事务无法回滚,那怎么处理?

    问:怎么设置 Redis 的 key 过期时间?

    key 的的过期时间通过 EXPIRE key seconds 命令来设置数据的过期时间。返回 1 表明设置成功,返回 0 表明 key 不存在或者不能成功设置过期时间。

    问:Redis 的过期策略有哪些?

    惰性删除:当读/写一个已经过期的 key 时,会触发惰性删除策略,直接删除掉这个过期 key ,并按照 key 不存在去处理。惰性删除,对内存不太好,已经过期的 key 会占用太多的内存。

    定期删除:每隔一段时间,就会对 Redis 进行检查,主动删除一批已过期的 key。

    问:为什么 Redis 不使用定时删除?

    定时删除,就是在设置 key 的过期时间的同时,创建一个定时器,让定时器在过期时间来临时,立即执行对 key 的删除操作。

    定时删会占用 CPU ,影响服务器的响应时间和性能。

    问:Redis 的内存回收机制都有哪些?

    当前已用内存超过 maxmemory 限定时,会触发主动清理策略,也就是 Redis 的内存回收策略。

    LRU 、TTL。

    noeviction :默认策略,不会删除任何数据,拒绝所有写入操作并返回客户端错误信息,此时 Redis 只响应读操作。

    volatitle - lru :根据 LRU 算法删除设置了超时属性的键,知道腾出足够空间为止。如果没有可删除的键对象,回退到 noeviction 策略。

    allkeys - lru :根据 LRU 算法删除键,不管数据有没有设置超时属性,直到腾出足够空间为止。

    allkeys - random :随机删除所有键,知道腾出足够空间为止。

    volatitle - random :随机删除过期键,知道腾出足够空间为止。

    volatitle - ttl :根据键值对象的 ttl 属性,删除最近将要过期数据。如果没有,回退到 noeviction 策略。

    问:手写一下 LRU 算法。

    问:Redis 的搭建有哪些模式?

    主从模式、哨兵模式、Cluster(集群)模式。最好是用集群模式。

    问:你用过的 Redis 是多主多从的,还是一主多从的?集群用到了多少节点?用到了多少个哨兵?

    集群模式。三主三从。

    问:Redis 采用多主多从的集群模式,各个主节点的数据是否一致?

    问:Redis 集群有哪些特性

    master 和 slaver。主从复制。读写分离。哨兵模式。

    问:Redis 是怎么进行水平扩容的?

    问:Redis 集群数据分片的原理是什么?

    Redis 数据分片原理是哈希槽(hash slot)。

    Redis 集群有 16384 个哈希槽。每一个 Redis 集群中的节点都承担一个哈希槽的子集。

    哈希槽让在集群中添加和移除节点非常容易。例如,如果我想添加一个新节点 D ,我需要从节点 A 、B、C 移动一些哈希槽到节点 D。同样地,如果我想从集群中移除节点 A ,我只需要移动 A 的哈希槽到 B 和 C。当节点 A 变成空的以后,我就可以从集群中彻底删除它。因为从一个节点向另一个节点移动哈希槽并不需要停止操作,所以添加和移除节点,或者改变节点持有的哈希槽百分比,都不需要任何停机时间(downtime)。

    问:讲一下一致性 Hash 算法。

    一致性 Hash 算法将整个哈希值空间组织成一个虚拟的圆环, 我们对 key 进行哈希计算,使用哈希后的结果对 2 ^ 32 取模,hash 环上必定有一个点与这个整数对应。依此确定此数据在环上的位置,从此位置沿环顺时针“行走”,第一台遇到的服务器就是其应该定位到的服务器。

    一致性 Hash 算法对于节点的增减都只需重定位环空间中的一小部分数据,具有较好的容错性和可扩展性。

    比如,集群有四个节点 Node A 、B 、C 、D ,增加一台节点 Node X。Node X 的位置在 Node B 到 Node C 直接,那么受到影响的仅仅是 Node B 到 Node X 间的数据,它们要重新落到 Node X 上。

    所以一致性哈希算法对于容错性和扩展性有非常好的支持。

    问:为什么 Redis Cluster 分片不使用 Redis 一致性 Hash 算法?

    一致性哈希算法也有一个严重的问题,就是数据倾斜。

    如果在分片的集群中,节点太少,并且分布不均,一致性哈希算法就会出现部分节点数据太多,部分节点数据太少。也就是说无法控制节点存储数据的分配。

    问:集群的拓扑结构有没有了解过?集群是怎么连接的?

    无中心结构。Redis-Cluster 采用无中心结构,每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。

    问:讲一下 Redis 主从复制的过程。

    从机发送 SYNC(同步)命令,主机接收后会执行 BGSAVE(异步保存)命令备份数据。

    主机备份后,就会向从机发送备份文件。主机之后还会发送缓冲区内的写命令给从机。

    当缓冲区命令发送完成后,主机执行一条写命令,就会往从机发送同步写入命令。

    问:讲一下 Redis 哨兵机制。

    下面是 Redis 官方文档对于哨兵功能的描述:

    监控(Monitoring):哨兵会不断地检查主节点和从节点是否运作正常。

    自动故障转移(Automatic Failover):当主节点不能正常工作时,哨兵会开始自动故障转移操作,它会将失效主节点的其中一个从节点升级为新的主节点,并让其他从节点改为复制新的主节点。

    配置提供者(Configuration Provider):客户端在初始化时,通过连接哨兵来获得当前 Redis 服务的主节点地址。

    通知(Notification):哨兵可以将故障转移的结果发送给客户端。

    问:讲一下布隆过滤器。

    布隆过滤器的主要是由一个很长的二进制向量和若干个(k 个)散列映射函数组成。因为每个元数据的存储信息值固定,而且总的二进制向量固定。所以在内存占用和查询时间上都远远超过一般的算法。当然存在一定的不准确率(可以控制)和不容易删除样本数据。

    布隆过滤器的优点:大批量数据去重,特别的占用内存。但是用布隆过滤器(Bloom Filter)会非常的省内存。

    布隆过滤器的特点:当布隆过滤器说某个值存在时,那可能就不存在,如果说某个值不存在时,那肯定就是不存在了。

    布隆过滤器的应用场景:新闻推送(不重复推送)。解决缓存穿透的问题。

    四、缓存

    问:缓存雪崩是什么?

    如果缓存数据设置的过期时间是相同的,并且 Redis 恰好将这部分数据全部删光了。这就会导致在这段时间内,这些缓存同时失效,全部请求到数据库中。这就是缓存雪崩。

    问:怎么解决缓存雪崩?

    解决方法:在缓存的时候给过期时间加上一个随机值,这样就会大幅度的减少缓存在同一时间过期。

    问:缓存穿透是什么?

    缓存穿透是指查询一个一定不存在的数据。由于缓存不命中,并且出于容错考虑,如果从数据库查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到数据库去查询,失去了缓存的意义。

    问:怎么解决缓存穿透?

    问:什么是缓存与数据库双写一致问题?

    问:如何保证缓存与数据库的一致性?

    读的时候,先读缓存,缓存没有的话,就读数据库,然后取出数据后放入缓存,同时返回响应。

    先删除缓存,再更新数据库。

    问:为什么是先删除缓存,而不是先更新缓存?

    问:先更新数据库,再删除缓存,会有什么问题?

    先更新数据库,再删除缓存。可能出现以下情况:

    如果更新完数据库, Java 服务提交了事务,然后挂掉了,那 Redis 还是会执行,这样也会不一致。

    如果更新数据库成功,删除缓存失败了,那么会导致数据库中是新数据,缓存中是旧数据,数据就出现了不一致。

    先删除缓存,再更新数据库。

    如果删除缓存失败,那就不更新数据库,缓存和数据库的数据都是旧数据,数据是一致的。

    如果删除缓存成功,而数据库更新失败了,那么数据库中是旧数据,缓存中是空的,数据不会不一致。因为读的时候缓存没有,所以去读了数据库中的旧数据,然后更新到缓存中。

    问:先删除缓存,在写数据库成功之前,如果有读请求发生,可能导致旧数据入缓存,引发数据不一致,怎么处理?

    分布式锁

    问:Redis 如何实现分布式锁?

    使用 set key value ex nx 命令。

    当 key 不存在时,将 key 的值设为 value ,返回 1。若给定的 key 已经存在,则 setnx 不做任何动作,返回 0。

    当 setnx 返回 1 时,表示获取锁,做完操作以后 del key ,表示释放锁,如果 setnx 返回 0 表示获取锁失败。

    详细的命令如下:

    set key value [EX seconds] [PX milliseconds] [NX|XX]

    EX seconds:设置失效时长,单位秒

    PX milliseconds:设置失效时长,单位毫秒

    NX:key不存在时设置value,成功返回OK,失败返回(nil)

    XX:key存在时设置value,成功返回OK,失败返回(nil)。

    示例如下:

    set name fenglin ex 100 nx

    问:为什么不先 set nx ,然后再使用 expire 设置超时时间?

    我们需要保证 setnx 命令和 expire 命令以原子的方式执行,否则如果客户端执行 setnx 获得锁后,这时客户端宕机了,那么这把锁没有设置过期时间,导致其他客户端永远无法获得锁了。

    问:使用 Redis 分布式锁, key 和 value 分别设置成什么?

    value 可以使用 json 格式的字符串,示例:

    {

    "count":1,

    "expireAt":147506817232,

    "jvmPid":22224,

    "mac":"28-D2-44-0E-0D-9A",

    "threadId":14

    }

    问:Redis 实现的分布式锁,如果某个系统获取锁后,宕机了怎么办?

    系统模块宕机的话,可以通过设置过期时间(就是设置缓存失效时间)解决。系统宕机时锁阻塞,过期后锁释放。

    问:设置缓存失效时间,那如果前一个线程把这个锁给删除了呢?

    问:如果加锁和解锁之间的业务逻辑执行的时间比较长,超过了锁过期的时间,执行完了,又删除了锁,就会把别人的锁给删了。怎么办?

    这两个属于锁超时的问题。

    可以将锁的 value 设置为 Json 字符串,在其中加入线程的 id 或者请求的 id ,在删除之前, get 一下这个 key ,判断 key 对应的 value 是不是当前线程的。只有是当前线程获取的锁,当前线程才可以删除。

    问:Redis 分布式锁,怎么保证可重入性?

    可以将锁的 value 设置为 Json 字符串,在其中加入线程的 id 和 count 变量。

    当 count 变量的值为 0 时,表示当前分布式锁没有被线程占用。

    如果 count 变量的值大于 0 ,线程 id 不是当前线程,表示当前分布式锁已经被其他线程占用。

    如果 count 变量的值大于 0 ,线程 id 是当前线程的 id ,表示当前线程已经拿到了锁,不必阻塞,可以直接重入,并将 count 变量的值加一即可。

    这种思路,其实就是参考了 ReentrantLock 可重入锁的机制。

    问:Redis 做分布式锁, Redis 做了主从,如果设置锁之后,主机在传输到从机的时候挂掉了,从机还没有加锁信息,如何处理?

    可以使用开源框架 Redisson ,采用了 redLock。

    问:讲一下 Redis 的 redLock。

    问:Zookeeper 是怎么实现分布式锁的?

    分布式锁:基于 Zookeeper 一致性文件系统,实现锁服务。锁服务分为保存独占及时序控制两类。

    保存独占:将 Zookeeper 上的一个 znode 看作是一把锁,通过 createznode 的方式来实现。所有客户端都去创建 / distribute _ lock 节点,最终成功创建的那个客户端也即拥有了这把锁。用完删除自己创建的 distribute _ lock 节点就释放锁。

    时序控制:基于/ distribute _ lock 锁,所有客户端在它下面创建临时顺序编号目录节点,和选 master 一样,编号最小的获得锁,用完删除,依次方便。

    更详细的回答如下:

    其实基于 Zookeeper ,就是使用它的临时有序节点来实现的分布式锁。

    原理就是:当某客户端要进行逻辑的加锁时,就在 Zookeeper 上的某个指定节点的目录下,去生成一个唯一的临时有序节点, 然后判断自己是否是这些有序节点中序号最小的一个,如果是,则算是获取了锁。如果不是,则说明没有获取到锁,那么就需要在序列中找到比自己小的那个节点,并对其调用 exist() 方法,对其注册事件监听,当监听到这个节点被删除了,那就再去判断一次自己当初创建的节点是否变成了序列中最小的。如果是,则获取锁,如果不是,则重复上述步骤。

    当释放锁的时候,只需将这个临时节点删除即可。

    五、Zookeeper

    问:Zookeeper 的原理是什么?

    问:Zookeeper 是怎么保证一致性的?

    zab 协议。

    zab 协议有两种模式,它们分别是恢复模式(选主)和广播模式(同步)。当服务启动或者在领导者崩溃后, zab 就进入了恢复模式,当领导者被选举出来,且大多数 server 完成了和 leader 的状态同步以后,恢复模式就结束了。状态同步保证了 leader 和 server 具有相同的系统状态。

    问:Zookeeper 有哪些应用场景?

    Zookeeper 可以作为服务协调的注册中心。还可以做分布式锁(如果没有用过分布式锁就不要说)。

    问:Zookeeper 为什么能做注册中心?

    Zookeeper 的数据模型是树型结构,由很多数据节点组成, zk 将全量数据存储在内存中,可谓是高性能,而且支持集群,可谓高可用。另外支持事件监听(watch 命令)。

    Zookeeper 可以作为一个数据发布/订阅系统。

    问:Zookeeper 的节点有哪些类型?有什么区别?

    临时节点,永久节点。更加细分就是临时有序节点、临时无序节点、永久有序节点、永久无序节点。

    临时节点:当创建临时节点的程序停掉之后,这个临时节点就会消失,存储的数据也没有了。

    问:Zookeeper 做为注册中心,主要存储哪些数据?存储在哪里?

    IP、端口、还有心跳机制。数据存储在 Zookeeper 的节点上面。

    问:心跳机制有什么用?

    问:Zookeeper 的广播模式有什么缺陷?

    广播风暴。

    问:讲一下 Zookeeper 的读写机制。

    Leader 主机负责读和写。

    Follower 负责读,并将写操作转发给 Leader。Follower 还参与 Leader 选举投票,参与事务请求 Proposal 投票。

    Observer 充当观察者的角色。Observer 和 Follower 的唯一区别在于:Observer 不参与任何投票。

    问:讲一下 Zookeeper 的选举机制。

    Leader 不可用时,会重新选举 Leader。超过半数的 Follower 选举投票即可,Observer 不参与投票。

    问:你们的 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 呢。

    问:Zookeeper 的集群节点,如果不是奇数可能会出现什么问题?

    可能会出现脑裂。

    假死:由于心跳超时(网络原因导致的)认为 master 死了,但其实 master 还存活着。

    脑裂:由于假死会发起新的 master 选举,选举出一个新的 master ,但旧的 master 网络又通了,导致出现了两个 master ,有的客户端连接到老的 master 有的客户端链接到新的 master。

    六、消息队列

    问:为什么使用消息队列?消息队列有什么优点和缺点?Kafka 、ActiveMQ 、RabbitMq 、RocketMQ 都有什么优点和缺点?

    消息队列解耦,削峰,限流。

    问:如何保证消息队列的高可用?(多副本)

    问:如何保证消息不被重复消费?(如何保证消息消费的幂等性)

    问:如何保证消息的可靠性传输?(如何处理消息丢失的问题)

    问:如何保证消息的顺序性?

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

    问:如果让你写一个消息队列,该如何进行架构设计啊?说一下你的思路。

    七、Kafka

    问:讲一下 Kafka。

    Kafka 的简单理解

    问:Kafka 相对其他消息队列,有什么特点?

    持久化:Kafka 的持久化能力比较好,通过磁盘持久化。而 RabbitMQ 是通过内存持久化的。

    吞吐量:Rocket 的并发量非常高。

    消息处理:RabbitMQ 的消息不支持批量处理,而 RocketMQ 和 Kafka 支持批量处理。

    高可用:RabbitMQ 采用主从模式。Kafka 也是主从模式,通过 Zookeeper 管理,选举 Leader ,还有 Replication 副本。

    事务:RocketMQ 支持事务,而 Kafka 和 RabbitMQ 不支持。

    问:Kafka 有哪些模式?

    如果一个生产者或者多个生产者产生的消息能够被多个消费者同时消费的情况,这样的消息队列称为"发布订阅模式"的消息队列。

    问:Kafka 作为消息队列,有哪些优势?

    分布式的消息系统。

    高吞吐量。即使存储了许多 TB 的消息,它也保持稳定的性能。

    数据保留在磁盘上,因此它是持久的。

    问:Kafka 为什么处理速度会很快?kafka 的吞吐量为什么高?

    零拷贝:Kafka 实现了"零拷贝"原理来快速移动数据,避免了内核之间的切换。

    消息压缩、分批发送:Kafka 可以将数据记录分批发送,从生产者到文件系统(Kafka 主题日志)到消费者,可以端到端的查看这些批次的数据。

    批处理能够进行更有效的数据压缩并减少 I / O 延迟。

    顺序读写:Kafka 采取顺序写入磁盘的方式,避免了随机磁盘寻址的浪费。

    问:讲一下 Kafka 中的零拷贝。

    数据的拷贝从内存拷贝到 kafka 服务进程那块,又拷贝到 socket 缓存那块,整个过程耗费的时间比较高, kafka 利用了 Linux 的 sendFile 技术(NIO),省去了进程切换和一次数据拷贝,让性能变得更好。

    问:Kafka 的偏移量是什么?

    消费者每次消费数据的时候,消费者都会记录消费的物理偏移量(offset)的位置。等到下次消费时,他会接着上次位置继续消费

    问:Kafka 的生产者,是如何发送消息的?

    生产者的消息是先被写入分区中的缓冲区中,然后分批次发送给 Kafka Broker。

    生产者的消息发送机制,有同步发送和异步发送。

    同步发送消息都有个问题,那就是同一时间只能有一个消息在发送,这会造成许多消息。

    无法直接发送,造成消息滞后,无法发挥效益最大化。

    异步发送消息的同时能够对异常情况进行处理,生产者提供了 Callback 回调。

    问:Kafka 生产者发送消息,有哪些分区策略?

    Kafka 的分区策略指的就是将生产者发送到哪个分区的算法。有顺序轮询、随机轮询、key - ordering 策略。

    key - ordering 策略:Kafka 中每条消息都会有自己的 key ,一旦消息被定义了 Key ,那么你就可以保证同一个 Key 的所有消息都进入到相同的分区里面,由于每个分区下的消息处理都是有顺序的,故这个策略被称为按消息键保序策略。

    问:Kafka 为什么要分区?

    实现负载均衡和水平扩展。Kafka 可以将主题(Topic)划分为多个分区(Partition),会根据分区规则选择把消息存储到哪个分区中,只要如果分区规则设置的合理,那么所有的消息将会被均匀的分布到不同的分区中,这样就实现了负载均衡和水平扩展。另外,多个订阅者可以从一个或者多个分区中同时消费数据,以支撑海量数据处理能力。

    问:Kafka 是如何在 Broker 间分配分区的?

    在 broker 间平均分布分区副本。

    假设有 6 个 broker ,打算创建一个包含 10 个分区的 Topic ,复制系数为 3 ,那么 Kafka 就会有 30 个分区副本,它可以被分配给这 6 个 broker ,这样的话,每个 broker 可以有 5 个副本。

    要确保每个分区的每个副本分布在不同的 broker 上面:

    假设 Leader 分区 0 会在 broker1 上面, Leader 分区 1 会在 broker2 上面, Leder 分区 2 会在 broker3 上面。

    接下来会分配跟随者副本。如果分区 0 的第一个 Follower 在 broker2 上面,第二个 Follower 在 broker3 上面。分区 1 的第一个 Follower 在 broker3 上面,第二个 Follower 在 broker4 上面。

    问:Kafka 如何保证消息的顺序性?

    Kafka 可以保证同一个分区里的消息是有序的。也就是说消息发送到一个 Partition 是有顺序的。

    问:Kafka 的消费者群组 Consumer Group 订阅了某个 Topic ,假如这个 Topic 接收到消息并推送,那整个消费者群组能收到消息吗?

    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 ,会被传递到已订阅的消费者群组里面的一个消费者实例。

    问:如何提高 Kafka 的消费速度?

    问:Kafka 出现消息积压,有哪些原因?怎么解决?

    出现消息积压,可能是因为消费的速度太慢。

    扩容消费者。之所以消费延迟大,就是消费者处理能力有限,可以增加消费者的数量。

    扩大分区。一个分区只能被消费者群组中的一个消费者消费。消费者扩大,分区最好多随之扩大。

    问:Kafka 消息消费者宕机了,怎么确认有没有收到消息?

    ACK 机制,如果接收方收到消息后,会返回一个确认字符。

    问:讲一下 Kafka 的 ACK 机制。

    acks 参数指定了要有多少个分区副本接收消息,生产者才认为消息是写入成功的。此参数对消息丢失的影响较大。

    如果 acks = 0 ,就表示生产者也不知道自己产生的消息是否被服务器接收了,它才知道它写成功了。如果发送的途中产生了错误,生产者也不知道,它也比较懵逼,因为没有返回任何消息。这就类似于 UDP 的运输层协议,只管发,服务器接受不接受它也不关心。

    如果 acks = 1 ,只要集群的 Leader 接收到消息,就会给生产者返回一条消息,告诉它写入成功。如果发送途中造成了网络异常或者 Leader 还没选举出来等其他情况导致消息写入失败,生产者会受到错误消息,这时候生产者往往会再次重发数据。因为消息的发送也分为 同步 和 异步, Kafka 为了保证消息的高效传输会决定是同步发送还是异步发送。如果让客户端等待服务器的响应(通过调用 Future 中的 get() 方法),显然会增加延迟,如果客户端使用回调,就会解决这个问题。

    如果 acks = all ,这种情况下是只有当所有参与复制的节点都收到消息时,生产者才会接收到一个来自服务器的消息。不过,它的延迟比 acks = 1 时更高,因为我们要等待不只一个服务器节点接收消息。

    问: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 个副本。虽然造成了数据冗余,但是带来了数据的安全性。

    问:Kafka 怎么保证可靠性?

    多副本以及 ISR 机制。

    在 Kafka 中主要通过 ISR 机制来保证消息的可靠性。

    ISR(in sync replica):是 Kafka 动态维护的一组同步副本,在 ISR 中有成员存活时,只有这个组的成员才可以成为 leader ,内部保存的为每次提交信息时必须同步的副本(acks = all 时),每当 leader 挂掉时,在 ISR 集合中选举出一个 follower 作为 leader 提供服务,当 ISR 中的副本被认为坏掉的时候,会被踢出 ISR ,当重新跟上 leader 的消息数据时,重新进入 ISR。

    问:什么是 HW ?

    HW(high watermark):副本的高水印值, replica 中 leader 副本和 follower 副本都会有这个值,通过它可以得知副本中已提交或已备份消息的范围, leader 副本中的 HW ,决定了消费者能消费的最新消息能到哪个 offset。

    问:什么是 LEO ?

    LEO(log end offset):日志末端位移,代表日志文件中下一条待写入消息的 offset ,这个 offset 上实际是没有消息的。不管是 leader 副本还是 follower 副本,都有这个值。

    问: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).

    问:Kafka 怎么处理重复消息?怎么避免重复消费?

    偏移量 offset :消费者每次消费数据的时候,消费者都会记录消费的物理偏移量(offset)的位置。等到下次消费时,他会接着上次位置继续消费。

    一般情况下, Kafka 重复消费都是由于未正常提交 offset 造成的,比如网络异常,消费者宕机之类的。

    使用的是 spring-Kafka ,所以把 Kafka 消费者的配置 enable.auto. commit 设为 false ,禁止 Kafka 自动提交 offset ,从而使用 spring-Kafka 提供的 offset 提交策略。

    sprin-Kafka 中的 offset 提交策略可以保证一批消息数据没有完成消费的情况下,也能提交 offset ,从而避免了提交失败而导致永远重复消费的问题。

    问:怎么避免重复消费?

    将消息的唯一标识保存起来,每次消费时判断是否处理过即可。

    问:如何保证消息不被重复消费?(如何保证消息消费的幂等性)

    怎么保证消息队列消费的幂等性?其实还是得结合业务来思考,有几个思路:

    比如你拿个数据要写库,你先根据主键查一下,如果这数据都有了,你就别插入了, update 一下好吧。

    比如你是写 Redis ,那没问题了,反正每次都是 set ,天然幂等性。

    如果是复杂一点的业务,那么每条消息加一个全局唯一的 id ,类似订单 id 之类的东西,然后消费到了之后,先根据这个 id 去比如 Redis 里查一下,之前消费过吗?

    如果没有消费过,你就处理,然后这个 id 写 Redis。如果消费过了,那你就别处理了,保证别重复处理相同的消息即可。

    问:Kafka 消息是采用 pull 模式,还是 push 模式?

    pull 模式。

    问:pull 模式和 push 模式,各有哪些特点?

    pull 模式,准确性?可以较大保证消费者能获取到消息。

    push 模式,即时性?可以在 broker 获取消息后马上送达消费者。

    问:Kafka 是如何存储消息的?

    Kafka 使用日志文件的方式来保存生产者和发送者的消息,每条消息都有一个 offset 值来表示它在分区中的偏移量。

    Kafka 中存储的一般都是海量的消息数据,为了避免日志文件过大,

    一个分片并不是直接对应在一个磁盘上的日志文件,而是对应磁盘上的一个目录。

    数据存储设计的特点在于以下几点:

    Kafka 把主题中一个分区划分成多个分段的小文件段,通过多个小文件段,就容易根据偏移量查找消息、定期清除和删除已经消费完成的数据文件,减少磁盘容量的占用;

    采用稀疏索引存储的方式构建日志的偏移量索引文件,并将其映射至内存中,提高查找消息的效率,同时减少磁盘 IO 操作;

    Kafka 将消息追加的操作逻辑变成为日志数据文件的顺序写入,极大的提高了磁盘 IO 的性能;

    问:讲一下 Kafka 集群的 Leader 选举机制。

    Kafka 在 Zookeeper 上针对每个 Topic 都维护了一个 ISR(in - sync replica ---已同步的副本)的集合,集合的增减 Kafka 都会更新该记录。如果某分区的 Leader 不可用, Kafka 就从 ISR 集合中选择一个副本作为新的 Leader。

    八、分库分表

    问:数据库如何处理海量数据?

    分库分表,主从架构,读写分离。

    问:数据库分库分表,何时分?怎么分?

    水平分库/分表,垂直分库/分表。

    水平分库/表,各个库和表的结构一模一样。

    垂直分库/表,各个库和表的结构不一样。

    问:读写分离怎么做?

    主机负责写,从机负责读。

    九、系统设计

    1、分布式、高并发场景

    遇到高并发场景,可以使用 Redis 缓存、Redis 限流、MQ 异步、MQ 削峰等。

    问:在实践中,遇到过哪些并发的业务场景?

    秒杀。比如抢商品,抢红包。

    2、秒杀

    问:如何设计一个秒杀/抢券系统?

    可以通过队列配合异步处理实现秒杀。

    使用 redis 的 list ,将商品 push 进队列, pop 出队列。

    异步操作不会阻塞,不会消耗太多时间。

    问:如何提高抢券系统的性能?

    使用多个 list。

    使用多线程从队列中拉取数据。

    集群提高可用性。

    MQ 异步处理,削峰。

    问:秒杀怎么避免少卖或超卖?

    redis 是单进程单线程的,操作具有原子性,不会导致少卖或者超卖。另外,也可以设置一个版本号 version ,乐观锁机制。

    问:考勤打卡,假如高峰期有几万人同时打卡,那么怎么应对这种高并发?

    使用 Redis 缓存。员工点击签到,可以在缓存中 set 状态。将工号作为 key ,打卡状态作为 value ,打卡成功为 01 ,未打卡或者打卡失败为 00 ,然后再将数据异步地写入到数据库里面就可以了。

    问:如何应对高峰期的超高并发量?

    Redis 限流。Redis 可以用计数器限流。使用 INCR 命令,每次都加一,处理完业务逻辑就减一。然后设置一个最大值,当达到最大值后就直接返回,不处理后续的逻辑。

    Redis 还可以用令牌桶限流。使用 Redis 队列,每十个数据中 push 一个令牌桶,每个请求进入后会先从队列中 pop 数据,如果是令牌就可以通行,不是令牌就直接返回。

    3、短链接

    问:如何将长链接转换成短链接,并发送短信?

    短 URL 从生成到使用分为以下几步:

    有一个服务,将要发送给你的长 URL 对应到一个短 URL 上.例如 www.baidu.com -> www.t.cn/1。

    把短 url 拼接到短信等的内容上发送。

    用户点击短 URL ,浏览器用 301 / 302 进行重定向,访问到对应的长 URL。

    展示对应的内容。

    问:长链接和短链接如何互相转换?

    思路是建立一个发号器。每次有一个新的长 URL 进来,我们就增加一。并且将新的数值返回.第一个来的 url 返回"www.x.cn/0",第二个返回"www.x.cn/1".

    问:长链接和短链接的对应关系如何存储?

    如果数据量小且 QPS 低,直接使用数据库的自增主键就可以实现。

    还可以将最近/最热门的对应关系存储在 K-V 数据库中,这样子可以节省空间的同时,加快响应速度。

    十、系统架构与设计

    问:如何提高系统的并发能力?

    使用分布式系统。

    部署多台服务器,并做负载均衡。

    使用缓存(Redis)集群。

    数据库分库分表 + 读写分离。

    引入消息中间件集群。

    问:设计一个红包系统,需要考虑哪些问题,如何解决?(本质上也是秒杀系统)

    问:如果让你设计一个消息队列,你会怎么设计?

    项目经验及数据量

    问:这个项目的亮点、难点在哪里?

    问:如果这个模块挂掉了怎么办?

    问:你们的项目有多少台机器?

    问:你们的项目有多少个实例?

    4 个实例。

    问:你们的系统 QPS(TPS)是多少?

    QPS ,每秒查询量。QPS 为几百/几千,已经算是比较高的了。

    TPS ,每秒处理事务数。TPS 即每秒处理事务数,包括:”用户请求服务器”、”服务器自己的内部处理”、”服务器返回给用户”,这三个过程,每秒能够完成 N 个这三个过程, TPS 也就是 3。

    问:一个接口,多少秒响应才正常?

    快的话几毫秒。慢的话 1-2 秒。异常情况可能会 10 几秒;最好保证 99 %以上的请求是正常的。

    问:这个接口的请求时间,大概多久?主要耗时在哪里?

    问:系统的数据量多少?有没有分库分表?

    正常情况下,几百万的数据量没有必要分库分表。只有超过几千万才需要分库分表。

    问:插入/更新一条数据要多久?更新十万/百万条数据要多久?

    插入/更新一条数据一般要几毫秒;更新十万条数据最好在 10 秒以内;

    百万条数据最好在 50-100 秒以内。

    展开全文
  • Java分布式面试题集合(收藏篇)

    千次阅读 2021-04-20 00:23:43
    分布式分为分布式缓存(Redis)、分布式锁(Redis 或 Zookeeper)、分布式服务(Dubbo 或 SpringCloud)、分布式服务协调(Zookeeper)、分布式消息队...

    分布式分为分布式缓存(Redis)、分布式锁(Redis 或 Zookeeper)、分布式服务(Dubbo 或 SpringCloud)、分布式服务协调(Zookeeper)、分布式消息队列(Kafka 、RabbitMq)、分布式 Session 、分布式事务、分布式搜索(Elasticsearch)等。不可能所有分布式内容都熟悉,一定要在某个领域有所专长。

    分布式理论

    问:分布式有哪些理论?

    CAP 、BASE。分布式 CAP 理论,任何一个分布式系统都无法同时满足 Consistency(一致性)、Availability(可用性)、Partition tolerance(分区容错性) 这三个基本需求。最多只能满足其中两项。而 Partition tolerance(分区容错性) 是必须的,因此一般是 CP ,或者 AP。

    问:你怎么理解分布式一致性?

    数据一致性通常指关联数据之间的逻辑关系是否正确和完整。在分布式系统中,数据一致性往往指的是由于数据的复制,不同数据节点中的数据内容是否完整并且相同。

    一致性还分为强一致性,弱一致性,还有最终一致性。强一致性就是马上就保持一致。
    最终一致性是指经过一段时间后,可以保持一致。

    分布式事务

    问:你怎么理解分布式事务?分布式事务的协议有哪些?

    分布式事务是指会涉及到操作多个数据库的事务。目的是为了保证分布式系统中的数据一致性。分布式事务类型:二阶段提交 2PC ,三阶段提交 3PC。

    •  2PC :第一阶段:准备阶段(投票阶段)和第二阶段:提交阶段(执行阶段)。

    •  3PC :三个阶段:CanCommit 、PreCommit 、DoCommit。

    问:分布式事务的解决方案有哪些?

    分布式事务解决方案:补偿机制 TCC 、XA 、消息队列 MQ。

    问:讲一下 TCC。


     T(Try)锁资源:锁定某个资源,设置一个预备类的状态,冻结部分数据。

    • 比如,订单的支付状态,先把状态修改为"支付中(PAYING)"。

    • 比如,本来库存数量是 100 ,现在卖出了 2 个,不要直接扣减这个库存。在一个单独的冻结库存的字段,比如 prepare _ remove _ stock 字段,设置一个 2。也就是说,有 2 个库存是给冻结了。

    • 积分服务的也是同理,别直接给用户增加会员积分。你可以先在积分表里的一个预增加积分字段加入积分。

    • 比如:用户积分原本是 1190 ,现在要增加 10 个积分,别直接 1190 + 10 = 1200 个积分啊!你可以保持积分为 1190 不变,在一个预增加字段里,比如说 prepare _ add _ credit 字段,设置一个 10 ,表示有 10 个积分准备增加。

    C(Confirm):在各个服务里引入了一个 TCC 分布式事务的框架,事务管理器可以感知到各个服务的 Try 操作是否都成功了。假如都成功了, TCC 分布式事务框架会控制进入 TCC 下一个阶段,第一个 C 阶段,也就是 Confirm 阶段。此时,需要把 Try 阶段锁住的资源进行处理。

    • 比如,把订单的状态设置为“已支付(Payed)”。

    • 比如,扣除掉相应的库存。

    • 比如,增加用户积分。

     C(Cancel):在 Try 阶段,假如某个服务执行出错,比如积分服务执行出错了,那么服务内的 TCC 事务框架是可以感知到的,然后它会决定对整个 TCC 分布式事务进行回滚。

    TCC 分布式事务框架只要感知到了任何一个服务的 Try 逻辑失败了,就会跟各个服务内的 TCC 分布式事务框架进行通信,然后调用各个服务的 Cancel 逻辑。也就是说,会执行各个服务的第二个 C 阶段, Cancel 阶段。

    • 比如,订单的支付状态,先把状态修改为" closed "状态。

    • 比如,冻结库存的字段, prepare _ remove _ stock 字段,将冻结的库存 2 清零。

    • 比如,预增加积分的字段, prepare _ add _ credit 字段,将准备增加的积分 10 清零。


    问:事务管理器宕掉了,怎么办?

    做冗余,设置多个事务管理器,一个宕掉了,其他的还可以用。

    问:怎么保证分布式系统的幂等性?

    状态机制。版本号机制。

    Redis 

    问:Redis 有哪些优势?

    1. 速度快,因为数据存在内存中。

    2. 支持丰富数据类型,支持 string、list、set 、sorted set、hash。

    3. 支持事务,操作都是原子性,所谓的原子性就是对数据的更改要么全部执行,要么全部不执行。

    4. 丰富的特性:可用于缓存,消息,按 key 设置过期时间,过期后将会自动删除。

    5. 单线程,单进程,采用 IO 多路复用技术。

    问:Redis 的存储结构是怎样的?

    key-value 键值对。

    问:Redis 支持哪些数据结构?

    string(字符串), hash(哈希), list(队列), set(集合)及 zset(sorted set 有序集合)。

    问:Redis 的数据结构,有哪些应用场景?

    • string:简单地 get / set 缓存。

    • hash:可以缓存用户资料。比如命令:hmset  user1 name "lin" sex "male"  age "25" ,缓存用户 user1 的资料,姓名为 lin ,性别为男,年龄 25。

    • list:可以做队列。往 list 队列里面 push 数据,然后再 pop 出来。

    • zset:可以用来做排行榜。


    问:Redis 的数据结构,底层分别是由什么实现的?

    • Redis 字符串,却不是 C 语言中的字符串(即以空字符 ’\0’ 结尾的字符数组),它是自己构建了一种名为 简单动态字符串(simple dynamic string , SDS)的抽象类型,并将 SDS 作为 Redis 的默认字符串表示。

    • Redi List ,底层是 ZipList ,不满足 ZipList 就使用双向链表。ZipList 是为了节约内存而开发的。和各种语言的数组类似,它是由连续的内存块组成的,这样一来,由于内存是连续的,就减少了很多内存碎片和指针的内存占用,进而节约了内存。


    问:Redis 怎么保证可靠性?Redis 的持久化方式有哪些?有哪些优缺点?

    一个可靠安全的系统,肯定要考虑数据的可靠性,尤其对于内存为主的 Redis ,就要考虑一旦服务器挂掉,启动之后,如何恢复数据的问题,也就是说数据如何持久化的问题。

    AOF 就是备份操作记录。AOF 由于是备份操作命令,备份快、恢复慢。

    AOF 的优点:AOF 更好保证数据不会被丢失,最多只丢失一秒内的数据。另外重写操作保证了数据的有效性,即使日志文件过大也会进行重写。AOF 的日志文件的记录可读性非常的高。

    AOF 的缺点:对于相同数量的数据集而言, AOF 文件通常要大于 RDB 文件。

    RDB 就是备份所有数据,使用了快照。RDB 恢复数据比较快。

    问:AOF 文件过大,怎么处理?

    会进行 AOF 文件重写。

    • 随着 AOF 文件越来越大,里面会有大部分是重复命令或者可以合并的命令。

    • 重写的好处:减少 AOF 日志尺寸,减少内存占用,加快数据库恢复时间。

    执行一个 AOF 文件重写操作,重写会创建一个当前 AOF 文件的体积优化版本。

    问:讲一下 Redis 的事务。

    先以 MULTI 开始一个事务, 然后将多个命令入队到事务中, 最后由 EXEC 命令触发事务, 一并执行事务中的所有命令。如果想放弃这个事务,可以使用 DISCARD 命令。

    问:Redis 事务无法回滚,那怎么处理?

    问:怎么设置 Redis 的 key 过期时间?

    key 的的过期时间通过 EXPIRE key seconds 命令来设置数据的过期时间。返回 1 表明设置成功,返回 0 表明 key 不存在或者不能成功设置过期时间。

    问:Redis 的过期策略有哪些?

    惰性删除:当读/写一个已经过期的 key 时,会触发惰性删除策略,直接删除掉这个过期 key ,并按照 key 不存在去处理。惰性删除,对内存不太好,已经过期的 key 会占用太多的内存。

    定期删除:每隔一段时间,就会对 Redis 进行检查,主动删除一批已过期的 key。

    问:为什么 Redis 不使用定时删除?

    定时删除,就是在设置 key 的过期时间的同时,创建一个定时器,让定时器在过期时间来临时,立即执行对 key 的删除操作。

    定时删会占用 CPU ,影响服务器的响应时间和性能。

    问:Redis 的内存回收机制都有哪些?

    当前已用内存超过 maxmemory 限定时,会触发主动清理策略,也就是 Redis 的内存回收策略。

    LRU 、TTL。

    noeviction :默认策略,不会删除任何数据,拒绝所有写入操作并返回客户端错误信息,此时 Redis 只响应读操作。

    • volatitle - lru :根据 LRU 算法删除设置了超时属性的键,知道腾出足够空间为止。如果没有可删除的键对象,回退到 noeviction 策略。

    • allkeys - lru :根据 LRU 算法删除键,不管数据有没有设置超时属性,直到腾出足够空间为止。

    • allkeys - random :随机删除所有键,知道腾出足够空间为止。

    • volatitle - random :随机删除过期键,知道腾出足够空间为止。

    • volatitle - ttl :根据键值对象的 ttl 属性,删除最近将要过期数据。如果没有,回退到 noeviction 策略。


    问:手写一下 LRU 算法。

    问:Redis 的搭建有哪些模式?

    主从模式、哨兵模式、Cluster(集群)模式。最好是用集群模式。

    问:你用过的 Redis 是多主多从的,还是一主多从的?集群用到了多少节点?用到了多少个哨兵?

    集群模式。三主三从。

    问:Redis 采用多主多从的集群模式,各个主节点的数据是否一致?


    问:Redis 集群有哪些特性

    master 和 slaver。主从复制。读写分离。哨兵模式。

    问:Redis 是怎么进行水平扩容的?


    问:Redis 集群数据分片的原理是什么?

    Redis 数据分片原理是哈希槽(hash slot)。

    Redis 集群有 16384 个哈希槽。每一个 Redis 集群中的节点都承担一个哈希槽的子集。

    哈希槽让在集群中添加和移除节点非常容易。例如,如果我想添加一个新节点 D ,我需要从节点 A 、B、C 移动一些哈希槽到节点 D。同样地,如果我想从集群中移除节点 A ,我只需要移动 A 的哈希槽到 B 和 C。当节点 A 变成空的以后,我就可以从集群中彻底删除它。因为从一个节点向另一个节点移动哈希槽并不需要停止操作,所以添加和移除节点,或者改变节点持有的哈希槽百分比,都不需要任何停机时间(downtime)。

    问:讲一下一致性 Hash 算法。

    一致性 Hash 算法将整个哈希值空间组织成一个虚拟的圆环, 我们对 key 进行哈希计算,使用哈希后的结果对 2 ^ 32 取模,hash 环上必定有一个点与这个整数对应。依此确定此数据在环上的位置,从此位置沿环顺时针“行走”,第一台遇到的服务器就是其应该定位到的服务器。

    一致性 Hash 算法对于节点的增减都只需重定位环空间中的一小部分数据,具有较好的容错性和可扩展性。

    比如,集群有四个节点 Node A 、B 、C 、D ,增加一台节点 Node X。Node X 的位置在 Node B 到 Node C 直接,那么受到影响的仅仅是 Node B 到 Node X 间的数据,它们要重新落到 Node X 上。

    所以一致性哈希算法对于容错性和扩展性有非常好的支持。

    问:为什么 Redis Cluster 分片不使用 Redis 一致性 Hash 算法?

    一致性哈希算法也有一个严重的问题,就是数据倾斜。

    如果在分片的集群中,节点太少,并且分布不均,一致性哈希算法就会出现部分节点数据太多,部分节点数据太少。也就是说无法控制节点存储数据的分配。

    问:集群的拓扑结构有没有了解过?集群是怎么连接的?

    无中心结构。Redis-Cluster 采用无中心结构,每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。

    问:讲一下 Redis 主从复制的过程。

    从机发送 SYNC(同步)命令,主机接收后会执行 BGSAVE(异步保存)命令备份数据。

    主机备份后,就会向从机发送备份文件。主机之后还会发送缓冲区内的写命令给从机。
    当缓冲区命令发送完成后,主机执行一条写命令,就会往从机发送同步写入命令。

    问:讲一下 Redis 哨兵机制。

    下面是 Redis 官方文档对于哨兵功能的描述:

    • 监控(Monitoring):哨兵会不断地检查主节点和从节点是否运作正常。

    • 自动故障转移(Automatic Failover):当主节点不能正常工作时,哨兵会开始自动故障转移操作,它会将失效主节点的其中一个从节点升级为新的主节点,并让其他从节点改为复制新的主节点。

    • 配置提供者(Configuration Provider):客户端在初始化时,通过连接哨兵来获得当前 Redis 服务的主节点地址。

    • 通知(Notification):哨兵可以将故障转移的结果发送给客户端。


    问:讲一下布隆过滤器。

    布隆过滤器的主要是由一个很长的二进制向量和若干个(k 个)散列映射函数组成。因为每个元数据的存储信息值固定,而且总的二进制向量固定。所以在内存占用和查询时间上都远远超过一般的算法。当然存在一定的不准确率(可以控制)和不容易删除样本数据。

    布隆过滤器的优点:大批量数据去重,特别的占用内存。但是用布隆过滤器(Bloom Filter)会非常的省内存。

    布隆过滤器的特点:当布隆过滤器说某个值存在时,那可能就不存在,如果说某个值不存在时,那肯定就是不存在了。

    布隆过滤器的应用场景:新闻推送(不重复推送)。解决缓存穿透的问题。

    缓存

    问:缓存雪崩是什么?

    如果缓存数据设置的过期时间是相同的,并且 Redis 恰好将这部分数据全部删光了。这就会导致在这段时间内,这些缓存同时失效,全部请求到数据库中。这就是缓存雪崩。

    问:怎么解决缓存雪崩?

    解决方法:在缓存的时候给过期时间加上一个随机值,这样就会大幅度的减少缓存在同一时间过期。

    问:缓存穿透是什么?

    缓存穿透是指查询一个一定不存在的数据。由于缓存不命中,并且出于容错考虑,如果从数据库查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到数据库去查询,失去了缓存的意义。

    问:怎么解决缓存穿透?

    问:什么是缓存与数据库双写一致问题?

    问:如何保证缓存与数据库的一致性?

    读的时候,先读缓存,缓存没有的话,就读数据库,然后取出数据后放入缓存,同时返回响应。

    先删除缓存,再更新数据库。

    问:为什么是先删除缓存,而不是先更新缓存?

    问:先更新数据库,再删除缓存,会有什么问题?

    先更新数据库,再删除缓存。可能出现以下情况:

    • 如果更新完数据库, Java 服务提交了事务,然后挂掉了,那 Redis 还是会执行,这样也会不一致。

    • 如果更新数据库成功,删除缓存失败了,那么会导致数据库中是新数据,缓存中是旧数据,数据就出现了不一致。

    先删除缓存,再更新数据库。

    • 如果删除缓存失败,那就不更新数据库,缓存和数据库的数据都是旧数据,数据是一致的。

    • 如果删除缓存成功,而数据库更新失败了,那么数据库中是旧数据,缓存中是空的,数据不会不一致。因为读的时候缓存没有,所以去读了数据库中的旧数据,然后更新到缓存中。

    问:先删除缓存,在写数据库成功之前,如果有读请求发生,可能导致旧数据入缓存,引发数据不一致,怎么处理?

    分布式锁

    问:Redis 如何实现分布式锁?

    使用 set key value ex nx 命令。

    • 当 key 不存在时,将 key 的值设为 value ,返回 1。若给定的 key 已经存在,则 setnx 不做任何动作,返回 0。

    • 当 setnx 返回 1 时,表示获取锁,做完操作以后 del key ,表示释放锁,如果 setnx 返回 0 表示获取锁失败。

    详细的命令如下:

    set key value [EX seconds] [PX milliseconds] [NX|XX]
    EX seconds:设置失效时长,单位秒
    PX milliseconds:设置失效时长,单位毫秒
    NX:key不存在时设置value,成功返回OK,失败返回(nil)
    XX:key存在时设置value,成功返回OK,失败返回(nil)。
    


    示例如下:

    set name fenglin ex 100 nx
    


    问:为什么不先 set nx ,然后再使用 expire 设置超时时间?

    我们需要保证 setnx 命令和 expire 命令以原子的方式执行,否则如果客户端执行 setnx 获得锁后,这时客户端宕机了,那么这把锁没有设置过期时间,导致其他客户端永远无法获得锁了。

    问:使用 Redis 分布式锁, key 和 value 分别设置成什么?

    value 可以使用 json 格式的字符串,示例:

    {
        "count":1,
        "expireAt":147506817232,
        "jvmPid":22224,
        "mac":"28-D2-44-0E-0D-9A",
        "threadId":14
    }
    


    问:Redis 实现的分布式锁,如果某个系统获取锁后,宕机了怎么办?

    系统模块宕机的话,可以通过设置过期时间(就是设置缓存失效时间)解决。系统宕机时锁阻塞,过期后锁释放。

    问:设置缓存失效时间,那如果前一个线程把这个锁给删除了呢?

    问:如果加锁和解锁之间的业务逻辑执行的时间比较长,超过了锁过期的时间,执行完了,又删除了锁,就会把别人的锁给删了。怎么办?

    这两个属于锁超时的问题。

    可以将锁的 value 设置为 Json 字符串,在其中加入线程的 id 或者请求的 id ,在删除之前, get 一下这个 key ,判断 key 对应的 value 是不是当前线程的。只有是当前线程获取的锁,当前线程才可以删除。

    问:Redis 分布式锁,怎么保证可重入性?

    可以将锁的 value 设置为 Json 字符串,在其中加入线程的 id 和 count 变量。

    • 当 count 变量的值为 0 时,表示当前分布式锁没有被线程占用。

    • 如果 count 变量的值大于 0 ,线程 id 不是当前线程,表示当前分布式锁已经被其他线程占用。

    • 如果 count 变量的值大于 0 ,线程 id 是当前线程的 id ,表示当前线程已经拿到了锁,不必阻塞,可以直接重入,并将 count 变量的值加一即可。

    这种思路,其实就是参考了 ReentrantLock 可重入锁的机制。

    问:Redis 做分布式锁, Redis 做了主从,如果设置锁之后,主机在传输到从机的时候挂掉了,从机还没有加锁信息,如何处理?

    可以使用开源框架 Redisson ,采用了 redLock。

    问:讲一下 Redis 的 redLock。

    问:Zookeeper 是怎么实现分布式锁的?

    分布式锁:基于 Zookeeper 一致性文件系统,实现锁服务。锁服务分为保存独占及时序控制两类。

    • 保存独占:将 Zookeeper 上的一个 znode 看作是一把锁,通过 createznode 的方式来实现。所有客户端都去创建 / distribute _ lock 节点,最终成功创建的那个客户端也即拥有了这把锁。用完删除自己创建的 distribute _ lock 节点就释放锁。

    • 时序控制:基于/ distribute _ lock 锁,所有客户端在它下面创建临时顺序编号目录节点,和选 master 一样,编号最小的获得锁,用完删除,依次方便。

    更详细的回答如下:

    其实基于 Zookeeper ,就是使用它的临时有序节点来实现的分布式锁。

    原理就是:当某客户端要进行逻辑的加锁时,就在 Zookeeper 上的某个指定节点的目录下,去生成一个唯一的临时有序节点, 然后判断自己是否是这些有序节点中序号最小的一个,如果是,则算是获取了锁。如果不是,则说明没有获取到锁,那么就需要在序列中找到比自己小的那个节点,并对其调用 exist() 方法,对其注册事件监听,当监听到这个节点被删除了,那就再去判断一次自己当初创建的节点是否变成了序列中最小的。如果是,则获取锁,如果不是,则重复上述步骤。

    当释放锁的时候,只需将这个临时节点删除即可。

    Zookeeper 

    问:Zookeeper 的原理是什么?

    问:Zookeeper 是怎么保证一致性的?

    zab 协议。

    zab 协议有两种模式,它们分别是恢复模式(选主)和广播模式(同步)。当服务启动或者在领导者崩溃后, zab 就进入了恢复模式,当领导者被选举出来,且大多数 server 完成了和 leader 的状态同步以后,恢复模式就结束了。状态同步保证了 leader 和 server 具有相同的系统状态。

    问:Zookeeper 有哪些应用场景?

    Zookeeper 可以作为服务协调的注册中心。还可以做分布式锁(如果没有用过分布式锁就不要说)。

    问:Zookeeper 为什么能做注册中心?

    Zookeeper 的数据模型是树型结构,由很多数据节点组成, zk 将全量数据存储在内存中,可谓是高性能,而且支持集群,可谓高可用。另外支持事件监听(watch 命令)。

    Zookeeper 可以作为一个数据发布/订阅系统。

    问:Zookeeper 的节点有哪些类型?有什么区别?

    临时节点,永久节点。更加细分就是临时有序节点、临时无序节点、永久有序节点、永久无序节点。  

    临时节点:当创建临时节点的程序停掉之后,这个临时节点就会消失,存储的数据也没有了。

    问:Zookeeper 做为注册中心,主要存储哪些数据?存储在哪里?

    IP、端口、还有心跳机制。数据存储在 Zookeeper 的节点上面。

    问:心跳机制有什么用?


    问:Zookeeper 的广播模式有什么缺陷?

    广播风暴。

    问:讲一下 Zookeeper 的读写机制。

    • Leader 主机负责读和写。

    • Follower 负责读,并将写操作转发给 Leader。Follower 还参与 Leader 选举投票,参与事务请求 Proposal 投票。

    • Observer 充当观察者的角色。Observer 和 Follower 的唯一区别在于:Observer 不参与任何投票。

    问:讲一下 Zookeeper 的选举机制。

    Leader 不可用时,会重新选举 Leader。超过半数的 Follower 选举投票即可,Observer 不参与投票。

    问:你们的 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 呢。

    问:Zookeeper 的集群节点,如果不是奇数可能会出现什么问题?

    可能会出现脑裂。

    • 假死:由于心跳超时(网络原因导致的)认为 master 死了,但其实 master 还存活着。

    • 脑裂:由于假死会发起新的 master 选举,选举出一个新的 master ,但旧的 master 网络又通了,导致出现了两个 master ,有的客户端连接到老的 master 有的客户端链接到新的 master。

    消息队列

    问:为什么使用消息队列?消息队列有什么优点和缺点?Kafka 、ActiveMQ 、RabbitMq 、RocketMQ 都有什么优点和缺点?

    消息队列解耦,削峰,限流。

    问:如何保证消息队列的高可用?(多副本)

    问:如何保证消息不被重复消费?(如何保证消息消费的幂等性)

    问:如何保证消息的可靠性传输?(如何处理消息丢失的问题)

    问:如何保证消息的顺序性?

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

    问:如果让你写一个消息队列,该如何进行架构设计啊?说一下你的思路。

    Kafka 

    问:讲一下 Kafka。

    Kafka 的简单理解

    问:Kafka 相对其他消息队列,有什么特点?

    • 持久化:Kafka 的持久化能力比较好,通过磁盘持久化。而 RabbitMQ 是通过内存持久化的。

    • 吞吐量:Rocket 的并发量非常高。

    • 消息处理:RabbitMQ 的消息不支持批量处理,而 RocketMQ 和 Kafka 支持批量处理。

    • 高可用:RabbitMQ 采用主从模式。Kafka 也是主从模式,通过 Zookeeper 管理,选举 Leader ,还有 Replication 副本。

    • 事务:RocketMQ 支持事务,而 Kafka 和 RabbitMQ 不支持。

    问:Kafka 有哪些模式?

    如果一个生产者或者多个生产者产生的消息能够被多个消费者同时消费的情况,这样的消息队列称为"发布订阅模式"的消息队列。

    问:Kafka 作为消息队列,有哪些优势?

    分布式的消息系统。

    高吞吐量。即使存储了许多 TB 的消息,它也保持稳定的性能。
    数据保留在磁盘上,因此它是持久的。

    问:Kafka 为什么处理速度会很快?kafka 的吞吐量为什么高?

    • 零拷贝:Kafka 实现了"零拷贝"原理来快速移动数据,避免了内核之间的切换。

    • 消息压缩、分批发送:Kafka 可以将数据记录分批发送,从生产者到文件系统(Kafka 主题日志)到消费者,可以端到端的查看这些批次的数据。

    • 批处理能够进行更有效的数据压缩并减少 I / O 延迟。

    • 顺序读写:Kafka 采取顺序写入磁盘的方式,避免了随机磁盘寻址的浪费。


    问:讲一下 Kafka 中的零拷贝。

    数据的拷贝从内存拷贝到 kafka 服务进程那块,又拷贝到 socket 缓存那块,整个过程耗费的时间比较高, kafka 利用了 Linux 的 sendFile 技术(NIO),省去了进程切换和一次数据拷贝,让性能变得更好。

    问:Kafka 的偏移量是什么?

    消费者每次消费数据的时候,消费者都会记录消费的物理偏移量(offset)的位置。等到下次消费时,他会接着上次位置继续消费

    问:Kafka 的生产者,是如何发送消息的?

    • 生产者的消息是先被写入分区中的缓冲区中,然后分批次发送给 Kafka Broker。

    • 生产者的消息发送机制,有同步发送和异步发送。

    • 同步发送消息都有个问题,那就是同一时间只能有一个消息在发送,这会造成许多消息。

    • 无法直接发送,造成消息滞后,无法发挥效益最大化。

    • 异步发送消息的同时能够对异常情况进行处理,生产者提供了 Callback 回调。


    问:Kafka 生产者发送消息,有哪些分区策略?

    Kafka 的分区策略指的就是将生产者发送到哪个分区的算法。有顺序轮询、随机轮询、key - ordering 策略。

    key - ordering 策略:Kafka 中每条消息都会有自己的 key ,一旦消息被定义了 Key ,那么你就可以保证同一个 Key 的所有消息都进入到相同的分区里面,由于每个分区下的消息处理都是有顺序的,故这个策略被称为按消息键保序策略。

    问:Kafka 为什么要分区?

    实现负载均衡和水平扩展。Kafka 可以将主题(Topic)划分为多个分区(Partition),会根据分区规则选择把消息存储到哪个分区中,只要如果分区规则设置的合理,那么所有的消息将会被均匀的分布到不同的分区中,这样就实现了负载均衡和水平扩展。另外,多个订阅者可以从一个或者多个分区中同时消费数据,以支撑海量数据处理能力。

    问:Kafka 是如何在 Broker 间分配分区的?

    在 broker 间平均分布分区副本。

    假设有 6 个 broker ,打算创建一个包含 10 个分区的 Topic ,复制系数为 3 ,那么 Kafka 就会有 30 个分区副本,它可以被分配给这 6 个 broker ,这样的话,每个 broker 可以有 5 个副本。

    要确保每个分区的每个副本分布在不同的 broker 上面:

    假设 Leader 分区 0 会在 broker1 上面, Leader 分区 1 会在 broker2 上面, Leder 分区 2 会在 broker3 上面。

    接下来会分配跟随者副本。如果分区 0 的第一个 Follower 在 broker2 上面,第二个 Follower 在 broker3 上面。分区 1 的第一个 Follower 在 broker3 上面,第二个 Follower 在 broker4 上面。

    问:Kafka 如何保证消息的顺序性?

    Kafka 可以保证同一个分区里的消息是有序的。也就是说消息发送到一个 Partition 是有顺序的。

    问:Kafka 的消费者群组 Consumer Group 订阅了某个 Topic ,假如这个 Topic 接收到消息并推送,那整个消费者群组能收到消息吗?

    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 ,会被传递到已订阅的消费者群组里面的一个消费者实例。

    问:如何提高 Kafka 的消费速度?

    问:Kafka 出现消息积压,有哪些原因?怎么解决?

    出现消息积压,可能是因为消费的速度太慢。

    扩容消费者。之所以消费延迟大,就是消费者处理能力有限,可以增加消费者的数量。
    扩大分区。一个分区只能被消费者群组中的一个消费者消费。消费者扩大,分区最好多随之扩大。

    问:Kafka 消息消费者宕机了,怎么确认有没有收到消息?

    ACK 机制,如果接收方收到消息后,会返回一个确认字符。

    问:讲一下 Kafka 的 ACK 机制。

    acks 参数指定了要有多少个分区副本接收消息,生产者才认为消息是写入成功的。此参数对消息丢失的影响较大。

    如果 acks = 0 ,就表示生产者也不知道自己产生的消息是否被服务器接收了,它才知道它写成功了。如果发送的途中产生了错误,生产者也不知道,它也比较懵逼,因为没有返回任何消息。这就类似于 UDP 的运输层协议,只管发,服务器接受不接受它也不关心。

    如果 acks = 1 ,只要集群的 Leader 接收到消息,就会给生产者返回一条消息,告诉它写入成功。如果发送途中造成了网络异常或者 Leader 还没选举出来等其他情况导致消息写入失败,生产者会受到错误消息,这时候生产者往往会再次重发数据。因为消息的发送也分为 同步 和 异步, Kafka 为了保证消息的高效传输会决定是同步发送还是异步发送。如果让客户端等待服务器的响应(通过调用 Future 中的 get() 方法),显然会增加延迟,如果客户端使用回调,就会解决这个问题。

    如果 acks = all ,这种情况下是只有当所有参与复制的节点都收到消息时,生产者才会接收到一个来自服务器的消息。不过,它的延迟比 acks = 1 时更高,因为我们要等待不只一个服务器节点接收消息。

    问: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 个副本。虽然造成了数据冗余,但是带来了数据的安全性。

    问:Kafka 怎么保证可靠性?

    多副本以及 ISR 机制。

    在 Kafka 中主要通过 ISR 机制来保证消息的可靠性。

    ISR(in sync replica):是 Kafka 动态维护的一组同步副本,在 ISR 中有成员存活时,只有这个组的成员才可以成为 leader ,内部保存的为每次提交信息时必须同步的副本(acks = all 时),每当 leader 挂掉时,在 ISR 集合中选举出一个 follower 作为 leader 提供服务,当 ISR 中的副本被认为坏掉的时候,会被踢出 ISR ,当重新跟上 leader 的消息数据时,重新进入 ISR。

    问:什么是 HW ?

    HW(high watermark):副本的高水印值, replica 中 leader 副本和 follower 副本都会有这个值,通过它可以得知副本中已提交或已备份消息的范围, leader 副本中的 HW ,决定了消费者能消费的最新消息能到哪个 offset。

    问:什么是 LEO ?

    LEO(log end offset):日志末端位移,代表日志文件中下一条待写入消息的 offset ,这个 offset 上实际是没有消息的。不管是 leader 副本还是 follower 副本,都有这个值。

    问: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).

    问:Kafka 怎么处理重复消息?怎么避免重复消费?

    偏移量 offset :消费者每次消费数据的时候,消费者都会记录消费的物理偏移量(offset)的位置。等到下次消费时,他会接着上次位置继续消费。

    一般情况下, Kafka 重复消费都是由于未正常提交 offset 造成的,比如网络异常,消费者宕机之类的。

    使用的是 spring-Kafka ,所以把 Kafka 消费者的配置 enable.auto. commit 设为 false ,禁止 Kafka 自动提交 offset ,从而使用 spring-Kafka 提供的 offset 提交策略。


    sprin-Kafka 中的 offset 提交策略可以保证一批消息数据没有完成消费的情况下,也能提交 offset ,从而避免了提交失败而导致永远重复消费的问题。

    问:怎么避免重复消费?

    将消息的唯一标识保存起来,每次消费时判断是否处理过即可。

    问:如何保证消息不被重复消费?(如何保证消息消费的幂等性)

    怎么保证消息队列消费的幂等性?其实还是得结合业务来思考,有几个思路:

    比如你拿个数据要写库,你先根据主键查一下,如果这数据都有了,你就别插入了, update 一下好吧。

    比如你是写 Redis ,那没问题了,反正每次都是 set ,天然幂等性。

    如果是复杂一点的业务,那么每条消息加一个全局唯一的 id ,类似订单 id 之类的东西,然后消费到了之后,先根据这个 id 去比如 Redis 里查一下,之前消费过吗?

    如果没有消费过,你就处理,然后这个 id 写 Redis。如果消费过了,那你就别处理了,保证别重复处理相同的消息即可。

    问:Kafka 消息是采用 pull 模式,还是 push 模式?

    pull 模式。

    问:pull 模式和 push 模式,各有哪些特点?

    pull 模式,准确性?可以较大保证消费者能获取到消息。

    push 模式,即时性?可以在 broker 获取消息后马上送达消费者。

    问:Kafka 是如何存储消息的?

    Kafka 使用日志文件的方式来保存生产者和发送者的消息,每条消息都有一个 offset 值来表示它在分区中的偏移量。


    Kafka 中存储的一般都是海量的消息数据,为了避免日志文件过大,
    一个分片并不是直接对应在一个磁盘上的日志文件,而是对应磁盘上的一个目录。

    数据存储设计的特点在于以下几点:

    1. Kafka 把主题中一个分区划分成多个分段的小文件段,通过多个小文件段,就容易根据偏移量查找消息、定期清除和删除已经消费完成的数据文件,减少磁盘容量的占用;

    2. 采用稀疏索引存储的方式构建日志的偏移量索引文件,并将其映射至内存中,提高查找消息的效率,同时减少磁盘 IO 操作;

    3. Kafka 将消息追加的操作逻辑变成为日志数据文件的顺序写入,极大的提高了磁盘 IO 的性能;


    问:讲一下 Kafka 集群的 Leader 选举机制。

    Kafka 在 Zookeeper 上针对每个 Topic 都维护了一个 ISR(in - sync replica ---已同步的副本)的集合,集合的增减 Kafka 都会更新该记录。如果某分区的 Leader 不可用, Kafka 就从 ISR 集合中选择一个副本作为新的 Leader。

    分库分表

    问:数据库如何处理海量数据?


    分库分表,主从架构,读写分离。

    问:数据库分库分表,何时分?怎么分?

    水平分库/分表,垂直分库/分表。

    • 水平分库/表,各个库和表的结构一模一样。

    • 垂直分库/表,各个库和表的结构不一样。

    问:读写分离怎么做?

    主机负责写,从机负责读。

    系统设计

    1、分布式、高并发场景

    遇到高并发场景,可以使用 Redis 缓存、Redis 限流、MQ 异步、MQ 削峰等。

    问:在实践中,遇到过哪些并发的业务场景?

    秒杀。比如抢商品,抢红包。

    2、秒杀

    问:如何设计一个秒杀/抢券系统?

    • 可以通过队列配合异步处理实现秒杀。

    • 使用 redis 的 list ,将商品 push 进队列, pop 出队列。

    • 异步操作不会阻塞,不会消耗太多时间。

    问:如何提高抢券系统的性能?

    • 使用多个 list。

    • 使用多线程从队列中拉取数据。

    • 集群提高可用性。

    • MQ 异步处理,削峰。

    问:秒杀怎么避免少卖或超卖?

    redis 是单进程单线程的,操作具有原子性,不会导致少卖或者超卖。另外,也可以设置一个版本号 version ,乐观锁机制。

    问:考勤打卡,假如高峰期有几万人同时打卡,那么怎么应对这种高并发?

    使用 Redis 缓存。员工点击签到,可以在缓存中 set 状态。将工号作为 key ,打卡状态作为 value ,打卡成功为 01 ,未打卡或者打卡失败为 00 ,然后再将数据异步地写入到数据库里面就可以了。

    问:如何应对高峰期的超高并发量?

    Redis 限流。Redis 可以用计数器限流。使用 INCR 命令,每次都加一,处理完业务逻辑就减一。然后设置一个最大值,当达到最大值后就直接返回,不处理后续的逻辑。

    Redis 还可以用令牌桶限流。使用 Redis 队列,每十个数据中 push 一个令牌桶,每个请求进入后会先从队列中 pop 数据,如果是令牌就可以通行,不是令牌就直接返回。

    3、短链接

    问:如何将长链接转换成短链接,并发送短信?

    短 URL 从生成到使用分为以下几步:

    • 有一个服务,将要发送给你的长 URL 对应到一个短 URL 上.例如 www.baidu.com -> www.t.cn/1。

    • 把短 url 拼接到短信等的内容上发送。

    • 用户点击短 URL ,浏览器用 301 / 302 进行重定向,访问到对应的长 URL。

    • 展示对应的内容。


    问:长链接和短链接如何互相转换?

    思路是建立一个发号器。每次有一个新的长 URL 进来,我们就增加一。并且将新的数值返回.第一个来的 url 返回"www.x.cn/0",第二个返回"www.x.cn/1".

    问:长链接和短链接的对应关系如何存储?

    如果数据量小且 QPS 低,直接使用数据库的自增主键就可以实现。

    还可以将最近/最热门的对应关系存储在 K-V 数据库中,这样子可以节省空间的同时,加快响应速度。

    系统架构与设计

    问:如何提高系统的并发能力?

    • 使用分布式系统。

    • 部署多台服务器,并做负载均衡。

    • 使用缓存(Redis)集群。

    • 数据库分库分表 + 读写分离。

    • 引入消息中间件集群。

    问:设计一个红包系统,需要考虑哪些问题,如何解决?(本质上也是秒杀系统)

    问:如果让你设计一个消息队列,你会怎么设计?

    项目经验及数据量

    问:这个项目的亮点、难点在哪里?

    问:如果这个模块挂掉了怎么办?

    问:你们的项目有多少台机器?

    问:你们的项目有多少个实例?
    4 个实例。

    问:你们的系统 QPS(TPS)是多少?
    QPS ,每秒查询量。QPS 为几百/几千,已经算是比较高的了。
    TPS ,每秒处理事务数。TPS 即每秒处理事务数,包括:”用户请求服务器”、”服务器自己的内部处理”、”服务器返回给用户”,这三个过程,每秒能够完成 N 个这三个过程, TPS 也就是 3。

    问:一个接口,多少秒响应才正常?
    快的话几毫秒。慢的话 1-2 秒。异常情况可能会 10 几秒;最好保证 99 %以上的请求是正常的。

    问:这个接口的请求时间,大概多久?主要耗时在哪里?

    问:系统的数据量多少?有没有分库分表?
    正常情况下,几百万的数据量没有必要分库分表。只有超过几千万才需要分库分表。

    问:插入/更新一条数据要多久?更新十万/百万条数据要多久?
    插入/更新一条数据一般要几毫秒;更新十万条数据最好在 10 秒以内;
    百万条数据最好在 50-100 秒以内。

    出处:cnblogs.com/expiator/p/10201004.html

    展开全文
  • 分布式一致性协议,二段、三段、TCC,优缺点 RPC过程 服务注册中心宕机了怎么办? 微服务还有其他什么组件 分布式架构与微服务的关系 你有什么问题要问我的? 二面: 各种排序算法、未排序常规数据...

    一面:

    • 个人介绍加项目介绍20分钟

    • 微服务架构是什么,它的优缺点?

    • ACID CAP BASE理论

    • 分布式一致性协议,二段、三段、TCC,优缺点

    • RPC过程

    • 服务注册中心宕机了怎么办?

    • 微服务还有其他什么组件

    • 分布式架构与微服务的关系

    • 你有什么问题要问我的?

    二面:

    • 各种排序算法、未排序常规数据查找第K大的数,时间复杂度。

    • 二叉树的深度

    • 虚拟内存分页了解不?

    • 进程和线程区别?

    • 第一二三范式是什么?

    • 一个表一千个列值为true和false,写sql 查询 有300个列值为true的行。

    • 脏读和幻读是什么?

    • 什么对象会从新生代晋升到老年代

    • 一个任务分成十个任务,最后汇总计算,不能用fork/join

    • 开源框架源码了解不?

    • 数据建模两道、个人题开放性题

    • 对安全方面了解多少?

    • 安全协议有哪些 、https是啥?

    • 介绍你做的项目和其中的难点。

    三面:

    • 从ConcurrentHashMap一路问到锁&锁优化->LongAdder->伪共享->缓存行填充->cas等诸多技术细节;

    • 从hystrix一路问到原理->自己如何实现->如何优化->响应流编程(reactive streams);

    • 从简单的生产者消费者模式设计到如何高效健壮实现等等。

    四面:

    • 如何倒序输出单向链表?

    • 个人直接想法是用栈先进后出的特点,把链表数据读到栈里然后输出。

    • 有更好的实现方式吗?

    • 主要问项目情况,然后根据一个项目,问如果量级扩大1000倍,你会怎么做?有哪些优化措施?高性能&高可用措施?

    五面:

    • 个人的职业规划是什么?

    • 你遇到的最大问题或者是困难是什么?

    • 你如何看待我们公司?

    • 你能为我们公司带来什么?

    • 你的优缺点是什么?

    面试总结:

    • 技术基础必须扎实:算法、数据结构、操作系统等,蚂蚁金服面试对技术的基础非常重视,基础扎实的同学有利于在前两轮突出重围。

    • 技术宽度:主要集中在高并发、多线程、分布式架构,大以及常用中间件(缓存等)的选型和比较。

    • 技术原理深入:重点还是提前准备好JVM、多线程高并发这块。

    • 参与的项目总结:你需要清楚你所做项目的关键细节、优化、特点、原理。

    • 很多所用第三方库&中间件等的原理,即使你不知道,也要有自己的想法能够说出如何代替实现,比如单点登录的替代方案。

    面试题总结

    面试文件获取方式:戳这里免费下载(助你面试无忧)

    其它面试题(springboot、mybatis、并发、java中高级面试总结等)

    va中高级面试总结等)**

    [外链图片转存中…(img-7N1LhBDd-1627359571691)]

    [外链图片转存中…(img-HZmphSRa-1627359571693)]

    展开全文
  • Java分布式面试题集合

    2021-01-19 07:24:00
    正文 分布式分为分布式缓存(Redis)、分布式锁(Redis 或 Zookeeper)、分布式服务(Dubbo 或 SpringCloud)、分布式服务协调(Zookeeper)、分布式消息队列(Kafka 、RabbitMq)、分布式 Session 、分布式事务、...
  • 分布式中session常见问题,即session共享.传统架构中(CS/BS)session存在服务器内存中key为cookie(session的唯一Id),cookie存在客户端浏览器中.在分布式场景下,假设有两个相同的服务负责同一业务,就可能出现session不...
  • 分布式系统的面试题9

    2021-03-09 06:49:45
    1、面试题分布式服务接口请求的顺序性如何保证?2、面试官心里分析其实分布式系统接口的调用顺序,也是个问题,一般来说是不用保证顺序的。但是有的时候可能确实是需要严格的顺序保证。给大家举个例子,你服务A调用...
  • 说起来开始进行面试是年前倒数第二周,上午9点,我还在去公司的公交上,突然收到蚂蚁的面试电话,其实算不上真正的面试面试官只是和我聊了下他们在做的事情(主要是做双十一这里大促的稳定性保障,偏中间件吧),...
  • 分布式 - 分布式事务面试题

    千次阅读 2021-04-15 17:02:47
    1 分布式事务面试题 现在Java面试,分布式系统、分布式事务几乎是标配。而分布式系统、分布式事务本身比较复杂,大家学起来也非常头疼。 最为常见的面试题: 问:分布式事务了解吗?你们是如何解决分布式事务问题...
  • 阿里巴巴Java岗面试题分享 1.HashMap 的内部结构?内部原理?和 HashTable 的区别,假如发⽣了 hash 碰撞,如何设计能让遍历效率⾼? 2.讲一讲讲讲 ConcurrentHashMap吧。 3.讲一下JVM虚拟机内存结构,以及它们的作...
  • 答:ZooKeeper 是一个开源的分布式应用程序协调服务,是一个典型的分布式数据一致性解决方案。设计目的是将那些复杂且容易出错的分布式一致性服务封装起来,构成一个高效可靠的系统,并以一系列简单易用的原子操作...
  • 如果依赖数据库本身的分布式事务管理功能去执行事务,将付出高昂的性能代价;如果由应用程序去协助控制,形成程序逻辑上的事务,又会造成编程方面的负担。 4.2 跨库跨表的join问题。 在执行了分库分表之后,难以避免...
  • 分布式锁 1、在分布式系统环境下,一个方法在同一时间只能被一个机器的一个线程执行 2、高可用的获取锁与释放锁 3、高性能的获取锁与释放锁 4、具备可重入特性(可理解为重新进入,由多于一个任务并发使用,而不必...
  • 一、分布式理论: 1. 什么是CAP理论? 2. 什么是BASE理论? 3. 什么是2PC? 4. 什么是3PC? 5. 什么是ZAB协议? 6. 什么是Raft协议? 7. 什么是Paxos算法? 二、Zookeeper: 8. ZooKeeper是什么...
  • Paxos算法解决的是一个基于消息传递来解决分布式系统如何就某个值(决议)达成一致。一个典型的场景是,在一个分布式数据框系统中,如果各个节点的初始状态一致,每个节点执行相同的操作序列,那么他们最后能够得到...
  • 在java中的模块比较种类多样和复杂,如果用分布式的思想来说,能够在使用的时候,让不同模块下的工具同时运行,而某一点的出错并不会影响整体的程序。我们在对于分布式知识点的考察上,分为不同的框架理解和其基本...
  • 5.集群、分布式、SOA、微服务的概念及区别?集群分布式SOA微服务 集群 不同服务器部署同一套应用服务对外提供访问,实现服务的负载均衡或者互备(热备、主从等),指同一种组件的多个实例,形成的逻辑上的整体。单个...
  • 今年的金三银四已经过去一大半了,在这其中参与过不少面试,2021都说工作不好找,这也是对开发人员的要求变向的提高了。 之前在Github上收获15K+star的Java核心神技(这参数,质量多高就不用我多说了吧)非常全面,...
  • 分布式事务 (含面试题)- 图解 - 秒懂 - 史上最全

    千次阅读 多人点赞 2021-02-04 22:48:14
    2021春招月薪过5万 总目录 疯狂创客圈 经典图书 : 《Netty Zookeeper Redis 高并发实战》 ...搞定下面这些面试题,2021春招月薪过5万(猛!) 阿里、京东、美团、头条… 随意挑、横着走!!! Java基础 JVM面
  • hi~大家好,今天分享一下微服务/分布式常见的面试问题,不过这些问题都是针对应届生的,对于比较senior的求职者应该会深入很多。题目都是来自2021大厂真实面经! 没有了解过分布式/微服务的老哥们也不要担心看不懂这...
  • 又到了一年一度的金九银十,互联网行业竞争是一年...分布式 一、大型网站系统的特点 二、大型网站架构演化发展历程 三、拆分VS集群 四、微服务VS SOA 五、前后端完全分离与Rest规范 六、CAP三进二和Base定理关系
  • 蚂蚁金服关于spring部分面试问题: Spring bean的生命周期能不能结合源码回答一下这个问题 Spring容器当中包含了哪些常用组件(至少说5个),作用是什么,场景是什么; Spring自动注入的原理是什么?能不能从源码来...
  • 分布式事务面试题

    2021-10-21 18:51:28
    分布式事务笔记 1. 分布式事务 1.1 什么是事务 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元,组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交,只要其中任一操作执行失败...
  • 原文地址:分布式相关的一些面试题~ 1、分布式服务API接口的幂等性如何设计? 幂等性:像一个接口,多次发送同一请求,需保证结果准确,也就是说不能多扣钱、多插入数据、统计值多+1等,这就是幂等性。 保证幂等...
  • 文章目录分布式概述分布式集群两个特点两大能力微服务多线程高并发 分布式概述 分布式 分布式(distributed)是为了解决单个物理服务器容量和性能瓶颈问题而采用的优化手段,将一个业务拆分成不同的子业务,分布在...
  • 分布式事务: 逻辑上的一组操作,组成这组操作的各个逻辑单元在不同的服务中,不同的服务器上,要么都成功,要么都失败。 场景。 场景: 不同服务,不同数据库 相同服务,不同数据库 不同服务,相同数据库 ...
  • java面试题分布式

    2021-02-27 08:26:33
    分布式分为分布式缓存(Redis)、分布式锁(Redis或Zookeeper)、分布式服务(Dubbo或SpringCloud)、分布式服务协调(Zookeeper)、分布式消息队列(Kafka、RabbitMq)、分布式Session、分布式事务、分布式搜索...
  • 学习分布式事务之前,先了解一下什么是分布式事务 1. 什么是分布式事务及作用? 分布式事务 分布式事务是指事务的参与者,支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上,且...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 85,945
精华内容 34,378
关键字:

分布式面试题

友情链接: flocking.zip