Redis

大家好，我是 为前端娱乐圈操碎了心的小迷妹 ，每天推荐一个小工具/源码，装满你的收藏夹，每天分享一个小技巧，让你轻松节省开发效率，实现不加班不熬夜不掉头发，是我的目标。 作为一名 GitHub 资深用户，我每日都会花不少时间泡在 GitHub 社区上面，有时候甚至于连吃饭都会用手机刷两下，看看最近有什么值得关注的项目。 顺便找一些自己比较喜欢的项目源码，下载下来到自己的本地查看，并且学习到别人的精华所在，下次遇到的时候，很多功能都可以直接借鉴过来，尤其是在工作的过程之中，实现一个客户的需求，很快就能做得出来，也节省了很多一个个字母敲在键盘上的时间。 今天推荐的这个项目是「netease-cloud-music-community」，是一个参照网易云音乐云村做的小程序社区，后端技术栈为 Java，SpringBoot，MySQL，Redis，前端技术栈为 uni-app。 功能简介 微信登录，发文本动态，发图文动态，发视频动态，关注，转发，评论，点赞，收藏等等 项目运行截图 技术栈 后端：Java，SpringBoot，MyBatis，MySQL，Redis 前端：uni-app 开发环境 后端：IntelliJ IDEA 前端：HbuilderX，微信开发者工具，QQ小程序开发者工具 项目运行 后端 创建数据库，执行根目录中的live.sql

Redis提供了两种持久化方案：RDB持久化和AOF持久化，一个是快照的方式，一个是类似日志追加的方式 RDB快照持久化 RDB持久化是通过快照的方式，即在指定的时间间隔内将内存中的数据集快照写入磁盘。在创建快照之后，用户可以备份该快照，可以将快照复制到其他服务器以创建相同数据的服务器副本，或者在重启服务器后恢复数据。RDB是Redis默认的持久化方式 save 900 1 当时间到900秒时，如果至少有1个key发生变化，就会自动触发 bgsave 命令创建快照 save 300 10 当时间到300秒时，如果至少有10个key发生变化，就会自动触发 bgsave 命令创建快照 save 60 10000 当时间到60秒时，如果至少有10000个key发生变化，就会自动触发 bgsave 命令创建快照 AOF持久化 除了RDB持久化，Redis还提供了AOF（Append Only File）持久化功能，AOF持久化会把被执行的写命令写到AOF文件的末尾，记录数据的变化。 一般设置1秒同步一次命令 AOF重写的目的就是减小AOF文件的体积，不过值得注意的是：AOF文件重写并不需要对现有的AOF文件进行任何读取、分享和写入操作，而是通过读取服务器当前的数据库状态来实现的 数据恢复 Redis4.0开始支持RDB和AOF的混合持久化（可以通过配置项 aof-use-rdb

Redis Redis 是高性能的基于内存的 NoSQL 数据库。因为内存是比较宝贵的资源，无法无限制使用，所以 Redis 提供了： 键过期策略 来防止内存饱和。 内存淘汰策略 来使得内存饱和之后继续对外提供服务。 内存过期策略 expire命令 Redis 提供了 expire 命令来给一个键(key)设置过期时间： redis> SET foo "bar" "OK" redis> EXPIRE foo 10 (integer) 1 redis> TTL foo (integer) 10 类似 setex 命令，也可以对目标键设置过期时间，但它其实相当于 set 和 expire 两个命令的原子操作。 expire 只能作用于 Redis 中的键，所以无法对 list 或者 set 中的元素设置过期时间。对某个键调用删除(delete)或者重写(override)的命令如 del , set , getset 之后，会清除键上的过期时间；调用 persist 命令也会清除键上的过期时间；而修改键内容的操作如 incr , hset ，则不会对键的过期时间产生影响。 键的过期原理 Redis 键有两种过期方式：被动方式(passive way)和主动方式(active way)。 被动删除 当某个设置了过期时间的键被访问时，如果发现它已经过期， Redis

1、RDB和AOF两种持久化机制的介绍 2、RDB持久化机制的优点 3、RDB持久化机制的缺点 4、AOF持久化机制的优点 5、AOF持久化机制的缺点 6、RDB和AOF到底该如何选择 我们已经知道对于一个企业级的redis架构来说，持久化是不可减少的 企业级redis集群架构：海量数据、高并发、高可用 持久化主要是做灾难恢复，数据恢复，也可以归类到高可用的一个环节里面去 比如你redis整个挂了，然后redis就不可用了，你要做的事情是让redis变得可用，尽快变得可用 重启redis，尽快让它对外提供服务，但是就像上一讲说，如果你没做数据备份，这个时候redis启动了，也不可用啊，数据都没了 很可能说，大量的请求过来，缓存全部无法命中，在redis里根本找不到数据，这个时候就死定了，缓存雪崩问题，所有请求，没有在redis命中，就会去mysql数据库这种数据源头中去找，一下子mysql承接高并发，然后就挂了 mysql挂掉，你都没法去找数据恢复到redis里面去，redis的数据从哪儿来？从mysql来。。。 具体的完整的缓存雪崩的场景，还有企业级的解决方案，到后面讲 如果你把redis的持久化做好，备份和恢复方案做到企业级的程度，那么即使你的redis故障了，也可以通过备份数据，快速恢复，一旦恢复立即对外提供服务 redis的持久化，跟高可用，是有关系的

1.安装ansible eple源 cat <<eof>>/etc/yum.repos.d/ my.repo [epel] name = epel baseurl =http://mirrors.aliyun.com/epel/7Server/x86_64/ enable =1 gpgcheck = 0 eof yum -y install ansible 安装 2.安装ansible 常用帮助 ansible-doc -h # 列出相关榜示 [root@4cd65df9495a /] # ansible-doc -l | grep yum#用于列出某个模块 [root@4cd65df9495a /] # ansible-doc -s yum #获取参数 -C # 不对远程主机做出一些改变，而是预测某些可能发生的改变 -f # 指定并行处理的进程数量，默认为5个 --list-hosts # 不会执行任何操作，而是列出匹配到的主机列表 -m # 指定要执行的模块名，默认的模块为"command" -k # 密码 --syntax-check # 检查语法 3.andible.cfg配置参数 Ansible有很多配置参数，以下是几个默认的配置参数： inventory = /etc/ansible/hosts # inventory的位子 library = /usr/share

一、介绍 有时候，Redis实例需要在很短的时间内加载大量先前存在或用户生成的数据，以便尽可能快地创建数百万个键。这就是所谓的批量插入，本文档的目标是提供有关如何以尽可能快的速度向Redis提供数据的信息。如果想查看英文原文，地址如下： https://redis.io/topics/mass-insert 二、操作详解 话不多说，直接进入主题了。 1、使用协议，卢克（Use the protocol, Luke） 使用普通Redis客户端的方式执行批量插入的操作并不是一个很好的办法，原因如下：发送一个命令的方式很慢，因为您必须为每个命令都会有往返的时间消耗。虽然可以使用管道模式来操作，但为了批量插入多条记录，您需要在读取回复的同时编写新命令，以确保尽可能快地插入。 另外，只有一小部分客户端支持非阻塞 I/O 操作，而且并不是所有的客户端都能够以最大化吞吐量这种有效的方式来解析这些回复。 由于以上这些原因，将大量数据导入Redis的首选方式是生成包含Redis协议的文本文件（原始格式），以便调用插入所需数据所需的命令。 例如，如果我需要生成一个大型数据集，其中包含数十亿个键：“keyN - > ValueN”，我将创建一个包含如下Redis协议格式的命令的文件： SET Key0 Value0 SET Key1 Value1 ... SET KeyN ValueN 一旦创建了该文件

1、下载Redis安装文件， 我选择的是 3.0.504 版本，有zip或msi可供下载。 2.解压缩后，打开安装目录 双击redis-server.exe启动redis服务器，双击redis-cli.exe打开redis客户端。或者执行命令行redis-server redis.windows.conf。 redis的常用命令，使用命令进行安装和注册redis到window服务。 安装命令：redis-server.exe --service-install redis.windows.conf --loglevel verbose 启动服务命令：redis-server.exe --service-start 关闭服务命令：redis-server.exe --service-stop 注册redis到window服务命令：redis-server --service-install redis.windows-service.conf --loglevel verbose 3、看到上图就表示redis服务启动成功。接下来将redis添加到windows服务，避免关闭命令行窗口服务停止。执行添加命令：redis-server --service-install redis.windows-service.conf --loglevel verbose。输入命令没有报错

原文: Redis进阶实践之十七 Redis协议的规范 一、介绍 Redis客户端使用RESP（Redis的序列化协议）协议与Redis的服务器端进行通信。 虽然该协议是专门为Redis设计的，但是该协议也可以用于其他 客户端-服务器 （Client-Server）软件项目。 RESP是对以下几件事情的折中实现： 1、实现简单 2、解析快速 3、人类可读 RESP可以序列化不同的数据类型，如整数（integers），字符串（strings），数组（arrays）。它还使用了一个特殊的类型来表示错误（errors）。 请求以字符串数组的形式来表示要执行命令的参数从客户端发送到Redis服务器 。Redis使用命令特有（command-specific）数据类型作为回复。 RESP协议是二进制安全的，并且不需要处理从一个进程传输到另一个进程的块数据的大小，因为它使用前缀长度（prefixed-length）的方式来传输块数据的。 （RESP is binary-safe and does not require processing of bulk data transferred from one process to another, because it uses prefixed-length to transfer bulk data.） 注意：该文章所说的协议是仅用于

好多年前看过redis的代码，那个时候还是2.6的版本，集群和哨兵还没加入正式代码，这几年redis发展的好快。简略翻译一篇文章redis的https://redis.io/topics/protocol redis的客户端和服务器通过一种叫 RESP (REdis Serialization Protocol)协议进行通讯。虽然他是为redis设计的协议，但是也可以用到其他的CS架构软件里。 RESP的设计主要考虑了以下几个要求： 容易实现 快速解析 人类可读 RESP能够序列化不同的数据类型像整型，字符串，数组。还有一种专门为错误设计的类型。从客户端发给服务器的请求是一个代表命令参数的数组。Redis返回一个该命令指定的数据类型。 RESP是二进制安全的而且从一个进程发块数据给另一个进程的时候不需要做转换，因为他会在块数据之前加上长度。 注意：这个协议只用于redis的客户端和服务器的信息交互。redis集群的node之间使用另一种二进制协议来交换信息。 网络层 redis的客户端和服务器通过6379端口建立连接。 虽然RESP是不依赖TCP协议的，但是这个协议只用在TCP连接上（或者是其他的流协议，比如unix套接字）。 请求-应答模型 redis能够接收带各种类型参数的命令。处理收到的命令并且返回应答。这是最简单的模型，但是有两个例外： redis支持管道