流水线（pipelined）
批量提交redis命令，减少通信次数
事务
- mulit，事务的开始
- exec，执行事务快内的命令
- discard，放弃事务快内的命令
- watch，监视key，如果key改动则中断事务,CAS乐观锁
- unwatch,取消监视key
分布式锁机制
- 随着负载增加，失败重试次数也增加
- 为代表锁的key生成值，来获取锁
- setnx命令，当key不存在时为key设置value(set not exist)
- 设置expire过期时间，防止挂掉的进程一直持有锁，形成死锁
- 删除锁时需要先获取，再判断，最后删除，存在类似i++的原子性问题，可以使用lua脚本把一组命令当成一个原子语句来执行
分布式锁高并发优化
对同一个商品id的key进行锁请求，会进行串行化处理。类似于ConcurrentHashMap的锁分段原理，把库存分段，比如0-100，100-200，对应的key为id_100,id_200，把对一个key的锁请求变成分段的锁请求。
publish和subscribe替代方案，解决连接断开失败的问题
生产者把消息发送到消费者的消息列表里
发布消息，更新到follower的timeline中
类似twitter的网红账号，有几千万粉丝，比如前1000的粉丝直接添加。超过数量的通过消息队列延迟处理
ziplist压缩列表
当整数集合在设置的限制条件内时，底层会使用ziplist压缩列表
主要包括list-max-ziplist-entires（最大元素数量）和list-max-ziplist-value（每个节点最大体积）
分片和哨兵机制
一般使用hash一致性算法获取取模，根据key值计算出属于哪一个节点上
一般是奇数台哨兵，哨兵会向主机发送心跳检测。如果长时间没回应，认为主机死亡，选举出新的master
配置只读服务器（拓展读性能）
slaveof host post
在多个服务器尝试与主服务器进行连接时，在主节点创建快照完成之前，子节点都会受到同一份快照。但是过多的快照副本可能会耗尽主节点资源，可以采树状的结构，将一级子节点作为二级子节点的主节点。
预先分片（拓展写性能）
在单机上运行多个实例，监听不同端口
应用和redis隔离部署
应用可能瞬间抢占了全部的CPU资源，导致redis没有资源超时，而应用如果刚好需要连接redis，会产生类似的死锁
redis和db的数据一致性
- 一般情况下，更新数据时先删除缓存再更新db，等读时再将db查询结果更新到缓存
- 高并发下，可能在更新db前就有新的读请求，这时缓存失效于是去db查旧数据又更新到缓存。解决方案是使用任务队列，把更新操作加入到队列中，当有读请求时，先看是否有更新请求
- 延时双删 ，在更新完db后，休眠比读请求耗时多几百ms的时间，再次删除缓存，消除高并发下读请求造成的脏数据
- 对key加分布式锁
db更新缓存失败
- 通过循环操作固定次数，减少网络瞬时抖动造成的影响
- 还是失败的话，添加任务到mq中，通知更新失败，让消费mq队列去更新缓存
热点数据防止缓存穿透和雪崩（利用分布式锁）
查询到缓存中key不存在，使用分布式锁，防止多个线程读同一个key请求多次db。在查询db前再判断一次缓存中key是否存在，如果别的线程已经将db更新到缓存中，则不允许再读db。
限制锁的数量，比如固定1000个，根据id的hashcode对1000取模，使得同时最多只有1000个并发，其他线程没有锁阻塞，延迟竞争锁。