m0_73856804的博客

可以认为是永不过期，即当下往Redis中存储数据时，不设置过期时间，而是在设置value时添加一个expire字段（在当前时间基础加上一个过期时间），该字段的意义在于提醒我们何时销毁该key，即在逻辑意义上维护的过期时间，而该key在redis中没有过期时间，再加上在redis配置的合适的内存淘汰策略，只要该key写入redis，就一定可以查到，不会出现缓存未命中的情况。命令的效果与之相近，当该key不存在的时候存入，如果存在就不存入，这就是一种互斥效果，在大量线程并发访问时，只有一条线程可以成功。

ThreadLocal就可以解决该问题，ThreadLocal是一个线程域对象，每一个进入Tomcat的请求都是一个独立的线程，而ThreadLocal的核心作用就是让每一个线程都有自己的数据副本，避免共享资源引发的竞态条件，这样就可以让每一个线程都有对应的独立内存空间取保存对应用户，线程之间互不干扰，因此无论几条请求访问哪些Controller都可以做到独立线程，都有自己的独立用户信息，当需要用户信息时，则Controller从ThreadLocal中取出用户即可。是一种前后端分离的架构。

假如现在只剩下一个商品，但在高并发情况下，假如说有两个线程，正常情况下，线程是按顺序执行的，这样两个线程按顺序执行，就不会出现超卖问题，但是在高并发请况下，线程并不按照顺序执行，可能会交叉执行，就会出现两个线程都会读到数据库中的库存还为一，因此两个库存一起扣减库存，于是库存变为了-1，就造成了超卖问题,，其实就是多线程并发安全问题。例如，线程A先去查询库存，在进行判断，最后在进行扣减时，在进行一次对库存的判断，要求查询到的库存需要和开始查询到的库存保持一致即可。不满足则回滚，其他线程同上。

同一个线程无法获取同一把锁可重入就是指同一个线程可以多次获取同一把锁。举例说明：方法a调用方法b，在方法a重要先获取锁，然后执行业务，去调用方法b，然后方法b也需要获取同一把锁，在这种情况下，如果锁是不可重入的，方法a中获取锁之后，方法b就无法获取锁，只能等待方法a中锁的释放，但锁无法释放，因为方法a的业务没有完成，于是就会出现死锁的情况。在这种场景下，我们要求的锁是可重入锁。：获取锁只尝试一次就返回false，没有重试机制。

如果不存储该字节码数据，RedisTemplate的自动序列化和反序列化就会失败，序列化时还可以，直接将对象里面的key与value存储进就好，但是反序列化需要知道json字符串要转成哪个类型的对象，如果不存储class类型的字节码数据，就无法识别到，就无法实现自动的反序列化。如果想要节省内存空间，就不能能去使用JSON序列化器来处理value，二是统一使用String序列化器，要求只能存储String类型的key或者value，当需要存储Java对象时，手动完成对象的序列化与反序列化。

在Redis官网中提供了各种语言的客户端，地址：以Redis命令做方法名称，学习成本低，简单实用，但是对于Jedis实例是线程不安全的（即创建一个Jedis实例，多线程并发运行时会有线程安全问题，在多线程使用时，必须为每一个线程创建独立的Jedis连接，就是必须要使用连接池的方式来配合使用。）多线程环境下需要基于连接池来使用。Lettuce是基于Netty实现的，支持同步、异步、和响应式编程方式，并且是线程安全的，支持Redis的哨兵模式、集群模式、和管道模式。

经过前面的学习，发现缓存中的问题，无论是缓存穿透，缓存雪崩，还是缓存击穿，这些问题的解决方案业务代码逻辑都很复杂，我们也不应该每次都来重写这些逻辑，我们可以将其封装成工具。而在封装的时候，也会有不少的问题需要去解决。案例学习：缓存工具封装基于StringRedisTemplate封装一个缓存工具类，满足下列需求：方法一：将任意Java对象序列化成JSON并存储在String类型的key中，并且可以设置TTL过期时间。

订单的特点就是数据量比较大，因为用户只要产生购买的行为，就会不停的产生新的订单，如果项目有一定的规模，用户量达到数百万，每天的订单可能就高达数百万，日积月累，单张表显然不能保存如此多的数据，如果无法保存，就需要分到多张表中，如果每张表都采用自增长，每张表都自增，那么订单的id就一定会重复，而订单就不应该重复，因为从业务的角度来考虑，将来一些售后服务还需要订单id，如果id重复，将来一定会出问题。生成时间戳：时间戳是一个31位的数字，单位为秒，需要一个基础的日期作为开始时间，再拿当前时间减去开始时间。

而现在是在方法内部加的锁，就有一个问题：比如方法开启事务，开始执行，获得锁之后，开始做查询，查询完之后减库存，提交订单，然后需要先释放锁，才能提交事务，因为事务被spring容器管理，所以事物的提交是在我们函数执行完以后，由spring做的提交，而在高并发情况下，在锁释放时，可能就已经有线程进行访问了，而此时由于事务尚未提交，如果有别的线程来查询订单，那我们刚新增的订单可能还没有写入数据库，因为没有提交事务，就有可能出现并发安全问题。这样一来，只要拿到的用户ID值一样，那么返回的结果永远一样。

类型示例StringHashListSet{A,B,C}SortedSetGEO（地理坐标（经纬度））BitMap（按位）HyperLog（按位）常用的类型为前五个，后三个则为特殊类型。Redis为了方便我们学习，将操作不同数据类型的命令也做了分组，在官网（

在原有拦截器的基础上再加上一个拦截器，这样用户请求就要先经过第一个拦截器，在经过第二个，第一个拦截器拦截全部路径，所有请求都会被拦截，就可以在这个拦截器中做刷新token有效期的业务（获取token，查询Redis用户，保存到ThreadLocal中，刷新token有效期，放行），第一个拦截器不做拦截，这样就可以确保一切请求都可以触发刷新的动作，第二个拦截器只需要做拦截业务（查询ThreadLocal的用户，不存在则拦截，存在，则继续）即可。问题太多，该方案就被pass了。

缓存就是数据交换的缓冲区（称为Cache），是存储数据的临时地方，一般读写性能较高。比如在计算机中分为CPU，内存以及磁盘，CPU的运算能力非常强，已经远远超过了内存与磁盘的读写能力，但是CPU需要先从内存或者磁盘读到数据，放在寄存器里才可以运算，因为数据读写德恩能够力远远低于CPU的运算能力，所以计算机性能受到了限制，为了解决此问题，就在CPU内部添加了缓存，CPU将经常需要读写的一些数据放在缓存中，就不需要从内存或者磁盘中去拿。这样就可以从分的发挥CPU的运算能力。

假设有两个JVM，JVM1中的线程A，来获取锁，就需要去寻找外部的锁监视器，一旦获取成功，就回去记录当前获取锁的是这个线程A，在高并发情况下，此时如果有其他线程也来获取锁，比如JVM2线程中的线程C，但因为外部的锁监视器中已经记录锁的持有者了，因此线程C获取锁失败，则需要等待锁释放，当线程A释放锁成功后，线程C来获取锁，之后执行自己的业务。线程开启，尝试获取锁，执行命令，结果有两种，OK,NIL，NIL代表失败，证明锁已经被获取，OK代表获取互斥锁成功，则执行业务，业务执行完之后，释放锁。

利用Redis集群提高服务的可用性（针对redis服务宕机）：为了尽可能的避免Redis的宕机，就要提高整个Redis的高可用性，想要提高Redis的高可用性，就必须借助于redis的集群，（redis的哨兵机制，可以实现对服务的监控），先搭建Redis集群形成主从，如果其中有一个机器宕机比如主机器宕机，哨兵会自动地从从机中选出一个替代原来的主，这样就可以保证redis一直能够正常对外提供服务，主从还可以实现数据同步，也不会导致数据的丢失，这样就可以在很大程度上保证Redis的高可用性。