- tcp如何保证可靠传输，tcp、udp区别#
tcp与udp区别
- 是否建立连接， udp不建立连接，tcp三次握手
- 是否可靠，udp不需要确认， tcp会有确认、重传、窗口、拥塞等机制
- 应用场景， udp一般用于即时通信，qq，直播； tcp用于文件传输，收发邮件、登录等
- 为什么要三次握手，四次挥手#
为什么要三次握手
确认双发收发功能都正常
为什么要四次挥手
确认双方都没有数据再发送
- 四次挥手的closewait, timewait分别在哪，为什么timewait要等待2msl#
2MSL是两倍的MSL(Maximum Segment Lifetime)，MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间
如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接
TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK
- 设计模式六大原则#
其中设计模式的SOLID原则(Principles)如下：
单一职责原则（Single Responsibility）
开闭原则（Open Closed）
里氏代换原则（Liskov Substitution）
接口隔离原原则（Interface Segregation）
依赖倒置原则（Dependency Inversion）
- 线上需要关注哪些机器参数#
指标 阈值
cpu.iowait 所有进程因为等待IO完成而被阻塞，导致CPU idle所花的时间的百分比
disk.io.util 如果这个指标较高，代表io遇到瓶颈
cpu.busy 60
cpu.load 1以下比较好，1.5 会引起程序响应时间变慢，应触发报警
mem.swapused 一般情况下使用swap，代表物理内存已不足，当系统没有足够物理内存来应付所有请求的时候就会用到 swap 设备。使用 swap 的代价非常大，如果系统没有物理内存可用，就会频繁 swapping，如果 swap 设备和程序正要访问的数据在同一个文件系统上，那会碰到严重的 IO 问题，最终导致整个系统迟缓。
cms gc后的老年代大小
jvm.fullgc.count 5
jvm.yonggc.count 70
jvm.yonggc.meantime(一分钟内的每次年轻代gc的平均时间) 500
- 有哪些处理线上问题的经验#
实际是在考雪崩，限流，降级等措施
xxx ES导致雪崩，bc端未分离，b端下游超时引发的血案
事件: 调用ES持续大量超时，服务bc端都在调用，b端超时时间设置长，占用了很多线程资源，影响C端服务响应，造成C端上游雪崩，影响二十度个服务
(调ES超时的原因？查询请求的返回响应太大了)
事中: 无熔断降级错误，现上线加熔断ES降级，
(降级措施是？返回有损服务，创建活动失败)
事后: bc端分离，对下游添加熔断降级，根本上还是要让es调用查询粒度更小一点，减少es调用的返回量
xxx 慢查询引发的血案1
事件：下单的时候先去删除用户未支付订单并归还库存，但未支付订单表竟然没有给orderid添加索引，导致delete操作锁全表，在当天有大量未支付订单，导致下单接口越来越慢，最终把订单db中的连接数占满，db的整体不可用。
分析原因: DB的客户端在超时的时候会断开连接，但DB服务器还是在执行该操作，或阻塞着，客户端新的调用再申请新的连接，直到把DB的连接池打满，DB完全阻塞在这个查询上，导致不可用。
事前： 1. 学习数据库知识，尤其是索引和锁相关 2. 定时检查服务的索引是否覆盖全 3. 提前做好限流熔断等降级措施
事中： 1. 限流降级， 2. 问题排查，数据库压力没有增加很多，但数据库响应缓慢，应该分析出是慢查询的原因，当很多的慢sql出来时
事后： 1. 对服务整体重新排查
xxx 慢查询引发问题，慢sql导致mq积压
事件: 新表去更新库存，但索引创建的时候没覆盖全场景，后续开发有sql未走到索引，某个周六出现MQ积压告警，看监控发现是慢sql更新，有条update语句未使用到索引，导致更新时锁全表
事中: 临时增加索引
事后: 检查了新表所有设计的sql没有未使用索引的情况。
（慢查询是有可能占用过多的DB资源，把整个DB打垮）（是有可能出现卖超的）
