Redis教程(一)：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服务器被配置为该方式，那末每当有数据修改产生时，都会被立即持久化到磁盘。