1.CAP定理

指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），最多只能同时三个特性中的两个，三者不可兼得。
CAP是所有分布式数据库的设计标准。例如Zookeeper、Redis、HBase等的设计都是基于CAP理论的。

image.png

Zookeeper
保证CP。当主节点故障的时候，Zookeeper会重新选主。此时Zookeeper是不可用的，需要等待选主结束才能重新提供注册服务。显然，Zookeeper在节点故障的时候，并没有满足可用性的特性。在网络情况复杂的生产环境下，这样的情况出现的概率也是有的。一旦出现，如果依赖Zookeeper的部分会卡顿，在大型系统上，很容易引起系统的雪崩。这也是大型项目不选Zookeeper当注册中心的原因。
Eureka
保证AP。在Eureka中，各个节点是平等的，它们相互注册。挂掉几个节点依然可以提供注册服务的（可以配置成挂掉的比例），如果连接的Eureka发现不可用，会自动切换到其他可用的几点上。另外，当一个服务尝试连接Eureka发现不可用的时候，切换到另外一个Eureka服务上，有可能由于故障节点未来得及同步最新配置，所以这个服务读取的数据可能不是最新的。所以当不要求强一致性的情况下，Eureka作为注册中心更为可靠。
Git
其实Git也是也是分布式数据库。它保证的是CP。很容易猜想到，云端的Git仓库于本地仓库必定是要保证数据的一致性的，如果不一致会先让数据一致再工作。当你修改完本地代码，想push代码到Git仓库上时，假如云端的HEAD与本地的HEAD不一致的时候，会先同步云端的HEAD到本地HEAD，再把本地的HEAD同步到云端。最终保证数据的一致性。

redis 键值对
mongoDb 文档

2.Redis的数据结构类型

1.字符串（String） 2.Hash 3 列表（List） 4 集合（Set） 5有序集合

3.Redis多机版

3.1复制

扩展系统对读的能力。（写用主库读用从库）

image.png

特点：

       1.master/slave角色
       2.master/slave数据相同
       3.降低了master读的压力。将读转交给从库。从库负责读取。

问题：（1）无法保证高可用（因为主服务器还属于单点）

（2）没有解决master写的操作。

3.2哨兵（sentinel）

为服务器提供高可用特性，减少故障停机的出现。

image.png

特点：

1.保证高可用
2.监控各个节点
3.自动故障迁移

缺点：
主从模式，切换需要时间，丢数据。
没有解决master写的压力

一主二从三哨兵：

image.png

参考博文：https://my.oschina.net/wangxu3655/blog/2214310?nocache=1538114138145

3.3 集群（proxy）

扩展内存容量，增加机器，提高性能读写能力和存储以及提供高可用特性

image.png

3.4 集群（直连型）

image.png

Redis Cluster包含了16384个哈希槽（solt），每个Key通过CRC16算法计算后都会落在具体一个槽位上，而这个槽位是属于哪个存储节点的，则由用户自己定义分配。例如机器硬盘小的，可以分配少一点槽位，硬盘大的可以分配多一点。如果节点硬盘都差不多则可以平均分配。所以哈希槽这种概念很好地解决了一致性哈希的弊端。

https://mp.weixin.qq.com/s/Gaf2NAbY3K0ZdEeJzAUIUA

4.常用命令：

见有道云笔记：这里不再重复

5.Redis持久化

redis持久化有两种方式：

5.1 RDB：

RDB全称叫做RedisDataBase

RDB功能核心函数rdbSave(生成RDB文件)和rdbLoad（从文件加载内存）两个函数

image.png

5.1.1rdbSave函数:

将内存中的数据库数据以 RDB 格式保存到磁盘（文件）中，文件存在,那么新的 RDB 文件将替换已有的 RDB 文件。

SAVE 和 BGSAVE 两个命令是操作 rdbSave函数的区别：
(1)SAVE命令 直接调用 rdbSave ，阻塞 Redis 主进程，直到保存完成为止。在主进程阻塞期间，服务器不能处理客户端的任何请求。
(2)BGSAVE 命令则 fork 出一个子进程，子进程负责调用 rdbSave ，并在保存完成之后向主进程发送信号，通知保存已完成。因为 rdbSave 在子进程被调用，所以 Redis 服务器在 BGSAVE 执行期间仍然可以继续处理客户端的请求。

AOF(redis默认不开启)

image.png

AOF 文件的保存频率通常要高于 RDB 文件保存的频率， 所以一般来说， AOF 文件中的数据会比 RDB 文件中的数据要新。因此， 如果服务器在启动时， 打开了 AOF 功能， 那么程序优先使用 AOF 文件来还原数据。 只有在 AOF 功能未打开的情况下， Redis 才会使用 RDB 文件来还原数据。

总结：Redis 默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。
RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。
Redis 需要手动开启AOF持久化方式，默认是每秒将写操作日志追加到AOF文件中。
AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。
Redis 针对 AOF文件大的问题，提供重写的瘦身机制。
若只打算用Redis 做缓存，可以关闭持久化。
若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份，留一后手。AOF出问题了，还有RDB。

参考文档：https://zackku.com/redis-rdb-aof/

参考文档：

NoSql之redis演变过程.pdf