标签:用户 超出 产生 vol 允许 处理 一致性 打开文件 ati
Redis
Redis
是一个key-value
存储系统。
string
(字符串)list
(列表)hash
(hash表)set
(集合)zset
(有序集合)和memcached
类似,redis
支持的数据类型更丰富、数据能持久化。
memcached
把数据全部存储在内存中,断电后会挂掉,数据不能超过内存大小。
而redis`数据会定期备份到硬盘上。
落地策略
RDB
持久化(snapshotting
):快照,整体备份。在指定的时间间隔内将内存中的数据集快照写入磁盘,实际上是fork
一个子线程,先将数据集写入临时文件,写入成功后,再替换之前的文件,用二进制压缩存储。AOF
持久化(append-only-file
):以日志的形式记录服务器所处理的每一个写、删除操作,查询操作不会记录,以文本的方式记录,可以打开文件看到详细的操作记录。过期策略
redis
会把设置了过期时间的key
放在单独的字典中,定时遍历来删除到期的key
key
删除key
占比超过1/4,重复步骤1key
并不一定会马上删除,还会占用着内存。当你真正查询这个key
时,redis
会检查一下,这个设置了过期时间的key
是否过期了,如果过期了就会删除,返回空。redis
内存超出物理内存限制时,会和磁盘产生swap
,这种情况性能极差,一般是不允许的。noeviction
:拒绝写操作,读、删除可以正常使用。默认策略allkeys-lru
:移除最近最少使用的key
,最常用的策略allkeys-random
:随机删除某个key
volatile-lru
:在设置了过期时间的key
中,移除最近最少使用的key
volatile-random
:在设置了过期时间的key
中,随机删除某个key
volatile-ttl
:在设置了过期时间的key
中,把最早要过期的key
优先删除Redis
缓存和MySQL
数据一致性方案在高并发的业务场景下,数据库大多数情况都是用户并发访问最薄弱的环节。所以,就需要使用redis
做一个缓冲操作,让请求先访问到redis
,而不是直接访问MySQL
数据库
请求先访问redis
缓存,如果缓存中有数据,直接加载数据,如果缓存中没有数据,再访问数据库,数据库会将数据放入redis
中,然后加载数据。
读取缓存一般没有什么问题,但是一旦涉及到数据更新:数据库和缓存更新,就容易出现缓存redis
和数据库MySQL
间的数据一致性问题。
Redis
,还没有来得及写库MySQL
,另一个线程就来读取,发现缓存为空,则去数据库中读取数据写入缓存,此时缓存中没脏数据。因为写和读是并发的,没法保证顺序,就会出现缓存和数据库的数据不一致的问题。
解决方案:异步更新缓存(基于订阅binlog
的同步机制)
MySQL
的binlog
增量订阅消费+消息队列+增量数据 更新到redis
。
(1)读redis
:热数据基本都在redis
(2)写MySQL
:增删改都是操作MySQL
(3)更新redis
数据:MySQL
的数据操作binlog
,来更新到redis
注意:MySQL
实现主从一致性,也是基于订阅binlog
来实现增量操作。
binlog
:是MySQL
的二进制文件,用于记录MySQL
的数据更新(insert
、update
、delete
操作)。
标签:用户 超出 产生 vol 允许 处理 一致性 打开文件 ati
原文地址:https://www.cnblogs.com/jackw1/p/12581127.html