这个系列是个人学习Redis的一点记录,希望对大家有帮助
若有错误,欢迎指正
我们为什么需要高可用性?
我们知道,Redis作为一个内存数据库,自然在物理层面上就奠定其高性能的基础,也就是常说的QPS(Queries Per Second)很高。
由于是内存数据库,其高效能的背后也有当机的风险,学过一点计算机组成原理的,或是对计算机硬件稍有了解的朋友,应该都对内存的特性不陌生------断电清空内容。
有人抬杠说,我们Redis有RDB(Redis Database)和AOF(Append Only File)这样的持久化方案,何必害怕当机,数据存在文件里了。
这一点光就今天讨论的可用性来说,无可厚非。但是倘若我们在生产中,如在把redis作为社交app的缓存之类的场景下,一旦当机,redis进程反复请求I/O,系统效能必定下降(谁又希望在刷微博的时候等上30s呢?)。
因此,我们必须找到一个在性能与可用性之间兼得的方案。
什么是高可用?
John Carnell在《Spring Microservice In Action》中如此描述高可用:
需要能够支持 “热”集群环境,…可以跨多个节点共享。如果一个节点变得不可用,集群中的其他节点应该能够接管工作
从这句话中,可以窥见高可用性的概念无非三点:
- 热集群:实时更新同步热数据,每个节点内部的数据都不过时。
- 共享:集群内的信息互通有无,比如,一个节点当机,集群内其他节点应该都会收到消息。
- 接管工作:集群内节点当机(master)时,应该上一个替补(slave),并且这个替补能够完全接管当机节点之前的工作。
Redis的高可用
Redis作为一个成熟的,被广泛使用的分布式的,KV型的NoSQL产品,以上的特性自然是被很好地实现了,我们由