北方有缓存 绝世而独立
一顾倾人城 再顾倾人国
没错我讲的这位美人就是 redis。一旦拥有爱不释手。那不如让我们一起掀起他的盖头来吧。
第一回鉴必穷源 看看官方怎么自我定位的
Redis is an open source (BSD licensed), in-memory data structure store, used as a database, cache and message broker.
Redis 是一个开源（BSD许可）的，内存中的数据结构存储系统，它可以用作数据库、缓存和消息中间件。
关键字:内存 数据结构 数据库 缓存 消息中间价 一句话透露了很多信息,有这是一个什么样的美人(基于内存的数据结构)，才艺是啥（数据库，缓存 消息中间件）
人生只如初见
- 基本数据类型: string (字符串)、list (列表)、set (集合)、hash (哈希) 和 zset (有序集合).
- 底层实现
轻拢慢拈抹复挑
-
持久方案：rdb aof Redis 的持久化机制有两种，第一种是快照，第二种是 命令日志。快照是一次全量备份，AOF日志是连续的增量备份。快照是内存数据二进制序列化形式，在存储上非常紧凑，而AOF日志记录的是内存数据修改的指令记录文本。AOF 日志在长期的运行过程中会变的无比庞大，数据库重启时需要加载 AOF 日志进行指令重放，这个时间就会无比漫长。所以Redi会对AOF文件重写，给 AOF 日志进行瘦身。
-
事务:acid 原子性：事物具有原子性是指数据库将事物中的多个操作当作一个整体来执行，服务器要么一个不执行，要么全部执行。redis把多个命令打包成一个可以保证原子性。 一致性：一致性是指事物在执行前是一致的，那么在事物执行后数据库也是一致的。 隔离性：隔离性是指事物在执行过程中不会被其他事物影响。因为redis执行命令是串行 所以隔离性是可以保证的。 持久性:这个根据所在的持久化模式息息相关，当运行在rdb模式时因为只有特定条件才会触发。所以不具有持久性，在aof模式下当apendfsync为always时才具有耐久性。 注意:redis的作者在官方文档中解释不支持事物会滚的是因为复杂的功能和redis追求简单高效的设计主旨不相符。并且他认为redis执行错误通常都是编程导致的。这种错误很少在实际的生产环境出现。
-
主从复制:
-
删除策略:
1、定时删除 定时删除策略对内存是最友好的：通过使用定时器，定时删除策略可以保证过期键会尽可能快地被删除，并释放过期键所占用的内存 定时删除策略的缺点是，它对CPU时间是最不友好的：在过期键比较多的情况下，删除过期键这一行为可能会占用相当一部分CPU时间 创建一个定时器需要用到Redis服务器中的时间事件，而当前时间事件的实现方式——无序列表，查找一个事件的时间复杂度为O(N)——并不能高效地处理大量时间事件
2、惰性删除 惰性删除策略对CPU时间来说是最友好的：程序只会在取出键时才对键进行过期检查，这可以保证删除过期键的操作只会在非做不可的情况下进行，并且删除的目标仅限于当前处理的键，这个策略不会再删除其他无关的过期键上花费任何CPU时间 惰性删除策略的缺点是，它对内存是最不友好的：如果一个键已经过期，而这个键又仍然保留在数据库中，那么只要这个过期键不被删除，它所占用的内存就不会释放
3、定期删除 定期删除策略是前两种策略的一种整合和折中： 定期删除策略每隔一段时间执行一次删除过期键操作，并通过限制删除操作执行的时长和频率来减少删除操作对CPU时间的影响 通过定期删除过期键，定期删除策略有效地减少了因为过期键而带来的内存浪费 定期删除策略的难点是确定删除操作执行的时长和频率：
Redis服务器实际使用的是惰性删除和定期删除两种策略：通过配合使用这两种策略，服务器可以很好地在合理使用CPU时间和避免浪费内存空间之间取得平衡 如果删除操作执行得太频繁，或者执行的时间太长，定期删除策略就会退化成定时删除策略，以至于将CPU时间过多地消耗在删除过期键上面 如果删除操作执行得太少，或者执行的时间太短，定期删除策略又会和惰性删除策略一样，出现浪费内存的情况
