运维面试题汇总

[TOC]

1 k8s控制器有几张并阐述其作用

5种控制器类型

1.1： Deployment （web应用）

部署无状态应用，只关心数量，不论角色等，称无状态
管理Pod和ReplicaSet
具有上线部署、副本设定、滚动升级、回滚等功能
提供声明式更新，例如只更新一个新的image
应用场景: web 服务

1.2： StatefulSet（数据库）

部署有状态应用
解决Pod独立生命周期，保持Pod启动顺序和唯一性
稳定，唯一的网络标识符，持久存储(例如: etcd 配置文件，节点地址发生变化，将无法使用)
有序，优雅的部署和扩展、删除和终止(例如: mysql 主从关系，先启动主，再启动从)
有序，滚动更新
应用场景: 数据库

1.3： DaemonSet（监控）

在每一个Node上运行一个Pod
新加入的Node也同样会自动运行一个Pod

1.4：Job分为普通任务（定时任务）

一次性执行
应用场景：离线数据处理，视频解码等业务

1.5： CronJob（周期性任务）

周期性任务，像Linux的Crontab一样。
周期性任务
应用场景：通知，备份

2 k8s创建一个pod未成功判断思路

一般来说，无论 Pod 处于什么异常状态，都可以执行以下命令来查看 Pod 的状态

kubectl get pod <pod-name> -o yaml 查看 Pod 的配置是否正确

kubectl describe pod <pod-name> 查看 Pod 的事件

kubectl logs <pod-name> [-c <container-name>] 查看容器日志

2.1 Pod --Pending状态

Pending 说明 Pod 还没有调度到某个 Node 上面。可以通过

kubectl describe pod <pod-name> 命令查看到当前 Pod 的事件，进而判断为什么没有调度。可能的原因包括

资源不足，集群内所有的 Node 都不满足该 Pod 请求的 CPU、内存、GPU 等资源
HostPort 已被占用，通常推荐使用 Service 对外开放服务端口

2.2 Pod --Waiting 或 ContainerCreating状态

首先还是通过 kubectl describe pod 命令查看到当前 Pod 的事件。可能的原因包括

镜像拉取失败，比如配置了镜像错误、Kubelet 无法访问镜像、私有镜像的密钥配置错误、镜像太大，拉取超时等
CNI 网络错误，一般需要检查 CNI 网络插件的配置，比如无法配置 Pod 、无法分配 IP 地址
容器无法启动，需要检查是否打包了正确的镜像或者是否配置了正确的容器参数

2.3 -Pod – ImagePullBackOff状态

这也是我们测试环境常见的，通常是镜像拉取失败。这种情况可以使用 docker pull <image> 来验证镜像是否可以正常拉取。

或者docker images | grep <images>查看镜像是否存在（系统有时会因为资源问题自动删除一部分镜像），

2.4 Pod – CrashLoopBackOff状态

CrashLoopBackOff 状态说明容器曾经启动了，但可能又异常退出了。此时可以先查看一下容器的日志

kubectl logs <pod-name> kubectl logs --previous <pod-name>

这里可以发现一些容器退出的原因，比如

容器进程退出
健康检查失败退出

2.5 Pod --Error 状态

通常处于 Error 状态说明 Pod 启动过程中发生了错误。常见的原因包括

依赖的 ConfigMap、Secret 或者 PV 等不存在
请求的资源超过了管理员设置的限制，比如超过了 LimitRange等
违反集群的安全策略，比如违反了 PodSecurityPolicy 等
容器无权操作集群内的资源，比如开启RBAC 后，需要为 ServiceAccount 配置角色绑定

2.6 Pod --Terminating 或 Unknown 状态

从 v1.5 开始，Kubernetes 不会因为 Node 失联而删除其上正在运行的 Pod，而是将其标记为 Terminating 或 Unknown 状态。想要删除这些状态的 Pod 有三种方法：

从集群中删除该 Node。使用公有云时，kube-controller-manager 会在 VM 删除后自动删除对应的 Node。而在物理机部署的集群中，需要管理员手动删除 Node（如 kubectl delete node 。
Node 恢复正常。Kubelet 会重新跟 kube-apiserver 通信确认这些 Pod 的期待状态，进而再决定删除或者继续运行这些 Pod。
用户强制删除。用户可以执行

kubectl delete pods <pod> --grace-period=0 --force

强制删除 Pod。除非明确知道 Pod 的确处于停止状态（比如 Node 所在 VM 或物理机已经关机），否则不建议使用该方法。
特别是 StatefulSet 管理的 Pod，强制删除容易导致脑裂或者数据丢失等问题。

2.7 Pod – Evicted状态

出现这种情况，多见于系统内存或硬盘资源不足，可df-h查看docker存储所在目录的资源使用情况，如果百分比大于85%，就要及时清理下资源，尤其是一些大文件、docker镜像。

清除状态为Evicted的pod：

kubectl get pods | grep Evicted | awk '{print $1}' | xargs kubectl delete pod

删除所有状态异常的pod：

kubectl delete pods $(kubectl get pods | grep -v Running | cut -d ' ' -f 1)

删除集群中没有在使用的docker镜像(慎用)：

docker system prune -a

查看pod对应的服务(镜像)版本：

kubectl --server=127.0.0.1:8888 get rc -o yaml | grep image: |uniq | sort | grep ecs-core

2.1面试1

[toc]

1 mysql主从和主主同步区别

1.2 主从同步复制原理复制分成三步：


1. master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）；
2. slave将master的binary log events拷贝到它的中继日志(relay log)；
3. slave重做中继日志中的事件，将改变反映它自己的数据。

1.3 主主

主主复制：互为主从
容易产生的问题：数据不一致；因此慎用
考虑要点：自动增长id

主要配置：
　　配置一个节点使用奇数id
　　　　auto_increment_offset=1 开始点
　　　　auto_increment_increment=2 增长幅度
　　另一个节点使用偶数id
　　　　auto_increment_offset=2
　　　　auto_increment_increment=2

2 k8s网络插件原理calico

calico是一个纯三层的虚拟网络，它没有复用docker的docker0网桥，而是自己实现的， calico网络不对数据包进行额外封装，不需要NAT和端口映射，扩展性和性能都很好
Calico网络提供了DockerDNS服务， 容器之间可以通过hostname访问，Calico在每一个计算节点利用LinuxKernel实现了一个高效的vRouter（虚拟路由）来负责数据转发，它会为每个容器分配一个ip，每个节点都是路由，把不同host的容器连接起来，从而实现跨主机间容器通信。
而每个vRouter通过BGP协议（边界网关协议）负责把自己节点的路由信息向整个Calico网络内传播——小规模部署可以直接互联，大规模下可通过指定的BGProute reflector来完成；Calico基于iptables还提供了丰富而灵活的网络策略，保证通过各个节点上的ACLs来提供多租户隔离、安全组以及其他可达性限制等功能。

网络模式

1.IPIP

把一个IP数据包又套在一个IP包里，即把IP层封装到IP层的一个 tunnel，它的作用其实基本上就相当于一个基于IP层的网桥，一般来说，普通的网桥是基于mac层的，根本不需要IP，而这个ipip则是通过两端的路由做一个tunnel，把两个本来不通的网络通过点对点连接起来。

2.BGP

边界网关协议（BorderGateway Protocol, BGP）是互联网上一个核心的去中心化的自治路由协议。它通过维护IP路由表或‘前缀’表来实现自治系统（AS）之间的可达性，属于矢量路由协议。BGP不使用传统的内部网关协议（IGP）的指标，而是基于路径、网络策略或规则集来决定路由。因此，它更适合被称为矢量性协议，而不是路由协议，通俗的说就是将接入到机房的多条线路（如电信、联通、移动等）融合为一体，实现多线单IP；

3 php-fpm某个进程cpu占用过高排查思路

3.1 使用top定位进程pid

top

3.2 strace跟踪进程利用nohup将strace转为后台执行，直到attach上的php-fpm进程死掉为止：

nohup strace -T -p 13167 > 13167-strace.log &

3.3 查找php-fpm占用过高的原因

我们可以配置php-fpm的慢日志，查找是哪些文件导致php-fpm占用过高。

先找到php-fpm.conf文件位置
ps -ef|grep php
修改php-fpm.conf，并打开日志选项错误日志
error_log = log/php-fpm.log
访问日志
access.log = log/$pool.access.log
访问日志格式
access.format = "%R - %u %t \"%m %r%Q%q\" %s %f %{mili}d %{kilo}M %C%%"
慢日志
slowlog = log/$pool.log.slow
慢日志超时时间
request_slowlog_timeout = 3

4 INGRESS原理做蓝绿发布

Nginx-ingress 是 Kubernetes 生态中的重要成员，主要负责向外暴露服务，同时提供负载均衡等附加功能；
截至目前，nginx-ingress 已经能够完成 7/4 层的代理功能（4 层代理基于 ConfigMap，感觉还有改进的空间）；
Nginx 的 7 层反向代理模式，可以简单用下图表示：

面试2

[TOC]

1 mysql半同步，同步，异步理解

1：Mysql的复制过程就是slave去master拉日志回来，存到relay文件中，然后执行。
2：Master根本不考虑数据是否达到了slave，或者slave是否执行成功了。
3：默认情况下mysql主从复制就是异步的方式，别看好像数据刚被创建，slve就可以看到了，因为你的数据量太小了，无法感受到异步的现象。
4：同步就是两边信息都完全一样，master确认了slvae数据复制并执行成功，才叫同步。

1.1 我们举个生产例子说明一下这件事。

生产中是否做过数据库读写分离？不管什么数据库，读写分离就是为了减轻数据库压力，假设我们有2台服务器，A是写入库，B是读库。用户注册了你网站的会员，注册的时候，是通过A库写入，登录的时候是同步B服务器，对吧？

1.2异步：

注册写到A库，应用前端直接返回注册成功，然后B库才到A库拉取新数据，在本地执行同步。如果由于网络，数据量等原因，B库还没有执行新数据，新用户就点击登录窗口，这个时候，应用前端就提示该用户尚未注册。。蛋疼了吧？？

1.3 同步情况：

注册写到A库，A库要把信息同步到B库，确定B库执行成功后，返回信息给前端，这个时候应用前端才显示注册成功。用户在注册后登录就不会出现异常了。这才符合逻辑吧？Mysql主从复制中，主库根本不去考虑从库是否把信息拷贝过去，或者成功执行了。

1.4 半同步又是什么概念？？

如果按mysql主从复制原理看，slave到master把数据垃取下来，然后执行，执行完后，把状态返回给master，这个时候应用程序才给客户端响应成功，这种延迟，用户都接受吗？找一个折中的方法：Mysql半同步在5.5版本横空出世。

1.5半同步情况：

一主一从，一主多从情况下，Master节点只要确认至少有一个slave接受到了事务，即可向发起请求的客户端返回执行成功的操作，master节点是不需要等待slave节点成功执行完这个事务。slave节点接受到这个事务，并成功写入到本地relay日志中，就算是成功了。
半同步在数据完成性上得到了保障，起码主从架构中，有一个备份集，当然，这也不是说半同步配置成功，就不会丢失数据，都是有可能的，比如sql错误,半同步发现错误后,默认会自动转换成半同步的。有利有弊，半同步也增加了成本，对性能也有一定的影响。开源的就是这样。不然为什么Oracle要收费。哈哈。。

原文链接：https://blog.csdn.net/enweitech/article/details/78467917

2 mysql存储引擎有几种分别作用

存储引擎

2.1、MyISAM

使用这个存储引擎，每个MyISAM在磁盘上存储成三个文件。

（1）frm文件：存储表的定义数据
（2）MYD文件：存放表具体记录的数据
（3）MYI文件：存储索引

frm和MYI可以存放在不同的目录下。MYI文件用来存储索引，但仅保存记录所在页的指针，索引的结构是B+树结构。下面这张图就是MYI文件保存的机制：

2.2、InnoDB

InnoDB是默认的数据库存储引擎，他的主要特点有：

（1）可以通过自动增长列，方法是auto_increment。
（2）支持事务。默认的事务隔离级别为可重复度，通过MVCC（并发版本控制）来实现的。
（3）使用的锁粒度为行级锁，可以支持更高的并发；
（4）支持外键约束；外键约束其实降低了表的查询速度，但是增加了表之间的耦合度。
（5）配合一些热备工具可以支持在线热备份；
（6）在InnoDB中存在着缓冲管理，通过缓冲池，将索引和数据全部缓存起来，加快查询的速度；
（7）对于InnoDB类型的表，其数据的物理组织形式是聚簇表。所有的数据按照主键来组织。数据和索引放在一块，都位于B+数的叶子节点上；

当然InnoDB的存储表和索引也有下面两种形式：

（1）使用共享表空间存储：所有的表和索引存放在同一个表空间中。
（2）使用多表空间存储：表结构放在frm文件，数据和索引放在IBD文件中。分区表的话，每个分区对应单独的IBD文件，分区表的定义可以查看我的其他文章。使用分区表的好处在于提升查询效率。

对于InnoDB来说，最大的特点在于支持事务。但是这是以损失效率来换取的。

2.3、Memory

将数据存在内存，为了提高数据的访问速度，每一个表实际上和一个磁盘文件关联。文件是frm。

（1）支持的数据类型有限制，比如：不支持TEXT和BLOB类型，对于字符串类型的数据，只支持固定长度的行，VARCHAR会被自动存储为CHAR类型；
（2）支持的锁粒度为表级锁。所以，在访问量比较大时，表级锁会成为MEMORY存储引擎的瓶颈；
（3）由于数据是存放在内存中，一旦服务器出现故障，数据都会丢失；
（4）查询的时候，如果有用到临时表，而且临时表中有BLOB，TEXT类型的字段，那么这个临时表就会转化为MyISAM类型的表，性能会急剧降低；
（5）默认使用hash索引。
（6）如果一个内部表很大，会转化为磁盘表。

在这里只是给出3个常见的存储引擎。使用哪一种引擎需要灵活选择，一个数据库中多个表可以使用不同引擎以满足各种性能和实际需求，使用合适的存储引擎，将会提高整个数据库的性能

面试3

[TOC]

1 查看内存命令有多少种

free
top
htop
cat /proc/meminfo

2 内存参数cache和buff区别

Cache：缓存区，是高速缓存（理解为存水池）
Buffer：缓冲区，用于存储速度不同步的设备或优先级不同的设备之间传输数据

3 docker网络原理

host：容器将不会虚拟出自己的网卡，配置自己的IP等，而是使用宿主机的IP和端口。
Container：创建的容器不会创建自己的网卡，配置自己的IP，而是和一个指定的容器共享IP、端口范围。
None：该模式关闭了容器的网络功能。
Bridge：此模式会为每一个容器分配、设置IP等，并将容器连接到一个docker0虚拟网桥，通过docker0网桥以及Iptables nat表配置与宿主机通信。

3.1.host模式，

如果启动容器的时候使用host模式，那么这个容器将不会获得一个独立的Network Namespace，而是和宿主机共用一个Network Namespace。容器将不会虚拟出自己的网卡，配置自己的IP等，而是使用宿主机的IP和端口。

3.2.Container容器模式，

这个模式指定新创建的容器和已经存在的一个容器共享一个 Network Namespace，而不是和宿主机共享。新创建的容器不会创建自己的网卡，配置自己的 IP，而是和一个指定的容器共享 IP、端口范围等。

3.3.none模式，

使用none模式，Docker容器拥有自己的Network Namespace，但是，并不为Docker容器进行任何网络配置。也就是说，这个Docker容器没有网卡、IP、路由等信息。需要我们自己为Docker容器添加网卡、配置IP等。这种网络模式下容器只有lo回环网络，没有其他网卡。

3.4.bridge模式,

当Docker进程启动时，会在主机上创建一个名为docker0的虚拟网桥，此主机上启动的Docker容器会连接到这个虚拟网桥上。虚拟网桥的工作方式和物理交换机类似，这样主机上的所有容器就通过交换机连在了一个二层网络中。

3 k8s 指定节点创建pod命令

在启动Pod的yaml文件中与containers同级别的位置添加如下两行即可

一、使用系统自带标签

kubectl get node --show-labels

#查看所有node节点的标签

nodeSelector:
  kubernetes.io/hostname: node的IP地址或主机名

Pod.spec.nodeSelector通过kubernetes的label-selector机制选择节点，由调度器调度策略匹配label，而后调度Pod到目标节点，该匹配规则属于强制约束。

三设置 Node Lable

kubectl label nodes 107 type=backEndNode1

Tomcatl.yaml文件

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: myweb
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: myweb
    spec:
      nodeSelector:
        type: backEndNode1
      containers:
      - name: myweb
        image: harbor/tomcat:8.5-jre8
        ports:
        - containerPort: 80

四、自己为节点打标签，然后调度到该节点

Kubernetes有着自己特定的调度算法与策略，有Master中的Scheduler组件来实现，根据Node资源使用情况自动调度Pod的创建，通常可以满足我们大部分的需求。但是有时我们希望可以将某些Pod调度到特定硬件节点上，这里采用目前最为简单的nodeName和nodeSelector来实现Pod调度。

kubectl label node k8s-node1 app=dev

nodeSelector:
  app: dev

4 k8s 驱逐某个node节点的pod

一.设置节点不可调度

[root@master ~]# kubectl cordon node02
node/node02 cordoned
[root@master ~]# kubectl get node
NAME     STATUS                     ROLES    AGE    VERSION
master   Ready                      master   184d   v1.14.2
node01   Ready                      <none>   183d   v1.14.2
node02   Ready,SchedulingDisabled   <none>   182d   v1.14.2
[root@master ~]# kubectl get po -o wide
NAME                           READY   STATUS    RESTARTS   AGE   IP             NODE     NOMINATED NODE   READINESS GATES
nginx-master-9d4cf4f77-47vfj   1/1     Running   0          30m   10.244.0.129   master   <none>           <none>
nginx-master-9d4cf4f77-69jn6   1/1     Running   0          30m   10.244.2.206   node02   <none>           <none>
nginx-master-9d4cf4f77-6drhg   1/1     Running   0          30m   10.244.1.218   node01   <none>           <none>

设置node02不可调度，查看各节点状态，发现node02为SchedulingDisabled，此时master不会将新的pod调度到该节点上，但是node02上pod还是正常运行。

二驱逐节点上的pod

[root@master ~]# kubectl drain node02 --delete-local-data --ignore-daemonsets --force 
node/node02 already cordoned

参数说明：

--delete-local-data 即使pod使用了emptyDir也删除
--ignore-daemonsets 忽略deamonset控制器的pod，如果不忽略，deamonset控制器控制的pod被删除后可能马上又在此节点上启动起来,会成为死循环；
--force 不加force参数只会删除该NODE上由ReplicationController, ReplicaSet, DaemonSet,StatefulSet or Job创建的Pod，加了后还会删除’裸奔的pod’(没有绑定到任何replication controller)
可以看到同一时刻只有一个pod进行迁移，对外提供服务的pod始终有9个。

5 k8s默认的命名空间有那些

K8s 初始状态下包含了四个命名空间：

default：默认命名空间。资源未指定命名空间时，均创建在此命名空间下
kube-system：K8s 系统创建的对象在此命名空间下
kube-public：这个命名空间对所有用户可见（包括未授权用户），通常作为保留资源为集群所使用
kube-node-lease：此命名空间用于与各个节点相关的租期（Lease）对象；此对象的设计使得集群规模很大时节点心跳检测性能得到提升

一阿里云面试

[TOC]

1 tomcat几种工作模式（挂掉）

1.1 bio(blocking I/O)- 1.7版本以前默认配置

阻塞式I/O操作，一个线程处理一个请求，缺点：并发量高时，线程数较多，浪费资源。

1.2.nio(new I/O)-1.8版本默认配置

nio是一个基于缓冲区、并能提供非阻塞I/O操作的利用 Java 的异步请求 IO 处理，可以通过少量的线程处理大量的请求
场景数量多连接短的请求，聊天。

1.3.apr

同步非阻塞，服务器实现模式为一个请求一个线程，多路复用器轮询到连接有I/O请求时才启动一个线程进行处理。（类似银行排号，没叫你之前随便干啥，叫到你才可以继续）
场景量多连接长的请求。相册。

2 高可用模式

2.1-NAT模式（NAT）小型

LVS 服务器同时充当一台NAT 网关,请求通过LVS Server 返还。可以将内部网络隐藏.同一个LAN中实现小型LB

2.2 IP隧道模式（TUN）

可以实现让集群中的节点处于不同网络段,

2.3 直连路由模式（DR）大型

当参与集群的计算机和作为控制管理的计算机在同一个网段时可以使用此种方法。控制请求包时直接送到参与集群的node上。当node 请求后将直接把结果返还至用户而不通过LVS Server 返还。DR的优势在于速度快、开销少。

3 lvs调度算法种类

3.1 rr：轮询

rr 算法就是将外部请求顺序轮流分配到集群中的node 上，但不考虑每台node 的负载情况。

3.2 wrr：加权轮询

wrr 算法在rr 算法的基础上会考察每台node的负载情况，并尝试让负较轻的node 承担更多请求。

3.3 lc：最少连接

尝试把新的请求交给当前连接数最少的node ，直到此node 连接数不再属于最少标准

3.4 wlc：加权最少连接

算法也由权重的干预。每台node的权重并综合连接数控制转发行为

3.5 lblc：局部最少连接

算法会加上针对源请求IP地址的路由估算，并尝试把请求发送到与源请求IP路由最近的node 上。此种方法一般用于远程或者是大规模的集群组

3.6 lblcr：带有复制的局部最少连接算法

lblcr 算法是在lblc 算法的基础上增加了一个node 列表，先依据lblc 算法计算出与源请求IP地址最近的一组node ，然后在决定把请求发送到最近一组中的最近的一台node

3.7 dh：目标地址散列算法

相当于随机

3.8 sh：原地址散列算法

相当于随机

4 k8s核心组件（挂掉）

API Server 接口
RC副本控制器（Replication Controller）
调度器（Scheduler）
命名空间控制器（Namespace Controller）
节点控制器（Kubelet)
接收转发（Kube-proxy）
存储器（Etcd）

5 内核调优（挂掉）

net.ipv4.ip_local_port_range = 1024 65535 # 可用端口的范围默认值：32768 61000
net.ipv4.tcp_tw_reuse # nginx-proxy前端代理，访问后端
net.ipv4.tcp_keepalive_time = 1200 # 间隔多久发送1次keepalive探测包默认：1700

net.ipv4.tcp_synack_retries=3
net.ipv4.tcp_syn_retries=3 # 减少SYN-ACK数据包的重发次数（默认是5次）

6 k8s监控

prometheus+grafana 前者采集-后者web界面展示

7 做过哪些自动化

gitlab+jenkins+maven +tomcat 自动集成打包部署
shell脚本自动部署，备份等

8 用过哪些开源运维工具

jumpserver 堡垒机
ewomail 邮箱服务器
nexus jar私服

9 docker和vmware view区别

最大的区别是虚拟化是同一个终端每个服务都是单独依赖一套底层系统，而docker则需一个即可。

10 遇到过哪些比较严重事故

1 测试环境中redis-6379漏洞

**原因：**未做限制通过低版本漏洞注入挖矿病毒，病毒脚本会删除相应目录和运行程序，未做限制导致现有服务被杀掉，并且一些默认路径文件也会被删除。
**方法：**重做系统

2 钱包服务器被攻击.

**原因：**丢失x数量的usdt，通过中间件获取了钱包rpc连接，密钥并修改矿工费以最低提前转入黑客接币地址。架构上客户充值到钱包在实时的转入冷钱包，在时间点被提前转走。
**方法：**重新部署服务器，代码层：开发通过token加密和钱包增加校验，运维：编写shell脚本每秒检测登录lastlog 和 ip 如有异常ip发邮件并直接关机。

3 tomcat上线后内存溢出导致java假死，增加内存限制。

**原因：**内存调用过多，导致java假死，增加内存限制。
方法
tomcat的catalina.sh启动文件增加
JAVA_OPTS="-server -Xms4096m -Xmx4096m -XX:MaxPermSize=512m"

4 rabbitmq堵塞

原因：在某一个时间段，下单量成倍数增加，下单机器人交易对过多，导致盘面k线横盘，无法下单。redis数据和mysql数据不一致等
**方法：**关掉机器人下单，等待队列处理完成。备份里面数据，丢弃掉所有队列，在业务量小的时候在重新导入。优化下单请求数。

tomcat报错无法连接mysql

**原因：**版本更新重启tomcat后在logs日志发现无法连接mysql
**方法：**从本机telnet 数据库，显示正常，从数据库服务器查看是有tomcat服务器的ip连接。在从数据库查看连接实时status，发现几条连接时间为30000秒的，在重启后连接重新请求，时间不会那么长。判断可能是进程假死，杀掉进程，重启tomcat观察连接成功。