1. 集群方案
- 主从高可用(该方案就是单实例形式,只是为了保证数据的安全,对于用户数据少,业务的前期可以采用,目前我司缓存架构就是采用该方案)
- 客户端分片(典型代表:Jedis。自主写分片算法,代码掌握在自己手中,可控性强,但是需要专业的开发运维人员维护,技术要求和维护成本高)
- 代理分片(典型代表:Twemproxy,redis集群没有正式推出之前官网推荐的方案,也是目前使用最多的)
- Redis cluster(3版本推出的集群方案,历时四年之多的开发)
- Codis集群(豌豆荚15年开源的解决方案,开源之前其已经用了2年之多,与其同期官网推出redis cluster)
- 各大互联网公司自主研发的集群架构,但是还没有开源,可能也不会开源
2. codis架构
简单说明:
- codis-proxy提供连接集群redis的服务入口
- codis-config管理工具,支持包括添加/删除redis/proxy节点,发起数据迁移等操 作,自带一个dashboard工具,浏览器可以直观查看集群的运行状态
- codis-server-group实现redis读写的水平扩展、高性能
- codis-server实现redis实例服务,通过codis-ha实现服务的高可用
- Zookeeper/etcd存放数据路由表和codis-proxy节点的元信息,codis-config发起的命令通过其同步到各个存活的codis-proxy,则zookeeper如果出问题则可能导致数据不一致的情况或者严重的会对外提供服务造成影响
3. Twemproxy
简单说明:
- proxy提供分片算法和redis服务入口,支持高可用
- Redis提供实现实例,并且通过sentinel支持高可用
- Redis-Twemporxy提供通知底层HA切换至proxy
- 每个层结构出现问题或者变更节点信息等所有操作都需要重新规划分片算法,则需要重启服务
4. redis-cluster架构
简单说明:
- redis cluster本身集群方案,客户端可以任一连接一个节点
- redis-trib.rb脚本为集群的管理工具,比如自动添加节点,规划槽位,迁移数据等一系列操作(ruby语言)
- 每个节点都和N-1个节点通信,所以要维护好这个集群架构的每个节点信息,不然会导致整个集群不可工作