场景题

【后端开发】后端常见场景题_后端开发 场景题-CSDN博客

场景题-CSDN博客

4、场景题&系统设计题很简单，直接背套路！_后端场景设计题-CSDN博客

Feed流系统设计-总纲 - 知乎 (zhihu.com)

  1. 100w个用户中，记录5分钟内重复登录的用户：hashmap存，然后过期淘汰采用类似redis的内存淘汰策略，一批批抽检过五分钟的直接删除直到占比小于5% //或者布隆过滤器

  2. 堆的应用场景： 100亿数据保留前100， 用最小堆

  3. 有几台机器存储着几亿淘宝搜索日志，你只有一台 2g 的电脑，怎么选出搜索热度最高的十个？

针对top k类文本问题，通常比较好的方案是【分治+trie树/hash+小顶堆】，即先将数据集按照hash方法分解成多个小数据集，然后使用trie树或者hash统计每个小数据集中的query词频，之后用小顶堆求出每个数据集中出频率最高的前K个数，最后在所有top K中求出最终的top K。

  1. 类似3，大数据量TopK问题，都是分治成小文件+hash统计频率+小顶堆 提取某日访问次数最多的100个 IP地址

  2. 如何用redis存储统计1亿用户一年的登陆情况，并快速检索任意时间窗口内的活跃用户数量

用位图法，每天一张位图，统计1e用户当天的登陆情况

  1. 如何设计一个消息队列（照着kafka的架构和特性来说）

怎么维护消费进度？

broker有一个topic维护offset

怎么消费？

长轮询

保障高性能IO**？**

批量消费+发送

零拷贝

稀疏索引+二分查找

顺序读写磁盘

可伸缩性

就是需要的时候快速扩容，就可以增加吞吐量和容量，那怎么搞？设计个分布式的系统呗，参照一下 kafka 的设计理念，broker -> topic -> partition，每个 partition 放一个机器，就存一部分数据。如果现在资源不够了，简单啊，给 topic 增加 partition，然后做数据迁移，增加机器，不就可以存放更多数据，提供更高的吞吐量了？

其次你得考虑一下这个 mq 的数据要不要落地磁盘吧？

Redis stream是内存，但是我们想要可靠的话最好还是落磁盘

怎么落盘？

一个topic partiion一个文件夹 顺序写，这样就没有磁盘随机读写的寻址开销，磁盘顺序读写的性能是很高的，这就是 kafka 的思路。

当然也可以参考rcmq的 全部topic的消息都写入一个文件里

mq 的可用性？

多副本 -> leader & follower -> broker 挂了重新选举 leader 即可对外服务。

leader和foller之间的数据一致性保证？

最高水位HW保证 共享的数据才能被消费者消费， leader和follwer故障时从HW开始恢复数据

如何维护消费者和分区的关系？

由消费者leader协商出方案发给broker协商者，协商者再通知各个消费者，延申出来的还有重平衡问题的解决

  1. 10万个数，输出从小到大？ 先划分成多个小文件，送进内存排序，然后再采用多路归并排序。

  2. 在 2.5 亿个整数中找出不重复的整数。注意：内存不足以容纳这 2.5 亿个整数。

位图法

构建两个bitmap，表达如下：

00表示这个数没出现过

01表示这个数出现过一次 （题目需要找的答案）

10表示这个数出现过多次

遍历 2.5 亿个整数，查看位图中对应的位，如果是 00，则变为 01，如果是 01 则变为 10，如果是 10 则保持不变。遍历结束后，查看位图，把对应位是 01 的整数输出即可。

  1. 秒杀场景

限流控制： 使用限流算法（如令牌桶、漏桶等）对用户的请求进行限制，防止瞬间并发请求过多。

缓存策略： 合理设置秒杀商品信息的缓存失效时间，避免在短时间内大量请求打到数据库上。

缓存预热： 在秒杀开始前，提前将商品信息加载到缓存中，避免瞬间并发请求导致缓存失效。

队列处理： 使用消息队列（如Kafka、RabbitMQ）将秒杀请求异步处理，削峰的同时实现异步下单，减小数据库压力。

数据库优化： 对数据库进行优化，使用索引、合理的SQL语句，提高数据库的查询和写入效率。分库分表

  1. 如何实现在秒杀场景下的限流服务？

令牌桶算法： 应用于接口的请求上。系统以固定的速率往令牌桶中放入令牌，用户的请求需要获取令牌才能继续执行。如果令牌桶中没有足够的令牌，则请求被拒绝，实现了限流效果。

分布式限流： 使用分布式限流组件，例如Redis或ZooKeeper，将限流规则存储在共享的分布式存储中，各个服务节点从分布式存储中获取限流规则，实现统一的限流策略。

Guava RateLimiter： Google的Guava库提供了一个RateLimiter类，可以用来实现令牌桶限流算法。RateLimiter允许你以一个固定的速率获取令牌，当令牌用完时，请求将被阻塞。

熔断器： 在高并发时，可以使用熔断器（例如Hystrix）来处理限流。熔断器能够实时监控系统的流量，当流量超过阈值时，自动打开熔断，拒绝新的请求，避免系统崩溃。当系统稳定后，熔断器会逐渐放开，恢复对新请求的处理。

  1. feed流设计

推拉结合模式：推模式在单向关系中，因为存在大V，那么一条消息可能会扩散几百万次，但是这些用户中可能有一半多是僵尸，永远不会上线，那么就存在资源浪费。而拉模式下，在系统架构上会很复杂，同时需要记录的位置信息是天量，不好解决，尤其是用户量多了后会成为第一个故障点。基于此，所以有了推拉结合模式，大部分用户的消息都是推模式，只有大V是拉模式，这样既控制了资源浪费，又减少了系统设计复杂度。但是整体设计复杂度还是要比推模式复杂

智力题

智力题：智力逻辑场景题_情景问题逻辑题目与解析-CSDN博客

  1. 毒药毒白鼠，找出哪个瓶子中是毒药

有1000个一模一样的瓶子，其中有999瓶是普通的水，有1瓶是毒药。任何喝下毒药的生命都会在一星期之后死亡。现在你只有10只小白鼠和1个星期的时间，如何检验出哪个瓶子有毒药？

首先一共有1000瓶，2的10次方是1024，刚好大于1000，也就是说，1000瓶药品可以使用10位二进制数就可以表示。从第一个开始：

第一瓶 ： 00 0000 0001

第二瓶： 00 0000 0010

第三瓶： 00 0000 0011

观察，若死亡的老鼠编号为：ACFGJ，一共死去五只老鼠，则对应的编号为 10 1001 1001，则有毒的药品为该编号的药品，转为十进制数为：613号。

  1. 利用烧绳子计算时间

现有若干不均匀的绳子，烧完这根绳子需要一个小时，问如何准确计时15分钟，30分钟，45分钟，75分钟。。。

计算15分钟：对折之后两头烧(要求对折之后绑的够紧，否则看45分钟解法)

计算30分钟：两头烧

计算45分钟：两根，一根两头烧一根一头烧，两头烧完过了30分钟，立即将第二根另一头点燃，到烧完又过15分钟，加起来45分钟

计算75分钟：将30和45分钟的方式加起来就可以了

  1. 在24小时里面时针分针秒针可以重合几次

24小时中时针走2圈，而分针走24圈，时针和分针重合24-2=22次，而只要时针和分针重合，秒针一定有机会重合（因为一分钟有60s，秒针不走一圈分针不会动的），所以总共重合22次