Redis学习手册(开篇)

一、简介：

     在过去的几年中，NoSQL数据库一度成为高并发、海量数据存储解决方案的代名词，与之相应的产品也呈现出雨后春笋般的生机。然而在众多产品中能够脱颖而 出的却屈指可数，如Redis、MongoDB、BerkeleyDB和CouchDB等。由于每种产品所拥有的特征不同，因此它们的应用场景也存在着一 定的差异，下面仅给出简单的说明：
      1). BerkeleyDB是一种极为流行的开源嵌入式数据库，在更多情况下可用于存储引擎，比如BerkeleyDB在被Oracle收购之前曾作为 MySQL的存储引擎，由此可以预见，该产品拥有极好的并发伸缩性，支持事务及嵌套事务，海量数据存储等重要特征，在用于存储实时数据方面具有极高的可用 价值。然而需要指出的是，该产品的Licence为GPL，这就意味着它并不是在所有情况下都是免费使用的。
      2). 对MongoDB的定义为Oriented-Document数据库服务器，和BerkeleyDB不同的是该数据库可以像其他关系型数据库服务器那样独 立的运行并提供相关的数据服务。从该产品的官方文档中我们可以获悉，MongoDB主要适用于高并发的论坛或博客网站，这些网站具有的主要特征是并发访问 量高、多读少写、数据量大、逻辑关系简单，以及文档数据作为主要数据源等。和BerkeleyDB一样，该产品的License同为GPL。
      3). Redis，典型的NoSQL数据库服务器，和BerkeleyDB相比，它可以作为服务程序独立运行于自己的服务器主机。在很多时候，人们只是将 Redis视为Key/Value数据库服务器，然而事实并非如此，在目前的版本中，Redis除了Key/Value之外还支持List、Hash、 Set和Ordered Set等数据结构，因此它的用途也更为宽泛。对于此种误解，Redis官网也进行了相应的澄清。和以上两种产品不同的是，Redis的License是 Apache License，就目前而言，它是完全免费。
      4). memcached，数据缓存服务器。为什么在这里要给出该产品的解释呢？很简单，因为笔者认为它在使用方式上和Redis最为相似。毕竟这是一篇关于 Redis的技术系列博客，有鉴于此，我们将简要的对比一下这两个产品。首先说一下它们之间的最大区别，memcached只是提供了数据缓存服务，一旦 服务器宕机，之前在内存中缓存的数据也将全部消失，因此可以看出memcached没有提供任何形式的数据持久化功能，而Redis则提供了这样的功能。 再有就是Redis提供了更为丰富的数据存储结构，如Hash和Set。至于它们的相同点，主要有两个，一是完全免费，再有就是它们的提供的命令形式极为 接近。
   
二、Redis的优势：

      1). 和其他NoSQL产品相比，Redis的易用性极高，因此对于那些有类似产品使用经验的开发者来说，一两天，甚至是几个小时之后就可以利用Redis来搭建自己的平台了。
      2). 在解决了很多通用性问题的同时，也为一些个性化问题提供了相关的解决方案，如索引引擎、统计排名、消息队列服务等。

三、目前版本中Redis存在的主要问题：

      1). 在官方版本中没有提供Windows平台的支持，已发布的正式版本中只是支持类Unix和MacOSX平台。
      2). 没有提供集群的支持，然而据官网所述，预计在2.6版本中会加入该特征。
      3). Publication/Subscription功能中，如果master宕机，slave无法自动提升为master。
   
四、和关系型数据库的比较：

      在目前版本(2.4.7)的Redis中，提供了对五种不同数据类型的支持，其中只有一种类型，既string类型可以被视为Key-Value结构，而其他的数据类型均有适用于各自特征的应用场景，至于具体细节我们将会在该系列后面的博客中予以说明。
      相比于关系型数据库，由于其存储结构相对简单，因此Redis并不能对复杂的逻辑关系提供很好的支持，然而在适用于Redis的场景中，我们却可以由此而 获得效率上的显著提升。即便如此，Redis还是为我们提供了一些数据库应该具有的基础概念，如：在同一连接中可以选择打开不同的数据库，然而不同的 是，Redis中的数据库是通过数字来进行命名的，缺省情况下打开的数据库为0。如果程序在运行过程中打算切换数据库，可以使用Redis的select 命令来打开其他数据库，如select 1，如果此后还想再切换回缺省数据库，只需执行select 0即可。
      在数据存储方面，Redis遵循了现有NoSQL数据库的主流思想，即Key作为数据检索的唯一标识，我们可以将其简单的理解为关系型数据库中索引的键， 而Value则作为数据存储的主要对象，其中每一个Value都有一个Key与之关联，这就好比索引中物理数据在数据表中存储的位置。在Redis 中，Value将被视为二进制字节流用于存储任何格式的数据，如Json、XML和序列化对象的字节流等，因此我们也可以将其想象为RDB中的BLOB类 型字段。由此可见，在进行数据查询时，我们只能基于Key作为我们查询的条件，当然我们也可以应用Redis中提供的一些技巧将Value作为其他数据的 Key，这些知识我们都会在后面的博客中予以介绍。
   
五、如何持久化内存数据：

      缺省情况下，Redis会参照当前数据库中数据被修改的数量，在达到一定的阈值后会将数据库的快照存储到磁盘上，这一点我们可以通过配置文件来设定该阈 值。通常情况下，我们也可以将Redis设定为定时保存。如当有1000个以上的键数据被修改时，Redis将每隔60秒进行一次数据持久化操作。缺省设 置为，如果有9个或9个以下数据修改是，Redis将每15分钟持久化一次。
      从上面提到的方案中可以看出，如果采用该方式，Redis的运行时效率将会是非常高效的，既每当有新的数据修改发生时，仅仅是内存中的缓存数据发生改变， 而这样的改变并不会被立即持久化到磁盘上，从而在绝大多数的修改操作中避免了磁盘IO的发生。然而事情往往是存在其两面性的，在该方法中我们确实得到了效 率上的提升，但是却失去了数据可靠性。如果在内存快照被持久化到磁盘之前，Redis所在的服务器出现宕机，那么这些未写入到磁盘的已修改数据都将丢失。 为了保证数据的高可靠性，Redis还提供了另外一种数据持久化机制--Append模式。如果Redis服务器被配置为该方式，那么每当有数据修改发生 时，都会被立即持久化到磁盘。