基于key-value的存储系统Redis

一、CAP原理

CAP是2000年PODC上Eric Brewer提出的一个概念，即Consistency（一致性），Availability（可用性），Partition tolerance（分区容错性），但是三者不可兼得。经典的关系型数据库在C，A两方面做的非常好，但在互联网飞速发展的今天，在网络扩展方面出现了致命的硬伤。由于各种web2.0网站追求用户创造内容，于是产生了大量的写操作，关系型数据库的replication模式已经不能承受，数据库必须进行分割。但分割对于业务没有普遍性，于是数据库的扩容变得捉襟见肘。于是，key-value数据库应运而生。
Key-value数据库就是尽可能地满足A，P两方面，甚至不惜牺牲C来满足。
于是key-value数据库中，基本不支持事务，大多自带replication功能，可以很方便的分表以及分布式实现。

二、Redis的原理

Redis是一个由Salvatore Sanfilippo用C语言实现的高性能的key-value类型的内存持久性数据库。Redis定位于一个内存数据库，但事实是其并不是将所有的数据都存储在内存中其持久性体现在在硬盘上进行写操作，它不仅仅是一种简单的key-value存储。类似于memcached，但Redis支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)和zset(有序集合)。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，Redis支持各种不同方式的排序。为了保证效率，数据都是缓存在内存中。但是Redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。

三、Redis的特点

1）支持多种数据结构
//Redis除了提供常规的数值或字符串外还提供4种数据类型：List、Set、Zset（Sorted Set）和Hset(Hash Set)。
//a. String（字符串）
String数据结构是简单的key-value类型，Value其实不仅是String,也可以是数字，使用Stirngs类型，可以完全实现目前Memcached的功能，并且效率更高；还可以享受Redis的定时持久化、操作日志及Repulication等功能。
//b. List(双向链表)
Lists就是链表，使用Lists结构可以轻松地实现最新消息排行等功能。Lists的另一个应用就是消息队列，可以利用Lists的PUSH操作将任务存在Lists中，随后工作线程再用POP操作将任务取出进行执行。Redis还提供了操作Lists中某一段的API，可以直接查询、删除Lists中某一段的元素。
//c. Set(集合
Sets是一个集合，集合的概念就是一堆不重复值的组合。Set是String类型的无序集合。Redis还为集合提供了求交集、并集、差集等操作，可以非常方便地实现如共同关注、共同喜好、二度好友等功能，对上面的所有集合操作还可以使用不同命令选择将结果返回给客户端还是保存到一个新的集合中。
//d. Zset(有序集合)
Zset与Set相似，但在Set的基础上增加了一个Score的属性。这一属性在添加修改元素时进行指定，每次指定后，Zset会自动按新的值重新调整顺序。
//e. Hash(hash表)
在Memcached中，经常将一些结构化的信息打包成hashmap，在客户端序列化后存储为一个字符串的值，比如用户的昵称、年龄、性别、积分等，在需要修改其中某一项时，通常需要将所有值取出反序列化后，修改某一项的值，再序列化存储回去。这样不仅增大了开销，也不适用于一些可能并发操作的场合（比如两个并发的操作都需要修改积分）。而Redis的Hash结构可以实现像在数据库中Update一个属性一样只修改某一项属性值。
2）Redis事务控制
Redis可以通过MULTI/EXEC来支持简单的事务控制。Redis只能保证事务中的所有命令串行执行，在事务的执行过程中不会为其他客户端发起的请求提供服务。当一个client使用multi命令时，这个连接会进入一个事务上下文，该连接后续的命令会放在一个队列中，当此连接收到exec命令后，Redis会顺序地执行队列中的所有命令，但是如果事务中的一个命令失败了，并不回滚其他命令。
3）持久化机制
Redis是一个能支持持久化的内存数据库，它通过将内存中的数据保存到磁盘来持久化。Redis有两种持久化方式，一种是Snapshotting（快照）,另一种是append-only file（缩写aof）的方式。下面分别介绍：
a. Snapshotting方式
快照是默认的持久化方式。这种方式是将内存中数据以快照的方式写入到二进制文件dump.rdb中。可以通过配置redis.conf来设置自动做快照持久化的方式。
b. aof方式
如果对数据要求很高，可以采用aof持久化方式。因为在使用aof持久化时，Redis会将每个命令都追加到appendonly.aof文件中，当Redi出现意外关闭后，重启后会通过执行appendonly.aof文件中的命令来在内存中重建整个数据。
4）主从复制
Redis主从复制配置非常简单，可以通过配置redis.conf文件中的Replication段来实现主从复制。Redis主从复制特点：
a. 支持一个master可以拥有多个slave，同时slave还可以接受其他的slave.
b. 主从复制不会阻塞master和slave,在同步数据时，master和slaver都可以接收client请求。
通过主从复制的特性可以做到以下3个方面：
1.可以做到读写分离，提供系统伸缩性和系统性能，如master主服务用来写数据，slave服务用来读数据。
2.可以做到备份数据分离，如slave服务器群中的一个或两个服务器用来备份数据。
3.虽然Redis宣称主从复制无阻塞，但是由于Redis使用单线程服务，而与slave第一次与master做同步时，如果master快照文件较大，相应快照文件的传输将耗费较长时间，文件传输过程中master会造成访问延迟。

四、Redis的缺点

Redis的数据库容量受到物理内存的限制，不能用作海量数据的高性能读写。它最大限制数据量是1GB，数据库容量受到物理内存的限制，因此在面对海量数据的读写时表现性能不是非常好，而且没有原生的可扩展机制，因此也没有可扩展的能力，需要通过依赖客户端才能实现分布式的读写。所以Redis主要适合在较小数据量的高性能操作和运算上。