相关业务问题+系统问题+设计问题整理统计

以我们日常的分析来说的话，对应突发问题发生时，平时我们会制定对应应对的SOP和详细的分工，比方指定一部分人进行分析流量来源的定位分析，立刻找到是因为什么爆发的，赶紧进行限流、扩容等措施同时告知上游调用其不合理的请求让对方加入处理管控；一部分人进行机器分析看下是单机问题还是部分机器问题还是集群整体的问题，单机问题直接进行禁用，多机问题进行安全重启同时进行扩容并预留一台机器赶紧进行dump分析，集群问题看是否发版问题赶紧回滚等；一部分进行问题分析等，这是日常常见放入操作分析。

排查线上问题是一项重要的工作，以下是一些常用的排查思路和步骤，以帮助您更有效地解决问题：

确认问题现象： 首先要明确问题是什么，如性能下降、服务崩溃、数据异常等。了解问题的具体现象可以指导后续的排查步骤。
查看日志： 检查应用程序和系统的日志，查找异常、错误信息和警告，日志通常提供了问题的线索。
监控指标： 使用监控工具查看系统的性能指标，如 CPU 使用率、内存占用、网络流量等，以确定系统是否存在异常负载。
版本变更： 查看是否有最近的代码、配置或环境变更，排查是否与问题相关。
重现问题： 如果可能，尝试在测试环境中重现问题，以便更深入地分析和排查。
分析堆栈信息： 对于应用程序崩溃或异常情况，查看堆栈跟踪信息，定位问题发生的位置。
网络问题： 检查网络连接是否正常，排查 DNS、防火墙、代理等问题。
数据库问题： 检查数据库的性能、连接数、死锁、慢查询等问题。
资源限制： 确认是否有资源限制，如 CPU、内存、磁盘空间等，导致了问题。
第三方服务： 检查是否有依赖的第三方服务出现故障，导致问题。
并发问题： 分析是否存在并发问题，如死锁、资源竞争等。
日志级别： 调整日志级别，获取更详细的信息，以便分析问题。
逐步减小范围： 如果问题难以定位，逐步排除不相关的部分，缩小排查范围。
收集证据： 在分析过程中，收集相关的数据、截图、日志等，以便更好地分析和解决问题。
团队协作： 如果需要，与团队成员合作，共同分析和解决问题。
解决问题： 基于分析结果，制定并实施解决方案，验证是否解决了问题。
预防措施： 总结问题原因，考虑采取预防措施，以避免类似问题再次发生。

总之，排查线上问题需要有系统的思维方式和方法，同时需要耐心和深入的分析。通过以上步骤，您可以更快速地定位问题并采取合适的措施解决问题。

2.高并发系统的限流如何实现？

在高并发系统中，限流是一种重要的机制，用于控制系统的访问量，防止系统过载和资源耗尽。以下是一些常见的限流实现方式：

固定窗口计数器：设置一个固定的时间窗口，例如1秒钟，统计在该时间窗口内的请求次数。当请求数超过设定的阈值时，拒绝后续的请求。
滑动窗口计数器：与固定窗口计数器类似，但是使用滑动时间窗口，例如每秒钟分为多个小时间窗口。可以根据具体需求选择滑动窗口的大小和间隔，动态地适应流量变化。
令牌桶算法：基于令牌的方式进行限流。系统以固定速率产生令牌，并放入令牌桶中。每个请求需要获取一个令牌才能被处理，如果令牌桶为空，则请求被暂时阻塞或拒绝。
漏桶算法：类似于令牌桶算法，但是以固定速率处理请求。桶中以固定速率漏出请求，如果桶已满，则请求被拒绝。
并发连接数限制：限制系统能够同时处理的并发连接数。当连接数达到阈值时，后续的连接将被拒绝。
排队等待：在系统处理请求之前，将请求放入队列中，并限制队列的长度。当队列已满时，后续的请求将被拒绝。
动态限流：根据系统的实时负载情况进行动态的限流控制。例如，根据系统的负载、响应时间等指标进行动态调整限流阈值，以保持系统的稳定性。

需要根据具体的业务场景和系统需求选择适合的限流算法和实现方式。同时，限流策略的设计也需要考虑系统的容量、性能、用户体验等方面的因素，以提供合理的限流控制。

系统可靠性可见博客：微服务架构服务可靠性分析：服务访问失败的原因和应对策略+服务容错+服务隔离+服务限流+服务降级：服务访问失败的原因和应对策略+服务容错+服务隔离+服务限流+服务降级_张彦峰ZYF的博客-CSDN博客目录一、服务访问失败的原因和应对策略（一）服务访问失败的4大原因和分类1硬件失败2.分布式环境的固有原因3.服务自身失败4.服务依赖失败（二）服务访问的雪崩效应（三）服务访问失败的应对策略二、服务容错1.Failover2.Failback3.Failsafe4.Failfast5.Forking6.Broadcast三、服务隔离...https://blog.csdn.net/xiaofeng10330111/article/details/86772740

3.高并发秒杀系统的设计？

架构设计上要提前分析，梳理主流程和可能遇到的种种问题，优化设计，同时做到“4 要 1 不要”原则，也就是：数据要尽量少、请求数要尽量少、路径要尽量短、依赖要尽量少，以及不要有单点。

数据要尽量少，首先是指用户请求的数据能少就少。请求的数据包括上传给系统的数据和系统返回给用户的数据（通常就是网页）。还要求系统依赖的数据能少就少，包括系统完成某些业务逻辑需要读取和保存的数据，这些数据一般是和后台服务以及数据库打交道的。
请求数要尽量少，用户请求的页面返回后，浏览器渲染这个页面还要包含其他的额外请求，比如说，这个页面依赖的 CSS/JavaScript、图片，以及 Ajax 请求等等都定义为“额外请求”，这些额外请求应该尽量少。
路径要尽量短，路径要尽量短所谓“路径”，就是用户发出请求到返回数据这个过程中，需求经过的中间的节点数。要缩短访问路径有一种办法，就是多个相互强依赖的应用合并部署在一起，把远程过程调用（RPC）变成 JVM 内部之间的方法调用。
依赖要尽量少所谓依赖，指的是要完成一次用户请求必须依赖的系统或者服务，这里的依赖指的是强依赖。要减少依赖，我们可以给系统进行分级分析。
不要有单点系统中的单点可以说是系统架构上的一个大忌，因为单点意味着没有备份，风险不可控。

在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流。

缓存：缓存比较好理解，在大型高并发系统中，如果没有缓存数据库将分分钟被爆，系统也会瞬间瘫痪。使用缓存不单单能够提升系统访问速度、提高并发访问量，也是保护数据库、保护系统的有效方式。大型网站一般主要是“读”，缓存的使用很容易被想到。在大型“写”系统中，缓存也常常扮演者非常重要的角色。比如累积一些数据批量写入，内存里面的缓存队列（生产消费），以及HBase写数据的机制等等也都是通过缓存提升系统的吞吐量或者实现系统的保护措施。甚至消息中间件，你也可以认为是一种分布式的数据缓存。
降级：服务降级是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。降级往往会指定不同的级别，面临不同的异常等级执行不同的处理。根据服务方式：可以拒接服务，可以延迟服务，也有时候可以随机服务。根据服务范围：可以砍掉某个功能，也可以砍掉某些模块。总之服务降级需要根据不同的业务需求采用不同的降级策略。主要的目的就是服务虽然有损但是总比没有好。
限流：限流可以认为服务降级的一种，限流就是限制系统的输入和输出流量已达到保护系统的目的。一般来说系统的吞吐量是可以被测算的，为了保证系统的稳定运行，一旦达到的需要限制的阈值，就需要限制流量并采取一些措施以完成限制流量的目的。比如：延迟处理，拒绝处理，或者部分拒绝处理等等。

4.秒杀并发情况下库存为负数问题分析

在秒杀场景下，高并发情况下库存为负数的问题可能出现的原因如下：

竞态条件（Race Condition）：当多个并发请求同时减少库存时，由于并发执行的不确定性，可能导致多个请求读取相同的库存值，然后减少库存，最终导致库存变为负数。
无效的库存检查：在秒杀开始之前，可能会进行库存检查来确定是否还有足够的库存。但是，在高并发情况下，多个请求同时进行库存检查时，由于并发执行的不确定性，可能会出现多个请求同时通过了库存检查，但实际上库存已经被消耗完了。
锁竞争问题：为了保证库存的原子性操作，可能会采用锁机制来控制并发访问。但是，如果锁的粒度过大或锁的竞争过于激烈，会导致多个请求同时等待获取锁，最终导致库存被超卖。

解决库存为负数的问题可以采取以下措施：

悲观锁：使用数据库的悲观锁机制或分布式锁来确保同一时间只有一个请求能够修改库存，避免并发冲突。
乐观锁：在库存更新操作中引入版本号或时间戳等机制，每次修改库存时都进行版本的比对，以确保操作的原子性。
库存预减：在进行秒杀前，先对库存进行预减操作，然后再检查库存是否足够，避免无效的库存检查。
队列削峰：通过消息队列等机制来平滑请求的流量，控制请求的处理速度，避免瞬时的高并发压力对库存造成冲击。
限制每个用户的购买数量：对每个用户进行限购，限制每个用户在一定时间内只能购买一定数量的商品，避免某个用户抢购过多导致库存不足。
库存补偿机制：在库存不足的情况下，可以通过异步任务或定时任务来补充库存，以保证商品的可售性。

综上所述，秒杀场景下库存为负数的问题主要是由于并发冲突、无效的库存检查或锁竞争问题导致的。采取合适的并发控制和库存管理策略，结合合理的锁机制和限流机制，可以有效地解决库存为负数的问题。

5.实现一套负载均衡架构，如何思考设计？考虑哪些主要内容呢？

设计一套负载均衡架构需要考虑以下主要内容：

目标与需求分析：明确负载均衡的目标和需求，了解系统要支持的负载类型、预期的吞吐量、延迟要求以及容错和可扩展性要求等。
选择负载均衡算法：根据实际情况选择合适的负载均衡算法，如轮询、权重轮询、最小连接数、哈希算法等。不同算法适用于不同场景。
服务器选择与配置：选用合适的服务器硬件和配置，确保服务器性能足够满足负载需求，同时考虑负载均衡策略和算法对服务器的要求。
健康检查与故障处理：设计健康检查机制，监测服务器状态，及时发现故障并从负载均衡中剔除不可用服务器，保证系统的高可用性。
分布式与高可用：考虑设计分布式负载均衡架构，避免单点故障，并保证负载均衡器本身的高可用性。
安全性：确保负载均衡系统的安全性，防止恶意攻击和入侵，采用合适的安全策略，如访问控制、防火墙等。
监控与日志：建立监控系统，实时监控服务器状态和负载均衡器性能，记录日志用于故障排查和性能优化。
网络拓扑与传输协议：设计合理的网络拓扑结构，选择适当的传输协议，确保数据在负载均衡器和服务器之间的高效传输。
扩展性：预留足够的扩展性，确保在负载增加时能够无缝扩展负载均衡系统，保持稳定的性能。
负载均衡器与应用的集成：考虑与应用程序的集成，确保负载均衡器能够准确地将请求转发到后端服务器，同时支持会话保持等功能。

综合考虑以上内容，你可以逐步制定负载均衡架构的设计方案，并在实施过程中不断优化和改进。

6.假如双十一等一些促销有高并发访问量要来访问我们的数据，怎么样做到可靠的服务？

数据要尽量少，首先是指用户请求的数据能少就少。请求的数据包括上传给系统的数据和系统返回给用户的数据（通常就是网页）。还要求系统依赖的数据能少就少，包括系统完成某些业务逻辑需要读取和保存的数据，这些数据一般是和后台服务以及数据库打交道的。
请求数要尽量少，用户请求的页面返回后，浏览器渲染这个页面还要包含其他的额外请求，比如说，这个页面依赖的 CSS/JavaScript、图片，以及 Ajax 请求等等都定义为“额外请求”，这些额外请求应该尽量少。
路径要尽量短，路径要尽量短所谓“路径”，就是用户发出请求到返回数据这个过程中，需求经过的中间的节点数。要缩短访问路径有一种办法，就是多个相互强依赖的应用合并部署在一起，把远程过程调用（RPC）变成 JVM 内部之间的方法调用。
依赖要尽量少所谓依赖，指的是要完成一次用户请求必须依赖的系统或者服务，这里的依赖指的是强依赖。要减少依赖，我们可以给系统进行分级分析。
不要有单点系统中的单点可以说是系统架构上的一个大忌，因为单点意味着没有备份，风险不可控。

在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流。

缓存：缓存比较好理解，在大型高并发系统中，如果没有缓存数据库将分分钟被爆，系统也会瞬间瘫痪。使用缓存不单单能够提升系统访问速度、提高并发访问量，也是保护数据库、保护系统的有效方式。大型网站一般主要是“读”，缓存的使用很容易被想到。在大型“写”系统中，缓存也常常扮演者非常重要的角色。比如累积一些数据批量写入，内存里面的缓存队列（生产消费），以及HBase写数据的机制等等也都是通过缓存提升系统的吞吐量或者实现系统的保护措施。甚至消息中间件，你也可以认为是一种分布式的数据缓存。
降级：服务降级是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。降级往往会指定不同的级别，面临不同的异常等级执行不同的处理。根据服务方式：可以拒接服务，可以延迟服务，也有时候可以随机服务。根据服务范围：可以砍掉某个功能，也可以砍掉某些模块。总之服务降级需要根据不同的业务需求采用不同的降级策略。主要的目的就是服务虽然有损但是总比没有好。
限流：限流可以认为服务降级的一种，限流就是限制系统的输入和输出流量已达到保护系统的目的。一般来说系统的吞吐量是可以被测算的，为了保证系统的稳定运行，一旦达到的需要限制的阈值，就需要限制流量并采取一些措施以完成限制流量的目的。比如：延迟处理，拒绝处理，或者部分拒绝处理等等。

7.一个黑名单集合，数据量很大，快速查询一个值是否在集合里，怎么设计？

采用布隆过滤器，使用一个byte数组保存黑名单集合，使用布隆过滤器原理来判断快速查询一个值是否在集合里。

布隆过滤器基本介绍、特点及使用场景

布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都比一般的算法要好的多，缺点是有一定的误识别率和删除困难。

假设遇到这样一个问题：一个网站有 20 亿 url 存在一个黑名单中，这个黑名单要怎么存？若此时随便输入一个 url，你如何快速判断该 url 是否在这个黑名单中？并且需在给定内存空间（比如：500M）内快速判断出。

哈希算法得出的Integer哈希值最大为：Integer.MAX_VALUE=2147483647，意思就是任何一个URL的哈希都会在0~2147483647之间。那么可以定义一个2147483647长度的byte数组，用来存储集合所有可能的值。为了存储这个byte数组，系统只需要：2147483647/8/1024/1024=256M。比如：某个URL（X）的哈希是2，那么落到这个byte数组在第二位上就是1，这个byte数组将是：000….00000010，重复的，将这20亿个数全部哈希并落到byte数组中。

判断逻辑：如果byte数组上的第二位是1，那么这个URL（X）可能存在。为什么是可能？因为有可能其它URL因哈希碰撞哈希出来的也是2，这就是误判。但是如果这个byte数组上的第二位是0，那么这个URL（X）就一定不存在集合中。

多次哈希：为了减少因哈希碰撞导致的误判概率，可以对这个URL（X）用不同的哈希算法进行N次哈希，得出N个哈希值，落到这个byte数组上，如果这N个位置没有都为1，那么这个URL（X）就一定不存在集合中。

算法特点

因使用哈希判断，时间效率很高。空间效率也是其一大优势。
有误判的可能，需针对具体场景使用。
因为无法分辨哈希碰撞，所以不是很好做删除操作。

使用场景

黑名单
URL去重
单词拼写检查
Key-Value缓存系统的Key校验
ID校验，比如订单系统查询某个订单ID是否存在，如果不存在就直接返回。

布隆过滤器原理

布隆过滤器（Bloom Filter）的核心实现是一个超大的位数组和几个哈希函数。假设位数组的长度为m，哈希函数的个数为k

以上图为例，具体的操作流程：假设集合里面有3个元素{x, y, z}，哈希函数的个数为3。

首先将位数组进行初始化，将里面每个位都设置位0。
对于集合里面的每一个元素，将元素依次通过3个哈希函数进行映射，每次映射都会产生一个哈希值，这个值对应位数组上面的一个点，然后将位数组对应的位置标记为1。
查询W元素是否存在集合中的时候，同样的方法将W通过哈希映射到位数组上的3个点。
如果3个点的其中有一个点不为1，则可以判断该元素一定不存在集合中。反之，如果3个点都为1，则该元素可能存在集合中。

注意：此处不能判断该元素是否一定存在集合中，可能存在一定的误判率。

可以从图中可以看到：假设某个元素通过映射对应下标为4，5，6这3个点。虽然这3个点都为1，但是很明显这3个点是不同元素经过哈希得到的位置，因此这种情况说明元素虽然不在集合中，也可能对应的都是1，这是误判率存在的原因。

整个的写入、查询的流程就是这样，汇总起来就是：对写入的数据做 H 次 hash 运算定位到数组中的位置，同时将数据改为 1 。当有数据查询时也是同样的方式定位到数组中。一旦其中的有一位为 0 则认为数据肯定不存在于集合，否则数据可能存在于集合中。

所以布隆过滤有以下几个特点：

只要返回数据不存在，则肯定不存在。
返回数据存在，但只能是大概率存在。
同时不能清除其中的数据。

第一点应该都能理解，重点解释下 2、3 点。

为什么返回存在的数据却是可能存在呢，这其实也和 HashMap 类似。

在有限的数组长度中存放大量的数据，即便是再完美的 Hash 算法也会有冲突，所以有可能两个完全不同的 A、B 两个数据最后定位到的位置是一模一样的。这时拿 B 进行查询时那自然就是误报了。

删除数据也是同理，当我把 B 的数据删除时，其实也相当于是把 A 的数据删掉了，这样也会造成后续的误报。

基于以上的 Hash 冲突的前提，所以 Bloom Filter 有一定的误报率，这个误报率和 Hash 算法的次数 H，以及数组长度 L 都是有关的。

简单实现一个布隆过滤

基本思路：

首先初始化了一个 int 数组。
写入数据的时候进行三次 hash 运算，同时把对应的位置置为 1。
查询时同样的三次 hash 运算，取到对应的值，一旦值为 0 ，则认为数据不存在。

注意：提高数组长度以及 hash 计算次数可以降低误报率，但相应的 CPU、内存的消耗就会提高；这就需要根据业务需要自行权衡。

public class BloomFilters {

    /**
     * 数组长度
     */
    private int arraySize;

    /**
     * 数组
     */
    private int[] array;

    public BloomFilters(int arraySize) {
        this.arraySize = arraySize;
        array = new int[arraySize];
    }

    /**
     * 写入数据
     * @param key
     */
    public void add(String key) {
        int first = hashcode_1(key);
        int second = hashcode_2(key);
        int third = hashcode_3(key);

        array[first % arraySize] = 1;
        array[second % arraySize] = 1;
        array[third % arraySize] = 1;

    }

    /**
     * 判断数据是否存在
     * @param key
     * @return
     */
    public boolean check(String key) {
        int first = hashcode_1(key);
        int second = hashcode_2(key);
        int third = hashcode_3(key);

        if (array[first % arraySize] == 0 || array[second % arraySize] == 0 
            array[third % arraySize] == 0 ) {
            return false;
        }

        return true;

    }

    /**
     * hash 算法1
     * @param key
     * @return
     */
    private int hashcode_1(String key) {
        int hash = 0;
        int i;
        for (i = 0; i < key.length(); ++i) {
            hash = 33 * hash + key.charAt(i);
        }
        return Math.abs(hash);
    }

    /**
     * hash 算法2
     * @param data
     * @return
     */
    private int hashcode_2(String data) {
        final int p = 16777619;
        int hash = (int) 2166136261L;
        for (int i = 0; i < data.length(); i++) {
            hash = (hash ^ data.charAt(i)) * p;
        }
        hash += hash << 13;
        hash ^= hash >> 7;
        hash += hash << 3;
        hash ^= hash >> 17;
        hash += hash << 5;
        return Math.abs(hash);
    }

    /**
     *  hash 算法3
     * @param key
     * @return
     */
    private int hashcode_3(String key) {
        int hash, i;
        for (hash = 0, i = 0; i < key.length(); ++i) {
            hash += key.charAt(i);
            hash += (hash << 10);
            hash ^= (hash >> 6);
        }
        hash += (hash << 3);
        hash ^= (hash >> 11);
        hash += (hash << 15);
        return Math.abs(hash);
    }
}

Guava实现布隆过滤及源码分析

为使性能效果和内存利用率做到最好，建议使用Guava BloomFilter实现。

    @Test
    public void guavaTest() {
        long star = System.currentTimeMillis();
        BloomFilter<Integer> filter = BloomFilter.create(
                Funnels.integerFunnel(),
                10000000,
                0.01);

        for (int i = 0; i < 10000000; i++) {
            filter.put(i);
        }

        Assert.assertFalse(filter.mightContain(96998));
        long end = System.currentTimeMillis();
        System.out.println("执行时间：" + (end - star));
    }

源码分析如下：

static <T> BloomFilter<T> create(
    Funnel<? super T> funnel, long expectedInsertions, double fpp, Strategy strategy) {
    checkNotNull(funnel);
    checkArgument(expectedInsertions >= 0, "Expected insertions (%s) must be >= 0", expectedInsertions);
    checkArgument(fpp > 0.0, "False positive probability (%s) must be > 0.0", fpp);
    checkArgument(fpp < 1.0, "False positive probability (%s) must be < 1.0", fpp);
    checkNotNull(strategy);

    if (expectedInsertions == 0) {
      expectedInsertions = 1;
    }

    long numBits = optimalNumOfBits(expectedInsertions, fpp);
    int numHashFunctions = optimalNumOfHashFunctions(expectedInsertions, numBits);
    try {
      return new BloomFilter<T>(new LockFreeBitArray(numBits), numHashFunctions, funnel, strategy);
    } catch (IllegalArgumentException e) {
      throw new IllegalArgumentException("Could not create BloomFilter of " + numBits + " bits", e);
    }
  }

从代码可以看出，需要4个参数，分别是

funnel 用来对参数做转化,方便生成hash值
expectedInsertions 预期插入的数据量大小，也就是上文公式中的n
fpp 误判率，也就是上文公式中的误判率p
strategy 生成hash值的策略，guava中也提供了默认策略，一般不需要你自己重新实现

从上面代码可知，BloomFilter创建过程中先检查参数的合法性

使用n和p来计算bitmap的大小m（optimalNumOfBits(expectedInsertions, fpp)）

通过n和m计算hash函数的个数k（optimalNumOfHashFunctions(expectedInsertions, numBits)）

这俩方法的具体实现如下：

static int optimalNumOfHashFunctions(long n, long m) {
    // (m / n) * log(2), but avoid truncation due to division!
    return Math.max(1, (int) Math.round((double) m / n * Math.log(2)));
  }
  static long optimalNumOfBits(long n, double p) {
    if (p == 0) {
      p = Double.MIN_VALUE;
    }
    return (long) (-n * Math.log(p) / (Math.log(2) * Math.log(2)));
  }

除此之外，BloomFilter除了提供创建和几个核心的功能外，还支持写入Stream或从Stream中重新生成BloomFilter，方便数据的共享和传输。

最关键的两个函数如下：

put函数和mightContain函数

MURMUR128_MITZ_64() {
    @Override
    public <T> boolean put(
        T object, Funnel<? super T> funnel, int numHashFunctions, BitArray bits) {
      long bitSize = bits.bitSize();
      byte[] bytes = Hashing.murmur3_128().hashObject(object, funnel).getBytesInternal();
      long hash1 = lowerEight(bytes);
      long hash2 = upperEight(bytes);

      boolean bitsChanged = false;
      long combinedHash = hash1;
      for (int i = 0; i < numHashFunctions; i++) {
        // Make the combined hash positive and indexable
        bitsChanged |= bits.set((combinedHash & Long.MAX_VALUE) % bitSize);
        combinedHash += hash2;
      }
      return bitsChanged;
    }

    @Override
    public <T> boolean mightContain(
        T object, Funnel<? super T> funnel, int numHashFunctions, BitArray bits) {
      long bitSize = bits.bitSize();
      byte[] bytes = Hashing.murmur3_128().hashObject(object, funnel).getBytesInternal();
      long hash1 = lowerEight(bytes);
      long hash2 = upperEight(bytes);

      long combinedHash = hash1;
      for (int i = 0; i < numHashFunctions; i++) {
        // Make the combined hash positive and indexable
        if (!bits.get((combinedHash & Long.MAX_VALUE) % bitSize)) {
          return false;
        }
        combinedHash += hash2;
      }
      return true;
    }

抽象来看，put是写，mightContain是读，两个方法的代码有一点相似，都是先利用murmur3 hash对输入的funnel计算得到128位的字节数组，然后高低分别取8个字节（64位）创建2个long型整数hash1，hash2作为哈希值。循环体内采用了2个函数模拟其他函数的思想，即上文提到的gi(x) = h1(x) + ih2(x) ，这相当于每次累加hash2，然后通过基于bitSize取模的方式在bit数组中索引。

在put方法中，先是将索引位置上的二进制置为1，然后用bitsChanged记录插入结果，如果返回true表明没有重复插入成功，而mightContain方法则是将索引位置上的数值取出，并判断是否为0，只要其中出现一个0，那么立即判断为不存在。

再说一下底层bit数组的实现，主要代码如下：

static final class BitArray {
    final long[] data;
    long bitCount;

    BitArray(long bits) {
      this(new long[Ints.checkedCast(LongMath.divide(bits, 64, RoundingMode.CEILING))]);
    }

    // Used by serialization
    BitArray(long[] data) {
      checkArgument(data.length > 0, "data length is zero!");
      this.data = data;
      long bitCount = 0;
      for (long value : data) {
        bitCount += Long.bitCount(value);
      }
      this.bitCount = bitCount;
    }

    /** Returns true if the bit changed value. */
    boolean set(long index) {
      if (!get(index)) {
        data[(int) (index >>> 6)] |= (1L << index);
        bitCount++;
        return true;
      }
      return false;
    }

    boolean get(long index) {
      return (data[(int) (index >>> 6)] & (1L << index)) != 0;
    }

    /** Number of bits */
    long bitSize() {
      return (long) data.length * Long.SIZE;
    }
...
}

Guava没有使用java.util.BitSet，而是封装了一个long型的数组，另外还有一个long型整数，用来统计数组中已经占用（置为1）的数量，在第一个构造函数中，它把传入的long型整数按长度64分段（例如129分为3段），段数作为数组的长度，你可以想象成由若干个64位数组拼接成一个超长的数组，它的长度就是64乘以段数，即bitSize，在第二个构造函数中利用Long.bitCount方法来统计对应二进制编码中的1个数，这个方法在JDK1.5中就有了，其算法设计得非常精妙，有精力的同学可以自行研究。

另外两个重要的方法是set和get，在get方法中，参考put和mightContain方法，传入的参数index是经过bitSize取模的，因此一定能落在这个超长数组的范围之内，为了获取index对应索引位置上的值，首先将其无符号右移6位，并且强制转换成int型，这相当于除以64向下取整的操作，也就是换算成段数，得到该段上的数值之后，又将1左移index位，最后进行按位与的操作，如果结果等于0，那么返回false，从而在mightContain中判断为不存在。在set方法中，首先调用了get方法判断是否已经存在，如果不存在，则用同样的逻辑取出data数组中对应索引位置的数值，然后按位或并赋值回去。

到这里，对Guava中布隆过滤器的实现就基本讨论完了，简单总结一下：

BloomFilter类的作用在于接收输入，利用公式完成对参数的估算，最后初始化Strategy接口的实例；
BloomFilterStrategies是一个枚举类，具有两个实现了Strategy接口的成员，分别为MURMUR128_MITZ_32和MURMUR128_MITZ_64，另外封装了long型的数组作为布隆过滤器底层的bit数组，其中在get和set方法中完成核心的位运算。

8.一个网站有 20 亿 url 存在一个黑名单中，这个黑名单要怎么存？若此时随便输入一个 url，你如何快速判断该 url 是否在这个黑名单中？并且需在给定内存空间（比如：500M）内快速判断出。

答案如上！

9.设计题：钱包领券的架构设计。

设计实现一套钱包领券系统涉及系统设计、方案设计、接口设计和库表设计。以下是一个基本的分析，有好的请留言分享下，多谢！

系统设计

架构选择：采用微服务架构，将不同功能模块拆分成独立的服务，如用户认证服务、优惠券管理服务、领券服务等，便于扩展和维护。
通信协议：使用RESTful API或Thrift作为服务之间通信的协议，确保接口的一致性和易用性。
异常处理：设计统一的异常处理机制，对错误进行合理的处理和日志记录，提高系统的可靠性和可维护性。

方案设计

用户认证：采用OAuth 2.0协议，支持用户注册、登录、退出等操作，确保用户身份验证和授权。
优惠券管理：建立后台管理系统，用于添加、编辑和删除优惠券，设定领取条件、有效期和使用规则等。
钱包系统：设计用户钱包功能，用于管理用户的优惠券，包括添加、删除、查看和使用优惠券等操作。
消息通知：实现消息推送或电子邮件通知功能，向用户发送优惠券领取成功、过期提醒等信息。

接口设计

用户服务接口：包括用户注册、登录、退出等接口。
优惠券服务接口：包括添加、编辑和删除优惠券、设定领取条件和有效期等接口。
钱包服务接口：包括添加、删除、查看和使用优惠券等接口。
消息通知接口：用于发送消息通知给用户的接口。

库表设计

用户表：存储用户信息，包括用户ID、用户名、密码等。
优惠券表：存储优惠券信息，包括优惠券ID、名称、折扣、有效期等。
用户优惠券表：记录用户领取的优惠券信息，包括用户ID、优惠券ID、领取时间、使用状态等。

综合以上设计分析，你可以按照这些方向逐步实现一套钱包领券系统，提供方便用户领取和使用优惠券的服务，并方便商家管理优惠券活动和评估优惠券的效果。

10.春节红包的架构设计和容量设计

设计春节红包系统的架构和容量需要考虑以下方面，有好的思路请留言：

架构设计

用户系统：包括用户注册、登录和认证等功能，管理用户的身份和权限。
红包系统：用于管理红包的生成、发放和领取，包括红包的种类、金额、数量等属性。
支付系统：处理用户的支付操作，将红包金额从发送者账户扣除，并转入接收者账户。
通知系统：在用户领取红包或支付成功时，发送通知给相关用户，以提供实时反馈。
数据存储：使用数据库或缓存等技术存储用户信息、红包记录、支付记录等数据。

容量设计

预估用户数量：根据用户规模和活跃度预估系统需要支持的用户数量，以确定服务器和数据库的规模。
并发访问量：预估系统在高峰期的并发访问量，以决定服务器和网络的负载能力。
存储容量：根据红包数量和平均金额估算存储容量，包括用户信息、红包记录、支付记录等数据。
高可用性：考虑系统的高可用性需求，设计主从复制、负载均衡、故障转移等机制，确保系统稳定运行。

性能优化

缓存技术：使用缓存来提高系统性能，例如缓存用户信息、红包状态等数据，减少数据库访问。
异步处理：将一些耗时的操作（如支付）设计为异步任务，以提高系统的响应速度。
水平扩展：根据业务需求和负载情况，采用水平扩展来增加系统的处理能力，例如增加服务器数量。

安全性和稳定性

用户身份验证和授权：确保用户领取红包和支付操作的安全性，采用合适的身份验证和授权机制。
防止重复领取和作弊：设计防止用户重复领取红包和作弊的机制，例如限制每个用户的领取次数、使用防作弊算法等。
错误处理和容错机制：考虑系统异常情况下的错误处理和容错机制，保证系统的稳定性和可靠性。

以上是春节红包系统的架构设计和容量设计的一些考虑要点。具体的实现还需要根据业务需求、技术栈和预算等因素进行进一步详细设计和规划。

11.设计一个多级分类的表，然后组装数据返给前端

要设计一个多级分类的表，并将数据组装后返回给前端，可以采用以下的设计思路

一、创建一个数据库表，用于存储多级分类的数据。

表中至少包含以下字段：

id: 分类的唯一标识符。
name: 分类的名称。
parent_id: 父级分类的标识符，用于建立分类之间的层级关系。

二、在表中插入多级分类的数据，确保每个分类都有一个对应的 parent_id 来指定其父级分类。根级分类的 parent_id 可以设置为特定的值（如0或null）。

三、使用适当的数据库查询语句（如递归查询或多次查询），从数据库中检索多级分类的数据。

四、将查询结果按照分类的层级关系进行组装，并构建一个合适的数据结构来表示多级分类的层级结构，例如树形结构。

五、将组装后的数据返回给前端，可以选择将数据转换为 JSON 格式，并通过网络传输给前端应用程序。

下面是一个伪代码示例，展示了如何实现上述步骤：

创建数据库表

CREATE TABLE categories (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    parent_id INT
);

插入分类数据

INSERT INTO categories (id, name, parent_id) VALUES (1, 'Category A', NULL);

INSERT INTO categories (id, name, parent_id) VALUES (2, 'Category B', NULL);

INSERT INTO categories (id, name, parent_id) VALUES (3, 'Subcategory A1', 1);

INSERT INTO categories (id, name, parent_id) VALUES (4, 'Subcategory A2', 1);

INSERT INTO categories (id, name, parent_id) VALUES (5, 'Subcategory B1', 2);

查询多级分类数据

SELECT id, name, parent_id FROM categories;

组装数据并构建层级结构

function buildCategoryTree(categories, parent_id):
    tree = []
    for category in categories:
        if category.parent_id == parent_id:
            subcategories = buildCategoryTree(categories, category.id)
            if subcategories:
                category.subcategories = subcategories
            tree.append(category)
    return tree

categories = executeQuery("SELECT id, name, parent_id FROM categories")
categoryTree = buildCategoryTree(categories, NULL)

返回组装后的数据给前端

response = convertToJSON(categoryTree)
return response

请注意，上述示例是一个简化的伪代码示例，具体实现可能因使用的数据库和编程语言而有所不同。你需要根据实际情况进行调整和适配，以便与你的项目和技术栈相匹配。

最后我们简单的给出一段java代码如下：

package org.zyf.javabasic.letcode.advance;

import com.alibaba.fastjson.JSON;

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

/**
 * @author yanfengzhang
 * @description
 * @date 2023/6/15  23:14
 */
public class Category {
    private int id;
    private String name;
    private int parentId;
    private List<Category> subcategories;

    public Category(int id, String name, int parentId) {
        this.id = id;
        this.name = name;
        this.parentId = parentId;
        this.subcategories = new ArrayList<>();
    }

    public int getId() {
        return id;
    }

    public String getName() {
        return name;
    }

    public int getParentId() {
        return parentId;
    }

    public List<Category> getSubcategories() {
        return subcategories;
    }

    public void addSubcategory(Category subcategory) {
        subcategories.add(subcategory);
    }

    public static List<Category> buildCategoryTree(List<Category> categories) {
        Map<Integer, Category> categoryMap = new HashMap<>();
        List<Category> rootCategories = new ArrayList<>();

        // 构建分类映射表，并找到根级分类
        for (Category category : categories) {
            categoryMap.put(category.getId(), category);
            if (category.getParentId() == 0) {
                rootCategories.add(category);
            }
        }

        // 组装分类层级关系
        for (Category category : categories) {
            if (category.getParentId() != 0) {
                Category parent = categoryMap.get(category.getParentId());
                if (parent != null) {
                    parent.addSubcategory(category);
                }
            }
        }

        return rootCategories;
    }

    public static void main(String[] args) {
        // 模拟数据库查询得到的分类数据
        List<Category> categories = new ArrayList<>();
        categories.add(new Category(1, "Category A", 0));
        categories.add(new Category(2, "Category B", 0));
        categories.add(new Category(3, "Subcategory A1", 1));
        categories.add(new Category(4, "Subcategory A2", 1));
        categories.add(new Category(5, "Subcategory B1", 2));

        // 构建分类层级树
        List<Category> categoryTree = Category.buildCategoryTree(categories);

        // 将组装后的数据转换为 JSON 格式（示例中省略了 JSON 转换的具体代码）
        //String jsonResponse = convertToJSON(categoryTree);

        // 返回数据给前端
        System.out.println(JSON.toJSONString(categoryTree));
    }

    // 辅助方法：将对象转换为 JSON 格式（示例中省略了具体实现）
    private static String convertToJSON(Object object) {
        // 实现省略
        return "";
    }
}

12.业务设计一个订单下单的流程，需要考虑哪些问题和使用哪些技术？如果有状态流转的话如何保证其有序性？

设计订单下单流程时，需要考虑以下问题和使用相关技术：

用户认证和授权：确保只有经过身份验证和授权的用户才能下单。可以使用技术如用户登录和权限管理。
商品选择和库存管理：用户在下单过程中需要选择商品，系统需要对商品库存进行管理，避免超卖情况的发生。可以使用数据库来管理商品信息和库存量，并使用事务来保证操作的原子性和一致性。
支付和交易处理：订单下单后需要进行支付和交易处理。可以使用第三方支付平台（如支付宝、微信支付）或集成支付网关来处理支付流程，保证支付的安全性和可靠性。
物流和配送：根据订单信息，需要安排商品的物流和配送过程。可以使用物流管理系统或与物流公司合作来实现物流跟踪和配送。
有状态流转和有序性：如果订单在下单过程中需要经历多个状态的流转，如待支付、已支付、待发货、已发货等，需要设计合适的状态机来管理订单状态。可以使用状态模式或状态机模式来定义订单状态及其流转规则，并使用数据库事务和乐观锁等机制来保证有序性和数据一致性。
异常处理和回滚：在订单下单流程中，可能会出现各种异常情况，如支付失败、库存不足等。需要设计合理的异常处理机制和回滚策略，确保订单下单流程的可靠性和容错性。
监控和日志记录：为了及时发现问题和进行故障排查，可以使用监控系统和日志记录来跟踪订单下单流程的执行情况和性能指标。

在实现订单下单流程时，可以使用技术栈包括但不限于：后端开发语言（如Java、Python）、Web框架（如Spring、Django）、数据库（如MySQL、MongoDB）、消息队列（如Kafka、RabbitMQ）、缓存（如Redis）、分布式系统（如微服务架构）等。

总之，在订单下单流程设计中，需要考虑业务需求、用户体验、数据安全性、性能优化等方面，并结合适当的技术和工具来实现一个高效、可靠的订单下单系统。

更为详细的如：

订单下单的流程需要考虑以下问题：

用户身份验证：需要验证用户的身份，确保用户有权下单。
商品选择：用户需要选择要购买的商品或服务。
商品数量和价格：用户需要指定购买的商品数量和价格。
支付方式：用户需要选择支付方式，如支付宝、微信支付等。
配送方式：用户需要选择配送方式，如快递、自提等。
收货地址：用户需要提供收货地址。
订单确认：用户需要确认订单信息，包括商品信息、价格、支付方式、配送方式、收货地址等。
订单提交：用户需要提交订单，生成订单号。
订单处理：商家需要处理订单，包括确认订单、准备商品、配送商品等。
订单状态跟踪：用户需要跟踪订单状态，包括订单已提交、商家已确认、商品已准备、商品已配送等。

在架构设计方面，可以采用微服务架构，将订单下单的流程拆分为多个微服务，每个微服务负责一个具体的功能，例如：

用户服务：负责用户身份验证和用户信息管理。
商品服务：负责商品信息管理和商品库存管理。
支付服务：负责支付功能的实现和支付状态的管理。
配送服务：负责配送功能的实现和配送状态的管理。
订单服务：负责订单信息的管理和订单状态的跟踪。

在技术实现方面，可以使用以下技术：

Spring Boot：使用Spring Boot框架实现微服务的开发和部署。
Spring Cloud：使用Spring Cloud框架实现微服务的注册、发现、配置等功能。
MySQL：使用MySQL数据库存储订单信息和用户信息等。
Redis：使用Redis缓存实现数据的快速访问和更新。
RabbitMQ：使用RabbitMQ消息队列实现异步处理和消息通知。
Nginx：使用Nginx实现负载均衡和反向代理等功能。
Docker：使用Docker容器化技术实现微服务的部署和管理。
Kubernetes：使用Kubernetes容器编排技术实现微服务的自动化部署和管理。

在具体实现中，需要考虑以下问题：

微服务之间的通信：需要使用RESTful API或RPC等方式实现微服务之间的通信。
数据库设计：需要设计合理的数据库结构，存储订单信息和用户信息等。
异步处理：需要使用消息队列等方式实现异步处理，提高系统的性能和可靠性。
安全性：需要考虑用户数据的安全性，包括用户身份验证、数据加密等。
并发处理：需要考虑高并发情况下的订单处理和状态跟踪，确保系统稳定性和可靠性。

13.设计题：设计一种聊天模式，在该模式下用户A给用户B发送消息，在B没有回复消息前，A最多可以发送三条消息。实现思路是？具体实现是?

实现该聊天模式可以采用以下思路：

聊天会话管理：建立一个会话对象，用于管理用户A和用户B之间的聊天会话。会话对象可以包含会话ID、参与用户的ID、会话状态等信息。
消息队列：为每个会话创建一个消息队列，用于存储用户A发送给用户B的消息。消息队列可以采用先进先出（FIFO）的方式进行消息存储。
发送消息限制：在用户A向用户B发送消息时，需要进行发送限制。这里可以引入一个计数器，记录用户A已发送的消息数量。初始计数器值为0，每次发送消息时递增。当计数器达到3时，用户A需要等待用户B回复消息才能再次发送消息。
接收消息：用户B在接收到用户A的消息后，可以进行回复操作。回复消息后，可以将该消息从消息队列中删除，并通知用户A。

具体实现可以借助以下技术和组件：

前端界面：使用前端框架（如React、Vue.js）创建用户A和用户B的聊天界面，提供消息发送和接收的交互操作。
后端服务：使用后端语言和框架（如Node.js、Django）创建后端服务，处理用户A和用户B之间的消息传递和限制。
数据库：使用数据库（如MySQL、MongoDB）存储会话信息、消息队列和用户数据。
消息队列服务：使用消息队列服务（如RabbitMQ、Apache Kafka）存储用户A发送给用户B的消息，并实现消息的异步处理和消费。
计数器和状态管理：可以使用缓存（如Redis）来存储计数器的值和会话的状态，以实现快速读写和状态管理。

具体实现流程如下：

用户A登录系统，并与用户B建立聊天会话。
用户A在聊天界面输入消息，点击发送按钮。
后端服务接收到用户A的消息请求，检查计数器的值。
如果计数器小于3，将消息存储到用户A和用户B对应的会话的消息队列中，并将计数器加1。
如果计数器等于3，后端服务返回提示消息给用户A，告知需要等待用户B回复。
用户B在聊天界面接收到用户A的消息，可以进行回复操作。
后端服务接收到用户B的回复消息，将消息从消息队列中删除，并通知用户A。
用户A在接收到用户B的回复后，可以继续发送下一条消息。

通过上述实现，可以满足用户A给用户B发送消息，在B没有回复消息前，A最多可以发送三条消息的要求，并确保有序性和限制条件的满足。

14.定时任务部署在多个服务器会重复执行，一般任务执行一次即可，如何设计保证可用性分析？

当需要在多个服务器上部署定时任务时，确保任务只执行一次并保证可用性是一个重要的设计考虑因素。以下是一些可以采取的方法来解决这个问题：

分布式锁：使用分布式锁来确保只有一个服务器可以获得任务执行的权限。服务器在执行任务之前，先尝试获取分布式锁，如果成功获取到锁，则执行任务，否则放弃执行。常用的分布式锁方案包括基于Redis的RedLock和基于ZooKeeper的ZooKeeper锁。
数据库记录状态：使用数据库记录任务的执行状态，每个服务器在执行任务之前先查询数据库，检查任务是否已经执行过。如果任务已经执行过，则跳过执行；否则，执行任务并更新数据库中的任务状态。
任务调度器：使用一个独立的任务调度器来控制任务的执行。任务调度器负责将任务分发给不同的服务器，并确保每个任务只被一个服务器执行。可以使用现有的任务调度框架，如Quartz或Spring Task，或者自己实现一个简单的任务调度器。
分布式消息队列：使用分布式消息队列来实现任务的异步处理。将任务放入消息队列中，每个服务器从队列中获取任务进行执行。消息队列可以确保每个任务只被一个服务器消费，从而避免重复执行。
去重机制：在任务执行过程中，使用去重机制来避免重复执行。可以使用分布式缓存（如Redis）来存储已执行任务的信息，每个服务器在执行任务之前先查询缓存，如果任务已经执行过，则跳过执行。

无论采用哪种方法，都需要确保分布式环境中的各个服务器之间能够进行有效的通信，并具备共享状态的能力。同时，需要考虑并发情况下的数据一致性和性能问题，选择适合具体场景需求的解决方案。

15.负载均衡的意义是？如何实现负载均衡呢？有哪些算法呢？4层负载均衡和7层负载均衡的区别是？

负载均衡的意义是在一个系统中分摊工作负载，将请求均匀地分发给多个服务器，以提高系统的性能、可用性和扩展性。通过负载均衡，可以实现以下几个重要的目标：

提高性能：负载均衡将请求分发到多个服务器上，使得每个服务器处理的请求量更加均衡，避免单个服务器过载，从而提高整个系统的性能和吞吐量。
提高可用性：通过将请求分发到多个服务器，即使某个服务器发生故障或不可用，其他服务器仍然可以继续处理请求，保证系统的可用性和稳定性。
扩展性：负载均衡使得系统可以通过添加更多的服务器来扩展处理能力，以满足不断增长的请求量和用户数量。

实现负载均衡的方法有多种，以下是几种常见的实现方式：

硬件负载均衡器：使用专门的硬件设备，如硬件负载均衡器（Load Balancer），将请求分发到多个后端服务器。硬件负载均衡器通常具有高性能和可靠性，并提供丰富的负载均衡算法和配置选项。
软件负载均衡器：在软件层面实现负载均衡，常见的软件负载均衡器包括Nginx、HAProxy等。这些负载均衡器通过配置和算法实现请求的分发和负载均衡。
DNS负载均衡：通过DNS服务器返回多个后端服务器的IP地址列表，客户端根据DNS解析结果选择其中一个服务器进行请求。DNS负载均衡的优势是简单易用，但存在缓存和调度不准确的问题。
软件编程实现：在应用程序的代码中编写负载均衡的逻辑，根据一定的负载均衡策略选择目标服务器进行请求。这种方式需要开发人员自行实现负载均衡算法，并集成到应用程序中。

负载均衡的实现方式选择取决于具体的需求、预算和技术栈。硬件负载均衡器通常适用于大规模和高性能的场景，而软件负载均衡器和DNS负载均衡则更适用于中小规模的应用。此外，负载均衡还可以结合其他技术如缓存、反向代理、CDN等来提升系统的性能和可用性。

在负载均衡中，常见的负载均衡算法包括：

轮询（Round Robin）：按照顺序依次将请求分发给后端服务器，循环往复。每个请求依次轮流分发到不同的服务器，实现了请求的均衡分发。
加权轮询（Weighted Round Robin）：为每个后端服务器分配一个权重值，根据权重值来决定请求的分发比例。权重值越高的服务器会获得更多的请求，适用于不同服务器性能不一致的情况。
最少连接（Least Connection）：根据当前连接数来决定请求的分发目标，选择连接数最少的服务器进行请求分发。这样可以尽可能地将请求分发给负载较轻的服务器，提高整体性能。
IP哈希（IP Hash）：根据客户端的IP地址进行哈希运算，将同一IP的请求分发到相同的服务器。这样可以实现对特定客户端的持久性会话，适用于需要保持会话的应用场景。
最少响应时间（Least Response Time）：根据服务器的响应时间来决定请求的分发目标，选择响应时间最短的服务器进行请求分发。这样可以将请求分发给响应速度较快的服务器，提供更好的用户体验。

以上是常见的负载均衡算法，每种算法都有其适用的场景和特点。在实际应用中，根据具体的需求和系统状况选择合适的负载均衡算法是很重要的。另外，还有一些高级的负载均衡算法如最少带宽成本（Least Bandwidth Cost）和一致性哈希（Consistent Hashing），用于处理更复杂的负载均衡问题。

4层负载均衡和7层负载均衡是两种常见的负载均衡方式，它们的区别如下：

4层负载均衡：基于传输层（Transport Layer）的负载均衡，主要关注IP地址和端口信息，根据请求的源IP和目标IP以及端口号来进行负载均衡。常见的4层负载均衡技术有基于网络设备的负载均衡器，如硬件负载均衡器和软件负载均衡器（如LVS、HAProxy等）。
7层负载均衡：基于应用层（Application Layer）的负载均衡，除了关注IP地址和端口信息外，还关注应用层协议（如HTTP、HTTPS等）和具体的应用层数据（如URL、报文头部等）。7层负载均衡可以实现更精细的请求分发策略，例如根据URL路径、域名、报文内容等进行负载均衡。常见的7层负载均衡技术有反向代理服务器（如Nginx、Apache等）和应用层负载均衡器（如F5 BIG-IP、Citrix NetScaler等）。

总结来说，4层负载均衡更关注网络传输层的信息，而7层负载均衡则更关注应用层的信息，具备更高级的请求分发和处理能力。选择适合的负载均衡方式取决于具体的应用场景和需求。

16.系统服务的幂等性实现分析？

系统服务的幂等性是指对于同一个请求，无论执行多少次，结果都是一致的。实现幂等性的关键是在系统设计和实现中采取相应的措施。下面是一些常见的实现幂等性的方法：

请求标识：每个请求都应该携带一个唯一的标识符，可以是一个请求ID或者一个全局唯一的标识符。服务端可以根据这个标识符判断请求的重复性，如果已经处理过相同标识符的请求，可以直接返回之前的结果，而不再执行重复的操作。
幂等性校验：服务端在接收到请求时，可以根据请求的内容和标识来判断是否已经处理过类似的请求。可以通过查询数据库、缓存或者其他持久化存储来检查请求的状态。如果发现之前已经处理过类似请求，可以直接返回之前的结果，避免重复执行操作。
事务处理：对于需要修改数据的操作，可以使用数据库事务或者其他具备原子性的操作来保证幂等性。通过将操作封装在事务中，即使请求被重复执行，只会对数据产生一次影响。
唯一索引约束：对于数据库操作，可以通过在关键字段上创建唯一索引来保证数据的唯一性。这样，在插入或更新数据时，如果违反了唯一索引约束，系统会自动拒绝重复的操作。
状态机设计：将系统的业务逻辑设计成状态机的形式，每个请求的处理都基于当前状态进行。通过状态的转移和限制，可以避免重复的操作。

以上是一些常见的方法，可以根据具体的系统需求和场景选择适合的实现方式。实现幂等性可以提高系统的可靠性和稳定性，确保系统在面对异常情况和重复请求时能够正确处理。

17.怎么表达滑动窗口限流？

滑动窗口限流是一种流量控制的策略，用于限制请求或操作的速率。它基于滑动时间窗口的概念，允许一定数量的请求通过，在滑动窗口内超过限定数量的请求将被限制或拒绝。以下是一种常见的滑动窗口限流算法的表达方式：

在滑动窗口限流算法中，可以使用一个固定大小的时间窗口，窗口被划分为固定大小的时间片段。每个时间片段表示一个固定时间段内允许通过的请求数量。

算法步骤如下：

初始化一个固定大小的时间窗口，包含固定数量的时间片段。
在每个时间片段开始时，将当前时间片段的计数器重置为0。
每当有请求到达时，将其计数加1。
如果请求的时间戳不在当前时间窗口内，将窗口滑动到当前时间，丢弃过期时间片段的计数。
如果当前时间片段内的请求数量超过限定数量，则拒绝或限制该请求。
定期滑动时间窗口，使时间窗口向前滑动，丢弃最旧的时间片段，并在窗口的末尾创建一个新的时间片段。

通过滑动窗口限流算法，可以平滑地控制请求的速率，防止突发流量对系统的影响，并提供一定的公平性。

需要注意的是，滑动窗口限流算法的具体实现可能因应用场景和需求而有所不同，例如可以根据具体业务要求调整时间窗口的大小、时间片段的数量和请求限制的阈值。

18.查询接口调优，不能用缓存，要求实时性，怎么调优？

当查询接口需要实时性且不能使用缓存时，以下是一些调优策略和技术可以帮助提高查询性能：

数据库索引优化：确保查询所涉及的字段上建立了合适的索引。索引可以加快数据库查询的速度，提高查询的效率。分析查询的条件和经常访问的字段，并创建合适的索引以优化查询。
数据库查询语句优化：分析查询语句，确保它们是有效的和高效的。避免不必要的关联查询、多余的字段选择和排序操作。使用数据库查询优化工具或分析器来检查查询语句的执行计划，并根据需要进行调整。
数据库分片或分区：如果数据规模较大，可以考虑将数据库进行分片或分区。这样可以将数据分布在多个物理服务器上，实现并行查询，提高查询性能和吞吐量。
数据库性能调优：对数据库进行性能调优，包括调整数据库参数、优化数据库配置、增加硬件资源等。确保数据库服务器具备足够的计算能力、内存和存储资源以支持高负载的实时查询。
垂直和水平扩展：如果查询负载过重，单台数据库服务器无法满足要求，可以考虑进行垂直扩展（升级硬件规格）或水平扩展（分布式数据库架构）来增加系统的处理能力。
数据库读写分离：如果查询压力主要集中在读操作上，可以考虑实现数据库的读写分离。通过使用主从复制技术，将读操作分流到从服务器，减轻主服务器的负载，提高查询性能。
使用异步处理：如果查询涉及复杂计算或调用第三方服务等耗时操作，可以使用异步处理方式。将耗时操作异步化，让查询接口立即返回，并在后台进行异步处理，减少查询接口的等待时间。
查询优化器和缓存层：考虑使用查询优化器和缓存层的工具或中间件，例如Redis、Memcached等。这些工具可以帮助提供更高效的查询缓存和查询路由，提高查询的响应速度和吞吐量。

综上所述，通过数据库索引优化、查询语句优化、数据库性能调优和扩展等措施，可以提高查询接口的实时性和性能。根据具体情况，可以结合多个技术和策略来进行系统的调优。

19.现在用户要查询一张表，当流控降级时，兜底方案应该是怎么样的？

当流控降级时，即在高并发或突发流量情况下，为了保护系统稳定性和资源的可用性，限制对某个表的查询操作时，可以考虑以下兜底方案：

返回默认值或空结果：对于被流控降级的查询请求，可以立即返回一个默认值或空结果。这样可以快速响应请求，并告知用户当前查询不可用，同时避免等待和资源消耗。
返回静态缓存数据：如果查询的表数据不经常变动，可以在降级时返回预先缓存的静态数据。这样可以提供一些基本信息给用户，并减少对数据库的访问压力。
返回错误提示或友好提示信息：在降级时，返回一个错误提示或友好的提示信息给用户，说明当前查询不可用的原因和可能的解决方案。这样可以增加用户的理解和减少不必要的重试。
异步处理和队列延后处理：当流控降级时，可以将查询请求放入消息队列或异步处理队列中，延后进行处理。这样可以在流量高峰过后逐渐处理积压的请求，减少对实时响应的依赖。
降级策略切换：如果流控降级仍无法满足需求，可以考虑切换到备用的查询服务或降级数据库，以提供有限但可用的查询能力。

无论采用哪种兜底方案，关键是在流控降级时保证系统的可用性和稳定性，同时提供用户一定的反馈信息，避免用户的困惑和不良体验。具体的兜底方案应根据业务需求、系统设计和用户体验等因素进行综合考虑。在实施时，还需要综合考虑系统的负载情况、降级策略的切换条件和恢复机制等方面。

20.用户下订单，订单按什么字段分表？分表之后，如果想按照某个时间段查询指定时间段内的所有用户的订单怎么办？

在订单系统中，分表的方式可以根据具体的业务需求和查询模式进行选择。以下是一些常见的订单分表策略和时间段查询的解决方案：

按订单ID分表：可以根据订单ID的哈希值或取模运算结果将订单分散到不同的表中。这种方式可以将订单均匀地分布到不同的表中，适用于需要快速根据订单ID查询的场景。
按时间范围分表：可以按照订单的创建时间或更新时间将订单分散到不同的表中。例如，可以按月份或按季度创建不同的订单表，将不同时间段内的订单存放在不同的表中。这种方式便于按照时间段查询指定时间的订单。

对于按时间范围分表的情况，为了实现按照某个时间段查询指定时间的订单，可以采用以下方案：

动态表名：在查询时，根据查询的时间范围动态构建需要查询的表名。例如，根据指定的年份和月份构建表名，然后在对应的表中查询订单数据。
数据库分区：可以使用数据库的分区功能，将订单表按照时间范围进行分区。每个分区代表一个时间段，查询时只需指定分区范围，数据库会自动查询对应的分区表。这样可以加速查询，并减少需要扫描的数据量。
跨表查询：如果订单表分散在多个表中，可以使用联合查询或者分布式查询方式，跨越多个表进行查询。将查询的逻辑封装在应用层，通过编程的方式将查询结果汇总。

需要根据具体业务场景和需求选择适合的分表策略，并结合数据库的功能和查询方式来实现指定时间段的订单查询。同时，应注意维护好表之间的关联关系，确保数据的一致性和完整性。

21.给定一个内存区域用来停车，车可能有货车、轿车等，如何高效分配和设计？有哪些最优思考点？反思到程序的内存分配上，如何高效分配和管理内存呢？

设计一个高效的停车区域用于停放不同类型的车辆（货车、轿车等），可以考虑以下最优思考点：

区域规划：合理规划停车区域的布局，确保充分利用空间，尽量减少空置和浪费。考虑道路宽度、车位大小和通行区域等因素。
车位设计：根据车辆类型和尺寸，设计不同大小的车位，以适应不同类型的车辆停放需求。货车和轿车可能需要不同大小的车位。
入口与出口：设计合理的入口和出口，确保车辆进出的流畅性和安全性。可以考虑使用多个入口和出口，避免拥堵。
车位标识：设立明确的车位标识和指示牌，方便车主找到合适的停车位。可以使用颜色或标志来区分不同类型的车位。
车辆流量控制：考虑车辆流量峰值时的应对措施，如设置交通导向标志、引导车辆停放到指定区域等，防止拥堵和混乱。
安全设施：为停车区域提供必要的安全设施，如监控摄像头、照明设备和紧急报警装置，确保车辆和车主的安全。
支付与管理：实现高效的支付和管理系统，可以考虑使用智能停车系统，支持电子支付和车辆识别技术，方便车主缴费和管理车辆信息。
环保考虑：在停车区域的设计中，可以考虑增加绿化带、设置雨水收集系统等，以减少对环境的影响。
可持续性：设计停车区域时应考虑未来的发展和扩展，保持灵活性和可持续性，以适应不断变化的需求。
反馈与改进：定期收集车主的反馈意见，进行改进和优化，以不断提升停车区域的服务质量和用户体验。

综合考虑以上最优思考点，你可以设计一个高效且用户友好的停车区域，满足不同类型车辆的停车需求，并提供便捷的管理和支付服务。

回到内存分析上，高效分配和管理内存是程序设计中非常重要的一部分，可以通过以下方法实现：

动态内存管理：避免静态内存分配过多，尽可能使用动态内存分配，如在C/C++中使用new和delete操作符，或者在其他语言中使用相应的动态内存分配方式。
内存池技术：使用内存池可以提前分配一块较大的内存区域，然后根据需要从内存池中分配内存，避免频繁的内存申请和释放，提高内存管理效率。
内存复用：尽量复用已分配的内存，避免多次分配相同大小的内存块。对于频繁使用的对象或数据结构，可以考虑使用对象池或缓存来复用内存。
内存回收：及时回收不再使用的内存，避免内存泄漏。在动态内存管理中，要注意正确地释放已分配的内存，避免造成内存泄漏问题。
内存对齐：在需要处理大量数据的情况下，注意将数据进行内存对齐，可以提高内存读取的效率。
内存压缩：对于占用较大内存的数据结构，可以考虑使用压缩算法进行内存压缩，减少内存的占用。
内存缓存：对于频繁读取的数据，可以使用内存缓存，避免频繁地从磁盘或网络读取数据，提高访问速度。
内存性能分析：使用内存性能分析工具，监测程序的内存使用情况，及时发现内存问题并进行优化。
内存优化算法：针对特定的内存使用场景，优化算法以减少内存占用，如使用压缩数据结构、避免不必要的内存拷贝等。
防止内存泄漏：在代码编写过程中，注意资源（包括内存）的正确释放，确保程序在长时间运行中不会出现内存泄漏问题。

综合运用上述方法，你可以高效地分配和管理内存，优化程序的内存使用，提高程序性能和稳定性。

22.给一个接口，入参是账户信息，出参是账户余额，问怎么设计接口？

针对这个接口，我们可以按照以下流程进行设计分析：

需求分析：首先需要明确这个接口的使用场景和目的，以及接口的调用者和使用方式。在这个接口中，我们可以假设调用者是一个用户或者系统，需要查询账户的余额信息。
接口设计：根据需求分析的结果，我们可以设计出该接口的输入参数和输出参数。在这个接口中，输入参数应该包含账户信息，如账户名、账户ID等；输出参数应该包含账户余额信息。
数据获取：为了获取账户余额信息，我们需要连接数据库或者其他数据存储系统，查询账户余额信息。在这个过程中，需要注意数据的安全性和可靠性，确保数据的正确性和完整性。
数据处理：获取到账户余额信息后，需要对数据进行处理，如格式化、加密等操作，确保数据的可读性和安全性。
数据返回：最后，将处理后的数据返回给调用者，确保数据的准确性和及时性。

整个流程中，需要注意数据的安全性和可靠性，确保数据的正确性和完整性。同时，需要考虑接口的可扩展性和可维护性，方便后续的升级和优化。

23.学生选课系统做表设计分析，只聚焦在学生选课这个场景，最好说出表之间的关系分析

聚焦在学生选课这个场景进行表设计分析，并描述表之间的关系：

学生表（Students）：学生ID（Primary Key）+姓名+年龄+性别+联系方式
课程表（Courses）：课程ID（Primary Key）+课程名称+授课教师ID（Foreign Key，关联到教师表）+上课时间+上课地点
教师表（Teachers）：教师ID（Primary Key）+姓名+职称+联系方式
选课表（CourseEnrollments）：+选课ID（Primary Key）+学生ID（Foreign Key，关联到学生表）+课程ID（Foreign Key，关联到课程表）+选课时间+选课状态

表之间的关系分析：

学生表与选课表之间是一对多关系，一个学生可以对应多个选课记录。
课程表与选课表之间也是一对多关系，一个课程可以对应多个选课记录，表示不同学生选了该课程。
教师表与课程表之间是一对多关系，一个教师可以授课多门课程。
选课表与学生表和课程表之间是多对一关系，表示一个选课记录对应一个学生和一门课程。
选课表中的学生ID和课程ID分别是外键，与学生表和课程表的主键关联起来，确保数据的完整性和一致性。

通过以上表设计和关系分析，你可以实现一个学生选课系统，方便学生选择课程，同时保持学生、课程和教师信息的管理与关联。

24.微博、微信朋友圈、头条的资讯推荐、快手抖音的视频推荐等，比如一条朋友圈状态、一条微博、一条咨询或一条短视频等发布，对应用户可以实时看到呢？

Feed流是Feed + 流，Feed的本意是饲料，Feed流的本意就是有人一直在往一个地方投递新鲜的饲料，如果需要饲料，只需要盯着投递点就可以了，这样就能源源不断获取到新鲜的饲料。在信息学里面，Feed其实是一个信息单元，比如一条朋友圈状态、一条微博、一条咨询或一条短视频等，所以Feed流就是不停更新的信息单元，只要关注某些发布者就能获取到源源不断的新鲜信息，我们的用户也就可以在移动设备上逐条去浏览这些信息单元。
当前最流行的Feed流产品有微博、微信朋友圈、头条的资讯推荐、快手抖音的视频推荐等，还有一些变种，比如私信、通知等，这些系统都是Feed流系统，Feed流本质上是一个数据流，是将 “N个发布者的信息单元” 通过 “关注关系” 传送给 “M个接收者”。

Feed流系统是一个数据流系统，核心要看数据，分为三类，分别是：

发布者的数据：发布者产生数据，然后数据需要按照发布者组织，需要根据发布者查到所有数据，比如微博的个人页面、朋友圈的个人相册等。
关注关系：系统中个体间的关系，微博中是关注，是单向流，朋友圈是好友，是双向流。不管是单向还是双向，当发布者发布一条信息时，该条信息的流动永远是单向的。
接收者的数据：从不同发布者那里获取到的数据，然后通过某种顺序（一般为时间）组织在一起，比如微博的首页、朋友圈首页等。这些数据具有时间热度属性，越新的数据越有价值，越新的数据就要排在最前面。

针对这三类数据，可以有如下定义：

存储库：存储发布者的数据，永久保存。
关注表：用户关系表，永久保存。
同步库：存储接收者的时间热度数据，只需要保留最近一段时间的数据即可。

设计Feed流系统时最核心的是确定清楚产品层面的定义，需要考虑的因素包括：

产品用户规模：用户规模在十万、千万、十亿级时，设计难度和侧重点会不同。
关注关系（单向、双写）：如果是双向，那么就不会有大V，否则会有大V存在。

Feed流系统设计总结

产品定义：首先需要定义产品，我们要做的产品是哪一种类型

数据存储库分析，针对以上产品分类

如果使用Tablestore，那么存储库表设计结构如下：

系统规模和产品类型，以及存储系统确定后，我们可以确定同步方式，常见的方式有三种

如果选择了Tablestore，那么同步库表设计结构如下：

确定了同步库的架构如下：

整个Feed流系统的基础功能完成了，但是对于一个完整Feed流产品而言，还缺元数据部分，接下来，我们看元数据如何处理：Feed流系统中的元数据主要包括用户详情和列表+关注或好友关系+推送session池

用户详情和列表，如果使用NoSQL数据库Tablestore，那么用户详情表设计结构如下：

关注或好友关系，如果使用Tablestore，那么关注关系表设计结构如下：

多元索引Schema：

查询的时候：

如果需要查询某个人的粉丝列表：使用TermQuery查询固定user_id，且按照timestamp排序。
如果需要查询某个人的关注列表：使用TermQuery查询固定follow_user_id，且按照timestamp排序。

推送session池，如果使用Tablestore，那么session表设计结构如下：

如果选择了Tablestore，那么“评论表”设计结构如下：

如果选择了Tablestore，那么“赞表”设计结构同评论表，这里就不再赘述了。系统架构中加了元数据系统后的架构如下：

Feed流系统的主题架构算是完成了。但是Feed流产品上还未结束，对于所有的feed流产品都需要有搜索能力，比如下面场景：微博中的搜索用户/搜索微博内容/微信中搜索好友等。系统架构中加了搜索功能后的架构如下：

25.什么是读扩散与写扩散？有啥优缺点？

写扩散与读扩散的概念常见于feeds流类型的业务中的数据写入和数据读取的流程。下图简单说明一下读扩散和写扩散：

综合优缺点分析（如下表），读扩散适用于在写多读少的场景，若读请求过多可能导致热点问题。

	优点	缺点
写扩散	控制逻辑和数据读取逻辑简单粉丝数据独立，方便粉丝内容定制化推荐。大V数据丢失，对关注者数据影响不大，关注者依然可以正常读取关注者发布的数据内容。	浪费存储成本写扩散需要使用专门的扩散队列数据实时性较差。（要等待数据扩散完才能看到关注的内容）
读扩散	数据实时性实时率高写入逻辑简单当读少写多时可以省下扩散成本（不需要扩散队列，也可以节省存储）	数据读取会导致热点问题。

26.实现微信二维码扫码PC登录设计？

生成二维码（QR Code）

在技术设计中，你需要使用合适的库或API来生成唯一的登录二维码，并将其展示给用户。二维码中通常包含一个识别码或标识符，用于标记该次登录请求的唯一性。

扫码登录流程

用户访问你的网页或应用后，生成一个登录二维码，并将其展示给用户。
用户使用微信扫描二维码，扫码后会跳转到微信授权页面。
用户确认授权后，微信会将授权回调链接中携带的认证凭证（code）发送给你的回调接口。

与微信服务器通信（Socket相关）

接收回调：后台服务器收到微信回调后，需要使用Socket或HTTP等协议与微信服务器通信，通过微信提供的API验证凭证的有效性和获取用户信息。
获取用户信息：使用认证凭证（code）通过微信API向微信服务器发送请求，获取用户的OpenID和Access Token等信息。
回调处理：处理微信服务器返回的数据，将用户信息与你的系统进行关联，完成登录过程，并返回登录结果给前端。

安全性和异常处理

在生成二维码和处理回调时，要确保安全性，防止恶意攻击和信息泄露。

考虑用户可能取消授权、认证凭证过期或其他异常情况，提供相应的提示和处理方式。

27.微信客户端之间怎么保持的连接？服务器怎么知道其在不在线？

微信客户端之间通过长连接来保持连接，实现实时消息的传递。在移动应用中，通常使用WebSocket技术来建立长连接，而不是传统的HTTP请求，从而保持客户端与服务器之间的持续通信。

具体流程如下：

建立连接：当用户登录微信客户端时，客户端会与服务器建立WebSocket连接。这个连接将保持打开状态，以便实时传递消息。
保持连接：客户端和服务器之间的WebSocket连接会保持打开状态，除非用户主动退出或网络异常导致连接断开。
消息传递：当有消息需要传递时，服务器将通过WebSocket向客户端发送消息，而不需要客户端发起请求。这样可以实现实时的消息通知功能。

关于服务器如何知道客户端是否在线，有几种常见的方式：

心跳机制：客户端定期向服务器发送心跳请求，证明自己在线。服务器在一定时间内没有收到心跳请求，就认为客户端离线。
WebSocket状态：服务器通过WebSocket的状态来判断客户端是否在线。如果WebSocket连接保持打开状态，就表示客户端在线；否则认为客户端离线。
推送消息确认：当服务器需要向客户端发送消息时，先向客户端发送一条特殊的确认消息，客户端收到确认消息后，再向服务器回复确认，表示自己在线。

通过这些方式，服务器可以及时得知客户端的在线状态，从而实现实时消息的推送和通知功能。同时，客户端与服务器之间的长连接也可以减少频繁的连接建立和断开操作，提高通信效率。

28.连接池设计分析，从技术难点和实现上分析

连接池是一种常见的优化数据库连接的技术，它可以帮助在数据库连接的管理和重用上提高效率。在连接池的设计和实现上，有以下技术难点和实现要点：

技术难点：

连接的获取与释放：连接池需要有效地管理数据库连接的获取和释放。在高并发情况下，需要避免连接泄漏和连接竞争，确保每个请求都能够获得到可用的数据库连接。
连接的健康检查：连接池需要对数据库连接进行健康检查，及时发现不可用的连接并剔除，以确保连接的可靠性和稳定性。
连接的动态调整：在负载变化较大的情况下，连接池需要能够动态调整连接的数量，以适应不同负载下的需求，避免资源浪费和拥堵。
连接的超时处理：对于长时间未被使用的连接，需要设定超时时间，并及时回收这些连接，防止连接过期或占用过多资源。

实现要点：

连接池大小控制：合理设置连接池的最大连接数和最小连接数，根据系统负载和数据库的处理能力进行调整。
连接复用：连接池需要能够重用已有的连接，而不是每次都创建新的连接，减少连接的创建和销毁开销。
连接池配置：提供灵活的连接池配置选项，允许调整连接池的参数，如最大空闲时间、最大等待时间等，以适应不同的应用场景。
连接健康检查：实现定期对连接的健康检查，包括ping测试等，排除不可用的连接，保证连接的可靠性。
连接回收：对于长时间未被使用的连接，进行超时检查并及时回收，以避免连接的过期和资源浪费。
连接请求管理：在高并发情况下，连接池需要能够合理管理连接请求，防止连接竞争和过多等待，确保请求能够得到及时处理。

29.熔断器设计思路，具体说明实现难点和注意事项

熔断器是一种用于提高系统稳定性的设计模式，它可以在系统出现故障或异常时进行自动熔断，防止故障进一步扩大，保护系统和依赖服务免受过载和连锁故障的影响。下面是熔断器设计的思路，以及实现难点和注意事项：

设计思路：

监控指标：设定监控指标，例如请求失败率、响应时间等，用于判断系统是否出现故障或异常。
阈值设定：设置触发熔断的阈值，当监控指标超过设定的阈值时，触发熔断操作。
熔断操作：触发熔断后，熔断器将停止对依赖服务的请求，并直接返回预设的降级响应或错误信息。
重试机制：熔断器在一定时间内定期尝试重新请求依赖服务，当请求成功后，熔断器逐渐恢复对服务的正常请求。

实现难点和注意事项：

合理设置阈值：设定合理的触发熔断的阈值是一个关键的难点。阈值设置过高可能导致熔断不敏感，而设置过低可能导致误触发熔断。
熔断时间窗口：需要合理设定熔断的时间窗口，即触发熔断后，熔断器在多长时间内不再请求依赖服务。太短可能会频繁切换状态，太长可能导致响应时间过长。
降级响应：熔断器触发后，需要返回预设的降级响应。这个响应应该是快速返回，不消耗过多资源，同时能够明确告知客户端当前服务不可用。
自动恢复：熔断器需要具备自动恢复功能，即在一定时间内尝试重新请求依赖服务。自动恢复的频率需要根据具体情况进行调整。
熔断器状态：熔断器需要具备状态管理，包括熔断状态、半开状态和关闭状态。在熔断状态下，需要设定定期检查依赖服务状态的时间间隔。
熔断器与依赖服务解耦：确保熔断器的设计和依赖服务解耦，避免因为熔断器的问题影响依赖服务本身。

30.如何设计一个订单系统？

具体订单设计可见博客：美团外卖订单中心的演进 - 美团技术团队，重点可以关注一下对应的实现难点。

31.数据库设计题：要求设计一个合理的数据库模型，考虑数据库结构、索引设计、数据分片、读写分离、数据同步等问题。

当设计一个合理的数据库模型时，需要综合考虑数据库结构、索引设计、数据分片、读写分离以及数据同步等问题。以下是对每个方面的设计思考：

数据库结构设计

实体和关系：识别业务中的实体和它们之间的关系，例如订单、用户、产品等实体，建立适当的关联关系。
规范化设计：将数据库设计规范化，避免数据冗余，减少数据存储和维护的开销。

索引设计

根据查询需求：根据常见的查询操作，选择合适的字段作为索引，提高查询性能。
覆盖索引：确保索引能够覆盖查询所需的字段，减少对数据表的二次查询。

数据分片

分片策略：根据数据量和查询负载，选择合适的数据分片策略，如基于哈希、范围等分片方式。
数据迁移：考虑数据迁移的问题，当数据量增长时，如何实现数据的动态分片和迁移。

读写分离

主从复制：设置主数据库用于写入操作，多个从数据库用于读取操作，提高读取性能和扩展性。
负载均衡：使用负载均衡技术，将读取请求均匀地分配给多个从数据库。

数据同步

主从同步：确保主数据库的数据变更能够及时同步到所有从数据库，保持数据的一致性。
异步同步：考虑使用异步方式进行数据同步，减少对主数据库的性能影响。

另外，还需要注意以下几个方面：

数据库安全性：保护敏感数据，设置适当的权限和加密机制，防止数据泄露和恶意访问。
容灾备份：设计容灾和备份策略，确保数据库的高可用性和数据的安全性。
数据库性能调优：对数据库进行性能优化，包括查询优化、索引优化、缓存策略等，提高数据库性能。

32.分布式系统设计题：要求设计一个分布式系统，包括分布式任务调度、分布式锁、分布式ID生成等。

设计一个分布式系统涉及分布式任务调度、分布式锁和分布式ID生成等，以下是对每个方面的设计思考：

分布式任务调度

任务调度中心：设计一个中心化的任务调度系统，负责接收任务请求，并进行任务调度和分配。可以使用消息队列来接收和分发任务。
任务队列：将任务放入任务队列中，多个工作节点从队列中获取任务并执行，保证任务的有序执行和避免重复执行。
任务执行状态：在任务调度系统中记录任务的执行状态，包括正在执行、已完成、失败等，以便监控任务的执行情况。
故障处理：考虑工作节点故障的情况，设计故障恢复机制，确保任务能够重新调度和执行。

分布式锁

锁服务：设计一个分布式锁服务，确保在分布式环境中对共享资源的访问具有原子性和互斥性。
锁的获取和释放：规定获取锁和释放锁的规则，并严格保证锁的正确释放，避免死锁和资源争用。
锁的超时处理：设置锁的超时时间，确保即使锁未正常释放，也能在一定时间内自动解锁。

分布式ID生成

ID生成器：设计一个分布式ID生成器，保证在分布式环境下生成唯一的ID。
生成算法：选择合适的ID生成算法，如Snowflake算法等，确保ID的唯一性和有序性。
分布式一致性：确保在分布式系统中生成的ID在不同节点之间是唯一且连续的。

除了以上的设计要点，还需要注意以下几个方面：

可靠性：设计分布式系统时要考虑故障恢复和容错机制，确保系统在节点故障和网络分区等情况下仍然可靠运行。
性能：合理优化分布式系统的性能，包括降低延迟、提高吞吐量、减少资源消耗等。
一致性：保证在分布式环境下的数据一致性，避免数据不一致的情况发生。

33.缓存设计题：要求设计一个高效的缓存系统，考虑缓存策略、缓存一致性、缓存穿透、缓存雪崩等问题。

设计一个高效的缓存系统需要综合考虑缓存策略、缓存一致性、缓存穿透、缓存雪崩等问题。以下是对每个方面的设计思考：

缓存策略

LRU（Least Recently Used）：使用最近最少使用算法，淘汰最近最少使用的缓存项，保留经常访问的数据。
LFU（Least Frequently Used）：使用最不经常使用算法，淘汰访问频率最低的缓存项，保留经常访问的数据。
TTL（Time To Live）：为每个缓存项设置过期时间，超过时间将自动失效并从缓存中删除。

缓存一致性

缓存更新机制：在数据更新时，及时更新缓存数据，保持缓存与数据库数据的一致性。
主动失效：当数据更新后，主动使缓存失效，下次访问时重新从数据库获取最新数据。
异步更新：在数据更新后，异步更新缓存，不影响当前请求的响应速度。

缓存穿透

布隆过滤器（Bloom Filter）：使用布隆过滤器判断请求的数据是否存在于缓存中，如果不存在，则不去查询数据库，避免缓存穿透。
空值缓存：对于数据库中不存在的数据，也缓存一个空值，防止恶意查询导致的缓存穿透。

缓存雪崩

多级缓存：设置多级缓存，将缓存分为不同的层级，降低缓存雪崩的风险。
并发限制：限制同时更新缓存的请求，避免大量请求同时查询数据库导致的缓存雪崩。

另外，还需要注意以下几个方面：

缓存容量：合理设置缓存容量，避免缓存过多导致内存占用过大。
缓存的使用场景：不是所有数据都适合缓存，需要根据业务需求和数据的访问频率来选择合适的缓存策略。
缓存监控：实时监控缓存的命中率、缓存失效率等指标，及时发现问题并进行优化。

34.基础架构设计题：要求设计一个稳定高效的基础架构，如负载均衡、高可用集群、服务发现与治理等。

设计一个稳定高效的基础架构时，需要综合考虑负载均衡、高可用集群、服务发现与治理等方面的设计。以下是对每个方面的设计思考：

负载均衡

负载均衡器：引入负载均衡器，将请求均匀地分发到多个服务器上，以实现负载均衡，提高系统的性能和容量。
算法选择：选择合适的负载均衡算法，如轮询、加权轮询、最少连接数等，根据业务需求和服务器性能进行调整。

高可用集群

多节点部署：设计多节点部署架构，确保在某个节点出现故障时，其他节点能够顶替并继续提供服务。
故障恢复：设置故障检测和故障恢复机制，自动检测节点故障，并快速进行故障切换或自动恢复。
数据冗余：对于涉及数据存储的服务，使用数据冗余技术，如主从复制或多副本存储，确保数据的可靠性和持久性。

服务发现与治理

注册中心：设计服务注册中心，用于管理和注册服务实例，实现服务的自动发现和负载均衡。
健康检查：对服务实例进行健康检查，确保只有健康的实例能够被路由到，避免请求失败或超时。
动态配置：使用动态配置中心，实现服务配置的动态更新和管理，减少对服务的重启和配置文件的修改。

另外，还需要注意以下几个方面：

安全性：加强基础架构的安全性，保护敏感数据和服务免受恶意攻击。
日志和监控：设置日志和监控系统，实时监控基础架构的运行状态，及时发现问题并进行排查。
自动化部署：设计自动化部署流程，减少手动操作，提高部署的效率和准确性。

35.微服务架构设计题：要求设计一个微服务架构，包括服务拆分、服务注册与发现、服务调用等。

设计一个微服务架构时，需要综合考虑服务拆分、服务注册与发现、服务调用等方面的设计。以下是对每个方面的设计思考：

服务拆分

单一职责：将每个微服务设计成只负责一个特定的业务功能，避免一个微服务过于庞大复杂。
业务边界：根据业务领域边界进行服务拆分，确保服务之间的职责清晰，并且服务之间的依赖尽量降低。
数据拆分：根据业务需求将数据拆分到不同的微服务中，避免数据耦合和数据冗余。

服务注册与发现

注册中心：引入注册中心，用于管理和注册微服务实例，实现服务的自动发现和负载均衡。
服务注册：每个微服务在启动时向注册中心注册自己的信息，包括服务名称、IP地址和端口等。
服务发现：其他微服务可以通过查询注册中心获取目标服务的实例信息，并进行服务调用。

服务调用

RESTful API：使用RESTful API设计风格，提供统一的接口让其他微服务调用。
服务代理：可以使用API网关或服务代理来管理微服务之间的调用，提供统一的入口和权限控制。
负载均衡：在服务调用时引入负载均衡机制，确保请求能够均匀地分发到多个服务实例。

另外，还需要注意以下几个方面：

安全性：加强微服务架构的安全性，保护敏感数据和服务免受恶意攻击。
日志和监控：设置日志和监控系统，实时监控微服务的运行状态，及时发现问题并进行排查。
服务版本控制：考虑服务的版本控制，确保不同版本的服务能够兼容和平滑升级。
异常处理：对服务调用进行异常处理，包括重试机制、熔断机制等，保证服务的可靠性。

36.数据结构与算法设计题：要求设计一个高效的算法，如排序算法、查找算法、图算法等。

设计一个高效的算法需要根据具体问题的要求和数据特点来选择合适的算法。以下是对排序算法、查找算法和图算法的设计思考：

排序算法

快速排序：快速排序是一种常用的排序算法，利用分治的思想将数组分为较小和较大的两部分，再递归地对子数组进行排序。
归并排序：归并排序也是一种分治算法，将数组拆分为多个子数组，然后对子数组进行合并排序，最终得到有序数组。
堆排序：堆排序利用堆这种数据结构进行排序，构建最大堆或最小堆后，不断取出堆顶元素，得到有序序列。

查找算法

二分查找：对于有序数组，二分查找是一种高效的查找算法，每次将查找区间缩小一半，直到找到目标元素或确定不存在。
哈希表：使用哈希表来实现查找，将元素映射到对应的哈希桶中，通过哈希函数进行快速查找。
二叉搜索树：对于动态数据集，可以使用二叉搜索树进行查找，平均时间复杂度为O(log n)。

图算法

深度优先搜索（DFS）：利用栈或递归实现DFS，从图的某个节点出发，逐步遍历所有相邻节点，用于遍历和搜索问题。
广度优先搜索（BFS）：利用队列实现BFS，从图的某个节点出发，逐层遍历所有相邻节点，用于最短路径等问题。
最小生成树算法：如Prim算法和Kruskal算法，用于找到图的最小生成树，以最小的代价连接图中所有节点。

需要注意以下几个方面：

时间复杂度：要关注算法的时间复杂度，确保算法在大规模数据下仍然能够高效运行。
空间复杂度：考虑算法的空间复杂度，避免过度消耗内存资源。
稳定性：对于排序算法，需要考虑算法是否稳定，即相等元素是否保持原有的相对位置。
适用场景：根据具体的问题和数据特点，选择合适的算法，避免过度设计和不必要的复杂性。

37.项目中限流怎么做的？漏桶和令牌桶原理，使用的什么数据结构？并发下队列是否有性能问题？

在项目中进行限流是为了保护系统免受过多请求的影响，防止系统因过载而崩溃。常见的限流算法包括漏桶算法和令牌桶算法。

漏桶算法：漏桶算法是一种固定容量的桶，请求按固定的速率进入桶中，如果桶已满，则多余的请求会被丢弃或排队等待。这样可以平滑请求流量，控制请求的处理速率。
令牌桶算法：令牌桶算法也是一种固定容量的桶，但是请求需要消耗令牌才能被处理。令牌以固定的速率被放入桶中，如果桶中没有足够的令牌，则请求被丢弃或排队等待。这样可以在允许的速率内处理请求。

在实现限流算法时，可以使用数据结构来表示漏桶或令牌桶。例如，用队列表示漏桶，按照请求的到达时间依次放入队列。对于令牌桶算法，可以使用令牌数和令牌放入的速率来模拟令牌桶。

在高并发时，队列可能会成为性能瓶颈，因为队列需要维护元素的添加和删除，而这些操作可能是串行的，导致性能下降。为了避免队列成为性能瓶颈，可以考虑以下措施：

使用无锁队列：采用无锁队列可以减少队列的竞争和串行操作，提高并发性能。
队列分片：将队列分为多个片段，每个片段独立维护，减少竞争。
异步处理：将队列的消费过程放到异步线程中，减少对主线程的影响。
增加队列长度：增加队列的长度，避免在高并发情况下队列满导致请求被拒绝。

综上所述，限流是项目中重要的保护措施，漏桶和令牌桶是常用的限流算法。在高并发时，队列可能会存在性能问题，但可以通过采用合适的数据结构和优化措施来减少影响。

38.Rpc和消息队列的优缺点，使用场景

RPC（远程过程调用）和消息队列是两种不同的通信模式，它们各自有优点和缺点，并适用于不同的使用场景。

RPC（远程过程调用）优点：

直观易懂：RPC可以像本地调用一样，通过远程调用来实现不同服务之间的通信，代码结构清晰易懂。
性能较高：RPC直接调用远程服务，通信效率较高，适用于对性能要求较高的场景。
强类型：RPC通常使用强类型的接口定义，能够在编译时进行类型检查，减少潜在的运行时错误。

RPC（远程过程调用）缺点：

耦合性较高：RPC需要明确地调用远程服务，因此服务之间的耦合性较强。
单点故障：如果RPC服务不可用，调用方会直接受到影响，存在单点故障的风险。
部署复杂：由于涉及到服务之间的直接调用，需要确保所有服务都处于可用状态，并且部署和维护较为复杂。

消息队列优点：

解耦：消息队列可以实现异步通信，发送方和接收方之间解耦，降低了系统的耦合性，增加了灵活性。
可靠性：消息队列通常提供持久化功能，确保消息不会丢失，并具有高可靠性。
削峰填谷：消息队列可以缓解请求的峰值，通过削峰填谷来保护后端服务。

消息队列缺点：

性能较低：消息队列的通信方式比RPC复杂，引入了额外的开销，通信效率相对较低。
顺序问题：消息队列保证消息的顺序投递，但是并不保证消息的处理顺序，可能导致消息处理顺序不一致的问题。

使用场景

RPC适用于需要高性能、低延迟的同步通信场景，特别是在微服务架构中常常用于服务之间的直接调用。
消息队列适用于需要解耦、削峰填谷、异步通信的场景，特别是在分布式系统中用于不同服务之间的异步通信和任务分发。

39.如何设计rpc框架？你认为其相比其他框架的优点是什么？

设计RPC（远程过程调用）框架涉及多个组件和设计决策，以下是一个简要的设计概述：

接口定义语言（IDL）：使用IDL定义服务接口，包括服务名称、方法名、参数类型和返回类型等。IDL通常采用类似于Protocol Buffers、Thrift或gRPC的格式。
通信协议：选择合适的通信协议，例如TCP、HTTP/2或自定义协议，以便在客户端和服务端之间传输数据。
序列化和反序列化：将参数和返回值序列化为字节流，在网络上传输，并在接收端进行反序列化。常用的序列化库有JSON、Protocol Buffers等。
服务注册与发现：提供服务注册中心，用于注册和发现可用的服务实例，以便客户端能够找到可用的服务端。
负载均衡：实现负载均衡算法，确保请求均匀地分布到不同的服务实例上，提高系统的可伸缩性和容错性。
连接管理：管理客户端与服务端之间的连接，包括连接的建立、断开和复用，以减少连接开销。
超时和重试机制：设计合理的超时和重试机制，防止长时间等待和增加系统的容错性。
并发处理：考虑并发请求的处理，可以使用线程池或异步机制来提高并发性能。
安全性：考虑数据的加密和认证，确保通信过程中的安全性。
监控与日志：实现监控和日志记录，方便跟踪和排查问题。

优点：

分布式调用：RPC框架可以让不同服务之间的调用就像本地调用一样，简化分布式系统开发。
性能高效：通过优化网络通信和数据传输，RPC框架可以实现高性能的远程调用。
抽象化：RPC框架提供了抽象化的接口定义，使得服务的使用者可以不必关心底层网络通信的细节。
可扩展性：RPC框架支持服务注册与发现，使得系统能够动态添加和删除服务实例，具备较好的可扩展性。
灵活性：可以根据业务需求选择不同的序列化协议、通信协议和负载均衡算法。
解耦：RPC框架将服务的调用者和提供者解耦，使得服务的实现和调用可以独立开发和演进。

综上所述，RPC框架通过简化分布式系统开发、提高性能、提供抽象化接口等优点，成为构建大规模分布式系统的重要工具。但也需要注意合理的设计和配置，以确保其在实际应用中能够发挥最佳效果。

40.一般讨论一个系统或服务的技术难点主要从哪些方面分析？

作为程序员回答一个项目的技术难点时，可以采取以下方法来回答得更好：

先了解项目需求：在回答之前，先仔细了解项目的需求和目标。这样可以确保你回答的难点与项目实际相关。
明确技术难点：将技术难点简洁明了地列出，并逐一说明每个难点的复杂性和挑战性。避免使用技术术语过多，以便非技术人员也能理解。
提供解决方案：针对每个技术难点，提供可能的解决方案或可行的工作流程。解释这些解决方案如何解决难点，以及它们可能的优缺点。
强调团队合作：强调项目中团队合作的重要性，特别是在解决技术难点时，团队的合作是至关重要的。指出你愿意与团队一起努力克服挑战。
坦诚诚实：在回答技术难点时，要坦诚诚实地表达你的观点。避免夸大或低估难点的复杂性，这样可以建立信任和透明度。
陈述经验：如果你在类似的技术难点上有经验，可以提及相关的项目经验，展示你在解决类似问题上的能力和熟练程度。
与他人讨论：如果不确定某些技术难点的解决方案，可以与其他团队成员或专家讨论，寻求他们的建议和帮助。
面对挑战态度：表达你对技术难点的积极态度，愿意学习和不断改进，以确保项目取得成功。

通过以上方法，可以以清晰、专业且积极的方式回答项目的技术难点，展示自己的专业能力和对项目的贡献意愿。

41.做一个商品敏感词系统所面临的技术难点和解决方案有哪些呢？

做一个商品敏感词系统所面临的技术难点和解决方案如下：

技术难点：

敏感词识别：准确识别包含敏感词汇的文本，包括单词拼写错误、变形、简写、遮挡等情况。
大规模数据处理：处理大量商品信息和文本数据，确保高效且快速地进行敏感词过滤。
实时性和低延迟：要求系统在实时应用场景下能够快速响应并过滤敏感词，避免影响用户体验。
多语言支持：支持不同语言的商品信息和文本内容的敏感词检测，涵盖多种语言的敏感词库。
敏感词库管理：维护、更新和扩展敏感词库，确保系统持续有效地检测最新的敏感词。
防止绕过策略：应对用户可能采取的绕过策略，确保系统能够识别和过滤各种敏感内容。

解决方案：

使用自然语言处理（NLP）技术：采用NLP算法和模型，如正则表达式、词向量模型等，来提高敏感词的准确识别。
分布式系统架构：采用分布式架构等。
缓存优化：采用缓存技术，将常用的敏感词缓存起来，降低敏感词识别的计算成本，提高系统的响应速度。
异步处理：使用异步处理机制，将敏感词识别任务从主线程中分离出来，避免阻塞和提高系统的并发处理能力。
多语言支持：选择合适的NLP库，针对不同语言建立相应的敏感词识别模型，以满足多语言支持的需求。
持续学习和更新：定期维护和更新敏感词库，结合用户反馈和实时数据，进行持续学习和优化算法。
敏感词审核：建立敏感词审核机制，对新增的敏感词进行审核和验证，确保只有合法的敏感词能够加入系统库中。
测试和评估：进行全面的测试和评估，包括准确率、召回率和误报率等指标，优化系统的性能和效果。
防御绕过策略：实施多层次的过滤机制，包括字符替换、规则引擎和用户行为监控，防止绕过策略的出现。
安全审计：记录敏感词检测的日志，定期进行安全审计，确保系统稳定性和数据安全。

综合以上解决方案，可以帮助构建一个高效、准确且稳定的商品敏感词系统，有效地过滤敏感内容，提升用户体验，并确保平台的合规性和安全性。

42.在设计一个接口的时候，我们重点关注的点有哪些？

在设计一个接口时，我们重点关注以下几个点：

功能明确性：确保接口的功能和用途明确，不产生歧义，让使用者能够轻松理解其用途和预期行为。
参数设计：合理设计接口的输入参数，确保参数名称和数据类型直观清晰，并提供必要的参数验证机制。
返回值定义：明确接口的返回值类型和格式，包括成功和失败的情况下返回的数据结构，方便使用者处理返回结果。
错误处理：考虑各种可能的错误情况，并定义合适的错误码和错误信息，以便使用者能够准确处理错误。
安全性：确保接口在设计时考虑安全性，包括身份验证、权限控制等，防止潜在的安全漏洞。
可扩展性：为未来可能的功能扩展预留余地，确保接口能够适应系统的演进和变化。
性能优化：考虑接口的性能，避免不必要的计算和数据传输，提供高效的接口调用方式。
文档清晰：提供详细的接口文档，包括接口说明、参数说明、返回值说明和示例，方便使用者正确使用接口。
版本控制：如果有必要，考虑为接口引入版本控制，确保对已有接口的修改不影响现有使用者。
合理命名：使用清晰、简洁、一致的命名规范，让接口易于理解和记忆。

通过关注以上点，设计出符合要求、易于使用、安全稳定且高效的接口，有助于提高开发效率，降低系统集成和使用的风险。

43.服务器的请求转发了解吗？具体讲讲

请求转发是指在网络中，当一个请求到达某个服务器时，该服务器将这个请求转发给另一个服务器进行处理。这个过程中，原始服务器充当了转发者的角色，而被转发的服务器则是实际处理请求的目标服务器。

请求转发可以在不同层级上进行，包括：

应用层请求转发：在应用层，例如Web服务器，可以将HTTP请求转发给其他Web服务器或应用服务器。这种情况下，负载均衡是一个常见的用例，通过将请求分发给多个服务器，以达到负载均衡和提高系统性能的目的。
网络层请求转发：在网络层，路由器或交换机可以根据目标IP地址和端口号将数据包转发给另一个网络节点。这种情况下，通常涉及到路由表，路由器根据路由表中的规则来决定数据包的转发路径。
传输层请求转发：在传输层，例如TCP/UDP协议，请求可以被转发到不同的目标主机和端口。例如，代理服务器可以将请求转发给实际的服务器，以实现代理功能。
DNS请求转发：在域名系统（DNS）中，当一个DNS服务器无法解析某个域名时，它可以将请求转发给另一个DNS服务器，直到找到合适的解析结果或达到最终的根域名服务器。

请求转发的实现通常涉及到网络设备或中间件的配置和管理。它可以用于实现负载均衡、容错、分布式系统中的数据传递等场景。请求转发的目的是将请求有效地路由到适当的处理节点，从而实现更好的系统性能和可靠性。

44.微博评论数可能不准确，如何解决这个问题，因为一般都千人千面的那个人看到的都不一样

微博评论数不准确的问题可能涉及多个因素，包括数据更新延迟、数据过滤、个性化推荐等。虽然完全消除这种问题可能是困难的，但可以采取一些方法来减少这种不准确性：

数据更新和同步： 微博评论数的准确性受到数据更新和同步的影响。确保系统能够及时更新评论数，并且数据同步是及时的。使用合适的数据库或缓存技术来确保数据的实时性。
数据缓存和刷新： 使用缓存可以减轻数据库负载，但缓存的数据可能不是实时的。使用合适的缓存刷新策略，定时或事件触发地刷新缓存中的评论数，以减少不准确性。
分布式系统一致性： 如果系统是分布式的，确保数据在不同节点之间保持一致性。可以使用分布式数据库或分布式锁来实现数据一致性。
用户个性化处理： 鉴于不同用户可能看到不同内容，评论数也可能因此而不同。考虑到用户个性化需求，可以在评论数上添加标识，例如显示评论数的范围（例如 "1000+"）或者提供用户可以定制的选项。
数据采样和估算： 如果评论数在实时性上难以满足准确性要求，可以考虑采样部分数据并进行估算，从而提供一个大致的评论数。这可以减少计算成本，但需要在用户体验和数据准确性之间权衡。
反作弊机制： 评论数可能受到刷评论等恶意行为的影响。实施反作弊机制，监测异常评论行为，并采取相应措施，有助于维护评论数的准确性。
透明度和信息提示： 向用户提供透明度，说明评论数可能会受到不同因素的影响。如果有信息不一致，可以提供用户反馈通道，以便修复问题。

虽然无法完全消除评论数的不准确性，但通过合理的系统设计、数据管理和用户沟通，可以最大程度地减少这种问题对用户体验的影响。

45.布隆过滤器为啥会误判，举例说明？

布隆过滤器是一种用于快速判断一个元素是否存在于集合中的数据结构，它使用一系列哈希函数和位数组来实现。布隆过滤器在判断元素存在性时非常高效，但也有可能发生误判，即判断一个元素存在于集合中，但实际上并不存在。

误判主要由以下几个因素引起：

哈希碰撞： 布隆过滤器使用多个哈希函数来将元素映射到位数组中的位置。如果两个不同的元素映射到了相同的位置，就会产生哈希碰撞。这样，即使一个元素在位数组中被标记为存在，也可能是因为另一个元素的哈希函数产生了相同的位置。
位数组大小： 布隆过滤器的位数组大小决定了其容纳元素的能力。如果位数组大小有限，当插入大量元素时，不可避免地会出现冲突，导致误判。

举个例子来说明：

假设我们有一个位数组大小为 8，并使用两个哈希函数来映射元素到位数组上的位置。现在，我们向布隆过滤器插入两个元素：A 和 B。元素 A 经过两个哈希函数后映射到位数组的第 2 和第 5 个位置，元素 B 映射到位数组的第 3 和第 6 个位置。

如果现在我们想判断元素 C 是否存在于集合中，它经过哈希函数后映射到位数组的第 2 和第 6 个位置，与元素 A 和元素 B 的映射位置重合。这将导致布隆过滤器错误地判断元素 C 存在于集合中，尽管实际上并没有插入过元素 C。

因此，布隆过滤器在设计和使用时需要权衡容错性和误判率。可以通过增加位数组大小、使用更多的哈希函数等方式来降低误判率，但同时也会增加内存占用和计算成本。

46.cpu 飘高的原因分析？生产环境中如何应对？

CPU 飙升（高负载）的原因可以有多种，常见的包括：

高并发： 系统同时处理大量请求，导致 CPU 负载增加。
复杂计算： 执行复杂的计算操作，消耗大量 CPU 资源。
死循环或无限递归： 程序中的死循环或无限递归会占用 CPU。
内存泄漏： 内存泄漏导致程序不断占用更多资源，包括 CPU。
I/O 阻塞： 阻塞的 I/O 操作会导致 CPU 等待，增加负载。
恶意程序或攻击： 恶意代码可能占用大量 CPU 资源。
缓存未命中： 频繁的缓存未命中导致不断加载数据，增加 CPU 负担。
错误配置或设置： 错误的配置可能导致系统过度消耗 CPU 资源。

在生产环境中应对 CPU 飙升问题，可以采取以下措施：

监控和报警： 部署监控系统，实时监测 CPU 使用率，设置阈值并触发报警，及时发现问题。
分析日志： 分析应用程序日志，找出异常情况，确定导致 CPU 飙升的具体原因。
性能优化： 对程序进行性能优化，如减少计算量、优化算法、缓存优化等，降低 CPU 使用率。
并发控制： 通过合理的并发控制策略，限制同时处理的请求数量，避免高并发引起 CPU 飙升。
定位死循环和无限递归： 定位并修复代码中的死循环和无限递归问题。
优化 I/O： 优化 I/O 操作，使用异步 I/O、多线程等方式，避免阻塞。
缓存优化： 优化缓存策略，减少缓存未命中，降低对 CPU 的负荷。
错误处理： 添加合适的错误处理和异常捕获，防止因错误导致的 CPU 飙升。
容量规划： 根据预估的负载，合理规划硬件资源，确保有足够的 CPU 资源可供使用。
自动扩展： 配置自动扩展策略，当 CPU 使用率高时，自动增加资源以分担负载。
应急处理： 出现 CPU 飙升问题时，考虑采取应急措施，如限流、重启服务等，确保系统稳定。

综合来看，对于 CPU 飙升问题，既需要预防和优化，也需要及时应对，以确保系统的稳定性和性能。

47.一个接口的写操作，大约会花费 5 分钟左右的时间。它在开始写时，会把数据库里的一个字段值更新为 start，写入完成后，更新为 done。有另外一个用户也想写入一些数据，但需要等待状态为 done。于是，开发人员在 WEB 端，使用轮询，每隔 5 秒，查询字段值是否为 done，当查询到正确的值，即可开始进行数据写入。你觉得最好的解决方法应该如何实现？

最好的解决方法是使用异步通知机制，而不是轮询：

异步通知机制：当一个用户开始写入数据时，首先将数据库字段值更新为 "start"，然后启动一个后台线程来执行写入操作。在写入完成后，将数据库字段值更新为 "done"，并触发一个事件通知或者发送一个消息到消息队列，通知其他等待写入操作的用户。
等待通知：其他用户在准备写入数据时，不再使用轮询方式查询字段值是否为 "done"。而是订阅写入完成的通知事件或者消息队列，并在收到通知后开始执行写入操作。
消息队列或事件通知：使用消息队列或者事件通知机制来实现异步通知。当写入完成后，后台线程将消息发送到消息队列或者触发一个事件通知，通知所有等待写入操作的用户。
避免线程阻塞：在写入操作时，避免使用同步锁或者阻塞式的等待机制，以充分利用系统资源并提高并发性能。

这种方式避免了轮询的频繁数据库查询，提高了系统的性能和并发能力。同时，它还能够实时地通知其他等待写入操作的用户，提高了系统的响应速度和用户体验。