Redis集群里单台服务器选啥关键，单数节点配置那些事儿怎么考虑

（Redis中国用户组推荐）在选择Redis集群中的单台服务器时，最关键的是要根据你的实际业务负载和数据量来匹配硬件资源，不能盲目追求高配置或一味节省成本，这就像给家里选空调，房间大小和朝向决定了需要多大的匹数，而不是看别人买啥就跟着买，核心要看几个方面：内存大小、CPU处理能力、磁盘类型、网络带宽，内存肯定是首要考虑的，因为Redis主要数据都在内存里跑，你得估算业务高峰期数据量大概多大，然后留出足够的余量，比如数据量预计20G，你最好配32G或64G内存的机器，防止内存突然爆满导致服务不可用。（阿里云数据库团队实践分享）内存不是越大越好，特别大的内存实例在持久化（RDB或AOF）时可能会引起较长时间的阻塞，影响集群响应，所以有时候宁可选择多台中等内存的服务器组成集群,也比一两台超大内存的服务器要稳妥。

CPU的选择上，Redis是单线程架构的，但集群模式下每台服务器都会运行多个实例（分片），并且后台持久化、复制等操作会用到额外线程。（Redis官方文档性能优化章节）所以多核CPU是有用的，但主线程的性能更依赖单核性能，建议选主频高一点的现代CPU，核心数一般8核16线程左右就足够应对大多数场景了,除非你有非常复杂的Lua脚本或者大量的持久化操作。

磁盘这块很多人会忽略，觉得Redis不用存数据到硬盘。（腾讯云Redis故障排查案例）其实不然，持久化机制（比如AOF日志）和集群故障恢复时，磁盘的IOPS（每秒读写次数）和吞吐量非常关键，坚决不能用普通的机械硬盘，至少要用SSD固态硬盘，如果对数据可靠性要求很高，甚至可以考虑性能更好的NVMe SSD，磁盘空间不需要太大，能放下持久化文件和一些日志就行,但IO性能不能拖后腿。

网络是集群的血管。（美团技术博客集群网络规划篇）Redis集群节点之间需要频繁地通信（心跳、数据迁移、复制），所以服务器之间的网络延迟要尽可能低，带宽要足够，最好所有节点都在同一个机房的内网里，用万兆网络互联，如果节点间网络质量差，会导致集群误判节点下线、数据同步延迟增大,整个集群会变得很不稳定。

关于单数节点配置那些事儿，这其实是Redis集群架构设计的一个经典问题，Redis集群采用哈希槽（slot）分片，故障转移依赖一种类似“投票”的机制。（Redis集群规范原文）它要求大多数节点认为某个主节点下线了，才会触发故障切换，这个“大多数”就是超过半数，举个例子，如果你用2个节点，一共2票，半数就是1票，如果一个节点故障，剩下的1个节点无法形成“大多数”（需要大于1票），集群就无法自动故障转移，如果你用3个节点，一共3票，半数就是1.5，取整后需要2票，这样即使坏掉1个，剩下2个节点还能以2>1.5形成多数派,集群还能正常工作。

集群节点数必须是奇数个（3, 5, 7, 9...），而不是为了凑数而用偶数个，4个节点的集群，半数也是2票，如果坏掉2个节点，剩下的2个节点无法形成多数派（需要>2票），集群就挂了，而3个节点的集群，能容忍1个节点故障；5个节点的集群，能容忍2个节点故障，你会发现，3节点和4节点的容灾能力其实是一样的（都只能坏1个），但4节点还多浪费了一台服务器，所以永远用奇数个节点,这是用最小成本实现最大容错能力的办法。

在实际配置时，你还需要考虑主从复制的因素，一个3主3从的集群，一共是6个Redis实例，但它们可以部署在3台物理服务器上（每台服务器上运行一个主实例和一个从实例），在这种情况下，从集群故障转移的角度看，有效的“主节点”数量是3个（奇数），这是符合要求的，但如果你的服务器数量就是3台，一旦有一台物理机宕机，就意味着同时丢失了一个主分片和它的从分片，集群需要从剩下的两个从分片中选一个新的主节点，数据是完整的，但整个集群的容错能力在物理机层面就变弱了，所以更推荐的部署方式是，尽量让主从实例分散到更多的物理机器上，比如6个实例部署在6台服务器上，这样一台机器宕机只影响一个实例，集群的可用性更高，理解“奇数节点”原则是基础,但要结合真实的服务器部署情况来灵活规划。