专栏首页游戏开发司机快收藏-2021最新阿里精选面试题(容器化,分布式篇)

快收藏-2021最新阿里精选面试题(容器化,分布式篇)

1. ZooKeeper 分布式是如何做到高可用?

ZooKeeper 运行期间,集群中至少有过半的机器保存了最新数据。集群超过半数的机器能够正常工作,集群就能够对外提供服务。

zookeeper 可以选出 N 台机器作主机,它可以实现 M:N 的备份;keepalive 只能选出 1台机器作主机,所以 keepalive 只能实现 M:1 的备份。

通常有以下两种部署方案:

双机房部署(一个稳定性更好、设备更可靠的机房,这个机房就是主要机房,而另外一个机房则更加廉价一些,例如,对于一个由 7 台机器组成的ZooKeeper 集群,通常在主要机房中部署 4 台机器,剩下的 3 台机器部署到另外一个机房中);

三机房部署(无论哪个机房发生了故障,剩下两个机房的机器数量都超过半数。在三个机房中都部署若干个机器来组成一个 ZooKeeper 集群。假设机器总数为 N,各机房机器数:N1 = (N-1)/2 ,N2=1~(N-N1)/2 ,N3 = N - N1 - N2 )。

水平扩容就是向集群中添加更多机器,Zookeeper2 种方式(不完美),一种是集群整体重启,另外一种是逐台进行服务器的重启。

2. kafka 高性能的原因?

A,Broker NIO 异步消息处理,实现了 IO 线程与业务线程分离;

B,磁盘顺序写;

C, 零拷贝(跳过用户缓冲区的拷贝,建立一个磁盘空间和内存的直接映射,数据不再复制到用户态缓冲区);

D,分区/分段(每次文件操作都是对一个小文件的操作,非常轻便,同时也增加了并行处理能力);

F,批量发送 (可以指定缓存的消息达到某个量的时候就发出去,或者缓存了固定的时间后就发送出去,大大减少服务端的 I/O 次数)

E,数据压缩

3. kafka 消息会不会丢失?

Kafka 消息发送分同步(sync)、异步(async)两种方式。默认是使用同步方式,可通过producer.type 属性进行配置;Kafka 保证消息被安全生产,有三个选项分别是 0,1,-1。

通过 request.required.acks 属性进行配置:

0 代表:不进行消息接收是否成功的确认(默认值);

1 代表:当 Leader 副本接收成功后,返回接收成功确认信息;

-1 代表:当 Leader 和 Follower 副本都接收成功后,返回接收成功确认信息;

网络异常

acks 设置为 0 时,不和 Kafka 集群进行消息接受确认,当网络发生异常等情况时,存在消息丢失的可能;

客户端异常

异步发送时,消息并没有直接发送至 Kafka 集群,而是在 Client 端按一定规则缓存并批量发送。在这期间,如果客户端发生死机等情况,都会导致消息的丢失;

缓冲区满了

异步发送时,Client 端缓存的消息超出了缓冲池的大小,也存在消息丢失的可能;

Leader 副本异常

acks 设置为 1 时,Leader 副本接收成功,Kafka 集群就返回成功确认信息,而 Follower副本可能还在同步。这时 Leader 副本突然出现异常,新 Leader 副本(原 Follower 副本)

未能和其保持一致,就会出现消息丢失的情况;

以上就是消息丢失的几种情况,在日常应用中,我们需要结合自身的应用场景来选择不同的配置。

想要更高的吞吐量就设置:异步、ack=0;想要不丢失消息数据就选:同步、ack=-1 策略

4. 怎么理解kafka 的leader 副本选举?

如果某个分区 patition 的 Leader 挂了,那么其它跟随者将会进行选举产生一个新的leader,之后所有的读写就会转移到这个新的Leader上,在kafka中,其不是采用常见的多数选举的方式进行副本的Leader选举,而是会在Zookeeper上针对每个Topic维护一个称为 ISR(in-sync replica,已同步的副本)的集合,显然还有一些副本没有来得及同步。只有这个 ISR 列表里面的才有资格成为 leader(先使用 ISR 里面的第一个,如果不行依次类推,因为 ISR 里面的是同步副本,消息是最完整且各个节点都是一样的)。

通过 ISR,kafka 需要的冗余度较低,可以容忍的失败数比较高。假设某个 topic 有 f+1个副本,kafka 可以容忍 f 个不可用,当然,如果全部 ISR 里面的副本都不可用,也可以选择其他可用的副本,只是存在数据的不一致。

5. 如何理解kafka 消息的检索?

其实很简单主要是用二分查找算法,比如我们要查找一条 offest=10000 的文件,kafka首先会在对应分区下的 log 文件里采用二分查看定位到某个记录该 offest=10000 这条消息的 log,然后从相应的 index 文件定位其偏移量,然后拿着偏移量到 log里面直接获取。这样就完成了一个消息的检索过程。

6 RabbitMQ 集群方式?

1)普通集群:

以两个节点(rabbit01、rabbit02)为例来进行说明。

rabbit01 和 rabbit02 两个节点仅有相同的元数据,即队列的结构,但消息实体只存在于其中一个节点 rabbit01(或者 rabbit02)中。

当消息进入 rabbit01 节点的 Queue 后,consumer 从 rabbit02 节点消费时,RabbitMQ会临时在 rabbit01、rabbit02 间进行消息传输,把 A 中的消息实体取出并经过 B 发送给 consumer。所以 consumer 应尽量连接每一个节点,从中取消息。即对于同一个逻辑队列,要在多个节点建立物理 Queue。否则无论 consumer 连 rabbit01 或 rabbit02,出口总在 rabbit01,会产生瓶颈。当 rabbit01 节点故障后,rabbit02 节点无法取到rabbit01 节点中还未消费的消息实体。如果做了消息持久化,那么得等 rabbit01 节点恢复,然后才可被消费;如果没有持久化的话,就会产生消息丢失的现象。

2)镜像集群:

在普通集群的基础上,把需要的队列做成镜像队列,消息实体会主动在镜像节点间同步,而不是在客户端取数据时临时拉取,也就是说多少节点消息就会备份多少份。该模式带来的副作用也很明显,除了降低系统性能外,如果镜像队列数量过多,加之大量的消息进入,集群内部的网络带宽将会被这种同步通讯大大消耗掉。所以在对可靠性要求较高的场合中适用由于镜像队列之间消息自动同步,且内部有选举 master 机制,即使 master 节点宕机也不会影响整个集群的使用,达到去中心化的目的,从而有效的防止消息丢失及服务不可用等问题

7 RabbitMQ 消息堆积怎么处理?

增加消费者的处理能力(例如优化代码),或减少发布频率

单纯升级硬件不是办法,只能起到一时的作用

考虑使用队列最大长度限制,RabbitMQ 3.1 支持给消息设置年龄,超时就丢弃.

默认情况下,rabbitmq 消费者为单线程串行消费,设置并发消费两个关键属性concurrentConsumers 和 prefetchCount,concurrentConsumers 设置的是对每个 listener在初始化的时候设置的并发消费者的个数,prefetchCount 是每次一次性从 broker 里面取的待消费的消息的个数

建立新的 queue,消费者同时订阅新旧 queue生产者端缓存数据,在 mq 被消费完后再发送到 mq打破发送循环条件,设置合适的 qos 值,当 qos 值被用光,而新的 ack 没有被 mq 接收时,就可以跳出发送循环,去接收新的消息;消费者主动 block 接收进程,消费者感受到接收消息过快时主动 block,利用 block 和 unblock 方法调节接收速率,当接收线程被 block时,跳出发送循环。

新建一个 topic,partition 是原来的 10 倍;然后写一个临时的分发数据的 consumer程序,这个程序部署上去消费积压的数据,消费之后不做耗时的处理,直接均匀轮询写入临时建立好的10倍数量的queue;接着临时征用10倍的机器来部署consumer,每一批consumer消费一个临时 queue 的数据;等快速消费完积压数据之后,得恢复原先部署架构,重新用原先的 consumer 机器来消费消息;

8. RabbitMQ 的消息丢失解决方案?

消息持久化:Exchange 设置持久化:durable:true;Queue 设置持久化;Message 持久化发送。

ACK 确认机制:消息发送确认;消息接收确认。

9.MQ 如何保证消息的一致性?

MQ 做数据同步也会造成不一致,又需要引入监控,实时计算 2 个集群的数据同步,做一致性同步。大部分来说,同步 es 和 solr 不要在代码中去同步,同步失败无法保证事务,而且业务耦合。可以使用 Databug 和 cancel 等工具去做代码解耦,MQ 支持重试,存储失败后抛出异常下次再处理。数据做异构,对外服务时任意拼装,MYSQL 在半同步复制上做了一些优化,保证了一致性,引入了诸如 paxos 等主流算法保证强一致性问题。

当 DB(监听从库),binlog 有变化,cancel 监听到时候解析过滤发送 MQ(表名字,主键等)到变化的实时从库中查询数据同步到 ES 聚合表,MQ 可以重试,系统解耦。事务 log挖掘县城会对 DB 的事务 log 监听,并把这些事件发布到消息代理。

10. Elasticsearch 分片使用优化?

(1)拆分集群

对于存在明显分界线的业务,可以按照业务、地域使用不同集群,这种拆分集群的思路是非常靠谱的。对于我们的场景,已经按照地域拆分了集群,且同一地域的子业务间分界线不明显,拆分过多的集群维护成本较高。

(2)调整滚动周期

根据保留时长调整index滚动周期是最简单有效的思路。例如保留3天的数据按天滚动,保留 31 天的数据按周滚动,保留一年的数据按月滚动。合理的滚动周期,可以在存储成本增加不大的情况下,大幅降低分片数量。

对于我们的场景,大部分数据保留 31 天,在按周滚动的情况下,集群的总分片数可以下降到 6.5w~个。

(3)合理设置分片数和副本数

除个别子业务压力较高外,大部分业务压力较小,合理设置单 Index 的分片数效果也不错。我们的经验是单个分片的大小在 10GB~30GB 之间比较合适,对于压力非常小的业务可以直接分配 1 个分片。其他用户可结合具体场景考虑,同时注意单分片的记录条数不要超过上限 2,147,483,519。

在平衡我们的业务场景对数据可靠性的要求 及 不同副本数对存储成本的开销 两个因素之后,我们选择使用一主一从的副本策略。

目前我们集群单 Index 的平均分配数为 3,集群的总分片数下降到 3w~个。

(4)分片分配流程优化

默认情况下,ES 在分配分片时会考虑分片 relocation 对磁盘空间的影响。在分片数较少时,这个优化处理的副作用不明显。但随着单机分片数量的上升,这个优化处理涉及的多层循环嵌套过程耗时愈发明显。可通过cluster.routing.allocation.disk.include_relocations: false 关闭此功能,这对磁盘均衡程度影响不明显。

(5)预创建 Index

对于单集群 3w 分片的场景,集中在每周某天 0 点创建 Index,对集群的压力还是较大,且存储空间存在波动。考虑到集群的持续扩展能力和可靠性,我们采用预创建方式提前创建分片,并把按 Index 的创建时间均匀打散到每周的每一天。

(6)持续调整分片数

对于集群分片的调整,通常不是一蹴而就的。随着业务的发展,不断新增的子业务 或 原有子业务规模发生突变,都需要持续调整分片数量。

默认情况下,新增的子业务会有默认的分片数量,如果不足,会在测试阶段及上线初期及时发现。随着业务发展,系统会考虑 Index 近期的数据量、写入速度、集群规模等因素,动态调整分片数量。

11. 负载均衡算法?

常见 6 种负载均衡算法:轮询,随机,源地址哈希,加权轮询,加权随机,最小连接数。

nginx5 种负载均衡算法:轮询,weight,ip_hash,fair(响应时间),url_hash

dubbo 负载均衡算法:随机,轮询,最少活跃调用数,一致性 Hash

文章分享自微信公众号:
游戏开发司机

本文参与 腾讯云自媒体分享计划 ,欢迎热爱写作的你一起参与!

原始发表时间:2021-12-29
如有侵权,请联系 cloudcommunity@tencent.com 删除。
登录 后参与评论
0 条评论

推荐阅读

  • 腾讯云上架构之资源命名规范设计

    本篇主要描述客户在使用腾讯云上云产品资源时,需从资源命名规范上,进行统一规范化设计。云上资源统一命名目的是:其一,云上资源命名规范化;其二,云上资源统一规范便于后续云上自动化,以增强整体云上运维能力,提升云平台整体运维透明度/资源辨识度,以及从资源管理、云上自动运维管理等维度提升云上管理的高效性。

    罗俊
    云服务器负载均衡私有网络
  • 系统设计的三板斧——抽象、具象和演算

    三包承诺:包记住,包理解,包会用。如有问题,请再看一遍。如想快速浏览,可以先看总结。

    一凡sir
  • C++深拷贝与浅拷贝,初始化列表,对象成员,静态成员相关分析

    使用new创建堆区数据,需要人为释放,new出来的东西是等到整个进程结束了才会自动释放。如果这个对象已经销毁,而这个类里没有析构函数却恰恰有个指针,自动释放的是栈区的变量,而不是堆区的,那么这个地址就没有指针指向它,就造成了内存泄漏。

    CtrlX
  • Hi,我是ChunJun,一个有趣好用的开源项目

    数字经济时代,各行各业数字化转型大趋势下,数据要素成为关键。海量多源异构数据汇聚,使得数据同步面临同步速率受限、稳定性差、维护成本高等挑战。

    数栈DTinsight
  • Elasticsearch 7.14.1集群压测报告(32核128G*10 本地NVMe SSD,Intel)

    本文描述问题及解决方法同样适用于 腾讯云 Elasticsearch Service(ES)。

    岳涛
    ElasticsearchService压力测试大数据解决方案大数据
  • 开源项目丨一文详解一站式大数据平台运维管家 ChengYing 如何部署 Hadoop 集群

    课件获取:关注公众号 “数栈研习社”,后台私信 “ChengYing” 获得直播课件

    数栈DTinsight
  • 【玩转 Cloud Studio】简单体验与思考

    界面跟vscode差不多, 可以安装vscode插件, 打开终端, 整体体验跟本地vscode没啥区别

    治电小白菜
    Cloud Studio
  • Kubebuilder 学习笔记之 Watching Resources

    我们在开发过程中,可能需要开发一个类似Deployment的资源逻辑,管理依赖资源是控制器的基础,如果不能观察它们的状态变化就不可能管理它们。这就意味着,我们需要 reconciler 能监控多个资源的变化。

    blazehu
    Kubernetes
  • Sealos+tkeauth 轻量化安装TKEStack

    参考文档:https://www.sealos.io/zh-Hans/docs/Intro

    xwc1125
    容器服务 TKE
  • 高并发场景下的BigCache本地缓存OOM问题

    线上频繁出现报警,提示内存被打爆问题,几个服务出现短暂不可用的现象,现就分析过程和解决过程记录如下

    后厂村鹅厂

扫码关注腾讯云开发者

领取腾讯云代金券