一、Redis管理命令
1.info命令
127.0.0.1:6379> info
redis_version:3.2.12
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:3b947b91b7c31389
redis_mode:standalone
os:Linux 2.6.32-431.el6.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.7
process_id:33007
run_id:46b07234cf763cab04d1b31433b94e31b68c6e26
tcp_port:6379
uptime_in_seconds:318283
uptime_in_days:3
hz:10
lru_clock:13601047
executable:/application/redis-3.2.12/redis-server
config_file:/etc/redis/6379/redis.conf
connected_clients:2
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
used_memory:845336
used_memory_human:825.52K
used_memory_rss:1654784
used_memory_rss_human:1.58M
used_memory_peak:845336
used_memory_peak_human:825.52K
total_system_memory:1028517888
total_system_memory_human:980.87M
used_memory_lua:37888
used_memory_lua_human:37.00K
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
mem_fragmentation_ratio:1.96
mem_allocator:jemalloc-4.0.3
loading:0
rdb_changes_since_last_save:131
rdb_bgsave_in_progress:0
rdb_last_save_time:1540009420
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:-1
rdb_current_bgsave_time_sec:-1
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
total_connections_received:19
total_commands_processed:299
instantaneous_ops_per_sec:0
total_net_input_bytes:10773
total_net_output_bytes:97146
instantaneous_input_kbps:0.00
instantaneous_output_kbps:0.00
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:5
evicted_keys:0
keyspace_hits:85
keyspace_misses:17
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:0
migrate_cached_sockets:0
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
used_cpu_sys:203.44
used_cpu_user:114.57
used_cpu_sys_children:0.00
used_cpu_user_children:0.00
cluster_enabled:0
db0:keys=17,expires=0,avg_ttl=0
127.0.0.1:6379> info cpu
used_cpu_sys:203.45
used_cpu_user:114.58
used_cpu_sys_children:0.00
used_cpu_user_children:0.00
2. client命令
127.0.0.1:6379> CLIENT LIST
id=2 addr=127.0.0.1:39376 fd=7 name= age=146 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client
id=3 addr=172.16.1.61:39112 fd=8 name= age=4 idle=4 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=command
127.0.0.1:6379>
3.select命令
在Redis中也是有库这个概念的，不过不同于MySQL，Redis的库是默认的，并不是我们手动去创建的，在Redis中一共有16（0-15）个库。在MySQL中进入某一个库，我们需要使用use dbname，在Redis中，只需要select即可。默认情况下，我们是在0库中进行操作，每个库之间都是隔离的。
127.0.0.1:6379> keys *
127.0.0.1:6379> SELECT 1
OK
127.0.0.1:6379[1]> keys *
(empty list or set)
4.flush（flushall、flushdb）命令
127.0.0.1:6379> flushall
OK
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> flushdb
OK
5.monitor命令
127.0.0.1:6379> MONITOR
OK
[root@db01 ~]
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> SELECT 1
OK
127.0.0.1:6379[1]> set k3 v3
OK
127.0.0.1:6379> MONITOR
OK
1589245546.086470 [0 127.0.0.1:39378] "AUTH" "123"
1589245546.086537 [0 127.0.0.1:39378] "keys" "*"
1589245558.400459 [0 127.0.0.1:39378] "set" "k1" "v1"
1589245565.759616 [0 127.0.0.1:39378] "set" "k2" "v2"
1589245578.585385 [0 127.0.0.1:39378] "SELECT" "1"
1589245583.754403 [1 127.0.0.1:39378] "set" "k3" "v3"
1589245627.079624 [0 127.0.0.1:39380] "AUTH" "123"
1589245627.082768 [0 127.0.0.1:39380] "COMMAND"
二、redis消息队列
1.什么是消息队列
消息队列（Message Queue）是一种应用间的通信方式，消息发送后可以立即返回，由消息系统来确保信息的可靠传递，消息生产者只管把消息发布到MQ中而不管谁来取，消息消费者只管从MQ中取消息而不管谁发布的，这样发布者和使用者都不用知道对方的存在。
2.为什么要使用消息队列
首先，我们可以知道，消息队列是一种异步的工作机制，比如说日志收集系统，为了避免数据在传输过程中丢失，还有订单系统，下单后，会生成对应的单据，库存的扣减，消费信息的发送，一个下单，产生这么多的消息，都是通过一个操作的触发，然后将其他的消息放入消息队列中，依次产生。再就是很多网站的，秒杀活动之类的，前多少名用户会便宜，都是通过消息队列来实现的。
这些例子，都是通过消息队列，来实现，业务的解耦，最终数据的一致性，广播，错峰流控等等，从而完成业务的逻辑
3.reids发布消息-任务队列模式
任务队列：顾名思义，就是“传递消息的队列”。与任务队列进行交互的实体有两类，一类是生产者（producer），另一类则是消费者（consumer）。生产者将需要处理的任务放入任务队列中，而消费者则不断地从任务队列中读入任务信息并执行。
任务队列的好处
1）松耦合。
生产者和消费者只需按照约定的任务描述格式，进行编写代码。
2）易于扩展。
多消费者模式下，消费者可以分布在多个不同的服务器中，由此降低单台服务器的负载。
4.发布-订阅模式
其实从Pub/Sub的机制来看，它更像是一个广播系统，多个订阅者（Subscriber）可以订阅多个频道（Channel），多个发布者（Publisher）可以往多个频道（Channel）中发布消息。
可以这么简单的理解：
1）Subscriber：收音机，可以收到多个频道，并以队列方式显示
2）Publisher：电台，可以往不同的FM频道中发消息
3）Channel：不同频率的FM频道
5.redis发布订阅模拟
1）订阅单个频道
127.0.0.1:6379> SUBSCRIBE read
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "read"
3) (integer) 1
127.0.0.1:6379> PUBLISH read "look look me"
(integer) 1
127.0.0.1:6379> SUBSCRIBE read
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "read"
3) (integer) 1
1) "message"
2) "read"
3) "look look me"
2）订阅多个频道
127.0.0.1:6379> SUBSCRIBE read test lalala
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "read"
3) (integer) 1
1) "subscribe"
2) "test"
3) (integer) 2
1) "subscribe"
2) "lalala"
3) (integer) 3
127.0.0.1:6379> PSUBSCRIBE *
Reading messages... (press Ctrl-C to quit)
1) "psubscribe"
2) "*"
3) (integer) 1
三、redis事务介绍
1.mysql中事务
begin;
事件1....
事件2....
commit;
begin;
事件1....
事件2....
rollback;
2.redis事务相关命令
127.0.0.1:6379> MULTI
127.0.0.1:6379> EXEC
127.0.0.1:6379> DISCARD
WATCH key [key ...]
UNWATCH
3.事务的使用
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set shijian1 1
QUEUED
127.0.0.1:6379> set shijian2 2
QUEUED
127.0.0.1:6379> get shijian1
QUEUED
127.0.0.1:6379> get shijian2
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) OK
3) "1"
4) "2"
127.0.0.1:6379> get shijian1
"1"
127.0.0.1:6379> get shijian2
"2"
127.0.0.1:6379> WATCH k1
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set k1 vvvv1
QUEUED
172.16.1.51:6379> set k1 v3445
OK
127.0.0.1:6379> EXEC
(nil)
4.注意
1.redis只支持乐观锁
2.事务在不开启watch时，谁后提交谁为准
3.事务在开启watch时，谁先提交谁为准
4.watch只能对接下来执行的一个事务进行监控，执行第二个事务的时候要重新watch
四、redis多实例
1.创建多实例目录
[root@db01 ~]
2.配置多实例
[root@db01 ~]
daemonize yes
bind 172.16.1.51 127.0.0.1
port 6379
pidfile /server/redis/6379/redis.pid
logfile /server/redis/6379/redis.log
protected-mode no
dir /server/redis/6379
dbfilename dump.rdb
save 900 1
save 300 10
save 60 10000
[root@db01 ~]
daemonize yes
bind 172.16.1.51 127.0.0.1
port 6380
pidfile /server/redis/6380/redis.pid
logfile /server/redis/6380/redis.log
protected-mode no
dir /server/redis/6380
dbfilename dump.rdb
save 900 1
save 300 10
save 60 10000
[root@db01 ~]
daemonize yes
bind 172.16.1.51 127.0.0.1
port 6381
pidfile /server/redis/6381/redis.pid
logfile /server/redis/6381/redis.log
protected-mode no
dir /server/redis/6381
dbfilename dump.rdb
save 900 1
save 300 10
save 60 10000
3.启动多实例
[root@db01 ~]
[root@db01 ~]
[root@db01 ~]
4.检查启动
[root@db01 ~]
root 15642 1 0 11:15 ? 00:00:00 redis-server 172.16.1.51:6379
root 15646 1 0 11:15 ? 00:00:00 redis-server 172.16.1.51:6380
root 15650 1 0 11:15 ? 00:00:00 redis-server 172.16.1.51:6381
root 15655 15208 0 11:16 pts/0 00:00:00 grep --color=auto redis
五、redis主从复制
1.主从复制特点
1）使用异步复制。
2）一个主服务器可以有多个从服务器。
3）从服务器也可以有自己的从服务器。
4）复制功能不会阻塞主服务器。
5）可以通过复制功能来让主服务器免于执行持久化操作，由从服务器去执行持久化操作即可。
2.主从复制原理
1.从服务器开启主从
2.从向主服务器发送 SYNC 命令
3.接到 SYNC 命令的主服务器会调用BGSAVE 命令，创建一个 RDB 文件
4.主库会将RDB文件传输到从库
5.主库在生成和传送RDB文件过程中，使用缓冲区记录接下来执行的所有写命令
6.从服务器接收到主库传来的rdb文件以后，会清空自己的数据
7.从库载入这个RDB文件。
8.主服务器将缓冲区储存的所有写命令发送给从服务器执行
3.主从复制机制
1）PSYNC只会将从服务器断线期间缺失的数据发送给从服务器。两个例子的情况是相同的，但SYNC 需要发送包含整个数据库的 RDB 文件，而PSYNC 只需要发送三个命令。
2）如果主从服务器所处的网络环境并不那么好的话（经常断线），那么请尽量使用 Redis 2.8 或以上版本：通过使用 PSYNC 而不是 SYNC 来处理断线重连接，可以避免因为重复创建和传输 RDB文件而浪费大量的网络资源、计算资源和内存资源。
4.redis主从实践
1）环境准备
| 角色 |
主机 |
端口 |
| 主库 |
172.16.1.51 |
6379 |
| 从库 |
172.16.1.51 |
6380 |
| 从库 |
172.16.1.51 |
6381 |
2）连接三台redis实例
[root@db01 ~]
[root@db01 ~]
[root@db01 ~]
3）查看三台实例主从状态
127.0.0.1:6379> info replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6379>
4）配置主从
127.0.0.1:6380> SLAVEOF 172.16.1.51 6379
OK
127.0.0.1:6379> info replication
role:master
connected_slaves:2
slave0:ip=172.16.1.51,port=6380,state=online,offset=71,lag=1
slave1:ip=172.16.1.51,port=6381,state=online,offset=71,lag=1
master_repl_offset:71
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:70
127.0.0.1:6380> info replication
role:slave
master_host:172.16.1.51
master_port:6379
master_link_status:up
master_last_io_seconds_ago:7
master_sync_in_progress:0
slave_repl_offset:57
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
slaveof 172.16.1.51 6379
5）如果主库出现问题
127.0.0.1:6380> set k6380 v6380
(error) READONLY You can't write against a read only slave.
#如果主库故障
127.0.0.1:6379> shutdown
not connected> quit
#选一台从库取消主从
127.0.0.1:6380> SLAVEOF no one
OK
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
#另一台redis修改主库同步
127.0.0.1:6381> SLAVEOF 172.16.1.51 6380
OK
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:172.16.1.51
master_port:6380
master_link_status:up