一
如果线上某台虚机CPU Load过高,该如何快速排查原因?只介绍思路和涉及的Linux命令即可 。
造成cpu load过高的原因: Full gc次数的增大、代码中存在Bug(例如死循环、正则的不恰当使用等)都有可能造成cpu load 增高。
- jps -v:查看java进程号
- top -Hp [java进程号]:查看当前进程下最耗费CPU的线程
- printf “%x\n” [步骤2中的线程号]:得到线程的16进制表示
- jstack [java进程号] | grep -A100 [步骤3的结果]:查看线程堆栈,定位代码行。参考:如何使用JStack分析线程状态
top命令查看个进程cpu使用率
二
请简要描述MySQL数据库联合索引的命中规则,可举例说明。
MySQL联合索引遵循最左前缀匹配规则,即从联合索引的最左列开始向右匹配,直到遇到匹配终止条件。例如联合索引(col1, col2, col3), where条件为col1=‘a’ AND col2='b’可命中该联合索引的(col1,col2)前缀部分, where条件为col2=‘b’ AND col3='c’不符合最左前缀匹配,不能命中该联合索引。
匹配终止条件为范围操作符(如>, <, between, like等)或函数等不能应用索引的情况。例如联合索引(col1, col2, col3), where条件为col1=‘a’ AND col2>1 AND col3=‘c’ 在col2列上为范围查询,匹配即终止,只会匹配到col1,不能匹配到(col1, col2, col3).
where条件中的顺序不影响索引命中。例如联合索引(col1, col2, col3), where条件为col3=
c
AND col2=b AND col1=a
, MySQL优化器会自行进行优化,可命中联合索引(col1, col2, col3).
三
什么是分布式事务,分布式事务产生的原因是什么?分布式事务的解决方案有哪些?分别有哪些优缺点?
分布式事物:将一次大的操作分为很多小的操作,这些小的操作位于各自的服务器上,分布式事物需要保证这些小的操作要么全部成功,要么全部失败。
分布式事物产生的原因:1.为了解决不同数据库操作时数据不一致的问题。2.应用SOA化。
分布式事物的解决方案:
1.2PC:两阶段提交
优点:保证数据的强一致性,适合对数据要求高的强一致性领域。
缺点:实现复杂,牺牲了可用性,性能不高,不适合高并发,高性能的场景。
2.3PC:三阶段提交
优点:相对于二阶段,它减低了阻塞的范围,解决了协调者这参与者同时挂掉的问题,即等待超时后,协调者或参与者会中断事务,避免单点问题。
缺点:数据不一致性依然存在。
3.补偿事务(TCC)
优点:1)性能提升,2)数据最终一致, 3)可靠性更高
缺点:花费高
第二个答案 更具体一点
一次大的操作由不同的小操作组成的,这些小的操作分布在不同的服务器上,分布式事务需要保证这些小操作要么全部成功,要么全部失败。从本质上来说,分布式事务是为了保证不同数据库的数据一致性。
2.1 数据库分库分表
当数据库单表数据达到千万级别,就要考虑分库分表,那么就会从原来的一个数据库变成多个数据库。例如如果一个操作即操作了01库,又操作了02库,而且又要保证数据的一致性,那么就要用到分布式事务。
2.2 应用SOA化
所谓的SOA化,就是业务的服务化。例如电商平台下单操作就会产生调用库存服务扣减库存和订单服务更新订单数据,那么就会设计到订单数据库和库存数据库,为了保证数据的一致性,就需要用到分布式事务。
归根到底是要操作多数据库,并且要保证数据的一致性,而产生的分布式事务的。
解决方案有:
1.用XA实现两阶段提交(2PC)
XA是一个分布式事务协议,由Tuxedo提出。XA中大致分为两部分:事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现,比如Oracle、Mysql等数据库都实现了XA接口,而事务管理器作为全局的调度者,负责各个本地资源的提交回滚。
缺点:1、同步阻塞问题,2、单点故障,3、数据不一致;
2.三阶段提交(3PC)
3PC其实在2PC的基础上增加了CanCommit阶段,是2PC的变种,并引入了超时机制。一旦事务参与者迟迟没有收到协调者的Commit请求,就会自动进行本地commit,这样相对有效的解决了协调者单点故障的问题。但是,性能和数据一致性问题没有根本解决。
3 补偿事务(TCC)
TCC(Try-Confirm-Cancel)又称补偿事务。它实际上与2PC、3PC一样,都是分布式事务的一种实现方案而已。它分为三个操作:
Try阶段:主要是对业务系统做检测及资源预留。
Confirm阶段:确认执行业务操作。
Cancel阶段:取消执行业务操作。
四
请描述https的请求过程。
-
客户端向服务器发起HTTPS请求,连接到服务器的443端口;
-
服务器端有一个密钥对,即公钥(即数字证书)和私钥,是用来进行非对称加密使用的,服务器端保存着私钥,不能将其泄露,公钥可以发送给任何人;
-
服务器将自己的公钥发送给客户端;
-
客户端收到服务器端的公钥之后,检查其合法性,如果发现发现公钥有问题,那么HTTPS传输就无法继续,如果公钥合格,则客户端会生成一个客户端密钥,然后用服务器的公钥对客户端密钥进行非对称加密成密文,至此,HTTPS中的第一次HTTP请求结束;
-
客户端发起HTTPS中的第二个HTTP请求,将加密之后的客户端密钥发送给服务器;
-
服务器接收到客户端发来的密文之后,会用自己的私钥对其进行非对称解密,解密之后的明文就是客户端密钥,然后用客户端密钥对数据进行对称加密,这样数据就变成了密文;
-
然后服务器将加密后的密文发送给客户端;
-
客户端收到服务器发送来的密文,用客户端密钥对其进行对称解密,得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束,整个HTTPS传输完成。
五
什么是事务传播行为?你知道Spring事务中都有哪些传播类型吗?如何使用/指定传播类型?
1) 事务传播用于描述当一个由事务传播行为修饰的方法被嵌套入另外一个方法时,事务如何传播。常用于定义发生事务嵌套时,如何继续执行。
2) Spring 中共定义了7中事务传播类型,明细如下表, 需答出3~4种常见类型即可:
a) PROPAGATION_REQUIRED: 当前没有事务时开启新事务,如果有则加入;
b) PROPAGATION_REQUIRES_NEW: 强制开启新事务,挂起已有事务(如有);
c) PROPAGATION_SUPPORTS: 当前有事务时加入, 没有则以非事务方式执行;
d) PROPAGATION_NOT_SUPPORTED: 以非事务方式执行, 挂起当前事务(如有);
3) 可以在注解或者XML中指定传播类型, 如 “@Transactional(Propagation=xxx)”
六
IO设计中Reactor 和 Proactor 区别。
1、 Reactor被动的等待指示事件的到来并作出反应,有一个等待的过程,做什么都要先放入到监听事件集合中等待handler可用时再进行操作,实现相对简单,对于耗时短的处理场景比较高效,但Reactor处理耗时长的操作会造成事件分发的阻塞,影响到后续事件的处理。
2、Proactor直接调用异步读写操作,调用完后立刻返回,实现了一个主动的事件分离和分发模型;这种设计允许多个任务并发的执行,从而提高吞吐量;并可执行耗时长的任务(各个任务间互不影响),Proactor性能更高,能够处理耗时长的并发场景,但Proactor实现逻辑复杂;依赖操作系统对异步的支持,目前实现了纯异步操作的操作系统少,实现优秀的如windows IOCP,但由于其windows系统用于服务器的局限性,目前应用范围较小;而Unix/Linux系统对纯异步的支持有限,应用事件驱动的主流还是通过select/epoll来实现。
八
给定一个字符串,你的任务是计算这个字符串中有多少个回文子串(回文串是一个正读和反读都一样的字符串)。
具有不同开始位置或结束位置的回文串,即使是由相同的字符组成,也会被计为是不同的子串。
输入描述:
输入仅包含一个字符串,长度不会超过 1000。
输出描述:
输出仅包含一个非负整数, 代表输入字符串有多少个回文子串。
输入例子1:
abc
输出例子1:
3
输入例子2:
aaa
输出例子2:
6
动态规划
import java.util.*;
public class Main {
public static void main (String[] args) {
Scanner in = new Scanner(System.in);
String str = in.next();
int n = str.length();
int res = 0;
boolean[][] dp = new boolean[n][n];
char[] c = str.toCharArray();
for