Redis缓存更新策略本文整理自黑马程序员相关资料内存淘汰超时剔除主动更新说明不用自己维护，利用Redis的内存淘汰机制，当内存不足时自动淘汰部分数据。下次查询时更新缓存给缓存数据添加TTL时间，到期后自动删除缓存，下次查询时更新缓存编写业务逻辑，在修改数据的同时，更新缓存一致性差一般好维护成本无低高业务场景需求：在基本不会更新数据的情况下可以使用内存淘汰机制在频繁更新数据的情况下可以使用主动更新，并以超时剔除作为兜底方案。主动更新的三种方法CacheAsidePattern：由缓存的调用者，在更新数据库的同时更新缓存Read/WriteThroughPattern：缓存和数据库整合为一个服务

Redis常见使用场景缓存、数据共享分布式、分布式锁、全局ID、计数器、限流、位统计、购物车、时间线Timeline、消息队列、抽奖、点赞、签到、打卡、商品标签、商品筛选、用户关注、推荐模型、排行榜.1.缓存String类型例如：热点数据缓存（例如报表、明星出轨），对象缓存、全页缓存、可以提升热点数据的访问数据。2.数据共享分布式String类型，因为Redis是分布式的独立服务，可以在多个应用之间共享例如：分布式Session org.springframework.session spring-session-data-redis3.分布式锁​ String类型setnx方法，只有不存在时

Redis的Java客户端Jedis优点：以Redis命令作为方法名称，学习成本低廉，简单且实用缺点：Jedis的实例是线程不安全的，在多线程的环境下需要基于线程池来使用lettuce（spring官方默认）基于Netty实现的，支持同步、异步和响应式编程方式，并且是线程安全的。支持Redis的哨兵模式、集群模式、管道模式Redisson（适用于分布式的环境）基于Redis实现的分布式、可伸缩的Java数据结构的集合。包含Map、Queue、Lock、Semaphore、AtomicLong等强大的功能JedisJedis基本使用步骤引入依赖创建Jedis对象，建立连接使用Jedis，方法名与

SQLvsNoSQL结构化SQL是结构化的，一旦定义了表结构，以后在维护数据的时候必须严格遵守定义的结构。NoSQL是非结构化的，常见的形式有Redis的Key-Value存储形式、Document文档型存储形式、Graph图类型存储形式关联的SQL数据库可以通过如外键的方式去维护数据与数据之间的关联NoSQL是非关系型的，如果想要维护数据与数据之间的关系，通常通过json格式的数据进行维护例如：{id:1,name:"张三",orders:[{id:1,item:{id:10,title:"荣耀6",price:4999}},{id:2,item:{id:20,title:"小米11",pr

概述MongoDB是一个介于关系型数据库和非关系型数据库之间的产品，是非关系型数据库中功能最丰富，最像关系型数据库的。MongoDB支持的数据结构非常松散，类似json的bson格式，因此可以存储比较复杂的数据类型。MongoDB最大的特点是支持的查询语言非常强大，语法类似于面向对象的查询语言，几乎可以实现类似关系型数据库单表查询的绝大部分功能，还支持对数据建立索引MongoDB的特点：面向集合存储，易存储对象类型的数据支持查询，以及动态查询支持多种语言文件存储格式为BSON支持主从复制、故障恢复和分片MongoDB的应用场景：游戏应用：使用MongoDB作为游戏服务器的数据库存储用户信息，用

SpringDataRedis的序列化的一些问题RedisTemplate可以接收任意Object作为值写入Redis，但是如果不实现设置序列化器的化默认是采用JDK序列化，序列化后的结果可读性差并且内存占用空间大，如下图。自定义RedisTemplate的序列化方式key和hashKey采用string序列化，value和HashValue采用JSON序列化@ConfigurationpublicclassRedisConfig{@BeanpublicRedisTemplateredisTemplate(RedisConnectionFactoryconnectionFactory){//创

大家好，我是大D。不知是否有小伙伴们疑问，为什么列式存储会广泛地应用在OLAP领域，和行式存储相比，它的优势在哪里？今天我们一起来对比下这两种存储方式的差别。其实，列式存储并不是一项新技术，最早可以追溯到1983年的论文Cantor。然而，受限于早期的硬件条件和应用场景，传统的事务型数据库（OLTP）如Oracle、MySQL等关系型数据库都是以行的方式来存储数据的。直到近几年分析型数据库（OLAP）的兴起，列式存储这一概念又变得流行，如HBase、Cassandra等大数据相关的数据库都是以列的方式来存储数据的。行式存储的原理与特点对于OLAP场景，大多都是对一整行记录进行增删改查操作的，那

zset底层的数据结构为什么使用调表而不是红黑树前言Redis中使用到的数据结构以及各个数据对象的底层数据结构在上一篇文章已经写得非常详细，这里不再赘述。https://www.cnblogs.com/ruigedada/p/16248689.htmlzset的底层数据结构是压缩列表和跳表，当满足以下条件时，Redis将使用压缩列表存储有序集合保存的元素个数要小于128个；有序集合保存的所有元素成员的长度都必须小于64字节。我们都知道，调表的查找时间复杂度为O(logn)，但是红黑树和AVL树的查找效率也是O(logn)呀，为什么zset的底层是调表而不是红黑树或者AVL树呢？一、跳表、红黑树

Redis参考博客https://www.cnblogs.com/beiluowuzheng/https://www.cnblogs.com/hunternet/如有侵权，请联系我删除，谢谢！目录一、什么是redis二、数据结构1.1SDS，简单动态字符串1.1.1SDS底层结构1.1.2SDS内存重分配1.1.3二进制安全1.1.4为什么使用SDS1.1.5SDSAPI1.1.6Redis3.2之后的SDSRedis3.2之后的SDS共有五个结构体Redis是如何创建SDS对象为什么SDS不用内存对齐1.2链表1.2.1list底层结构1.2.2Redis的链表实现的特性1.2.3双向无环链

Redis的三大缓存异常原因分析和解决方案缓存的三个异常分别是缓存击穿、缓存雪崩、缓存穿透。这三个问题一旦发生，会导致大量的请求积压到数据库层，并发量巨大的情况下很有可能导致数据库宕机或是故障，造成严重的生产事故。接下来就来看看这三种缓存异常的原因分析和解决方案。缓存击穿缓存击穿是指针对某个热点数据的请求，无法在缓存中处理，导致大量的针对该数据的请求一下子全都发送到了后端数据库，使数据库压力激增，影响到数据库处理其他的请求。产生原因缓存击穿的情况，经常是发生在热点数据过期失效的情况。如下图：解决方案对于缓存击穿，解决方案其实也很直接。对于访问很频繁的热点数据，就不需要设置过期时间了。这样对热点