华为，阿里资深工程师带你 走进nosql之redis

1. Nosql 历史

随着大数据时代的到来，越来越多的网站、应用系统需要支撑海量数据存储，高并发请求、高可用、高可扩展性等特性要求，传统的关系型数据库在应付这些调整已经显得力不从心，暴露了许多能以克服的问题。由此，各种各样的NoSQL（Not Only SQL）数据库作为传统关系型数据的一个有力补充得到迅猛发展。
本文将分析传统数据库的存在的相关问题，以及几大类NoSQL如何解决这些问题，希望给大家提供在不同业务场景下，关于存储方面技术选型提供参考。
2. 传统数据库缺点
· 大数据场景下I/O较高
因为数据是按行存储，即使只针对其中某一列进行运算，关系型数据库也会将整行数据从存储设备中读入内存，导致I/O较高
· 存储的是行记录，无法存储数据结构
· 表结构schema扩展不方便
如要需要修改表结构，需要执行执行DDL(data definition language)，语句修改，修改期间会导致锁表，部分服务不可用
· 全文搜索功能较弱
关系型数据库下只能够进行子字符串的匹配查询，当表的数据逐渐变大的时候，like查询的匹配会非常慢，即使在有索引的情况下。况且关系型数据库也不应该对文本字段进行索引
· 存储和处理复杂关系型数据功能较弱
许多应用程序需要了解和导航高度连接数据之间的关系，才能启用社交应用程序、推荐引擎、欺诈检测、知识图谱、生命科学和 IT/网络等用例。然而传统的关系数据库并不善于处理数据点之间的关系。它们的表格数据模型和严格的模式使它们很难添加新的或不同种类的关联信息。

3. K-V数据库
   指的是使用键值(key-value)存储的数据库，其数据按照键值对的形式进行组织、索引和存储。KV 存储非常适合不涉及过多数据关系业务关系的数据，同时能有效减少读写磁盘的次数，比 SQL 数据库存储拥有更好的读写性能，能够解决关系型数据库无法存储数据结构的问题。
   3.1. 常见 K-V数据库
   3.1.1. REDIS

Redis是一个使用ANSI C编写的开源、支持网络、基于内存、可选持久性的键值对存储数据库。从2015年6月开始，Redis的开发由Redis Labs赞助，而2013年5月至2015年6月期间，其开发由Pivotal赞助。在2013年5月之前，其开发由VMware赞助。根据月度排行网站http://DB-Engines.com的数据显示，Redis是最流行的键值对存储数据库。
官网：http://redis.io/
3.1.2. CASSANDRA

Apache Cassandra（社区内一般简称为C*）是一套开源分布式NoSQL数据库系统。它最初由Facebook开发，用于储存收件箱等简单格式数据，集Google BigTable的数据模型与Amazon Dynamo的完全分布式架构于一身。Facebook于2008将 Cassandra 开源，此后，由于Cassandra良好的可扩展性和性能，被 Apple, Comcast,Instagram, Spotify, eBay, Rackspace, Netflix等知名网站所采用，成为了一种流行的分布式结构化数据存储方案。
官网：http://cassandra.apache.org/
3.1.3. LEVELDB

Leveldb 是 Google 开发的一个非常高效的 kv 数据库，支持 billion 级别的数据量，在这个数量级别下还有着非常高的性能，主要归功于它的良好的设计，特别是 LSM 算法。Leveldb 已经作为存储引擎被 Riak 和 Kyoto Tycoon 所支持，在国内淘宝的 Tair 开源 key-value 存储也已经将 LevelDB 作为其持久化存储引擎，并部署在线上使用。
官网：http://code.google.com/p/leveldb/
3.1.4. BERKELEY DB

Berkeley DB 是一个开源的文件数据库，介于关系数据库与内存数据库之间，使用方式与内存数据库类似，它提供的是一系列直接访问数据库的函数，而不是像关系数据库那样需要网络通讯、SQL 解析等步骤。
官网：http://www.oracle.com/technetwork/products/berkeleydb/overview/index.html
4. 文档数据库
文档数据库（也称为文档型数据库）是旨在将半结构化数据存储为文档的一种数据库。文档数据库通常以 JSON 或 XML 格式存储数据。
由于文档数据库的no-schema特性，可以存储和读取任意数据。
由于使用的数据格式是JSON或者BSON，因为JSON数据是自描述的，无需在使用前定义字段，读取一个JSON中不存在的字段也不会导致SQL那样的语法错误，可以解决关系型数据库表结构schema扩展不方便的问题
4.1. 常见文档数据库
4.1.1. MONGODB

MongoDB是一种面向文档的数据库管理系统，由C++撰写而成，以此来解决应用程序开发社区中的大量现实问题。2007年10月，MongoDB由10gen团队所发展。2009年2月首度推出。
官网：https://www.mongodb.com/
4.1.2. COUCHDB

Apache CouchDB是一个开源数据库，专注于易用性和成为"完全拥抱web的数据库"。它是一个使用JSON作为存储格式，JavaScript作为查询语言，MapReduce和HTTP作为API的NoSQL数据库。其中一个显著的功能就是多主复制。CouchDB的第一个版本发布在2005年，在2008年成为了Apache的项目。
官网：http://couchdb.apache.org/
5. 图形数据库
图形数据库应用图形理论存储实体之间的关系信息。最常见例子就是社会网络中人与人之间的关系。关系型数据库用于存储“关系型”数据的效果并不好，其查询复杂、缓慢、超出预期，而图形数据库的独特设计恰恰弥补了这个缺陷，解决关系型数据库存储和处理复杂关系型数据功能较弱的问题。
5.1. 常见图形数据库
5.1.1. NEO4J

Neo4j是由Neo4j，Inc。开发的图形数据库管理系统。由其开发人员描述为具有原生图存储和处理的符合ACID的事务数据库，根据DB-Engines排名， Neo4j是最流行的图形数据库。
官网：https://neo4j.com/
5.1.2. ARANGODB

ArangoDB是由triAGENS GmbH开发的原生多模型数据库系统。数据库系统支持三个重要的数据模型（键/值，文档，图形），其中包含一个数据库核心和统一查询语言AQL（ArangoDB查询语言）。查询语言是声明性的，允许在单个查询中组合不同的数据访问模式。ArangoDB是一个NoSQL数据库系统，但AQL在很多方面与SQL类似。
官网：https://www.arangodb.com/
5.1.3. TITAN

Titan是一个可扩展的图形数据库，针对存储和查询包含分布在多机群集中的数百亿个顶点和边缘的图形进行了优化。Titan是一个事务性数据库，可以支持数千个并发用户实时执行复杂的图形遍历。
官网：http://titan.thinkaurelius.com/
5.1.4. ORIENTDB

OrientDB是兼具文档数据库的灵活性和图形数据库管理链接能力的可深层次扩展的文档-图形数据库管理系统。可选无模式、全模式或混合模式下。支持许 多高级特性，诸如ACID事务、快速索引，原生和SQL查询功能。可以JSON格式导入、导出文档。若不执行昂贵的JOIN操作的话，如同关系数据库可在几毫秒内可检索数以百记的链接文档图。
官网：https://orientdb.com/
6. 时序数据库
时序数据库全称为时间序列数据库。时间序列数据库主要用于指处理带时间标签（按照时间的顺序变化，即时间序列化）的数据，带时间标签的数据也称为时间序列数据。
时间序列数据主要由电力行业、化工行业等各类型实时监测、检查与分析设备所采集、产生的数据，这些工业数据的典型特点是：产生频率快（每一个监测点一秒钟内可产生多条数据）、严重依赖于采集时间（每一条数据均要求对应唯一的时间）、测点多信息量大（常规的实时监测系统均有成千上万的监测点，监测点每秒钟都产生数据，每天产生几十GB的数据量）。
6.1. 常见时序数据库
6.1.1. InfluxDB

InfluxDB 由 Golang 语言编写，也是由 Golang 编写的软件中比较著名的一个，在很多 Golang 的沙龙或者文章中可能都会把 InfluxDB 当标杆来介绍，这也间接帮助 InfluxDB 提高了知名度。
官网：https://www.influxdata.com/
6.1.2. RRDtool
RRDtool is the OpenSource industry standard, high performance data logging and graphing system for time series data. RRDtool can be easily integrated in shell scripts, perl, python, ruby, lua or tcl applications.
官网：https://oss.oetiker.ch/rrdtool/
6.1.3. OPENTSDB
基于Hbase的分布式的，可伸缩的时间序列数据库。
主要用途，就是做监控系统；譬如收集大规模集群（包括网络设备、操作系统、应用程序）的监控数据并进行存储，查询。
官网：http://opentsdb.net/
6.1.4. 数据结构与对象

6.1.5. 简单动态字符串
源文件
简单动态字符串对应的源文件sds.h/sds.c
特点

API

6.1.6. 链表
6.1.6.1. 源文件
链表对应的源文件adlist.h/adlist.c
6.1.6.2. 特点

7. Redis简单介绍
   7.1. C/S模式
   Redis-cli.c客户端
   Redis-server.c 服务器
   配置文件对应的数据结构

static struct config {
char *hostip;
int hostport;
char *hostsocket;
long repeat;
long interval;
int dbnum;
int interactive;
int shutdown;
int monitor_mode;
int pubsub_mode;
int latency_mode;
int latency_dist_mode;
int latency_history;
int lru_test_mode;
long long lru_test_sample_size;
int cluster_mode; int cluster_reissue_command;
int slave_mode;
int pipe_mode;
int pipe_timeout;
int getrdb_mode;
int stat_mode;
int scan_mode;
int intrinsic_latency_mode;
int intrinsic_latency_duration;
char pattern; char rdb_filename;
int bigkeys;
int memkeys;
unsigned memkeys_samples;
int hotkeys;
int stdinarg; / get last arg from stdin. (-x option) / char auth;
int output; / output mode, see OUTPUT_ defines /
sds mb_delim;
char prompt[128];
char eval;
int eval_ldb;
int eval_ldb_sync;
/ Ask for synchronous mode of the Lua debugger./
int eval_ldb_end;
/ Lua debugging session ended. /
int enable_ldb_on_eval;
/ Handle manual SCRIPT DEBUG + EVAL commands. */
int last_cmd_type;
int verbose;
clusterManagerCommand cluster_manager_command;
int no_auth_warning;
} config;

7.2. Redis基本命令
http://doc.redisfans.com/index.html
源代码过长：想要获取代码，可以私信我关键字+【资料】获取，文章已经整理PDF文档

7.3. Redis客户端支持
https://redis.io/clients#c

7.4. Redis 通信协议
Redis客户端使用名为RESP（Redis序列化协议）的协议与Redis服务器进行通信。 虽然该协议是专为Redis设计的，但它可以用于其他CS软件项目的通讯协议。
RESP是以下几方面的考虑：
l 易于实现
l 快速解析
l 可读性高
RESP可以序列化不同的数据类型，如整型，字符串，数组。 还有一种特定的错误类型。 请求将要执行的命令作为字符串数组从Redis客户端发送到Redis服务器。Redis使用特定数据类型的命令进行回复。
RESP是二进制安全的，不需要处理从一个进程传输到另一个进程的批量数据，因为它使用前缀长度来传输批量数据。
注意：此处概述的协议仅用于客户端 - 服务器通信。 Redis Cluster使用不同的二进制协议，以便在节点之间交换消息。

7.5. Redis内部实现框架

因文章过长，已整理为PDF文档，想要获取资料的可以找我获取；