非关系型数据库Redis核心内容

2年前 (2022) 程序员胖胖胖虎阿
366 0 0

redis和memcache的区别;

1 . Redis中,并不是所有的数据都一直存储在内存中的,这是和Memcached相比一个最大的区别。

2 . redis不仅仅支持简单的k/v类型的数据,同时还提供list,set,hash等数据结构的存储。

3 . Redis支持数据的备份,即master-slave模式的数据备份。

4 . Redis支持数据的持久化,可以将内存中的数据保持在磁盘中,重启的时候可以再次加载进行使用。

Redis在很多方面具备数据库的特征,或者说就是一个数据库系统,而Memcached只是简单的K/V缓存

用redis做过什么;

缓存,做key-value型数据库

redis是如何持久化的:rdb和aof;

RDB持久化配置

Redis会将数据集的快照dump到dump.rdb文件中。此外,我们也可以通过配置文件来修改Redis服务器dump快照的频率,在打开6379.conf文件之后,我们搜索save,可以看到下面的配置信息:

save 900 1 #在900秒(15分钟)之后,如果至少有1个key发生变化,则dump内存快照。

save 300 10 #在300秒(5分钟)之后,如果至少有10个key发生变化,则dump内存快照。

save 60 10000 #在60秒(1分钟)之后,如果至少有10000个key发生变化,则dump内存快照。

AOF持久化配置

在Redis的配置文件中存在三种同步方式,它们分别是:

appendfsync always #每次有数据修改发生时都会写入AOF文件。

appendfsync everysec #每秒钟同步一次,该策略为AOF的缺省策略。

appendfsync no #从不同步。高效但是数据不会被持久化。

redis集群如何同步

配置主从服务器

Redis主从服务器的搭建很简单,只要少许配置即可,为了演示的方便,我们就在一台服务器上配置:
前提是你已经有了一台redis服务器

下面看看如何配置从服务器:

假设主服务器的配置文件是:/etc/redis.conf,我们复制一份作为从服务器的配置文件:

cp /etc/redis.conf /etc/redis_slave.conf

并作修改:

非关系型数据库Redis核心内容

主服务器的端口使用的是缺省的6379,从服务器的端口我们设置成6380。

然后插入一些测试数据:

redis-benchmark

由于我们没有设定任何参数,所以使用的是缺省端口(6379),在本例中就是主服务器。

然后启动从服务器:

redis-server /etc/redis_slave.conf

确认一下是否都正常启动了:

ps -ef | grep redis

进入数据目录,查一下数据文件的散列:

md5sum *.rdb

你会发现数据文件散列都一样,自动同步了。

然后我们关闭一下从服务器(不关也行,我就是为了告诉你如何正确关闭redis服务器):

redis-cli -p 6380 shutdown

接着再往主服务器上写入测试数据:

redis-benchmark -l

这会循环插入测试数据,数据量的大小取决于时间的长短,你可以在适当的时候按ctrl+c停止。

如果从服务器没有启动的话,接着再重新启动从服务器:

redis-server /etc/redis_slave.conf

通过观察文件大小你会发现数据会自动同步,如果没有重启动从服务器,那么数据文件的md5sum散列值可能不同,这是正常的,不要紧。

在操作过程中,有时候你会发现主从服务器的数据文件大小不一样,一般来说也不是问题,因为redis是异步写入磁盘的,此时可能有部分数据还在内存中,没有同步到磁盘,所以文件大小略显不同,可以分别在主从服务器上执行:

redis-cli save(redis-cli -p 6380 save)

这条命令强制同步到磁盘,再看大小就应该一样了。

配置文件redis.conf里有一部分和save相关的参数,缺省如下:
非关系型数据库Redis核心内容

在主服务器上,我们可以去掉上面的设置,改成类似下面的设置(只要参数值够大即可):

save 10000000000 10000000000

如此一来主服务器变成一个完全的内存服务器,所有的操作都在内存里完成,“永远”不会再往磁盘上持久化保存数据,异步的也没有。持久化则通过从服务器来完 成,这样在操作主服务器的时候效率会更高。

不过要注意的一点是此方法不适合保存关键数据,否则一旦主服务器挂掉,如果你头脑一热简单的重启服务,那么从服 务器的数据也会跟着消失,此时,必须拷贝一份备份数据到主服务器,然后再重启服务才可以,数据的恢复稍显麻烦。

从服务器也可以通过设置这个参数来调整从内存同步到磁盘的频率。

利用主从服务器备份

可以利用主从服务器的方便性来备份,专门做一台从服务器用于备份功能,当需要备份的时候,在从服务器上执行下列命令:

redis-cli save
redis-cli shutdown

然后拷贝数据目录下的rdb文件即可

redis的数据添加过程是怎样的:哈希槽;

Redis 集群中内置了 16384 个哈希槽,当需要在 redis 集群中放置一个 key-value

时,redis 先对 key 使用 crc16 算法算出一个结果,然后把结果对 16384 求余数,

这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽,redis 会根据节点数量大

致均等的将哈希槽映射到不同的节点

redis的淘汰策略有哪些;

Redis内存淘汰指的是用户存储的一些键被可以被Redis主动地从实例中删除,从而产生读miss的情况,那么Redis为什么要有这种功能?这就是我们需要探究的设计初衷。Redis最常见的两种应用场景为缓存和持久存储,首先要明确的一个问题是内存淘汰策略更适合于那种场景?是持久存储还是缓存?

内存的淘汰机制的初衷是为了更好地使用内存,用一定的缓存miss来换取内存的使用效率。

作为Redis用户,我如何使用Redis提供的这个特性呢?看看下面配置

非关系型数据库Redis核心内容

我们可以通过配置redis.conf中的maxmemory这个值来开启内存淘汰功能,至于这个值有什么意义,我们可以通过了解内存淘汰的过程来理解它的意义:

1 . 客户端发起了需要申请更多内存的命令(如set)。

2 .Redis检查内存使用情况,如果已使用的内存大于maxmemory则开始根据用户配置的不同淘汰策略来淘汰内存(key),从而换取一定的内存。

3 .如果上面都没问题,则这个命令执行成功。

maxmemory为0的时候表示我们对Redis的内存使用没有限制。

Redis提供了下面几种淘汰策略供用户选择,其中默认的策略为noeviction策略:

· noeviction:当内存使用达到阈值的时候,所有引起申请内存的命令会报错。

· allkeys-lru:在主键空间中,优先移除最近未使用的key。

· volatile-lru:在设置了过期时间的键空间中,优先移除最近未使用的key。

· allkeys-random:在主键空间中,随机移除某个key。

· volatile-random:在设置了过期时间的键空间中,随机移除某个key。

· volatile-ttl:在设置了过期时间的键空间中,具有更早过期时间的key优先移除。

这里补充一下主键空间和设置了过期时间的键空间,举个例子,假设我们有一批键存储在Redis中,则有那么一个哈希表用于存储这批键及其值,如果这批键中有一部分设置了过期时间,那么这批键还会被存储到另外一个哈希表中,这个哈希表中的值对应的是键被设置的过期时间。设置了过期时间的键空间为主键空间的子集。

我们了解了Redis大概提供了这么几种淘汰策略,那么如何选择呢?淘汰策略的选择可以通过下面的配置指定:

非关系型数据库Redis核心内容

但是这个值填什么呢?为解决这个问题,我们需要了解我们的应用请求对于Redis中存储的数据集的访问方式以及我们的诉求是什么。同时Redis也支持Runtime修改淘汰策略,这使得我们不需要重启Redis实例而实时的调整内存淘汰策略。

下面看看几种策略的适用场景:

· allkeys-lru:如果我们的应用对缓存的访问符合幂律分布(也就是存在相对热点数据),或者我们不太清楚我们应用的缓存访问分布状况,我们可以选择allkeys-lru策略。

· allkeys-random:如果我们的应用对于缓存key的访问概率相等,则可以使用这个策略。

· volatile-ttl:这种策略使得我们可以向Redis提示哪些key更适合被eviction。

另外,volatile-lru策略和volatile-random策略适合我们将一个Redis实例既应用于缓存和又应用于持久化存储的时候,然而我们也可以通过使用两个Redis实例来达到相同的效果,值得一提的是将key设置过期时间实际上会消耗更多的内存,因此我们建议使用allkeys-lru策略从而更有效率的使用内存。

redis有哪些数据结构;

String——字符串
Hash——字典
List——列表
Set——集合
Sorted Set——有序集合

版权声明:程序员胖胖胖虎阿 发表于 2022年9月26日 上午8:08。
转载请注明:非关系型数据库Redis核心内容 | 胖虎的工具箱-编程导航

相关文章

暂无评论

暂无评论...