redisredis

    分布式缓存为什么采用redis？

    • 开发活跃。社区非常成熟，包括StackOverflow/暴雪/新浪微博/Flickr等公司广泛使用。

    • 高性能：100k+TPS。

    • 功能丰富。K/V存储的Value不仅仅支持string，还支持list、hash、set、sorted set。大量的原子操作。基本涵盖了memcached的功能。

    • 支持经典的Master/Slave高可用部署架构，支持缓存内容的持久化。

    redis有哪些数据类型？

    string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合)。

    string:

    string 是 redis 最基本的类型，你可以理解成与 Memcached 一模一样的类型，一个 key 对应一个 value。

    string 类型是二进制安全的。意思是 redis 的 string 可以包含任何数据。比如jpg图片或者序列化的对象。

    string 类型是 Redis 最基本的数据类型，string 类型的值最大能存储 512MB

    hash:

    Redis hash 是一个键值(key=>value)对集合。

    Redis hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象。

    list:

    Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。

    set:

    Redis 的 Set 是 string 类型的无序集合。

    集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。

    zset:

    Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。

    不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。

    zset的成员是唯一的,但分数(score)却可以重复。

    redis有几种数据过期策略?

    • 被动删除:当读/写 一个过期的key时，会触发惰性删除策略，直接删除这个key

    • 主动删除由于惰性策略无法保证冷数据已经被删除，所以redis会定期主动删除一些已过期的key，或者当内存达到为redis服务器设置的最大内存的时候，会主动的删除一些数据（触发数据淘汰策略）

    redis内存淘汰策略

    其实当内存占用过多的时候，此时会进行内存淘汰，redis提供了如下策略：

    • noeviction：当内存不足以容纳新写入数据时，新写入数据会报错。

    • allkeys-lru：当内存不足以容纳新写入数据时，会移除最近最少使用的key。

    • allkeys-random：当内存不足以容纳新写入数据时，会随机移除某个key。

    • volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。

    • volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。

    • volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。

    以上几个策略最常用的应该是allkeys-lru，其实这个也要根据业务场景去选择

    redis的持久化机制

    AOF 介绍：https://redisbook.readthedocs.io/en/latest/internal/aof.html

    RDB 介绍：https://redisbook.readthedocs.io/en/latest/internal/rdb.html

    • RDB和AOF机制

    RDB持久化机制原理是对redis中的数据执行者周期性的持久化，是redis默认的持久化机制，他的默认持久化策略是如果在900S之内执行了一次数据变更操作，或者在300S内执行了10次，再或者在60s执行了10000次，那么在这个900S、300S、60S将会生成一个redis数据快照文件。

    AOF持久化机制对每条redis的写入指令都会做一条日志，以append-only的模式写入一个日志文件中，在redis重启的时候会回放日志文件中的指令来重新构建数据，它默认会每秒保存一个文件。

    如果同时启用了RDB和AOF的话，redis会使用AOF来恢复数据，因为AOF的数据会更加完整。

    在我们实际生产使用中，可以定期把RDB和AOF做备份到云服务器来做灾难恢复，数据恢复。

    • RDB的优缺点

    RDB机制有几个优点，首先它会生成多个数据文件，每个文件都代表某个时刻redis中的数据快照，这种文件非常适合我们做冷备，可以定期把这种文件推送到云服务做存储来应对灾难恢复；其次，RDB对redis对外提供的读写服务影响比较小，可以让redis保持高性能，因为redis只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化；而且由于RDB是基于数据文件恢复的，所以说相对于AOF来说更加快速。

    RDB的缺点在于2个方面，首先在redis故障的时候，RDB由于它是定期去数据快照，所以说可能会丢失一部分数据；其次RDB每次在fork子进程来生成快照文件的时候，如果数据文件特别大，可能会导致对客户端提供服务暂停数毫秒，甚至数秒。

    • AOF机制的优缺点

    AOF机制的优点：

    1.AOF可以更好的避免数据丢失问题，默认AOF每隔1S，通过后台线程执行一次fsync操作，它最多丢失1S的数据。2.AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能比较高，而且文件不容易受损坏，redis也提供了修复受损坏AOF文件的方式，很容易修复。3.AOF日志文件可读性比较高，可以追踪误操作记录（如flush all），来删除这个日志记录进行紧急恢复。

    AOF机制的缺点：

    1.对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大。2.AOF开启之后，支持的写QPS会比RDB支持的写QPS低，因为默认AOF会每秒去fsync一次日志。

    • RDB和AOF该如何选择？

    其实我们应该两者一起使用的，用AOF来保证尽可能的不丢失数据，作为数据恢复的第一选择，利用RDB来做冷备，当AOF丢失或者不可用的时候来使用RDB快照来快速回复。如果单一选择RDB的话对比AOF可能会丢失部分数据，选择AOF的换又没有RDB回复的速度快而且AOF的备份很复杂。