- Redis的RDB和AOF
- RDB是定时备份会定时fork一个子进程备份这段时间的数据,生成一个二进制的rdb文件
- AOF会记录所有的写操作记录到appendonly上保证数据的一致性
- 但是rdb会越来越大,大到一定程度会影响性能,rdb还会有一定程度的数据丢失
- AOF会进行一个数据整合的操作,不过AOF是一个同步的操作,对性能会有影响
- redis的哨兵机制,哨兵进程会定期检测master服务是否正常运行,挂了会通过选主方式
- 集群的脑裂问题:也是区块链中的双花攻击问题?
- redis的配置文件有两个参数:最少slave数量和连接master的最大延迟数,延时超过多少秒会拒绝写请求,如果发生了脑裂会拒绝写请求可以减少数据丢失的问题
- redis是怎么保证数据的同步和初始化的?
从服务发送一个sync同步命令给主服务器要求全量同步
主服务器接收到sync的同步命令会fork一个子进程后台执行bgsave命令(非阻塞)快照保存生成RDB文件,并将RDB文件发送给从服务
从服务再将RDB载入自己的redis内存
待从服务将RDB载入完成后,主服务将缓冲区的所有写命令发送给从服务
从服务再将主服务所有写命令载入内存实现数据的完整同步
从服务下次再需要同步数据时只需要发送自己的offset位置相当于(mysql的 binlog位置),只同步更新的数据而不需要全量同步
- 双写一致性问题:先删除缓存再更新数据库然后再重新加载到缓存。不论哪一步失败都可以保证数据的一致性。
- redis的QPS:10w/s
- redis的缓存击穿和缓存穿透:缓存穿透是没走缓存请求直接到了数据库,缓存击穿是有个热点key过期后请求会直接到数据库
- 解决方案:设置key永不过期,集群化部署保证不同的过期时间,加上互斥锁。布隆过滤器
- redis的分布式锁:setnx (set if not exits)
- Python的线程安全问题:
- 数据库的MVCC
- 重复消费问题:设置成幂等操作比如+1应该先加1算出值之后将其设置成1,多次操作和一次操作返回的结果是一样的
- 应用层、表示层
- 会话层:SSL、TLS、rpc
- 传输层:tcp
- 网络层:ip
- 数据链路层:arp
- syn,ack+syn,ack,seq:顺序的
- 最后进入established:已确认状态
- 为什么要三次握手才能建立起连接?
为了初始化seq number初始值作为以后通信的序号,确保应用层收到的数据不会因为网络上的传输问题而乱序,tcp会用这个seq来拼接数据
三次握手已经可以确定连接的可靠性
- 有个SYN攻击一直不发数据浪费服务器资源:通过syn cookie,如果syn队列满了之后通过cookie机制
- syn_sent、syn_rcvd
- fin_wait、close_wait、time_wait、closed
- 为什么会有time_wait状态:确保有足够的时间让对方接收到ack包,如果没有收到就会重发
- 避免新旧连接混淆
- fin ack报文
- udp的特点:非连接、数据包报头只有8个字节额外的开销小
- UDP支持一对一,一对多,多对多的通信模式
- tcp是面向字节流的,udp是面向报文的
- tcp有拥塞控制,udp没有适合通信媒体
- tcp首部20个字节,udp8个
- 拥塞控制的方式:
慢启动:不要一上来就发送大量的数据
快重传
快恢复:乘法减小算法
- TCP的重传机制
- TCP的滑动窗口:用来做流量控制不是拥塞控制,控制的是接受端而不是发送端
- HTTP无连接无状态
- TLS、SSL安全套接字SSL之后是TLS采用身份验证和数字加密保证数据的完整性
- 经典的输入url发生了什么?
DNS解析、TCP连接、HTTP请求、响应、渲染、连接结束