Redis数据一致性
Redis集群节点的数据一致性
哈希槽
Redis 集群没有使用一致性hash, 而是引入了哈希槽的概念。Redis 集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个哈希槽。集群的每个节点负责一部分hash槽。这种结构很容易添加或者删除节点，并且无论是添加删除或者修改某一个节点，都不会造成集群不可用的状态。
使用哈希槽的好处就在于可以方便的添加或移除节点。当需要增加节点时，只需要把其他节点的某些哈希槽挪到新节点就可以了；当需要移除节点时，只需要把移除节点上的哈希槽挪到其他节点就行了；以后新增或移除节点的时候不用先停掉所有的 Redis 服务。
主从复制
Redis集群的主从架构：为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型,每个节点都会有N-1个复制品。
主从复制：
【1】Redis的复制功能是支持多个数据库之间的数据同步。一类是主数据库（master），一类是从数据库（slave）。主数据库可以进行读写操作，当发生写操作的时候自动将数据同步到从数据库，而从数据库一般是只读的，并接收主数据库同步过来的数据，一个主数据库可以有多个从数据库，而一个从数据库只能有一个主数据库。
【2】通过Redis的复制功能可以很好的实现数据库的读写分离，提高服务器的负载能力。主数据库主要进行写操作，而从数据库负责读操作。
- 当一个从数据库启动时，会向主数据库发送sync命令
- 主数据库接收到sync命令后会开始在后台保存快照（执行rdb操作），并将保存期间接收到的命令缓存起来
- 当快照完成后，redis会将快照文件和所有缓存的命令发送给从数据库
- 从数据库收到后，会载入快照文件并执行收到的缓存的命令
例如有A，B，C三个节点的集群,在没有复制模型的情况下,如果节点B失败了，那么整个集群就会以为缺少B节点所承担的哈希槽这个范围的槽而不可用。
然而如果在集群创建的时候（或者过一段时间）为每个节点添加一个从节点A1，B1，C1,那么整个集群便有三个master节点和三个slave节点组成，这样在节点B失败后，集群便会选举B1为新的主节点继续服务，整个集群便不会因为槽找不到而不可用了。
Redis数据一致性
所谓的Redis数据一致性即当进行修改或者保存、删除之后，Redis中的数据也应该进行相应变化，不然用户再次查询的时候很可能查询出已经删除过的脏数据。
缓存一致的必要性
使用Redis的时候缓存一致性的问题需要着重考虑，例如：保存了一个新用户之后，就应该同时在Redis缓存中也插入该条数据，更新了某条数据在缓存中也应该同步更新，而Redis默认的做法是：当不去设置的时候Redis中存放的值是之前存放的数据，只有在重启服务器的时候数据才会同步，显然这是非常不可取的。
缓存一致性实现
- 在进行插入操作之后，把该条数据取出来同时保存到Redis缓存中去，这样再次查询缓存的时候也可以看到新的数据
- 定期清除Redis中的数据，例如设置一个定时任务，每当一个小时的时候就会清除Redis中的数据，也就是让Redis中的数据失效，然后再次保存、删除的时候之前的 Redis中的数据已经不存在，所以相当于是将数据重新设置到Redis中去，所以可以保证数据的一致性
