m0_56709616的博客

【代码】11 Redis大厂真实需求落地案例实战。

如果redis中有数据：需要和数据库中的值相同如果redis中无数据：数据库中的值要是最新值请求A进行写操作，删除缓存后，工作正在进行中…A还么有彻底更新完请求B开工，查询redis发现缓存不存在请求B继续，去数据库查询得到了myslq中的旧值请求B将旧值写入redis缓存请求A将新值写入mysql数据库上述情况就会导致不一致的情形出现。如果数据库更新失败，导致B线程请求再次访问缓存时，发现redis里面没数据，缓存缺失，再去读取mysql时，从数据库中读取到旧值。

MySQL的主从复制将经过如下步骤：开启 MySQL的binlog写入功能授权canal连接MySQL账号mysql默认的用户在mysql库的user表里默认没有canal账户，此处新建+授权canal服务端下载解压后整体放入/mycanal路径下配置修改/mycanal/canal.deployer-1.1.5/conf/example路径下instance.properties换成自己的在mysql新建的canal账户建module改pom写YML主启动业务

int保存long 型(长整型)的64位(8个字节)有符号整数只有整数才会使用 int，如果是浮点数， Redis 内部其实先将浮点数转化为字符串值，然后再保存。embstr代表 embstr 格式的 SDS(Simple Dynamic String 简单动态字符串),保存长度小于44字节的字符串EMBSTR 顾名思义即：embedded string，表示嵌入式的Stringraw保存长度大于44字节的字符串。

定期删除策略的难点是确定删除操作执行的时长和频率：如果删除操作执行得太频繁，或者执行的时间太长，定期删除策略就会退化成立即删除策略，以至于将CPU时间过多地消耗在删除过期键上面。如果删除操作执行得太少，或者执行的时间太短，定期删除策略又会和惰性删除束略一样，出现浪费内存的情况。因此，如果采用定期删除策略的话，服务器必须根据情况，因此，如果只采用定期删除策略，会导致很多key到时间没有删除。周期性轮询redis库中的时效性数据，采用随机抽取的策略，利用过期数据占比的方式控制删除频度。

**} }synchronized单机版OK，上分布式nginx分布式微服务，单机锁不行/(ㄒoㄒ)/~~取消单机锁，上redis分布式锁setnx只加了锁，没有释放锁，出异常的话，可能无法释放锁，必须要在代码层面finally释放锁宕机了，部署了微服务代码层面根本没有走到finally这块，没办法保证解锁，这个key没有被删除，需要有lockKey的过期时间设定为redis的分布式锁key，增加过期时间。

是什么危害建Module：bloomfilter_demo改POM写YML主启动业务类布隆过滤器说明方案3：Redis布隆过滤器解决缓存穿透Guava缺点说明：Guava 提供的布隆过滤器的实现还是很不错的 （想要详细了解的可以看一下它的源码实现），但是它有一个重大的缺陷就是只能单机使用 ，而现在互联网一般都是分布式的场景。案例：白名单过滤器白名单架构说明误判问题，但是概率小可以接受，不能从布隆过滤器删除全部合法的key都需要放入过滤器+redis里面，不然数据就

使用时最好不要让实际元素数量远大于初始化数量当实际元素数量超过初始化数量时，应该对布隆过滤器进行重建，重新分配一个 size 更大的过滤器，再将所有的历史元素批量 add 进行。

JD购物车早期 设计目前不再采用，当前小中厂可用。

Redis自身出道就是优秀，基于内存操作、数据结构简单、多路复用和非阻塞 I/O、避免了不必要的线程上下文切换等特性，在单线程的环境下依然很快；但对于大数据的 key 删除还是卡顿厉害，因此在 Redis 4.0 引入了多线程unlink key/flushall async 等命令，主要用于 Redis 数据的异步删除；