做模板网站,泉州app开发,网站开发 保证书,网站赏析计算机网络知识汇总补充 一、四次挥手1、为什么TCP要等待2MSL2、如果说一个系统中#xff0c;有大量的time_wait和close_wait#xff0c;会是什么原因#xff1f; 二、你是怎么解决粘包问题#xff1f;三、你觉得哪些场景适合redis四、redis的持久化策略五、你会怎么保证my… 计算机网络知识汇总补充 一、四次挥手1、为什么TCP要等待2MSL2、如果说一个系统中有大量的time_wait和close_wait会是什么原因 二、你是怎么解决粘包问题三、你觉得哪些场景适合redis四、redis的持久化策略五、你会怎么保证mysql 和Redis的一致性六、事务隔离级别和MVCC控制的理解七、对称加密非对称加密八、堆和栈的不同九、如果A服务调B服务出现失败下游服务调用失败或者无法响应请求了怎么优化十、redo log,bin log, undo log 一、四次挥手 1、刚开始客户端和服务端都处于连接状态假如客户端发起关闭请求 2、第一次挥手客户端向服务器发送FIN报文发完进入FIN_WAIT_1状态即主动关闭TCP连接不再发送数据但是可以接收服务器发来的报文等待服务器回复。 3、第二次挥手服务器接到FIN报文返回一个ACK报文表名自己接收到此报文服务器进入CLOSE_WAIT等待关闭状态此时客户端就知道服务端接收到自己的断开连接的请求进入FIN_WAIT_2状态TCP处于半关闭状态但是服务器可能还有数据要传输。 4、第三次挥手服务器关闭客户端连接发送FIN报文给客户端数据传输完毕等待客户端回应。 5、第四次握手客户端收到FIN报文后发送一个ACK给服务端做为应答此时客户端处于TIME_WAIT状态这个状态是为了等待足够的时间以确保TCP接收到连接中断请求的确认。
1、为什么TCP要等待2MSL
注意这时服务器到客户端的TCP连接并未被释放客户端需要经过等待2MSLMSL表示一个报文的来回时间后才会进入CLOSED状态这样做的目的是确保服务器收到自己的ACK报文如果在规定时间没有收到客户端发的ACK那么服务器会重发FIN客户端再次收到FIN报文就知道自己的ACK丢了然后会重发ACK给服务器。服务器收到ACK后就会关闭连接处于CLOSE状态了。
2、如果说一个系统中有大量的time_wait和close_wait会是什么原因
未正确关闭连接 处理连接过程中出错 网络延迟或故障
二、你是怎么解决粘包问题
1、粘包定义粘包指的是数据和数据之间没有明确的分界线导致不能正确读取数据。 2、这意味着UDP根本不会粘包但是会丢数据不可靠。意味着: TCP传输数据是可靠的但是会粘包。 所谓粘包问题主要还是因为: 1、接收方不知道消息之间的界限不知道一个消息要提取多少字节的数据所造成的。 (服务器端出现黏包) 2、tcp在发送数据少且间隔时间短的数据时会将几条和并一起发送。(客户端出现黏包) 3、黏包的解决办法 为字节流加上一个报头,告诉发送的字节流总大小然后接收端来一个死循环接收完所有数据。用struck将序列化后的数据长度打包成4个字节(4个字节完全够用)。 客户端把数据长度封装成一个固定大小的数据 这时服务端就可以指定读取固定大小的内容,不会读取数据的内容服务端只要根据数据长度再来接收数据内容就好了所以客户端连续两次发数据(文件) , 不会粘包,因为服务器端每次接收都只接收了本次该接收的数据。
4.你使用TCP的时候会出现那么UDP会出现吗
- 不会出现三、你觉得哪些场景适合redis
String字符串缓存、计数器限流Hash哈希存储对象数据、统计类数据List列表文章列表Set无序集合标签、点赞、签单Zset有序集合排行榜
redis你使用的场景 string异步执行任务消息队列
四、redis的持久化策略 RDB持久化RDB持久化会在指定的时间间隔内生成一个快照文件Snapshot将数据集的内容写入一个压缩的二进制文件中。RDB持久化方式适合数据集较大但不要求数据丢失太多的场景。可以通过配置文件设置快照生成的条件和时间间隔。 AOF持久化AOF持久化是以日志的方式记录每个写操作的命令在Redis重启时重新执行这些命令来恢复数据。AOF持久化方式保证了每个写操作的数据一致性和持久性但相比RDB会更占用磁盘空间和对性能有一定影响。
五、你会怎么保证mysql 和Redis的一致性
淘汰缓存在更新 MySQL 数据后异步地更新 Redis 中的数据。这种方式可以降低对数据库写入性能的影响但可能会导致短暂的数据不一致。更新缓冲在系统中同时写入 MySQL 和 Redis确保两者的数据保持一致。这种方式可以保证每次写入操作都同时更新 MySQL 和 Redis但会增加系统的写入负载。消息队列使用消息队列来实现 MySQL 和 Redis 数据的同步。在数据库更新后发送消息到队列消费者将消息同步到 Redis 中确保数据的一致性。监控和报警实时监控 MySQL 和 Redis 的数据一致性一旦发现数据不一致情况及时进行报警并修复。
六、事务隔离级别和MVCC控制的理解 用于处理并发事务的一致性和隔离性 MVCC是一种并发控制机制常用于数据库管理系统中用于解决并发访问数据库时的数据一致性问题。MVCC通过在每个数据项上维护多个版本来实现并发控制。 MVCC的核心思想是在读操作和写操作之间创建一个快照使得读操作不会被写操作所阻塞从而提高并发性能。具体实现方式如下 版本号每个数据项都会有一个版本号用于标识该数据项的版本。当一个事务开始时它会获得一个全局的事务ID并将该ID作为版本号。 读操作当一个事务执行读操作时它会读取最新的符合条件的版本。如果存在比当前事务ID更大的版本号则说明该数据项已被其他事务修改当前事务需要等待。 写操作当一个事务执行写操作时它会创建一个新的版本并将新版本的数据写入数据库。同时该事务会更新所有已读取该数据项的事务的版本号使得它们无法再读取旧版本。 回滚如果一个事务执行过程中发生了错误或者被取消它可以通过回滚操作将数据库恢复到事务开始之前的状态。回滚操作会撤销该事务对数据库的所有修改。 MVCC的优点是提高了并发性能和并发控制的粒度减少了锁的使用从而减少了事务之间的冲突。但也存在一些缺点如增加了存储空间的开销和读操作的复杂性。
七、对称加密非对称加密
对称加密
对称加密使用相同的密钥称为私钥来加密和解密数据。加密和解密过程使用同一个密钥因此对称加密算法在加密和解密速度上通常比较快。常见的对称加密算法包括AES高级加密标准等。
非对称加密
非对称加密使用一对密钥公钥和私钥来加密和解密数据。公钥用于加密数据私钥用于解密数据这两个密钥是相关联的但不相同。非对称加密算法能够实现数据的安全传输和身份认证但由于涉及复杂的数学运算其加密和解密速度较慢。常见的非对称加密算法包括 RSA等。
八、堆和栈的不同 九、如果A服务调B服务出现失败下游服务调用失败或者无法响应请求了怎么优化 实现重试机制 在A服务发现调用B服务失败时可以实现简单的重试机制尝试重新调用B服务一定次数以确保请求能够成功响应。重试机制可以设置一定的重试间隔和次数避免过多的请求导致负担增加。 实现服务降级 当B服务无法响应或出现异常时A服务可以实现服务降级策略返回默认值或者缓存数据保证用户体验。服务降级可以在一定程度上减少对下游服务的依赖提高系统的可用性。 设置超时时间 为A服务调用B服务设置合理的超时时间以避免长时间等待响应导致的性能问题。当超过设定的超时时间后可以及时进行异常处理或重试操作。
十、redo log,bin log, undo log
binlog主节点 binlog主从复制的基础是主库记录数据库的所有变更记录到 binlog。binlog是数据库服务器启动的那一刻起保存所有修改数据库结构或内容的一个文件。undo log记录事务提交前的状态更新前的值用于事务回滚redo log记录事务提交后的状态更新后的值用于数据恢复持久化
