企业级nosql数据库应用与实战-redis

一、NoSQL简介

1.1.1 MySQL主从读写分离

　　由于数据库的写入压力增加，Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术达到读写分离，以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了。

1.1.2 分库分表

　　随着web2.0的继续高速发展，在Memcached的高速缓存，MySQL的主从复制，读写分离的基础之上，这时MySQL主库的写压力开始出现瓶颈，而数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替MyISAM。同时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候，分表分库成了一个热门技术，是业界讨论的热门技术问题。也就在这个时候，MySQL推出了还不太稳定的表分区，这也给技术实力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群，但是由于在互联网几乎没有成功案例，性能也不能满足互联网的要求，只是在高可靠性上提供了非常大的保证。

关系型数据库面临的问题：

扩展困难：由于存在类似Join这样多表查询机制，使得数据库在扩展方面很艰难；
读写慢：这种情况主要发生在数据量达到一定规模时由于关系型数据库的系统逻辑非常复杂，使得其非常容易发生死锁等的并发问题，所以导致其读写速度下滑非常严重；
成本高：企业级数据库的License价格很惊人，并且随着系统的规模，而不断上升；
有限的支撑容量：现有关系型解决方案还无法支撑Google这样海量的数据存储；

数据库访问的新需求：

低延迟的读写速度：应用快速地反应能极大地提升用户的满意度；
支撑海量的数据和流量：对于搜索这样大型应用而言，需要利用PB级别的数据和能应对百万级的流量；
大规模集群的管理：系统管理员希望分布式应用能更简单的部署和管理；
庞大运营成本的考量：IT经理们希望在硬件成本、软件成本和人力成本能够有大幅度地降低；
NoSQL数据库仅仅是关系数据库在某些方面（性能、扩展）的一个弥补
单从功能上讲，NoSQL的几乎所有的功能，在关系数据库上都能够满足。
一般会把NoSQL和关系数据库进行结合使用，各取所长，各得其所。
在某些应用场合，比如一些配置的关系键值映射存储、用户名和密码的存储、Session会话存储等等
在某些场景下，用NoSQL完全可以替代关系数据库(如：MySQL)存储。不但具有更高的性能，而且开发也更加方

1.3 分布式系统的挑战

CAP原理是指这三个要素最多只能同时实现两点，不可能三者兼顾。因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求，否则就失去了价值。因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。对于大多数WEB应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是多数分布式数据库产品的方向

在理论计算机科学中，CAP定理（CAP theorem），又被称作布鲁尔定理(Brewer’s theorem)，它指出对于一个分布式计算系统来说，不可能同时满足以下三点

一致性（Consistency)—所有节点在同一时间具有相同的数据
可用性（Availability）—保证每个请求不管成功或者失败都有响应
分隔容忍（Partition tolerance）—系统中任意信息的丢失或失败不会影响系统的继续运作

1.3.1关系数据库和NoSQL侧重点

关系数据库	NoSQL
分布式关系型数据库中强调的`ACID`分别是：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）	对于许多互联网应用来说，对于一致性要求可以降低，而可用性(Availability)的要求则更为明显，在CAP理论基础上，从而产生了弱一致性的理论BASE。
ACID的目的就是通过事务支持，保证数据的完整性和正确性	`BASE`分别是英文：Basically，Available（基本可用）， Softstate（软状态）非实时同步，Eventual Consistency（最终一致）的缩写，这个模型是反`ACID`模型

1.4 NoSQL的优缺点

优点：

简单的扩展

　　典型例子是Cassandra，由于其架构是类似于经典的P2P，所以能通过轻松地添加新的节点来扩展这个集群；

快速的读写

　　主要例子有Redis，由于其逻辑简单，而且纯内存操作，使得其性能非常出色，单节点每秒可以处理超过10万次读写操作；

低廉的成本

　　这是大多数分布式数据库共有的特点，因为主要都是开源软件，没有昂贵的License成本；

缺点：

不提供对SQL的支持

　　如果不支持SQL这样的工业标准，将会对用户产生一定的学习和应用迁移成本；

支持的特性不够丰富

　　现有产品所提供的功能都比较有限，大多数NoSQL数据库都不支持事务，也不像Oracle那样能提供各种附加功能，比如BI和报表等；

现有产品的不够成熟

　　大多数产品都还处于初创期，和关系型数据库几十年的完善不可同日而语

1.5 NoSQL总结

NoSQL数据库的出现，弥补了关系数据（比如MySQL）在某些方面的不足，在某些方面能极大的节省开发成本和维护成本。
MySQL和NoSQL都有各自的特点和使用的应用场景，两者的紧密结合将会
给web2.0的数据库发展带来新的思路。让关系数据库关注在关系上，NoSQL关注在功能、性能上。
随着移动互联网的发展，以及业务场景的多样化，社交元素的普遍化，Nosql从性能和功能上很好的补充了web2.0时代的原关系型数据的缺点，目前已经是各大公司必备的技术之一

二、NoSQL的分类

2.1 基本分类

Column-oriented（列式）

主要围绕着“列（Column）”，而非 “行（Row）”进行数据存储
属于同一列的数据会尽可能地存储在硬盘同一个页（Page）中
大多数列式数据库都支持Column Family这个特性
（很多类似数据仓库（Data Warehouse）的应用，虽然每次查询都会处理很多数据，但是每次所涉及的列并没有很多）
特点：比较适合汇总（Aggregation）和数据仓库这类应用。

Key-value(重要)

类似常见的HashTable，一个Key对应一个Value，但是其能提供非常快的查询速度、大的数据存放量和高并发操作，

非常适合通过主键对数据进行查询和修改等操作，虽然不支持复杂的操作，但可通过上层的开发来弥补这个缺陷。

Document（文档） (比如：mongodb)

类似常见的HashTable，一个Key对应一个Value，
其能提供非常快的查询速度、大的数据存放量和高并发操作，
非常适合通过主键对数据进行查询和修改等操作，
数据类型多且存在大量的空项。比如SNS类的用户profile，手机，邮箱，地址，性别……有很多项，而且大部分是空项。

2.2 常见分类

关注一致性和可用性的(CA)

这些数据库对于分区容忍性方面比较不感冒，主要采用复制（Replication）这种方式来保证数据的安全性，常见的CA系统有：

传统关系型数据库，比如Postgres和MySQL等(Relational)
- Oracle (Relational)
- Aster Data (Relational)
- Greenplum (Relational)

关注一致性和分区容忍性的(CP)

这种系统将数据分布在多个网络分区的节点上，并保证这些数据的一致性，但是对于可用性的支持方面有问题，比如当集群出现问题的话，节点有可能因无法确保数据是一致性的而拒绝提供服务，主要的CP系统有：

BigTable (Column-oriented)
Hypertable (Column-oriented)
HBase (Column-oriented)
MongoDB (Document)
Terrastore (Document)
Redis (Key-value)
Scalaris (Key-value)
MemcacheDB (Key-value)
Berkeley DB (Key-value)

关于可用性和分区容忍性的(AP)

这类系统主要以实现“最终一致性（Eventual Consistency）”来确保可用性和分区容忍性，AP的系统有：

三、企业常见Nosql应用

3.1 纯NoSQL架构（Nosql为主）

在一些数据结构、查询关系非常简单的系统中，我们可以只使用NoSQL即可以解决存储问题。
在一些数据库结构经常变化，数据结构不定的系统中，就非常适合使用NoSQL来存储。
- 比如监控系统中的监控信息的存储，可能每种类型的监控信息都不太一样。
有些NoSQL数据库已经具有部分关系数据库的关系查询特性，他们的功能介于key-value和关系数据库之间，却具有key-value数据库的性能，基本能满足绝大部分web 2.0网站的查询需求。

纯Nosql架构

3.2 以NoSQL为数据源的架构（Nosql为主）

数据直接写入NoSQL，再通过NoSQL同步协议复制到其他存储。
根据应用的逻辑来决定去相应的存储获取数据。
应用程序只负责把数据直接写入到NoSQL数据库，然后通过NoSQL的复制协议，把NoSQL数据的每次写入，更新，删除操作都复制到MySQL数据库中。
同时，也可以通过复制协议把数据同步复制到全文检索实现强大的检索功能。
这种架构需要考虑数据复制的延迟问题，这跟使用MySQL的mastersalve模式的延迟问题是一样的，解决方法也一样。

Nosql为主

3.3 NoSQL作为镜像（nosql为辅）

不改变原有的以MySQL作为存储的架构，使用NoSQL作为辅助镜像存储，用NoSQL的优势辅助提升性能。
在原有基于MySQL数据库的架构上增加了一层辅助的NoSQL存储。
在写入MySQL数据库后，同时写入到NoSQL数据库，让MySQL和NoSQL拥有相同的镜像数据。
在某些可以根据主键查询的地方，使用高效的NoSQL数据库查询。

Nosql为辅

3.4 NoSQL为镜像（同步模式，nosql为辅）

通过MySQL把数据同步到NoSQL中, ，是一种对写入透明但是具有更高技术难度一种模式
适用于现有的比较复杂的老系统，通过修改代码不易实现，可能引起新的问题。同时也适用于需要把数据同步到多种类型的存储中。

同步模式，Nosql为辅

3.5 MySQL和NoSQL组合（nosql为辅）

MySQL中只存储需要查询的小字段，NoSQL存储所有数据。
把需要查询的字段，一般都是数字，时间等类型的小字段存储于MySQL中，根据查询建立相应的索引，
其他不需要的字段，包括大文本字段都存储在NoSQL中。
在查询的时候，我们先从MySQL中查询出数据的主键，然后从NoSQL中直接取出对应的数据即可。

Nosql为辅

3.6 其他应用

由于NoSQL数据库天生具有高性能、易扩展的特点，所以我们常常结合关系数据库，存储一些高性能的、海量的数据。
　　从另外一个角度看，根据NoSQL的高性能特点，它同样适合用于缓存数据。用NoSQL缓存数据可以分为内存模式和磁盘持久化模式。

内存模式

Memcached提供了相当高的读写性能，在互联网发展过程中，一直是缓存服务器的首选。
NoSQL数据库Redis又为我们提供了功能更加强大的内存存储功能。跟Memcached比，Redis的一个key的可以存储多种数据结构Strings、Hashes、Lists、Sets、Sorted sets。
Redis不但功能强大，而且它的性能完全超越大名鼎鼎的Memcached。
- Redis支持List、hashes等多种数据结构的功能，提供了更加易于使用的api和操作性能，比如对缓存的list数据的修改

持久化模式

虽然基于内存的缓存服务器具有高性能，低延迟的特点，但是内存成本高、内存数据易失却不容忽视。
大部分互联网应用的特点都是数据访问有热点，也就是说，只有一部分数据是被频繁访问的。
其实NoSQL数据库内部也是通过内存缓存来提高性能的，通过一些比较好的算法
- 把热点数据进行内存cache
- 非热点数据存储到磁盘
- 以节省内存占用
使用NoSQL来做缓存，由于其不受内存大小的限制，我们可以把一些不常访问、不怎么更新的数据也缓存起来

四、redis

4.1 什么是redis？

redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sortedset --有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。
　　 Redis 是一个高性能的key-value数据库。 redis的出现，很大程度补偿了memcached这类key/value存储的不足，在部分场合可以对关系数据库起到很好的补充作用。它提供了Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客户端，使用很方便。
　Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。存盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。
　　redis的官网地址，非常好记，是redis.io。

　　目前，Vmware在资助着redis项目的开发和维护

4.2 redis的特性

完全居于内存，数据实时的读写内存，定时闪回到文件中。采用单线程,避免了不必要的上下文切换和竞争条件；
支持高并发量，官方宣传支持10万级别的并发读写；
支持持久存储，机器重启后的，重新加载模式，不会掉数据；
海量数据存储，分布式系统支持，数据一致性保证，方便的集群节点添加/删除；
Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储；
灾难恢复–memcache挂掉后，数据不可恢复; redis数据丢失后可以通过aof恢复；
虚拟内存–Redis当物理内存用完时，可以将一些很久没用到的value 交换到磁盘；
Redis支持数据的备份，即master-slave模式的数据备份。

redis的架构

各功能模块说明如下：
File Event: 处理文件事件，接受它们发来的命令请求（读事件），并将命令的执行结果返回给客户端（写事件）)
Time Event: 时间事件(更新统计信息，清理过期数据，附属节点同步，定期持久化等)
AOF: 命令日志的数据持久化
RDB：实际的数据持久化
Lua Environment : Lua 脚本的运行环境. 为了让 Lua 环境符合 Redis 脚本功能的需求，Redis 对 Lua 环境进行了一系列的修改，包括添加函数库、更换随机函数、保护全局变量，等等
Command table(命令表)：在执行命令时，根据字符来查找相应命令的实现函数。
Share Objects（对象共享）：
主要存储常见的值：
　　a.各种命令常见的返回值，例如返回值OK、ERROR、WRONGTYPE等字符；
　　b. 小于 redis.h/REDIS_SHARED_INTEGERS (默认1000)的所有整数。通过预分配的一些常见的值对象，并在多个数据结构之间共享对象，程序避免了重复分配的麻烦。也就是说，这些常见的值在内存中只有一份。
Databases：Redis数据库是真正存储数据的地方。当然，数据库本身也是存储在内存中的。

4.4 redis 启动流程

redis启动流程

4.5 redis 安装方式

redis安装常用两种方式，yum安装和源码包安装
　　yum 安装：通常是在线安装，好处是安装方式简单，不易出错；常用的安装yum源为epel。
　　源码包安装：是先将 redis 的源码下载下来，在自己的系统里编译生成可执行文件，然后执行，好处是因为是在自己的系统上编译的，更符合自己系统的性能，也就是说在自己的系统上执行 redis 服务性能效率更好。
　　区别：路径和启动方式不同，支持的模块也不同。

4.5.1 redis 程序路径

    配置文件： /etc/redis.conf
    主程序： /usr/bin/redis-server
    客户端： /usr/bin/redis-cli
    Unit File:/usr/lib/systemd/system/redis.service
    数据目录： /var/lib/redis
    监听： 6379/tcp

4.6 redis 配置文件

4.6.1 网络配置项(NETWORK)

### NETWORK ###
bind IP   #监听地址192.168.1.100 10.0.0.1  127.0.0.1 ::1
port PORT    #监听端口
protected-mode yes    #是否开启保护模式，默认开启。要是配置里没有指定bind和密码。开启该参数后，redis只会本地进行访问，拒绝外部访问。
tcp-backlog 511   #定义了每一个端口最大的监听队列的长度
unixsocket /tmp/redis.sock    #也可以打开套接字监听
timeout 0    #连接的空闲超时时长；

4.6.2 通用配置项(GENERAL)

### GENERAL ###
daemonize no    #是否以守护进程启动
supervised no    #可以通过upstart和systemd管理Redis守护进程，这个参数是和具体的操作系统相关的
pidfile "/var/run/redis/redis.pid"    #pid文件
loglevel notice   #日志等级
logfile "/var/log/redis/redis.log"    #日志存放文件
databases 16     #设定数据库数量，默认为16个，每个数据库的名字均为整数，从0开始编号，默认操作的数据库为0；
	切换数据库的方法：SELECT <dbid>

4.6.3 快照配置(SNAPSHOTTING)

### SNAPSHOTTING  ###
save 900 1         #900秒有一个key变化，就做一个保存
save 300 10       #300秒有10个key变化，就做一个保存，这里需要和开发沟通
save 60 10000   #60秒有10000个key变化就做一个保存
stop-writes-on-bgsave-error yes   #在出现错误的时候，是不是要停止保存
rdbcompression yes   #使用压缩rdb文件，rdb文件压缩使用LZF压缩算法，yes：压缩，但是需要一些cpu的消耗；no：不压缩，需要更多的磁盘空间
rdbchecksum yes    #是否校验rdb文件。从rdb格式的第五个版本开始，在rdb文件的末尾会带上CRC64的校验和。这跟有利于文件的容错性，但是在保存rdb文件的时候，会有大概10%的性能损耗，所以如果你追求高性能，可以关闭该配置。
dbfilename "along.rdb"     #rdb文件的名称
dir "/var/lib/redis"    #数据目录，数据库的写入会在这个目录。rdb、aof文件也会写在这个目录

4.6.4 限制相关配置(LIMITS)

### LIMITS ###
maxclients 10000    #设置能连上redis的最大客户端连接数量
maxmemory <bytes>    #redis配置的最大内存容量。当内存满了，需要配合maxmemory-policy策略进行处理。
maxmemory-policy noeviction    #淘汰策略：volatile-lru, allkeys-lru, volatile-random, allkeys-random, volatile-ttl, noeviction
内存容量超过maxmemory后的处理策略：
① # volatile-lru：利用LRU算法移除设置过过期时间的key。
② # volatile-random：随机移除设置过过期时间的key。
③ # volatile-ttl：移除即将过期的key，根据最近过期时间来删除（辅以TTL）
④ # allkeys-lru：利用LRU算法移除任何key。
⑤ # allkeys-random：随机移除任何key。
⑥ # noeviction：不移除任何key，只是返回一个写错误。
# 上面的这些驱逐策略，如果redis没有合适的key驱逐，对于写命令，还是会返回错误。redis将不再接收写请求，只接收get请求。写命令包括：set setnx
maxmemory-samples 5   #淘汰算法运行时的采样样本数

4.6.5 持久化配置(APPEND ONLY MODE)

### APPEND ONLY MODE ###
# 默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了。但是redis如果中途宕机，会导致可能有几分钟的数据丢失，根据save来策略进行持久化，Append Only File是另一种持久化方式，可以提供更好的持久化特性。Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件，每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件。
appendonly no    #不启动aof模式
appendfilename "appendonly.aof"    #据读入内存里，先忽略RDB文件，aof文件名(default: "appendonly.aof")
appendfsync
Redis supports three different modes:
no：redis不执行主动同步操作，而是OS进行；
everysec：每秒一次；
always：每语句一次

如果Redis只是将客户端修改数据库的指令重现存储在AOF文件中，那么AOF文件的大小会不断的增加，因为AOF文件只是简单的重现存储了客户端的指令，而并没有进行合并。对于该问题最简单的处理方式，即当AOF文件满足一定条件时就对AOF进行rewrite，rewrite是根据当前内存数据库中的数据进行遍历写到一个临时的AOF文件，待写完后替换掉原来的AOF文件即可。
　　redis重写会将多个key、value对集合来用一条命令表达。在rewrite期间的写操作会保存在内存的rewrite buffer中，rewrite成功后这些操作也会复制到临时文件中，在最后临时文件会代替AOF文件

no-appendfsync-on-rewrite no 
#在aof重写或者写入rdb文件的时候，会执行大量IO，此时对于everysec和always的aof模式来说，执行fsync会造成阻塞过长时间，no-appendfsync-on-rewrite字段设置为默认设置为no。如果对延迟要求很高的应用，这个字段可以设置为yes，否则还是设置为no，这样对持久化特性来说这是更安全的选择。设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes。Linux的默认fsync策略是30秒。可能丢失30秒数据。

auto-aof-rewrite-percentage 100 aof自动重写配置。当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，即当aof文件增长到一定大小的时候Redis能够调用bgrewrite aof对日志文件进行重写。当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。

auto-aof-rewrite-min-size 64mb #设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写。上述两个条件同时满足时，方会触发重写AOF；与上次aof文件大小相比，其增长量超过100%，且大小不少于64MB;

aof-load-truncated yes #指redis在恢复时,会忽略最后一条可能存在问题的指令。aof文件可能在尾部是不完整的，出现这种现象，可以选择让redis退出，或者导入尽可能多的数据。如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。
如果是no，用户必须手动redis-check-aof修复AOF文件才可以。
注意：持久机制本身不能取代备份；应该制订备份策略，对redis库定期备份；Redis服务器启动时用持久化的数据文件恢复数据，会优先使用AOF；

我们继续来看 redis 的持久化：
RDB：snapshotting, 二进制格式；按事先定制的策略，周期性地将数据从内存同步至磁盘；数据文件默认为dump.rdb；
　　客户端显式使用SAVE或BGSAVE命令来手动启动快照保存机制；
　　SAVE：同步，即在主线程中保存快照，此时会阻塞所有客户端请求；
　　BGSAVE：异步；backgroud
AOF：Append Only File, fsync
　　记录每次写操作至指定的文件尾部实现的持久化；当redis重启时，可通过重新执行文件中的命令在内存中重建出数据库；
　　BGREWRITEAOF：AOF文件重写；
　　不会读取正在使用AOF文件，而是通过将内存中的数据以命令的方式保存至临时文件中，完成之后替换原来的AOF文件；

4.6.6 慢查询日志相关配置(SLOW LOG)

### SLOW LOG ###
slowlog-log-slower-than 10000    #当命令的执行超过了指定时间，单位是微秒；1s=10^6微秒
slowlog-max-len 128   #慢查询日志长度。当一个新的命令被写进日志的时候，最老的那个记录会被删掉。
ADVANCED配置：
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
设置ziplist的键数量最大值，每个值的最大空间；

4.7 redis命令介绍

└── bin
├── redis-benchmark #redis性能测试工具，可以测试在本系统本配置下的读写性能
├── redis-check-aof #对更新日志appendonly.aof检查，是否可用
├── redis-check-dump #用于检查本地数据库的rdb文件
├── redis-cli #redis命令行操作工具，也可以用telnet根据其纯文本协议来操作
├── redis-sentinel Redis-sentinel 是Redis实例的监控管理、通知和实例失效备援服务，是Redis集群的管理工具
└── redis-server #redis服务器的daemon启动程序

4.7.1 redis-cli命令介绍

redis-cli -p 6379　　#默认选择 db库是 0
redis 127.0.0.1:6379> keys *　　#查看当前所在“db库”所有的缓存key
redis 127.0.0.1:6379> select 8　　#选择 db库
redis 127.0.0.1:6379> FLUSHALL　　#清除所有的缓存key
redis 127.0.0.1:6379 8> FLUSHDB　　#清除当前“db库”所有的缓存key
redis 127.0.0.1:6379> set keyname keyvalue　　#设置缓存值
redis 127.0.0.1:6379> get keyname #获取缓存值
redis 127.0.0.1:6379> del keyname #删除缓存值：返回删除数量（0代表没删除）

服务端的相关命令：

time：返回当前服务器时间
client list: 返回所有连接到服务器的客户端信息和统计数据参见http://redisdoc.com/server/client_list.html
client kill ip:port：关闭地址为 ip:port 的客户端
save：将数据同步保存到磁盘
bgsave：将数据异步保存到磁盘
lastsave：返回上次成功将数据保存到磁盘的Unix时戳
shundown：将数据同步保存到磁盘，然后关闭服务
info：提供服务器的信息和统计
config resetstat：重置info命令中的某些统计数据
config get：获取配置文件信息
config set：动态地调整 Redis 服务器的配置(configuration)而无须重启，可以修改的配置参数可以使用命令 CONFIG GET * 来列出
config rewrite：Redis 服务器时所指定的 redis.conf 文件进行改写
monitor：实时转储收到的请求
slaveof：改变复制策略设置
debug：sleep segfault
slowlog get：获取慢查询日志
slowlog len：获取慢查询日志条数
slowlog reset：清空慢查询

4.8 redis 常用数据类型

Redis内部使用一个redisObject对象来表示所有的key和value,redisObject最主要的信息如上图所示：

　　type代表一个value对象具体是何种数据类型
　　encoding是不同数据类型在redis内部的存储方式
　　比如：type=string代表value存储的是一个普通字符串，那么对应的encoding可以是raw或者是int,如果是int则代表实际redis内部是按数值型类存储和表示这个字符串的，当然前提是这个字符串本身可以用数值表示，比如:“123” "456"这样的字符串。
　　Redis的键值可以使用物种数据类型：字符串，散列表，列表，集合，有序集合。

4.8.1 对KEY操作的命令

exists(key)：确认一个key是否存在
del(key)：删除一个key
type(key)：返回值的类型
keys(pattern)：返回满足给定pattern的所有key
randomkey：随机返回key空间的一个
keyrename(oldname, newname)：重命名key
dbsize：返回当前数据库中key的数目
expire：设定一个key的活动时间（s）
ttl：获得一个key的活动时间
move(key, dbindex)：移动当前数据库中的key到dbindex数据库
flushdb：删除当前选择数据库中的所有key
flushall：删除所有数据库中的所有key

4.8.2 对String操作的命令

应用场景：String是最常用的一种数据类型，普通的key/ value 存储都可以归为此类.即可以完全实现目前 Memcached 的功能，并且效率更高。还可以享受Redis的定时持久化，操作日志及 Replication等功能。除了提供与 Memcached 一样的get、set、incr、decr 等操作外，Redis还提供了下面一些操作：

set(key, value)：给数据库中名称为key的string赋予值value
get(key)：返回数据库中名称为key的string的value
getset(key, value)：给名称为key的string赋予上一次的value
mget(key1, key2,…, key N)：返回库中多个string的value
setnx(key, value)：添加string，名称为key，值为value
setex(key, time, value)：向库中添加string，设定过期时间time
mset(key N, value N)：批量设置多个string的值
msetnx(key N, value N)：如果所有名称为key i的string都不存在
incr(key)：名称为key的string增1操作
incrby(key, integer)：名称为key的string增加integer
decr(key)：名称为key的string减1操作
decrby(key, integer)：名称为key的string减少integer
append(key, value)：名称为key的string的值附加value
substr(key, start, end)：返回名称为key的string的value的子串