(integer) 2
查询权重值为1-2之间的值得个数
redis 127.0.0.1:6379> zcount zset1 1 2
(integer) 3
redis 127.0.0.1:6379> zrange zset1 0 4
1) "one"
2) "one1"
3) "two"
4) "three"
5) "four"
取范围之,并且拿到评分
redis 127.0.0.1:6379> zrange zset1 0 -1 withscores
1) "one"
2) "1"
3) "one1"
4) "1"
5) "two"
6) "2"
7) "three"
8) "3"
9) "four"
10) "4"
?
redis 127.0.0.1:6379> zincrby zset1 1 one
"2"
redis 127.0.0.1:6379> zrange zset1 0 -1 withscores
1) "one1"
2) "1"
3) "one"
4) "2"
5) "two"
6) "2"
7) "three"
8) "3"
9) "four"
10) "4"
指定set集合元素的权重数值增长指定的数值,其中2是增长分数,one是元素
redis 127.0.0.1:6379> zincrby zset1 2 one
"4"
redis 127.0.0.1:6379> zrange zset1 0 -1 withscores
1) "one1"
2) "1"
3) "two"
4) "2"
5) "three"
6) "3"
7) "four"
8) "4"
9) "one"
10) "4"
?
事务操作
redis 127.0.0.1:6379> multi #开启事务
OK
redis 127.0.0.1:6379> incr age
QUEUED
redis 127.0.0.1:6379> exec #提交事务
1) (integer) 102 #提交成功的时候会有提交的值
?
redis 127.0.0.1:6379> set age 1
OK
redis 127.0.0.1:6379> multi #开启事务
OK
redis 127.0.0.1:6379> set age 30
QUEUED
redis 127.0.0.1:6379> get age
QUEUED
redis 127.0.0.1:6379> discard #事务回滚
OK
redis 127.0.0.1:6379> get age
"1"
?
乐观锁:
第一个cli
redis 127.0.0.1:6379> get age
"1"
redis 127.0.0.1:6379> watch age
OK
redis 127.0.0.1:6379> multi #开启事务
OK
redis 127.0.0.1:6379> set age 4
QUEUED
第二个cli
redis 127.0.0.1:6379> set age 2
OK #ok可以修改age的值
redis 127.0.0.1:6379> set age 10
OK
第一个cli
redis 127.0.0.1:6379> exec
(nil) #可见,事务提交是失败的
redis 127.0.0.1:6379> get age
"10" #得到的是第二个cli提交的值
?
悲观锁
?
?
?
存储数据到磁盘
Redis是一个支持持久化的内存数据库，也就是说redis需要经常将内存中的数据同步到磁盘来保证持久化。
redis支持两种持久化方式：
RDB Snapshotting（快照），redis默认方式；
Append-only file（缩写aof）的方式。
?
RDB
RDB快照是默认的持久化方式。Rdb的主要原理就是在某个时间点把内存中的所有数据的快照保存一份到磁盘上。
?
手动持久化：
save
bgsave
自动持久化配置
save
示例：
save 900 1 #900秒内如果超过1个key被修改，则发起快照保存
save 300 10 #300秒内容如超过10个key被修改，则发起快照保存
rdbcompression yes/no #对快照文件进行压缩
dbfilename <文件名> #快照文件名
dir ./ <目录名> #快照文件保存目录
?
配置:
################################ SNAPSHOTTING #################################
#
# Save the DB on disk:
#指出在多长时间内，有多少次更新操作，就将数据同步到数据文件。这个可以多个条件配合，比如默认配置文件中的设置，就设置了三个条件。
#900秒（15分钟）内至少有1个key被改变
save 900 1
#300秒（5分钟）内至少有10个key被改变
save 300 10
#60秒内至少有10000个key被改变
save 60 10000
#存储至本地数据库时是否压缩数据，默认为yes
rdbcompression yes
#本地数据库文件名，默认值为dump.rdb
dbfilename dump.rdb
#本地数据库存放路径，默认值为 ./
dir d:/redis/var
##当snapshot时出现错误无法继续时，是否阻塞客户端“变更操作”，“错误”可能因为磁盘已满/磁盘故障/OS级别异常等
stop-writes-on-bgsave-error yes
?
优点：
文件紧凑；
非常适用于灾难恢复；
性能比较好；
恢复速度快；
缺点
在快照时，如果数据量大里，会有停顿感；
如果系统崩溃，会有数据丢失；
?
AOF:
AOF 比快照方式有更好的持久化性，是由于在使用aof持久化方式时,redis 会将每一个收到的写命令都通过write函数追加到文件中(默认是appendonly.aof)。
AOF配置：
appendonly yes //启用aof持久化方式
appendfsync always //收到写命令就立即写入磁盘，最慢，但是保证完全的持久化
appendfsync everysec //每秒钟写入磁盘一次，在性能和持久化方面做了很好的折中
appendfsync no //完全依赖os，性能最好,持久化没保证
aof 文件位置配置
appendfilename
?
优点
数据更安全；
采用增量追加的方式写文件；
文件可以重写；
文件的可读性比较好。
缺点
AOF文件比RDB文件大；
根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB；
AOF文件恢复较慢；
?
?
服务器可能在程序正在对 AOF 文件进行写入时停机， 如果停机造成了 AOF 文件出错（corrupt）， 那么 Redis 在重启时会拒绝载入这个 AOF 文件， 从而确保数据的一致性不会被破坏。
文件修复命令：
redis-check-aof –fix <文件名>
注意： 修复文件前，需要对文件进行备份
?
重写AOF
AOF 的运作方式是不断地将命令追加到文件的末尾， 所以随着写入命令的不断增加， AOF 文件的体积也会变得越来越大。
手动重写AOF文件
bgrewriteaof
丢弃中间结果,保留最后的结果
自动化重写：
auto-aof-rewrite-percentage 100
当前写入日志文件的大小占到初始日志文件大小的某个百分比时触发Rewrite
auto-aof-rewrite-min-size 64mb
本