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