第一章 Redis 快速入门

1.1Key-Value 存储系统简介

1.2 为什么选择 Key-Value Store

1.3 初识 Redis

Redis 是一个 Key-Value 存储系统。和 Memcached 类似，它支持存储的 value 类型相对更多，包括 string(字符串)、list(链表)、set(集合)和 zset(有序集合)。这些数据类型都支持 push/pop、

1.1Key-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 数据库分为很多种类，具体如下图:

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

1.1.1 Voldemort

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

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

1.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.1.3 memcachedb

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

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

1.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.1.6 Hypertable

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

1.2 为什么选择 Key-Value Store

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

1.2.1 大规模的互联网应用

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

RDBMS 这种熟悉的技术，但缺点在于它是针对特定应用的，就是说，由于应用的不同，切割的方法是不一样的。

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

1.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 都不影响整个系统的运行；
高可靠性：容错、冗余等保证了数据库系统的可靠性。
1. 1. Redis 实际应用案例

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

在新浪微博 Redis 的部署场景很多，大概分为如下的 2 种: 第一种是应用程序直接访问 Redis 数据库

第二种是应用程序直接访问 Redis，只有当 Redis 访问失败时才访问 MySQL

同时，Digg 的一项新功能，添加了对文章浏览数的显示，这一功能的一大卖点是其实时性。

1.3 初识 Redis

Redis 是一个开源的使用 ANSI C 语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库，并提供多种语言的API。从2010 年3 月15 日起，Redis 的开发工作由VMware主持。

1.3.1 数据类型

作为 Key-value 型数据库，Redis 也提供了键（Key）和键值（Value）的映射关系。但是，除了常规的数值或字符串，Redis 的键值还可以是以下形式之一：

Lists （列表）
Sets （集合）
Sorted sets （有序集合）
Hashes （哈希表）

键值的数据类型决定了该键值支持的操作。Redis 支持诸如列表、集合或有序集合的交集、并集、查集等高级原子操作；同时，如果键值的类型是普通数字，Redis 则提供自增等原子操作。

1.3.2 持久化

通常，Redis 将数据存储于内存中，或被配置为使用虚拟内存。通过两种方式可以实现数据持久化：使用截图的方式，将内存中的数据不断写入磁盘；或使用类似 MySQL 的日志方式，记录每次更新的日志。前者性能较高，但是可能会引起一定程度的数据丢失；后者相反。

1.3.3 主从同步

Redis 支持将数据同步到多台从库上，这种特性对提高读取性能非常有益。

1.3.4 性能

相比需要依赖磁盘记录每个更新的数据库，基于内存的特性无疑给 Redis 带来了非常优秀的性能。读写操作之间有显著的性能差异。

1. 1. 提供 API 的语言
C
C++
C#
Clojure
Common Lisp
Erlang
Haskell
Java
Javascript
Lua
Objective-C
Perl
PHP
Python
Ruby
Scala
Go
Tcl

1.3.6 适用场合

毫无疑问，Redis 开创了一种新的数据存储思路，使用 Redis，我们不用在面对功能单调的数据库时，把精力放在如何把大象放进冰箱这样的问题上，而是利用 Redis 灵活多变的数据结构和数据操作，为不同的大象构建不同的冰箱。希望你喜欢这个比喻。

下面是 Redis 适用的一些场景:

1、取最新 N 个数据的操作

比如典型的取你网站的最新文章，通过下面方式，我们可以将最新的 5000 条评论的 ID 放在

Redis 的 List 集合中，并将超出集合部分从数据库获取。

使用 LPUSH latest.comments<ID>命令，向 list 集合中插入数据

插入完成后再用 LTRIM latest.comments 0 5000 命令使其永远只保存最近 5000 个 ID

然后我们在客户端获取某一页评论时可以用下面的逻辑

如果你还有不同的筛选维度，比如某个分类的最新 N 条，那么你可以再建一个按此分类的

List，只存 ID 的话，Redis 是非常高效的。

2、排行榜应用，取 TOP N 操作

这个需求与上面需求的不同之处在于，前面操作以时间为权重，这个是以某个条件为权重，比如按顶的次数排序，这时候就需要我们的 sorted set 出马了，将你要排序的值设置成 sorted

set 的 score，将具体的数据设置成相应的 value，每次只需要执行一条 ZADD 命令即可。

3、需要精准设定过期时间的应用

比如你可以把上面说到的 sorted set 的 score 值设置成过期时间的时间戳，那么就可以简单地通过过期时间排序，定时清除过期数据了，不仅是清除 Redis 中的过期数据，你完全可以把 Redis 里这个过期时间当成是对数据库中数据的索引，用 Redis 来找出哪些数据需要过期删除，然后再精准地从数据库中删除相应的记录。

4、计数器应用

Redis 的命令都是原子性的，你可以轻松地利用 INCR，DECR 命令来构建计数器系统。

5、Uniq 操作，获取某段时间所有数据排重值

这个使用 Redis 的 set 数据结构最合适了，只需要不断地将数据往 set 中扔就行了，set 意为集合，所以会自动排重。

6、实时系统，反垃圾系统

通过上面说到的 set 功能，你可以知道一个终端用户是否进行了某个操作，可以找到其操作的集合并进行分析统计对比等。没有做不到，只有想不到。

7、Pub/Sub 构建实时消息系统

Redis 的 Pub/Sub 系统可以构建实时的消息系统，比如很多用 Pub/Sub 构建的实时聊天系统的例子。

8、构建队列系统

使用 list 可以构建队列系统，使用 sorted set 甚至可以构建有优先级的队列系统。

9、缓存

这个不必说了，性能优于 Memcached，数据结构更多样化。

1.4 安装 Redis

1.4.1 安装Redis

Redis 的官方下载站是 http://redis.io/download，可以去上面下载最新的安装程序下来，我写此文章时的的稳定版本是 2.2

怎么安装 Redis 数据库呢？下面将介绍 Linux 版本的安装方法步骤一: 下载 Redis

下载安装包：wget http://redis.googlecode.com/files/redis-2.2.12.tar.gz

步骤二: 编译源程序

步骤三: 启动 Redis 服务

src/redis-server

Redis 服务端的默认连接端口是 6379

步骤四: 将 Redis 作为 Linux 服务随机启动

vi /etc/rc.local, 使用 vi 编辑器打开随机启动配置文件，并在其中加入下面一行代码

/root/4setup/redis-2.2.12/src/redis-server

步骤五: 客户端连接验证

新打开一个 Session 输入：src/redis-cli，如果出现下面提示，那么您就可以开始 Redis 之旅了

步骤六: 查看 Redis 日志

查看服务器端 session，即可对 Redis 的运行状况进行查看或分析了

以上的几个步骤就 OK 了！！这样一个简单的 Redis 数据库就可以畅通无阻地运行起来了。

步骤七: 停止 Redis 实例

最简单的方法是在启动实例的 session 中，直接使用 Control-C 来将实例停止。

1.4.2 配置 Redis

如果是一个专业的 DBA，那么实例启动时会加很多的参数以便使系统运行的非常稳定，这样就可能会在启动时在 Redis 后面加一个参数，以指定配置文件的路径，就象 mysql 一样的读取启动配置文件的方式来启动数据库。源码编译完成后，在 redis-2.2.12 目录下有一个

redis.conf 文件，这个文件即是 Redis 的配置文件，用配置文件来启动 Redis 的方法如下:

Redis 支持很多的参数，但都有默认值。

1.daemonize:

默认情况下，redis 不是在后台运行的，如果需要在后台运行，把该项的值更改为 yes

2.pidfie

当 Redis 在后台运行的时候，Redis 默认会把 pid 文件放在/var/run/redis.pid，你可以配置到其他地址。当运行多个 redis 服务时，需要指定不同的 pid 文件和端口

3.bind

指定 Redis 只接收来自于该 IP 地址的请求，如果不进行设置，那么将处理所有请求，在生产环境中最好设置该项

4.port

监听端口，默认为 6379

5.timeout

设置客户端连接时的超时时间，单位为秒。当客户端在这段时间内没有发出任何指令，那么关闭该连接

6.oglevel

log 等级分为 4 级，debug, verbose, notice, 和 warning。生产环境下一般开启 notice

7.ogfile

配置 log 文件地址，默认使用标准输出，即打印在命令行终端的窗口上

8.databases

设置数据库的个数，可以使用 SELECT <dbid>命令来切换数据库。默认使用的数据库是 0

9.save

设置 Redis 进行数据库镜像的频率。

if(在 60 秒之内有 10000 个 keys 发生变化时){ 进行镜像备份

}else if(在 300 秒之内有 10 个 keys 发生了变化){ 进行镜像备份

}else if(在 900 秒之内有 1 个 keys 发生了变化){ 进行镜像备份

}

10.rdbcompression

在进行镜像备份时，是否进行压缩

11.dbfiename

镜像备份文件的文件名

12.dir

数据库镜像备份的文件放置的路径。这里的路径跟文件名要分开配置是因为 Redis 在进行备份时，先会将当前数据库的状态写入到一个临时文件中，等备份完成时，再把该该临时文件替换为上面所指定的文件，而这里的临时文件和上面所配置的备份文件都会放在这个指定的路径当中

13.saveof

设置该数据库为其他数据库的从数据库

14.masterauth

当主数据库连接需要密码验证时，在这里指定

15.requirepass

设置客户端连接后进行任何其他指定前需要使用的密码。警告：因为 redis 速度相当快，所以在一台比较好的服务器下，一个外部的用户可以在一秒钟进行 150K 次的密码尝试，这意味着你需要指定非常非常强大的密码来防止暴力破解。

16.maxcients

限制同时连接的客户数量。当连接数超过这个值时，redis 将不再接收其他连接请求，客户端尝试连接时将收到 error 信息。

17.maxmemory

设置 redis 能够使用的最大内存。当内存满了的时候，如果还接收到 set 命令，redis 将先尝试剔除设置过 expire 信息的 key，而不管该 key 的过期时间还没有到达。在删除时，将按照过期时间进行删除，最早将要被过期的 key 将最先被删除。如果带有 expire 信息的 key 都删光了，那么将返回错误。这样，redis 将不再接收写请求，只接收 get 请求。maxmemory 的设置比较适合于把 redis 当作于类似 memcached 的缓存来使用。

18.appendony

默认情况下，redis 会在后台异步的把数据库镜像备份到磁盘，但是该备份是非常耗时的，而且备份也不能很频繁，如果发生诸如拉闸限电、拔插头等状况，那么将造成比较大范围的数据丢失。所以 redis 提供了另外一种更加高效的数据库备份及灾难恢复方式。开启 append only 模式之后， redis 会把所接收到的每一次写操作请求都追加到

appendonly.aof 文件中，当 redis 重新启动时，会从该文件恢复出之前的状态。但是这样会造成 appendonly.aof 文件过大，所以 redis 还支持了 BGREWRITEAOF 指令，对

appendonly.aof 进行重新整理。所以我认为推荐生产环境下的做法为关闭镜像，开启

appendonly.aof，同时可以选择在访问较少的时间每天对 appendonly.aof 进行重写一次。

19.appendfsync

设置对 appendonly.aof 文件进行同步的频率。always 表示每次有写操作都进行同步，

everysec 表示对写操作进行累积，每秒同步一次。这个需要根据实际业务场景进行配置

20.vm-enabed

是否开启虚拟内存支持。因为 redis 是一个内存数据库，而且当内存满的时候，无法接收新的写请求，所以在 redis 2.0 中，提供了虚拟内存的支持。但是需要注意的是，redis 中，所有的 key 都会放在内存中，在内存不够时，只会把 value 值放入交换区。这样保证了虽然使用虚拟内存，但性能基本不受影响，同时，你需要注意的是你要把vm-max-memory 设置到足够来放下你的所有的 key

21.vm-swap-fie

设置虚拟内存的交换文件路径

22.vm-max-memory

这里设置开启虚拟内存之后，redis 将使用的最大物理内存的大小。默认为 0，redis 将把他所有的能放到交换文件的都放到交换文件中，以尽量少的使用物理内存。在生产环境下，需要根据实际情况设置该值，最好不要使用默认的 0

23.vm-page-size

设置虚拟内存的页大小，如果你的 value 值比较大，比如说你要在 value 中放置博客、新闻之类的所有文章内容，就设大一点，如果要放置的都是很小的内容，那就设小一点。

24.vm-pages

设置交换文件的总的 page 数量，需要注意的是，page table 信息会放在物理内存中，每

8 个 page 就会占据 RAM 中的 1 个 byte。总的虚拟内存大小＝ vm-page-size * vm-pages

25.vm-max-threads

设置 VM IO 同时使用的线程数量。因为在进行内存交换时，对数据有编码和解码的过程，所以尽管 IO 设备在硬件上本上不能支持很多的并发读写，但是还是如果你所保存的 vlaue 值比较大，将该值设大一些，还是能够提升性能的

26.gueoutputbuf

把小的输出缓存放在一起，以便能够在一个 TCP packet 中为客户端发送多个响应，具体原理和真实效果我不是很清楚。所以根据注释，你不是很确定的时候就设置成 yes

27.hash-max-zipmap-entries

在 redis 2.0 中引入了 hash 数据结构。当 hash 中包含超过指定元素个数并且最大的元素没有超过临界时，hash 将以一种特殊的编码方式（大大减少内存使用）来存储，这里可以设置这两个临界值

28.activerehashing

开启之后，redis 将在每 100 毫秒时使用 1 毫秒的 CPU 时间来对 redis 的 hash 表进行重新 hash，可以降低内存的使用。当你的使用场景中，有非常严格的实时性需要，不能够接受 Redis 时不时的对请求有 2 毫秒的延迟的话，把这项配置为 no。如果没有这么严格的实时性要求，可以设置为 yes，以便能够尽可能快的释放内存

1.4.3 操作数据库

下面我们来简单的操作一下数据库。

插入数据

redis 127.0.0.1:6379> set name wwl

OK

设置一个 key-value 对

查询数据

redis 127.0.0.1:6379> get name

"wwl"

取出 key 所对应的 value

删除键值

redis 127.0.0.1:6379> del name

删除这个 key 及对应的 value

验证键是否存在

redis 127.0.0.1:6379> exists name

其中 0，代表此 key 不存在；1 代表存在