常用Redis的几种使用方法包括：单副本Redis单副本采用单Redis节点部署架构。没有备份节点实时同步数据，没有提供数据持久化和备份策略。适用于对数据可靠性要求不高的纯缓存业务场景。优点：架构简单，易于部署。性价比高：不需要备节点做缓存（单实例可用性可以通过supervisor或crontab来保证）。当然，为了满足业务的高可用，也可以牺牲一个备节点，但同时只有一个实例对外提供服务。高性能。缺点：数据可靠性无法保证。使用缓存并重启进程后，数据丢失。即使有备用节点解决高可用，也无法解决缓存预热问题，不适合对数据可靠性要求高的业务。高性能受限于单核CPU的处理能力（Redis是单线程机制），CPU是主要瓶颈，适合操作命令简单、排序少、计算量少的场景。您也可以考虑改用Memcached。Redis多副本（master-slave）Redis多副本采用主从（replication）部署结构。与单副本相比，最大的特点是主从实例之间的数据实时同步，并提供数据持久化和备份策略。主从实例部署在不同的物理服务器上。根据公司基础环境配置，可同时对外提供服务和读写分离策略。优点：可靠性高：一方面采用双机主备架构，当主库出现故障时可以自动切换主备，并推动从库为主库提供服务，保证服务的顺利运行；另一方面，启用数据持久化优化功能和合理的备份策略，可以有效解决数据误操作和数据异常丢失的问题。读写分离策略：从节点可以扩展主库节点的读能力，有效应对大并发读操作。缺点：故障恢复复杂。如果没有RedisHA系统（需要开发），当主库节点出现故障时，需要手动提升一个从节点为主节点。同时需要通知业务方更改配置，需要让其他从库节点转为主节点。整个复制新主库节点的过程需要人工干预，比较繁琐。主库写入能力受限于单机，可以考虑分片。主库存储容量受限于单机，可以考虑Pika。nativereplication的缺点在早期版本中也会更加突出。比如Redis复制中断后，slave会发起psync。或二级冻结。并且由于COW机制，极端情况下主库内存溢出，程序异常退出或崩溃；主库节点生成的备份文件导致服务器磁盘IO和CPU（压缩）资源的消耗；发送几千兆的备份文件，导致服务器出口带宽激增，请求受阻。建议升级到最新版本。Redis哨兵（Sentinel）Redis哨兵是社区版推出的原生高可用解决方案。其部署架构主要包括两部分：RedisSentinel集群和Redis数据集群。其中，RedisSentinel集群是由多个Sentinel节点组成的分布式集群，可以实现故障发现、故障自动转移、配置中心和客户端通知。RedisSentinel的节点数要满足2n+1的奇数（n>=1）。优点：RedisSentinel集群部署简单；可以解决Redis主从模式下的高可用切换问题；非常方便的实现Redis数据节点的线性扩展，轻松突破Redis自身的单线程瓶颈，可以极大的满足大容量或者高性能的Redis业务需求；可以实现一套Sentinel来监控一组Redis数据节点或者多组数据节点。缺点：相比Redis主从模式，部署更复杂，原理理解更繁琐；资源浪费，Redis数据节点中的slave节点作为备份节点，不提供服务；RedisSentinel主要是针对Redis数据节点中master节点的高可用切换，Redis数据节点的故障判断有两种：主观下线和客观下线。对于Redis从节点，对节点进行主观下线操作，不进行故障转移。不能解决读写分离的问题，实现起来也比较复杂。建议：如果要监控同一个业务，可以选择Sentinel集群监控多组Redis数据节点，或者选择Sentinel方案监控一组Redis数据节点。sentinelmonitor建议将配置中的设置为Sentinel节点的一半加1。当Sentinel部署在多个IDC时，部署的Sentinel数量不建议由单个IDC超过（哨兵数量-法定人数）。合理设置参数，防止误切，控制开关灵敏度控制：a．法定人数。毫秒后下降30000c.故障转移超时180000d。最大客户。Redis推荐使用pipeline和multi-key操作来减少RTT时间，提高请求效率。自行获取配置中心（zookeeper），方便客户端链接访问实例。RedisClusterRedisCluster是社区版推出的Redis分布式集群解决方案。主要解决Redis分布式方面的需求。比如在遇到单机内存、并发、流量等瓶颈时，RedisCluster可以起到很好的负载均衡。的目标。RedisCluster集群节点最低配置6个节点以上（3主3从）。主节点提供读写操作，从节点作为备份节点。它不提供请求，仅用于故障转移。RedisCluster使用虚拟槽分区。根据哈希函数，所有键都映射到0到16383整数槽。每个节点负责维护一部分槽位和映射到槽位的key-value数据。优点：无中心架构；数据按槽位分布在多个节点存储，节点间数据共享，数据分布可动态调整；可扩展性：线性扩展到1000个以上节点，节点可以动态添加或删除；高可用：当部分节点不可用时，集群仍然可用。通过添加Slave作为备用数据副本，可以实现故障自动转移，节点间通过gossip协议交换状态信息，利用投票机制完成从Slave到Master的角色提升；降低运维成本，提高系统的可扩展性和可用性。缺点：Client实现复杂，驱动需要SmartClient实现，slot映射信息缓存更新及时，增加开发难度，客户端不成熟影响稳定性商业。目前只有JedisCluster比较成熟，异常处理部分还不完善，比如常见的“maxredirectexception”。节点会因为某种原因被阻塞（阻塞时间大于clutser-node-timeout），判断为下线。这种故障转移是不必要的。数据是异步复制的，不保证数据的强一致性。当多个业务使用同一套集群时，无法通过统计区分冷热数据，资源隔离性差，容易相互影响。Slave在集群中充当“冷备”，无法缓解读取压力。当然，通过SDK的合理设计，可以提高Slave资源的利用率。Key批量操作限制，比如使用mset和mget目前只支持批量操作相同槽值的Key。对于映射到不同slot值的Keys，由于Keys不支持跨slot查询，所以进行mset、mget、sunion等操作并不友好。对Key事务操作的支持是有限的。只支持同一节点上多个key的事务操作。当多个key分布在不同节点时，交易功能无法使用。Key是数据分区的最小粒度，hash、list等大的key-value对象不能映射到不同的节点。不支持多个数据库空间，单机下的redis最多可以支持16个数据库，集群模式下只能使用一个数据库空间，即db0。复制结构只支持一层，从节点只能复制主节点，不支持嵌套树复制结构。避免产生热键，导致主库节点成为系统的短板。避免产生big-key，造成网卡爆裂、查询慢等问题。重试时间要大于cluster-node-time时间。RedisCluster不推荐使用pipeline和multi-key操作来减少maxredirect产生的场景。Redis自研Redis自研高可用解决方案主要体现在配置中心、故障检测和故障转移处理机制上，通常需要根据企业业务的实际线上环境进行定制。优点：高可靠、高可用；自主可控性高；满足业务实际需求，具有良好的扩展性和兼容性。缺点：实现复杂，开发成本高；需要建立配套的外围设施，如监控、域名服务、存储元数据信息的数据库等；维护成本高。作者：张东红作者简介：极数云舟数据库架构师，极数学院联合创始人，前新浪微博高级DBA，Redis中国用户群主席，阿里云MVP。
