非关系型数据库：
#非关系型数据库的特性
1、使用键值对存储数据；
2、分布式；
3、一般不支持ACID特性；
4、非关系型数据库严格上不是一种数据库，应该是一种数据结构化存储方法的集合。
#非关系型数据库的优点
1、无需经过sql层的解析，读写性能很高；
2、基于键值对，数据没有耦合性，容易扩展；
3、存储数据的格式：nosql的存储格式是key,value形式、文档形式、图片形式等等，文档形式、图片形式等等，而关系型数据库则只支持基础类型。
#非关系型数据库的缺点
1、不提供sql支持，学习和使用成本较高；
2、无事务处理，附加功能bi和报表等支持也不好；
NoSql，MongoDb，redis
MongoDb:它的特点是高性能、易部署、易使用，存储数据非常方便。主要功能特性有：
*面向集合存储，易存储对象类型的数据。
*模式自由。
*支持动态查询。
*支持完全索引，包含内部对象。
*支持查询。
*支持复制和故障恢复。
*使用高效的二进制数据存储，包括大型对象（如视频等）。
*自动处理碎片，以支持云计算层次的扩展性。
*支持RUBY，PYTHON，JAVA，C++，PHP，C#等多种语言。
*文件存储格式为BSON（一种JSON的扩展）。
*可通过网络访问。
NoSql:1. 它们可以处理超大量的数据。
2. 它们运行在便宜的PC服务器集群上。
3. 它们击碎了性能瓶颈。
4. 没有过多的操作。
5. Bootstrap支持。
redis特点、优缺点
特点
1. 内存数据库，速度快，也可以持久化
2. key-value结构
3. 数据类型：String、list、set、sorted set、hash
4. 支持事务，数据的原子性，要么全做，要么全不做
5. 单线程
优点
1. 读写性能很好
2. 支持数据持久化，支持AOF和RDB方式的持久化
3. 支持主从复制，主机会自动将数据同步到从机，实习读写分离
4. 数据结构丰富，有：String、list、set、sorted set、hash
缺点
1. Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。
2. 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。
3. Redis的主从复制采用全量复制，复制过程中主机会fork出一个子进程对内存做一份快照，并将子进程的内存快照保存为文件发送给从机，这一过程需要确保主机有足够多的空余内存。若快照文件较大，对集群的服务能力会产生较大的影响，而且复制过程是在从机新加入集群或者从机和主机网络断开重连时都会进行，也就是网络波动都会造成主机和从机间的一次全量的数据复制，这对实际的系统运营造成了不小的麻烦。
4. Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。
Redis的性能
这是官方给出的数据：SET操作每秒钟 110000 次，GET操作每秒钟 81000 次。
实验中模拟了20个客户端对redis进行写操作。当数据库中的数据达到G数据级时，写速度会有明显的下降。
可能的原因: 1、redis需要将数据同步到磁盘，占用了大量的CPU和内存； 2、key数量增大，需要重新布局； 3、消息队列中还存在大量请求，致使请求阻塞。
Redis数据类型：
1String（字符串）
string 是 redis 最基本的类型，你可以理解成与 Memcached 一模一样的类型，一个 key 对应一个 value。
string 类型是二进制安全的。意思是 redis 的 string 可以包含任何数据。比如jpg图片或者序列化的对象。
string 类型是 Redis 最基本的数据类型，string 类型的值最大能存储 512MB。
2Hash（哈希）
Redis hash 是一个键值(key=>value)对集合。
Redis hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象。
3List（列表）
Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。
4Set（集合）
Redis 的 Set 是 string 类型的无序集合。
集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。
5zset(sorted set：有序集合)
Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。
不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。
zset的成员是唯一的,但分数(score)却可以重复。
持久化两种方式
RDB持久化： 在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储 。
AOF持久化： AOF 机制对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中，在 redis 重启的时候，可以通过回放 AOF 日志中的写入指令来重新构建整个数据集。
RDB和AOF如何选择？
不要仅仅使用 RDB，因为那样会导致你丢失很多数据；
也不要仅仅使用 AOF，因为那样有两个问题：第一，你通过 AOF 做冷备，没有 RDB 做冷备来的恢复速度更快；第二，RDB 每次简单粗暴生成数据快照，更加健壮，可以避免 AOF 这种复杂的备份和恢复机制的 bug；
redis 支持同时开启开启两种持久化方式，我们可以综合使用 AOF 和 RDB 两种持久化机制，用 AOF 来保证数据不丢失，作为数据恢复的第一选择; 用 RDB 来做不同程度的冷备，在 AOF 文件都丢失或损坏不可用的时候，还可以使用 RDB 来进行快速的数据恢复。
事务作用：串联多个命令防止别的命令插队
常用事务命令：Mutli EXEC DISCARD
cas:CAS是项乐观锁技术，当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。
乐观锁是一种思想。CAS是这种思想的一种实现方式。
watch作用：监控事务流程
主从复制好处：读写分离性能能拓展 容灾恢复快
解决扩容问题：在新的机器上创建实例，并且每个实例设置为被迁移实例的从机。
主从复制完成之后，设置程序将新的实例作为主。
停止旧的实例
经过如上步骤之后，旧机器的内存就变大了，最后内存最大为每台机器一个Redis实例。
主从模式衍生：上个slave是下一个slave的master,分摊写操作压力
主从复制down机后
方法一：手动 slaveof no one 在去slaveof hadoop 6380
方法二：哨兵机制 在第四台机器创建sentinel.conf 开启文件
选取slave转为master的选取机制是：
1选择优先级靠前
2数据最新
3选runid最小
7.哨兵作用：
1、监控
2、通知
3、自动故障转移 （1.投票决策master是否挂了，如果投票决策master挂了，2.则进一步决策选出执行故障转移的leader, 去执行故障转移）
4、充当client的授权和master查询服务
8.redis集群搭建流程：
创建cluster 至少需要六台机器，分别把六台redis.conf文件修改，添加cluster-enabled yes cluster-config-file nodes-7000~7005.conf cluster-node-timeout 15000
分别开启服务，redis-cli --cluster create 192.168.220.202:7000
192.168.220.202:7001 192.168.220.202:7002
192.168.220.202:7003 192.168.220.202:7004 192.168.220.202:7005 --replicas 1
redis-cli -c -p 7000~7005
cluster nodes
原文：https://www.cnblogs.com/meng310227/p/13392593.html