Redis笔记整理（三）：进阶操做与高级部分
Redis笔记整理（三）：进阶操做与高级部分
Redis发布订阅
Redis发布订阅（pub/sub）是一种消息通讯模式：发送者(pub)发送消息，订阅者(sub)接收消息。 Redis客户端能够订阅任意数量的频道。 下图展现了频道channel1，以及订阅这个频道的三个客户端——client1，client2，client5之间的关系。 当有新消息经过PUBLISH命令发送给频道channel1时，这个消息就会被发送给订阅它的三个客户端：
相关操做命令以下：web
| 命令 | 描述 |
|---|---|
| PSUBSCRIBE pattern [pattern ...] | 订阅一个或多个符合给定模式的频道 |
| PUSBSUB subcommand [argument [argument...]] | 查看订阅与发布系统状态 |
| PUBLISH channel message | 将消息发送到指定的频道 |
| PUNSUBSCRIBE [ pattern [pattern ...]] | 退订全部给定模式的频道 |
| SUBSCRIBE channel [channel ...] | 订阅给定的一个或多个频道的信息 |
| UNSUBSCRIBE [channel [channel ...]] | 指退订给定的频道 |
举例以下：redis
建立的订阅频道名为redisChat localhost:6379> SUBSCRIBE redisChat 1) "subscribe" 2) "redisChat 从新打开一个新的redis客户端，而后在同一个频道redisChat发布两次消息，订阅者就能接收到相关消息。 127.0.0.1:6379> PUBLISH redisChat "jack is handsome boy" 这时在订阅端中很快就能够看到该消息。
Redis事务
Redis事务能够一次执行多个命令，而且带有如下两个重要的保证：
事务是一个单独的隔离操做：事务中的全部命令都会序列化、按顺序地执行。
事务在执行的过程当中，不会被其余客户端发送来的命令请求所打断。
事务是一个原子操做：事务中的命令要么所有被执行，要么所有都不执行。
一个事务从开始到执行会经历三个阶段：
开始事务。
命令入队。
执行事务。
其相关操做命令以下：算法
| 命令 | 描述 |
|---|---|
| DISCARD | 取消事务，放弃执行事务块内的全部命令 |
| EXEC | 执行全部事务块内的命令 |
| MULTI | 标记一个事务块的开始 |
| UNWATCH | 取消WATCH命令对全部key的监视 |
| WATCH key [key ...] | 监视一个或多个key，若是在事务执行以前这些key被其它命令所改动，那么事务将被打断 |
举例以下：数据库
uplooking01:7001> get name "xpleaf" uplooking01:7001> MULTI OK uplooking01:7001> get name QUEUED uplooking01:7001> set name yyh QUEUED uplooking01:7001> get name QUEUED uplooking01:7001> EXEC 1) "xpleaf" 2) OK 3) "yyh"
Redis命令总结
Redis的经常使用命令主要分为两个方面、一个是键值相关命令、一个是服务器相关命令
一、键值相关命令
keys * 取出当前全部的key
exists name 查看redis是否有name这个key
del name 删除key name
expire confirm 100 设置confirm这个key100秒过时
ttl confirm 获取confirm 这个key的有效时长
select 0 选择到0数据库 redis默认的数据库是0~15一共16个数据库
move confirm 1 将当前数据库中的key移动到其余的数据库中，
persist confirm 移除confirm这个key的过时时间
randomkey 随机返回数据库里面的一个key
rename key2 key3 重命名key2 为key3
type key2 返回key的数据类型
二、服务器相关命令
ping PONG返回响应是否链接成功
echo 在命令行打印一些内容
select 0~15 编号的数据库
quit /exit 退出客户端
dbsize 返回当前数据库中全部key的数量
info 返回redis的相关信息
config get dir/* 实时传储收到的请求
flushdb 删除当前选择数据库中的全部key
flushall 删除全部数据库中的数据库
Redis安全
咱们能够经过redis的配置文件设置密码参数，这样客户端链接到redis服务就须要密码验证，这样可让你的redis服务更安全。缓存
咱们能够经过如下命令查看是否设置了密码验证：安全
uplooking01:7001> config get requirepass 1) "requirepass" 2) ""
默认状况下requirepass参数是空的，这就意味着无需密码验证就能够链接到redis服务。若是设置密码，客户端链接redis服务就须要密码验证。不然没法执行命令，有两方式完成认证：服务器
能够在链接时就指定密码：redis-cli -h uplooking03 -a uplooking 也能够先链接，到终端后再认证：auth uplooking
Redis管道与性能测试
Redis是一种基于客户端-服务端模型以及请求/响应协议的TCP服务。这意味着一般状况下一个请求会遵循如下步骤： 客户端向服务端发送一个查询请求，并监听scoket返回，一般是以阻塞模式，等待服务端响应。 服务端处理命令，并将结果返回给客户端。 Redis管道技术能够在服务端末响应时，客户端能够继续想服务端发送请求，并最终一次性读取全部服务端的相应。
下面使用Java代码来进行测试：数据结构
package com.uplooking.bigdata;
import com.uplooking.bigdata.common.util.redis.JedisUtil;
import org.junit.Test;
import redis.clients.jedis.Jedis;
import redis.clients.jedis.Pipeline;
/**
* 使用管道和不使用管道的性能测试对比
*/
public class PipelineTest {
@Test
public void testPipeline() {
int count = 10000;
// 标记不使用管道操做时的开始时间
long start = System.currentTimeMillis();
// 不使用管道执行操做
withoutPipeline(count);
// 标记不使用管道操做时的结束时间
long end = System.currentTimeMillis();
// 输出不使用管道进行操做时所消耗的时间
System.out.println("withoutPipeline: " + (end-start));
// 标记使用管道操做时的开始时间
start = System.currentTimeMillis();
// 使用管道执行操做
usePipeline(count);
// 标记使用管道操做时的结束时间
end = System.currentTimeMillis();
// 输出使用管道进行操做时所消耗的时间
System.out.println("usePipeline: " + (end-start));
}
private void withoutPipeline(int count) {
JedisUtil.getJedis();
Jedis jedis = JedisUtil.getJedis();
for(int i =0; i < count; i++) {
jedis.incr("testKey1");
}
cleanUp(jedis);
}
private void usePipeline(int count) {
Jedis jedis = JedisUtil.getJedis();
Pipeline pl = jedis.pipelined();
for(int i =0; i < count; i++) {
pl.incr("testKey1");
}
pl.sync();
cleanUp(jedis);
}
public void cleanUp(Jedis jedis) {
JedisUtil.returnJedis(jedis);
}
}
JedisUtil能够查看前面的代码，这里就再也不给出。并发
输出结果以下：app
withoutPipeline: 1935 usePipeline: 60
测试结果仍是有明显的差距，因此屡次操做使用pipeline仍是有明显的优点。
Redis性能测试：读写能力查看
Redis性能测试是经过同时执行多个命令实现的。 语法 redis-benchmark [option] [option-value] 实例 如下实例同时执行10000个请求来检测性能： 1)、redis-benchmark -n 100000 2)、redis-benchmark -h localhost -p 6379 -t set,lpush -n 100000 -q
其常见的命令选项以下：
| 选项 | 描述 | 默认值 |
|---|---|---|
| -h | 指定服务器主机名 | 127.0.0.1 |
| -p | 指定服务器端口 | 6379 |
| -s | 指定服务器socket | |
| -c | 指定并发链接数 | 50 |
| -n | 指定请求数 | 10000 |
| -d | 以字节的形式指定set/get值的数据大小 | 2 |
| -k | 1=keep alive 0=reconnect | 1 |
| -r | set/get/incr使用随机key,sadd使用随机值 | |
| -P | 经过管道传输<numreq>请求 | 1 |
| -q | 强制退出redis。仅显示query/sec值 | |
| -csv | 以CSV格式输出 | |
| -l | 生产循环，永久执行测试 | |
| -t | 仅运行以逗号分割的测试命令列表 | |
| -I | Idle模式。仅打开N个idle链接并等待 |
完整测试案例
[uplooking@uplooking01 ~]$ redis-benchmark -h uplooking01 -p 6379 -n 100000 -c 20 ====== PING_INLINE ====== 100000 requests completed in 1.29 seconds 20 parallel clients 3 bytes payload keep alive: 1 99.96% <= 1 milliseconds 100.00% <= 1 milliseconds 77459.34 requests per second ====== PING_BULK ====== 100000 requests completed in 1.33 seconds 20 parallel clients 3 bytes payload keep alive: 1 99.95% <= 1 milliseconds 99.96% <= 2 milliseconds 100.00% <= 2 milliseconds 75187.97 requests per second ====== SET ====== 100000 requests completed in 1.29 seconds 20 parallel clients 3 bytes payload keep alive: 1 99.96% <= 1 milliseconds 99.98% <= 2 milliseconds 99.98% <= 4 milliseconds 99.99% <= 5 milliseconds 100.00% <= 5 milliseconds 77339.52 requests per second ====== GET ====== 100000 requests completed in 1.35 seconds 20 parallel clients 3 bytes payload keep alive: 1 99.98% <= 1 milliseconds 100.00% <= 1 milliseconds 74239.05 requests per second ====== INCR ====== 100000 requests completed in 1.29 seconds 20 parallel clients 3 bytes payload keep alive: 1 99.98% <= 1 milliseconds 100.00% <= 1 milliseconds 77279.75 requests per second ====== LPUSH ====== 100000 requests completed in 1.28 seconds 20 parallel clients 3 bytes payload keep alive: 1 99.98% <= 1 milliseconds 100.00% <= 1 milliseconds 77821.02 requests per second ====== RPUSH ====== 100000 requests completed in 1.28 seconds 20 parallel clients 3 bytes payload keep alive: 1 99.94% <= 1 milliseconds 100.00% <= 1 milliseconds 77881.62 requests per second ====== LPOP ====== 100000 requests completed in 1.27 seconds 20 parallel clients 3 bytes payload keep alive: 1 99.99% <= 1 milliseconds 100.00% <= 1 milliseconds 78616.35 requests per second ====== RPOP ====== 100000 requests completed in 1.27 seconds 20 parallel clients 3 bytes payload keep alive: 1 99.92% <= 1 milliseconds 100.00% <= 1 milliseconds 78678.20 requests per second ====== SADD ====== 100000 requests completed in 1.34 seconds 20 parallel clients 3 bytes payload keep alive: 1 99.99% <= 1 milliseconds 100.00% <= 1 milliseconds 74404.77 requests per second ====== SPOP ====== 100000 requests completed in 1.34 seconds 20 parallel clients 3 bytes payload keep alive: 1 99.96% <= 1 milliseconds 100.00% <= 1 milliseconds 74738.41 requests per second ====== LPUSH (needed to benchmark LRANGE) ====== 100000 requests completed in 1.27 seconds 20 parallel clients 3 bytes payload keep alive: 1 99.96% <= 1 milliseconds 100.00% <= 1 milliseconds 78492.93 requests per second ====== LRANGE_100 (first 100 elements) ====== 100000 requests completed in 2.81 seconds 20 parallel clients 3 bytes payload keep alive: 1 99.87% <= 1 milliseconds 99.98% <= 2 milliseconds 100.00% <= 3 milliseconds 35536.61 requests per second ====== LRANGE_300 (first 300 elements) ====== 100000 requests completed in 7.59 seconds 20 parallel clients 3 bytes payload keep alive: 1 97.91% <= 1 milliseconds 99.83% <= 2 milliseconds 99.96% <= 3 milliseconds 100.00% <= 4 milliseconds 100.00% <= 4 milliseconds 13166.56 requests per second ====== LRANGE_500 (first 450 elements) ====== 100000 requests completed in 10.27 seconds 20 parallel clients 3 bytes payload keep alive: 1 37.79% <= 1 milliseconds 99.54% <= 2 milliseconds 99.91% <= 3 milliseconds 99.97% <= 4 milliseconds 99.99% <= 5 milliseconds 100.00% <= 6 milliseconds 100.00% <= 6 milliseconds 9734.25 requests per second ====== LRANGE_600 (first 600 elements) ====== 100000 requests completed in 13.01 seconds 20 parallel clients 3 bytes payload keep alive: 1 0.72% <= 1 milliseconds 98.59% <= 2 milliseconds 99.76% <= 3 milliseconds 99.94% <= 4 milliseconds 99.98% <= 5 milliseconds 100.00% <= 6 milliseconds 7689.35 requests per second ====== MSET (10 keys) ====== 100000 requests completed in 1.69 seconds 20 parallel clients 3 bytes payload keep alive: 1 99.98% <= 1 milliseconds 100.00% <= 1 milliseconds 59241.71 requests per second
能够看到执行了多个命令进行测试，若是只是但愿测试部分命令的性能状况，能够参考下面的部分测试案例。
部分测试案例
[uplooking@uplooking01 ~]$ redis-benchmark -h uplooking01 -p 6379 -t set,lpush -n 100000 -q SET: 75301.21 requests per second LPUSH: 77101.00 requests per second
经过上面的测试，咱们就能够知道咱们的Redis环境的读写能力究竟如何。
Redis数据持久化
RDB（默认）
rdb方式的持久化是经过快照完成的，当符合必定条件时redis会自动将内存中的全部数据执行快照操做并存储到硬盘上。 默认存储在dump.rdb文件中。(文件名在配置文件中dbfilename) redis进行快照的时机（在配置文件redis.conf中） save 900 1：表示900秒内至少一个键被更改则进行快照。 save 300 10 save 60 10000 （redis自动实现快照的过程，见下面的文档内容） 手动执行save或者bgsave命令让redis执行快照。 两个命令的区别在于，save是由主进程进行快照操做，会阻塞其它请求。bgsave是由redis执行fork函数复制出一个子进程来进行快照操做。 文件修复：redis-check-dump rdb的优缺点 优势：因为存储的有数据快照文件，恢复数据很方便。 缺点：会丢失最后一次快照之后更改的全部数据。
redis实现快照的过程：
1：redis使用fork函数复制一份当前进程的副本(子进程) 2：父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件 3：当子进程写入完全部数据后会用该临时文件替换旧的RDB文件，至此，一次快照操做完成。 注意：redis在进行快照的过程当中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任什么时候候RDB文件都是完整的。 这就使得咱们能够经过定时备份RDB文件来实现redis数据库的备份 RDB文件是通过压缩的二进制文件，占用的空间会小于内存中的数据，更加利于传输。
AOF
AOF基本配置
aof方式的持久化是经过日志文件的方式。默认状况下redis没有开启aof，能够经过参数appendonly参数开启。
appendonly yes
aof文件的保存位置和rdb文件的位置相同，都是dir参数设置的，默认的文件名是appendonly.aof，能够经过 appendfilename参数修改
appendfilename appendonly.aof
redis写命令同步的时机：
#appendfsync always 每次都会执行 appendfsync everysec 默认 每秒执行一次同步操做（推荐，默认） #appendfsync no不主动进行同步，由操做系统来作，30秒一次
另外查看aof日志文件，它的内容以下：
[uplooking@uplooking01 redis]$ tail -f appendonly.aof single $2 no *3 $3 SET $3 age $2 18
其相关符号的说明以下：
*<参数数量> $<参数 1 的字节数量> <参数 1 的数据> ... $<参数 N 的字节数量> <参数 N 的数据>
aof日志文件重写
auto-aof-rewrite-percentage 100(当目前aof文件大小超过上一次重写时的aof文件大小的百分之多少时会再次进行重写，若是以前没有重写，则以启动时的aof文件大小为依据) auto-aof-rewrite-min-size 64mb 手动执行bgrewriteaof进行重写 重写的过程只和内存中的数据有关，和以前的aof文件无关。 所谓的“重写”实际上是一个有歧义的词语， 实际上， AOF 重写并不须要对原有的 AOF 文件进行任何写入和读取， 它针对的是数据库中键的当前值。 文件修复：redis-check-aof
对于aof日志文件重写的概念再进一步说明：
所谓“重写”实际上是一个有歧义的词语，实际上，AOF重写并不须要对原有AOF文件进行任何写入和读取， 它针对的是数据库中键的当前值。 假设服务器对键list执行了如下四条命令： 127.0.0.1:6379[1]> RPUSH list 1 2 3 4 //[1,2,3,4] 127.0.0.1:6379[1]> RPOP list //[1,2,3] 127.0.0.1:6379[1]> LPOP list //[2,3] 当前列表键list在数据库中的值就为[2,3]。要保存这个列表的当前状态，而且尽可能减小使用的命令数， 最简单的方式不是去AOF文件分析前面执行的三条命令，而是直接读取list键在数据库中的当前值， 而后用一条RPUSH 2，3代替前面的三条命令。 根据键的类型，使用适当的写入命令来重现键的当前值，这就是AOF重写的实现原理
rdb切换到aof
动态切换redis持久方式，从RDB切换到AOF（支持Redis 2.2及以上） CONFIG SET appendonly yes CONFIG SET save ""（可选） 注意：当redis启动时，若是rdb持久化和aof持久化都打开了，那么程序会使用aof方式来恢复数据集， 由于aof方式所保存的数据一般是最完整的。若是aof文件丢失了，则启动以后数据库内容为空。 注意：若是想把正在运行的redis数据库，从RDB切换到AOF，建议先使用动态切换方式，再修改配置文件，重启数据库。 (不能本身修改配置文件，重启数据库，不然数据库中数据就为空了。由于此时会直接读取aof文件的数据， rdb的数据文件还存在，可是redis只会加载aof日志文件。)
在实际测试时，效果跟上面的描述是同样的：
1.先使用rdb的方式做为数据的持久化方式 2.向redis中添加数据 3.动态执行CONFIG SET appendonly yes 而后会发如今redis目录下动态生成一个aof文件，而且其数据就是当前redis内存中的数据。 而且经过测试发现，假如age这个key是原来rdb中存在的数据，一旦动态切换，原来rdb的数据都会备份到aof日志文件中， 这样也就验证了，其实动态切换的过程，会把当前redis内存中的数据都保存到aof日志文件中。
Redis优化
Redis内存占用状况
100万个键值对（键是0到999999值是字符串“hello world”）在32位操做系统的笔记本上用了100MB 使用64位的操做系统的话，相对来讲占用的内存会多一点，这是由于64位的系统里指针占用了8个字节， 可是64位系统也能支持更大的内存，因此运行大型的redis服务仍是建议使用64位服务器 一个Redis实例最多能存放多少keys 理论上Redis能够处理多达232-1的keys，而且在实际中进行了测试，每一个实例至少存放了2亿5千万的keys 也能够说Redis的存储极限是系统中的可用内存值。
Redis优化1：基本优化
1.精简键名和键值
键名：尽可能精简，可是也不能单纯为了节约空间而使用不易理解的键名。
键值：对于键值的数量固定的话可使用0和1这样的数字来表示，（例如：male/female、right/wrong）
2.当业务场景不须要数据持久化时，关闭全部的持久化方式能够得到最佳的性能
3.内部编码优化（了解）
redis为每种数据类型都提供了两种内部编码方式，在不一样的状况下redis会自动调整合适的编码方式。（如图所示）
4.SLOWLOG [get/reset/len]
slowlog-log-slower-than 它决定要对执行时间大于多少微秒(microsecond，1秒 = 1,000,000 微秒)的命令进行记录
slowlog-max-len 它决定 slowlog 最多能保存多少条日志
当发现redis性能降低的时候能够查看下是哪些命令致使的
Redis优化2：内存使用优化
1.限制redis的内存大小
经过redis的info命令查看内存使用状况
若是不设置maxmemory或者设置为0，64位系统不限制内存，32位系统最多使用3GB内存。
修改配置文件中的maxmemory和maxmemory-policy
maxmemory：最大内存
maxmemory-policy：内存不足时,数据清除策略
1.若是能够肯定数据总量不大，而且内存足够的状况下不须要限制redis使用的内存大小。
若是数据量不可预估，而且内存也有限的话，尽可能限制下redis使用的内存大小，这样能够避免redis使用swap分区。
注意：若是不限制内存，当物理内存使用完以后，会使用swap分区，这样性能较低，若是限制了内存，
当到达指定内存以后就不能添加数据了，不然会报OOM错误。
能够设置maxmemory-policy，内存不足时删除数据。
更详细的说明以下：
在硬盘上进行读写操做要比在内存上进行读写操做，时间上慢了近5个数量级，内存是0.1μs(微秒)、而硬盘是10ms(毫秒)。若是Redis进程上发生内存交换，那么Redis和依赖Redis上数据的应用会受到严重的性能影响。 经过查看used_memory指标可知道Redis正在使用的内存状况，若是used_memory>可用最大内存，那就说明Redis实例正在进行内存交换或者已经内存交换完毕。管理员根据这个状况，执行相对应的应急措施。
排查方案：如果在使用Redis期间没有开启rdb快照或aof持久化策略，那么缓存数据在Redis崩溃时就有丢失的危险。由于当Redis内存使用率超过可用内存的95%时，部分数据开始在内存与swap空间来回交换，这时就可能有丢失数据的危险。当开启并触发快照功能时，Redis会fork一个子进程把当前内存中的数据彻底复制一份写入到硬盘上。所以如果当前使用内存超过可用内存的45%时触发快照功能，那么此时进行的内存交换会变的很是危险(可能会丢失数据)。 假若在这个时候实例上有大量频繁的更新操做，问题会变得更加严重。
经过减小Redis的内存占用率，来避免这样的问题，或者使用下面的技巧来避免内存交换发生：1：尽量的使用Hash数据结构。由于Redis在储存小于100个字段的Hash结构上，其存储效率是很是高的。因此在不须要集合(set)操做或list的push/pop操做的时候，尽量的使用Hash结构。好比，在一个web应用程序中，须要存储一个对象表示用户信息，使用单个key表示一个用户，其每一个属性存储在Hash的字段里，这样要比给每一个属性单独设置一个key-value要高效的多。 一般状况下假若有数据使用string结构，用多个key存储时，那么应该转换成单key多字段的Hash结构。 如上述例子中介绍的Hash结构应包含，单个对象的属性或者单个用户各类各样的资料。Hash结构的操做命令是HSET(key, fields, value)和HGET(key, field)，使用它能够存储或从Hash中取出指定的字段。
2：设置key的过时时间。一个减小内存使用率的简单方法就是，每当存储对象时确保设置key的过时时间。假若key在明确的时间周期内使用或者旧key不大可能被使用时，就能够用Redis过时时间命令(expire,expireat, pexpire, pexpireat)去设置过时时间，这样Redis会在key过时时自动删除key。 假如你知道每秒钟有多少个新key-value被建立，那能够调整key的存活时间，并指定阀值去限制Redis使用的最大内存。
3：回收key。在Redis配置文件中(通常叫Redis.conf)，经过设置“maxmemory”属性的值能够限制Redis最大使用的内存，修改后重启实例生效。也可使用客户端命令config set maxmemory 去修改值，这个命令是当即生效的，但会在重启后会失效，须要使用config rewrite命令去刷新配置文件。 如果启用了Redis快照功能，应该设置“maxmemory”值为系统可以使用内存的45%，由于快照时须要一倍的内存来复制整个数据集，也就是说若是当前已使用45%，在快照期间会变成95%(45%+45%+5%)，其中5%是预留给其余的开销。 若是没开启快照功能，maxmemory最高能设置为系统可用内存的95%。
当内存使用达到设置的最大阀值时，须要选择一种key的回收策略，可在Redis.conf配置文件中修改“maxmemory-policy”属性值。 如果Redis数据集中的key都设置了过时时间，那么“volatile-ttl”策略是比较好的选择。但若是key在达到最大内存限制时没可以迅速过时，或者根本没有设置过时时间。那么设置为“allkeys-lru”值比较合适，它容许Redis从整个数据集中挑选最近最少使用的key进行删除(LRU淘汰算法)。Redis还提供了一些其余淘汰策略，以下：volatile-lru：使用LRU算法从已设置过时时间的数据集合中淘汰数据。volatile-ttl：从已设置过时时间的数据集合中挑选即将过时的数据淘汰。volatile-random：从已设置过时时间的数据集合中随机挑选数据淘汰。allkeys-lru：使用LRU算法从全部数据集合中淘汰数据。allkeys-random：从数据集合中任意选择数据淘汰no-enviction：禁止淘汰数据。
经过设置maxmemory为系统可用内存的45%或95%(取决于持久化策略)和设置“maxmemory-policy”为“volatile-ttl”或“allkeys-lru”(取决于过时设置)，能够比较准确的限制Redis最大内存使用率，在绝大多数场景下使用这2种方式可确保Redis不会进行内存交换。假若你担忧因为限制了内存使用率致使丢失数据的话，能够设置noneviction值禁止淘汰数据。
Redis优化3
Redis是个单线程模型，客户端过来的命令是按照顺序执行的，因此想要一次添加多条数据的时候可使用管道(能够理解为批处理)，或者使用一次能够添加多条数据的命令，例如：
| set | mset |
|---|---|
| get | mget |
| lindex | lrange |
| hset | hmset |
| hget | hmget |
相关文章
- 1. Redis笔记整理（三）：进阶操做与高级部分
- 2. 三、HIVE 高级进阶笔记
- 3. Redis高级进阶
- 4. Redis高级功能整理笔记
- 5. redis高级进阶(2)
- 6. Redis高级进阶（一）
- 7. redis高级进阶(1)
- 8. Python进阶三部曲之IO操做
- 9. MySQL高级部分笔记
- 10. 《Android高级进阶》读书笔记
- 更多相关文章...
- • Scala 高阶函数 - Scala教程
- • XML DOM 高级 - XML 教程
- • Tomcat学习笔记（史上最全tomcat学习笔记）
- • Java Agent入门实战（三）-JVM Attach原理与使用
相关标签/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
最新文章
欢迎关注本站公众号,获取更多信息
相关文章
- 1. Redis笔记整理（三）：进阶操做与高级部分
- 2. 三、HIVE 高级进阶笔记
- 3. Redis高级进阶
- 4. Redis高级功能整理笔记
- 5. redis高级进阶(2)
- 6. Redis高级进阶（一）
- 7. redis高级进阶(1)
- 8. Python进阶三部曲之IO操做
- 9. MySQL高级部分笔记
- 10. 《Android高级进阶》读书笔记