1.数据淘汰策略
-noeviction:返回错误当内存限制达到并且客户端尝试执行会让更多内存被使用的命令(大部分的写入指令,但DEL和几个例外)
- allkeys-lru:尝试回收最少使用的键(LRU), 使得新添加的数据有空间存放。
- volatile-lru:尝试回收最少使用的键(LRU),但仅限于在过期集合的键,使得新添加的数据有空间存放。
- allkeys-random:回收随机的键使得新添加的数据有空间存放。
- volatile-random:回收随机的键使得新添加的数据有空间存放,但仅限于在过期集合的键。
- volatile-ttl:回收在过期集合的键,并且优先回收存活时间(TTL)较短的键,使得新添加的数据有空间存放。
2.集群
1.twemproxy,大概概念是,它类似于一个代理方式,使用方法和普通Redis无任何区别,设置好它下属的多个Redis实例后,使用时在本需要连接Redis的地方改为连接twemproxy,它会以一个代理的身份接收请求并使用一致性hash算法,将请求转接到具体Redis,将结果再返回twemproxy.使用方式简便(相对Redis只需修改连接端口),对旧项目扩展的首选。
问题: twemproxy自身单端口实例的压力,使用一致性hash后,对Redis节点数量改变时候的计算值的改变,数据无法自动移动到新的节点。
-
codis, 目前用的最多的集群方案,基本和twemproxy一致的效果,但它支持在节点数量改变情况下,旧节点数据可恢复到新hash节点。
-
Redis cluster3.0自带的集群,特点在于他的分布式算法不是一致性hash,而是hash槽的概念,以及自身支持节点设置从节点。具体看官方文档介绍。
4.在业务代码层实现,起几个毫无关联的Redis实例,在代码层,对key进行hash计算,然后去对应的Redis实例操作数据。这种方式对hash层代码要求比较高,考虑部分包括,节点失效后的替代算法方案,数据震荡后的自动脚本恢复,实例的监控,等等。
标签:hash,twemproxy,Redis,回收,概念,数据,节点 From: https://www.cnblogs.com/lwx11111/p/17609642.html