redis cluster 介绍

介绍

1. cluster的做用

（1）自动将数据进行分片，每一个master上放一部分数据 
（2）提供内置的高可用支持，部分master不可用时，仍是能够继续工做的

2. redis集群实现方案 

关于redis的集群化方案 目前有三种 
（1）Twitter开发的twemproxy
（2）豌豆荚开发的codis
（3）redis官方的redis-cluster
简介：

　　twemproxy架构简单 就是用proxy对后端redis server进行代理 可是因为代理层的消耗性能很低 并且一般涉及多个key的操做都是不支持的 并且自己不支持动态扩容和透明的数据迁移 并且也失去维护 Twitter内部已经不使用了
       redis-cluster是三个里性能最强大的 由于他使用去中心化的思想 使用hash slot方式 将16348个hash slot 覆盖到全部节点上 对于存储的每一个key值 使用CRC16(KEY)&16348=slot 获得他对应的hash slot 并在访问key时就去找他的hash slot在哪个节点上 而后由当前访问节点从实际被分配了这个hash slot的节点去取数据 节点之间使用轻量协议通讯 减小带宽占用 性能很高 自动实现负载均衡与高可用 自动实现failover  而且支持动态扩展 官方已经玩到能够1000个节点 实现的复杂度低 总之我的比较喜欢这个架构 由于他的去中心化思想免去了proxy的消耗 是全新的思路
       可是它也有一些不足 例如官方没有提供图形化管理工具 运维体验差 全手工数据迁移 而且本身对本身自己的redis命令支持也不彻底等 可是这些问题 我以为不能掩盖他关键的新思想所带来的的优点 随着官方的推动 这些问题应该都能在必定时间内获得解决 那么这时候去中心化思想带来的高性能就会表现出他巨大的优点 
       codis使用的也是proxy思路 可是作的比较好 是这两种之间的一个中间级 并且支持redis命令是最多的 有图形化GUI管理和监控工具 运维友好

   　redis cluster架构下，每一个redis要放开两个端口号，好比一个是6379，另一个就是加10000的端口号，好比16379，

16379端口号是用来进行节点间通讯的，也就是cluster bus的东西，集群总线。cluster bus的通讯，用来进行故障检测，配置更新，故障转移受权
cluster bus用了另一种二进制的协议，主要用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间。

3. 持久化的方案

由两种方式构成 aof & rdb
1). aof就像关系数据库中的binlog同样  把每一次写操做以追加的形式记录在其中以文件的形式刷到磁盘里 
而且可使用不一样的fsync策略     无fsync,每秒fsync,每次写的时候fsync.
使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求)
一旦出现故障，最多丢失1秒的数据.
可是缺点也随之而来 那就是aof文件的大小会随着时间线性增加 一段时间以后 就会变得很大 
若是要在一端以AOF的形式来恢复数据 那么因为AOF文件的巨大致积 可能会让进程如同假死同样 十分的慢
2). rdb则是一种快照机制 
redis工做在内存中 rdb就是每隔一段时间 对内存中的数据作一次快照  保存在rdb文件中 
并且redis的主从同步能够实现异步 也是因为rdb的机制 他在作快照时会fork出一个子进程 由子进程来作快照
父进程彻底处理请求 绝不影响 很适合数据的备份 
可是问题是 若是数据量很大的话 rdb它要保存一个完整的数据集 是一个大的工做 若是时间间隔设置的过短 
那么严重影响redis的性能 可是按照常规设置的话 如5分钟一次 那么若是宕机或者重启 就会基于上次作rdb的时间
从而丢失分钟级的数据

4.Redis Cluster分区

　　 Redis Cluster中有一个16384长度的槽的概念，他们的编号为0、一、二、3……1638二、16383。这个槽是一个虚拟的槽，并非真正存在的。正常工做的时候，Redis Cluster中的每一个Master节点都会负责一部分的槽，当有某个key被映射到某个Master负责的槽，那么这个Master负责为这个key提供服务，至于哪一个Master节点负责哪一个槽，这是能够由用户指定的，也能够在初始化的时候自动生成（redis-trib.rb脚本）。

键到slot的基本映射算法以下：　　

　　HASH_SLOT=CRC16(key)mod16384

通常采用三主三从的方式搭建集群。具体步骤见下篇文章。