redis集群 官方方案redis-cluster搭建实战

1.为什么使用redis？

redis是一种典型的no-sql 即非关系数据库 像python的字典一样 存储key-value键值对 工作在memory中

所以很适合用来充当整个互联网架构中各级之间的cache 比如lvs的4层转发层 nginx的7层代理层

尤其是lnmp架构应用层如php-fpm或者是Tomcat到mysql之间 做一个cache 以减轻db的压力

因为有相当一部分的数据 只是简单的key-value对应关系，而且在实际的业务中常常在短时间内迅速变动 

如果用关系数据库mysql之类存储 会大大增加对db的访问 导致db的负担很重 因为所有的require中的大部分最后都要汇聚到db

所以如果想要业务稳定 那么解决db的压力 就是关键 所以现在大部分的解决方案就是在db层之上的各级使用多级的no-sql 

像memcache redis 等 来为db提供缓冲  

2.为什么使用redis-cluster？

为了在大流量访问下提供稳定的业务，集群化是存储的必然形态

未来的发展趋势肯定是云计算和大数据的紧密结合 只有分布式架构能满足要求

如果没有集群化 何来的分布式？

3.顺带一提总结一波今天的redis原理之数据持久化

虽然redis这种no-sql一般都是作为cache来服务  但是如果完全没有数据可持久化的方法 那么显得有些单薄

就像memcache 由于这种no-sql是工作在memory的 那么由于memory的实体是ram

所以如果重启或者宕机 memory中的数据就全没了 数据的一致性的不到保障 

但是 redis不同 redis有相对的数据持久化的方案 由两种方式构成 aof & rdb

aof就像关系数据库中的binlog一样  把每一次写操作以追加的形式记录在其中以文件的形式刷到磁盘里 

并且可以使用不同的fsync策略     无fsync,每秒fsync,每次写的时候fsync.

使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求)

一旦出现故障，最多丢失1秒的数据.

但是缺点也随之而来 那就是aof文件的大小会随着时间线性增长 一段时间之后 就会变得很大 

如果要在一端以AOF的形式来恢复数据 那么由于AOF文件的巨大体积 可能会让进程如同假死一样 十分的慢

rdb则是一种快照机制 

redis工作在内存中 rdb就是每隔一段时间 对内存中的数据做一次快照  保存在rdb文件中 

而且redis的主从同步可以实现异步 也是由于rdb的机制 他在做快照时会fork出一个子进程 由子进程来做快照

父进程完全处理请求 毫不影响 很适合数据的备份 

但是问题是 如果数据量很大的话 rdb它要保存一个完整