前言

Redis 是一个 Key-Value 存储系统。和 Memcached 类似，它支持存储的 value 类型相对更多，包括 string(字符串)、list(链表)、set(集合)和 zset(有序集合)。这些数据类型都支持 push/pop、 add/remove 及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，Redis 支持各种不同方式的排序。与 memcached 一样，为了保证效率，数据都是缓存在内存中。区别的是 Redis 会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了 master-slave(主从)同步。

下面我们先讲一下Key-Value存储系统和为什么选择Key-Value Store。

一、 Key-Value 存储系统简介

Key-Value Store 是当下比较流行的话题，尤其在构建诸如搜索引擎、IM、P2P、游戏服务器、 SNS 等大型互联网应用以及提供云计算服务的时候，怎样保证系统在海量数据环境下的高性能、高可靠性、高扩展性、高可用性、低成本成为所有系统架构们挖苦心思考虑的重点，而怎样解决数据库服务器的性能瓶颈是最大的挑战。

按照分布式领域的 CAP 理论（Consistency、 Availability、Tolerance to network Partitions 这三部分在任何系统架构实现时只可能同时满足其中二点，没法三者兼顾）来衡量，传统的关系数据库的 ACID 只满足了 Consistency、Availability，因此在 Partition tolerance 上就很难做得好。另外传统的关系数据库处理海量数据、分布式架构时候在 Performance、Scalability、 Availability 等方面也存在很大的局限性。

而 Key-Value Store 更加注重对海量数据存取的性能、分布式、扩展性支持上，并不需要传统关系数据库的一些特征，例如：Schema、事务、完整 SQL 查询支持等等，因此在分布式环境下的性能相对于传统的关系数据库有较大的提升。

Key-Value 数据库分为很多种类，具体如下图：

Redis——Key-Value存储系统和为什么选择Key-Value Store

这些Key-Value数据库，有的是用C/C++编写的，有的是用Java编写的，还有的是用Erlang编写的，每个都有自己的独到之处，我们从中挑选一些比较有特色且应用广泛的产品学习和了解一下。

1.1Voldemort

Voldemort 是一个分布式 Key/Value 存储系统，它具有以下特点：

数据自动在多个服务器之间复制;
数据自动分区，因此每个服务器只包括整体数据的一个子集;
服务器故障处理是透明的;  支持插入式序列化，允许丰富的 Key 和 Value 类型，包括列表和元组，也可以集成常见的序列化框架，如 Protocol Buffers，Thrift，Avro 和 Java Serialization
数据项支持版本化，即使在故障情况下，数据完整性也可以得到保障;
每个节点都是独立的，无需其他节点协调，因此也没有中央节点;
单节点性能优秀：根据机器配置、网络、磁盘系统和数据复制因素的不同，每秒可以执行 10-20k 操作;
支持地理分散式部署。

1.2 Dynamo

Dynamo 是亚马逊的 key-value 模式的存储平台，可用性和扩展性都很好，性能也不错：读写访问中 99.9%的响应时间都在 300ms 内。

接下来对 Dynamo 需要的一些特性做一下简要的描述：

Cost-effectiveness - 省钱！Dynamo 不像一些商用数据库产品，需要昂贵的服务器来得到良好的性能，而且可能增加 5％的访问量会需要你花 2 万美刀去买一台新服务器。而在 Dynamo 上，由于是利用一堆廉价机器来存数据，于是你可能只需要花个 500 刀买个破机器加入到集群里就行了。
Dynamo 是一个 Key-Value 存储 - 因此他不支持外键和关联查询什么的。其 Value 值是二进制存储的，所以查询条件也只能作用在 Key 上。
配置简单的分布式存储 - 这是由于 Dynamo 是去中心化地设计，在集群中它的每一台机器都是对等的，不像 MongoDB 这样的中心化设计，于是它也不会有单点问题。

1.3 memcachedb

memcachedb 是一个由新浪网的开发人员开放出来的开源项目，给 memcached 分布式缓存服务器添加了 Berkeley DB 的持久化存储机制和异步主辅复制机制，让 memcached 具备了事务恢复能力、持久化能力和分布式复制能力，非常适合于需要超高性能读写速度，但是不需要严格事务约束，能够被持久化保存的应用场景，例如 memcachedb 被应用在新浪博客上面。

1.4 Cassandra

Apache Cassandra 是一套开源分布式 Key-Value 存储系统。它最初由 Facebook 开发，用于储存特别大的数据。Facebook 目前在使用此系统。

主要特性：

分布式
基于 column 的结构化
高伸展性

Cassandra 的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对 Cassandra 的一个写操作，会被复制到其他节点上去，对 Cassandra 的读操作，也会被路由到某个节点上面去读取。对于一个 Cassandra 群集来说，扩展性能是比较简单的事情，只管在群集里面添加节点就可以了。

Cassandra 是一个混合型的非关系的数据库，类似于 Google 的 BigTable。其主要功能比 Dynomite（分布式的 Key-Value 存储系统）更丰富，但支持度却不如文档存储 MongoDB（介于关系数据库和非关系数据库之间的开源产品，是非关系数据库当中功能最丰富，最像关系数据库的。支持的数据结构非常松散，是类似 json 的 bjson 格式，因此可以存储比较复杂的数据类型。）Cassandra 最初由 Facebook 开发，后转变成了开源项目。它是一个网络社交云计算方面理想的数据库。以 Amazon 专有的完全分布式的 Dynamo 为基础，结合了 Google BigTable 基于列族（Column Family）的数据模型。P2P 去中心化的存储。很多方面都可以称之为 Dynamo 2.0。

和其他数据库比较，有几个突出特点：

模式灵活：使用 Cassandra，像文档存储，你不必提前解决记录中的字段。你可以在系 www.ChinaDBA.net 中国 DBA 超级论坛 9 统运行时随意的添加或移除字段。这是一个惊人的效率提升，特别是在大型部署上。 
真正的可扩展性：Cassandra 是纯粹意义上的水平扩展。为给集群添加更多容量，可以指向另一台电脑。你不必重启任何进程，改变应用查询，或手动迁移任何数据。 
多数据中心识别：你可以调整你的节点布局来避免某一个数据中心起火，一个备用的数据中心将至少有每条记录的完全复制。 
范围查询：如果你不喜欢全部的键值查询，则可以设置键的范围来查询。 
列表数据结构：在混合模式可以将超级列添加到 5 维。对于每个用户的索引，这是非常方便的。 
分布式写操作：有可以在任何地方任何时间集中读或写任何数据。并且不会有任何单点失败。

1.5 memcached

memcached 是一套分布式的快取系统，当初是 Danga Interactive 为了 LiveJournal 所发展的，但目前被许多软件（如 MediaWiki）所使用。这是一套开放源代码软件，以 BSD license 授权释出。

memcached 缺乏认证以及安全管制，这代表应该将 memcached 服务器放置在防火墙后。

memcached 的 API 使用三十二位元的循环冗余校验（CRC-32）计算键值后，将资料分散在不同的机器上。当表格满了以后，接下来新增的资料会以 LRU 机制替换掉。由于 memcached 通常只是当作快取系统使用，所以使用 memcached 的应用程式在写回较慢的系统时（像是后端的数据库）需要额外的程式码更新 memcached 内的资料。

memcached 具有多种语言的客户端开发包，包括Perl/PHP/JAVA/C/Python/Ruby/C#/MySQL/

1.6 Hypertable

Hypertable 是一个开源、高性能、可伸缩的数据库，它采用与 Google 的 Bigtable 相似的模型。在过去数年中，Google 为在 PC 集群上运行的可伸缩计算基础设施设计建造了三个关键部分。第一个关键的基础设施是 Google File System（GFS），这是一个高可用的文件系统，提供了一个全局的命名空间。它通过跨机器（和跨机架）的文件数据复制来达到高可用性，并因此免受传统文件存储系统无法避免的许多失败的影响，比如电源、内存和网络端口等失败。第二个基础设施是名为 Map-Reduce 的计算框架，它与 GFS 紧密协作，帮助处理收集到的海量数据。第三个基础设施是 Bigtable，它是传统数据库的替代。Bigtable 让你可以通过一些主键来组织海量数据，并实现高效的查询。Hypertable 是 Bigtable 的一个开源实现，并且根据我们的想法进行了一些改进。

二、为什么选择 Key-Value Store

大量的互联网用户选择 Key-Value Store 的原因具体是什么呢？主要分为下面的 2 个主要原因：

2.1 大规模的互联网应用

对于 google，ebay 这样的互联网企业，每时每刻都有无数的用户在使用它们提供的互联网服务，这些服务带来的就是大量的数据吞吐量，在同一时间，会并发的有成千上万的连接对数据库进行操作。在这种情况下，单台服务器或者几台服务器远远不能满足这些数据处理的需求，简单的升级服务器性能这样的 scale up 的方式也不行，所以唯一可以采用的办法就是 scale out 了。scale out 的方法有很多种，但大致分为两类：一类仍然采用 RDBMS，然后通过对数据库的垂直和水平切割将整个数据库部署到一个集群上，这种方法的优点在于可以采用 RDBMS 这种熟悉的技术，但缺点在于它是针对特定应用的，就是说，由于应用的不同，切割的方法是不一样的。

还有一类就是 google 所采用的方法，抛弃 RDBMS，采用 key-value 形式的存储，这样可以极大的增强系统的可扩展性（scalability），如果要处理的数据持续增大，多加机器就可以了。事实上，key-value 的存储就是由于 BigTable 等相关论文的发表慢慢进入人们的视野的。

2.2 云存储

如果说上一个问题还有可以替代的解决方案（切割数据库）的话，那么对于云存储来说，也许 key-value 的 store 就是唯一的解决方案了。云存储简单点说就是构建一个大型的存储平台给别人用，这也就意味着在这上面运行的应用其实是不可控的。如果其中某个客户的应用随着用户的增长而不断增长时，云存储供应商是没有办法通过数据库的切割来达到 scale 的，因为这个数据是客户的，供应商不了解这个数据自然就没法作出切割。在这种情况下， key-value 的 store 就是唯一的选择了，因为这种条件下的 scalability 必须是自动完成的，不能有人工干预。这也是为什么几乎所有的现有的云存储都是 key-value 形式的，例如 Amazon 的 smipleDB，底层实现就是 key-value，还有 google 的 GoogleAppEngine，采用的是 BigTable 的存储形式。也许唯一可能例外的是 MS 的解决方案，我在 Qcon 大会上听说 MS 的 Azure 平台的下一个版本中就会推出基于 RDBMS 的云存储，尽管我本人仍然对此保持怀疑。

Key-Value Store 最大的特点就是它的可扩展性，这也就是它最大的优势。所谓的可扩展性，在我看来这里包括了两方面内容。一方面，是指 Key-Value Store 可以支持极大的数据的存储，它的分布式的架构决定了只要有更多的机器，就能够保证存储更多的数据。另一方面，是指它可以支持数量很多的并发的查询。对于 RDBMS，一般几百个并发的查询就可以让它很吃力了，而一个 Key-Value Store，可以很轻松的支持上千的并发查询。下面而简单的罗列了一些特点：

Key-value store：一个 key-value 数据存储系统，只支持一些基本操作，如：SET(key, value) 和 GET(key) 等；
分布式：多台机器（nodes）同时存储数据和状态，彼此交换消息来保持数据一致，可视为一个完整的存储系统。
数据一致：所有机器上的数据都是同步更新的、不用担心得到不一致的结果；
冗余：所有机器（nodes）保存相同的数据，整个系统的存储能力取决于单台机器（node）的能力；
容错：如果有少数 nodes 出错，比如重启、当机、断网、网络丢包等各种 fault/fail 都 www.ChinaDBA.net 中国 DBA 超级论坛 11 不影响整个系统的运行；
高可靠性：容错、冗余等保证了数据库系统的可靠性。

2.3 Redis 实际应用案例

目前全球最大的 Redis 用户是新浪微博，在新浪有 200 多台物理机，400 多个端口正在运行着 Redis, 有+4G 的数据跑在 Redis 上来为微博用户提供服务。

Redis——Key-Value存储系统和为什么选择Key-Value Store