搭建Redis试试看，换个存储方式，到底要搭几个才够用呢？

“搭建Redis试试看，换个存储方式，到底要搭几个才够用呢？”这个问题其实挺有意思的，它背后藏着从新手到老鸟都会遇到的一个实际困惑，咱们就抛开那些让人头疼的专业名词，像聊天一样来琢磨琢磨这事儿，这事儿没有标准答案，完全看你手头的事儿有多大，对数据有多在乎。

最开始的时候,你可能就是觉得程序跑得有点慢，听说Redis这个东西特别快，像个超速记本，能把经常要查的数据放在内存里，不用每次都去麻烦慢吞吞的数据库，这时候，你脑子里想的可能就是“搭一个试试看”。（来源：普遍的新手入门场景）你就找一台服务器，可能就是你开发用的那台电脑或者一个最普通的云服务器，下载Redis，改改配置文件里的绑定地址和密码，然后启动起来，接着在你的程序代码里，把原来直接连数据库的地方，改成先问问Redis有没有数据，没有再去找数据库，拿到数据后顺手塞一份到Redis里，设置个几分钟的过期时间，哎，你一测试，之前要等一秒的页面，嗖”一下就出来了，这个阶段，一个Redis实例完全够用，你的目标是验证效果，体验一下缓存带来的速度飞跃，你甚至会觉得，Redis不过如此嘛，很简单。

但很快,你可能就会遇到新问题，你发现服务器重启了一下，Redis里辛辛苦苦缓存的数据全没了，一些没那么重要但又希望它能持久存在的用户状态丢了，或者，你的应用访问量稍微大了一点，这个单枪匹马的Redis开始有点响应不过来，偶尔会超时，这时候你就得考虑“换个存储方式”了，其实是在给这个单一的Redis增加能力，为了解决重启数据丢失，你得配置持久化。（来源：Redis官方文档关于持久化的章节）简单说就是让Redis时不时地把内存里的数据写到硬盘上一个叫.rdb的文件里，或者更细致地记录每一个写操作命令到.aof文件里，这样即使重启，也能从文件里把数据恢复回来，这还只是在一个Redis实例上做文章。

当你的应用真的有很多人用了,问题会变得更复杂，你会发现这一台Redis服务器万一硬盘坏了，或者整个机器宕机了，你的整个应用就因为缓存失效而几乎瘫痪，这时候，“高可用”就成了必须考虑的事儿，你需要搭建主从复制。（来源：分布式系统常见的高可用方案）通俗讲，就是你再搞一台服务器，也装上Redis，让它当成“小弟”（从节点），时刻盯着“大哥”（主节点）的一举一动，主节点每写一个数据，从节点马上就跟着学一遍，这样，万一主节点宕机了，你手动（或者用工具自动）把一个小弟扶正成新大哥，你的应用就能继续运行，只是中间可能会有一小会儿卡顿，到这里，你至少需要两个Redis实例（一主一从）才能保证服务不那么容易彻底挂掉。

如果流量再上一个台阶,比如你要做一个全国性的活动，预计会有海量的数据和并发访问，这时候你可能会发现，即便是一主多从的架构，写压力全都在主节点这一个点上，它可能还是会扛不住，单台机器的内存总是有限的，不可能无限制地缓存所有数据，这时就要祭出终极武器——分片集群。（来源：应对大数据量和高并发的常见分布式架构）这个听起来有点唬人，但道理不难理解，就是把一大坨数据拆成很多小块，比如按用户ID的后几位数字拆，然后搭建多套主从Redis，比如三套（三个分片），每一套负责存储和管理其中一部分数据，这样，写压力和存储压力就分散到了三台主节点上，能同时处理的事情就多多了，要实现这个，你至少需要六个Redis实例（三个主节点，每个主节点至少配一个从节点，3主 + 3从 = 6实例），这已经是比较正式的生产环境架构了。

所以你看,回到最初的问题“到底要搭几个才够用呢？”，答案完全取决于你的“够用”标准是什么，如果只是个人学习、做个课程demo，一个就够了，如果是个小项目，希望服务别那么脆弱，能抗住一般的小故障，两个（主从）是起码的，如果是正经的、有一定用户量的线上业务，想要保证高可用和可扩展性，至少六个（分片集群）才算是个比较稳妥的起点，这就像一个升级打怪的过程，随着你的业务规模和要求的提高，你需要搭建的Redis实例数量和架构复杂度也会一步步提升，没有一步到位的完美方案，只有在当前阶段最合适的方案。