1、Redis（常用数据类型、概念、RDB和AOF、集群）；

NoSQL，泛指非关系型的数据库，NoSQL即Not-Only SQL，它可以作为关系型数据库的良好补充。

1. string
2. hash (map)
3. list (linkedlist)
4. set (无序唯一)
5. zset (sorted set 有序set)

jedis对redis 相当于 jdbc对关系型数据库

Redis是一种高级key-value数据库。它跟memcached类似，不过数据可以持久化，而且支持的数据类型很丰富。有字符串，链表，集 合和有序集合。为了保证它的效率，会将数据缓存在内存中，但是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，以保证数据的持久化。以免在断电关机时数据丢失。

Redis持久化

Redis的高性能是由于其将所有数据都存储在了内存中，为了使Redis在重启之后仍能保证数据不丢失，需要将数据从内存中同步到硬盘中，这一过程就是持久化。Redis支持两种方式的持久化（RDB和AOF），可以同时使用。

Redis提供的持久化方式有两种：

rdb:快照形式是直接把内存中的数据保存到一个dump文件中，定时保存。

默认情况下，是rdb的持久化方式，将内存中的数据以快照的方式写入二进制文件中，默认的文件名是dump.rdb。

配置文件默认的策略，他们之间的关系是或，每隔900秒，在这期间变化了至少一个键值，做快照。或者每三百秒，变化了十个键值做快照。或者每六十秒，变化了至少一万个键值，做快照。

当然，也可以手动的使用save和bgSave来完成保存。

save 900 1 当15分钟之内有1个key发生变化就拍照

save 300 10 当300秒之内有10个key发生变化就拍照

save 60 10000 当60秒之内有1w个key发生变化就拍照

aof：把所有的对redis的服务器进行修改的命令都存到一个文件里，保存命令的集合。

配置文件中的appendonly修改为yes。开启AOF持久化后，执行的每一条指令，都会write到appendonly.aof文件中。但事实上，并不会立即将命令写入到硬盘文件中，而是写入到硬盘缓存，然后可以通过配置文件配置多久来从硬盘缓存写入到硬盘文件。重启服务器后,默认是从rdb文件中恢复数据到内存中

这里是配置文件中AOF持久化的配置。redis默认使用everysec，就是说每秒持久化一次，而always则是每次操作都会立即写入aof文件中。而no则是不主动进行同步操作，是默认30s一次。always一定是效率最低的，一般everysec就够用了，数据安全性能又高。

RDB的优势

1). 一旦用rdb方式，那么整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，可以非常容易的进行恢复。

2). 对于灾难恢复而言，RDB是非常不错的选择。因为可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。

3). 性能最大化。RDB分为了save和bgsave，save是主线程保存，这段时间会阻塞，服务会不可用不推荐使用。bgsave会fork子进程来保存，不会阻塞服务。

4). 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

RDB的劣势

1). 如果想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

2). 保存过程中，如果当数据集较大时，会导致磁盘IO压力大。

3).每次保存完整的数据到临时空间，保存完毕后，替换掉原来的备份。

AOF的优势

1). 可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，每秒同步、每修改同步和不同步。每秒同步也是异步完成的，效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。这种方式在效率上是最低的。

2). 由于机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。

3). 如果日志过大，Redis可以自动启用rewrite机制。Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。

4). AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。也可以通过该文件完成数据的重建。

5).持久化时，父进程会收集这段时间执行的命令，fork一个子进程来保存过去所有的命令，然后子进程保存完成后再把父进程这段时间保存的命令加进去一起保存起来。

AOF的劣势

1). 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB在恢复大数据集时的速度比AOF的恢复速度要快。

2). 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。

bgrewriteaof、bgsave，重写 aof 文件及备份 RDB 文件时，会 fork 出子进程和内存，此期间是阻塞的，取决于 Redis 内存大小和机器性能。所以许多企业的做法是主节点上关闭 aof 和 rdb，只在从节点上备份。