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

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

并作修改：

主服务器的端口使用的是缺省的 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 相关的参数，缺省如下：

在主服务器上，我们可以去掉上面的设置，改成类似下面的设置（只要参数值够大即可）：

save 10000000000 10000000000

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

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

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

利用主从服务器备份

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

redis-cli saveredis-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.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 也支持 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——有序集合