写在前面
本学习教程所有示例代码见GitHub：https://github.com/selfconzrr/Redis_Learning
使用配置文件启动服务器：src/redis-server redis.conf
主要配置项：Redis支持很多的参数，但都有默认值。
********************************* General ######################
默认情况下，redis不是在后台运行的，如果需要在后台运行，把该项的值更改为yes。
当Redis在后台运行的时候，Redis默认会把pid文件放在/var/run/redis.pid，你可以配置到其他地址。当运行多个redis服务时，需要指定不同的pid文件和端口。
指定Redis只接收来自于该IP地址的请求，如果不进行设置，那么将处理所有请求，在生产环境中最好设置该项。
监听端口，默认为6379。
设置客户端连接时的超时时间，单位为秒。当客户端在这段时间内没有发出任何指令，那么关闭该连接。
log等级分为4级，debug, verbose, notice和warning。生产环境下一般开启notice。
配置log文件地址，默认使用标准输出，即打印在命令行终端的窗口上。
设置数据库的个数，可以使用SELECT 命令来切换数据库。默认使用的数据库是0。
********************************* SnapShotting##################
设置Redis进行数据库快照的频率。
if(在60秒之内有10000个keys发生变化时){
进行镜像备份 save 60 1000
}else if(在300秒之内有10个keys发生了变化){
进行镜像备份 save 300 10
}else if(在900秒之内有1个keys发生了变化){
进行镜像备份 save 900 1
}
在进行镜像备份时，是否进行压缩。Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大
镜像备份文件的文件名，后缀为.rdb
数据库镜像备份的文件放置的路径。这里的路径跟文件名要分开配置是因为Redis在进行备份时，先会将当前数据库的状态写入到一个临时文件中，等备份完成时，再把该该临时文件替换为上面所指定的文件，而这里的临时文件和上面所配置的备份文件都会放在这个指定的路径当中。
********************************* Replication####################
设置该数据库为其他数据库的从数据库。slaveof
当主数据库连接需要密码验证时，在这里指定。
********************************* Security######################
设置客户端连接后进行任何其他指定前需要使用的密码。警告：因为redis速度相当快，所以在一台比较好的服务器下，一个外部的用户可以在一秒钟进行150K次的密码尝试，这意味着你需要指定非常非常强大的密码来防止暴力破解。
********************************* Limits########################
限制同时连接的客户数量。当连接数超过这个值时，redis将不再接收其他连接请求，客户端尝试连接时将收到error信息。
设置redis能够使用的最大内存。当内存满了的时候，如果还接收到set命令，redis将先尝试剔除设置过expire信息的key，而不管该key的过期时间还没有到达。在删除时，将按照过期时间进行删除，最早将要被过期的key将最先被删除。如果带有expire信息的key都删光了，那么将返回错误。这样，redis将不再接收写请求，只接收get请求。maxmemory的设置比较适合于把redis当作于类似memcached的缓存来使用。
********************************* Append Only Mode##############
默认情况下，redis会在后台异步的把数据库镜像备份到磁盘，但是该备份是非常耗时的，而且备份也不能很频繁，如果发生诸如拉闸限电、拔插头等状况，那么将造成比较大范围的数据丢失。所以redis提供了另外一种更加高效的数据库备份及灾难恢复方式。开启append only模式之后，redis会把所接收到的每一次写操作请求都追加到appendonly.aof文件中，当redis重新启动时，会从该文件恢复出之前的状态。但是这样会造成appendonly.aof文件过大，所以redis还支持了BGREWRITEAOF指令，对appendonly.aof进行重新整理。所以我推荐生产环境下的做法为关闭镜像，开启appendonly.aof，同时可以选择在访问较少的时间每天对appendonly.aof进行重写一次。
设置对appendonly.aof文件进行同步的频率。always表示每次有写操作都进行同步，everysec表示对写操作进行累积，每秒同步一次。这个需要根据实际业务场景进行配置。
********************************* Advanced Config##########################
是否开启虚拟内存支持，默认值为no。因为redis是一个内存数据库，而且当内存满的时候，无法接收新的写请求，所以在redis 2.0中，提供了虚拟内存的支持。但是需要注意的是，redis中，所有的key都会放在内存中，在内存不够时，只会把value值放入交换区。这样保证了虽然使用虚拟内存，但性能基本不受影响，同时，你需要注意的是你要把vm-max-memory设置到足够来放下你的所有的key。简单的介绍一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中。
设置虚拟内存的交换文件路径，不可多个Redis实例共享。
这里设置开启虚拟内存之后，redis将使用的最大物理内存的大小。默认为0，redis将把他所有的能放到交换文件的都放到交换文件中，以尽量少的使用物理内存。在生产环境下，需要根据实际情况设置该值，最好不要使用默认的0。
设置虚拟内存的页大小，如果你的value值比较大，比如说你要在value中放置博客、新闻之类的所有文章内容，就设大一点，如果要放置的都是很小的内容，那就设小一点，比如32或者64bytes。
设置交换文件的总的page数量，需要注意的是，page table信息会放在物理内存中，每8个page就会占据RAM中的1个byte。总的虚拟内存大小 = vm-page-size * vm-pages。
设置VM IO同时使用的线程数量。因为在进行内存交换时，对数据有编码和解码的过程，所以尽管IO设备在硬件上本不能支持很多的并发读写，但是还是如果你所保存的vlaue值比较大，将该值设大一些，还是能够提升性能的。
把小的输出缓存放在一起，以便能够在一个TCP packet中为客户端发送多个响应，具体原理和真实效果我不是很清楚。所以根据注释，你不是很确定的时候就设置成yes
| hash-max-zipmap-entries 64: |
| hash-max-zipmap-values 512: |
在redis 2.0中引入了hash数据结构。当hash中包含超过指定元素个数或者最大的元素超过临界时，hash将以一种特殊的编码方式(大大减少内存使用)来存储，这里可以设置这两个临界值。
开启之后，redis将在每100毫秒时使用1毫秒的CPU时间来对redis的hash表进行重新hash，可以降低内存的使用。当你的使用场景中有非常严格的实时性需要，不能够接受Redis时不时的对请求有2毫秒的延迟的话，把这项配置为no。如果没有这么严格的实时性要求，可以设置为yes，以便能够尽可能快的释放内存。
********************************* Redis Cluster#########################
如果配置yes则开启集群功能，此redis实例作为集群的一个节点，否则，它是一个普通的单一的redis实例。
| cluster-config-file nodes-6379.conf: |
虽然此配置的名字叫"集群配置文件"，但是此配置文件不能人工编辑，它是集群节点自动维护的文件，主要用于记录集群中有哪些节点、他们的状态以及一些持久化参数等，方便在重启时恢复这些状态。通常是在收到请求之后这个文件就会被更新。
| cluster-node-timeout 15000: |
这是集群中的节点能够失联的最大时间，超过这个时间，该节点就会被认为故障。如果主节点超过这个时间还是不可达，则用它的从节点将启动故障迁移，升级成主节点。注意，任何一个节点在这个时间之内如果还是没有连上大部分的主节点，则此节点将停止接收任何请求。一般设置为15秒即可。
| cluster-slave-validity-factor 10: |
如果设置成０，则无论从节点与主节点失联多久，从节点都会尝试升级成主节点。如果设置成正数，则cluster-node-timeout乘以cluster-slave-validity-factor得到的时间，是从节点与主节点失联后，此从节点数据有效的最长时间，超过这个时间，从节点不会启动故障迁移。假设cluster-node-timeout=5，cluster-slave-validity-factor=10，则如果从节点跟主节点失联超过50秒，此从节点不能成为主节点。注意，如果此参数配置为非0，将可能出现由于某主节点失联却没有从节点能顶上的情况，从而导致集群不能正常工作，在这种情况下，只有等到原来的主节点重新回归到集群，集群才恢复运作。
------至所有正在努力奋斗的程序猿们！加油！！
有码走遍天下 无码寸步难行
1024 - 梦想，永不止步!
爱编程 不爱Bug
爱加班 不爱黑眼圈
固执 但不偏执
疯狂 但不疯癫
生活里的菜鸟
工作中的大神
身怀宝藏，一心憧憬星辰大海
追求极致，目标始于高山之巅
一群怀揣好奇，梦想改变世界的孩子
一群追日逐浪，正在改变世界的极客
你们用最美的语言，诠释着科技的力量
你们用极速的创新，引领着时代的变迁
——乐于分享，共同进步，欢迎补充
——Any comments greatly appreciated
——诚心欢迎各位交流讨论！QQ:1138517609
——CSDN：https://blog.csdn.net/u011489043
——简书：https://www.jianshu.com/u/4968682d58d1
——GitHub：https://github.com/selfconzrr
