Redi缓存注意事项

缓存使用的场景

在一个高频访问的应用系统中，每次用户的请求须要去存储中获取数据，会对数据库形成很大的压力、容易致使数据库的奔溃。因此才会出现缓存来分担一部分的数据库的压力。

具体会产生数据库访问压力的业务场景以下：

1 高频访问数据存储会对数据库的QPS形成很大的压力。

2数据统计类的查询须要消耗很大的数据库cpu、改为由定时任务产生数据推送缓存、每次查询从缓存里面取。

3 业务中产生中间态的数据没有什么业务含义、但有须要有个存储来持久化、因此放到缓存中来。例如验证码、登陆的token等。 

 

缓存使用的问题

 

1 缓存一致性问题

当数据时效性要求很高时，须要保证缓存中的数据与数据库中的保持一致，并且须要保证缓存节点和副本中的数据也保持一致，不能出现差别现象。这就比较依赖缓存的过时和更新策略。通常会在数据发生更改的时，主动移除对应的缓存。

  因此须要经过事物机制来保证缓存的一致性。

2缓存高并发访问问题

在高并发场景下，有多个请求去共同请求一份相同的业务数据。有可能多个请求先去从缓存中获取数据、获取不到的并发的去从数据库获取数据，对后端数据库形成极大的冲击，甚至致使 “雪崩”现象。

方案一

能够作一个随机的等待、错峰去访问缓存的信息。这样就能保证同一时刻高并发的访问、通过时间离散以后只有小部分的请求访问数据库、大部分的请求去命中缓存。

方案二

能够按照比例限制有部分数据直接访问数据库而后更新缓存、大部分的数据直接请求缓存。

按照实际的场景去作判断例如 1%的场景直接访问数据库，99%的能够经过缓存获取到数据。

方案一和方案有什么区别呢？你们能够思考下。

 

3缓存击穿的问题

 在系统设计的的时候预期是经过缓存来减轻数据库的压力、防止数据奔溃的状况。在某个实际发生的场景中、大量的请求并无命中缓存而致使了大量请求达到数据库、从而致使数据库有巨大冲击和压力。

 场景一 缓存中没有数据

  在某个大促活动中有大量的热点数据，互动一开始须要访问这些数据。因为活动开始的时候洪峰流量到来，全部的请求缓存、缓存直接击穿，访问数据库致使数据库直接cpu 100%,业务系统直接奔溃。

对于这种场景能够提早对数据进行预热，开活动开始前先将数据推送到缓存中。

 

 场景二 缓存集中失效

 

因为咱们在缓存使用的过程当中会设置缓存的失效时间、若是设置的不合理可能会致使数据集中失效的状况。因为缓存集中失效会致使系统缓存穿透、在同一时刻高并发的访问数据，形成数据雪崩。

解决这种场景的能够将失效的时间由固定值+随机值来构成。EXPIRE_TIME=FIX_TIME+RUND_TIME 例如你想保证整个EXPIRE_TIME是5S 左右，能够 经过EXPIRE_TIME=4000+Random(1000)

3单条缓存数据过大

  咱们大多数缓存服务的实现都依赖于内存，而大多数缓存服务在设计的时候都是用来存储不少小数据的内存分配机制。而内存分配算法都是 512 bte ,1k,2k,4k的内存分配机制来确保系统的内存可以容纳更多的记录数。

 同时对接持久存储的时候大多都遵循磁盘4k对其的刷盘原理。若是咱们存储的一条记录数据超过4K、对整个缓存的性能形成很大的影响。从而致使系统oom。

例如REDIS内存分配策略：

Redis默认内存分配器采用jemalloc，可选的分配器还有：glibe、tcmalloc。

内存分配器是为了更好的管理和重复利用内存，分配内存策略通常采用固定范围的内存块进行内存分配。

这里不去深究jemalloc的内存分配原理，简单地说jemalloc将内存空间划分为三个部分：Small class、Large class、Huge class，每一个部分又划分为不少小的内存块单位： 
- Small class: [8byte], [16byte, 32byte, … 128byte], [192byte, 256byte, … 512byte], [768byte, 1024byte, … 3840byte] 
- Large class: [4kb, 8kb, 12kb, … 4072kb] 
- Huge class: [4mb, 8mb, 12mb …]

https://blog.csdn.net/Leon_cx/article/details/82597722

常见使用方式

 1定时失效

 

用发起请求后系统从缓存获取数据、获取不到从数据库获取、获取以后放入到缓存中，设置一个主动失效的时间。

 

2 主动失效

 

在数据查询的时候会设置一个时间、超时会依赖缓存自身的机制来失效数据。当数据更新的时候、会主动失效缓存。保证缓存的数据和数据库的数据尽量一致。

3 定时更新缓存

 

对于统计类的需求、每次查询须要耗费不少数据库资源、直接查询数据库会严重影响数据库的性能。而且数据变化很是快、采用主动或者被动缓存都会有缓存击穿的风险。因此直接经过定时任务来统计数据、统计完之后会更新到缓存中，每次用去取都是从缓存中查询。这样作会形成缓存中的数据不是实时的，但能确保整个系统的稳定性。

 

3 按比例放行更新缓存

 

当用户在大流量访问的时候能够按照比列来更新数据缓存信息 这样既能保证数据的实时性，又能保证数据库的稳定性。在用户访问量小的状况下能够将访问数据库的比列调大一点，在数据访问的高峰期的是能够将比列调小。