redis缓存集群与分布式实现方式

redis缓存集群与分布式实现方式


redis是一种支持Key-Value等多种数据结构的存储系统,

提供字符串、哈希、列表、队列、集合结构直接存取，

基于内存，可持久化。

一个键值最大存储512MB,memcached为1M


redis持久有两种方式:Snapshotting(快照),Append-only file(AOF)

Snapshotting(快照)
1、将存储在内存的数据以快照的方式写入二进制文件中，如默认dump.rdb中
2、save 900 1
#900秒内如果超过1个Key被修改，则启动快照保存
3、save 300 10
#300秒内如果超过10个Key被修改，则启动快照保存
4、save 60 10000
#60秒内如果超过10000个Key被修改，则启动快照保存

Append-only file(AOF)
1、使用AOF持久时，服务会将每个收到的写命令通过write函数追加到文件中（appendonly.aof）
2、AOF持久化存储方式参数说明
    appendonly yes 
           #开启AOF持久化存储方式
    appendfsync always
         #收到写命令后就立即写入磁盘，效率最差，效果最好
    appendfsync everysec
         #每秒写入磁盘一次，效率与效果居中
    appendfsync no
         #完全依赖OS，效率最佳，效果没法保证


Redis3.0以后开始支持集群，实现了半自动化的数据分片，不过需要smart-client的支持。

Redis使用单线程的IO复用模型，自己封装了一个简单的AeEvent事件处理框架，主要实现了epoll、kqueue和select，对于单纯只有IO操作来说，单线程可以将速度优势发挥到最大，但是Redis也提供了一些简单的计算功能，比如排序、聚合等，对于这些操作，单线程模型实际会严重影响整体吞吐量，CPU计算过程中，整个IO调度都是被阻塞住的。


在一致性问题上，个人感觉redis没有memcached实现的好，Memcached提供了cas命令(比较和交换(Conmpare And Swap))，可以保证多个并发访问操作同一份数据的一致性问题。 Redis没有提供cas 命令，并不能保证这点，不过Redis提供了事务的功能，可以保证一串命令的原子性，中间不会被任何操作打断。


Java客户端Jedis


数据复制：
1. 如果设置了一个Slave，无论是第一次连接还是重连到Master，它都会发出一个SYNC命令；
2. 当Master收到SYNC命令之后，会做两件事：
a) Master执行BGSAVE：后台写数据到磁盘（rdb快照）；
b) Master同时将新收到的写入和修改数据集的命令存入缓冲区（非查询类）；
3. 当Master在后台把数据保存到快照文件完成之后，Master会把这个快照文件传送给Slave，而Slave则把内存清空后，加载该文件到内存中；
4. 而Master也会把此前收集到缓冲区中的命令，通过Reids命令协议形式转发给Slave，Slave执行这些命令，实现和Master的同步；
5. Master/Slave此后会不断通过异步方式进行命令的同步，达到最终数据的同步一致；
6. 需要注意的是Master和Slave之间一旦发生重连都会引发全量同步操作。但在2.8之后，也可能是部分同步操作。
2.8开始，当Master和Slave之间的连接断开之后，他们之间可以采用持续复制处理方式代替采用全量同步。
Master端为复制流维护一个内存缓冲区（in-memory backlog），记录最近发送的复制流命令；同时，Master和Slave之间都维护一个复制偏移量(replication offset)和当前Master服务器ID（Masterrun id）。

当网络断开，Slave尝试重连时：
a. 如果MasterID相同（即仍是断网前的Master服务器），并且从断开时到当前时刻的历史命令依然在Master的内存缓冲区中存在，则Master会将缺失的这段时间的所有命令发送给Slave执行，然后复制工作就可以继续执行了；
b. 否则，依然需要全量复制操作。

读写分离：redis支持读写分离，而且使用简单，只需在配置文件中把redis读服务器和写服务器进行配置，多个服务器使用逗号分开如下：


Redis 3.0
Redis 3.0。新版本主要是实现了Cluster的功能，增删集群节点后会自动的进行数据迁移。
实现 Redis 集群在线重配置的核心就是将槽从一个节点移动到另一个节点的能力。因为一个哈希槽实际上就是一些键的集合， 所以 Redis 集群在重哈希（rehash）时真正要做的，就是将一些键从一个节点移动到另一个节点。



数据淘汰策略：
redis 提供 6种数据淘汰策略：
volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰
allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
no-enviction（驱逐）：禁止驱逐数据


集群（即分布式）
Redis 集群中不存在中心（central）节点或者代理（proxy）节点， 集群的其中一个主要设计目标是达到线性可扩展性（linear scalability）。

Redis 集群为了保证一致性（consistency）而牺牲了一部分容错性： 系统会在保证对网络断线（netsplit）和节点失效（node failure）具有有限（limited）抵抗力的前提下，尽可能地保持数据的一致性。


集群特性：
(1)所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
(2)节点的fail是通过集群中超过半数的节点检测失效时才生效。
(3)客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
(4)redis-cluster把所有的物理节点映射到[0-16383]slot上,cluster 负责维护node<->slot<->value

Redis 集群不像单机Redis 那样支持多数据库功能， 集群只使用默认的 0 号数据库， 并且不能使用 SELECT 命令。


Redis 集群中的节点有以下责任：
1. 持有键值对数据。
2. 记录集群的状态，包括键到正确节点的映射（mappingkeys to right nodes）。
3. 自动发现其他节点，识别工作不正常的节点，并在有需要时，在从节点中选举出新的主节点。


因为客户端可以自由地向集群中的任何一个节点发送命令请求， 并可以在有需要时， 根据转向错误所提供的信息， 将命令转发至正确的节点，所以在理论上来说， 客户端是无须保存集群状态信息的。不过， 如果客户端可以将键和节点之间的映射信息保存起来， 可以有效地减少可能出现的转向次数， 籍此提升命令执行的效率。



键分布模型
Redis 集群的键空间被分割为 16384 个槽（slot）， 集群的最大节点数量也是 16384 个。

推荐的最大节点数量为 1000 个左右。每个主节点都负责处理 16384 个哈希槽的其中一部分。

。重配置指的是将某个/某些槽从一个节点移动到另一个节点。一个主节点可以有任意多个从节点，这些从节点用于在主节点发生网络断线或者节点失效时， 对主节点进行替换。


集群节点属性：
每个节点在集群中都有一个独一无二的 ID ， 该 ID 是一个十六进制表示的 160 位随机数， 在节点第一次启动时由 /dev/urandom 生成。

节点会将它的 ID 保存到配置文件， 只要这个配置文件不被删除，节点就会一直沿用这个 ID 。节点 ID 用于标识集群中的每个节点。一个节点可以改变它的 IP 和端口号， 而不改变节点 ID 。集群可以自动识别出 IP/端口号的变化， 并将这一信息通过 Gossip 协议广播给其他节点知道。


以下是每个节点都有的关联信息， 并且节点会将这些信息发送给其他节点：
1. 节点所使用的 IP 地址和 TCP 端口号。
2. 节点的标志（flags）。
3. 节点负责处理的哈希槽。
4. 节点最近一次使用集群连接发送 PING 数据包（packet）的时间。
5. 节点最近一次在回复中接收到 PONG 数据包的时间。
6. 集群将该节点标记为下线的时间。
7. 该节点的从节点数量。
8. 如果该节点是从节点的话，那么它会记录主节点的节点 ID 。如果这是一个主节点的话，那么主节点 ID 这一栏的值为 0000000 。

以上信息的其中一部分可以通过向集群中的任意节点（主节点或者从节点都可以）发送 CLUSTER NODES 命令来获得。


MOVED 转向：
一个 Redis 客户端可以向集群中的任意节点（包括从节点）发送命令请求。节点会对命令请求进行分析， 如果该命令是集群可以执行的命令， 那么节点会查找这个命令所要处理的键所在的槽。如果要查找的哈希槽正好就由接收到命令的节点负责处理，那么节点就直接执行这个命令。另一方面， 如果所查找的槽不是由该节点处理的话， 节点将查看自身内部所保存的哈希槽到节点 ID 的映射记录，并向客户端回复一个 MOVED 错误。

即使客户端在重新发送 GET 命令之前， 等待了非常久的时间，以至于集群又再次更改了配置， 使得节点 127.0.0.1:6381 已经不再处理槽 3999 ， 那么当客户端向节点 127.0.0.1:6381 发送 GET 命令的时候， 节点将再次向客户端返回 MOVED 错误， 指示现在负责处理槽 3999 的节点。

虽然我们用 ID 来标识集群中的节点， 但是为了让客户端的转向操作尽可能地简单，，节点在 MOVED 错误中直接返回目标节点的 IP 和端口号，而不是目标节点的 ID 。但一个客户端应该记录（memorize）下“槽 3999 由节点 127.0.0.1:6381 负责处理“这一信息， 这样当再次有命令需要对槽 3999 执行时， 客户端就可以加快寻找正确节点的速度。

注意， 当集群处于稳定状态时， 所有客户端最终都会保存有一个哈希槽至节点的映射记录（map of hash slots to nodes）， 使得集群非常高效： 客户端可以直接向正确的节点发送命令请求， 无须转向、代理或者其他任何可能发生单点故障（single point failure）的实体（entiy）。


集群在线重配置：
Redis 集群支持在集群运行的过程中添加或者移除节点。实际上， 节点的添加操作和节点的删除操作可以抽象成同一个操作，那就是， 将哈希槽从一个节点移动到另一个节点：添加一个新节点到集群， 等于将其他已存在节点的槽移动到一个空白的新节点里面。从集群中移除一个节点， 等于将被移除节点的所有槽移动到集群的其他节点上面去。

因此， 实现Redis 集群在线重配置的核心就是将槽从一个节点移动到另一个节点的能力。 因为一个哈希槽实际上就是一些键的集合， 所以 Redis 集群在重哈希（rehash）时真正要做的， 就是将一些键从一个节点移动到另一个节点。


Redis集群模式主要有2种:
主从集群
分布式集群。
前者主要是为了高可用或是读写分离，后者为了更好的存储数据，负载均衡。

前者主要是为了高可用或是读写分离，后者为了更好的存储数据，负载均衡。

创建一个从节点：redis-server --port 6379 --slaveof master-ip master-port

集群--主从模式--哨兵模式

主从模式本身通过设置从机就可以实现了


内部通过Cluster相关命令帮我们简化集群创建、检查、槽迁移和均衡等常见运维操作。(执行后会执行槽的分配,线性分配)



客户端（Jedis）连接与操作
https://cloud.tencent.com/developer/article/1333005(Redis Cluster的搭建与部署，实现redis的分布式方案)
https://www.cnblogs.com/chenkeyu/p/8047811.html



哨兵模式(类似zk)
Sentinel(哨兵)进程是用于监控redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用，

每个哨兵(Sentinel)进程会向其它哨兵(Sentinel)、Master、Slave定时发送消息，以确认对方是否”活”着，如果发现对方在指定配置时间(可配置的)内未得到回应，则暂时认为对方已掉线，也就是所谓的”主观认为宕机” ，

自动故障迁移(Automatic failover)：当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作，它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master；当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用现在的Master替换失效Master。Master和Slave服务器切换后，Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变，即，Master主服务器的redis.conf配置文件中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。



Redis集群用Cluster就可以了，实现了分布式存储、高可用性、故障转移、主从的功能了










https://blog.csdn.net/middleware2018/article/details/80355418(关于redis，学会这8点就够了)
https://www.cnblogs.com/yangxiaolan/p/5786123.html(分布式缓存Redis使用心得)