Redis自带的原生集群真的挺靠谱，效率高又简单，用起来蛮顺手的

基于个人及团队在多个中小型互联网项目中的实际使用经验,项目类型包括电商秒杀、实时消息推送和会话缓存等。）

说实话,刚开始接触Redis集群的时候，心里是有点打鼓的，毕竟一提到“集群”、“分布式”这些词，脑子里浮现的就是一堆复杂无比的配置、各种协调和可能出现的诡异问题，我们当时也考虑过用第三方的主从代理方案，比如Codis之类的，但后来决定先试试Redis官方自带的这个集群模式（Redis Cluster），没想到这一用，还真就离不开了，给我的感觉就是，它把复杂的东西给封装起来了，暴露给开发和使用者的是一个相对简单、直接的界面。

先说它怎么个“简单”法。 这个简单，不是说它功能弱，而是指上手和运维的复杂度比预想中低很多，搭建一个最小化的集群，只需要改几行配置文件，然后用Redis自带的命令行工具 redis-trib.rb（新版本是 redis-cli --cluster create）跑一下，三下五除二，一个包含三个主节点和三个从节点的集群就起来了，它自动帮你把16384个哈希槽（slots）平均分配好了，完全不用你操心数据该怎么分片，对于我们这种不是专门做基础设施运维的团队来说，这简直是福音，你不需要去理解特别深奥的一致性哈希算法，Redis Cluster自己内部就帮你把数据该放在哪个节点上管理得明明白白，客户端连接的时候，只需要知道任意一个节点的地址就行，哪怕这个节点宕机了，客户端库一般也有机制去尝试连接其他节点获取最新的集群信息，这种“开箱即用”的体验，让部署环节非常顺畅。

再来说说“效率高”。 这一点在我们做电商秒杀活动时感受特别明显，Redis Cluster的核心优势在于，它的数据是分片存储在不同节点上的，这意味着写压力和存储压力也被分摊了，我们有大量的商品库存信息需要频繁扣减，如果只用单个Redis实例，所有的请求都怼在一个节点上，网络带宽、CPU和内存很快会成为瓶颈，但用了集群之后，不同的商品Key根据哈希计算会被分布到不同的主节点上，相当于有好几个Redis在同时干活，整体的吞吐量自然就上去了，它的性能损耗很小，客户端在拿到集群的槽位映射信息后，会直接请求正确的数据节点，大多数情况下不需要代理中转，等于是直连，延迟和单机Redis几乎没什么差别，只有在客户端缓存的路由信息过期或者遇到跨槽位命令需要重定向（比如MGET多个不在同一个节点的key）时，才会多一次跳转，但这种场景在我们规范使用的情况下并不多。

最后也是最重要的，挺靠谱”。 靠谱主要体现在它的高可用性上，我们配置的每个主节点都挂了一个从节点，有一次，一台物理机突然宕机，上面跑的一个Redis主节点自然也就挂了，当时我们还挺紧张，准备手动干预，结果监控报警刚响没多久，我们就发现，集群已经自动完成了故障转移：那个挂掉的主节点对应的从节点，被提升为了新的主节点，整个过程也就十几秒钟，整个服务除了在故障转移的那一瞬间有极少数请求可能超时了一下，几乎没有受到任何影响，等我们修好那台机器，把新的Redis实例作为从节点重新加入集群，它又自动地从新的主节点那里同步数据，恢复了正常，这种自我修复能力，大大减少了我们半夜被叫起来处理故障的次数，让人非常安心。

它也不是完全没有缺点,它不支持跨多个key的事务（因为key可能分布在不同的节点上），对于一些复杂的数据结构操作也有限制，但这些问题，通过我们在设计数据模型和业务逻辑时稍微注意一下，比如使用哈希标签（hashtag）来确保有关联的key落在同一个节点上，就基本可以规避，权衡下来，这些小小的不便，相对于它带来的高性能、高可用和易于维护的优势来说，是完全值得的。

Redis自带的这个集群,就像是一个朴实能干的好帮手，它没有那么多花里胡哨的概念，而是用非常务实的方式解决了数据分片和高可用的问题，只要你遵循它的规则，不在它不擅长的地方较劲，它就能给你提供稳定、高效的服务，用久了之后，那种“顺手”的感觉会越来越强，你会觉得数据库这一层很稳固，可以让你更专注于业务逻辑的开发，如果业务发展到单机Redis无法承受，需要走向分布式时，Redis Cluster绝对是一个值得优先考虑的、非常靠谱的选择。