【redis】redis的哨兵Sentinel高可用架构

找到 /ect/redis/redis.conf 文件修改如下：注释掉 127.0.0.1 ，如果不需要远程连接redis则不需要这个操作。使用客户端向 Redis 服务器发送一个 PING ，如果服务器运作正常的话，会返回一个 PONG。默认情况下，Redis服务器不允许远程访问，只允许本机访问，所以我们需要设置打开远程访问的功能。执行sudo apt-get install redis-server 安装命令。查看 redis 是否启动，重新打开一个窗口。停止/启动/重启redis。

下载版本Redis-x64-5.0.14.1.zip。(可能需要开代理)

也就是在设定的时间里数据没有取出来，但是锁由过期了，常见的思路是，锁过期时间值递增，但是想想不靠谱，因为第一个请求可能超时，如果后面的也超时呢，接连多次超时之后，锁过期时间值势必特别大了，这样做弊端太多。雪崩，和击穿类似，不同的是击穿是一个热点Key某时刻失效，而雪崩是大量的热点Key在一瞬间失效，网络上很多博客都在强调解决雪崩的策略是随机过期时间，这个非常不准确，举个例子，银行做活动，之前这个利息系数为2%，过了零点系数改为3%，这种情况能将用户的对应的key改为随机过期吗？如果用的过去的数据叫脏数据。

这是一道经典的Redis面试题，一个Redis中可能存在很多很多的key，这些key中可能有很大一部分都有过期时间，此时Redis服务器咋知道哪些key已经过期，哪些还没过期呢？如果直接遍历所有的key，这显然是行不通的，效率非常低！！Redis整体的策略是定期删除和惰性删除相结合。举个栗子：假如我去小卖铺买东西，付款的时候，发现东西过期了。就告知老板，于是老板下架此产品。消费者发现过期了，才去下架，这就叫。小卖铺老板主动定期抽取一部分商品，进行筛查，这就叫定期删除。

Redis 是一种内存键值数据库。它支持多种数据结构，如 String, Hash, List, Set 和 SortedSet。

这里 我就改用 sudo service redis start。然后 他会提示你要占多少磁盘空间 例如 我这里是 1.7 M。因为我们刚安装好 端口 密码都没设置过 就是。然后 我们可以根据版本选择启动命令。没问题就 y 然后回车就可以了。如下图 我们很明显就是连接到了。先打开我们的Linux服务器。这样我们 redis就起来了。终端执行 安装redis。这样 就能看到版本了。

本章节主要讲解redis中的红锁，假设我们有个客户端要获取锁，然后向master去获取锁，然后master会把锁同步到slave节点，假设现在还没同步出去的时候,master节点挂了。然后从节点升级为主节点，然后另外一个刚刚在竞争锁失败处于阻塞状态的线程去获取锁的时候，但是新的master上，并没有锁的信息，然后就能拿到锁，此时就可能导致一些问题。此时我们就能使用红锁，来解决这个问题。一个客户端要向多个master节点发送加锁请求。只有半数的锁加锁成功，才是获取锁。

自定义目录：/myredis/redis.conf。

里面大致说了redis的架构演进。开始学redis架构的时候，总是感觉架构好多，迷迷糊糊的，但是你知道Redis 架构演化之路之后，就明白了前因后果，这样学习更加深入以及搞笑。这篇文章我想和你聊一聊 Redis 的架构演化之路。现如今 Redis 变得越来越流行，几乎在很多项目中都要被用到，不知道你在使用 Redis 时，有没有思考过，Redis 到底是如何稳定、高性能地提供服务的？如果你对 Redis 已经有些了解，肯定也听说过。

Redis哨兵机制和集群有什么区别？redis集群有几种实现方式，一个是主从集群，一个是redis cluster.

如果需要根据某种模式来获取键，更好的选择是使用更高效的命令，如SCAN命令，它使用游标方式迭代返回匹配的键，避免了遍历整个键空间的性能问题，并且可以逐步处理数据。KEYS命令用于检索匹配指定模式的所有键。如果匹配的键非常多，返回的结果列表可能巨大无比，占用大量的内存。在极端情况下，如果执行KEYS命令返回的结果集非常大，并且内存不足以容纳整个结果集，Redis服务器可能会发生内存溢出错误。如果KEYS命令运行时间较长或遇到大量匹配的键，会导致服务器长时间无法响应其他请求，从而对系统的可用性产生负面影响。

在Redis中，大key是指存储了大量数据的键。处理大key可能会对Redis服务器的性能和资源消耗产生负面影响。询问这个问题，首先要知道redis的大key会有什么影响。大key占用的内存空间较大，当大量的大key存在时，会消耗大量的内存资源。这可能导致Redis服务器的内存不足，并触发内存溢出，从而影响系统的稳定性和性能。当读取或写入大key时，需要将大量的数据通过网络传输。对于大量的网络传输，特别是在高并发的情况下，会增加整体的延迟，并占用带宽资源。

putIfAbsent 指的是如果传入key对应的value已经存在，就返回存在的value，不进行替换。如果不存在，就添加key和value，返回null。如果传入key对应的value已经存在，就返回存在的value，不进行替换。如果不存在，就添加key和value，返回null。下面这两句话，可以实现向Redis插入Hash数据，并且设置整个Hash的过期时间。TimeUnit.MILLISECONDS：毫秒。TimeUnit.MILLISECONDS：微秒。TimeUnit.MINUTES：分。

该模板的序列化机制改变起来也很容易，并且Redis模块在org.springframework.data.redis.serializer包中提供了多种可用的实现，详情请参考Serializers。大部分的用户都喜欢用RedisTemplate，它相应的包是org.springframework.data.redis.core。虽然RedisConnection提供接受和返回二进制值（字节数组）的低级方法，但该模板可以处理序列化和连接管理，使得用户不需要处理太多的细节。如果 两者是实现的效果是相同的。

对于上面这种情况，对于第一次查询，请求 B 查询的数据是 10，但是 MySQL 的数据是 11，只存在这一次不一致的情况，对于不是强一致性要求的业务，可以容忍。这个图已经画的很清晰了，我就不用再去啰嗦了吧，不过这里有个前提，就是对于读请求，先去读 Redis，如果没有，再去读 DB，但是读请求不会再回写 Redis。请求 A、B 都是先写 MySQL，然后再写 Redis，在高并发情况下，如果请求 A 在写 Redis 时卡了一会，请求 B 已经依次完成数据的更新，就会出现图中的问题。

对网络同学开销的平衡：redis集群中的每个节点，会发送心跳消息，而心跳包中会携带节点的完整配置，他能够以幂等的方式来实现配置的更新。但是修改集群的槽位数量需要进行数据迁移和重新均衡，会对集群产生较大的影响，因此一般情况下建议使用默认的 16384 个槽位。可用性和容错性：16384 是一个较大的数字，可以提供足够的槽位数量来分布数据，从而提高集群的可用性和容错性。应用程序去存储一个key的时候会通过，对key进行一个CRC16去计算，再取模，然后路由到hash slot所在的节点。

为了避免子进程在重写过程过程中，主进程中的数据发生变化，导致AOF文件里面的数据和redis内存中的数据不一致，redis中还做了一个优化，也就是说在子进程在做这个重写的过程中，主进程中的数据变更，需要追加到AOF的重写缓冲区中，等到AOF重写完成以后，再把AOF重写缓冲区的数据，追加到新的AOF文件里面，这样意料就能保证新的AOF文件里面的数据和当前Redis中的数据保持一致。子进程在进行重写的过程中，主进程依然可以去处理客户端的一个请求，这样一来子进程在重写的过程中，不耽误客户端的使用。

建议大家去看原文，这里是学到了，记录一下。最近项目的生产环境遇到一个奇怪的问题：现象 ：每天早上客服人员在后台创建客服事件时，都会创建失败。当我们重启 这个微服务后，后台就可以正常创建了客服事件了。到第二天早上又会创建失败，又得重启这个微服务才行。初步排查 ：创建一个客服事件时，会用到 Redis 的递增操作来生成一个唯一的分布式 ID 作为事件 id。而恰巧每天早上这个递增操作都会返回 null，进而导致后面的一系列逻辑出错，保存客服事件失败。当重启微服务后，这个递增操作又正常了。

然后再看这个好理解一些。bitmap的表象意义是，使用一个01标识位来表示是否的状态，可以达到节省空间和高效判定的效果。在我们的实际工作中，也有着许多的应用场景，相信了解bitmap定会给你带来一些额外的收获。

Redis保证高可用主要有三种方式：主从、哨兵、集群。

报错信息如下Spring 官方给出的解决方案如下。

文章浏览阅读151次，点赞4次，收藏3次。在分布式系统中，涉及多个主机访问同一块资源，此时就需要锁来做互斥控制，避免出现类似线程安全问题。而Java中的synchronized只是对当前进程中的线程有效，多个主机实际上是多个进程，那么它就无能为力了，此时就需要分布式锁。

现有6台redis，为集群，3主3从，由于两台服务器故障重装系统之后进行重新安装2台redis,安装完成之后。查询当前redis状态，发现有存留的节点，但连接为fai。将新建的两台redis启动，保证配置文件一致。查询fail节点的node_id。将新建的两台redis设为从节点。登录新建的两台redis服务器。先通过ID删掉无用的节点。