Redis1

Commands

key

• exists
• set - getset(override)
• get
• del
• expire - persist - ttl

 EXPIRE key seconds

String

• set - get
• setnx - setex
• incr - decr - incrby - decrby
• mset - mget - msetnx

MSET key value [key value ...]

List

• lpush - lpushx - lpop

• rpush - rpushx - rpop

  堆栈 FILO lpushx(lpush) - rpop
  队列 FIFO rpushx(rpush) - lpop

• lset

• lindex

Hash

• hset - hget - hgetall - hsetnx - hdel
• hmset - hmget
• hlen - hkeys - hvals

Set

• sadd - spop
• smembers
• sunion - sdiff

SortedSet

• zadd - zrem - zrange

Pub/Sub

• publish - subscribe
• psubscribe - punsubscribe
• unsubscribe
• pubsub

Transaction

• multi - exec - disacrd
• watch - unwatch

Connection

• auth
• echo
• ping
• quit
• select

Server

• client kill - list - setname
• config get - set - rewrite - resetstat
• debug object - segfault
• flushdb - flushall
• info
• save - bgsave
• sync
• lastsave
• shutdown
• slowlog
• monitor
• time

Usage

Keyspace

Keyspace notifications allows clients to subscribe to Pub/Sub channels in order to receive events affecting the Redis data set in some way.

Because Redis Pub/Sub is frie and forget currently there is no way to use this feature if you application demands reliable notification of events.

Config

config set/get notify-keyspace-events KEg$lshzxe

Transaction

Either all of the commands or none are processed, so a Redis transaction is automic.

When using the append-only file Redis makes usre to use a single write(2) syscall to write the transaction on disk.If the server crashes in some hard way, use the redis-check-aof tool is possible to fix the append only file.

From 2.6.5, the way to handle transaction queue is pipline. So the errors in queue will not be exec also the client will cancel all the pipline.

check-and-set CAS

WATCH mykeyval = GET mykeyval = val + 1MULTISET mykey $valEXEC

exec wile reset the watch whatever how many keys is watched.

ZPOP

WATCH zsetelement = ZRANGE zset 0 0MULTI    ZREM zset elementEXEC

Pub/Sub

TODO