为什么引入缓存
- 高性能
sql语句查询600ms，缓存查询2ms，查询速度提高300倍。
- 高并发
mysql这么重的数据库，压根儿设计不是让你玩儿高并发的，虽然也可以玩儿，但是天然支持不好。mysql单机支撑到2000qps也开始容易报警了。所以要是你有个系统，高峰期一秒钟过来的请求有1万，那一个mysql单机绝对会死掉。你这个时候就只能上缓存，把很多数据放缓存，别放mysql。缓存功能简单，说白了就是key-value式操作，单机支撑的并发量轻松一秒几万十几万，支撑高并发so easy。单机承载并发量是mysql单机的几十倍。
redis分布式缓存原理
高性能
- 纯内存操作
- 单线程避免上下文切换
- 数据结构优化
- NIO线程模型（多路复用）
高并发
Redis 读并发 110000 次 /s, 写并发 81000 次 /s 。
读写分离
如果redis要支撑超过10万+的读并发，那应该怎么做？
单机的redis几乎不太可能说QPS超过10万+，除非一些特殊情况，比如你的机器性能特别好，配置特别高，物理机，维护做的特别好，而且你的整体的操作不是太复杂。
读写分离，一般来说，对缓存，一般都是用来支撑读高并发的，写的请求是比较少的，可能写并发也就一秒钟几千。
大量的请求都是读，假设一秒钟二十万次读，单机redis肯定撑不住这个并发，我们可以采用读写分离的技术方案去解决：
主从架构，即一主带多从的架构。主服务器只负责应对写入并发，然后将数据同步到从服务器，从服务器只负责读取并发。由于follower的数据是master的全映像，因此可以通过follow-slave的横向扩容很容易的增加读并发能力。
数据分片
当缓存的写入并发越来越大，单机master的架构就会成为瓶颈。这时我们仍然可以借鉴分布式DB的思路，通过数据分片来降低master单机的写并发。实现架构：
主从模式组 + 多个组集群。其中每一个组相当于一套主从结构的系统。多个组间存储不同数据分片，共同构成集群。
数据分片架构下需要考虑key的映射，集群的扩容缩容以及服务器状态管理等问题，这些功能目前已经有相应的框架实现，不需要过分侵入业务开发工程师的精力。目前实现数据分片(集群)技术方案大致有三种：
- 客户端实现数据分片
即客户端自己计算数据的key应该在哪个机器上存储和查找，此方法的好处是降低了服务器集群的复杂度，客户端实现数据分片时，服务器是独立的，服务器之前没有任何关联。多数redis客户端库实现了此功能，也叫sharding，这种方式的缺点是客户端需要实时知道当前集群节点的联系信息，同时，当添加一个新的节点时，客户端要支持动态sharding，多数客户端实现不支持此功能，需要重启redis。另一个弊端是redis的HA需要额外考虑。
- 服务器实现数据分片
客户端随意与集群中的任何节点通信，服务器端负责计算某个key在哪个机器上。当客户端访问某台机器时，服务器计算对应的key应该存储在哪个机器，然后把结果返回给客户端。客户端再去对应的节点操作key，是一个重定向的过程，此方式是redis3.0正在实现，Redis 3.0的集群同时支持HA功能，某个master节点挂了后，其slave会自动接管。
- 通过代理服务器实现数据分片
此方式是借助一个代理服务器实现数据分片，客户端直接与proxy联系，proxy计算集群节点信息，并把请求发送到对应的集群节点。降低了客户端的复杂度，需要proxy收集集群节点信息。Twemproxy是twitter开源的，实现这一功能的proxy。这个实现方式在客户端和服务器之间加了一个proxy，但这是在redis 3.0稳定版本出来之前官方推荐的方式。结合redis-sentinel的HA方案，是个不错的组合。
高可用
Redis的几种常见架构方案包括以下几种，需要根据不同的业务实际做选择：
• Redis单副本；
• Redis多副本（主从）；
Redis Sentinel（哨兵）；
Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案。实际上这意味着你可以使用Sentinel模式创建一个可以不用人为干预而应对各种故障的Redis部署。
Sentinel（哨兵）的主要功能有以下几点：
- 监控：Sentinel不断的检查master和slave是否正常的运行。
- 通知：如果发现某个redis节点运行出现问题，可以通过API通知系统管理员和其他的应用程序。
- 自动故障转移：能够进行自动切换。当一个master节点不可用时，能够选举出master的多个slave中的一个来作为新的master，其它的slave节点会将它所追随的master的地址改为被提升为master的slave的新地址。
- 配置提供者：哨兵作为Redis客户端发现的权威来源。客户端连接到哨兵请求当前可靠的master的地址。如果发生故障，哨兵将报告新地址。
sentinel的分布式特性：
很显然，只使用单个sentinel进程来监控redis集群是不可靠的，当sentinel进程宕掉后(sentinel本身也有单点问题，single-point-of-failure)整个集群系统将无法按照预期的方式运行。所以有必要将sentinel集群，这样有几个好处：
- 即使有一些sentinel进程宕掉了，依然可以进行redis集群的主备切换；
- 如果只有一个sentinel进程，如果这个进程运行出错，或者是网络堵塞，那么将无法实现redis集群的主备切换（单点问题）;
- 如果有多个sentinel，redis的客户端可以随意地连接任意一个sentinel来获得关于redis集群中的信息。
参考：
Redis Cluster
hash slot算法
redis cluster有固定的16384个hash slot，对每个key计算CRC16值，然后对16384取模，可以获取key对应的hash slot
redis cluster中每个master都会持有部分slot，比如有3个master，那么可能每个master持有5000多个hash slot
hash slot让node的增加和移除很简单，增加一个master，就将其他master的hash slot移动部分过去，减少一个master，就将它的hash slot移动到其他master上去。
移动hash slot的成本是非常低的。
Redis Cluster是一个高性能高可用的分布式系统。由多个Redis实例组成的整体，数据按照Slot存储分布在多个Redis实例上，通过Gossip协议来进行节点之间通信。
Redis Cluster功能特点如下：
1)所有的节点相互连接
2)集群消息通信通过集群总线通信，，集群总线端口大小为客户端服务端口+10000，这个10000是固定值
3)节点与节点之间通过二进制协议进行通信
4)客户端和集群节点之间通信和通常一样，通过文本协议进行
5)集群节点不会代理查询
6)数据按照Slot存储分布在多个Redis实例上
7)集群节点挂掉会自动故障转移
8)可以相对平滑扩/缩容节点
- 节点间的内部通信机制
redis cluster节点间采取gossip协议进行通信。跟集中式不同，不是将集群元数据（节点信息，故障等等）集中存储在某个节点上（比如哨兵节点上），而是互相之间不断通信，保持整个集群所有节点的数据是完整的。
集中式：好处在于，元数据的更新和读取，时效性非常好，一旦元数据出现了变更，立即就更新到集中式的存储中，其他节点读取的时候立即就可以感知到;。不好在于，所有的元数据的跟新压力全部集中在一个地方，可能会导致元数据的存储有压力。
gossip：好处在于，元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力；缺点，元数据更新有延时，可能导致集群的一些操作会有一些滞后。
对于gossip通信方式，可能有些同学会考虑网状结构通信的问题。考虑到以下实际情况：一是节点相对较少，二是元数据信息更新频率较低。所以，在这个背景下采用gossip通信方式是合理的。
参考：developer.aliyun.com/article/626…
缓存架构业务场景分析
当我们考虑是否采用缓存架构作为技术方案，需要考虑以下几个问题：
- 项目的读写操作比例为多少，如果是写多读少，那缓存真的不一定能帮助你，此时不妨考虑数据库分库分表，然后做MySQL的分布式集群，或者简单直接，将硬盘全部替换为SSD(如果你的公司财大气粗)，反之，以读为主的项目就比较适合加缓存了。
- 项目的访问频率高不高（用户多不多）？如果用户区区几千人或几万人，全然没有必要使用缓存，这点访问量经过网络后几乎不会造成并发，即使偶出现几万的并发，MySQL也是扛得住的，强行使用缓存反而会增加代码复杂度，甚至不容易维护，得不偿失。
- 数据是否要求强一致性？如果项目涉及到金钱或者重要数据，且数据频繁发生变化，不允许存在一点差异，那是否使用缓存就要慎重慎重再慎重！因为缓存适用的是对数据一致性不是特别高的项目，如果使用，需要对缓存的设计有很好的方案，非常考验技术功底。
如果最后决定使用缓存方案，则需要根据实际业务场景进行缓存架构设计。是采用单副本架构，还是主从架构或者分片架构？需要根据业务的读写特征来看，一般的：
- 当业务读写并发量都较小时，单副本架构完全可以满足未来业务发展，就不需要考虑读写分离和数据分片方案给架构带来不必要的复杂性。
- 当写并发较小，且评估单副本无法承载读并发的场景，可以考虑读写分离的主从架构方案。
- 如果随着业务的不断发展，写并发逐渐增大，master压力较大，则可以考虑做主从+分片的架构方案。
参考：www.cnblogs.com/wangbaojun/…
常见缓存问题
缓存雪崩
缓存雪崩是指缓存中数据大批量到过期时间（比如缓存服务器宕机，也算做缓存雪崩），而查询数据量巨大，引起数据库压力过大甚至宕机。和缓存击穿不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。
热点数据集中失效场景导致缓存雪崩场景
-
通常的解决办法是对不同的数据使用不同的失效时间，避免热点数据缓存集中失效。例如，我们要缓存user数据，会对每个用户的数据设置不同的缓存过期时间，可以定义一个基础时间，假设10秒，然后加上一个两秒以内的随机数，过期时间为10～12秒，就会避免缓存雪崩。
-
类似击穿的情形，也可以尝试以下方案。
-
在第一个请求去查询数据库的时候对他加一个互斥锁，其余的查询请求都会被阻塞住，直到锁被释放，从而保护数据库。但是也是由于它会阻塞其他的线程，此时系统吞吐量会下降。这种方案会导致日常业务并发出现负尖刺的情况，因此需要结合实际的业务去考虑是否要这么做。
-
定时主动刷新，避免缓存过期场景。
缓存服务不可用场景导致缓存雪崩场景
事前：
- 使用集群缓存，保证缓存服务的高可用
这种方案就是在发生雪崩前对缓存集群实现高可用，如果是使用 Redis，可以使用 主从+哨兵 ，Redis Cluster 来避免 Redis 全盘崩溃的情况。
事中：
- ehcache本地缓存 + Hystrix限流&降级,避免MySQL被打死
使用 ehcache 本地缓存的目的也是考虑在 Redis Cluster 完全不可用的时候，ehcache 本地缓存还能够支撑一阵。
使用 Hystrix进行限流 & 降级 ，比如一秒来了5000个请求，我们可以设置假设只能有一秒 2000个请求能通过这个组件，那么其他剩余的 3000 请求就会走限流逻辑。
然后去调用我们自己开发的降级组件（降级），比如设置的一些默认值呀之类的。以此来保护最后的 MySQL 不会被大量的请求给打死。
事后：
- 开启Redis持久化机制，尽快恢复缓存集群
一旦重启，就能从磁盘上自动加载数据恢复内存中的数据。
缓存击穿
缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。解决方案：
- 设置热点数据永远不过期，比如配置数据，但是可以主动刷新。比如clientQuoteDefinition表配置。
- 定时刷新。保证汇率不过期。
- 缓存预热。
- 加互斥锁。
上面的现象是多个线程同时去查询数据库的这条数据，那么我们可以在第一个查询数据的请求上使用一个 互斥锁来锁住它。
其他的线程走到这一步拿不到锁就等着，等第一个线程查询到了数据，然后做缓存。后面的线程进来发现已经有缓存了，就直接走缓存。
public String get(key) {
String value = redis.get(key);
if (value == null) { //代表缓存值过期
//设置3min的超时，防止del操作失败的时候，下次缓存过期一直不能load db
if (redis.setnx(key_mutex, 1, 3 * 60) == 1) { //代表设置成功
value = db.get(key);
redis.set(key, value, expire_secs);
redis.del(key_mutex);
} else { //这个时候代表同时候的其他线程已经load db并回设到缓存了，这时候重试获取缓存值即可
sleep(50);
get(key); //重试
}
} else {
return value;
}
}
缓存穿透
缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。解决方案：
- 接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截（业务约束校验）。
- 设置null值，并设定超时时间。从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击。针对攻击key值重复率过高的场景。
- bloomfilter，直接校验key值是否存在，针对攻击key值重复率低的场景。
缓存并发竞争
这里的并发指的是多个redis的client同时set key引起的并发问题。实际上，Redis是一种单线程机制的nosql数据库，基于key-value，数据可持久化落盘。由于单线程所以Redis本身并没有锁的概念，多个客户端连接并不存在竞争关系，但是利用jedis等客户端对Redis进行并发访问时会出现问题。
比如：同时有多个子系统去set一个key。这个时候要注意什么呢？举一个例子：
多客户端同时并发写一个key，一个key的值是1，本来按顺序修改为2,3,4，最后是4。但是因为网络原因，顺序变成了4,3,2，最后变成了2。再比如汇率更新场景。
- 分布式锁+时间戳
这种情况，主要是准备一个分布式锁，大家去抢锁，抢到锁就做set操作。加锁的目的实际上就是把并行读写改成串行读写的方式，从而来避免资源竞争。
当然，分布式锁可以基于很多种方式实现，比如zookeeper、redis等，不管哪种方式实现，基本原理是不变的：用一个状态值表示锁，对锁的占用和释放通过状态值来标识。
时间戳
由于上面举的例子，要求key的操作需要顺序执行，所以需要保存一个时间戳判断set顺序。
系统A key 1 {ValueA 7:00}
系统B key 1 { ValueB 7:05}
假设系统B先抢到锁，将key1设置为{ValueB 7:05}。接下来系统A抢到锁，发现自己的key1的时间戳早于缓存中的时间戳（7:00<7:05），那就不做set操作了。
- 消息队列
在并发量过大的情况下，可以通过消息中间件进行处理，把并行读写进行串行化。把Redis.set操作放在队列中使其串行化,必须的一个一个执行。这种方式在一些高并发的场景中算是一种通用的解决方案。
缓存与数据库双写不一致（缓存更新策略）
在读取缓存方面，一般按照下图的流程来进行业务操作。
但是在更新缓存方面，对于更新完数据库，是更新缓存呢，还是删除缓存。又或者是先删除缓存，再更新数据库。考虑到缓存和DB的数据一致性，目前还存在很大的争议。
在这里，我们讨论三种更新策略：
- 先更新数据库，再更新缓存
- 先删除缓存，再更新数据库
- 先更新数据库，再删除缓存
先更新数据库，再更新缓存
这套方案，大家是普遍反对的。为什么呢？
原因一（线程安全角度）
同时有请求A和请求B进行更新操作，那么会出现
（1）线程A更新了数据库
（2）线程B更新了数据库
（3）线程B更新了缓存
（4）线程A更新了缓存
这就出现请求A更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存。这就导致了脏数据，因此不考虑。
原因二（业务场景角度）
如果你是一个写数据库场景比较多，而读数据场景比较少的业务需求，采用这种方案就会导致，数据压根还没读到（由于主从同步延迟的原因），缓存就被更新，导致数据不一致的情况。
实际上，对于某些业务场景，也可以采用这个方案。比如外汇业务下某业务场景的汇率更新问题。对于某汇率数据库使用select for update控制单线程操作，并且数据库采用单体的架构方案。对于汇率缓存更新操作，使用先更新DB,再更新缓存的技术方案完全能够满足需求。从这里我们可以看到：
- 架构方案是死的，且任何一套方案都有其优点和缺点，但是业务场景和业务需求是多变得，架构师的选择也是灵活的，在做架构方案时，不要过于刻板。
- 没有任何架构方案能够做到百分百的高可用，最终都需要人工兜底。
接下来讨论的就是争议最大的，先删缓存，再更新数据库。还是先更新数据库，再删缓存的问题。
先删缓存，再更新数据库
该方案会导致不一致的原因是。同时有一个请求A进行更新操作，另一个请求B进行查询操作。那么会出现如下情形:
（1）请求A进行写操作，删除缓存
（2）请求B查询发现缓存不存在
（3）请求B去数据库查询得到旧值
（4）请求B将旧值写入缓存
（5）请求A将新值写入数据库
上述情况就会导致不一致的情形出现。而且，如果不采用给缓存设置过期时间策略，该数据永远都是脏数据。
那么，如何解决呢？采用延时双删策略
伪代码如下
public void write(String key,Object data){
redis.delKey(key);
db.updateData(data);
Thread.sleep(1000);
redis.delKey(key);
}
转化为中文描述就是
（1）先淘汰缓存
（2）再写数据库（这两步和原来一样）
（3）休眠1秒，再次淘汰缓存
这么做，可以将1秒内所造成的缓存脏数据，再次删除。
那么，这个1秒怎么确定的，具体该休眠多久呢？
针对上面的情形，读者应该自行评估自己的项目的读数据业务逻辑的耗时。然后写数据的休眠时间则在读数据业务逻辑的耗时基础上，加几百ms即可。这么做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。
如果你用了mysql的读写分离架构怎么办？
ok，在这种情况下，造成数据不一致的原因如下，还是两个请求，一个请求A进行更新操作，另一个请求B进行查询操作。
（1）请求A进行写操作，删除缓存
（2）请求A将数据写入数据库了，
（3）请求B查询缓存发现，缓存没有值
（4）请求B去从库查询，这时，还没有完成主从同步，因此查询到的是旧值
（5）请求B将旧值写入缓存
（6）数据库完成主从同步，从库变为新值
上述情形，就是数据不一致的原因。还是使用双删延时策略。只是，睡眠时间修改为在主从同步的延时时间基础上，加几百ms。
采用这种同步淘汰策略，吞吐量降低怎么办？
ok，那就将第二次删除作为异步的。自己起一个线程，异步删除。这样，写的请求就不用沉睡一段时间后了，再返回。这么做，加大吞吐量。
第二次删除，如果删除失败怎么办？
这是个非常好的问题，因为第二次删除失败，就会出现如下情形。还是有两个请求，一个请求A进行更新操作，另一个请求B进行查询操作，为了方便，假设是单库：
（1）请求A进行写操作，删除缓存
（2）请求B查询发现缓存不存在
（3）请求B去数据库查询得到旧值
（4）请求B将旧值写入缓存
（5）请求A将新值写入数据库
（6）请求A试图去删除请求B写入对缓存值，结果失败了。
ok,这也就是说。如果第二次删除缓存失败，会再次出现缓存和数据库不一致的问题。
如何解决呢？
采用重试机制和告警监控人工兜底方案。
先更新数据库，再删缓存
老外提出了一个缓存更新套路，名为《Cache-Aside pattern》。其中就指出
- 失效：应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。
- 命中：应用程序从cache中取数据，取到后返回。
- 更新：先把数据存到数据库中，成功后，再让缓存失效。
另外，知名社交网站facebook也在论文《Scaling Memcache at Facebook》中提出，他们用的也是先更新数据库，再删缓存的策略。
这种情况不存在并发问题么？
不是的。假设这会有两个请求，一个请求A做查询操作，一个请求B做更新操作，那么会有如下情形产生
（1）缓存刚好失效
（2）请求A查询数据库，得一个旧值
（3）请求B将新值写入数据库
（4）请求B删除缓存
（5）请求A将查到的旧值写入缓存
ok，如果发生上述情况，确实是会发生脏数据。
然而，发生这种情况的概率又有多少呢？
发生上述情况有一个先天性条件，就是步骤（3）的写数据库操作比步骤（2）的读数据库操作耗时更短，才有可能使得步骤（4）先于步骤（5）。可是，大家想想，数据库的读操作的速度远快于写操作的（不然做读写分离干嘛，做读写分离的意义就是因为读操作比较快，耗资源少），因此步骤（3）耗时比步骤（2）更短，这一情形很难出现。
假设，有人非要抬杠，有强迫症，一定要解决怎么办？
如何解决上述并发问题？
首先，给缓存设有效时间是一种方案。其次，采用异步延时删除策略，保证读请求完成以后，再进行删除操作。
