Redis学习笔记

一、redis痛点

• 压力 内存不够用或者磁盘不够用。
• 单点 可用性无法保证。
• 主从同步中一致性问题。 

二、Redis的事务

　　redis事务很事务：事务提交前和事务提交后，事务提交前检查指令的语法才会提交，如果一旦提交了全部执行，即便其中有报错，也要全部执行，不会回滚。

　　如下图：

　　　　multi开启事务

　　　　执行set a ooxx 回车

　　　　lpop a 回车，exec提交事务

　　都会执行，会报错，但不会回滚。　

　　

 

三、请求到redis服务端的流程

1. 指令set a ooxx 先到内核，内核会有一个socket来接收请求。
2. 每个客户端都有有一个socket，请求会放到缓冲区，queue表示有序的。
3. redis会监听这些socket。
4. 监听采用的IO模型是多路复用器。
5. 收到指令请求后，要将指令通过IO读取到redis服务端。
6. 所有客户端的指令请求都读取到redis服务端。
7. 多个客户端的指令请求不能保证先到先执行，但同一客户端多个指令请求是可以保证的。

四、redis实现强一致性方法？

1. 通过配置文件设置同步数量，1秒。
2. wait方法。

　　注：强一致性会破坏可用性。同步数量应该小于节点数据，应对集群数量变化。

 

五、CAP理论

　　P是必然的，一定是多台机器才会有CAP理论。P出现原因可能是网络中断、OS压力比较大。

 

六、redis集群问题

1. 在使用redis分布式锁和重复锁时，如果redis的主从主备集群会出现获取到锁了，但是主节点挂了，导致其它线程也可以获取到锁， 解决方法是不使用集群。

2. 持久化数据无作用，因为如果主节点挂掉，哨兵会选择一个从节点当主节点，当主节点重启后，会清空自己的缓存，全量同步新主节点数据。
3. 主从同步时，当主节点挂掉时，哨兵会去验证主节点是否真的挂掉了，这时如果运维设置的自动重启，那么可能导致哨兵验证结果是主节点没有挂掉，但是主节点没有设置持久化数据，从而导致主节点上的缓存都丢失，也会同步给从节点，导致从节点数据也会丢失。

七、redis集群底层实现

• 计算向数据移动。
• 计算key得出存放节点。
• 为了应对节点数量变化，使用映射来划分槽。
• redis共有16384个槽。 

注：这些是自己学习的笔记，如有不准确，欢迎指出！