weixin_52136521的博客

例如一些抢票业务，要判断库存，那必定就要加锁，由于锁属于jvm，集群部署下面多个jvm的锁不一样，单体项目没关系，集群就锁不住，这里就需要公共所，也就是分布式锁。在业务粒子细度比较大的时候，不同函数可能相互调用，例如下图，一个线程内方法一里面逻辑加锁，执行业务，业务里面调用方法二，方法二加同一把锁，如果能加成功，代表可重入，否则不是。如何实现重入锁呢？

查询一个不存在的数据，mysql查询不到数据也不会直接写入缓存，就会导致每次请求都查数据库简单来说就是大量请求打到数据库去了。我们知道数据库是与磁盘打交道的，速度很慢，远不及类似于redis这种缓存数据库。为什么会发生上述的情况呢？原因在于有人知道你的请求路径，并发起恶意攻击。例如下图，恶意用户用造假的id发起大量请求，此时redis大概率是没有该数据，请求就会直接打入数据库，由于数据库也没有数据，所以不会写入redis，那么每次请求都会打入数据库，大量的这种请求可能会瞬间压垮数据库。

这里针对的是互斥锁解决缓存击穿的一个细节。如下图，当线程1在第4步构建缓存之时，线程2查询缓存未命中，之后线程1完成缓存写入操作，释放锁，线程2获取互斥锁成功，线程2就会进行重复的查询数据库、重建缓存。这里我只展示了一个线程2，当大量类似线程2的请求来临时，数据库依然会有压力，这里的解决办法是双重判定锁。对比下面两个逻辑，不一样的地方加粗了。

同时，因为原Master宕机了12s，没有一个（min-slaves-to-write）从节点与主节点之间的数据复制在10s（min-slaves-max-lag）内，不满足配置要求，原Master就无法执行写操作了。脑裂的主要原因其实就是哨兵集群认为主节点已经出现故障了，重新选举其它从节点作为主节点，而原主节点其实是假故障，从而导致短暂的出现两个主节点，那么在主从切换期间客户端一旦给原主节点发送命令，就会造成数据丢失。如果Master节点因为某些原因挂了12s，导致哨兵判断主节点客观下线，开始主从切换。

如下图，单个redis处理数据上限不够就要搭建集群，搭建多个redis，其中一个为主节点，其他的为从节点，主节点进行写操作，然后同步到从节点，从节点进行读操作，这样的读写分离大大提高了redis的整体性能。那主节点如何同步数据给从节点呢？接着往下看。

先给大家抛出一个问题： redis也是存储数据的，那肯定就存在容量问题，内存是有限的，数据存满了后该怎么办呢？淘汰部分数据？淘汰哪些数据？这个其实就是redis内存淘汰策略的知识。有八大淘汰策略，重点关注的我会提醒。

给某一个key设置过期时间，当key过期的时候，恰好这时间点对这个key有大量的并发请求过来，这些并发的请求可能会瞬间把DB压垮。我知道你可能会想，第一个请求打到数据库拿到数据后，会进行redis数据同步吧，这样的话后续的请求就直接从redis请求数据了，那你就太理想化了。打个比方，某个key在业务逻辑非常麻烦，在redis重建需要很久，那么这个时间段redis是没有数据的，恰好又有大量请求，这些请求就会全部打入数据库，给数据库带来巨大压力。

例如set name liming 10. 10秒后name会被被如何删除呢？redis提供两种方案。