高频面试题汇总：相关业务问题+系统问题+设计问题整理统计

1.遇到线上相关问题怎么排查？

以个人看法来看，存在降级直接降级，关键在于及时止损！！！！然后再分析！！！！

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

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

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

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

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

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

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

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

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，将消息存入对应会话的消息队列，并将计数器加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（主键）、姓名、年龄、性别和联系方式。
课程表（Courses）：涵盖课程ID（主键）、课程名称、授课教师ID（外键，关联教师表）、上课时间和上课地点。
教师表（Teachers）：有教师ID（主键）、姓名、职称和联系方式。
选课表（CourseEnrollments）：具备选课ID（主键）、学生ID（外键，关联学生表）、课程ID（外键，关联课程表）、选课时间和选课状态。

表间关系如下：

学生表和选课表呈一对多关系，即一名学生能有多个选课记录。
课程表与选课表也是一对多关系，意味着一门课程会有多个学生选课记录。
教师表和课程表同样是一对多关系，一位教师可教授多门课程。
选课表和学生表、课程表是多对一关系，一个选课记录对应一名学生和一门课程。
选课表中的学生ID和课程ID作为外键，分别与学生表和课程表的主键关联，保障数据完整一致。

借助上述表设计和关系分析，能搭建学生选课系统，便于学生选课，还能有效管理和关联学生、课程及教师信息。

24.Feed流类型的产品设计问题

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

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。从图中的任意一个节点开始，持续深入探索其相邻节点，依次推进，直至遍历完所有可达节点。DFS常用于解决遍历和搜索相关问题，能深入挖掘图中各个节点的关联信息。
广度优先搜索（BFS）：通过队列来实现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框架通过简化分布式系统开发、提高性能、提供抽象化接口等优点，成为构建大规模分布式系统的重要工具。但也需要注意合理的设计和配置，以确保其在实际应用中能够发挥最佳效果。

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”。而是订阅写入完成的通知事件或者消息队列，并在收到通知后开始执行写入操作。
消息队列或事件通知：使用消息队列或者事件通知机制来实现异步通知。当写入完成后，后台线程将消息发送到消息队列或者触发一个事件通知，通知所有等待写入操作的用户。
避免线程阻塞：在写入操作时，避免使用同步锁或者阻塞式的等待机制，以充分利用系统资源并提高并发性能。

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

参考书籍、文献和资料

原文阅读