redis_tips
认知
集群：解决数据量大，请求量大，实例水平扩展的问题（一般对key进行hash，分散数据）
容灾：主从+哨兵 同城多活（或冷备） 异地多活等
路径
为了保证redis高可用，主要有一下几个方面：
-
数据持久化
数据备份，宕机时可以从磁盘恢复，恢复之前服务不可用
-
主从复制
部署多个副本节点，实时复制主节点数据，当主宕机，有完整副本可用
副本节点分担读请求，实现读写分离
-
自动故障恢复
主节点宕机，手动操作把从节点提升为主节点继续提供服务，耗时耗力也无法保证及时性，需要故障自动恢复机制，主节点故障时，自动把从节点提上来，无需人工干预，提升服务可用性，redis通过哨兵实现故障自动恢复
-
集群化
当读写数据量都很大，单个主节点无法承受大量写，这时需要集群化
多个主节点构成一个集群，每个节点存储一部分数据，写请求可以分散到多个主节点
在容量不足或者新能不够的时候可以动态扩容
集群化方案
1.代理方案（服务端分片）
1.1Codis
客户端和服务端增加一个代理层，在代理层实现请求转发，转发到后面的多个redis节点上
功能比较齐全，除了请求转发，还是先了在线数据迁移、节点扩容缩容、故障自动恢复等
集群划分为1024个槽位，采用crc32hash算法计算key的hash值，对1024取模找到具体的redis节点
codis基于redis的3.2.8版本作了二次开发，目前已停更，无法升级redis版本
有些命令如keys不支持
1.2Twemproxy
twitter开源方案，可以作redis和memcached的proxy
功能单一，只实现请求路由转发（客户端分片逻辑放到了proxy层），没有其他功能
2.直接方案（客户端分片）
2.1客户端分片
客户端采用hash或者一致性hash算法，把相应的key写到指定的redis里
2.2Redis Cluster
必须使用smart client，请求转发的逻辑放在了smart client中，采用16385个槽位进行路由规则的转发
同时提供在线数据迁移，节点扩容缩容等功能，内置了哨兵完成故障自动恢复
文章内容来自于：Redis集群化方案对比：Codis、Twemproxy、Redis Cluster | Kaito's Blog