聊聊 Redis 的缓存场景

从关系型数据库中读取数据，在数据库层面也可以进行各种优化，例如读性能不足，那么可以添加几个从库，从而数据库的一主多从；例如写性能不足，那么可以分库分表。

在有些场景中，要使用缓存，是因为无法解决读的速度，例如count（*）的操作，无论从数据库的层面如何优化，都不可能提高；还有一种就是sql的执行本身就必须消耗很多资源和时间，例如各种关联查询子查询，这些时候，都可以将这些数据放在缓存当中，从而大大的减轻数据库的压力。

2、缓存穿透问题

在使用缓存的时候，第一个问题就是缓存穿透的问题，就是使用了缓存和没使用缓存是一样的，应用程序到缓存中查询数据，发现数据么有，那么就去数据库查询，在这里，穿透了缓存，缓存没起到保护数据库的作用。

在爬虫爬取网页的时候，每个分页都会爬取，而对于缓存的分页数据，一般只缓存了热点数据，也就是前几页的数据在缓存当中，如果全部爬取，那么就会造成缓存不命中，导致查询数据库；还有一种就是故意搜索一些不存在的关键字，而这些搜索的结果都没有数据，在数据库中也不存在数据，从而造成缓存穿透。

此种解决方法就是：当用户进行第一次查询的时候发现结果为空，那么可以将结果放在缓存中，设置一个短暂的过期时间，从而可以缓解穿透的问题；而对于爬虫的爬取数据，只能进行监控，然后进行访问的IP，依旧只能缓解，不能完全解决。

3、缓存雪崩的问题

缓存雪崩指的是当缓存失效之后，从而引起系统性能的急剧下降，导致数据库不可用从而系统挂掉。

缓存最关键的地方就是内存，当内存满了之后，会有各种策略将缓存进行失效，在分布式环境下，如果有一个缓存失效，而恰好这个缓存是一个热点数据，前端有10个应用都需要访问这个缓存，并且TPS很高的话，那么全部的线程都会去访问数据库，从而能直接将数据库拖垮。

应对缓存雪崩，有很多策略，例如可以设置两个缓存的key，而具有不同的失效时间，当key1失效之后，访问key2，然后更新key1和key2；可以使用分布式锁，从而当应用发现缓存失效之后，拿到锁的线程才去更新缓存；可以使用消息通知机制，当应用发现缓存失效之后，发送消息，然后后台线程进行更新缓存，后台线程会检测缓存中是否存在缓存，如果存在就不更新；专门用一个后台线程来更新缓存，快速的检测缓存是否存在，然后更新缓存，此种也可以解决缓存不一致的问题。

4、缓存命名和失效时间

在使用缓存的时候，都需要一个key，那么这个key怎么命名呢？key太长，占用内存，会使得缓存中能存储的数据减少；key一般的命名规则可以为SQL:1782，表示为这是缓存一个sql的结果，然后用冒号分割，然后表示为缓存的编号，可以为各种sql条件的hash后的结果，这种命名规则的好处就是，在每次在缓存里查询的时候，可以使用通配符，从而可以查询到有多少个缓存在系统中。

缓存的失效时间，这个和业务强相关，对于一些时效性比较高的数据，就不能放在缓存当中，而对于一些不经常变化的数据，可以放在缓存当中，例如一天，缓存主要是应对读多写上的应用，从而大部分的数据例如在搜索的结果的分页数据，这种实时性无须太高，可以放在缓存当中。。。主要看业务的容忍程度，也影响到一部分的用户体验，可能我放入了缓存，更新了，刷新下，还没有更新。

5、缓存预热和缓存热点问题

缓存预热，在系统宕机刚上线的时候，流量全部涌入，而此时缓存中还没有缓存数据，从而可能导致直接压垮数据库，从而在应用程序启动之后，要进行缓存预热，最简单的方法就是点点界面，然后搜索一下结果；最好的方式，就是写一个后台线程，进行缓存预热，在这个后台线程里，会将常用的热点数据都直接加载进缓存当中。

缓存热点，当使用的是缓存集群的时候，如果缓存分布的有问题

（编辑：开发网_开封站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!