redis原理总结

作为很常用的缓存工具，一个合格的码农应该对redis的使用以及redis一些底层原理及概念上的一些认知有自己的认识。今天就说下自己对redis理解，我会尽量简洁以及一改我以往不仅陈述事实还解释原因的风格。

下面我也打算从这几个方面入手：

1. redis持久化
2. redis主从复制
3. redis分区
4. redis集群
5. redis事务
6. redis实现分布式锁

1，redis持久化

在redis持久化中有两种持久化方式：RDB和AOF。redis默认是不开启持久化的，但是RDB格式是redis主从同步的信息传输内容，redis在2.4版本后，可以在不开启RDB持久化的同时能够进行主从同步。这里主要介绍RDB和AOF的主要优缺点对比：

1，RDB是一个非常紧凑的文件，而AOF则是一条命令一条命令的格式通过AOF文件会比较大，当然，它会有重写功能。

2，RDB在恢复数据时速度比AOF快，但是AOF的持久化性能比RDB好，RDB每一次的生成，需要后台开启一个进程去将redis内存数据生成一个rdb文件，当数据很多时会很耗时，所以RDB持久化开启后会设置多长时间内redis接受命令达到一个什么样的量级后才会生成一次RDB文件，这样当出现宕机情况，会导致比较大的数据丢失。AOF（append only file）从名字就可以看出来，只是在文件末尾加上刚接受的命令，通常有1秒内持久化一次，每接收一次命令持久化一次，利用操作系统自己持久化。

2，redis主从复制

这里也简单介绍下redis主从同步原理。redis会开启后台进程进行同步所以不会阻塞对外提供的服务，redis主从同步目前不支持同步复制策略（据说以后会加上）。同步方式也分为全量同步和部分同步。同步时每个slave会向master发送一个replication id和offset，replication id很显然是确定数据源，offset确定偏移值。而master在接收客户端命令时会先将命令缓存的缓存区，然后进行持久化（开启的话），收到slave请求同步消息后，会比对replication id和offset，当replication id是master自身目前的replication id相同且offset在上面缓存的命令中可见时就会启动部分同步，简单的把命令发送给slave就行了。当replication id是历史版本的replication id或者offset超过缓存范围时，就启用全量同步。全量同步则需要redis将自身内存数据转化为rdb格式文件，然后传送给slave以完成同步操作，显然，这个过程会影响对客户端提供服务。但是你也无须太过担心，只要你的备份服务器不是性能太差，网络也ok的情况下，很少会出现这种情况的。

3，redis分区

通常认为的分区是redis cluster中实现的分区将16384个槽分别分配给若干个redis server，并让他们之间进行通信互相告诉对方自己拥有那些槽。而这样做的目的，就是想让不同的key能够有规律的分配的不同redis server上。你可以通过在客户端分配或者实现一个代理来达到同样的效果。

4，redis集群

redis集群是在redis主从复制和redis分区的基础上成为一个高可用架构。它能够对主节点失效进行自动剔除并选举出新的主节点。其中主要涉及一些编程规范，比如不能对键集进行操作，不能将对分布在不同redis server上的key的操作放在事务中等等；redis集群会有小windows的消息丢失场景。集群确实用很多研究点，可以参考官网：redis集群规范

5，redis事务

redis事务并没有像数据库事务那样实现ACID，只是简单的保证放在事务中的语句一定会在执行期间不受其他client打扰，保证串行化。而且要知道，redis事务是分为两部分的，1，先将命令入队列，如果此时有失败，则清除队列命令，返回失败消息；2，执行命令，此时如果在执行中出错，已执行的命令不会回退。

6，redis实现分布式锁

经常用的有一个是redis实现分布式锁。其原理主要是通过setNX命令来实现。一个线程需要获取锁时，会通过setnx先在redis中创建一个key，并且为了防止线程无休止阻塞死掉，通常会设置一个expiretime，到了过期时间，自动删除此key（释放锁）。当然也应该注意这样一种情况，如果一个线程A获取锁后，并超时，此时，锁会自动释放，另一个线程B此时获取锁并且成功后，如果上面超时的线程A这时恢复了，并且执行完了，那么它就会释放锁，那么就会释放B刚获取到的锁，但事实上这个线程B还没有执行完，但是锁已经被错误的释放，其他线程就可以争夺，从而导致你不想看到的结果。

这里算是对redis重点地方做一个小总结，便于以后回顾。