- 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请求、响应、渲染、连接结束
