questions

nber1994

All
Posts
Categories
Tags
About

questions

    ❐else ✎ summary


Questions

OS

虚拟内存 段页式 倒排页表 LRU,LFU算法实现 共享内存 多进程,多线程 如何fork一个进程 exec waitpid exit 页表的copy-on-worite PCB

PCB process control block > task_struct存储了进程的页表,打开文件描述符表,内存描述符,通用寄存器,进程状态等

进程状态 IO多路复用 select,poll,epoll实现和优劣

用户态和内核态区别 进程,线程间通信 什么时候多线程什么时候多进程 线程ID进程组ID 线程和进程的切换和调度,切换的时什么 多进程 - 数据共享复杂,需要进程间通信 - 相对于多线程占用更多的内存 - 进程间切换相对于多线程开销较大 - 编程调试较简单 - 进程间互相不影响 - 适用于多机,性能扩展性较好 多线程 - 数据共享较简单 - 线程间可能会互相影响 - 编程调试较复杂 - 可以利用多核的优势 - 多线程之间切换开销较小

网络

http https

https相比较于http来说,在会话层加入了stl算法加密,过程如下 1.服务端发送来证书和公钥 2.客户端根据内置的颁发机构验证证书的真伪 3.如果证书为假,则报错 4.如果证书为真,则生成随机值,并用公钥加密传递给服务端 5.服务端收到后使用私钥进行解密,拿到随机值 6.之后的通信都使用随机值进行加密

http code

200 ok 301 moved permanly 302 Found 303 See Other 400 Bad Request 401 Nuauthorized 403 forbidden 404 Not Found 500 internal server error 502 bad gateway 503 service unavaliable 504 gateway timout

ISO7层

应用层 用于应用之间的协议 表示层 特定格式和网络通用格式之间的转换 会话层 管理会话,发送策略 传输层 节点之间的可靠传输 网络层 寻址&路由 数据链路层 链路之间的通信 物理层 01和电压高低转换

如何排查网络问题

ping 看是否可以ping通 nslookup 获取域名对应的IP traceroute 来看请求到达经历了多少跳路由 出现***说明有问题 telnet 检查端口是否出现开放 netstat 检查本地端口是否开启 iptables 查看防火墙 iftop 查看网络流量ip维度 tcpdump 抓包工具

DNS 13个根服务器 所有一级 跟服务器 -》一级 -》 二级-》 。。。。。-》本地服务器 本地如果没有直接到根服务器查询

tcp 3,4手

msl 最大生存时间

ACK 确认 SYN 同步序号 FIN 终结 seq 序号

三次握手

第一次:建立连接,客户端发送SYN seq=x 客户端进入SYN_SENT状态 第二次:服务端接收到后,返回 seq=y ack=x+1 服务端进入SYN_RECV状态 第三次:客户端回复,ack=1 连接建立完成 客户端进入ESTABLISHED 服务端接收到ack之后进入ESTABLISHED

为什么三次握手

为了防止某个SYN包在某个网络节点长时间的滞留之后又到达接收端 此时如果只是两次,接收端收到SYN之后就返回ack,建立连接但是事实上发送端并没有建立连接,白白浪费了接收端的资源

四次分手

第一次:一端向另一端发送FIN seq=x 进入FIN_WAIT_1 第二次:另一端回复ack=x+1 进入CLOSE_WAIT 第三次:另一端发送FIN seq=y 进入FIN_WAIT_2 第四次:一端接收到之后返回ack=y+1 进入TIME_WAIT 另一端收到ack报文之后就关闭连接

为什么四次分手

因为一方发送FIN表明的是这一方已经没有数据需要传输了,而另一方收到之后会立马回复一个ack 但是另一方可能还有数据要发送,所以这个时候连接还不能断开,只有等到两方都没有数据要发送之后,才可以断开连接 CLOSE_WAIT的意思是,我已经知道对方要断开连接了,我要做的就是看我自己是否还存在数据未发送 通俗讲tcp三四

为什么time_wait时两倍的msl 1.让之前的包失效 2.及时接收到FIN

mss 最大包长度

华东窗口 拥塞窗口

tcp 为什么可靠

tcp状态图

负载均衡 四层和七层

四层 ip+端口 是在ip加端口层次做负载均衡 负载均衡相当于是路由器,根据规则将ip+端口的包根据NAT协议分发给后端机器,tcp的握手是原机器和目标机器直接握手 七层 虚拟url或者主机ip等 在url或者主机ip上坐负载均衡 需要负载均衡机器首先和客户端建立tcp连接,然后和后端机器家里连接,将请求转发 对机器要求较高

|          | 四层负载均衡(layer 4 | 七层负载均衡(layer 7                          |
+----------+-------------------------+--------------------------------------------------+
| 基于     | 基于IP+Port的           | 基于虚拟的URL或主机IP等                        |
+----------+-------------------------+--------------------------------------------------+
| 类似于   | 路由器                  | 代理服务器                                       |
+----------+-------------------------+--------------------------------------------------+
| 握手次数 | 1                     | 2                                              |
+----------+-------------------------+--------------------------------------------------+
| 复杂度   |                       |                                                |
+----------+-------------------------+--------------------------------------------------+
| 性能     | 高;无需解析内容        | 中;需要算法识别 URLCookie  HTTP head 等信息 |
+----------+-------------------------+--------------------------------------------------+
| 安全性   | 低,无法识别 DDoS等攻击 | 高, 可以防御SYN cookie以SYN flood等             |
+----------+-------------------------+--------------------------------------------------+
| 额外功能 |                       | 会话保持,图片压缩,防盗链等                     |

NAT

一个网络存在一个公网地址,网络内的内网主机访问外网时,会在NAT网管转换源地址为公网地址,并记录,返回值根据这条记录返回到之前的主句 当多个内网主句同时访问外网机器,会分配不同的端口,来区分不同的返回结果

tcp拥塞控制 慢启动 快启动

tcp的拥塞控制是由拥塞窗口和慢启动来实现的, 拥塞窗口就是发送端每次会发送窗口的大小,实际发送为min(拥塞窗口,接收端窗口) 首先在建立连接之后,发送端会一1MSS的大小发送包,并且每收到一个ack时窗口加一,这样会以指数增长 当第一次发生超时重传时,会设置拥塞窗口阈值为当时窗口的一半,并且从1MSS开始发送 当发生快速重传时,由于其发生时网络情况较超时重传时较轻,会设置阈值为一半并且窗口为一半+3 当窗口超过阈值时,收到一个ack会按照一个窗口的字节数/拥塞窗口的字节数的比例增加窗口 这样看来其实拥塞窗口看起来像是在逐步侵占网络

tcp通过什么保持可靠

seq 每次连接建立时会随机生成一个seq原始值,并在握手时互相通知,以后每次都会根据包的大小累加 防止上一个连接的包干扰本次连接 ack 收到确认,并且回把确认收到的seq返回 超时重传,如果超过超时重传事件没有收到ack则重发 快速重传,三次收到相同的seq值得ack,说明某个包丢失,则重传seq之后的包

tcp如何提速

按照窗口发送,并不需要等待上一个包收到ack后才发下一个 延时确认,等待窗口缓冲区被消费,返回更大的窗口大小 捎带应答,将应用的应打包和ack何为一个包发送

mysql

myisam和innodb的区别

myisam 不支持事务,行级锁,索引为聚簇索引 innodb 支持事务,行级锁,索引为聚簇索引

隔离级别

uncommited read 未提交读,可能导致脏读,不可重复读,幻读 commited read 提交读,可能导致不可重复读,幻读 repetable read 可重复读,可能导致幻读 serialize 最安全,并发较低

事务实现

mysql默认实现了不可重复读隔离级别的事务, 借助undo log实现了MVCC,来实现可重复读 每个事务开始之前会分配一个commitID,快照读ID之前的数据,update 新插入一条为本ID的数据,delete 标记本ID删除,insert 本ID 同时借助next-key锁解决了幻读的问题,幻读其实是对于insert来说的,next-key锁会在间隙加上锁,并在之前加上gap锁,有时会退化为行锁(唯一索引)

索引实现细节

innodb采用B+树组织索引,B+树特点属于平衡树的一种,当数据量很大时也能保持比较低的树高保证查询速度(每次查询一个io) 每个非节点只存储关键字,并不存储数据内容,使得每个飞叶子节点能存储更多的关键词 主键索引的叶子节点存储数据行,因此叫做聚簇索引 辅助索引的叶子节点存储主键iD,因此每次查询会先查询副主索引得到主键ID再去查询朱建索引

为什么使用B+树

B+树属于平衡二叉树,左右节点树高不能相差大于1,当数据量较大时也能通过横向扩展保持较低的树高 b+树非叶子节点不保存数据行,每个叶子节点可以存储更多的关键字 叶子节点存储数据行,并且叶子节点之间互相连接,便于范围查找

树高为什么这么高

innodb中一页的大小为16k,如果主键索引为bigint(8byte),同时一个指针为6byte,则一个飞叶子节点可以存储大约16k/14=1170个关键字,叶子节点假设一行1k,则一个叶子节点保存16个,三层1170117016=2千万

binlog

mysql层次,记录每次对数据的改动, 记录修改的sql 记录数据行被修改后 混合模式,如一些函数修改,无法完成中从同步,则直接记录被修改后的记录 主要实现主从同步和回滚

redo log

innodb内部实现持久化的日志 分为两种,一种是redolog缓冲区内的(易失),一种是redolog文件中的(不易失) 记录每一页的变动,采取force log bofore commit机制保证事务的持久化 每次事务提交后,写入redolog缓冲区,通过策略sync到磁盘 mysql重新启动时,都会重做redolog,根据checkpoint来恢复磁盘数据

undolog

innodb内部实现MVCC和事务回滚的日志 undolog同时会产生对应的redolog 记录每一行的变动

主从延迟的原因

通过binlog进行主从同步,binglog顺序写入性能较高,slave主从复制线程从master拉取binlog也比较快 slave的slave_IO_Runing线程从binlog中读取日志执行也比较快 slave_io_running线程为单线程处理ddl和dml,同时可能与query产生锁争夺,所以同步会存在延迟 主库的插入可以并发,并且一般主库不query减少了锁争夺

联合索引

联合索引的每个飞叶子节点,保存着所有联合索引的字段的关键字 最左前缀原则 联合索引的前一个字段如果使用><或者函数,则后面的索引不会用到

各种innoDBcahche buffer pool

innodb的插入缓冲中的页包含数据页,索引页,插入缓冲页,锁信息,自适应哈希索引页等 缓冲池中的页采用lru算法来进行管理,lru_list和free_list

锁 分库分表分片

redis

zset 类型&实现 hash lru:redis的实现,应用 事件机制,单线程高性能 集群实现,一致性hash,分布式事务,一致性 raft算法 内存淘汰 过期key 主从同步 持久化 pipline redis事务实现 主从同步 psync和fsync

算法

hash简单实现 list array tree 二叉树 侧边看过去 动态规划 最大面积 树的蛇形遍历 lfu,leu hashmap(增删改查) 单列表排序 八皇后 字符串匹配

设计题

微服务%