- 返回数组中第K个最大的元素。比如nums = [3,2,1,6,5,4],k = 2,就返回5
【思路】首先注意一个问题,比如nums有重复值,比如[1,4,4,4,4,4],那么第二大的元素是4还是1?肯定是4,所以完全不需要对nums进行set去重,直接sort排序,对排序后且去重的nums取[-k]就是数组中第K个最大的元素。
以数据intervals表示若干个区间的集合,其中单个区间是intervals[i] = [start,end],请用python合并所有重叠区间,返回一个不重叠的区间数组。该数组需恰好覆盖输入数组中的所有区间。比如intervals=[[1,3],[2,6],[8,29],[30,99]],返回[[1,6],[8,29,][30,99]]。
【思路】这个我开始的想法是将intervals每个数组展开到一个新的list1里,然后for循环比较,如果相邻的左边比右边大,就删除两者。最后因为索引会溢出,强制加上最后一个,最后在恢复成两两一对的数组。但是这个做法是有问题的,首先不建议对list进行remove或者pop,因为会打乱索引,搞得局面很难收拾。其次如果因为索引超出,强制写死最后一个,如果最后一个又不是整个intervals最大值就很尴尬。所以这个最好的办法就是“排序 + 合并”。1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21def merge(intervals):
if not intervals:
return []
# 按 start 排序
intervals.sort(key=lambda x: x[0])
merged = [intervals[0]] # 初始化合并后的列表
for current in intervals[1:]:
last = merged[-1]
# 如果当前区间的 start <= 上一个区间的 end → 重叠,合并
if current[0] <= last[1]:
merged[-1][1] = max(last[1], current[1])
else:
merged.append(current)
return merged
# 示例
intervals = [[1,3],[2,6],[8,29],[30,99]]
print(merge(intervals)) # 输出 [[1, 6], [8, 29], [30, 99]]mysql用唯一索引来去重,这个是什么原因?
唯一索引具备唯一性约束,即当在某个字段(或字段组合)上创建唯一索引后,MySQL 会自动检查插入或更新的数据是否违反唯一性约束。
a. 如果插入的数据与现有数据重复,MySQL 会抛出 Duplicate entry 错误(错误码 1062)。
b. 如果更新的数据导致唯一性冲突,也会报错。
c. 比较常见的场景就是“防止用户重复提交表单(如投票、优惠券领取)”,由数据库层强制保证数据唯一性,无需应用层校验,但是可能增加写操作的延迟。这也是一种“防呆机制”的体现。有一个字符串它的构成是词+空格的组合,如“北京 杭州 杭州 北京”, 要求输入一个匹配模式(简单的以字符来写), 比如 aabb, 来判断该字符串是否符合该模式, 举个例子:1. pattern = “abba”, str=”北京 杭州 杭州 北京” 返回 ture 2. pattern = “aabb”, str=”北京 杭州 杭州 北京” 返回 false 3. pattern = “baab”, str=”北京 杭州 杭州 北京” 返回 ture
【思路】因为是匹配模式,就让人联想到k-v这样的模式,那么对于python来说dict(字典)是最好不过的选择。所以可以以pattern里的每一个元素作为k,然后str对应索引的那个所谓v。如果不在dict里,就先写进去对应的k-v,然后如果k存在那么就比较v,如果v不对,就直接返回false。如果v对就返回ture。不过这里要注意一下,这里需要“双映射机制”,因为有可能出现“模式(pattern):aba,字符串(string):dog dog dog“这样的一对多的情况。1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29def is_match(pattern, string):
words = string.split()
if len(pattern) != len(words):
return False
pattern_to_word = {}
word_to_pattern = {}
for p, w in zip(pattern, words):
if p in pattern_to_word:
if pattern_to_word[p] != w:
return False
else:
if w in word_to_pattern:
# 该词已被其他模式字符映射
return False
pattern_to_word[p] = w
word_to_pattern[w] = p
return True
# 测试用例
if __name__ == "__main__":
# 示例1: 模式 abba
print(is_match("abba", "北京 杭州 杭州 北京")) # 输出: True
# 示例2: 模式 aabb
print(is_match("aabb", "北京 杭州 杭州 北京")) # 输出: False
# 示例3: 模式 baab
print(is_match("baab", "北京 杭州 杭州 北京")) # 输出: True域名被劫持,是什么原理?
域名被劫持是指攻击者通过非法手段篡改域名解析结果或控制域名所有权,将用户引导至恶意网站,窃取敏感信息(如账号密码、支付数据)或进行网络钓鱼。
常见手段:
a.DNS 缓存投毒(DNS Cache Poisoning):攻击者向 DNS 服务器注入错误的 IP 地址,导致后续查询返回恶意地址。
b.入侵DNS 服务器:攻击者入侵目标域名的 DNS 服务器,修改 A 记录或 CNAME 记录。
c.本地 DNS 劫持:在局域网或运营商网络中,攻击者通过 ARP 欺骗或路由器漏洞篡改本地 DNS 配置。
d.域名所有权劫持:攻击者通过盗用域名注册商账户或社会工程学手段,将域名转移到自己控制的账户下,从而控制域名所有权。
e.CDN 劫持:攻击者通过篡改 CDN 配置或利用 CDN 服务漏洞,将域名流量劫持到恶意内容。
等等
- DAO层是啥?
DAO层负责与数据库进行交互,DAO层的主要职责是将数据库操作与业务逻辑分离,提供统一的接口供上层调用。常见技术是JDBC、MyBatis等等。好处如下:
a.DAO 中的数据库操作可被多个业务逻辑复用。
b.为了业务逻辑层(Service)不直接操作数据库,而是通过 DAO 接口调用,降低模块间的依赖。
c.数据库变更(如更换数据库类型)只需修改 DAO 层,无需改动上层代码。
如果是python的话,可以用SQLAlchemy、Django ORM模拟 DAO 层的功能。
- 某个java应用启动很慢,有什么思路去解决?
主要的几个着力点就是:
a.应用镜像包减小:Docker 的镜像由多层只读层(Layer)组成,每个 RUN、COPY、ADD 指令会生成一个新的镜像层(含安装包和临时文件)。合并多个这种指令可以减少镜像层数,从而减小镜像体积。
b.清理删除无用的jar
c.应用分层构建
d.梳理所有的依赖服务,没必要的依赖就可以干掉了。我曾经见过我们的一个国际化的应用,在特定场景下依赖的服务只在某一个单元环境部署,比如应用A在新加坡部署时只依赖新加坡的服务,在杭州部署时会依赖杭州的服务,但代码中的所有consumer还是会在启动的时候全都初始化一遍,导致新加坡部署时HSF consumer还是会对杭州的服务进行初始化,但并没有服务地址可以获取到,就会默认等待3s,服务多了这个时间就会很长了。
e.数据库、缓存这样的中间件在启动的时候会初始化,这里也可以操作一下:比如TDDL(它是在阿里巴巴开源的druid基础上做的)做了分库分表,而且分表数量较多,那么初始化可能会耗费大量时间,就算做了异步,也会因为长尾的原因无法起到太大效果,建议从根本上降低tddl的初始化耗时。
其实在启动的时候,可以关注CPU开销,如果不高,那么就是很多时间在等待(等网络,等io、等锁、等资源),这里要分别关注。按理说jvm停了,cpu就低了,jvm加载类的时候,执行cpu应该很高。
等io还是等锁可以用jstack
来看,查看是否有线程处于BLOCKED(等待锁)或 WAITING(等待 I/O)
状态。
- 如果一个应用在启动的时候发现线程池满,有什么思路?
一般来说应用启动的时候线程池满,会同时搭配cpu飙升的情况,同时要看他的code_cache
利用率,如果code_cache
利用率此时利用率较低,则可以证明“这个应用在启动的过程中是没有预热的,所以启动完成后,cpu直接会到100%”。
那么遇到这种情况,就需要对“代码进行预热”,以解决应用刚启动时,部分请求超时或线程池被打满问题,保证应用提供持续稳定的低响应时间和高吞吐量。
去年你做过的最关键的事儿?
你们做了哪些事儿有效的提升了SLA?
你们为了应付流量上涨都有什么策略?
a. 根据历史的监控情况,做好单链路压测和全链路压测,来做好容器的规划,一半预留30%。
b. 服务尽量做到无状态,将状态数据(session等)外存到redis,这样随时都可以扩容。
c. 配置k8s 的HPA触发自动扩容。
d. 启动的时候预加载缓存/缩容的时候延迟下线,避免请求丢失。
e. 做好限流,sentinel做好服务层接口限流。
f. 通知、日志这些能做异步化的做异步化。
g. 排队机制。
h. 紧急预案,比如临时取消一些非核心的逻辑。我有一个应用,是产出短链接的,每一次产出都不一样,可以被用户分享到各个社交平台,然后用户点击访问。读qps大约3000,写qps大约1000,每一个短链接有效期30天。 从以上几个信息,你能判断出我这个应用需要做哪些稳定性的建设么?