redis启动：
直接 redis-server.exe 启动服务，是按照redis默认配置启动的,如果想按照自己的配置文件启动，要加上 redis-server.exe redis.windows.config
一、redis读写键空间时的维护操作
在读取一个键后（读和写操作都要对键进行读取），服务器会根据键是否存在更新键空间命中（hit）和不命中（miss）次数。
在读取一个键后，服务器会更新键的LRU时间（最后一次使用时间），这个可以用来计算键的闲置时间。
在读取一个键时发现键已过期，则会先删除这个过期键，再执行余下操作。
若使用WATCH监视了某个键，服务器在对被监视键修改后，会将这个键标记为脏。
服务器每次修改一个键之后，都会对脏键计数器的值增1，这个计数器会触发服务器的持久化以及复制操作
如果服务器开启了数据库通知功能，那么在对键修改之后，服务器将按配置发送相应的数据库的通知
二、键的生存时间功能及删除策略
redisDb结构中的字典expires，保存了所有设置了超时时间的键。字典expires中的每个键值对，键与redisDb中的dict共享，值记录了该键的生存时间，生存时间都是以一个以毫秒表示的Unix时间戳进行保存的。
删除一个过期的键，一共有三种策略，它们分别是：
a、定时删除：在设置键的过期时间的同时，创建一个定时器，该定时器在键的过期时间来临时，立即执行对键的删除操作。
b、惰性删除：放任键过期不管，每次从键空间中访问键时，都检查该键是否过期，如果过期的话，则删除该键。
c、定期删除：每隔一段时间，程序就对数据库进行一次检查，删除其中的过期键。至 于要删除多少过期键，以及要检查多少个数据库，则由算法决定。
Redis服务器实际使用的是惰性删除和定期删除两种策略，通过配合使用这两种删除策略，服务器可以很好地在合理使用CPU时间和避免浪费内存空间之间取得平衡。
AOF、RDB和复制功能对过期键的处理：
a：RDB功能处理过期键的策略如下：
执行SAVE命令或BGSAVE命令创建一个新的RDB文件时，程序会对数据库中的键进行检查，已过期的键不会被保存到新的RDB文件中；
如果服务器开启了RDB功能，那么启动Redis服务器时，将会载入RDB文件。
如果服务器以主服务器模式运行，则在载人RDB文件时，程序会对文件中保存的键进行检查，过期键则会被忽略而不被载入；
如果服务器以从服务器模式运行，则在载人RDB文件时，文件中保存的所有键，不论是否过期，都会被载人到数据库中。
不过，因为主从服务器在进行数据同步时，从服务器的数据库就会被清空，所以一般来讲，过期键对载人RDB文件的从服务器不会造成影响。
b：AOF功能处理过期键的策略如下：
当服务器以AOF持久化模式运行时，如果数据库中的某个键已经过期，但它还没有被惰性删除或定期删除，则AOF文件不会因为这个过期键而产生任何影响；
当过期键被惰性删除或定期删除之后，程序会向AOF文件追加一条DEL命令，显式地记录该键已被删除。这是通过propagateExpire函数实现的，而该函数会在expireIfNeeded中被调用。
在执行AOF重写的过程中，程序会对数据库中的键进行检查，已过期的键不会被保存到重写后的AOF文件中。
c：复制功能处理过期键的策略如下：
当服务器运行在复制模式下时，从服务器的过期键删除动作由主服务器控制：
主服务器在删除一个过期键之后，会显式地向所有从服务器发送一个DEL命令，告知从服务器删除这个过期键。这是通过propagateExpire函数实现的，而该函数会在expireIfNeeded中被调用。
从服务器在执行客户端发送的读命令时，即使碰到过期键也不会将过期键删除，而是继续像处理未过期的键一样来处理过期键。
从服务器只有在接到主服务器发来的DEL命令之后，才会删除过期键。
通过由主服务器来控制从服务器统一地删除过期键，可以保证主从服务器数据的一致性。
三、RDB持久化
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。
有两个命令可以用于生成RDB文件：
- SAVE:会阻塞redis服务器进程
- BGSAVE:派生出一个子进程，父进程可以继续处理命令请求
RDB文件地载入是在服务器启动时自动执行的，所以没有专门的用于载入RDB文件的命令。
RDB文件是一个经过压缩的二进制的文件。
服务器保存所有用save选项设置的保存条件，当任意一个条件满足时，自动执行BGSAVE命令。
因为AOF文件的更新频率通常比RDB文件的更新频率高，所以如果服务器开启了AOF持久化功能，则会优先使用AOF文件来还原数据库状态
四、AOF持久化
AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。
与RDB持久化通过保存数据库中的键值对来记录数据库状态不同，AOF持久化是通过保存Redis服务器所执行的写命令来记录数据库状态的。
与RDB持久化相比，AOF持久化可能丢失的数据更少，但是AOF持久化可能会降低Redis的性能。
写人AOF文件的所有命令都是以Redis的统一请求协议格式保存的。
AOF持久化功能的实现可以分为命令追加、文件写入、文件同步(sync)三个步骤。
- 命令请求会先保存到AOF缓冲区里面，之后再定期写入并同步到AOF文件
- appendfsync选项的值对AOF持久化功能的安全性以及服务器性能有很大的影响
appendfsync: always #每次有数据修改发生时都会写入AOF文件。
appendfsync: everysec #每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync: no #从不同步。高效但是数据不会被持久化。
加载AOF文件：
Redis服务器启动时，如果AOF功能开启的话，则需要根据AOF文件的内容恢复到数据中。
Redis加载AOF文件的方式非常巧妙，因为AOF中记录的是统一请求协议格式的客户端命令，因此Redis创建一个不带网络连接的伪客户端，通过伪客户端逐条执行AOF中的命令来恢复数据。
AOF重写可以产生一个新的AOF文件，这个新的AOF文件和原有的AOF文件所保存的数据库状态一样，但体积更小。
五、两种持久化方式对比
RDB优点：
- RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑
- RDB 可以最大化 Redis 的性能
- RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快
RDB缺点：
- 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
- 由于RDB是通过fork子进程来协助完成数据持久化工作的， 在数据集比较庞大时， fork()可能会非常耗时，造成服务器在某某毫秒内停止处理客户端。
AOF 优点：
- 使用 AOF 持久化会让 Redis 变得非常耐久（much more durable）：你可以设置不同的 fsync 策略，比如无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）。
- 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题
- Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写
- AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建
AOF缺点：
- 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
- 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB
- AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。 （举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug 。） 测试套件里为这种情况添加了测试： 它们会自动生成随机的、复杂的数据集， 并通过重新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见， 但是对比来说， RDB 几乎是不可能出现这种 bug 的
六、事件驱动机制
pass
七、安全处理：
(1) 限制Redis的访问IP，如指定本地IP获指定特定IP可以访问。
(2) 如果是本地访问和使用，打开防火墙，不开放Redis端口，最好修改掉Redis的默认端口；
(3) 如果要远程访问，给Redis配置上授权访问密码；