面试题总结

Redis面试题

Redis的过期策略以及内存淘汰机制

redis采用定期删除+惰性删除的策略。

        定时删除用一个定时器去检测key, 过期则删除, 虽然及时释放内存, 但是十分耗费cpu资源。在高并发情况下, cpu应该是去处理请求, 而不是在这定时删除key。因此没有采用这一策略.

        定期删除, redis默认每隔100ms检查, 是否有过期的 key, 有过期key则删除。redis不是每个100ms将所有的key进行检查, 而是随机抽取进行检查。如果只采用这种定期删除的方式进行删除, 那么redis中将会存在很多key没有被删除。 因此redis还会启用惰性删除的策略, 你在获取某个key的值的时候 redis会检查一下这个key是否过期, 过期则删除。

        如果惰性删除也没有生效, 定时清理也没有及时清理的话 redis内存也会越来越高。redis这时有很多选择 : 

1. noevication: 当内存不足容纳新写入数据时, 此时新写入的操作就会报错。
2. allkeys-lru: 当内存不足容纳新写入的数据时, 在键空间中, 移除最近最少使用的key。
3. allkeys-random: 当内存不足容纳新写入的数据时, 在键空间中, 随机移除某个key。
4. volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的 key。
5. volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键 空间中，随机移除某个 key。
6. volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键 空间中，有更早过期时间的key 优先移除。

---

Kafka面试题

Kafka如何保证消息不丢失

        kafka是用来实现异步消息通讯的一个中间件, 它的整个架构是由Producer Consumer Broker 来组成

        首先, Producer端需要去确保消息能够到达Broker, 并且实现消息的存储, 这个层面上有可能会出现网络异常导致消息发送失败, 所以针对Producer可以通过两种方式来避免消息丢失, 

        Producer默认是异步发送消息的, 需要确保消息发送成功, 第一个方式是把异步发送改成同步发送这样就能实时知道消息发送的结果。 第二种方式是添加异步回调函数的机制来监听消息发送的结果, 如果发送失败可以在回调中重试。第三种Producer本身提供了一种重试参数retries, 因为网络问题或者Broker 出现问题会进行重试。

        Broker 端需要确保Producer 提供来的消息不会丢失, 但是kafka 采用的是异步批量刷盘的实施机制, 他会按照一定的消息量和时间间隔去刷盘, 然后最终刷新到磁盘的这个动作是操作系统去调度执行的, 如果在刷盘之前, 系统先奔溃了, 那么数据就会丢失. kafka 并没有提供同步刷盘的一个实现机制, 所以我们要通过Partition 副本的机制和acks机制来解决, Partition 副本机制他是针对每个数据分区的而采用的高可用策略, 每一个Partition 副本集会包含唯一的一个Leader 和多个Follower ,Leader会专门处理一些事务类型的请求, 而Follower 会负责同步Leader的数据, 在这样的一个基础上呢, Kafka 提供了一个acks 的参数, Producer 可以设置acks 的参数, 去结合Broker 的副本机制来共同保障数据的可靠性. acks 的参数的值有几个选择, acks = 0 这样一种情况是Producer 不需要等带Broker 的响应就认为消息的发送成功了, 这样就会造成消息丢失, 当acks = 1时, 表示Broker中的Leader Partition 收到消息之后不等待其他的 Follower Partition 的同步就给Producer返回了一个确认, 这种情况下假设Leader Partition 和 Follower Partition 挂了就会造成消息丢失, 当acks = -1时, 表示Broker 中的Leader Partition收到消息后等待ISR列表中的Follower Partition同步完成才回去给Paoducer 返回一个确认。

        最后就是Consumer 必须要确保消费到这个消息, 除非是Consumer 还没有消费完这个消息就提交了Offset , 即便是这样也可以去设置 Offset的值去实现重新消费。