5、redis

介绍

Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

高可用redis集群搭建以及原理详解.

1、Redis集群的数据分片

Redis集群没有使用一致性hash，而是引入了哈希槽的概念

Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个解点负责一部分hash槽

举例：当前集群有3个解点，那么：

节点A包含0-5500号哈希槽

节点B包含5501-11000号哈希槽

节点C包含11001-16384号哈希槽

这种结构很容易添加或者删除节点，比如如果我想新添加个节点D,我选哟从节点ABC中得到部分槽到D上。如果我移除节点A，需要将A中的槽移到B和C节点上，然后将没有任何槽的A节点从集群中移除即可。由于从一个节点将哈希槽移动到另一个节点并不会停止服务，所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态

2、Redis集群的主从复制模型

为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型，每个节点都会有N-1各复制品

在我们例子中具有ABC三个节点的集群，在没有复制模型情况下，如果节点B失败了，那么整个集群就会衣卫缺少了5501-11000这个范围内的槽而不可用

然而如果在集群创建的时候（或者过一段时间）我们为每个节点添加一个从节点，A1,B1,C1，那么整个集群便有三个master节点和三个slave节点组成，这样在节点B失败后，集群便会选择B1为新的主节点继续服务，整个集群便不会因为槽找不到而不可用。

不过当B和B1都失败后，集群式不可用的

3、Redis一致性保证

Redis并不能保证数据的一致性，这意味着在实际中集群在特定的条件下可能会丢失写操作

第一个原因是因为集群使用了异步复制，写操作过程：

客户端向主节点B写入一条命令

主节点B想客户端回复命令状态

主节点将写操作复制给他的从节点B1,B2,B3

主节点对命令的复制工作发生在返回命令回复之后，因为如果每次处理命令请求都需要等待复制操作完成之后的话，那么主节点处理命令请求的速度将极大地降低-------我们必须在性能和一致性之间做出权衡。注意：redis集群可能会在将来提供同步的写的方法。Redis集群另外一个可能会丢置命令的情况是集群出现网络分区，并且一个客户端与至少一个主节点在内的少数实例被孤立

举例：假设集群包含A,B,C,A1,B1,C1六个节点，还有一个哭护短z1，假设集群中发生网络分区，那么集群可能会分为两方，大部分的一方包含节点A,C,A1,B1,C1，小部分的一方则包含节点B和客户端z1，z1仍然能够想主节点B中写入，若果网络分区发生时间较短，那么集群将会继续正常运行，如果分区时间足够让大部分的以放B1选举成为新的master，那么z1写入B中的数据就会丢失。

注意：在网络分裂弧线期间，客户端z1可以向主节点B发送写命令的最大时间是有限制的，这一时间限制称为节点超时时间（node timeout），是Redis集群的一个重要的配置选项