https://blog.csdn.net/hjm4702192/article/details/80518856 https://www.cnblogs.com/xrq730/p/8944539.html https://www.cnblogs.com/qwangxiao/p/8921171.html
1.为什么要使用redis 从性能和并发的角度,当然也可以作为分布锁
从性能角度上来看 -------需要执行耗时特别久，且结果不频繁变动的SQL，就特别适合将运行结果放入缓存 从并发角度上来看 -------大并发的情况下，所有的请求直接访问数据库，数据库会出现连接异常,就需要使用redis做一个缓冲操作，让请求先访问到redis，而不是直接访问数据库 一刹那者为一念，二十念为一瞬，二十瞬为一弹指，二十弹指为一罗预，二十罗预为一须臾，一日一夜有三十须臾。 2.redis的缺点 -------缓存与数据库双写一致性问题 -------缓存雪崩问题 -------缓存击穿问题 -------缓存并发竞争问题 3.单线程的redis为什么这么快 -------这个问题实际上是对redis的内部机制的考察,实际上redis单线程的工作模型 回答:因为redis是纯内存操作,并且是单线程操作避免了频繁的上下文切换,最后采用了非阻塞i/o的多路复用机制 4.redis的数据类型以及使用场景 –String类型 就是最常规的set get操作,value可以是String也可以是数字,一般用于做复杂的计数功能的缓存 –hash类型 value存放的就是结构性的对象,可以比较方便的操作其中的一个字段,做单点登录的时候，就是用这种数据结构存储用户信息，以cookieId作为key，设置30分钟为缓存过期时间，能很好的模拟出类似session的效果。 –list类型 使用list可以简单的做消息队列的功能,另外可以使用lang功能做基于redis的分页功能,用户体验好,本人还用一个场景，很合适—取行情信息。就也是一个生产者和消费者的场景。LIST可以很好的完成排队，先进先出的原则。 –set类型 set类型存放的是没有重复数据的集合，可以做全局去重，那么为什么不使用jvm自带的set进行去重呢，因为我们一般情况是用集群进行部署，因此如果希望全局去重的话就要重新起一个公共服务，之后，这样就很麻烦。另外可以利用交集、并集、差集等操作，可以计算共同喜好，全部的喜好，自己独有的喜好等功能。
–sorted set sorted set多了一个权重参数score,集合中的元素能够按score进行排列。可以做排行榜应用，取TOP N操作。 5.redis的过期策略和内存淘汰机制 比如你redis只能存5G数据，可是你写了10G，那会删5G的数据。怎么删的？ 数据已经设置了过期时间，但是时间到了，内存占用率还是比较高，原因是什么? 因为redis采用的是定期删除和惰性删除策略 那么为什么不使用定时删除策略呢 ？ 定时删除，使用一个定时器来负责监视key，过期则自动删除。虽然内存及时释放，但是十分的消耗CPU资源，在大并发请求下，CPU要将应用时间用在处理请求，而不是删除key，因此没有使用定时删除策略 那么定期删除和惰性删除策略是如何进行工作的呢？ redis默认每隔离100ms检查是否有过期的key，有过期的key则删除。需要说明的是，redis不是每个100ms将所有的key检查一次，而是随机抽取进行检查(如果每个100ms将全部key进行检查，redis将会相当卡)。因此，如果只采用定期删除策略会导致很多key到时间了没有删除 因此这个时候需要用到惰性删除，就是说在你获取某一个key的时候redis会检查一下，这个key如果设置了过期时间，那么判断是否过期，如果过期了之后就会删除。 那么采用过期删除和惰性删除之后，就完全正确吗？ 不是的，如果定期删除没有删除掉key，然后也没有及时的去请求key，这样的话惰性删除也没有生效，这样redis的内存会越来越高，那么这个时候就应该采用内存淘汰机制。 在redis.conf中有一行配置 #maxmemory-policy volatile-lru 该配置就是配置内存淘汰策略的 noeviction：内存没有空间容纳新写入的数据时候，新写入操作就会报错。很少用 allkeys-lru:当内存没有空间容纳新写入的数据时候，在键空间中移除最近最少使用的key。推荐使用，项目中使用 allkeys-random:当内存不足以容纳新写入数据时候，在键空间中，随机移除某个key。 allkeys-random:当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。很少用 volatile-lru:当内存不足以容纳新写入的数据时候，在设置了过期时间的键空间中，移除最近使用最少的key。这种情况一般是将redis既当缓存又做持久化存储的时候使用，不推荐 volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。不推荐 volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。不推荐 注意：如果没有设置 过期时间expire 的key, 不满足先决条件(prerequisites)，那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行为, 和 noeviction(不删除) 基本上一致。 6.redis和数据库双写一致性问题
一致性问题是分布式常见的问题，一致性问题还可以分为最终一致性和强一致性问题，数据库和缓存双写就必然会存在不一致的问题。在处理一致性问题上面要知道弱国数据有强一致性要求，不能放缓存。因此我们就是努力保证最终一致性，另外我们做的方案其实从根本上来说，只能降低不一致发生的概率，无法完全避免。 因此要采取正确更新策略，先更新数据库，再删缓存。其次，因为可能存在删除缓存失败的问题，提供一个补偿措施即可，例如利用消息队列。
7.redis对象的保存方式 对象的保存方式分为两种一种是json字符串的方式，一种是字节流的方式 json字符串的方式需要
