Stream 是 Redis 5.0 版本专门为消息队列设计的数据类型,借鉴了 Kafka 的 Consume Group 设计思路,提供了消费组概念。 同时提供了消息的持久化和主从复制机制,客户端可以访问任何时刻的数据,并且能记住每一个客户端的访问位置,从而保证消息不丢失。
在 Redis 的实际使用过程中,我们经常会面对以下的场景: 在 Redis 上执行同样的命令,为什么有时响应很快,有时却很慢; 为什么 Redis 执行 GET、SET、DEL 命令耗时也很久; 为什么我的 Redis 突然慢了一波,之后又恢复正常了; 为什么我的 Redis 稳定运行了很久,突然从某个时间点开始变慢了。 这时我们还是需要一个全面的排障流程,不能无厘头地进行优化;全面的排障流程可以帮助我们找到真正的根因和性能瓶颈,以及实施正确高效的优化方案。 这篇文章我们就从可能导致 Redis 延迟的方方面面开始,逐步深入排障深水区,以提供一个「全面」的 Redis 延迟问题排查思路。
什么是数据倾斜? 单台机器的硬件配置有上限制约,一般我们会采用分布式架构将多台机器组成一个集群,下图的集群就是由三台Redis单机组成。客户端通过一定的路由策略,将读写请求转发到具体的实例上。 由于业务数据特殊性,按照指定的分片规则,可能导致不同的实例上数据分布不均匀,大量的数据集中到了一台或者几台机器节点上计算,从而导致这些节点负载多大,而其他节点处于空闲等待中,导致最终整体效率低下。
面试中,被问到Redis问题的概率非常高,如果问一些理论性的问题,相信你只要背背八股文就能搞定,但,如果结合项目来问就没那么好对付了。
今天下午和一位同学聊Redis集群,这玩意真没那么简单,内容非常多。 Redis Cluster是Redis官方提供的Redis集群功能。