缓存+redis+容器

序言

夏日炎炎,无风。。。从空调房间出来,再到接近四十度的高温,这个过程。。。缓存预热了解一下。。。

为什么要用缓存?因为追求性能,因为要追求极致的用户体验。

缓存基本上不需要持久化,从而是无状态的,那么使用容器是最好的方法了,而缓存系统,redis相当合适。。不要问为什么不用memcache。。。因为redis的功能比memcache多,因为redis还能持久化,因为redis还能支持各种数据结构,并且两者的性能相差无几,都能支持8万左右的TPS。

缓存理论

1、 缓存适合的场景

缓存,就是将一些需要读取数据放在磁盘或者内存中,由于是追求速度,从而一般放在内存中。

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

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

2、 缓存穿透问题

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

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

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

3、 缓存雪崩的问题

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

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

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

4、 缓存命名和失效时间

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

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

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

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

缓存热点,当使用的是缓存集群的时候,如果缓存分布的有问题,那么可能一台缓存服务器承担了大部分的压力,而另外一些缓存服务器则没有压力,从而也有可能导致缓存雪崩,直接压垮一台缓存服务器,上线,又压垮一台,死循环。。。

在进行缓存数据的时候,需要分析热点数据,并且要分析缓存的数据量的大小,否则无论是网络还是内存,都可能造成缓存雪崩的潜在影响点。

java不可能的。。。快让我看看你的jedis报错是啥,read olny?time out?还是redis server went away。。。。

redis主备

reids是一个键值存储的内存cache或者持久化存储,用redis做缓存是简单的。而redis再此时也无需持久化机制,从而直接在容器中使用。

两条指令运行一个redis的主从缓存,配置文件使用默认的配置文件,在master的配置文件中修改bind即可,在slave的配置文件中,修改bind和slaveof即可。

如何来检测这个redis是ok的呢。。。嗯,用容器来运行一个测试redis的功能,执行的效果如下所示:

专门使用一个testredis的容器来运行一个测试任务,在正常的情况下,容器的退出码为0,当redis异常的时候,容器的退出码为1,从而可以在生产中进行功能性测试,当然,你也可以进行自动修复,例如拉起失败的redis容器即可。

检测脚本的内容:

在运行这个测试容器的时候,需要注意的是,要使用host的网络,如下所示:

以后要进行运行测试容器的时候,只要start这个容器即可。

此种过程进行优化,例如使用一个脚本,就直接创建master,slave和测试容器,还能进一步将master和slave分布在不同的机器上,还能进一步直接创建sentinel进行自动切换和故障转移,还能直接创建一个redis cluster模式。

在使用config rewrite写入配置文件的时候,注意selinux可能会阻止你写入配置文件。

在使用的缓存策略为noeviction的时候,那么一旦可用内存使用完毕,就会显示OOM,内存超过了最大使用内存,默认配置并不会使用LRU算法。

在查看键的数量的时候,切记keys是高危指令,会阻塞所有的请求,影响生产环境的服务。。。不信?到生产上试试,指令为keys *。

在查看大量键的时候,使用scan指令,每次返回一个游标,相当于分页查看咯。

在进行转储的时候,不要用save指令,切记要使用bgsave和bgrewriteaof,虽然这两个不会阻塞服务,其实也会阻塞,不过时间很短,主要耗费的时间在fork的时候,400ms了解一下。。。fork一般需要多少ms?求解

闲扯

缓存命中率?不可能的。。。这辈子都不可能命中的。。。。

带着期望而来,满怀失望而去。。。夏日无风。。。

如何捍卫你的观点?这是一个有意思的话题。

依稀记得有人挑战,但是我忘记了是个具体什么样的问题。。。其实捍卫不捍卫真的无所谓。。。不捍卫自己的观点在于,暴露对方的无知。。。如果捍卫我自己的观点,那就会暴露自己的无知,当然,一般我都是先表现出我的无知。。。这样才能引入新奇的观点,否则。。。一无所获。

再谈自动化运维,有人说,你就两个命令的事儿,你还费劲巴拉的写成一个界面,写成一个按钮,有意思么。。。有意思,相当有意思。

防止误操作,这是主要功能,自动化平台承担大部分责任,封装所有的高危操作指令,可以进行二次确认。

权限控制,哪些人能使用这个,哪些人不能使用。

一台机器两个指令,三台你试试,三百台你试试,三千台呢?

有的时候,感觉思维层次不同。。。都不想解释,解释就是掩饰

一个缓存系统,能玩多久?能玩很久很久。。。。

一个系统,里面包含着无数个小系统,缓存系统?可以用redis可以用memcache,你怎么选?

一个系统,里面又包含着无数的知识点,redis是单进程单线程的服务,那么那些会阻塞服务?在客户端请求过来,tcp连接满了怎么办?参数backlop是否要响应增加?

一个系统,要追求高可用,高性能,那么就会引入其他的组件,例如使用sentinel达成高可用,使用redis cluster来进行搭建,使用前端的各种中间件。。。

一个系统的配置,又包含了各种样的东西,redis的持久化有两种,一种是rdb,一种是aof,有何区别,哪种更好?如果持久化会丢失数据否?丢失多久的数据可以接受?

一个系统的构成,各种各样的方式,如何进行主备复制?sentinel如何来检测master是否宕机?sentinel为何要用3个或者5个节点?

子子孙孙无穷尽也。。。可能很多时候,都碰不到这种场景?高并发,不可能的。。。这辈子都不可能的,风都么有。。。 备用知识命中率,了解一下。。

原文发布于微信公众号 - SRE运维实践(gh_319dd73ec076)

原文发表时间:2018-07-25

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券