Redis---- 小结（原创笔记）

正确使用redis

client-server通信模式，完全基于内存（内存不会成为瓶颈）；
数据结构简单；
多路I/O复用模型，避免上下文交换（利用select、poll、epoll可以同时监察多个流的 I/O 事件的能力，描述了用户态和内核态）；
多个 socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO多路复用程序会监听多个 socket，会将产生事件的 socket 放入队列中排队，事件分派器每次从队列中取出一个 socket，根据 socket 的事件类型交给对应的事件处理器进行处理

elect/epoll的优势并不是对于单个连接能处理得更快，而是在于能处理更多的连接。所以，如果处理的连接数不是很高的话，使用select/epoll的web server不一定比使用多线程 + 阻塞 IO的web server性能更好，可能延迟还更大。

Pub/Sub 发布订阅

解耦发布者和订阅者，不关心是否有订阅者

管道 Pipelining（客户端一次可发送多个命令）

必须等本次Pipe返回才能继续写，基于此，其本质是要减少网络延迟问题（减少 RTT： round trip time）
举例：若 RTT为250ms，即使服务器1s能处理10w个请求，那么每秒最多处理 4 个请求。
尽量创造本机网络（减小RTT，本机网络小于 1ms）
pipelining VS Scripting （client支持发送请求后不必等server响应返回，就继续发送下个请求，然后一次性收到返回）

复制机制（异步非阻塞）

1）slave 为master的副本，基于命令流的同步。
2）哨兵模式问题：本质是主从切换技术。
master自动重启足够快时，sentinel无法探测到，重启后的master将从空数据集开始复制，若slaver试图从master复制，则slaver被清空问题。（此针对关闭持久化，且允许重启进程的设置）
3) 集群模式

持久化

1）RDB 数据快照存储（二进制），Redis数据的紧凑文件，适合用于备份。
AOF 记录写操作，启动快。对同样的数据集，AOF文件通常要大于等价的RDB文件。
so，不建议单独使用aof，可以两种模式一起使用。
2）同步时钟问题：归根结底是数据一致性的问题，可由cap理论引申到base理论；

不稳定性

基于redis用于分布式锁场景。
分布式锁的基本要求：
1）安全性：即互斥，任意时刻最多1个客户端持有；
2）活性 ：无死锁，即使客户端崩溃或者网络分区时；
3）容错：锁可释放，不可重复获取；
举例：C1----master 获取锁， master宕机前同步了该锁到slaver，此slaver变为master，C2从新master获取锁
分布式锁原则：安全，代价小。
尽量key失效时间+客户端Id
事务、存储
解决方式： 延迟重启、时间漂移问题（每台实例时间差）