4.3、缓存击穿
击穿定义：
现象：大并发集中对这一个热点key进行访问，当这个Key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库。
击穿解决：
设置热点数据永远不过期 加上互斥锁也能搞定了
4.4、双写一致性
双写：缓存跟数据库均更新数据，如何保证数据一致性？
1、先更新数据库，再更新缓存
安全问题：线程A更新数据库->线程B更新数据库->线程B更新缓存->线程A更新缓存。导致脏读。
业务场景：读多写少场景，频繁更新数据库而缓存根本没用。更何况如果缓存是叠加计算后结果更浪费性能。
2、先删缓存，再更新数据库
A 请求写来更新缓存。
B 发现缓存不在去数据查询旧值后写入缓存。
A 将数据写入数据库，此时缓存跟数据库不一致。
因此 FackBook 提出了 Cache Aside Pattern
失效：应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。
命中：应用程序从cache中取数据，取到后返回。
更新：先把数据存到数据库中，成功后，再让缓存失效。
4.5、脑裂
脑裂是指因为网络原因，导致master节点、slave节点 和 sentinel集群处于不用的网络分区，此时因为sentinel集群无法感知到master的存在，所以将slave节点提升为master节点 此时存在两个不同的master节点就像一个大脑分裂成了两个。其实在Hadoop 、Spark集群中都会出现这样的情况，只是解决方法不同而已(用ZK配合强制杀死)。
集群脑裂问题中，如果客户端还在基于原来的master节点继续写入数据那么新的master节点将无法同步这些数据，当网络问题解决后sentinel集群将原先的master节点降为slave节点，此时再从新的master中同步数据将造成大量的数据丢失。
Redis处理方案是redis的配置文件中存在两个参数
min-replicas-to-write 3 表示连接到master的最少slave数量
min-replicas-max-lag 10 表示slave连接到master的最大延迟时间
如果连接到master的slave数量 < 第一个参数 且 ping的延迟时间 <= 第二个参数那么master就会拒绝写请求，配置了这两个参数后如果发生了集群脑裂则原先的master节点接收到客户端的写入请求会拒绝就可以减少数据同步之后的数据丢失。
