小滴课堂后端面试题（12）~持续更新中

一、描述 Kafka⽣产者发送到Broker分区策略是怎样的，消费者根据什么模式从broker获取数据的？

回答

（一）⽣产者发送到broker⾥⾯的流程是怎样的呢，⼀个 topic 有多个partition分区，每个分区⼜有多个副本

1、如果指定Partition ID,则PR被发送⾄指定Partition(ProducerRecord)

2、如果未指定Partition ID,但指定了Key, PR会按照hash(key)发送⾄对应Partition

3、如果未指定Partition ID也没指定Key，PR会按照默认 round-robin轮训模式发送到每个Partition

消费者消费partition分区默认是range模式

4、如果同时指定了Partition ID和Key, PR只会发送到指定的Partition (Key不起作⽤，代码逻辑决定)

注意：Partition有多个副本，但只有⼀个replicationLeader负责该Partition和⽣产者消费者交互

（二）⽣产者到broker发送流程

Kafka的客户端发送数据到服务器，不是来⼀条就发⼀条，会经过内存缓冲区（默认是16KB），通过KafkaProducer发送出去的消息都是先进⼊到客户端本地的内存缓冲⾥，然后把很多消息收集到的Batch⾥⾯，再⼀次性发送到Broker上去的，这样性能才可能题⾼

（三）消费者根据什么模式从broker获取数据的？

为什么是pull模式，⽽不是broker主动push？

（1）消费者采⽤ pull 拉取⽅式，从broker的partition获取数据

（2）pull 模式则可以根据 consumer 的消费能⼒进⾏⾃⼰调整，不同的消费者性能不⼀样

如果broker没有数据，consumer可以配置 timeout 时间，阻塞等待⼀段时间之后再返回

（3）如果是broker主动push，优点是可以快速处理消息，但是容易造成消费者处理不过来，消息堆积和延迟。

（四）消费者从哪个分区进⾏消费？

⼀个 topic 有多个 partition，⼀个消费者组⾥⾯有多个消费者，那是怎么分配过

（1）⼀个主题topic可以有多个消费者，因为⾥⾯有多个partition分区 ( leader分区)

（2）⼀个partition leader可以由⼀个消费者组中的⼀个消费者进⾏消费

（3）⼀个 topic 有多个 partition，所以有多个partitionleader，给多个消费者消费，有多种消费策略

（五）消费者从哪个分区进⾏消费？两个策略

1、顶层接口

org.apache.kafka.clients.consumer.internals.Abstra
ctPartitionAssignor

2、round-robin （RoundRobinAssignor⾮默认策略）轮训

（1）【按照消费者组】进⾏轮训分配，同个消费者组监听不同主题也⼀样，是把所有的 partition 和所有的 consumer都列出来， 所以消费者组⾥⾯订阅的主题是⼀样的才⾏，主题不⼀样则会出现分配不均问题，例如7个分区，同组内2个消费者

（2）topic-p0/topic-p1/topic-p2/topic-p3/topic-p4/topic-p5/topic-p6

（3）c-1: topic-p0/topic-p2/topic-p4/topic-p6

（4）c-2:topic-p1/topic-p3/topic-p5

（5）弊端

①如果同⼀消费者组内，所订阅的消息是不相同的，在执⾏分区分配的时候不是轮询分配，可能会导致分区分配的不均匀

②有3个消费者C0、C1和C2，他们共订阅了 3 个主题：t0、t1 和 t2

③t0有1个分区(p0)，t1有2个分区(p0、p1)，t2有3个分区(p0、p1、p2))

④消费者C0订阅的是主题t0，消费者C1订阅的是主题t0和t1，消费者C2订阅的是主题t0、t1和t2

3、range （RangeAssignor默认策略）范围

（1）【按照主题】进⾏分配，如果不平均分配，则第⼀个消费者会分配⽐较多分区， ⼀个消费者监听不同主题也不影响，例如7个分区，同组内2个消费者

（2）topic-p0/topic-p1/topic-p2/topic-p3/topic-p4/topic-p5//topic-p6

（2）c-1: topic-p0/topic-p1/topic-p2/topic-p3

（3）c-2:topic-p4/topic-p5/topic-p6

（4）弊端

①只是针对 1 个 topic ⽽⾔，c-1多消费⼀个分区影响不⼤

②如果有 N 多个 topic，那么针对每个 topic，消费者 C-1都将多消费 1 个分区，topic越多则消费的分区也越多，则性能有所下降

二、后端业务离不开数据处理-⼤数据⾥⾯的ETL和数仓分层是否了解

回答

（一）什么是ETL（Extract-Transform-Load）

1、抽取（extract）、转换（transform）、加载（load）缩写

2、ETL⼀词较常⽤在数据仓库，但其对象并不限于数据仓库

3、将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，⽬的是将企业中的分散、零乱、标准不统⼀的数据整合到⼀起，为企业的决策提供分析依据， ETL是BI（商业智能）项⽬重要的⼀个环节

（二）数仓分层介绍

（三）为什么要分层

1、开发者都希望⾃⼰的数据能够有顺序地流转，⽅便排查问题

2、复杂问题简单化

复杂任务分层处理，每层定位职责不⼀样，每个层只解决特定的问题

3、减少重复开发量

规范数据分层，开发通⽤的中间层，可以极⼤地减少重复计算的⼯作

三、分库分表之后，id 主键如何处理？

回答

基于数据库的实现⽅案 数据库⾃增 id 这个就是说你的系统⾥每次得到⼀个 id，都是往⼀个库的⼀个表⾥插⼊⼀条没什么业务含义的数据，然后获取⼀个数据库⾃增的⼀个 id。拿到这个 id 之后再往对应的分库分表⾥去写⼊。

这个⽅案的好处就是⽅便简单，谁都会⽤；缺点就是单库⽣成⾃增 id，要是⾼并发的话，就会有瓶颈的；如果你硬是要改进⼀下，那么就专⻔开⼀个服务出来，这个服务每次就拿到当前 id 最⼤值然后⾃⼰递增⼏个 id，⼀次性返回⼀批 id，然后再把当前最⼤ id 值修改成递增⼏个 id 之后的⼀个值；但是⽆论如何都是基于单个数据库。

适合的场景：你分库分表就俩原因，要不就是单库并发太⾼，要不就是单库数据量太⼤；除⾮是你并发不⾼，但是数据量太⼤导致的分库分表扩容，你可以⽤这个⽅案，因为可能每秒最⾼并发最多就⼏百，那么就⾛单独的⼀个库和表⽣成⾃增主键即可。

设置数据库 sequence 或者表⾃增字段步⻓ 可以通过设置数据库 sequence 或者表的⾃增字段步⻓来进⾏⽔平伸缩。

⽐如说，现在有 8 个服务节点，每个服务节点使⽤⼀个 sequence 功能来产⽣ ID，每个 sequence 的起始 ID 不同，并且依次递增，步⻓都是 8。

合的场景：在⽤户防⽌产⽣的 ID 重复时，这种⽅案实现起来⽐较简单，也能达到性能⽬标。但是服务节点固定，步⻓也固定，将来如果还要增加服务节点，就不好搞了。

UUID 好处就是本地⽣成，不要基于数据库来了；不好之处就是，UUID 太⻓了、占⽤空间⼤，作为主键性能太差了；更重要的是，UUID 不具有有序性，会导致 B+ 树索引在写的时候有过多的随机写操作（连续的 ID 可以产⽣部分顺序写），还有，由于在写的时候不能产⽣有顺序的 append 操作，⽽需要进⾏ insert 操作，将会读取整个 B+ 树节点到内存，在插⼊这条记录后会将整个节点写回磁盘，这种操作在记录占⽤空间⽐较⼤的情况下，性能下降明显。

适合的场景：如果你是要随机⽣成个什么⽂件名、编号之类的，你可以⽤ UUID，但是作为主键是不能⽤ UUID 的。

UUID.randomUUID().toString().replace(“-”, “”) -> sfsdf23423rr234sfdaf

获取系统当前时间 这个就是获取当前时间即可，但是问题是，并发很⾼的时候，⽐如⼀秒并发⼏千，会有重复的情况，这个是肯定不合适的。基本就不⽤考虑了。

适合的场景：⼀般如果⽤这个⽅案，是将当前时间跟很多其他的业务字段拼接起来，作为⼀个 id，如果业务上你觉得可以接受，那么也是可以的。你可以将别的业务字段值跟当前时间拼接起来，组成⼀个全局唯⼀的编号。

snowflake 算法 snowflake 算法是 twitter 开源的分布式 id ⽣成算法，采⽤ Scala 语⾔实现，是把⼀个 64 位的 long 型的 id，1 个 bit 是不⽤的，⽤其中的 41 bit 作为毫秒数，⽤ 10 bit 作为⼯作机器 id，12 bit 作为序列号。

1 bit：不⽤，为啥呢？因为⼆进制⾥第⼀个 bit 为如果是 1，那么都是负数，但是我们⽣成的 id 都是正数，所以第⼀个 bit 统⼀都是 0。 41 bit：表示的是时间戳，单位是毫秒。41 bit 可以表示的数字多达2^41 - 1，也就是可以标识 2^41 - 1 个毫秒值，换算成年就是表示69年的时间。 10 bit：记录⼯作机器id，代表的是这个服务最多可以部署在 2^10台机器上哪，也就是1024台机器。但是 10 bit ⾥ 5 个 bit代表机房 id，5 个 bit 代表机器 id。意思就是最多代表 2^5个机房（32个机房），每个机房⾥可以代表2^5 个机器（32台机器）。 12 bit：这个是⽤来记录同⼀个毫秒内产⽣的不同 id，12 bit 可以代表的最⼤正整数是 2^12 - 1 = 4096，也就是说可以⽤这个 12 bit 代表的数字来区分同⼀个毫秒内的 4096 个不同的 id。

0 | 0001100 10100010 10111110 10001001 01011100 00 | 10001 | 1 1001 | 0000
00000000

public class IdWorker {
 private long workerId;
 private long datacenterId;
 private long sequence;
 public IdWorker(long workerId, long datacenterId, long sequence) {
 // sanity check for workerId
 // 这⼉不就检查了⼀下，要求就是你传递进来的机房id和机器id不能超过32，不能⼩于0
 if (workerId > maxWorkerId || workerId < 0) {
 throw new IllegalArgumentException(
 String.format("worker Id can't be greater than %d or less
than 0", maxWorkerId));
 }
 if (datacenterId > maxDatacenterId || datacenterId < 0) {
 throw new IllegalArgumentException(
 String.format("datacenter Id can't be greater than %d or
less than 0", maxDatacenterId));
 }
 System.out.printf(
 "worker starting. timestamp left shift %d, datacenter id bits
%d, worker id bits %d, sequence bits %d, workerid %d",
 timestampLeftShift, datacenterIdBits, workerIdBits, 
sequenceBits, workerId);
 this.workerId = workerId;
 this.datacenterId = datacenterId;
 this.sequence = sequence;
 }
 private long twepoch = 1288834974657L;

private long workerIdBits = 5L;
 private long datacenterIdBits = 5L;
 // 这个是⼆进制运算，就是 5 bit最多只能有31个数字，也就是说机器id最多只能是32以内
 private long maxWorkerId = -1L ^ (-1L << workerIdBits);
 // 这个是⼀个意思，就是 5 bit最多只能有31个数字，机房id最多只能是32以内
 private long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);
 private long sequenceBits = 12L;
 private long workerIdShift = sequenceBits;
 private long datacenterIdShift = sequenceBits + workerIdBits;
 private long timestampLeftShift = sequenceBits + workerIdBits +
datacenterIdBits;
 private long sequenceMask = -1L ^ (-1L << sequenceBits);
 private long lastTimestamp = -1L;
 public long getWorkerId() {
 return workerId;
 }
 public long getDatacenterId() {
 return datacenterId;
 }
 public long getTimestamp() {
 return System.currentTimeMillis();
 }
 public synchronized long nextId() {
 // 这⼉就是获取当前时间戳，单位是毫秒
 long timestamp = timeGen();
 if (timestamp < lastTimestamp) {
 System.err.printf("clock is moving backwards. Rejecting requests
until %d.", lastTimestamp);
 throw new RuntimeException(String.format(
 "Clock moved backwards. Refusing to generate id for %d
milliseconds", lastTimestamp - timestamp));
 }
 if (lastTimestamp == timestamp) {
 // 这个意思是说⼀个毫秒内最多只能有4096个数字
 // ⽆论你传递多少进来，这个位运算保证始终就是在4096这个范围内，避免你⾃⼰传递
个sequence超过了4096这个范围
 sequence = (sequence + 1) & sequenceMask;
 if (sequence == 0) {
 timestamp = tilNextMillis(lastTimestamp);

    }
} else {
 sequence = 0;
 }
 // 这⼉记录⼀下最近⼀次⽣成id的时间戳，单位是毫秒
 lastTimestamp = timestamp;
 // 这⼉就是将时间戳左移，放到 41 bit那⼉；
 // 将机房 id左移放到 5 bit那⼉；
 // 将机器id左移放到5 bit那⼉；将序号放最后12 bit；
 // 最后拼接起来成⼀个 64 bit的⼆进制数字，转换成 10 进制就是个 long 型
 return ((timestamp - twepoch) << timestampLeftShift) | (datacenterId
<< datacenterIdShift)
 | (workerId << workerIdShift) | sequence;
 }
 private long tilNextMillis(long lastTimestamp) {
 long timestamp = timeGen();
 while (timestamp <= lastTimestamp) {
 timestamp = timeGen();
 }
 return timestamp;
 }
 private long timeGen() {
 return System.currentTimeMillis();
 }
 // ---------------测试---------------
 public static void main(String[] args) {
 IdWorker worker = new IdWorker(1, 1, 1);
 for (int i = 0; i < 30; i++) {
 System.out.println(worker.nextId());
 }
 }
}

怎么说呢，⼤概这个意思吧，就是说 41 bit 是当前毫秒单位的⼀个时间戳，就这意思；然后 5 bit 是你传递进来的⼀个机房 id（但是最⼤只能是 32 以内），另外 5 bit 是你传递进来的机器 id（但是最⼤只能是 32 以内），剩下的那个 12 bit序列号，就是如果跟你上次⽣成 id 的时间还在⼀个毫秒内，那么会把顺序给你累加，最多在 4096 个序号以内。

所以你⾃⼰利⽤这个⼯具类，⾃⼰搞⼀个服务，然后对每个机房的每个机器都初始化这么⼀个东⻄，刚开始这个机房的这个机器的序号就是 0。然后每次接收到⼀个请求，说这个机房的这个机器要⽣成⼀个id，你就找到对应的 Worker ⽣成。

利⽤这个 snowflake 算法，你可以开发⾃⼰公司的服务，甚⾄对于机房 id 和机器 id，反正给你预留了5 bit + 5 bit，你换成别的有业务含义的东⻄也可以的。

这个 snowflake 算法相对来说还是⽐较靠谱的，所以你要真是搞分布式 id ⽣成，如果是⾼并发啥的，那么⽤这个应该性能⽐较好，⼀般每秒⼏万并发的场景，也⾜够你⽤了。