redis总结_c# redis fulshall-CSDN博客

本文链接：https://blog.csdn.net/liliping28/article/details/81012138

周阳老师讲的非常好

关于型数据库四大特性：ACIP

A(原子性)，C（一致性）I（隔离性）P（持久性）

CAP分布式存储系统中只能实现2点

CAP只能三选二

C(强一致)，A(高可用性),P(分区容错性)

redis,mongodb,hbase:CP, rdbms(关系型数据库)：CA

BASE:

基本可用，软状态，最终一致

分布式+集群

先了解负载均衡是指在多用户访问时，尽可能的平均分配到不同的机器上进行访问，提高效率。好比几个人打算耗羊毛，一共有10只羊不可能只可一只羊耗羊毛，应该每只羊耗一些羊毛。

分布式是指不同的服务器上部署不同的服务模块（工程），他们之间通过rpc/rmi通信和调度，对外提供服务和组内协作

集群是指不同的服务器上部署相同的服务模块，通过分布式的调度软件进行统一的调度，对外提供服务和访问

redis是一份远程字段数据库。可以用来做缓存,可以将一些不易变冷数据放到redis下

redis的3个优点：

1.支持数据的持久化，可以将内存中的数据保存到磁盘中，重启的时候可以再次加载进行使用

2.不仅仅支持key-value，同时还支持list,set,zset,hash等数据结构进行存储

3.redis支持数据的备份，即master-slave模式的数据备份

redis默认端口6379

redis常用的5大基本类型：

string（字符串）

list(列表)

hash(类似java里的map)

set（集合）

zset(sort set)（有序的集合）
redis.config文件

https://www.cnblogs.com/kreo/p/4423362.html

http://redisdoc.com/

https://www.jianshu.com/p/797099257c30

守护进程：有人来我就干活，没人来了我就休息。不用再后台一直运行

redis持久化：RDB(rdb)和AOF(aof)

1.RDB:是指在时间段内将内存中的数据集快照（区块数据）写入到磁盘。反之可以snapshot快照，它恢复时是将快照文件读到内存里。

为什么可以写入到磁盘：

redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件，等到持久化进程结束了，再用这个临时文件替换上次的持久化文件。整个过程中主进程不进行任何的io操作，这就确保了极高的性能。如果需要进行大规模的数据恢复，并且对数据的完整性要求不是非常敏感（完整）的话，那RDB方式比AOF方式更加的高效。RDB的缺点最后一次进行数据持久化可能会丢失。

FORK是指复制一个和当前进程一样的进程。新进程的所有数据（变量，环境变量，程序计数器等）数值和原来进程一样，但是是一个全新的进程，此进程作为原来进程的子进程。

RDB保存的是dump.rdb文件。

shutdown或者fulshall命令会生产新的dump.rdb文件。save和bgsave命令会手动备份数据，会生产最新的dump.rdb文件.save是同步的，当保存时其他数据是无法写入的，bgsave是异步的，当保存时其他数据是可以写入的

优势：1.适合大规模数据的恢复 2.对数据的完整性和一致性不高

劣势：1.如果redis意外down的话，对最后一次的数据的快照容易丢失 2.fork时候，内存中的数据被克隆了一份。大致2倍的膨胀性需要考虑内存空间

如果丢包，或者异常关闭导致数据格式不正确。恢复指令是redis-check-dump --fix dump.rdb 这个会把不符合语法的指令全部去掉

AOF:是指以日志的形式记录每次写的操作，将Redis执行过的所有写指令记录来下来（读操作不记录）。只允许追加文件但不可以改写文件，redis重启之初会读取该文件重新构建数据。换言之，redis重启时会根据日志文件的内容指令从前往后执行一次以完成的数据恢复工作。

如果appendonly.aof和dump.rdb是可以共存的，如果同时存在的话，先加载appendonly.aof文件。

如果丢包，或者异常关闭导致数据格式不正确。恢复指令是redis-check-aof --fix appendonly.aof.这个会把不符合语法的指令全部去掉

AOF下的Rewrite:AOF采用文件的不断追加，文件会越来越大，为避免出现这种情况，新增了重写机制。当AOF文件的大小超过了设定的阈值时，Redis就会启动AOF文件的内容压缩。只保留可以恢复数据的最小指令集，可以使用bgrewrirteaof.

重写原理：AOF的文件持续增长而过大时，会fork出现一条新的进程将文件重写（也是先临时写一个文件最后在rename）。遍历新进程的内存中数据，每记录有一条set的语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据内容用命令的方式重写了一个新的aof文件，这点和快照类似。

触发机制：Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

优势：方式灵活多变，1.同步立刻记录 2.异步每秒记录一次 3.不记录

劣势：1.相同的数据集aof大于rdb,恢复速度慢于rdb

2.aof的运行效率慢于rdb，每秒的同步策略效率较好，不同于效率和rdb一样

建议两种持久化方式同时开启:

aof和rdb同时存在时会优选载入aof文件来恢复原始的数据。当rdb的数据不实时，同时使用两者重启服务器时，只会找aof文件。

那要不要只用aof呢？

作者建议不要，因为rdb更适用于数据的备份（aof在不断变化不好备份）。可以留作一个手段以做万一。

redis的事务是指在开启事务时，所有的执行命令加入到队列当中，当执行事务时会将命令统一执行。

multi事务开启,总会返回ok，但是并不表示一定会开启事务。除非及特殊情况是开启不了的，服务器关了等

exec（执行事务内的所有命令）执行事务，

discard（取消事务内的所有命令）取消事务，

unwatch取消wathc监视的所有key,

watch（监控）：监视一个或者多个key,如果在事务执行之前这个或者这些key被其他命令所改动，那么事务将会被打断

redis的事务的规则：

1.事务开启

2.事务执行

3.有时全部命令执行：有时指的是在当事务内的命令语法不对（编译期间）提交到队列当中，会立即返回错误语法信息给用户。当用户想提交队列中的所有命令时，就会返回全部执行失败的提示。例如：事务中的命令是 setget k1 a（乱写的命令）,这时提交到队列当中，会立即返回错误给用户。当用户执行事务的所有命令，就会所有命令执行失败

4.有时错误的命令不执行，其他的执行。有时指的是在当事务内的命令正确，但是如果在运行时产生的错误，当用户想提交队列中的所有命令时，其他命令可以执行，运行时产生的错误命令执行失败。例如：用户提交命令set k1 1,事务中的命令是 icn k1 a（icn自动相加命令）,这时运行该条的事务命令就会产生错误，因为int和string无法相加.

redis的事务特性：

1.单独的隔离操作

2.没有隔离级别概念

3.不保证原子性

redis消息的发布订阅：在企业开发不经常用，因为redis主要是做高速缓存的，MQ是java的消息中间件比redis要好

redis的主从复制（master/alaver）：主机更新数据根据配置和策略，自动的同步到备用机器上master/alaver机制，master以写为主，从机以读为主

能干什么呢？

info replication查看库的主从信息详情的命令

1.读写分离

2.容灾恢复

怎么玩呢？

1.配从不配主