redis相关东西总结

redis：
1、打开redis大内存设置：默认64位操作系统的服务器对内存没有限制，导致数据量大后内存数据溢出。不要让你的Redis所在机器物理内存使用超过实际内存总量的3/5
3、批量插入时使用jedis管道插入
4、尽量使用hash结构的内存数据，减少内存空间的使用
5、尽量使用较短的key存储
6、使用服务器端Lua脚本
7、缓存模式下，尽量为每块缓存设置时效性，避免冷数据长时间占用资源。
8、生产环境中尽量避免使用keys操作，由于redis是单线程模式，大量的keys操作会阻塞其他的命令执行。
9、设置合理的内存回收策略，保证内存可用性的同时能适当的提供缓存的命中率。基于时间过期淘汰机制或使用频率低的缓冲
10、不要开启seve，会阻塞当前redis服务器，可以开启bgsave，会创建一个fork子进程来备份。

Redis支持五种数据类型：string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合)。

Redis--各个数据类型最大存储量
Strings类型：一个String类型的value最大可以存储512M
Lists类型：list的元素个数最多为2^32-1个，也就是4294967295个。
Sets类型：元素个数最多为2^32-1个，也就是4294967295个。
Hashes类型：键值对个数最多为2^32-1个，也就是4294967295个。
Sorted sets类型：跟Sets类型相似。

redis特点：不会有两条命令被同时执行，不会产生并发问题，这就是Redis的单线程基本模型。

redis的缓存机制：Redis是一种高级key-value数据库，Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”)；
                也可以把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)。
redis持久化配置：RDB和AOF两种持久化方式。RDB用来备份，但是bgsave，一个时间，一个是key的变化数量。bgsave是Fork会拷贝父进程的所有状态，包括已分配的内存：
                 aof是有三种情况，每秒同步、每次修改同步、不同步。修改参数appendof 位yes
                
                
./redis-cli --raw -h 192.168.11.129 -a master  打开客户端的方式                
                
                
4、常用配置
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          #从不同步。高效但是数据不会被持久化。

5、redis的使用方式：4种
                （1）单节点实例，就是一台服务器就只有一台redis，这个配置简单。线上环境不可能使用这种，这种只能在开发和测试环境里面搞。
                （2）主从模式：master节点可以进行读和写，slave节点只能进行读操作，写操作被禁止
                               不要修改配置让slave节点支持写操作，没有意义，原因一，写入的数据不会被同步到其他节点；原因二，当master节点修改同一条数据后，slave节点的数据会被覆盖掉
                               slave节点挂了不影响其他slave节点的读和master节点的读和写，重新启动后会将数据从master节点同步过来
                               master节点挂了以后，不影响slave节点的读，Redis将不再提供写服务，master节点启动后Redis将重新对外提供写服务。
                               master节点挂了以后，不会slave节点重新选一个master
                            （1）（bb这一堆，就是主负责读写，从只会读，就算添加写的功能也是白给，也会被主覆盖，然后主从谁挂了都不会影响服务器，但是主挂了会让数据不能写，当重新连接后又会自动加入进去）
                            （2）客户端访问master需要密码
                                启动slave需要密码，在配置中进行配置即可
                                客户端访问slave不需要密码    
                            （3）redis的主从已经搭建好了，测试了一下，主可以读写，从只能读。
                            缺点就是主挂了之后，就会导致整个服务不能写入了，线上环境可不能这样搞，实用性不大。
                            搭建方式：最主要的就是在从的服务器的配置文件里面添加：slaveof  主ip 主端口  
                                                                                  若是主有密码的话：还需要在从配置文件里面：masterauth  主的密码
                （3）（sentinel）守卫模式：守卫模式是建立在主从模式基础上，当sentinel发现master节点挂了以后，sentinel就会从slave中重新选举一个master。
                                           sentinel系统可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；当某个master服务下线时，
                                           自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。
                                           所以sentinel就不能部署在master上面，不然master服务器挂了，sentinel也挂了。但是可以在每个redis服务器里面都启动一个sentinel，这样就完美了。
                                           Redis主从结构支持一主多从+n个sentinel模式
                                           
                                           搭建方式：redis的文件夹里面有个sentinel.conf的文件，如果没有就重新创建一个，redis先启动。
                                                     sentinel的配置文件里面全部填写的是redis主服务器里面的东西，之所以能监听所有的主从，就是因为上一种主从模式就把主从关系定好了。（最后有配置文件大致内容）
                                            
                                            启动命令：./redis-server ../sentinel.conf --sentinel    这就是后台运行了。
                                            
                                            所以sentinel是包含在redis里面的，挺好的，很方便。
                                            
                                            这种模式也存在一个缺陷，那就是服务器的压力大，若是数据太多，太占内存以及硬盘了，所以下一种模式就出来了，集群。
                                            
                                            
                                            
                                            sentinel monitor <masterName> <ip> <port> <quorum>
                                            四个参数含义：
                                            masterName这个是对某个master+slave组合的一个区分标识（一套sentinel是可以监听多套master+slave这样的组合的）。
                                            ip 和 port 就是master节点的 ip 和 端口号。
                                            quorum这个参数是进行客观下线的一个依据，意思是至少有 quorum 个sentinel主观的认为这个master有故障，才会对这个master进行下线以及故障转移。
                                            因为有的时候，某个sentinel节点可能因为自身网络原因，导致无法连接master，而此时master并没有出现故障，所以这就需要多个sentinel都一致认为该master有问题，
                                            才可以进行下一步操作，这就保证了公平性和高可用。
                                            2）sentinel down-after-milliseconds <masterName> <timeout> 
                                            这个配置其实就是进行主观下线的一个依据，masterName这个参数不用说了，timeout是一个毫秒值，表示：
                                            如果这台sentinel超过timeout这个时间都无法连通master包括slave（slave不需要客观下线，因为不需要故障转移）的话，
                                            就会主观认为该master已经下线（实际下线需要客观下线的判断通过才会下线）
                                            那么，多个sentinel之间是如何达到共识的呢？
                                            这就是依赖于前面说的第二个定时任务，某个sentinel先将master节点进行一个主观下线，
                                            然后会将这个判定通过sentinel is-master-down-by-addr这个命令问对应的节点是否也同样认为该addr的master节点要做客观下线。
                                            最后当达成这一共识的sentinel个数达到前面说的quorum设置的这个值时，就会对该master节点下线进行故障转移。
                                            quorum的值一般设置为sentinel个数的二分之一加1，例如3个sentinel就设置2。
                                           
                （4）（cluster）集群模式：cluster可以说是sentinel和主从模式的结合体，通过cluster可以实现主从和master重选功能，所以如果配置两个副本三个分片的话，就需要六个Redis实例。
                                          因为Redis的数据是根据一定规则分配到cluster的不同机器的，当数据量过大时，可以新增机器进行扩容
                                          这种模式适合数据量巨大的缓存要求，当数据量不是很大使用sentinel即可
 

     //这里全是主服务器的东西，redisMaster自定义的，我定义的就是mymaster，只要保证后面都一样，每个sentinel里面的配置文件基本上一致的。            
    //后台启动，这个一定要配置            
sentinel的配置文件大致内容：
port 26379
pidfile "/usr/local/redis/var/redis-sentinel.pid"
dir "/usr/local/redis/data/sentinel"    
daemonize yes    
protected-mode no   
logfile "/usr/local/redis/var/redis-sentinel.log"   
sentinel myid e1505ffc65f787871febfde2f27b762f70cddd71
sentinel monitor redisMaster 192.168.10.202 6379 2  
sentinel down-after-milliseconds redisMaster 10000
sentinel failover-timeout redisMaster 60000