第七周作业
-
-
基于流复制完成postgresql的高可用。
-
实现postgresql的时间点还原。
-
规划高可用的LAMP，要求wordpress网站放在NFS共享存储上，并且用户可以正常发布博客，上传图片。尝试更新wordpress版本，测试网站仍可用。
-
redis数据类型有哪些？
-
redis RDB和AOF比较？
-
PostgreSQL 9.1之前，主从复制传输以WAL日志文件为单位，主库写完一个WAL日志文件后才传送到备库，这种方式导致主备延迟特别大。
9.1引入了主备流复制，传输单位是WAL日志的record，备库不断从主库同步相应的数据，并apply每个WAL record，因此9.1能够做到同步复制。同时9.1提供了Hot Standby，备库在应用WAL record的同时能够提供只读服务，大大提升了用户体验。
1.主备流复制架构
PG主备流复制的核心由三个进程组成：
walsender：用于主库发送WAL日志记录至从库
walreceiver：用于从库接收主库的WAL日志记录
startup：用于从库apply日志
2. 流复制的启动
2.1. 启动过程
本节探讨流复制的启动顺序，以了解三个核心进程如何启动，以及它们之间如何建立连接
（1）启动主、备服务器 （2）备节点启动startup进程 （3）备节点启动walreceiver进程 （4）walreceiver进程向主节点发送连接请求，如果主库尚未启动，walreceiver会定期重发该请求 （5）当主节点收到连接请求时，将启动walsender进程，并建立walsender与walreceiver之间的TCP连接 （6）walreceiver发送备节点最新的LSN，这个阶段在IT领域称为握手机制 （7）如果备库最新LSN小于主库最新LSN（落后），walsender会将前一个LSN到后一个LSN之间的wal数据发送到walreceiver。这个阶段就是备库追赶主库的阶段。 （8）流复制开始工作
2.2. walsender状态
通过pg_stat_replication视图可以查看所有正在运行的walsender状态
SELECT client_addr,client_port,application_name,state,sync_state FROM pg_stat_replication;
walsender进程可能的状态如下： start-up：上图（5）~（6） catch-up：上图（7） streaming：上图（8） backup：由于备份发送整个数据库集群的文件，比如pg_basebackup
3.2 备节点长期停机再启动后，会发生什么？
9.4以前，如果备节点请求的wal段在主节点已被覆盖，那么备节点将无法追上主节点。这个问题没有什么好的解决方案，只能把wal_keep_segments参数增大，减少发生的可能性。
9.4开始，这个问题可以使用复制槽（replication slot）来预防——通过暂停walreceiver进程，将含有未发送wal段的pg_xlog保存在复制槽中。复制槽可提高wal数据发送灵活性性，主要用于逻辑复制。
参考文档
http://mysql.taobao.org/monthly/2015/10/04/
二、基于流复制完成postgresql的高可用。
流复制包含两个方面：日志传输和数据同步。
流复制是基于日志传输的，主节点会在写入日志记录时，将WAL数据发送到已连接的备节点。
同步复制需要数据库同步，主节点与多个备节点通信，从而同步整个数据库集群。
为了更容易理解，本节描述了一主一备的情况，下一节介绍一主多备的情况
1. 主备间的通信
假设在备节点处于同步模式、hot_standby参数已禁用、wal_level为'archive'，即主库配置以下参数： synchronous_standby_names = 'standby1' hot_standby = off wal_level = archive 假设后台进程在自动提交模式下在主节点发出一条insert语句。后台进程启动事务、发出一条insert语句、然后立即提交事务。我们来探讨如何完成此次提交。 （1）后台进程执行XLogInsert()和 XLogFlush()函数，将wal数据写入缓存并flush到wal段文件。 （2）walsender将写入wal段文件的wal数据发送到walreceiver。 （3）主节点发送wal数据后，后端进程继续等待来自备节点的ACK响应。更确切地说，后台进程执行内部函数SyncRepWaitForLSN()来获取latch，并等待释放它。 （4）walreceiver通过write()函数将接收到的wal数据写入备节点的wal缓存，并且返回ACK响应给walsender。 （5）walreceiver通过fsync()函数将wal数据全部flush到wal段文件，并且再返回一个ACK响应给walsengder，通知startup进程wal相关数据已更新。 （6）starup进程应用已经写入wal段文件的wal数据。 （7）walsender在接受到ACK响应后释放latch，然后后端进程完成commit或abort动作。latch释放的时间取决于参数synchronous_commit（详细参考下片）：
如果参数是on，则在步骤（5）接受ACK响应后释放latch；
如果是remote_write，那么在步骤（4）接受ACK响应后就释放latch。 如果wal_level设置为hot_standby或logical，pg会根据commit或abort操作的记录，写入热备功能相关的wal记录
2. ACK响应内容
ACK响应将备节点内部信息发送主节点，包含以下4个项目: 已写入的最新WAL数据的LSN位置 已刷新的最新WAL数据的LSN位置 startup进程最新应用的wal数据的LSN位置 发送此ACK的时间戳 walreceiver不仅在写入和刷新WAL数据的时候返回ACK响应，还定期发送备节点心跳（心跳发送间隔通过wal_receiver_status_interval设置，默认10秒）。因此，主节点始终掌握所有已连接备节点的状态。 通过以下查询可以看到所连接备库相关LSN的信息 SELECT application_name AS host,write_location AS write_LSN,flush_location AS flush_LSN,replay_location AS replay_LSN FROM pg_stat_replication; host | write_lsn | flush_lsn | replay_lsn ----------+-----------+-----------+------------ standby1 | 0/5000280 | 0/5000280 | 0/5000280 standby2 | 0/5000280 | 0/5000280 | 0/5000280
3. 发生故障时的行为
本节描述同步模式下备节点故障时主节点的行为，以及该如何处理这种情况。 即使同步备节点故障，不能再返回ACK响应给主节点，主节点也会继续等待备库的ACK响应。因此，在主节点运行的事务会无法提交，后续的查询也无法执行。换句话说，主节点所有的操作都停止（流复制不支持由于超时自动降级为异步模式）。 有两种方法避免这种情况的发生： 提供多台备节点来提高系统的可用性 通过手动执行以下步骤从同步流复制转换到异步流复制 # 1.设置synchronous_standby_names为空串 synchronous_standby_names = '' #2.执行reload命令重载配置文件 pg_ctl -D $PGDATA reload 以上操作对已经连接的客户端没有影响，主节点会继续处理所有连接的session的事物。
4、 管理多个备节点（高可用方面）
1. 同步优先级与同步状态
主节点会为自己的所有备节点指定sync_priority（同步优先级）和sync_state（同步状态）。 同步优先级 sync_priority表示备节点在同步模式下的优先级。它是一个固定值，值越小优先级越高，0是个特殊值，表示异步模式。备节点优先级是个有序列表，按synchronous_standby_names中的顺序依次给出。 例如，以下配置中standy1和standy2的优先级分别是1和2。参数中未列出的备节点是异步模式，优先级为0。 synchronous_standby_names = 'standby1,standby2' 同步状态 sync_state表示备节点的状态，这个值由各备节点的运行状态及优先级而定，以下是可能的值： Sync：具有最高优先级的同步模式备节点状态 Potential：同步模式下优先级>=2的备节点状态。如果Sync状态（最高优先级）的备节点故障，优先级第二高（优先级=2）的备节点会代替故障节点变为最高优先级。 ASync：异步模式备节点的固定值，除非修改同步模式，否则它们的状态永远不会是sync和potential。 可以通过pg_stat_replication视图查看这两个值 SELECT application_name AS host,sync_priority,sync_state FROM pg_stat_replication; host | sync_priority | sync_state ----------+---------------+------------ standby1 | 1 | sync standby2 | 2 | potential
2. 主节点如何管理多个备节点
主节点仅等待Sync状态备节点的ACK响应，换句话说，主节点仅确保Sync状态备节点已写入并刷新wal数据。因此，在流复制中，只有Sync状态备节点与主节点是始终的同步的。 下图展示了Potential状态备库ACK响应早于Sync状态备库的情况：此时主库并不会完成当前事务的提交操作，而要继续等待Sync状态备库ACK响应。当收到Sync状态备库ACK响应时，主库后端进程才释放latch并完成事务提交。
这里standby1和standby2的sync_state分别是sync和potentail。
尽管主库已接收到Potential状态备库ACK响应，但主库的后端进程还是持续等待Sync状态备节点ACK响应 接收到Sync状态备节点ACK响应后，主库后端进程释放latch，完成当前的事物提交 相反，如果主库先接收到Sync状态备库ACK响应，它会立即完成当前事物提交，而不去确认potentail状态的备库是否已写入并刷新wal数据。
3. 备库发生故障时的行为
Potential或Async状态备节点故障
主节点会终止连接到故障备节点的walsender进程，并继续进行自己的事务处理。换句话说，主节点的事务处理不受这两类备节点故障的影响。
sync状态备节点故障
主节点终止连接到故障节点的walsender进程，Potential状态备节点顶替故障的备节点变为Sync状态（期间主库不可用），在替换完成后主库恢复事务处理。因此，备节点的故障检测（下节介绍）对提高流复制高可用至关重要。
![]()
5、 备节点的故障检测
流复制使用两种常见的故障检测程序，不需要任何特殊的硬件。 1. 备节点进程的故障检测 当检测到walsender与walreceiver的连接中断时，主节点立即判定备节点或walreceiver出现故障。 当底层网络函数由于未能成功读/写walreceiver套接字接口而返回错误时，主节点也会立即判定其失效。 2.硬件或者网络故障检测 如果walreceiver在wal_sender_timeout内（默认60s）没有返回任何结果，主节点会认为备节点出现故障。与上述故障对比，即使备节点由于硬件、网络等故障已无法返回任何响应，主库也需要最长wal_sender_timeout的时间来确认备节点故障。 根据故障类型，在故障和检测之间可能会有时间差，特别是如果在Sync状态备库中发生第2种故障，那么即使有多个Potential状态备节点正常工作，检测到Sync状态备库失效，主库仍然可能会有一段时间不可用。 在9.2及之前版本，wal_sender_timeout参数被称为replication_timeout。
6、 进程通信详细过程
1. walsender和walreceiver的流复制过程
2. walreceiver和startup进程
前提条件： 为了能做时间点恢复，要满足两点： 第一，做好基础备份 第二，配置好自动归档 在满足这两点之后，可以按以下步骤进行恢复 1.停止postgresql服务，把data目录和表空间目录（如果有）移到其他位置。备份这两个目录是防止万一，在恢复的过程中有可能需要。 2.把基础备份文件复制到postgresql原来的data目录和表空间目录（如果有）。 3.配置recovery.conf文件。 4.重新启动postgresql服务。 在以上的四个步骤中，有几个需要注意的问题。 在第二个步骤中，把基础备份文件复制到postgresql的data目录时，要注意owner问题，复制后要检查owner是否为postgres（这个是安装数据库时配置的用户）。另外（如果有表空间）还要检查一下data/pg_tblspc中的软连接是否正确，最后还要检查一下data目录本身的权限，要求是700，否则，会导致启动服务失败。 在配置recovery.conf时，最关键的是配置restore_command. 这个命令其实也简单，就是把归档中的日志文件复制到pg_wal目录下。和归档配置中的archive_command做相反的操作。 在配置recovery.conf中另外一个重要的事就是配置恢复到的时间点。默认情况下，恢复将会一直恢复到 WAL 日志的末尾。下面的参数可以被用来指定一个更早的停止点。在recovery_target、recovery_target_lsn、recovery_target_name、recovery_target_time和recovery_target_xid中，最多只能使用一个，如果在配置文件中使用了多个，将使用最后一个。
2、增量备份
优点
- 零停机时间–增量数据库备份对于无法承受一分钟停机时间的关键系统非常重要。 使用时间点恢复，可以完全消除数据库备份的停机时间，因为该机制可以使数据库备份和系统访问同时进行。
- 节省存储空间–通过增量数据库备份，我们将备份自上次备份以来的最新存档日志文件，而不是每天进行完整数据库备份。
PostgreSQL备份步骤摘要
修改postgresql.conf以支持存档日志
进行基本备份（完整数据库备份）
备份基本备份到远程存储。
将WAL（归档日志文件）备份到远程存储（连续过程）
PostgreSQL时间点恢复步骤摘要
从基本备份中提取文件
从pg_xlog文件夹复制文件
创建recovery.conf文件
开始恢复
1.实验需求 ________________________________________ （1）nfs server导出/data/application/web,在目录中提供wordpress; （2）nfs client挂载nfs server导出的文件系统，至/var/www/html; （3）客户端1(lamp)部署wordpress，并让其正常访问，要确保正常发文章，上传图片。 （4）客户端2(lamp),挂载nfs server导出的文件系统至/var/www/html，验证其wordpress是 否可被访问，要确保能正常发文章，上传图片。 （5）nfs server 导出/mydata/目录； （6）nfs client挂载/mydata/至本地的/mydata目录，mysqld或mariadb服务的数据目录设置为/mydata, 要求服务能正常启动，且可正常存储数据。 2.服务器规划 ________________________________________ 服务器版本 角色 主机名 IP地址 centos7.2x86_64 web服务器01（apache+php） nfs客户端 web01 172.16.52.51 centos7.2x86_64 web服务器02（apache+php） nfs客户端 web02 172.16.52.52 centos7.2x86_64 mysqld数据库服务 nfs客户端 db 172.16.52.53 centos7.2x86_64 nfs服务端 nfs 172.16.52.54 部署NFS服务端及nfs客户端 ________________________________________ 3.1 配置nfs服务端 (1)安装nfs软件 [root@nfs ~]# yum -y install nfs-utils [root@nfs ~]# rpm -qa nfs-utils nfs-utils-1.3.0-0.21.el7.x86_64 (2)启动nfs服务 开机自启动nfs服务： [root@nfs ~]# systemctl enable rpcbind.service [root@nfs ~]# systemctl enable nfs-server.service 启动rpcbind和nfs服务： 注意要先启动rpcbind [root@nfs ~]# systemctl start rpcbind.service [root@nfs ~]# systemctl start nfs.service 查看nfs状态： [root@nfs ~]# rpcinfo -p (3)配置nfs服务 [root@nfs ~]# cat /etc/exports /data/application/web 172.16.0.0/16(rw,sync,anonuid=888,anongid=888) /mydata 172.16.0.0/16(rw,sync,anonuid=3306,anongid=3306) 重新导出： [root@nfs ~]# exportfs -arv exporting 172.16.0.0/16:/data exporting 172.16.0.0/16:/data/application/web 为nfs共享文件创建授权用户（uid）： 这里我们不使用默认的nfsnobody用户 [root@nfs ~]# groupadd -g 888 apache [root@nfs ~]# useradd -u 888 -g apache -s/sbin/nologin -M apache [root@nfs ~]# id apache uid=888(apache) gid=888(apache) groups=888(apache) [root@nfs ~]# chown apache.apache/data/application/web [root@nfs ~]# ls -ld /data/application/web/ drwxr-xr-x 2 apache apache 6 Jul 20 04:27/data/application/web/ [root@nfs ~]# groupadd -g 3306 mysql [root@nfs ~]# useradd -u 3306 -g mysql -s/sbin/nologin -M mysql [root@nfs ~]# id mysql uid=3306(mysql) gid=3306(mysql) groups=3306(mysql) [root@nfs ~]# chown mysql.mysql /data [root@nfs ~]# ls -ld /data drwxr-xr-x 4 mysql mysql 35 Jul 20 04:27 /data 3.2 配置nfs客户端 注：3个nfs客户端配置都一样 安装软件包： [root@db ~]# yum -y install nfs-utils 启动rpcbind： 客户端只用启动rpcbind即可。 [root@db ~]# systemctl start rpcbind 4.部署lamp环境 ________________________________________ 说明：本次lamp环境采用rpm包安装，数据库分离 web01 和web02 配置一样。 为了方便测试：web01域名blog.magedu.com；web02域名blog02.magedu.com 4.1 安装软件 [root@web01 ~]# yum -y install httpd php php-mysql 4.2 配置虚拟主机 [root@web01 conf.d]# cat blog.conf <VirtualHost *:80> ServerNameblog.magedu.com DocumentRoot"/var/www/html" CustomLog"/var/log/httpd/blog/access_log" combined ErrorLog "/var/log/httpd/blog/error_log" <Directory"/var/www/html"> OptionsNone AllowOverrideNone Requireall granted </Directory> </VirtualHost> 5. 部署mariadb数据库服务 ________________________________________ mariadb采用通用二进制安装 [root@db soft]# ln -sv mariadb-5.5.46-linux-x86_64 mariadb [root@db soft]#ls mariadb mariadb-5.5.46-linux-x86_64 5.1 创建mysql用户 [root@db soft]# groupadd -g 3306 mysql [root@db soft]# useradd -u 3306 -g mysql mysql [root@db soft]# id mysql uid=3306(mysql) gid=3306(mysql) groups=3306(mysql) 5.2 创建数据目录并授权 [root@db soft]# mkdir /mydata [root@db soft]# chown -R mysql.mysql /mydata [root@db soft]# ls -ld /mydata drwxr-xr-x 2 mysql mysql 6 Jul 20 07:27 /mydata 5.3 初始化数据库 [root@db mariadb]# chown -R root.mysql /data/soft/mariadb/ [root@db mariadb]# cd /data/soft/mariadb [root@db mariadb]# scripts/mysql_install_db--user=mysql --datadir=/mydata --basedir=/data/soft/mariadb 5.4 配置/etc/my.cnf # cp support-files/my-large.cnf /etc/my.cnf vim /etc/my.cnf [mysqld] port = 3306 basedir = /data/soft/mariadb datadir = /data/mydata innodb_file_per_table = 1 #让innodb表每个表一个表空间文件。 5.5 配置mysqld启动脚本 复制mysql启动脚本到/etc/init.d/mysqld [root@db ~]# cp /data/soft/mariadb/support-files/mysql.server/etc/init.d/mysqld [root@db ~]# chmod 755 /etc/init.d/mysqld [root@db ~]# sed -i‘s#/usr/local/mysql#/data/soft/mariadb#g‘ /etc/init.d/mysqld [root@db ~]# chkconfig --add mysqld 修改PATH环境变量： [root@db mariadb]# cat /etc/profile.d/mysql.sh export PATH=/data/soft/mariadb/bin:$PATH 配置库文件搜索路径： [root@db mariadb]# echo"/data/soft/mariadb/lib" > /etc/ld.so.conf.d/mysqld.conf [root@db mariadb]# ldconfig 5.6 启动mysqld服务 [root@db /]# service mysqld start Starting MySQL.. SUCCESS! [root@db /]# lsof -i:3306 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME mysqld 7668mysql 15u IPv4 23521 0t0 TCP *:mysql (LISTEN) 5.7 测试php与数据库的连接 注：事先创建好相关的库和用户 在web服务器站点下创建mysql.php 文件 [root@web01 html]# cat mysql.php <?php $conn= mysql_connect(‘172.16.52.53‘,‘wordpress‘,‘123456‘); if($conn) echo‘connect 172.16.52.53 is OK‘; else echo‘failure‘; ?> 5.8 把nfs服务端的/mydata/目录挂载至本地的/mydata [root@db ~]# showmount -e 172.16.52.54 Export list for 172.16.52.54: /mydata 172.16.0.0/16 /data/application/web 172.16.0.0/16 [root@db ~]# ls -ld /mydata/ drwxr-xr-x 6 mysql mysql 4096 Jul 21 06:05 /mydata/ [root@nfs /]# ls -ld /mydata drwxr-xr-x 6 mysql mysql 4096 Jul 21 06:05 /mydata 把本地mysql数据目录/mydata里面的文件复制到nfs服务端的/mydata目录里 [root@db ~]# scp -r /mydata/*root@172.16.52.54:/mydata 重新对nfs服务端/mydata/下面的文件授权： chown -R mysql.mysql /mydata 挂载： mount -t nfs 172.16.52.54:/mydata /mydata 重启mysqld测试： [root@db ~]# service mysqld restart Shutting down MySQL. SUCCESS! Starting MySQL.. SUCCESS! ok,没有问题。 6.部署web服务器站点目录 ________________________________________ 6.1 LAMP 01部署wordpress站点 站点目录严格授权: [root@web01 html]# chown -R root.root/var/www/html/ [root@web01 html]# find /var/www/html/ -type f|xargs chmod 644 [root@web01 html]# find /var/www/html/ -type d|xargs chmod 755 [root@web01 html]# chown -R apache.apache/var/www/html/wordpress/wp-content 6.2 把nfs服务端的/data/application/web 挂载至web01本地的/var/www/html （1）把/var/www/html下面的文件复制到/data/application/web目录下面 [root@web01 ~]# scp -rp /var/www/html/*root@172.16.52.54:/data/application/web/ （2）授权 [root@nfs~]# chown -R apache.apache /data/application/web/wordpress/wp-content/ （3）挂载 [root@web01 ~]# showmount -e 172.16.52.54 Export list for 172.16.52.54: /mydata 172.16.0.0/16 /data/application/web 172.16.0.0/16 [root@web01 wordpress]# mount -t nfs 172.16.52.54:/data/application/web/var/www/html 6.3 把nfs服务端的/data/application/web 挂载至web02本地的/var/www/html （1）挂载 [root@web02 ~]# mount -t nfs172.16.52.54:/data/application/web /var/www/html （2）访问blog02.magedu.com/wordpress/index.php 7. 总结 ________________________________________ 本次实验实现了web站点数据的共享，一定程度上实现session共享和负载均衡的功能。
Redis支持五种数据类型：string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合)。 String（字符串） string 是 redis 最基本的类型，你可以理解成与 Memcached 一模一样的类型，一个 key 对应一个 value。 string 类型是二进制安全的。意思是 redis 的 string 可以包含任何数据。比如jpg图片或者序列化的对象。 string 类型是 Redis 最基本的数据类型，string 类型的值最大能存储 512MB。 常用命令：set、get、decr、incr、mget等。 注意：一个键最大能存储512MB。 Hash（哈希） Redis hash 是一个键值(key=>value)对集合；是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象。 每个 hash 可以存储 232 -1 键值对（40多亿）。 常用命令：hget、hset、hgetall等。 应用场景：存储一些结构化的数据，比如用户的昵称、年龄、性别、积分等，存储一个用户信息对象数据。 List（列表） Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。 list类型经常会被用于消息队列的服务，以完成多程序之间的消息交换。 常用命令：lpush、rpush、lpop、rpop、lrange等。 列表最多可存储 232 - 1 元素 (4294967295, 每个列表可存储40多亿)。 Set（集合） Redis的Set是string类型的无序集合。和列表一样，在执行插入和删除和判断是否存在某元素时，效率是很高的。集合最大的优势在于可以进行交集并集差集操作。Set可包含的最大元素数量是4294967295。 集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。 应用场景： 1、利用交集求共同好友。 2、利用唯一性，可以统计访问网站的所有独立IP。 3、好友推荐的时候根据tag求交集，大于某个threshold（临界值的）就可以推荐。 常用命令：sadd、spop、smembers、sunion等。 集合中最大的成员数为 232 - 1(4294967295, 每个集合可存储40多亿个成员)。 zset(sorted set：有序集合) Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。 不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。 zset的成员是唯一的,但分数(score)却可以重复。 sorted set是插入有序的，即自动排序。 常用命令：zadd、zrange、zrem、zcard等。 当你需要一个有序的并且不重复的集合列表时，那么可以选择sorted set数据结构。 应用举例： （1）例如存储全班同学的成绩，其集合value可以是同学的学号，而score就可以是成绩。 （2）排行榜应用，根据得分列出topN的用户等。
持久化之RDB 定义：在指定的时间间隔内生成数据集的时间点快照 RDB 的优点: 1.RDB 是一个非常紧凑的文件 它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份： 比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个
RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。 2.RDB 非常适用于灾难恢复 它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心，或者亚马逊 S3 中。 3.RDB 可以最大化 Redis 的性能 父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。 4.RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。 RDB 的缺点 如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。 虽然 Redis 允许你设置不同的保存点来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状
态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。 每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户
端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。 AOF 的优点 使用 AOF 持久化会让 Redis 变得非常耐久：你可以设置不同的 fsync 策略，比如无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一
次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）。 AOF 文件是一个只进行追加操作的日志文件， 因此对 AOF 文件的写入不需要进行 seek ， 即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等
）， redis-check-aof 工具也可以轻易地修复这种问题。 Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因
为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就
会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。 AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析也很轻松。 导出 AOF 文件也非常
简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。 AOF 的缺点 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也
是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间。 AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。 （举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样
的 bug 。） 测试套件里为这种情况添加了测试： 它们会自动生成随机的、复杂的
数据集， 并通过重新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见， 但是对比来说， RDB 几乎是不可能出现这种 bug 的。 总结：rdb和aof的优缺点 RDB的优点 1.体积更小：相同的数据量rdb数据比aof的小，因为rdb是紧凑型文件 2.恢复更快：因为rdb是数据的快照，基本上就是数据的复制，不用重新读取再写入内存 3.性能更高:父进程在保存rdb时候只需要fork一个子进程，无需父进程的进行其他io操作，也保证了服务器的性能。 RDB的缺点 1.故障丢失:因为rdb是全量的，我们一般是使用shell脚本实现30分钟或者1小时或者每天对redis进行rdb备份，但是最少也要5分钟进行一次的备份，所以当服务死掉后，最少也要丢失5分钟的数据。 2.耐久性差:相对aof的异步策略来说，因为rdb的复制是全量的，即使是fork的子进程来进行备份，当数据量很大的时候对磁盘的消耗也是不可忽视的，尤其在访问量很高的时候，fork的时间也会延长，导致cpu吃紧，耐久性相对较差。 aof的优点 1.数据保证：我们可以设置fsync策略，一般默认是everysec，也可以设置每次写入追加，所以即使服务死掉了，咱们也最多丢失一秒数据 2.自动缩小：当aof文件大小到达一定程度的时候，后台会自动的去执行aof重写，此过程不会影响主进程，重写完成后，新的写入将会写到新的aof中，旧的就会被删除掉。但是此条如果拿出来对比rdb的话还是没有必要算成优点，只是官网显示成优点而已。 aof的缺点 1.性能相对较差：它的操作模式决定了它会对redis的性能有所损耗 2.体积相对更大：尽管是将aof文件重写了，但是毕竟是操作过程和操作结果仍然有很大的差别，体积也毋庸置疑的更大。 3.恢复速度更慢 最后的总结 redis有两种持久化方式，aof和rdb，aof相当于日志记录操作命令，rdb相当于数据的快照。安全性来讲由于aof的记录能够精确到秒级追加甚至逐条追加，而rdb只能是全量复制，aof明显高于rdb。但是从性能来讲rdb就略胜一筹，rdb是redis性能最大化的体现，
它不用每秒监控是否有数据写入，当达到触发条件后就自动fork一个子进程进行全量更新，速度也很快。容灾回复方面rdb更是能够快速的恢复数据，而aof需要读取再写入，相对慢了很多。
redis部署与使用
redis 基础
官网地址https://redis.io/
Redis和 Memcached 是非关系型数据库，也称为NoSQL数据库 ，MySQL 、 Mariadb 、 SQL S erver 、 PostgreSQL 、Oracle 数据库属于关系型数据 RDBMS, Relational Database Management System
redis 简介
Redis (Remote Dictionary S erver在2009年发布开发者Salvatore Sanfilippo是意大利开发者他本想为自己的公司开发一个用于替换MySQL的产品 Redis，但是没有想到他把Redis开源后大受欢迎，短短几年，Redis就有了很大的用户群体，目前国内外使用的公司有知乎网 、新浪微博、GitHub等；
Redis是一个开源的、遵循BSD协议的、 基于内存的而且目前比较流行的键值数据库key value database是一个非关系型数据库redis提供将内存通过网络远程共享的一种服务 ，提供类似功能的还有memcache，但相比memcache redis还提供了易扩展、高性能、具备数据持久性等功能。
Redis在高并发、低延迟环境要求比较高的环境使用量非常广泛，目前redis在DBE nginx月排行榜https://db engines.com/en/ranking 中一直比较靠前，而且一直是键值型存储类的首位 。
redis 对比 memcached
1、支持数据的持久化：可以将内存中的数据保持在磁盘中，重启redis 服务或者服务器之后 可以从 备份文件中 恢复 数据到内存继续使用 。
2、支持更 多 的数据类型：支持 string 字符串 、hash( 哈希 数据 、list( 列表 、set( 集合 、ze t( 有序 集合）。
3、支持数据的备份：可以实现 类似于 数据的 master slave 模式的数据备份，另外 也支持使用快照 +AOF 。
4、支持更大的 value 数据 memcache 单个 key value 最大只支持 1MB ，而 redis 最大 支持 512MB 。
5、Redis 是单线程， 而 memcache 是多线程， 所以 单机 情况下没有 memcache 并发高， 但 redis 支持分布式 集群 以 实现更高的并发 单 Redis 实例可以实现数万并发。
6、支持集群横向扩展：基于redis cluster的横向扩展，可以实现分布式集群，大幅提升性能和数据安全性。
7、都是基于C语言开发。
redis 典型应用场景：
1、Session共享 ：常见于web集群中的Tomcat或者PHP中多web服务器session 共享
2、消息队列ELK 的日志缓存、部分业务的订阅发布系统
3、计数器访问排行榜 、商品浏览数等和次数相关的数值统计场景
4、缓存数据 查询、 电商网站商品信息 、新闻内容
Redis 安装及使用：
官方下载地址： http://download.redis.io/releases/
在centos 系统 上 需要安装 epel 源。
|
1
2
|
[root@rs2keepalived]#yum install redis -y[root@rs2keepalived]#systemctl start redis |
连接Redis用法：
主要分为运维人员的连接和程序的连接
本机非密码连接
|
1
|
# redis-cli |
跨主机非密码连接：
|
1
|
# redis-cli -h HOSTNAME/IP -p PORT |
跨主机密码连接
|
1
|
# redis-cli -h HOSTNAME/IP -p PORT -a PASSWORD |
二、redis配置文件
1、redis基本配置文件
|
1
2
3
4
5
6
7
8
9
10
|
bind 0.0.0.0 监听地址可以用空格隔开后多个监听IPprotected-mode yes #redis3.2之后加入的新特性在没有设置 bind IP和密码的时候只允许访问127.0.0.1 :6379port 6379 监听端口tcp-backlog 511 # 三次握手的 时候 server 端收到client ack确认号之后的队列值，默认不需要改。timeout 0 客户端和Redis服务端的连接超时时间，默认是0，表示永不超时。tcp-keepalive 300 #tcp会话保持时间daemonize yes #默认情况下redis不是作为守护进程运行的，如果你想让它在后台运行，你就把它改成yes, 当redis作为守护进程运行的时候，它会写一个pid到/var/run/redis.pid文件里面，需要改为yes，进行后端运行。supervised systemd #和操作系统相关参数可以设置通过upstart和systemd管理Redis守护进程centos7以后都使用systemdpidfile /var/run/redis_6379.pid #pid文件路径loglevel notice 日志级别，默认即可 |
实现配置文件案例演示：
以源码编译安装的配置文件为例：配置文件在/apps/redis/目录下，此时我们要配置其他目录文件： 源码编译的redis服务，需要启动redis服务：redis-server /apps/redis/etc/redis.conf
源码编译步骤详见链接：https://www.cnblogs.com/struggle-1216/p/12116664.html
1、监听本地IP地址和回环网卡IP地址，允许远程访问redis服务
|
1
2
3
|
[root@rs1~]#vim /apps/redis/etc/redis.confbind 127.0.0.1 192.168.37.17 监听本地IP地址和回环地址protected-mode yes 有此模式就必须监听本地IP地址，否则无法远程连接 |
2、 创建数据、日志及pid目录，将不同文件存放在不同的目录下
|
1
|
[root@rs1~]#mkdir /apps/redis/{data,logs,run} |
修改redis配置文件，将pid文件指定在新建的目录下，如果想开启多个redis，就新建多个pid的端口，只需要修改端口号即可：
如：pidfile /apps/redis/run/redis_6379.pid ，想再开启一个redis，就将端口号改为一个没人用的端口号：pidfile /apps/redis/run/redis_6378.pid
|
1
2
3
|
[root@rs1~]#vim /apps/redis/etc/redis.confpidfile /apps/redis/run/redis_6379.pid logfile "/apps/redis/logs/redis_6379.log" |
此时启动redis服务，就会发现生成了log和pid文件，如果重新启动redis，需要将配置文件用kill -9 进程号 命令杀死进程号才行。
|
1
2
3
4
5
6
7
|
[root@rs1redis]#redis-server /apps/redis/etc/redis.conf[root@rs1redis]#ll /apps/redis/run/redis_6379.pid-rw-r--r-- 1 root root 5 Dec 29 23:21 /apps/redis/run/redis_6379.pid[root@rs1redis]#ll /apps/redis/logs/redis_6379.log-rw-r--r-- 1 root root 1692 Dec 29 23:21 /apps/redis/logs/redis_6379.log[root@centos17~]#ll /apps/redis/data/dump_6379.rdb-rw-r--r-- 1 root root 104 Dec 30 09:33 /apps/redis/data/dump_6379.rdb |
2、redis快照配置文件
|
1
2
3
4
5
6
7
8
9
10
|
databases 16 设置db库数量，默认16个库always-show-logo yes # 在启动 redis 时是否 显示 logsave 900 1 # 在900 秒内有一个键内容发生更改触发快照机制save 300 10 在300 秒内有10个键内容发生更改触发快照机制save 60 10000stop-writes-on-bgsave-error no 快照出错时，是否禁止redis写入操作rdbcompression yes 持久化到 RDB 文件时，是否压缩，"yes" 为压缩，“no” 则反之rdbchecksum yes 是否开启RC64校验，默认是开启dbfilename dump.rdb 快照文件名dir ./ 快照文件保存路径 |
配置文件演示：
1、当我们redis快照备份失败时，如果是yes就无法对redis进行写内容，如果改为no就无法写内容，很重要，改为no。
vim /apps/redis/etc/redis.conf
指定快照存放目录及快照名称：
3、redis配置文件详解
1、replica-serve-stale-data yes # 当从库同主库失去连接或者复制正在进行，从机库有两种运行方式：
1) 如果 replica serve stale data 设置为 yes( 默认设置 ))，从库会继续响应客户端的 读 请求。
2) 如果 replicaserve stale data 设置为 no ，除 去指定的命令之外的任何请求都会返回一个错误 "SYNC with master in progress" 。
2、replica-read-only yes # 是否设置从库只读
3、repl-diskless-sync no 是否使用 socket 方式复制数据， 目前 redis 复制提供两种方式， disk 和 socket 如果新的 slave 连上来或者重连的 slave 无法部分同步，就会执行全量同步， master 会生成 rdb 文件，有2 种方式：
1）disk 方式是 master 创建一个新的进程把 rdb 文件保存到磁盘，再把磁盘上的 rdb 文件传递给 slave socket 是 master 创建一个新的进程，
直接把 rdb 文件以 socket 的方式发给 slave disk 方式的时候，当一个 rdb 保存的过程中，多个 slave 都能共享这个 rdb 文件。
2）socket 的方式就是 一个个 slave顺序复制， 只有在磁盘速度缓慢但是 网络相对较 快的情况下才使用 socket 方式，否则使用默认的disk方式。
4、repl-diskless-sync-delay 30 #diskless 复制的延迟时间， 设置 0为关闭 一旦复制开始还没有结束之前，master 节点不会再接收新 slave 的复制请求， 直到下一次开始。
5、repl-ping-slave-period 10 #slave 根据 master 指定 的时间进行周期性的 PING 监测
6、repl-timeout 60 复制链接超时时间，需要大于 repl ping slave period 否则会 经常 报超时
7、repl-disable-tcp-nodelay no 在 socket 模式下是否在slave 套接字发送 SYNC之后禁用TCP_NODELAY
如果你选择“yes Redis 将使用更少的 TCP 包和带宽来向 slaves 发送数据。但是这 将使数据传输到 slave上有延迟， Linux 内核的默认配置会达到 40毫秒，
如果你选择了 "no" 数据传输到 salve 的延迟将会减少但要使用更多的带宽。
8、repl-backlog-size 1mb 复制缓冲区大小， 只有在 slave 连接之后 才 分配内存 。
9、repl-backlog-ttl 3600 多次时间 master 没有 slave 连接，就清空 backlog 缓冲区 。
10、replica-priority 100 当 master 不可用，Sentinel 会根据 slave 的优先级选举一个 master 。最低的优先级的 slave ，当选 master 。而配置成 0，永远不会被选举。
11、requirepass foobared 设置 redis 连接密码，配置了redis，必须设置密码，防止被入侵之后被黑客搞破坏。
12、rename-command 重命名 一些高 危命令
13、maxclients 10000 最大连接客户端
14、maxmemory 最大内存 单位为 bytes 字节 8G 内存 的 计算方式 8 G ))*1024 ( MB)*1024 ( KB)*1024 Kbyte，用bc命令可以计算；
需要注意的是 slave 的输出缓冲区是不计算在 maxmemory 内 ，此最大内存应该最大占计算机内存的一半，留一部分内存用来做快照使用。
15、appendonly no #是否开启 AOF 日志 记录 默认 redis使用的是 rdb 方式持久化，这种方式在许多应用中已经足够用了。但是 redis 如果中途宕机，会导致可能有几分钟的数据丢失，
根据 save 来策略进行持久化，Append Only File 是另一种持久化方式，可以提供更好的持久化特性。 Redis 会把每次写入的数据在接收后都写入 appendonly.aof 文件，每次启动时 Redis 都会先把这个文件的数据读入内存里，先忽略 RDB 文件。
16、appendfilename "appendonly.aof" #AOF文件名
17、appendfsync everysec #aof 持久化策略的配置 no 表示不执行 fsync 由操作系统保证数据同步到磁盘 ,always 表示每次写入都执行 fsync ，以保证数据同步到磁盘 ,everysec 表示每秒执行一次 fsync ，
可能会导致丢失这 1s 数据。
18、no-appendfsync-on-rewrite no（推荐为yes） 在 aof rewrite 期间 是否对 aof 新记录的 append 暂缓使用文件同步策略 主要考虑磁盘 IO 开支和请求阻塞时间。默认为 no, 表示不暂缓新的 aof 记录仍然会被立即同步
Linux 的默认fsync策略是30 秒，如果为 yes 可能丢失 30 秒数据 ，但由于yes性能较好,而且会避免出现阻塞, 因此比较推荐 。
19、auto-aof-rewrite-percentage 100 # 当 Aof log增长超过指定百分比例时，重写 logfile设置为0表示不自动重写 Aof 日志，重写是为了使 aof 体积保持最小，而确保保存最完整的数据。
20、auto-aof-rewrite -min size 64mb # 触发 aof rewrite 的最小文件大小
21、aof-load-truncated yes 是否加载 由于 其他原因 导致 的 末尾 异常 的 AOF文件主进程被 kill/ 断电等
当文件存在问题时，可以针对不同的文件进行修复操作：可以修复aof和rdb后缀的文件。
打开此功能，就会在/apps/redis/data/目录下生成appendonly.aof后缀的文件。
22、aof-use-rdb-preamble yes #r edis4.0 新增 RDB AOF 混合持久化格式，在开启了这个功能之后， AOF 重写产生的文件将同时包含 RDB 格式的内容和 AOF 格式的内容，其中 RDB 格式的内容用于记录已有的数
据，而 AOF 格式的内存则用于记录最近发生了变化的数据，这样 Redis 就可以同时兼有 RDB 持久化和AOF 持久化的优点（既能够快速地生成重写文件，也能够在出现问题时，快速地载入数据）。
23、luatime-limit 5000 #lua 脚本 的 最大 执行时间单位为毫秒
24、cluster-enabled yes 是否开启集群模式，默认是单机模式
25、cluster-config-file-nodes 6379.conf 由 node节点自动生成的集群配置 文件
26、cluster-node-timeout 15000 集群中node节点连接 超时时间
27、cluster-replica-validity-factor 10 在 执行故障转移的时候可能有些节点和 master 断开一段时间数据比较旧 这些 节点就 不适用于选举为 master 超过这个时间的就不会被进行故障转移
28、cluster-migration-barrier 1 一个主节点拥有的至少正常工作的从节点 即如果主节点的 slave 节点故障后， 会 将多余的从节点 分配 到当前主节点 成为 其 新的 从节点。
29、cluster-require-full-coverage no 集群 槽位覆盖 如果 一个 主库宕机 且 没有备库就会出现集群槽位不全 那么 yes 情况下 redis 集群 槽位 验证不全就不再对外提供服务，
而 no 则可以继续使用但是会出现查询数据查不到的情况 (因为有数据丢失) 。
#Slow log 是 Redis 用来记录查询执行时间的日志系统 slow log 保存在内存里面，读写速度非常快，因此你可以放心地使用它，不必担心因为开启slow log而损害 Redis 的速度。
30、slowlog-log-slower than 10000 以微秒 为单位 的 慢日志记录， 为 负数会禁用慢日志，为0会记录 每个命令操作。
31、slowlog-max-len 128 # 记录多少条慢日志 保存在 队列，超出后会删除最早的，以此滚动删除
测试效果：
|
1
2
3
4
5
6
7
8
|
127.0.0.1:6379> slowlog len(integer) 14127.0.0.1:6379> slowlog get1) 1) (integer) 142) (integer) 15446906173) (integer) 44) 1) "slowlog"127.0.0.1:6379> SLOWLOG reset |
redis 持久化：
redis虽然是一个内存级别的缓存程序，即 redis 是使用内存进行数据的缓存的，但是其可以将内存的数据按照一定的策略保存到硬盘上，从而实现数据持久保存的目的， redis 支持两种不同方式的数据持久化保存机制，分别是RDB和AOF。
RDB 模式
1、RDB基于时间的快照， 只保留 当前最新的一次快照， 特点是执行速度比较快，缺点是可能会丢失从上次快照到当前快照未完成之间的数据。
2、RDB实现的具体过程 R edis 从主进程先 fork 出一个子进程，使用写时复制机制，子进程将内存的数据保存为一个临时文件，
比如 dump.rdb.temp ，当数据保存完成之后再将上一次保存的 RDB 文件替换掉，然后关闭子进程，这样可以保存每一次做RDB快照的时候保存的数据都是完整的，
因为直接替换RDB文件的时候可能会出现突然断电等问题而导致 RDB 文件还没有保存完整就突然关 机停止保存而导致
数据丢失的情况，可以手动将每次生成的 RDB 文件进程备份，这样可以最大化保存历史数据。
RDB 模式的优缺点：
优点：
1、RDB 快照 保存了某个时间点的数据，可以通过脚本执行 bgsave 非 阻塞 或者 save( 阻塞 命令自定义时间点备份，可以保留多个备份，当出现问题可以恢复到不同时间点的版本。
2、可以最大化 IO的性能，因为父进程在保存 RDB 文件的时候唯一要做的是 fork 出一个子进程，然后的操作都会有这个子进程操作，父进程无需任何的 IO操作,RDB在大量数据比如几个G的数据，恢复的速度比AOF的快。
缺点
1、不能时时的保存数据，会丢失自上一次执行 RDB 备份到当前的内存数据
2、数据量非常大的时候，从父进程 fork 的时候需要一点时间，可能是毫秒或者秒
AOF 模式
1、AOF:按照 操作顺序依次 将 操作 添加 到 指定 的日志文件当中，特点是数据安全性相对较高，缺点是即使有些操作是重复的也会全部记录。
2、AOF和 RDB一样使用了写时复制机制， AOF 默认为每秒钟 fsync 一次，即将执行的命令保存到 AOF 文件当中，这样即使 redis 服务器发生故障的话顶多也就丢失 1 秒钟之内的数据，也可以设置不同的 fsync
策略，或者设置每次执行命令的时候执行 fsync fsync 会在后台执行线程，所以主线程可以继续处理用户的正常请求而不受到写入 AOF 文件的 IO 影响。
AOF 模式优缺点
1、AOF的文件大小要大于RDB格式的文件
2、根据所使用的fsync 策略 (fsync 是同步内存中 redis 所有已经修改的文件到存储设备 ))，默认是appendfsync everysec 即每秒执行一次 fsync
三、redis数据类型
字符串 string
字符串是所有编程语言中 最常见 的和最常 用的数据类型，而且也是 redis 最基本的数据类型之一，而且redis中所有的 key 的类型都是字符串。
添加 一个 key
|
1
2
3
4
5
6
7
8
|
127.0.0.1:6379> set key1 value1OK127.0.0.1:6379> get key1"value1"127.0.0.1:6379> TYPE key1string127.0.0.1:6379> SET name2 jack2 ex 3 设置自动过期时间OK |
获取一个 key 的内容：
|
1
2
|
127.0.0.1:6379> get key1"value1" |
删除一个 key
|
1
2
3
|
127.0.0.1:6379> DEL key1(integer) 1 |
批量 设置多个 key
|
1
2
|
127.0.0.1:6379> MSET key1 value1 key2 value2OK |
批量 获取 多个 key
|
1
2
|
127.0.0.1:6379> MSET key1 value1 key2 value2OK |
追加 数据：
|
1
2
3
4
5
|
127.0.0.1:6379> APPEND key1 append(integer) 12127.0.0.1:6379> get key1"value1append" |
数值 递增：
|
1
2
3
4
5
6
|
127.0.0.1:6379> set num 10OK127.0.0.1:6379> INCR num(integer) 11127.0.0.1:6379> get num"11" |
数值递减：
|
1
2
3
4
5
6
|
127.0.0.1:6379> set num 10OK127.0.0.1:6379> DECR num(integer) 9127.0.0.1:6379> get num"9" |
返回 字符串 key 长度：
|
1
2
3
|
127.0.0.1:6379> STRLEN key1(integer) 12 |
列表 list
列表是一个双向可读写的管道 其头部是左侧尾部是右侧，一个列表最多可以包含 2^32 1 个元素即
4294967295 个 元素。
生成列表 并插入数据：
|
1
2
3
4
5
|
127.0.0.1:6379> LPUSH list1 jacktom jhon(integer) 3127.0.0.1:6379> TYPE list1list |
消息队列
消息队列 主要 分为两种，分别是 生产者 消费者模式和发布者订阅者模式，这两种模式 Redis 都 支持
生产者消费者模式：
在生产者消费者 Producer/Consumer 模式下， 上层 应用 接收到 的外部请求 后 开始处理 其 当前步骤的操作，
在执行完成后将 已经 完成的操作发送至 指定的频道 channel 当中 ，并 由其 下层的应用监听该频道并继续下一步的操作， 如果 其处理完成 后 没有下一步的操作就直接返回 数据 给外部请求，如果还有
下一步的操作就 再将任务发布 到另外一个频道， 由 另外一个消费者 继续 监听和处理。
模式介绍
生产者 消费者模式下， 多个 消费者同时监听一个队里，但是 一个 消息只能被 最先抢到消息的消费者消费,即消息任务是一次性 读取 和处理,
此模式在分布式业务 架构 中非常常用 比较 常用 的软件还有RabbitMQ、 K afka 、 RocketMQ 、 ActiveMQ 等。
队列介绍
队列当中的消息由不同的生产者写入也会有不同的消费者取出进行消费处理，但是一个消息一定是只能被取出一次也就是被消费一次。
发布者订阅模式：
模式简介：
在 发布者订阅者模式下，发布者将消息发布到指定的 channel 里面 凡是 监听该 channel 的消费者都会 收到 同样的一份消息，
这种模式类 似于是收音机模式，即凡是收听某个频道的听众 都会 收到主持人发布的 相同 的消息 内容。
此模式 常用语 群聊天 、 群通知、群 公告 等场景。
|
1
2
3
|
Subscriber ：订阅者Publisher 发布者Channel 频道 |
redis其他命令
CONFIG
config命令用于查看当前redis配置、以及不重启更改redis配置等，修改的都是临时的配置，重启redis服务就会失效，最终还是需要修改到配置文件中。
更改最大内存：
改为最大物理机内存的一半大小
|
1
2
3
4
5
|
127.0.0.1:6379> CONFIG set maxmemory 8589934592OK127.0.0.1:6379> CONFIG get maxmemory1) "maxmemory"2) "8589934592" |
设置连接密码
|
1
2
|
127.0.0.1:6379> CONFIG SET requirepass 123456OK |
获取当前配置内容：
info：显示当前redis运行状态
SELECT：切换数据库
DBSIZE：返回当前库下的所有key数量
keys:查看当前库下的所有key
BGSAVE：手动在后台执行RDB 持久化 操作
FLUSHDB：强制清空当前库中的所有key
FLUSHALL：强制清空当前 redis 服务器所有 数据 库 中的所有 key 即删除所有数据
参考文档
https://www.cnblogs.com/struggle-1216/p/12117211.html
浙公网安备 33010602011771号