站长资讯网本篇文章给大家带来了关于Redis的相关知识，其中主要介绍了集群的相关问题，Redis集群是一种分布式数据库方案，集群通过分片来进行数据共享，并提供复制和故障转移功能，希望对大家有帮助。
推荐学习：Redis学习教程
几种 Redis 高可用性的解决方案。包括：「主从模式」、「哨兵机制」以及「哨兵集群」。
- 「主从模式」具有读写分离，分担读压力、数据备份，提供多个副本等优点。
- 「哨兵机制」在主节点故障后能自动将从节点提升成主节点，不需要人工干预操作就能恢复服务可用。
- 「哨兵集群」解决单点故障以及单机哨兵产生「误判」问题。
Redis 从最简单的单机版，经过数据持久化、主从多副本、哨兵集群，通过这么一番的优化，不管是性能还是稳定性，都越来越高。
但是随着时间的发展，公司业务体量迎来了爆炸性增长，此时的架构模型，还能够承担这么大的流量吗？
比如有这么一个需求：要用 Redis 保存 5000 万个键值对，每个键值对大约是 512B，为了能快速部署并对外提供服务，我们采用云主机来运行 Redis 实例，那么，该如何选择云主机的内存容量呢？
通过计算，这些键值对所占的内存空间大约是 25GB（5000 万 *512B）。
想到的第一个方案就是：选择一台 32GB 内存的云主机来部署 Redis。因为 32GB 的内存能保存所有数据，而且还留有 7GB，可以保证系统的正常运行。
同时，还采用 RDB 对数据做持久化，以确保 Redis 实例故障后，还能从 RDB 恢复数据。
但是，在使用的过程中会发现，Redis 的响应有时会非常慢。通过 INFO命令 查看 Redis 的latest_fork_usec指标值（表示最近一次 fork 的耗时），结果发现这个指标值特别高。
这跟 Redis 的持久化机制有关系。
在使用 RDB 进行持久化时，Redis 会 fork 子进程来完成，fork 操作的用时和 Redis 的数据量是正相关的，而 fork 在执行时会阻塞主线程。数据量越大，fork 操作造成的主线程阻塞的时间越长。
所以，在使用 RDB 对 25GB 的数据进行持久化时，数据量较大，后台运行的子进程在 fork 创建时阻塞了主线程，于是就导致 Redis 响应变慢了。
显然这个方案是不可行的，我们必须要寻找其他的方案。
