高并发技巧之Redis和本地缓存使用技巧分享

高并发技巧之Redis和本地缓存使用技巧分享

众所周知，缓存最主要的目的就是加速访问，缓解数据库压力。最常用的缓存就是分布式缓存，比如redis，在面对大部分并发场景或者一些中小型公司流量没有那么高的情况，使用redis基本都能解决了。但是在流量较高的情况下可能得使用到本地缓存了，比如guava的LoadingCache和快手开源的ReloadableCache。

三种缓存的使用场景

这部分会介绍redis，比如guava的LoadingCache和快手开源的ReloadableCache的使用场景和局限，通过这一部分的介绍就能知道在怎样的业务场景下应该使用哪种缓存，以及为什么。

Redis的使用场景和局限性

如果宽泛的说redis何时使用，那么自然就是用户访问量过高的地方使用，从而加速访问，并且缓解数据库压力。如果细分的话，还得分为单节点问题和非单节点问题。

如果一个页面用户访问量比较高，但是访问的不是同一个资源。比如用户详情页，访问量比较高，但是每个用户的数据都是不一样的，这种情况显然只能用分布式缓存了，如果使用redis，key为用户唯一键，value则是用户信息。

redis导致的缓存击穿。

但是需要注意一点，一定要设置过期时间，而且不能设置到同一时间点过期。举个例子，比如用户又个活动页，活动页能看到用户活动期间获奖数据，粗心的人可能会设置用户数据的过期时间点为活动结束，这样会

单（热）点问题

单节点问题说的是redis的单个节点的并发问题，因为对于相同的key会落到redis集群的同一个节点上，那么如果对这个key的访问量过高，那么这个redis节点就存在并发隐患,这个key就称为热key。

如果所有用户访问的都是同一个资源，比如小爱同学app首页对所有用户展示的内容都一样（初期），服务端给h5返回的是同一个大json，显然得使用到缓存。首先我们考虑下用redis是否可行，由于redis存在单点问题，如果流量过大的话，那么所有用户的请求到达redis的同一个节点，需要评估该节点能否抗住这么大流量。我们的规则是，如果单节点qps达到了千级别就要解决单点问题了（即使redis号称能抗住十万级别的qps），最常见的做法就是使用本地缓存。显然小爱app首页流量不过百，使用redis是没问题的。

LoadingCache的使用场景和局限性

对于这上面说的热key问题，我们最直接的做法就是使用本地缓存，比如你最熟悉的guava的LoadingCache，但是使用本地缓存要求能够接受一定的脏数据，因为如果你更新了首页，本地缓存是不会更新的，它只会根据一定的过期策略来重新加载缓存，不过在我们这个场景是完全没问题的，因为一旦在后台推送了首页后就不会再去改变了。即使改变了也没问题，可以设置写过期为半小时，超过半小时重新加载缓存，这种短时间内的脏数据我们是可以接受的。

LoadingCache导致的缓存击穿

虽然说本地缓存和机器上强相关的，虽然代码层面写的是半小时过期，但由于每台机器的启动时间不同，导致缓存的加载时间不同，过期时间也就不同，也就不会所有机器上的请求在同一时间缓存失效后都去请求数据库。但是对于单一一台机器也是会导致缓存穿透的，假如有10台机器，每台1000的qps，只要有一台缓存过期就可能导致这1000个请求同时打到了数据库。这种问题其实比较好解决，但是容易被忽略，也就是在设置LoadingCache的时候使用LoadingCache的load-miss方法，而不是直接判断cache.getIfPresent()== null然后去请求db；前者会加虚拟机层面的锁，保证只有一个请求打到数据库去，从而完美的解决了这个问题。

但是，如果对于实时性要求较高的情况，比如有段时间要经常做活动，我要保证活动页面能近实时更新，也就是运营在后台配置好了活动信息后，需要在C端近实时展示这次配置的活动信息，此时使用LoadingCache肯定就不能满足了。

ReloadableCache的使用场景和局限性

对于上面说的LoadingCache不能解决的实时问题，可以考虑使用ReloadableCache，这是快手开源的一个本地缓存框架，最大的特点是支持多机器同时更新缓存，假设我们修改了首页信息，然后请求打到的是A机器，这个时候重新加载ReloadableCache，然后它会发出通知，监听了同一zk节点的其他机器收到通知后重新更新缓存。使用这个缓存一般的要求是将全量数据加载到本地缓存，所以如果数据量过大肯定会对gc造成压力，这种情况就不能使用了。由于小爱同学首页这个首页是带有状态的，一般online状态的就那么两个，所以完全可以使用ReloadableCache来只装载online状态的首页。

小结

到这里三种缓存基本都介绍完了，做个小结：

对于非热点的数据访问，比如用户维度的数据，直接使用redis即可； 对于热点数据的访问，如果流量不是很高，无脑使用redis即可； 对于热点数据，如果允许一定时间内的脏数据，使用LoadingCache即可； 对于热点数据，如果一致性要求较高，同时数据量不大的情况，使用ReloadableCache即可；

小技巧

不管哪种本地缓存虽然都带有虚拟机层面的加锁来解决击穿问题，但是意外总有可能以你意想不到的方式发生，保险起见你可以使用两级缓存的方式即本地缓存+redis+db。

缓存使用的简单介绍

这里redis的使用就不再多说了，相信很多人对api的使用比我还熟悉

LoadingCache的使用

这个是guava提供的网上一抓一大把，但是给两点注意事项

要使用load-miss的话, 要么使用V get(K key, Callable loader)；要么使用build的时候使用的是build(CacheLoader loader)这个时候可以直接使用get()了。此外建议使用load-miss，而不是getIfPresent==null的时候再去查数据库，这可能导致缓存击穿； 使用load-miss是因为这是线程安全的，如果缓存失效的话，多个线程调用get的时候只会有一个线程去db查询，其他线程需要等待，也就是说这是线程安全的。

?

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。