redis整理

Redis

Redis 是一个 key-value 存储系统。

Redis支持五种数据类型:

string
list
hash
set
zset

memcached 类似, redis 支持的数据类型更丰富、数据能持久化。

memcached 把数据全部存储在内存中,断电后会挂掉,数据不能超过内存大小。

而redis`数据会定期备份到硬盘上。

落地策略

  • RDB 持久化( snapshotting ):快照,整体备份。在指定的时间间隔内将内存中的数据集快照写入磁盘,实际上是 fork 一个子线程,先将数据集写入临时文件,写入成功后,再替换之前的文件,用二进制压缩存储。
  • AOF 持久化( append-only-file ):以日志的形式记录服务器所处理的每一个写、删除操作,查询操作不会记录,以文本的方式记录,可以打开文件看到详细的操作记录。

过期策略

  • 定期删除: redis 会把设置了过期时间的 key 放在单独的字典中,定时遍历来删除到期的 key
    key
    key
    
  • 惰性删除
    • 过期的 key 并不一定会马上删除,还会占用着内存。当你真正查询这个 key 时, redis 会检查一下,这个设置了过期时间的 key 是否过期了,如果过期了就会删除,返回空。
  • 内存淘汰机制
    redis 内存超出物理内存限制时,会和磁盘产生 swap ,这种情况性能极差,一般是不允许的。
    (1) noeviction :拒绝写操作,读、删除可以正常使用。默认策略
    (2) allkeys-lru :移除最近最少使用的 key ,最常用的策略
    (3) allkeys-random :随机删除某个 key
    (4) volatile-lru :在设置了过期时间的 key 中,移除最近最少使用的 key
    (5) volatile-random :在设置了过期时间的 key 中,随机删除某个 key
    (6) volatile-ttl :在设置了过期时间的 key 中,把最早要过期的 key 优先删除

Redis 缓存和 MySQL 数据一致性方案

在高并发的业务场景下,数据库大多数情况都是用户并发访问最薄弱的环节。所以,就需要使用 redis 做一个缓冲操作,让请求先访问到 redis ,而不是直接访问 MySQL 数据库

请求先访问 redis 缓存,如果缓存中有数据,直接加载数据,如果缓存中没有数据,再访问数据库,数据库会将数据放入 redis 中,然后加载数据。

读取缓存一般没有什么问题,但是一旦涉及到数据更新:数据库和缓存更新,就容易出现缓存 redis 和数据库 MySQL 间的数据一致性问题。

  • 如果先删除了缓存 Redis ,还没有来得及写库 MySQL ,另一个线程就来读取,发现缓存为空,则去数据库中读取数据写入缓存,此时缓存中没脏数据。
  • 如果先写了库,在删除缓存之前,写库的线程宕机了,没有删除掉缓存,则也会出现数据不一致情况。

因为写和读是并发的,没法保证顺序,就会出现缓存和数据库的数据不一致的问题。

解决方案:异步更新缓存(基于订阅 binlog 的同步机制)

MySQLbinlog 增量订阅消费+消息队列+增量数据 更新到 redis

(1)读 redis :热数据基本都在 redis
(2)写 MySQL :增删改都是操作 MySQL

(3)更新 redis 数据: MySQL 的数据操作 binlog ,来更新到 redis

注意: MySQL 实现主从一致性,也是基于订阅 binlog 来实现增量操作。

binlog :是 MySQL 的二进制文件,用于记录 MySQL 的数据更新( insertupdatedelete 操作)。

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章