redis优化方案

流水线（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个并发，其他线程没有锁阻塞，延迟竞争锁。