Redis基础（一）

最新推荐文章于 2023-05-07 11:30:44 发布
最新推荐文章于 2023-05-07 11:30:44 发布
阅读量507 收藏
点赞数
分类专栏： 笔记 领域知识 文章标签： redis 数据库 java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_43820687/article/details/125841929
版权

redis

什么是redis？

Redis是一款内存高速缓存数据库。Redis全称为：Remote Dictionary Server（远程数据服务），使用C语言编写，Redis是一个key-value存储系统（键值存储系统），支持丰富的数据类型，如：String、list、set、zset、hash。
Redis是一种支持key-value等多种数据结构的存储系统。可用于缓存，事件发布或订阅，高速队列等场景。支持网络，提供字符串，哈希，列表，队列，集合结构直接存取，基于内存，可持久化。

docker下安装redis

mkdir -p /mydata/redis/conf
touch /mydata/redis/conf/redis.conf

docker run -p 6379:6379 --name redis -v /mydata/redis/data:/data \
-v /mydata/redis/conf/redis.conf:/etc/redis/redis.conf \
-d redis redis-server /etc/redis/redis.conf

redis.conf地址
daemonize=NO 非后台模式，如果为YES 会的导致 redis 无法启动，因为后台会导致docker无任务可做而退出。
127.0.0.1改成0.0.0.0 否则只能本地访问

5种基础数据类型

请添加图片描述
在这里插入图片描述

String字符串

String是redis中最基本的数据类型，一个key对应一个value。

下图是一个String类型的实例，其中键为hello，值为world
请添加图片描述
命令使用
在这里插入图片描述
命令执行

127.0.0.1:6379> set hello world
OK
127.0.0.1:6379> get hello
"world"
127.0.0.1:6379> del hello
(integer) 1
127.0.0.1:6379> get hello
(nil)
127.0.0.1:6379> set counter 2
OK
127.0.0.1:6379> get counter
"2"
127.0.0.1:6379> incr counter
(integer) 3
127.0.0.1:6379> get counter
"3"
127.0.0.1:6379> incrby counter 100
(integer) 103
127.0.0.1:6379> get counter
"103"
127.0.0.1:6379> decr counter
(integer) 102
127.0.0.1:6379> get counter
"102"

实战应用

  1. 缓存：经典使用场景，把常用信息，字符串，图片或者视频等信息放到redis中，redis作为缓存层，mysql做持久化层，降低mysql的读写压力。
  2. 计数器：redis是单线程模型，一个命令执行完才会执行下一个，同时数据可以一步落地到其他的数据源。
  3. session：常见方案spring session + redis实现session共享。

List列表

Redis中的List其实就是链表（Redis用双端链表实现List）。
使用List结构，我们可以轻松地实现最新消息排队功能（比如新浪微博的TimeLine）。List的另一个应用就是消息队列，可以利用List的 PUSH 操作，将任务存放在List中，然后工作线程再用 POP 操作将任务取出进行执行。
请添加图片描述
命令使用
在这里插入图片描述
命令执行

127.0.0.1:6379> lpush mylist 1 2 ll ls mem
(integer) 5
127.0.0.1:6379> lrange mylist 0 -1
1) "mem"
2) "ls"
3) "ll"
4) "2"
5) "1"
127.0.0.1:6379> lindex mylist -1
"1"
127.0.0.1:6379> lindex mylist 10        # index不在 mylist 的区间范围内
(nil)

实战场景
微博TimeLine: 有人发布微博，用lpush加入时间轴，展示新的列表信息。
消息队列

Set集合

Redis 的 Set 是 String 类型的无序集合。集合成员是唯一的，这就意味着集合中不能出现重复的数据。
Redis 中集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。

图例
请添加图片描述
命令使用
在这里插入图片描述
命令执行

127.0.0.1:6379> sadd myset hao hao1 xiaohao hao
(integer) 3
127.0.0.1:6379> smembers myset
1) "xiaohao"
2) "hao1"
3) "hao"
127.0.0.1:6379> sismember myset hao
(integer) 1

实战场景
标签（tag）,给用户添加标签，或者用户给消息添加标签，这样有同一标签或者类似标签的可以给推荐关注的事或者关注的人。
点赞，或点踩，收藏等，可以放到set中实现

Hash散列

Redis hash 是一个 string 类型的 field（字段） 和 value（值） 的映射表，hash 特别适合用于存储对象
请添加图片描述
命令使用
在这里插入图片描述
命令执行

127.0.0.1:6379> hset user name1 hao
(integer) 1
127.0.0.1:6379> hset user email1 hao@163.com
(integer) 1
127.0.0.1:6379> hgetall user
1) "name1"
2) "hao"
3) "email1"
4) "hao@163.com"
127.0.0.1:6379> hget user user
(nil)
127.0.0.1:6379> hget user name1
"hao"
127.0.0.1:6379> hset user name2 xiaohao
(integer) 1
127.0.0.1:6379> hset user email2 xiaohao@163.com
(integer) 1
127.0.0.1:6379> hgetall user
1) "name1"
2) "hao"
3) "email1"
4) "hao@163.com"
5) "name2"
6) "xiaohao"
7) "email2"
8) "xiaohao@163.com"

实战场景
缓存： 能直观，相比string更节省空间，的维护缓存信息，如用户信息，视频信息等。

Zset有序集合

Redis 有序集合和集合一样也是 string 类型元素的集合,且不允许重复的成员。不同的是每个元素都会关联一个 double 类型的分数。redis 正是通过分数来为集合中的成员进行从小到大的排序。
著作权归https://pdai.tech所有。
链接：https://pdai.tech/md/db/nosql-redis/db-redis-data-types.html

有序集合的成员是唯一的, 但分数(score)却可以重复。有序集合是通过两种数据结构实现：

  1. 压缩列表(ziplist): ziplist是为了提高存储效率而设计的一种特殊编码的双向链表。它可以存储字符串或者整数，存储整数时是采用整数的二进制而不是字符串形式存储。它能在O(1)的时间复杂度下完成list两端的push和pop操作。但是因为每次操作都需要重新分配ziplist的内存，所以实际复杂度和ziplist的内存使用量相关
  2. 跳跃表（zSkiplist): 跳跃表的性能可以保证在查找，删除，添加等操作的时候在对数期望时间内完成，这个性能是可以和平衡树来相比较的，而且在实现方面比平衡树要优雅，这是采用跳跃表的主要原因。跳跃表的复杂度是O(log(n))。
    请添加图片描述
    命令执行
127.0.0.1:6379> zadd myscoreset 100 hao 90 xiaohao
(integer) 2
127.0.0.1:6379> ZRANGE myscoreset 0 -1
1) "xiaohao"
2) "hao"
127.0.0.1:6379> ZSCORE myscoreset hao
"100"

实战场景
**排行榜：**有序集合经典使用场景。例如小说视频等网站需要对用户上传的小说视频做排行榜，榜单可以按照用户关注数，更新时间，字数等打分，做排行

3种特殊类型

HyperLogLogs（基数统计）

什么是基数？
举个例子，A = {1, 2, 3, 4, 5}， B = {3, 5, 6, 7, 9}；那么基数（不重复的元素）= 1, 2, 4, 6, 7, 9； （允许容错，即可以接受一定误差）
HyperLogLogs 基数统计用来解决什么问题？
这个结构可以非常省内存的去统计各种计数，比如注册 IP 数、每日访问 IP 数、页面实时UV、在线用户数，共同好友数等

它的优势体现在哪？
一个大型的网站，每天 IP 比如有 100 万，粗算一个 IP 消耗 15 字节，那么 100 万个 IP 就是 15M。而 HyperLogLog 在 Redis 中每个键占用的内容都是 12K，理论存储近似接近 2^64 个值，不管存储的内容是什么，它一个基于基数估算的算法，只能比较准确的估算出基数，可以使用少量固定的内存去存储并识别集合中的唯一元素。而且这个估算的基数并不一定准确，是一个带有 0.81% 标准错误的近似值（对于可以接受一定容错的业务场景，比如IP数统计，UV等，是可以忽略不计的）。

相关命令使用

127.0.0.1:6379> pfadd key1 a b c d e f g h i	# 创建第一组元素
(integer) 1
127.0.0.1:6379> pfcount key1					# 统计元素的基数数量
(integer) 9
127.0.0.1:6379> pfadd key2 c j k l m e g a		# 创建第二组元素
(integer) 1
127.0.0.1:6379> pfcount key2
(integer) 8
127.0.0.1:6379> pfmerge key3 key1 key2			# 合并两组：key1 key2 -> key3 并集
OK
127.0.0.1:6379> pfcount key3
(integer) 13

Bitmap （位存储）

Bitmap 即位图数据结构，都是操作二进制位来进行记录，只有0 和 1 两个状态。

用来解决什么问题？
比如：统计用户信息，活跃，不活跃！ 登录，未登录！ 打卡，不打卡！ 两个状态的，都可以使用 Bitmaps！
如果存储一年的打卡状态需要多少内存呢？ 365 天 = 365 bit 1字节 = 8bit 46 个字节左右！
相关命令使用
使用bitmap 来记录 周一到周日的打卡！ 周一：1 周二：0 周三：0 周四：1 …

127.0.0.1:6379> setbit sign 0 1
(integer) 0
127.0.0.1:6379> setbit sign 1 1
(integer) 0
127.0.0.1:6379> setbit sign 2 0
(integer) 0
127.0.0.1:6379> setbit sign 3 1
(integer) 0
127.0.0.1:6379> setbit sign 4 0
(integer) 0
127.0.0.1:6379> setbit sign 5 0
(integer) 0
127.0.0.1:6379> setbit sign 6 1
(integer) 0
查看某一天是否有打卡！
127.0.0.1:6379> getbit sign 3
(integer) 1
127.0.0.1:6379> getbit sign 5
(integer) 0
统计操作，统计 打卡的天数！
127.0.0.1:6379> bitcount sign # 统计这周的打卡记录，就可以看到是否有全勤！
(integer) 3

geospatial (地理位置)

geoadd

添加地理位置

127.0.0.1:6379> geoadd china:city 118.76 32.04 manjing 112.55 37.86 taiyuan 123.43 41.80 shenyang
(integer) 3
127.0.0.1:6379> geoadd china:city 144.05 22.52 shengzhen 120.16 30.24 hangzhou 108.96 34.26 xian
(integer) 3

规则

两级无法直接添加，我们一般会下载城市数据(这个网址可以查询 GEO： http://www.jsons.cn/lngcode)！
有效的经度从-180度到180度。
有效的纬度从-85.05112878度到85.05112878度

geopos

获取指定的成员的经度和纬度

127.0.0.1:6379> geopos china:city taiyuan manjing
1) 1) "112.54999905824661255"
   1) "37.86000073876942196"
2) 1) "118.75999957323074341"
   1) "32.03999960287850968"

geodist

单位如下
m
km
mi 英里
ft 英尺

127.0.0.1:6379> geodist china:city taiyuan shenyang m
"1026439.1070"
127.0.0.1:6379> geodist china:city taiyuan shenyang km
"1026.4391"

georadius

附近的人 ==> 获得所有附近的人的地址, 定位, 通过半径来查询

127.0.0.1:6379> georadius china:city 110 30 1000 km			以 100,30 这个坐标为中心, 寻找半径为1000km的城市
1) "xian"
2) "hangzhou"
3) "manjing"
4) "taiyuan"
127.0.0.1:6379> georadius china:city 110 30 500 km
1) "xian"
127.0.0.1:6379> georadius china:city 110 30 500 km withdist
1) 1) "xian"
   2) "483.8340"
127.0.0.1:6379> georadius china:city 110 30 1000 km withcoord withdist count 2
1) 1) "xian"
   2) "483.8340"
   3) 1) "108.96000176668167114"
      2) "34.25999964418929977"
2) 1) "manjing"
   2) "864.9816"
   3) 1) "118.75999957323074341"
      2) "32.03999960287850968"

参数 key 经度 纬度 半径 单位 [显示结果的经度和纬度] [显示结果的距离] [显示的结果的数量]

georadiusbymember

显示与指定成员一定半径范围内的其他成员

127.0.0.1:6379> georadiusbymember china:city taiyuan 1000 km
1) "manjing"
2) "taiyuan"
3) "xian"
127.0.0.1:6379> georadiusbymember china:city taiyuan 1000 km withcoord withdist count 2
1) 1) "taiyuan"
   2) "0.0000"
   3) 1) "112.54999905824661255"
      2) "37.86000073876942196"
2) 1) "xian"
   2) "514.2264"
   3) 1) "108.96000176668167114"
      2) "34.25999964418929977"

参数与 georadius 一样

geohash(较少使用)

该命令返回11个字符的hash字符串

127.0.0.1:6379> geohash china:city taiyuan shenyang
1) "ww8p3hhqmp0"
2) "wxrvb9qyxk0"

将二维的经纬度转换为一维的字符串, 如果两个字符串越接近, 则距离越近

Redis持久化

RDB

RDB 就是 Redis DataBase 的缩写，中文名为快照/内存快照，RDB持久化是把当前进程数据生成快照保存到磁盘上的过程，由于是某一时刻的快照，那么快照中的值要早于或者等于内存中的值。

手动触发

save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存 比较大的实例会造成长时间阻塞，线上环境不建议使用
bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子 进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短
bgsave流程图如下所示
请添加图片描述
著作权归https://pdai.tech所有。
链接：https://pdai.tech/md/db/nosql-redis/db-redis-x-rdb-aof.html

具体流程如下：

  1. redis客户端执行bgsave命令或者自动触发bgsave命令；
  2. 主进程判断当前是否已经存在正在执行的子进程，如果存在，那么主进程直接返回；
  3. 如果不存在正在执行的子进程，那么就fork一个新的子进程进行持久化数据，fork过程是阻塞的，fork操作完成后主进程即可执行其他操作；
  4. 子进程先将数据写入到临时的rdb文件中，待快照数据写入完成后再原子替换旧的rdb文件；
  5. 同时发送信号给主进程，通知主进程rdb持久化完成，主进程更新相关的统计信息（info Persitence下的rdb_*相关选项）。

自动触发

  1. redis.conf中配置save m n，即在m秒内有n次修改时，自动触发bgsave生成rdb文件；
  2. 主从复制时，从节点要从主节点进行全量复制时也会触发bgsave操作，生成当时的快照发送到从节点；
  3. 执行debug reload命令重新加载redis时也会触发bgsave操作；
  4. 默认情况下执行shutdown命令时，如果没有开启aof持久化，那么也会触发bgsave操作；

redis.conf中配置RDB

# 周期性执行条件的设置格式为
save <seconds> <changes>

# 默认的设置为：
save 900 1
save 300 10
save 60 10000

# 以下设置方式为关闭RDB快照功能
save ""

著作权归https://pdai.tech所有。
链接：https://pdai.tech/md/db/nosql-redis/db-redis-x-rdb-aof.html

以上三项默认信息设置代表的意义是： 如果900秒内有1条Key信息发生变化，则进行快照； 如果300秒内有10条Key信息发生变化，则进行快照； 如果60秒内有10000条Key信息发生变化，则进行快照。读者可以按照这个规则，根据自己的实际请求压力进行设置调整。

其他配置

// An highlighted block
var foo = 'bar';# 文件名称
dbfilename dump.rdb

# 文件保存路径
dir /home/work/app/redis/data/

# 如果持久化出错，主进程是否停止写入
stop-writes-on-bgsave-error yes

# 是否压缩
rdbcompression yes

# 导入时是否检查
rdbchecksum yes

优缺点

优点
RDB文件是某个时间节点的快照，默认使用LZF算法进行压缩，压缩后的文件体积远远小于内存大小，适用于备份、全量复制等场景；
Redis加载RDB文件恢复数据要远远快于AOF方式；
缺点 ：
RDB方式实时性不够，无法做到秒级的持久化；
每次调用bgsave都需要fork子进程，fork子进程属于重量级操作，频繁执行成本较高；
RDB文件是二进制的，没有可读性，AOF文件在了解其结构的情况下可以手动修改或者补全；
版本兼容RDB文件问题；

AOF

Redis是“写后”日志，Redis先执行命令，把数据写入内存，然后才记录日志。日志里记录的是Redis收到的每一条命令，这些命令是以文本形式保存。PS: 大多数的数据库采用的是写前日志（WAL），例如MySQL，通过写前日志和两阶段提交，实现数据和逻辑的一致性。

而AOF日志采用写后日志，即先写内存，后写日志。
请添加图片描述

如何实现AOF

AOF日志记录Redis的每个写命令，步骤分为：命令追加（append）、文件写入（write）和文件同步（sync）。

著作权归https://pdai.tech所有。
链接：https://pdai.tech/md/db/nosql-redis/db-redis-x-rdb-aof.html

命令追加
当AOF持久化功能打开了，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器的 aof_buf 缓冲区。
文件写入和同步
关于何时将 aof_buf 缓冲区的内容写入AOF文件中，Redis提供了三种写回策略：
请添加图片描述
Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；
Everysec，每秒写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；
**No，**操作系统控制的写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

三种写回策略的优缺点 上面的三种写回策略体现了一个重要原则：trade-off，取舍，指在性能和可靠性保证之间做取舍。 关于AOF的同步策略是涉及到操作系统的 write 函数和 fsync 函数的，在《Redis设计与实现》中是这样说明的：

为了提高文件写入效率，在现代操作系统中，当用户调用write函数，将一些数据写入文件时，操作系统通常会将数据暂存到一个内存缓冲区里，当缓冲区的空间被填满或超过了指定时限后，才真正将缓冲区的数据写入到磁盘里。

这样的操作虽然提高了效率，但也为数据写入带来了安全问题：如果计算机停机，内存缓冲区中的数据会丢失。为此，系统提供了fsync、fdatasync同步函数，可以强制操作系统立刻将缓冲区中的数据写入到硬盘里，从而确保写入数据的安全性。

redis.conf中配置AOF

默认情况下，Redis是没有开启AOF的，可以通过配置redis.conf文件来开启AOF持久化，关于AOF的配置如下：

# appendonly参数开启AOF持久化
appendonly no

# AOF持久化的文件名，默认是appendonly.aof
appendfilename "appendonly.aof"

# AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的
dir ./

# 同步策略
# appendfsync always
appendfsync everysec
# appendfsync no

# aof重写期间是否同步
no-appendfsync-on-rewrite no

# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 加载aof出错如何处理
aof-load-truncated yes

# 文件重写策略
aof-rewrite-incremental-fsync yes

以下是Redis中关于AOF的主要配置信息：
appendonly：默认情况下AOF功能是关闭的，将该选项改为yes以便打开Redis的AOF功能。
appendfilename：这个参数项很好理解了，就是AOF文件的名字。
**appendfsync：**这个参数项是AOF功能最重要的设置项之一，主要用于设置“真正执行”操作命令向AOF文件中同步的策略。 什么叫“真正执行”呢？还记得Linux操作系统对磁盘设备的操作方式吗？ 为了保证操作系统中I/O队列的操作效率，应用程序提交的I/O操作请求一般是被放置在linux Page Cache中的，然后再由Linux操作系统中的策略自行决定正在写到磁盘上的时机。而Redis中有一个fsync()函数，可以将Page Cache中待写的数据真正写入到物理设备上，而缺点是频繁调用这个fsync()函数干预操作系统的既定策略，可能导致I/O卡顿的现象频繁 。 与上节对应，appendfsync参数项可以设置三个值，分别是：always、everysec、no，默认的值为everysec。
no-appendfsync-on-rewrite：always和everysec的设置会使真正的I/O操作高频度的出现，甚至会出现长时间的卡顿情况，这个问题出现在操作系统层面上，所有靠工作在操作系统之上的Redis是没法解决的。为了尽量缓解这个情况，Redis提供了这个设置项，保证在完成fsync函数调用时，不会将这段时间内发生的命令操作放入操作系统的Page Cache（这段时间Redis还在接受客户端的各种写操作命令）。
**auto-aof-rewrite-percentage：**上文说到在生产环境下，技术人员不可能随时随地使用“BGREWRITEAOF”命令去重写AOF文件。所以更多时候我们需要依靠Redis中对AOF文件的自动重写策略。Redis中对触发自动重写AOF文件的操作提供了两个设置：auto-aof-rewrite-percentage表示如果当前AOF文件的大小超过了上次重写后AOF文件的百分之多少后，就再次开始重写AOF文件。例如该参数值的默认设置值为100，意思就是如果AOF文件的大小超过上次AOF文件重写后的1倍，就启动重写操作。
**auto-aof-rewrite-min-size：**参考auto-aof-rewrite-percentage选项的介绍，auto-aof-rewrite-min-size设置项表示启动AOF文件重写操作的AOF文件最小大小。如果AOF文件大小低于这个值，则不会触发重写操作。注意，auto-aof-rewrite-percentage和auto-aof-rewrite-min-size只是用来控制Redis中自动对AOF文件进行重写的情况，如果是技术人员手动调用“BGREWRITEAOF”命令，则不受这两个限制条件左右。

RDB和AOF混合方式

Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。简单来说，内存快照以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。
请添加图片描述

看看1996
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
Redis基础.md
12-26
# Redis基础 ## 数据类型 ### strings * `set key value`和`get key`，注意set操作会覆盖已有的key/value，若不希望覆盖可使用`set key value nx` * `mset key1 value1 key2 value2 ...`和`mget key1 key2 ...`...
Linux安装Redis
学无止境
10-17 3224
【Linux安装Redis】
Redis的使用
zhinian1204的博客
04-05 1880
Redis 1.基础知识 redis是内存性数据库，断电，数据丢失，进程重启，数据丢失 需要配置redis的数据持久化，防止数据丢失 redis支持ms复制，读写分离，防止单点故障，数据丢失 1.1.安装 rpm包安装 yum自动化安装，在阿里的yum仓库中，有redis的软件包 yum install redis -y 源代码编译安装 # 1.下载redis源码 wget http://download.redis.io/releases/redis-4.0.10.tar.gz # 2.解
Redis的介绍与安装
小小本科生
07-31 195
Redis的介绍与安装一：NoSQL数据库概述二：Redis概述2.1、Redis简介2.1、Redis的优势2.3、Redis与其他key-value存储有什么不同？三：Redis应用场景四：安装Redis（Linux环境下）4.1、安装C 语言的编译环境4.2、解压安装包4.3、编译并安装4.4、将 REDIS 安装为系统服务并后台启动4.5、查看REDIS服务启动情况4.6、启动REDIS客户端并测试4.7、设置允许远程连接4.8、设置访问密码 一：NoSQL数据库概述 NoSQL(NoSQL = N
redis主从配置之持久化配置
cm777的博客
12-30 1110
文章看起来有点长，但没什么废话，几乎全是图 环境描述： centos：7.6 docker：19.03.1 redis：6.0.9 对于centos怎么装docker，docker又怎么装redis镜像等等内容就不做概述了。如果还不会这个，就先去百度把这些前置技能学习下 本文并没有配置哨兵模式，且全部是在一台服务器上完成的。 以下是正文 先贴一个redis官方的配置文件，使用下面的命令可以直接获取 wget http://download.redis.io/redis-stable/r
Redis配置详解（转）
u010468993的博客
02-24 225
# Redis 配置文件 # 当配置中需要配置内存大小时，可以使用 1k, 5GB, 4M 等类似的格式，其转换方式如下(不区分大小写) # # 1k => 1000 bytes # 1kb => 1024 bytes # 1m => 1000000 bytes # 1mb => 1024*1024 bytes # 1g => 1000000000 bytes # 1gb => 1024*1024*1024bytes # # 内存配置大小写是一样的.比如 1gb 1Gb
redis基础一(安装、常用命令等)
01-07
Redis是一个高性能的key/value 非关系型的内存数据库，基于C语言编写。  1)、单进程、线程的工作机制；  2)、采用Reactor模式，基于事件驱动(文件事件和时间事件)，使用I/O的多路复用程序来同时监听多个套接字； ...
Redis基础1
08-04
#第一章 NoSQL数据库发展历史简介#1、 Web的历史发展历程web1.0时代简介web 1.0是以编辑为特征，网站提供给用户的内容是网站编辑进行编辑处理后
redis基础.doc
12-10
redis 是一种基于键值对（key-value）数据库，其中 value 可以为 string、hash、list、 set、zset 等多种数据结构，可以满足很多应用场景。还提供了键过期，发布订阅，事务， 流水线，等附加功能, 流水线: Redis 的...
redis基础资料
09-05
Redis是一款开源的、高性能的键-值存储（key-value store）。它常被称作是一款数据结构服务器（data structure server）。Redis的键值可以包括字符串（strings）类型，同时它还包括哈希（hashes）、列表（lists）、...
redis分布式以及持久化机制（主从、哨兵、分片、RDB、AOF）
m0_52889702的博客
11-11 714
redis持久化RDBRDB 触发RDB的配置RDB异步持久化原理AOFAOF触发AOF的配置AOF重写AOF重写触发二者对比主从集群搭建集群主从数据同步原理哨兵机制状态监控故障恢复通知搭建哨兵集群客户端连接主从集群分片集群搭建分片集群散列插槽集群伸缩故障转移
Redis未授权漏洞利用
小安安
12-02 1178
Redis未授权漏洞利用
Redis 配置
干燥的空气，湿润的呼吸
10-30 88
一、必须要修改: Redis配置默认必须修改： daemonize no 修改为 daemonize yes bind 127.0.01 注释掉 requirepass 设置密码 二、必须要知道: 服务端启动： ./bin/redis-server ./redis.conf 本地客户端登录 用redis-cli 密码登陆 redis-cli -a password 远程服务上执行命令: ...
Redis基础篇
Wolf__king的博客
05-07 9237
Hash表，List可重复有序的，set不可重复无序的。下面三种是基于基本类型的基础上进行了特殊的处理用来实现特殊功能。5种基本类型，3中复杂类型。
redis-server监听配置
sujin的博客
04-09 2759
Redis监听在0.0.0.0，可能导致服务对外或内网横向移动渗透风险，极易被黑客利用入侵。 操作时建议做好记录或备份 加固建议 Redis监听在0.0.0.0，可能导致服务对外或内网横向移动渗透风险，极易被黑客利用入侵，建议监听在: 127.0.0.1或内网地址。如业务需要监听外网，请配置防火墙安全策略。 ...
Redis安装说明（转 侵删）
三分明月落的博客
03-03 2256
Redis安装说明（转 侵删）1.单机安装Redis1.1.安装Redis依赖1.2.上传安装包并解压1.3.启动1.3.1.默认启动1.3.2.指定配置启动1.3.3.开机自启2.Redis客户端2.1.Redis命令行客户端2.2.图形化桌面客户端2.2.1.安装2.2.2.建立连接 大多数企业都是基于Linux服务器来部署项目，而且Redis官方也没有提供Windows版本的安装包。因此课程中我们会基于Linux系统来安装Redis. 此处选择的Linux版本为CentOS 7. Redis的官方网站
【Redis高可用】
t194978的博客
10-15 715
redis高可用
允许redis远程访问 修改redis.conf 如图，默认为127.0.0.1只能本地访问，修改为0.0.0.0
m0_67403188的博客
03-24 1377
允许redis远程访问 修改redis.conf 如图，默认为127.0.0.1只能本地访问，修改为0.0.0.0
Redis教程（一）——Redis安装
Amos技术足迹
06-13 219
截止当前时间，Redis最新版本是5.0.5,本博文基于此版本在centos7系统中安装redis，并且设置为开机启动Redis服务。同时为了以后Redis集群方便，我们再进行centos7服务器方便的配置来实现我们的Redis集群 Redis安装 下载Redis 进入 /usr/local 下下载Redis安装文件，并且解压该压缩文件 cd /usr/local ## ...
redis基础学习思路
最新发布
09-13
对于学习Redis的基础知识，可以按照以下...以上是学习Redis基础知识的一个思路，你可以根据自己的实际情况和需求进行学习和拓展。推荐参考一些经典的Redis教程和实战案例，通过实际操作和项目实践来提升自己的技能。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值