今天突然想起来这个,就是那么突然,上次项目上用过redis,是一个消息已读未读的问题,由于消息挺多的,如果每次都去查数据库,那岂不是裂开,所以就存缓存了。
现在想想,还是不大行,我看表里已经十万数据了,而且都不怎么用,如果火力全开,可能一天就得1w+的数据。
所以,我认为,更具不同的区域进行分表,然后在存入redis,通过不同的区域key。(没有什么事情是加一层解决不了的,如果有,就再加一层!)
回归正题哈,扯了一会淡(反正也就我自己复习的时候看看博客,无所吊谓!)
既然是同步redis和数据库(以下以修改数据为例子),就有两个情况:
到底是先修改数据库,还是先改redis
我认为,不管是先更新哪一个,都会出现问题(没加锁前提下):
先更新数据库会出现:数据库刚更新完,还没更新redis,就有访问,导致取redis的旧数据。
先更新redis会出现:redis更新成功,一个线程在更新数据库之前去到了redis拿去用了,可是,更新数据库时报错了!这个数据就是错数据,玩球了!
延迟双删:
调用修改接口时,删除缓存一次,之后再修改数据,然后延迟几秒后再删除缓存。
所以,直接加锁,(性能降低一些,保证数据安全性),只要我的两个操作没有完,就不能访问。
还可以用版本号(乐观锁)来解决,redis和数据库两边的版本号是否相同,一旦不相同就不读取还在更新redis缓存。
另外一种就是利用消息队列来解决也就是成了异步更新,一旦更新数据库成功,就向消息队列中发送一条更新消息,消费者拿到后进行更新redis,如果失败就重试。