缓存发展史总结及常见问题解决

为什么需要缓存?

我们的服务一般都是  请求-->服务器--->数据库. 

1.当请求越来越大时,服务器和数据库都需要扩展. 数据库除了可以主从分离等方式,还可以使用缓存做中间件减少数据库压力. 就像 请求-->服务器--->缓存-->数据库. 

2.同时有些查询直接通过数据库实际上是比较耗时的,添加缓存也可以提升性能

缓存的优化过程

读的优化

我们加入了一台redis,后面发现读的需求越来越高,一台服务器无法满足需求.这个时候可以采取主从分离的模式,主服务器负责写 从服务器负责读. 只需要不断的扩展从服务器就可以提升读的要求.同时从服务器挂掉也有备用机

写的优化

主服务器如果挂掉怎么办? redis哨兵模式,如果主服务器挂掉,会在从服务器中选举一个新的主服务器.

越来越多的写请求 一台主服务器满足不了, 同时一台服务器的存储能力是有限的?

采用分区方式存取数据. 如现在有三台redis. 每一个数据存的时候 hash(key)%3 存到对应redis即可.

后期数据越来越大 三台已经无法满足需求了呢

继续扩展主服务器,这里有另外一个问题 如果采取上面的算法  添加第四台服务器时 前面的三台数据都需要平移.

减少数据平移的办法?

于是一致性哈希算法出来了.我们将一定范围的hash做成一个环 将最开始三 台服务器的hash计算出来,放在环里对应的位置,这样数据存的时候只需要计算key的hash值 然后顺时针找到最近的一个服务器即可.这样添加第四台服务器时 只需要平移顺时针最近的一台

在服务器比较少的时候 ,比如只有两台 且两台服务器的hash比较接近.那么数据大部分会存在第一台服务器上.如何避免这个问题?

虚拟化服务器,比如现在只有两台,我们计算服务器hash位置的时候 虚拟一百台.然后分给两台.存储数据的时候找到对应的虚拟服务器,然后再存到真实的服务器中.

缓存穿透问题

大量请求到缓存时都没有数据,直接请求到数据库.

真实没有数据的情况,将null也存入缓存

使用布隆过滤器,规划缓存key,过滤掉无效的key

请求时先存入缓存,(key,null)返回,然后异步去刷新缓存(影响真实用户体验)

缓存雪崩问题

缓存服务器同时崩溃,或者数据同时过期

1.保证服务器的高可用

2.存缓存时,过期时间采用固定时间加随机时间

缓存一致性问题

数据库和缓存一个更新成功一个更新失败.

一般先更新数据库 再使用MQ更新缓存,失败了之后MQ可以再次消费.

同时线程并发问题,我们需要给数据加一个版本号.MQ只处理最新版本号的更新.也可以采用删除方式同步,MQ发出删除操作, 在读的时候再去查了保存.这个只能保证最终一致,同时第一次读的时候会相对较慢,所以热点数据需要开机缓存.

针对特别并发频繁数据 如秒杀类数据,采用lua脚本直接更新或发送到MQ.好处是不用关注缓存问题.

缓存并发问题

通常是热点数据到期.大量请求累计起来,大家都在等查询数据库

这种访问高频率的数据,最好不要设置过期时间,由lua监控mysql及时更新即可.

刚开始写技术博客,有问题麻烦指教,不胜感激.当然排版啊  画图啥的 有愿意指导也可以,还不会 哈哈哈