redis 基础

标签：

一 redis数据类型
redis支持5种类型的数据类型，它描述如下的:
1. 字符串
　　Redis字符串是字节序列。Redis字符串是二进制安全的，这意味着他们有一个已知的长度没有任何特殊字符终止，所以你可以存储任何东西，512兆为上限。
2. 哈希
　　Redis的哈希是键值对的集合。 Redis的哈希值是字符串字段和字符串值之间的映射，因此它们被用来表示对象.
3. 列表
　　Redis的列表是简单的字符串列表，排序插入顺序。您可以添加元素到Redis的列表的头部或尾部。
　　列表的最大长度为 232 - 1 元素（4294967295，每个列表中可容纳超过4十亿的元素）。
4. 集合
　　Redis的集合是字符串的无序集合。在Redis您可以添加，删除和测试文件是否存在，在成员O（1）的时间复杂度。
　　集合中的元素最大数量为 232 - 1 （4294967295，可容纳超过4十亿元素）。
5. 有序集合
　　Redis的有序集合类似于Redis的集合，字符串不重复的集合。不同的是，一个有序集合的每个成员用分数，以便采取有序set命令，从最小的到最大的成员分数有关。虽然成员具有唯一性，但分数可能会重复。

二 Redis 文件说明

$ find . -type f -executable

./redis-benchmark // 用于进行redis性能测试的工具

./redis-check-dump // 用于修复出问题的dump.rdb文件
./redis-cli // redis的客户端
./redis-server // redis的服务端
./redis-check-aof // 用于修复出问题的AOF文件
./redis-sentinel // 用于集群管理

三 Redis 管理

• 服务启动：./redis-server ../redis.conf 端口默认为6379
• 使用客户端：./redis-cli
• 通过客户端来关闭redis服务端 127.0.0.1:6379> shutdown
•  一些注意:

　　　　1. key不要太长，尽量不要超过1024字节，这不仅消耗内存，而且会降低查找的效率；
　　　　2. key也不要太短，太短的话，key的可读性会降低；
　　　　3. 在一个项目中，key最好使用统一的命名模式，例如user:10000:passwd。
　　　　4. 字符串类型的用法就是这么简单，因为是二进制安全的，所以你完全可以把一个图片文件的内容作为字符串来存储。

四 redis 持久化

•  Redis提供了两种持久化的方式，分别是RDB（Redis DataBase）和AOF（Append Only File）。
• RDB，简而言之，就是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上；
• AOF，则是换了一个角度来实现持久化，那就是将redis执行过的所有写指令记录下来.
• 在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。
• 其实RDB和AOF两种方式也可以同时使用，在这种情况下，如果redis重启的话，则会优先采用AOF方式来进行数据恢复，这是因为AOF方式的数据恢复完整度更高。
• 如果你没有数据持久化的需求，也完全可以关闭RDB和AOF方式，这样的话，redis将变成一个纯内存数据库，就像memcache一样。
• 两种方式是可以同时使用的。

五 redis持久化 – RDB

•  Redis在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件替换上次持久化好的文件。正是这种特性，让我们可以随时来进行备份，因为快照文件总是完整可用的。
• 对于RDB方式，redis会单独创建（fork）一个子进程来进行持久化，而主进程是不会进行任何IO操作的，这样就确保了redis极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

六 Redis持久化 - AOF

•  AOF，英文是Append Only File，即只允许追加不允许改写的文件。
•  通过配置redis.conf中的appendonly yes就可以打开AOF功能。如果有写操作（如SET等），redis就会被追加到AOF文件的末尾。
•  默认的AOF持久化策略是每秒钟fsync一次（fsync是指把缓存中的写指令记录到磁盘中）.因为在这种情况下，redis仍然可以保持很好的处理性能，即使redis故障，也只会丢失最近1秒钟的数据。
• 如果在追加日志时，恰好遇到磁盘空间满、inode满或断电等情况导致日志写入不完整，也没有关系，redis提供了redis-check-aof工具，可以用来进行日志修复。
• AOF文件会变得越来越大，为此，redis提供了AOF文件重写（rewrite）机制，即当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。
• 在进行AOF重写时，仍然是采用先写临时文件，全部完成后再替换的流程，所以断电、磁盘满等问题都不会影响AOF文件的可用性.
• AOF的一个好处场景再现，如果有人不小心清了数据库。在AOF文件还没没被重写的情况下， 可以通过停掉Redis修改AOF文件，去掉误操作的语句。重启Redis恢复数据。
• 如果出现AOF文件被写坏的情况。可按如下步骤修复：

　　   a.备份被写坏的AOF文件
　　　b.运行redis-check-aof –fix进行修复
　　　c.用diff -u来看下两个文件的差异，确认问题点
　　　d.重启redis，加载修复后的AOF文件

七 Redis 主从同步

• redis的主从同步是异步进行的，这意味着主从同步不会影响主逻辑，也不会降低redis的处理性能。
• 主从架构中，可以考虑关闭主服务器的数据持久化功能，只让从服务器进行持久化，这样可以提高主服务器的处理性能。
• 在主从架构中，从服务器通常被设置为只读模式，这样可以避免从服务器的数据被误修改。
• 但是从服务器仍然可以接受CONFIG等指令，所以还是不应该将从服务器直接暴露到不安全的网络环境中。
• 如果必须如此，那可以考虑给重要指令进行重命名，来避免命令被外人误执行。
• 重命名指定可以参考另一篇blog

八 Redis 同步

• 从服务器会向主服务器发出SYNC指令，当主服务器接到此命令后，就会调用BGSAVE指令来创建一个子进程专门进行数据持久化工作，也就是将主服务器的数据写入RDB文件中。
• 在数据持久化期间，主服务器将执行的写指令都缓存在内存中。
• 在BGSAVE指令执行完成后，主服务器会将持久化好的RDB文件发送给从服务器，从服务器接到此文件后会将其存储到磁盘上，然后再将其读取到内存中。
• 这个动作完成后，主服务器会将这段时间缓存的写指令再以redis协议的格式发送给从服务器。

九 redis 事务

• 事务是指“一个完整的动作，要么全部执行，要么什么也没有做”。
• 四个redis指令，即MULTI、EXEC、DISCARD、WATCH。这四个指令构成了redis事务处理的基础。
• MULTI用来组装一个事务；
• EXEC用来执行一个事务；
• DISCARD用来取消一个事务；
• WATCH用来监视一些key，一旦这些key在事务执行之前被改变，则取消事务的执行。

　　例子：

redis> MULTI //标记事务开始 
OK
redis> INCR user_id //多条命令按顺序入队
QUEUED
redis> INCR user_id
QUEUED
redis> INCR user_id
QUEUED
redis> PING
QUEUED
redis> EXEC //执行
1) (integer) 1
2) (integer) 2
3) (integer) 3
4) PONG

• QUEUED的字样，这表示我们在用MULTI组装事务时，每一个命令都会进入到内存队列中缓存起来，如果出现QUEUED则表示我们这个命令成功插入了缓存队列，在将来执行EXEC时，这些被QUEUED的命令都会被组装成一个事务来执行.
• 对于事务的执行来说，如果redis开启了AOF持久化的话，那么一旦事务被成功执行，事务中的命令就会通过write命令一次性写到磁盘中去。
• 如果在向磁盘中写的过程中恰好出现断电、硬件故障等问题，那么就可能出现只有部分命令进行了AOF持久化，这时AOF文件就会出现不完整的情况。这时，我们可以使用redis-check-aof工具来修复这一问题，这个工具会将AOF文件中不完整的信息移除，确保AOF文件完整可用。

    两类错误：

• 调用EXEC之前的错误。
• 有可能是由于语法有误导致的，也可能时由于内存不足导致的。只要出现某个命令无法成功写入缓冲队列的情况，redis都会进行记录，在客户端调用EXEC时，redis会拒绝执行这一事务。
• 调用EXEC之后的错误。
• Redis则采取了完全不同的策略，即redis不会理睬这些错误，而是继续向下执行事务中的其他命令。这是因为，对于应用层面的错误，并不是redis自身需要考虑和处理的问题，所以一个事务中如果某一条命令执行失败，并不会影响接下来的其他命令的执行。
• WATCH本身的作用是“监视key是否被改动过”，而且支持同时监视多个key，只要还没真正触发事务，WATCH都会尽职尽责的监视，一旦发现某个key被修改了，在执行EXEC时就会返回nil，表示事务无法触发。

redis 基础

标签：

原文地址：http://www.cnblogs.com/fangshenghui/p/5693734.html