Redis简介,搭建,部署方式

it2024-01-29  68

文章内容出处

https://www.cnblogs.com/cyleon/p/10930997.html

https://blog.csdn.net/ahfywangqiang/article/details/86537421

redis简介

redis是一个key-value存储系统。和Memcached类似,它支持存储的value类型相对更多,包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash(哈希类型)。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作,而且这些操作都是原子性的。在此基础上,redis支持各种不同方式的排序。与memcached一样,为了保证效率,数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件,并且在此基础上实现了master-slave(主从)同步。

Redis 是一个高性能的key-value数据库。 redis的出现,很大程度补偿了memcached这类key/value存储的不足,在部 分场合可以对关系数据库起到很好的补充作用。它提供了Java,C/C++,C#,PHP,JavaScript,Perl,Object-C,Python,Ruby,Erlang等客户端,使用很方便。 [1] 

Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步,从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。存盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制,使得从数据库在任何地方同步树时,可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。

redis的官网地址,非常好记,是redis.io。(域名后缀io属于国家域名,是british Indian Ocean territory,即英属印度洋领地),Vmware在资助着redis项目的开发和维护

安装

安装参照如下链接

https://www.runoob.com/redis/redis-install.html

常用命令

[root@db1 ~]# redis-server /etc/redis.conf    # 指定配置文件起动服务 [root@db1 ~]# redis-cli shutdown # 关闭redis服务器 [root@db1 ~]# redis-cli -h 127.0.0.1 -p 6379 -a password # 连接指定的redis服务 

# 通用操作

> KEYS * # 查询所有的键的名字 > FLUSHALL # 清空所有的键 > SET name leon # 设置key值 > GET name # 获取key值 > EXISTS name # 查询key是否存在 > EXPIRE name 30 # 以秒为单位设定生存时间,PTTL以毫秒为单位 > TTL name # 以秒为单位查看生命周期剩余时间,PTTL是以毫秒为单位 > DEL name # 删除一个key > TYPE fans # 返回键所存储值的类型> RENAME fans myfans # 修改键的名字 # string类型 > INCR zan # 数值型整数,每次加1,若key不存在,设置key初始值为0,增加后结果为1 > DECR zan # 每次减1 > decrby zan 3 # 直接n个数字 > MSET name leon id 1 age 30 # 生成多个键值对 > MGET name id age # 获取多个键值 # hash类型(字典类型)类似于mysql的一种类型:hmset 表 列 值 列 值 ... > HMSET student id 1001 name leon age 33 gender M OK > HGETALL student 1) "id" 2) "1001" 3) "name" 4) "leon\x9d" 5) "age" 6) "33" 7) "gender" 8) "M" # list类型 127.0.0.1:6379> LPUSH mylist a b c 1 2 # 若key不存在,创建该键及与其关联的list,依次a b c 1 2,若list类型的key存在,则插入value中 (integer) 5 127.0.0.1:6379> LPUSHX mylist2 xx # 若key不存在,此命令无效,若key存在则插入value中 (integer) 0 127.0.0.1:6379> LINSERT mylist before a a1 # 在a的前面插入新元素a1 (integer) 6 127.0.0.1:6379> LINSERT mylist after c p1 # 在c的后面插入新元素p1 (integer) 7 127.0.0.1:6379> RPUSH mylist y z # 在链表尾部先插入z,在插入y (integer) 9 127.0.0.1:6379> RPUSHX mylist p2 # 若key存在,在尾部插入p2,若key不存在则无效 (integer) 10 127.0.0.1:6379> RPOPLPUSH mylist mylist2 # 将mylist的尾部无素弹出,再插入到mykey2的头部(原子性操作) "p2" 127.0.0.1:6379> del mylist2 # 删除已有的键 (integer) 1 # SET集合类 127.0.0.1:6379> SADD mr yuwen shuxue yingyu gaoshu (integer) 4 127.0.0.1:6379> SADD xs yingyu dili gaoshu jisuanji (integer) 4 127.0.0.1:6379> SUNION mr xs # mr和xs的并集 1) "gaoshu" 2) "shuxue" 3) "jisuanji" 4) "dili" 5) "yingyu" 6) "yuwen" 127.0.0.1:6379> SINTER mr xs # mr的xs的交集 1) "gaoshu" 2) "yingyu" 127.0.0.1:6379> SDIFF mr xs # mr和xs的差集 1) "shuxue" 2) "yuwen" # sortedset(有序集合)排行榜应用场景,取TOP N操作 127.0.0.1:6379> ZADD music 0 xxy 0 jmjmjh 0 xhn 0 qys (integer) 4 127.0.0.1:6379> ZINCRBY music 999 xxy "999" 127.0.0.1:6379> ZINCRBY music 888 jmjmjh "888" 127.0.0.1:6379> ZINCRBY music 777 xhn "777" 127.0.0.1:6379> ZINCRBY music 500 qys "500" 127.0.0.1:6379> ZREVRANGE music 0 -1 1) "xxy" 2) "jmjmjh" 3) "xhn" 4) "qys" 127.0.0.1:6379> ZREVRANGE music 0 -1 withscores 1) "xxy" 2) "999" 3) "jmjmjh" 4) "888" 5) "xhn" 6) "777" 7) "qys" 8) "500" # 生产者/消费者模型,发布订阅,不能进行消息堆积 127.0.0.1:6379> SUBSCRIBE fm1024 # 订阅一个管道fm1024 127.0.0.1:6379> PUBLISH fm1024 yimiyangguang # 向1024管道发送内容

 

配置文件redis.conf

#slaveof 127.0.0.1 6379 ################################################################ ###################网络(NETWORK)################ ############################################################## #指定redis只能接受来自此IP绑定的网卡的请求,注意此默认值默认外网是不可访问的 #bind 127.0.0.1 #是否开启保护模式。如果没有指定bind和密码,redis只会本地进行访问,拒绝外部访问。 protected-mode yes #默认端口,建议生产环境不要使用默认端口避免被恶意扫描到 port 6379 #TCP连接中已完成队列(完成三次握手之后)的长度 #backlog其实是一个连接队列,backlog队列总和=未完成三次握手队列 + 已完成三次握手队列。 #在高并发环境下你需要一个高backlog值来避免慢客户端连接问题。 tcp-backlog 511 #客户端连接空闲超过timeout将会被断开,为0则断开(0表示不断,一直连着) timeout 0 #tcp keepalive参数 #单位为秒,如果设置为0,则不会进行keepalive检测,建议设置成60 tcp-keepalive 300 ################################################################ ###################基本配置(GENERAL)################ ############################################################## #是否后台启动 daemonize yes #可以通过upstart和systemd管理Redis守护进程 #选项: #supervised no - 没有监督互动 #supervised upstart - 通过将Redis置于SIGSTOP模式来启动信号 #supervised systemd - signal systemd将READY = 1写入$ NOTIFY_SOCKET #supervised auto - 检测upstart或systemd方法基于 UPSTART_JOB或NOTIFY_SOCKET环境变量 supervised no #配置PID文件路径 pidfile "/var/run/redis_6379.pid" #日志级别 #参数: # debug # verbose # notice # warning loglevel notice #日志文件路径 logfile "/home/redis-5.0.5/bin/redis-server.log" #数据库的数量,默认使用的数据库是DB 0 #可以通过”SELECT “命令选择一个db #集群环境默认只有DB 0 databases 16 #是否一直显示logo always-show-logo yes ################################################################ ###################数据持久化RDB(SNAPSHOTTING)################ ############################################################## #保存数据到磁盘: # 保存<秒> <修改> #在下面的例子中,行为将被保存: #900秒(15分钟)后,如果至少有一个键发生了变化 #300秒(5分钟)后,如果至少有10个键被更改 #60秒后,如果至少10000个键发生了变化 #注意:您可以通过注释掉所有“save”行来完全禁用save。 #也可以删除所有以前配置的save,通过添加一个带有一个空字符串参数的save指令,就像下面的例子: #save "" save 900 1 save 300 10 save 60 10000 #持久化出现错误后,是否依然进行继续进行工作 stop-writes-on-bgsave-error yes #是否校验rdb文件 rdbcompression yes #使用压缩rdb文件,rdb文件压缩使用LZF压缩算法, rdbchecksum yes #rdb文件名称 dbfilename "redis-server.rdb" #rdb使用上面的“dbfilename配置指令的文件名保存到这个目录 dir "/home/redis-5.0.5/bin" ################################################################ ###################主从复制################ ############################################################## #master的密码 masterauth "jitadmin" #当一个slave失去和master的连接,或者同步正在进行中,slave的行为有两种可能: #如果 replica-serve-stale-data 设置为 “yes” (默认值),slave会继续响应客户端请求,可能是正常数据,也可能是还没获得值的空数据。 #如果 replica-serve-stale-data 设置为 “no”,slave会回复"正在从master同步(SYNC with master in progress)"来处理各种请求,除了 INFO 和 SLAVEOF 命令。 slave-serve-stale-data yes #配置从是否为只读,开启后从则不能写入数据,旧版本是:slave-read-only yes replica-read-only yes #同步策略: 磁盘或socket,默认磁盘方式 repl-diskless-sync no #如果非磁盘同步方式开启,可以配置同步延迟时间,以等待master产生子进程通过socket传输RDB数据给slave。 #默认值为5秒,设置为0秒则每次传输无延迟。 repl-diskless-sync-delay 5 #是否在slave套接字发送SYNC之后禁用 TCP_NODELAY #如果选择yes,Redis将使用更少的TCP包和带宽来向slaves发送数据。但是这将使数据传输到slave上有延迟,Linux内核的默认配置会达到40毫秒。 #如果选择no,数据传输到salve的延迟将会减少但要使用更多的带宽。 #默认我们会为低延迟做优化,但高流量情况或主从之间的跳数过多时,可以设置为“yes”。 repl-disable-tcp-nodelay no #优先级 旧版本是:slave-priority 100 replica-priority 100 #从服务配置,主机不配置。ip(主ip) 端口 #slaveof 192.168.21.30 6379 ################################################################ ###################安全(SECURITY)################ ############################################################## #密码 requirepass "jitadmin" ################################################################ ###################懒删除################ ############################################################## #内存满逐出 lazyfree-lazy-eviction no #过期key删除 lazyfree-lazy-expire no #内部删除,比如rename oldkey newkey时,如果newkey存在需要删除newkey lazyfree-lazy-server-del no #接收完RDB文件后清空数据选项 slave-lazy-flush no ################################################################ ###################持久化方式AOF################ ############################################################## #每次启动时Redis都会先把这个文件的数据读入内存里,先忽略RDB文件 appendonly no #AOF文件名称 appendfilename "appendonly.aof" #fsync() 系统调用告诉操作系统把数据写到磁盘上,而不是等更多的数据进入输出缓冲区。 #有些操作系统会真的把数据马上刷到磁盘上;有些则会尽快去尝试这么做。 #Redis支持三种不同的模式: #no:不要立刻刷,只有在操作系统需要刷的时候再刷。比较快。 #always:每次写操作都立刻写入到aof文件。慢,但是最安全。 #everysec:每秒写一次。折中方案。 #默认的 “everysec” 通常来说能在速度和数据安全性之间取得比较好的平衡。 appendfsync everysec #如果AOF的同步策略设置成 “always” 或者 “everysec”,并且后台的存储进程(后台存储或写入AOF 日志)会产生很多磁盘I/O开销。某些Linux的配置下会使Redis因为 fsync()系统调用而阻塞很久。 #注意,目前对这个情况还没有完美修正,甚至不同线程的 fsync() 会阻塞我们同步的write(2)调用。 #为了缓解这个问题,可以用下面这个选项。它可以在 BGSAVE 或 BGREWRITEAOF 处理时阻止fsync()。 #这就意味着如果有子进程在进行保存操作,那么Redis就处于"不可同步"的状态。 #这实际上是说,在最差的情况下可能会丢掉30秒钟的日志数据。(默认Linux设定) #如果把这个设置成"yes"带来了延迟问题,就保持"no",这是保存持久数据的最安全的方式。 no-appendfsync-on-rewrite no #自动重写AOF文件。如果AOF日志文件增大到指定百分比,Redis能够通过 BGREWRITEAOF 自动重写AOF日志文件。 #工作原理:Redis记住上次重写时AOF文件的大小(如果重启后还没有写操作,就直接用启动时的AOF大小) #这个基准大小和当前大小做比较。如果当前大小超过指定比例,就会触发重写操作。 #你还需要指定被重写日志的最小尺寸,这样避免了达到指定百分比但尺寸仍然很小的情况还要重写。 #指定百分比为0会禁用AOF自动重写特性。 auto-aof-rewrite-percentage 100 #文件达到大小阈值的时候进行重写 auto-aof-rewrite-min-size 64mb #如果设置为yes,如果一个因异常被截断的AOF文件被redis启动时加载进内存,redis将会发送日志通知用户 #如果设置为no,erdis将会拒绝启动。此时需要用"redis-check-aof"工具修复文件。 aof-load-truncated yes #加载时Redis识别出AOF文件以“REDIS”开头字符串, #并加载带此前缀的RDB文件,然后继续加载AOF aof-use-rdb-preamble no #Lua 脚本的最大执行毫秒数 lua-time-limit 5000 ################################################################ ###################慢查询日志################ ############################################################## #记录超过多少微秒的查询命令 #1000000等于1秒,设置为0则记录所有命令 slowlog-log-slower-than 10000 #记录大小,可通过SLOWLOG RESET命令重置 slowlog-max-len 128 ################################################################ ###################延时监控系统################ ############################################################## #记录执行时间大于或等于预定时间(毫秒)的操作,为0时不记录 latency-monitor-threshold 0 ################################################################ ###################事件通知################ ############################################################## #Redis能通知 Pub/Sub 客户端关于键空间发生的事件,默认关闭 notify-keyspace-events "" ################################################################ ###################内部数据结构################ ############################################################## #当hash只有少量的entry时,并且最大的entry所占空间没有超过指定的限制时,会用一种节省内存的 #数据结构来编码。可以通过下面的指令来设定限制 hash-max-ziplist-entries 512 hash-max-ziplist-value 64 #当取正值的时候,表示按照数据项个数来限定每个quicklist节点上的ziplist长度。比如,当这个参数配置 #成5的时候,表示每个quicklist节点的ziplist最多包含5个数据项。 #当取负值的时候,表示按照占用字节数来限定每个quicklist节点上的ziplist长度。这时,它只能取-1到-5 #这五个值,每个值含义如下: #-5: 每个quicklist节点上的ziplist大小不能超过64 Kb。(注:1kb => 1024 bytes) #-4: 每个quicklist节点上的ziplist大小不能超过32 Kb。 #-3: 每个quicklist节点上的ziplist大小不能超过16 Kb。 #-2: 每个quicklist节点上的ziplist大小不能超过8 Kb。(-2是Redis给出的默认值) #-1: 每个quicklist节点上的ziplist大小不能超过4 Kb。 list-max-ziplist-size -2 #这个参数表示一个quicklist两端不被压缩的节点个数。 #注:这里的节点个数是指quicklist双向链表的节点个数,而不是指ziplist里面的数据项个数。 #实际上,一个quicklist节点上的ziplist,如果被压缩,就是整体被压缩的。 #参数list-compress-depth的取值含义如下: #0: 是个特殊值,表示都不压缩。这是Redis的默认值。 #1: 表示quicklist两端各有1个节点不压缩,中间的节点压缩。 #2: 表示quicklist两端各有2个节点不压缩,中间的节点压缩。 #3: 表示quicklist两端各有3个节点不压缩,中间的节点压缩。 #依此类推… #由于0是个特殊值,很容易看出quicklist的头节点和尾节点总是不被压缩的,以便于在表的两端进行快速存取。 list-compress-depth 0 #set有一种特殊编码的情况:当set数据全是十进制64位有符号整型数字构成的字符串时。 #下面这个配置项就是用来设置set使用这种编码来节省内存的最大长度。 set-max-intset-entries 512 #与hash和list相似,有序集合也可以用一种特别的编码方式来节省大量空间。 #这种编码只适合长度和元素都小于下面限制的有序集合 zset-max-ziplist-entries 128 zset-max-ziplist-value 64 #HyperLogLog稀疏结构表示字节的限制。该限制包括 #16个字节的头。当HyperLogLog使用稀疏结构表示 #这些限制,它会被转换成密度表示。 #值大于16000是完全没用的,因为在该点 #密集的表示是更多的内存效率。 #建议值是3000左右,以便具有的内存好处, 减少内存的消耗 hll-sparse-max-bytes 3000 #启用哈希刷新,每100个CPU毫秒会拿出1个毫秒来刷新Redis的主哈希表(顶级键值映射表) activerehashing yes #客户端的输出缓冲区的限制,可用于强制断开那些因为某种原因从服务器读取数据的速度不够快的客户端 client-output-buffer-limit normal 0 0 0 client-output-buffer-limit slave 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60 #默认情况下,“hz”的被设定为10。提高该值将在Redis空闲时使用更多的CPU时,但同时当有多个key #同时到期会使Redis的反应更灵敏,以及超时可以更精确地处理 hz 10 #当一个子进程重写AOF文件时,如果启用下面的选项,则文件每生成32M数据会被同步 aof-rewrite-incremental-fsync yes

哨兵配置文件sentinel.conf

sentinel deny-scripts-reconfig yes # 哨兵sentinel监控的redis主节点的 ip port # master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。 # quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了 # sentinel monitor <master-name> <ip> <redis-port> <quorum> sentinel monitor mymaster 192.168.21.30 6379 2 # 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒 # sentinel down-after-milliseconds <master-name> <milliseconds> sentinel down-after-milliseconds mymaster 2000 #是否后台启动 daemonize yes # 哨兵sentinel实例运行的端口 默认26379 port 26379 # 客户端重新配置主节点参数脚本 # 当一个master由于failover而发生改变时,这个脚本将会被调用,通知相关的客户端关于master地址已经发生改变的信息。 # 以下参数将会在调用脚本时传给脚本: # <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port> # 目前<state>总是“failover”, # <role>是“leader”或者“observer”中的一个。 # 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通信的 # 这个脚本应该是通用的,能被多次调用,不是针对性的。 # sentinel client-reconfig-script <master-name> <script-path> #sentinel client-reconfig-script mymaster /data/redis/server/redis-4.0.14/bin/redis_reconfig.sh # 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码 # 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码 # sentinel auth-pass <master-name> <password> sentinel auth-pass mymaster 1234 # 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步, #这个数字越小,完成failover所需的时间就越长, #但是如果这个数字越大,就意味着越 多的slave因为replication而不可用。 #可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。 # sentinel parallel-syncs <master-name> <numslaves> sentinel parallel-syncs mymaster 1 # 故障转移的超时时间 failover-timeout 可以用在以下这些方面: #1. 同一个sentinel对同一个master两次failover之间的间隔时间。 #2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。 #3.当想要取消一个正在进行的failover所需要的时间。 #4.当进行failover时,配置所有slaves指向新的master所需的最大时间。不过,即使过了这个超时,slaves依然会被正确配置为指向master,但是就不按parallel-syncs所配置的规则来了 # 默认三分钟 # sentinel failover-timeout <master-name> <milliseconds> sentinel failover-timeout mymaster 180000 # Generated by CONFIG REWRITE #哨兵sentinel的工作目录 dir "/home/redis-5.0.5/bin"

Redis三种部署方案

转自https://blog.csdn.net/ahfywangqiang/article/details/86537421

standaloan(单机模式)

standaloan 是redis单机模式,及所有服务连接一台redis服务,该模式不适用生产。如果发生宕机,内存爆炸,就可能导致所有连接改redis的服务发生缓存失效引起雪崩。

ssentinel(哨兵模式)

redis-Sentinel(哨兵模式)是Redis官方推荐的高可用性(HA)解决方案,当用Redis做Master-slave的高可用方案时,假如master宕机了,Redis本身(包括它的很多客户端)都没有实现自动进行主备切换,而Redis-sentinel本身也是一个独立运行的进程,它能监控多个master-slave集群,发现master宕机后能进行切换

sentinel哨兵如下功能实现 (1)monitoring:监控redis是否正常运行 (2)notification:通知application错误信息 (3)failover:当某个master死掉,选择另外一个slave升级为master,更 新master-slave关系。 (4)configurationprovider:client通过sentinel获取redis地址,并在failover时更新地址

2.sentinels and slaves autodiscovery(redis2.8及以上) 配置文件中只配置master地址,slave地址和sentinel地址可以自动发现。 (1)sentinels——sentinel之间通过redis pub/sub交换信息获得。 (2)slaves——询问master获得。

3.sdown、odown、failover 故障检测一般都是通过ping-pong机制,sentinel引入sdown(主观下线)和odown(客观下线)机制,目的应该是在集群规模较大时,检测更客观 (1)sdwon——is-master-down-after-milliseconds(可配置)时间内ping-pong失败。sdown的slave不能升级为master。 (2)odown——超过一定数目(可配置)的sentinel认为sdown,odown只针对master。 (3)failover——多数sentinel认为odown。

redis-cluster(集群模式)

redis集群模式,同样可以实现redis高可用部署,Redis Sentinel集群模式中,随着业务量和数据量增,到性能达到redis单节点瓶颈,垂直扩容受机器限制,水平扩容涉及对应用的影响以及数据迁移中数据丢失风险。针对这些痛点 Redis3.0推出cluster分布式集群方案,当遇到单节点内存,并发,流量瓶颈是,采用cluster方案实现负载均衡,cluster方案主要解决分片问题,即把整个数据按照规则分成多个子集存储在多个不同几点上,每个节点负责自己整个数据的一部分。 Redis Cluster采用哈希分区规则中的虚拟槽分区。虚拟槽分区巧妙地使用了哈希空间,使用分散度良好的哈希函数把所有的数据映射到一个固定范围内的整数集合,整数定义为槽(slot)。Redis Cluster槽的范围是0 ~ 16383。槽是集群内数据管理和迁移的基本单位。采用大范围的槽的主要目的是为了方便数据的拆分和集群的扩展,每个节点负责一定数量的槽。Redis Cluster采用虚拟槽分区,所有的键根据哈希函数映射到0 ~ 16383,计算公式:slot = CRC16(key)&16383。每一个实节点负责维护一部分槽以及槽所映射的键值数据。下图展现一个五个节点构成的集群,每个节点平均大约负责3276个槽,以及通过计算公式映射到对应节点的对应槽的过程。redis-cluster架构图

 

 

最新回复(0)