redis相关
-
redis 集群
Redis 集群介绍
集群架构图
Redis 集群是一个提供在多个Redis间节点间共享数据的程序集。
Redis集群并不支持处理多个keys的命令,因为这需要在不同的节点间移动数据,从而达不到像Redis那样的性能,在高负载的情况下可能会导致不可预料的错误.
Redis 集群通过分区来提供一定程度的可用性,在实际环境中当某个节点宕机或者不可达的情况下继续处理命令. Redis 集群的优势:
- 自动分割数据到不同的节点上。
- 整个集群的部分节点失败或者不可达的情况下能够继续处理命令。
redis-cluster投票:容错
-
投票过程是集群中所有
master
参与,如果半数以上master
节点与master
节点通信超时(cluster-node-timeout
),认为当前master
节点挂掉. -
什么时候整个集群不可用(
cluster_state:fail
)?- 如果集群任意
master
挂掉,且当前master
没有slave
.集群进入fail
状态,也可以理解成集群的slot
映射[0-16383
]不完整时进入fail状态.
redis-3.0.0.rc1
加入cluster-require-full-coverage
参数,默认关闭,打开集群兼容部分失败.
- 如果集群超过半数以上
master
挂掉,无论是否有slave
,集群进入fail
状态.
- 如果集群任意
Redis 集群的数据分片
Redis 集群没有使用一致性hash, 而是引入了 哈希槽的概念.
Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽,举个例子,比如当前集群有3个节点,那么:
- 节点 A 包含 0 到 5500号哈希槽.
- 节点 B 包含5501 到 11000 号哈希槽.
- 节点 C 包含11001 到 16384号哈希槽.
这种结构很容易添加或者删除节点. 比如如果我想新添加个节点D, 我需要从节点 A, B, C中得部分槽到D上. 如果我想移除节点A,需要将A中的槽移到B和C节点上,然后将没有任何槽的A节点从集群中移除即可. 由于从一个节点将哈希槽移动到另一个节点并不会停止服务,所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态.
Redis 集群的主从复制模型
为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用,所以集群使用了主从复制模型,每个节点都会有N-1个复制品.
在我们例子中具有A,B,C三个节点的集群,在没有复制模型的情况下,如果节点B失败了,那么整个集群就会以为缺少5501-11000这个范围的槽而不可用.
然而如果在集群创建的时候(或者过一段时间)我们为每个节点添加一个从节点A1,B1,C1,那么整个集群便有三个master节点和三个slave节点组成,这样在节点B失败后,集群便会选举B1为新的主节点继续服务,整个集群便不会因为槽找不到而不可用了
不过当B和B1 都失败后,集群是不可用的.
Redis 一致性保证
Redis 并不能保证数据的强一致性. 这意味这在实际中集群在特定的条件下可能会丢失写操作.
第一个原因是因为集群是用了异步复制. 写操作过程:
- 客户端向主节点B写入一条命令.
- 主节点B向客户端回复命令状态.
- 主节点将写操作复制给他得从节点 B1, B2 和 B3.
主节点对命令的复制工作发生在返回命令回复之后, 因为如果每次处理命令请求都需要等待复制操作完成的话, 那么主节点处理命令请求的速度将极大地降低 —— 我们必须在性能和一致性之间做出权衡。 注意:Redis 集群可能会在将来提供同步写的方法。 Redis 集群另外一种可能会丢失命令的情况是集群出现了网络分区, 并且一个客户端与至少包括一个主节点在内的少数实例被孤立。
举个例子 假设集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六个节点, 其中 A 、B 、C 为主节点, A1 、B1 、C1 为A,B,C的从节点, 还有一个客户端 Z1 假设集群中发生网络分区,那么集群可能会分为两方,大部分的一方包含节点 A 、C 、A1 、B1 和 C1 ,小部分的一方则包含节点 B 和客户端 Z1 .
Z1仍然能够向主节点B中写入, 如果网络分区发生时间较短,那么集群将会继续正常运作,如果分区的时间足够让大部分的一方将B1选举为新的master,那么Z1写入B中得数据便丢失了.
注意, 在网络分裂出现期间, 客户端 Z1 可以向主节点 B 发送写命令的最大时间是有限制的, 这一时间限制称为节点超时时间(node timeout), 是 Redis 集群的一个重要的配置选项:
例子
现在出行项目用的是集群+主备模式。如果只是集群那么任意节点失败,将会有一个区间的slot不可用。如果每个节点再加上主备模式,那么主失败,从将顶替,这个区间的slot依然可用。这样确保高可用。
集群常用命令:
- redis-cli -a saic-pass --stat 可以查看请求量
- redis-cli -a saic-pass --latency-history 查看平均耗时(默认15S统计一次)
- redis-cli -a saic-pass --cluster info 查看集群状态,包括失败的节点有几个
- redis-cli -a saic-pass info 可以看到更全的信息,例如当前节点是否时主或从,主从offset分别是多少(以此判断数据是否同步)
集群下查询KEY参考:010303.redis查询排查
-
redis客户端
命令行模式
TODO
项目中使用方式
TODO
-
常用的数据结构
数据结构
|
使用场景
|
注意事项
|
---|---|---|
string | key-value,可支持数字,性能高 | |
list | 双链表实现,可以支持队列机制,或者存储按时间顺序排序的某些信息 | 注意区分链表的左右,处理好线程并发写的问题 |
set | 不重复数据的集合,如订阅、关注用户id等信息 | 集合无序 |
hash | map,存储对象数据,可以直接读取或修改特定属性的值,可应用于redis分布式锁 | 不要全部取整个hash,性能开销比较大,不推荐做复杂查询,会增加维护成本 |
zset | 有序集合,带权重的集合,可以根据权重进行排序或查找 |
参考文档:http://redisdoc.com/string/incrby.html
-
问题分析
审计日志
告警
slow redis
-
问题处理
redis删除
生产上删除redis数据,需要给运维提供一个工单:新建 → 运维服务 → 数据变更申请, 在描述中写好需要删除的是哪个服务的缓存, 删除原因,及要删除的key,再将单子转交给对应的运维操作即可。
-
规范
-
参考资料