weixin_62513677的博客

第三方开源的canal-starter：地址:https://github.com/NormanGyllenhaal/canal-client。缓存预热:在实际开发中，我们可以利用大数据统计用户访问的热点数据，在项目启动时将这些热点数据提前查询并保存到Redis中。注意：这里的path是路径，并不包含IP和端口，这个请求会被nginx内部的server监听并处理，可以使用反向代理。Canal提供了各种语言的客户端，当Canal监听到binlog变化时，会通知Canal的客户端。

默认情况下，当一个元素过期的时候，Caffeine不会立即将其清理或删除，而是当再一次读或写操作后，或者在空闲时间完成对失效数据的驱逐。Redis处理并发的能力是非常强大的，但是tomcat的支持并发的能力跟不上Redis的性能，导致整体性能的下降。为了应对上述问题，我们采用多级缓存，就是在请求处理的每个环节分别添加缓存，减轻tomcat的压力，提升性能。Caffeine是一个基于java8开发的，提供了近乎最佳命中率的高性能本地缓存库。缺点：存储容量有限，可靠性较低，无法共享。

Lua是一种小巧的脚本语言，底层用C语言实现，为了嵌入式应用程序中。官网：https://www.lua.org/例如：定义一个函数，用来打印数组。函数测试变量的或值的数据类型。

key是num，那么就根据num计算，如果是{itcast}num，则根据itcast计算。命令可以让集群中的某个master宕机，切换到执行cluster failover命令的这个slave节点上，实现无感的数据迁移。如上图的流程，首先发送请求，得到现在的offset值，判断是否一致，不一致进行追赶，然后进行故障转移。：参数将添加的节点设置为从节点，并可以指定对应的主节点，如果没有参数默认添加的节点为主节点。在主节点出现宕机的情况下，如果使用插槽，可以进行将宕机节点对应的插槽转移到对应或者的节点。

在Sentinel集群监管下的Redis主从集群，其节点会因为自动故障转移而发生变化，Redis的客户端必须感知这种变化,及时更新连接信息。Spring的RedisTemplate底层利用lettuce实现了节点的感知和自动切换。若超过指定数量的哨兵都认为该实例主观下线，则该实例客观下线，这个值最好超过哨兵实例数量的一半。如果某哨兵节点发现某实例未在规定时间内响应，则认为该实例主观下线。这里我们讲述在Linux下搭建三个三个哨兵。

这个时候如果redis从节点宕机当他醒过来之后，master已经转了一圈了上一圈的数据被覆盖掉，slave就只能进行全量同步了。注意：repl_baklog中的存储是进行环形存储的，slave与master一直在环形存储内进行增量同步。slave返回的offset中记录了返回来的在backlog中读取到了哪里，baklog将后边的数据返回。主从第一次同步是全量同步，但是如果slave重启后同步，则执行增量同步。主从节点可以实现读写分离，将都大量的读操作分担与诸多从节点当中去。在cli客户端使用命令。

快速掌握Redis持久化

如果我们需要统计UV值，我们可以使用HyperLogLog，它是从LogLog算法中派生出来的概率算法，用于确定非常大的集合的基数，但是它的单个存储的统计内存永远小于16kb，但是代价就是统计是概率性的有小于0.81%的误差，不过可以忽略。也叫做写扩散，发布的消息不需要写入到发件箱中，直接推送到被关注人的收件箱中并通过时间戳进行排序，延时低，但是比如说微博中的一些大V，粉丝人特别多，这样就会写很多。范围可以是圆形或矩形。:指定圆心、半径，找到该圆内包含的所有member，并按照与圆心之间的距离排序后返回。

但是这种方式存在弊端，当我们指定ID为$的时候，如果我们在执行handleMessage操作时一下传过来四五条消息，这时就会出现漏读的情况，针对这个我们采用一下方案。PubSub（发布订阅），消费者可以订阅一个或多个channel，生产者向对应channel发送消息后，所有的订阅者都能够收到相关信息。其它：根据指定的id从pending-list中获取已消费但未确认的消息，例如0，是从pending-list中的第一个消息开始。起始ID标示，$代表队列的最后一个消息，0则代表队列中的第一个消息。

在当下的场景中都是多台Redis服务器进行主从服务器，假定这时有一个线程访问中Redis服务器，成功获取锁，就在这时，主服务器与从服务器同步数据的时候主服务器出现故障，这时Redis哨兵会从从服务器中选出一个来当主服务器，这是锁信息并未同步，就在这时其他线程也能够得到锁进行操作，就会出现问题。原理就是在存放value的时候通过计数器机制进行重复访问，当同一个线程在此访问这个锁的时候会进行判断，是不是自己同一个线程，是的话计数器加1，同理释放锁的时候就是将该计数器的数字减1。这是可复用锁的底层原理。

分布式锁中我们设置的过期时间：如果有一个线程获取锁之后在进行操作时，到达了锁的过期时间，之后就会有别的线程获得锁，如果这时，第一个线程执行完成后释放锁，就会将第二个锁的线程删除改进分布式锁添加释放锁的判断上述我们做了修改进行判断，但是还存在一种极端情况，当线程操作完毕需要释放锁的时候，这个时候已经判断完毕，但是由于比如说垃圾回收等问题对线程的释放操作进行阻塞，这个时候如果超过等待时间，这是还是会出现上述问题，在阻塞结束之后，会删除其他线程的锁。

就是在商品上添加版本号，一个线程查询用户的时候查询到id和版本号信息，当他需要进行修改数据的时候进行对比现在的版本号看有没有发生变化马，如果有就停止操作，并重新开始，如果没有则修改数据并将版本号加一，每个线程都执行此操作。就是在下单的时候，在订单数据库中进行查询如果该用户已经存在单子，那么会返回异常，如果在库中没有该用户，在创建新的订单，注意在创建新的订单之前需要使用悲观锁，防止多线程问题。原因：在多个集群中就会有多个jvm下的锁监视器，这些锁监视器只会监控本服务器下的悲观锁。判断库存有没有发生变化。

32bit，秒内的计数器，支持每秒生成2^32个不同的ID。:31bit，一秒为单位，可以使用69年。:1bit,一直为0。

假若有很多线程进来，访问这个被击穿的数据，这是线程1先进来，拿到互斥锁，进行后面的数据库查询，写入缓存操作，其他线程在这个期间就不会拿到互斥锁，拿不到就会进行等待过一段时间重新在缓存中进行访问。在使用逻辑数据的时候同时也用到了互斥锁，但是处理不同，在线程获得互斥锁后，再创建一个新的线程来进行写入缓存的操作，这时候先返回过期的数据，其他没有拿到互斥锁的线程也是先返回过期数据。缓存雪崩是指在同一时间段，大量的缓存key同时失效或者Redis服务器宕机，导致大量请求到达数据库，带来巨大压力。

当数据库中查询无果的时候，我们在对应的缓存中写入一个null，在下一次访问的时候就不会到达数据库，由缓存返回一个null。首先通过布隆过滤器，如果没有数据就拒绝访问，底层时间通过数据库中的数据通过哈希算法算出哈希值存到布隆过滤器中。缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在，这样缓存就永远不会生效，这些请求都会打到数据库。可能造成短期的不一致 （我在数据库插入一条数据，但是对应的缓存中存的是null）在服务层判断数据库的时候加入缓存空对象方面的技术。优点：内存占用少，没有多余的key。

我们在作者之前的文章:快速掌握Redis安装与基本语法的基础上进行系统的学习，学习自黑马程序员的Redis实战课堂，进行学习总结，希望对大家有所帮助。