gnwu1111的专栏

1. 安全性问题，由于和第三方接口对接涉及到数据的跨网络传输，为了防止数据被拦。性和可靠性，这两个方面会直接影响用户体验和业务的正常流转，所以需。，需要采用安全的通信机制，比如https协议，以及数据签名等。问限制或者费用，如果存在并发量的限制，需要评估是否满足当前。题考察候选人实际开发过程中是否有参与过第三方接口的对接。很多候选人基本上都是按照第三方的接口文档去写，甚。中，是否有深度思考过对接过程中的一些问题。如果存在费用，需要评估是否符合预算。至成熟一点的三方接口都提供了封装好。

如果在接口中有操作数据库层面的代码，可以优化数据库IO的效率，比如SQL。代码本身的优化，可以利用合适的算法减少时间复杂度、避免一些很明显的重。. 但个部署节点的计算能力瓶颈，也会影响接口性能，可以采用分。务器硬件资源如CPU、内存等，会影响到接口中代码的执行效率。总的来说，接口的性能优化涉及到的因素比较多，如果。所以针对这个问题，可以打开回答的思路，从宏观到。让候选人多说，更好的去了解候选人的技术能力。方法调用，可以采用异步方式避免同步阻塞，从而。网络带宽，带宽的大小会影响数据的传输效率。

听说了吗？IT界发生了一件大事，这个事情导致Java之父余胜军直播间人数狂飙到2000人。评论区言论一边倒，引发了对Java之父这个头衔的质疑和嘲讽！事情是这样的，Java之父余胜军和陆总监直播连麦进行互动，本来聊天氛围和直播间氛围都还不错。结果陆总监突然向Java之父提了一个面试题：结果，Java之父竟然没回答上来，最精彩的是，评论区一堆看热闹不嫌事大的人开始带节奏。事情愈演愈烈，直播间人数从1000直接狂飙到2000人。这个问题其实不难，我梳理了一。

所以我们可以根据错误日志定位到冲突的类或者方法，然后找到所属的包。是把存在冲突版本的包排除就行了。下面来看看完整的回答。常，比如常见的NoSuchMethodExcepti。即便没遇到过，也能基于自己已有的经验去回答出来。个简单的经验问题，一般在工作中都有可能遇到过。应用程序中存在包冲突的情况下，一般不需要主动。因是不同版本的依赖包中的类或者方法存在差异。去发现，程序在运行的时候会提示异。哪些依赖包中引用了不同的版本库。这个工具自带的依赖关系分析或者。析当前应用中的包依赖关系，文件对应的依赖包中，通过

锁竞争：当多个事物同时对同一个表进行读写操作时，就会产生锁竞争，而锁竞争。：索引是提高查询效率的重要手段，但是如果索引失效，就会导致查询效。需要查询大量数据的时候，数据库需要进行数据分页，而数据分页的。，就会导致数据库频繁地进行磁盘IO，从而影响查询效率。大的时候，需要占用更多的内存空间来缓存数据，而如果内。：数据量大意味着需要从磁盘中读取更多的数据，而磁盘。程需要占用大量的CPU资源，因此也会影响查询效率。索引失效的原因可能是查询条件中使用了不支持索引的。的技术能力，让候选人尽可能多的说自己的。

里面涉及到的变量比较多，比如数据行的大小、索引大小会决定B+树的层高，而层高又间接决定不同数据量级的查询性能。对该表的查询维度、查询条件的复杂度，即便在几十万数据的表中也可能会出现查询性能低的问题。以，面对这个问题，建议是可以发散思维去分析，通过知识的宽度来获得认可。：当系统的业务逻辑越来越复杂，不同的业务之间的数据耦合度越来越低，如果某些表的数据访问频率非常高，单个数据库节点无法满足高并。另外，如果单纯基于数据量来推导分库分表的行为是不严谨的。甚至是表结构设计不合理也有影响，比如如果建立的是宽表，

比如我们的user表设置了手机号的唯一索引，假如用户量太大了，将user表进行了分库分表，那么手机号的唯一索引是不是就失效了，这种情况要怎么解决呢：问题分析我们先来分析这个问题。首先，面试官问这个问题背后的潜在业务逻辑是，当有新用户注册的时候，或者用户在换绑手机号的时候。需要判断这个手机号是否已经被其他用户绑定过了，如果在单个表里面，直接使用唯一约束就可以解决。但是在分表以后，这种唯一性不好判断了，因此让我们想想解决办法。问题解答1. 分表后，如何知道这个。

2. 需要从这么大的文件中做筛选，如果用普通的思维方法，查找速度很慢因此可以从这两个方面着手去思考回答思路。面试官更多的是去考察候选人的技术思维和技术积累，因此大胆一点回答没有关系。进行分割成大小为512KB小文件，总共得到2048个小文件，避免一。，小顶堆中最终得到的100个单词，就是top 100了。另外，对于这类问题，我们可以发散自己的思维去回答。不管怎么变，top k问题的本质是一样的。k问题，在面试的时候，会产生很多变体。件，然后采用分治和堆的算法，来解决这。表，把频率前100的单词存入小。

如果CPU和内存使用率都很正常，那就需要进一步开启GC 日志，分析用户线程暂停的时间、各部分内存区域GC次数和时间等指标，可以借助jstat或可视化工具GCeasy等，如果问题出在GC上面的话，考虑是否是内存不够、根据垃圾对象的特点进行参数调。程序运算过程中，会直接或者间接涉及到一些磁盘IO相关的操作，比如程序直接读写磁盘，或者程序依赖的第三方组件涉及到磁盘的持久化存储，所以磁盘的IO效率也会对程序。用率过高，说明当前服务器要处理的指令比较多，当CPU忙不过来的时候，指令的。

秒杀系统的核心有两个。

一致性hash，是一种比较特殊的hash算法，它的核心思想是解决在分布式环境下，hash表中可能存在的动态扩容和缩容的问题。为什么会出现一致性hash一般情况下，我们会使用hash表的方式以keyvalue的方式来存储数据，但是当数据量比较大的时候，我们就会把数据存储到多个节点上，(如图)然后通过hash取模的方法来决定当前key存储到哪个节点上。这种方式有一个非常明显的问题，就是当存储节点增加或者减少的时候，原本的映射关系就会发生变化。

在流量低峰的时候，令牌桶会出现堆积，因此当出现瞬时高峰的时候，有足够多的令牌 可以获取 ，因此令牌桶能够允许瞬时流量的处理。3. (如图)漏桶算法 ，它是一种恒定速率的限流算法，不管请求量是多少 ，服务端的处理效率是恒定的。网关层面的限流、或者接口调用的限流，都可以使用令牌桶算法，像 Google 的 Guava， 和Redisson 的限流 ，都用到了令牌桶算法。它的核心思想是，令牌桶以恒定速率去生成令牌保存到令牌桶里面，桶的大小是固定的， 令牌桶满了以后就不再生成令牌。

4. 使用 redis 里面提供的 setNX 指令 ，比如对于 MQ 消费的场景 ，为了避免 MQ 重 复消费导致数据多次被修改的问题，可以在接受到 MQ 的消息时，把这个消息通过 setNx 写入到 redis 里面 ，一旦这个消息被消费过 ，就不会再次消费。5. 使用状态机来实现幂等 ，所谓的状态机是指一条数据的完整运行状态的转换流程， 比如订单状态 ，因为它的状态只会向前变更，所以多次修改同一条数据的时候，一 旦状态发生变更 ，那么对这条数据修改造成的影响只会发生一次。

有一张 200W 数据量的会员表 ，每个会员会有长短不一的到期时间 ，现在想在快到 期之前发送邮件通知提醒续费”该怎么实现。

3. 从业务层面来考虑，限制页数，一般情况下用户去翻 100W 页来找数据，如果让你 们老板去翻 100w 页，估计第二天就把你开除了。我们通常会通过搜索来优化查找过程。以上就是这个问题的回答思路，面试的时候不一定要完全陷入到面试官的逻辑中，也可以跳出来思考。需要注意 id 是索引列 ，通过索引排序后再 limit ，同样减少了计算次数。关于这个问题 ，有多种解决方案 ，大家可以在回答的时候尽可能的考虑全面一点。1. 如果 id 是连续的 ，可以直接使用这样的方式。

2021 年 7 月 13 日晚上 22：52 ，B 站崩了。整个事件的罪魁祸首竟然只是，这么短短 的几行代码；回到 B 站崩溃那天 ，仅不到半个小时 ，这个消息就冲上了微博的热搜头条。从 B 站出来的用户甚至带崩了 A 站、豆瓣、知乎等多个网站。有网友调侃说， B 站服务器一蹦 ，紧张加班的除了 B 站的程序员 ，同时让 A 站知乎、豆瓣、微博的程序员默默打开了电脑。B 站崩溃的背后 ，背后的根本原因到底是什么呢？在这个事故发生后 ，公司内部必然要做的几件事情。

这种方式适用于大规模数据，但数据状态又不是很多的情况，通常是用来判断某个数据 存不存在的。但是如果我们有几千万甚至上亿的数据的时候 {如图} ，虽然可以通过不同的数据结构 来优化数据检索的时间复杂度 ，但是整体的效率依然很慢，而且会占用非常多的内存空间 ，这个问题该怎么解决呢？它的原理是，当一个元素被加入集合时，通过 K 个散列函数将这个元素映射成一个位数 组中的 K 个点 ，把它们置为 1。检索的时候，使用同样的方式去映射，只要看到每个映射的位置的值是不是 1，就可以大概知道该元素是否存在集合中了。

这样 ，在已经得知到已读消息的数量和具体消息 id 的情况下 ，我们可以直接使用消息 id 来查询没有消费过的数据。这个方案看起来没什么问题，但实际上，我们把所有用户通知的消息全部放在一个表里 面 ，如果有 10W 个用户 ，那么同样的消息需要存储 10W 条。只需要设计一个消息内容表和一个用户通知表，当创建一条系统通知后，数据插入到消息内容表。你们看，一个小小的方案设计的优化，就能带来性能上的巨大提升，这就是为什么很多 企业宁愿多花点钱也要招技术厉害的人的原因了吧。2、点到面的消息传送。

3. 使用状态机的方式来实现幂等 ，在很多的业务场景中 ，都会存在业务状态的流转， 并且这些状态流转只会前进，所以我们在对数据进行修改的时候，只需要在条件里 面带上状态 ，就能避免数据被重复修改的问题。2. 使用 Redis 里面的 setNx 命令，我们可以把当前请求中带有唯一标识的信息存储到 Redis 里面，根据 setNx 命令返回的结果来判断是否是重复执行，如果是则丢弃该请求。为了保证服务端接口的幂等性，我们就需要在服务端的接口中去识别当前请求是重复请 求 ，从而不再进行数据的变更操作。

4.. 利用主流 MQ 中的延迟消息功能，消息发送到 Broker 上以后并不会立刻投递，而是根据消息中设置的延迟时间去投递。3. 时间轮算法 (如图) ，这种算法是采用了一个环状数组+链表的方式来管理延迟任 务 ，我们只需要计算这个订单的超时时间 ，再加入到时间轮里面即可。2. 轮询数据库 ，会给数据库造成很大的压力 ，如果订单表的数据量比较大的情况下， 轮询的效率也会比较低。这个问题简单，直接写个定时任务去轮询数据库，根据订单时间找到超时的订单把它取 消就行了。这种方式存在几个问题。

2、APP 扫描这个二维码，把 APP 的 token 信息、二维码 ID 发送给 Server 端， Server 收到请求后修改二维码的扫码状态 ，并生成一个临时 token。4、用户确认登录后 ，携带临时 token 给到 server ，server 端修改二维码状态 并为网页端生成授权 token。1、在网页端打开登录页面，展示一个二维码，这个二维码有一个唯一编号是服 务端生成的。扫码登录的本质是，通过已经登录过的 App 应用，扫描未登录的 Web 端程序中的二维。