wayne_youlu的博客

在Redis延迟队列中，我们使用有序集合（Sorted Set）来存储消息，其中，消息的到期时间作为有序集合的分数，消息内容作为有序集合的成员。支持多种操作：除了基本的添加、删除和范围查询，Sorted Set还支持其他一些有用的操作，如获取成员的分数、修改成员的分数、按照分数范围删除成员等。在这个命令中，delay_queue是有序集合的名称，1640390400是消息的到期时间（即2023年12月25日的时间戳），"message content"是消息的内容。其中就包括了延迟队列的实现。

Bean// 创建模板// 设置连接工厂// 设置序列化工具// key和 hashKey采用 string序列化// value和 hashValue采用 JSON序列化当配置好配置类后，再次执行上文的代码就不会出现上述情况了，但是问题又来了，当我们的value是一个对象时：不仅仅是这个问题，由于我们的value是object类型。在反序列化的时候还经常会出现把long值转成int值导致泛型转化失败等场景。这里推荐不需要json序列化器，直接用string序列化器用。

Redis big key problem，实际上不是大Key问题，而是Key对应的value过大，因此严格来说是Big Value问题，Redis value is too large (key value is too large)。到底多大的value会导致big key问题，并没有统一的标准。例如，对于String类型的value，有时候超过5M属于big key，有时候稳妥起见，超过10K就可以算作Bigey。Big Key会导致哪些问题呢？

定期过期：每隔⼀定的时间，会扫描⼀定数量的数据库的expires字典中⼀定数量的key，并清除其中已过期的key。(expires字典会保存所有设置了过期时间的key的过期时间数据，其中，key是指向键空间中的某个键的指针，value是该键的毫秒精度的UNIX时间戳表示的过期时间。定时过期：每个设置过期时间的key都需要创建⼀个定时器，到过期时间就会⽴即清除。该策略可以⽴即清除过期的数据，对内存很友好；但是会占⽤⼤量的CPU资源去处理过期的数据，从⽽影响缓存的响应时间和吞吐量。

如果删除的是字符串类型的 key，但是key对应value比较大，比如有几百M，那么也是会 阻塞Redis的。这种bigkey是我们要尽量减少出现的情况。LFU 算法(Least Frequently Used，最不经常使用)：淘汰最近一段时间被访问次数最少的 数据，以次数作为参考。LRU 算法(Least Recently Used，最近最少使用)：淘汰很久没被访问过的数据，以最近一 次访问时间作为参考。绝大多数情况我们都可以用LRU策略，当存在大量的热点缓存数据时，LFU可能更好点。

奇数个master节点可以在满足选举该条件的基础上节省一个节点。例如三个master节点和四个master节点的集群相比。的集群master节点同意才能选举成功，如果只有两个master节点，当其中一个挂了，是达不到选举新master的条件的。master的选举需要。所以奇数的master节点更多的是从。