Redis 概述与例子

1. 概述

REmote DIctionary Server(Redis) 是一个由Salvatore Sanfilippo写的key-value存储系统。

Redis是一个开源的使用ANSI C语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

它通常被称为数据结构服务器，因为值（value）可以是 字符串(String), 哈希(Map), 列表(list), 集合(sets) 和 有序集合(sorted sets)等类型。

一般 MySql 使用 Query Cache，每次表的更新 Cache 就会失效，是一种大粒度的 Cache，而 NoSql(Not Only Sql) 数据库的 Cache 是记录级的，是一种细粒度的 Cache，所以 NoSql 数据库在这个层面上来说性能高很多。

1.1. BCD 协议

BSD开源协议是一个给于使用者很大自由的协议。可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。当你发布使用了BSD协议的代码，或者以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：

• 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
• 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
• 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。

BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销 售，因此是对商业集成很友好的协议。

很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。

1.2. RDBMS 与 NOSQL

RDBMS 特点：

• 高度组织化结构化数据
• 结构化查询语言（SQL）
• 数据和关系都存储在单独的表中
• 数据操纵语言，数据定义语言
• 严格的一致性
• 基础事务

NoSQL 特点：

• 代表不仅仅是 SQL
• 没有声明性查询语言
• 没有预定义的模式
• 键值对存储、列存储、文档存储、图形数据库
• 最终一致性，而非 ACID 属性
• 非结构化和不可预知的数据
• CAP 定理
• 高性能，高可用性和可伸缩性

1.3. 传统 ACID

1.3.1. A(Atomicity) 原子性

原子性即事务里所有的操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。比如银行转账，从 A 转 1000 元到 B，分为两个步骤：从 A 取 1000，存入1000 到 B，这两步要么一起完成，要么一起失败，如果只完成第一步，A 会莫名少1000元。

1.3.2. C(Consistency) 一致性

一致性是指事务使得系统从一个一致的状态转换到另一个一致状态。事务的一致性决定了一个系统设计和实现的复杂度。事务可以不同程度的一致性：

强一致性：读操作可以立即读到提交的更新操作。

弱一致性：提交的更新操作，不一定立即会被读操作读到，此种情况会存在一个不一致窗口，指的是读操作可以读到最新值的一段时间。

最终一致性：是弱一致性的特例。事务更新一份数据，最终一致性保证在没有其他事务更新同样的值的话，最终所有的事务都会读到之前事务更新的最新值。如果没有错误发生，不一致窗口的大小依赖于：通信延迟，系统负载等。

其他一致性变体还有：

单调一致性：如果一个进程已经读到一个值，那么后续不会读到更早的值。

会话一致性：保证客户端和服务器交互的会话过程中，读操作可以读到更新操作后的最新值。

1.3.3. I(Isolation) 独立性

并发事务之间互相影响的程度，比如一个事务会不会读取到另一个未提交的事务修改的数据。在事务并发操作时，可能出现的问题有：

脏读：事务A修改了一个数据，但未提交，事务B读到了事务A未提交的更新结果，如果事务A提交失败，事务B读到的就是脏数据。

不可重复读：在同一个事务中，对于同一份数据读取到的结果不一致。比如，事务B在事务A提交前读到的结果，和提交后读到的结果可能不同。不可重复读出现的原因就是事务并发修改记录，要避免这种情况，最简单的方法就是对要修改的记录加锁，这回导致锁竞争加剧，影响性能。另一种方法是通过MVCC可以在无锁的情况下，避免不可重复读。

幻读：在同一个事务中，同一个查询多次返回的结果不一致。事务A新增了一条记录，事务B在事务A提交前后各执行了一次查询操作，发现后一次比前一次多了一条记录。幻读是由于并发事务增加记录导致的，这个不能像不可重复读通过记录加锁解决，因为对于新增的记录根本无法加锁。需要将事务串行化，才能避免幻读。

事务的隔离级别从低到高有：

Read Uncommitted：最低的隔离级别，什么都不需要做，一个事务可以读到另一个事务未提交的结果。所有的并发事务问题都会发生。

Read Committed：只有在事务提交后，其更新结果才会被其他事务看见。可以解决脏读问题。
Repeated Read：在一个事务中，对于同一份数据的读取结果总是相同的，无论是否有其他事务对这份数据进行操作，以及这个事务是否提交。可以解决脏读、不可重复读。
Serialization：事务串行化执行，隔离级别最高，牺牲了系统的并发性。可以解决并发事务的所有问题。

1.3.4. D(Durability) 持久性

事务提交后，对系统的影响是永久的。

1.4. NoSQL 数据库的 CAP

CAP 理论核心：一个分布式系统不可能同时很好的满足一致性（Consistency），可用性（Availability) 和分区容错性（Tolerance of network Partition），最多只能同时较好的满足两个。

因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三大类：

• CA：单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
• CP：满足一致性，分区容忍性的系统，通常性能不是特别高。
• AP：满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。

1.5. NoSQL 数据库的 BASE

BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。

BASE其实是下面三个术语的缩写：

BASE是NoSQL数据库通常对可用性及一致性的弱要求原则:

• 基本可用（Basically Available）：基本可用
• 软状态（Soft state）：软状态/柔性事务。 “Soft state” 可以理解为”无连接”的, 而 “Hard state” 是”面向连接”的
• 最终一致（Eventually consistent）：最终一致性， 也是是 ACID 的最终目的。

2. HelloWorld 例子

2.1. 安装

Ubuntu 下安装

在 Ubuntu 系统安装 Redis 可以使用以下命令:

$sudo apt-get update
$sudo apt-get install redis-server

启动 Redis

$ redis-server

查看 redis 是否启动？

$ redis-cli

以上命令将打开以下终端：

redis 127.0.0.1:6379>

127.0.0.1 是本机 IP ，6379 是 redis 服务端口。现在我们输入 PING 命令。

redis 127.0.0.1:6379> ping
PONG

以上说明我们已经成功安装了redis。

这样安装的 redis 程序会在 /usr/bin 目录下

2.2. 备份出厂文件

进入 redis.conf 目录

$ cd /etc/redis

通过 ls -l 可以看到

创建备份目录

$ mkdir myredis

复制出厂文件

cp redis.conf myredis/redis.conf

2.3. 启动

通过 ps -ef | grep redis 命令可以看到

此时没有 redis 服务启动。

通过备份后的配置文件启动

$ redis-server myredis/redis.conf

使用 redis 命令行工具

$ redis-cli -p 6379

测试

通过 shutdown 和 exit 关闭

一次我在安装redis后遇到过这样的情况

即我在拷贝好redis.conf之后启动了redis-server，通过 ps -ef | grep redis查看redis进程，发现有两个redis进程，我最开始没在意，后面发现无法远程连接6379端口，再仔细一看，发现第一个进程是 redis 自身启动的，而我再次启动发现并不会造成什么冲突，我 kill 一个进程之后，问题就解决了。

解决了这个问题之后我再次实验，多次启动 redis-server，也不能造成这个样子了。