GJ_863的博客

我们通过故意将一个master端口的Redis宕机，可以发现之后redis自动选取了他的从节点作为新的master，原来的宕机的那个在重新启动后，变成了slave，整个过程不需要哨兵，自动完成。实际业务中，可能由于某台master老旧，就为他添加了新的slave，想要将这个新的slave变成master，实现手动故障转移。而且，如果key时和节点绑定，节点宕机后，数据就丢失了，而和插槽绑定，节点宕机后将他上面的插槽转移即可。如果是新添加一个master，上面一开始是没有插槽的，我们可以使用。

但是由于$代表读最新的消息，如果我们处理一条消息的过程中，又有超过一条消息到达消息队列，则下次只能获取最新的那条消息，出现漏读消息的问题。消费者可以订阅一个或多个channel，生产者向对应channel发送消息后，所有订阅者都能收到相关消息，就实现了。一般不需要手动创建消费者，当我们指定一个组去监听消息时，如果他发现组中没有消费者，会自动帮我们创建。缺点：不支持数据持久化，无法避免数据丢失，消息堆积有上限，超出时数据丢失。pubsub：基本的点对点消息模型。消息可以回溯，可以被多个消费者读取。

线程1拿到锁后执行业务完毕，对比完锁中的线程标识和自己的线程标识，正准备释放锁，但此时发生了阻塞（可能是jvm的full gc等问题），锁超时释放，线程2拿到了锁，此时线程1的阻塞结束，释放了锁，线程3又能拿到锁，这样线程2和线程3都在执行业务，产生并发问题。Redisson的可重试不是无休止的等待和重试，而是利用Redis的订阅发布和信号量，在锁彻底被释放时，发布一条消息，正在等待重试的线程一旦接收到这样的消息，就会先判断时间是否超出最大等待时间，没有就进行抢锁，期间也会不断校验是否超出最大等待时间。

指某个时间段，缓存集中过期失效，于是所有的请求都会达到存储层，集中创建缓存，存储层的调用量会暴增，造成周期性压力。其中，最要害的问题，就是数据的一致性问题，从严格意义上讲，这个问题无解。这个key过期的瞬间，持续的大并发就穿破缓存，直接请求数据库，同时回写缓存，这时给数据库造成很大压力。Redis 缓存的使用，极大的提升了应用程序的性能和效率，特别是数据查询方面。数据库和缓存中都没有，这样缓存无法拦截，也无法在数据库中查询到存到缓存中，查询一个数据，如果缓存中存在，则返回数据。另外的一些典型问题就是，

假设哨兵1先检测到master宕机，系统不会马上进行failover（故障转移） 过程，仅仅是主观下线，等到一定数量的哨兵检测到主机宕机，就会进行一次投票选取新的主机，切换成功后，会通过发布订阅模式，各个哨兵告诉自己监控的从机切换主机，称为客观下线。哨兵模式是一种特殊的模式，首先 Redis 提供了哨兵的命令，哨兵是一个独立的进程，它会独立运行。在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务，分担服务器负载。当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复。

这些命令被广泛用于构建即时通信应用，比如网络聊天室（频道当做聊天室，将信息回显给所有人）和实时广播、实时提醒等。Redis客户端可以订阅任意数量的频道。redis发布订阅是一种消息通信模式。稍微复杂的场景会用消息中间件 MQ等。发布（pub） 订阅（sub）

先将数据写入一个临时文件，等持久化过程都结束了，再用这个临时文件替换上次持久化好的文件，整个过程主进程不进行IO操作，确保及高性能。会单独创建一个子进程来进行持久化（fork作用是复制一个与当前进程相同的进程，这是个全新的进程，作为原来进程的子进程）Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘，一旦服务器进程退出，数据库状态将丢失，以日志的形式将所有的命令都记录下来（读数据操作不记录），恢复时，将这个文件全部执行一遍。aof默认是文件的无限累加，文件越来越大，所以设置了重写机制。

redis基于内存操作，所以 cpu不是redis的性能瓶颈，redis的瓶颈是网络带宽和内存，可以使用单线程来实现。Redis中单条命令的执行是保证原子性的，而事务是不保证的，且没有回滚，事务中任意命令执行失败，其余命令仍会被执行。若命令中存在语法错误（类似Java中的1/0，运行时异常），执行exec时，错误命令抛出异常，其它命令正常执行。redis将所有数据放在内存中，所以使用单线程效率最高，多线程会有cpu中的上下文切换，这是耗时操作。位图，也是radis的数据结构。如果数据较多，可能会有误差。