wayees的博客

reids cluster搭建，测试以及维护 在哨兵sentinel机制中，可以解决redis高可用的问题，即当master故障后可以自动将slave提升为master从而可以保证redis服务的正常使用，但是无法解决redis单机写入的瓶颈问题，即单机的redis写入性能受限于单机的内存大小、并发数量、网卡速率等因素，因此redis官方在redis 3.0版本之后推出了无中心架构的redis cluster机制，在无中心的redis集群当中，其每个节点保存当前节点数据和整个集群状态,每个节点都和其他所有节

redis 主从只能保证数据备份，引入哨兵实现高可用 哨兵的缺陷：redis哨兵机制还是建立在redis的一主多从上面，其实不能解决redis主服务器的压力（因为这种架构下master还是只有一个，master不但要进行replication，还要进行来自客户端的write，要解决这个问题就要使用redis cluster。 就拿一主两从来说，三个redis节点，至少需要三个sentinel（一个sentinel存在单点失败问题sentinel需要互相监控，两个sentinel存在脑裂问题），因此最少使用三

1.redis数据持久化（将内存中的数据fsync到磁盘中） **RDB**: save 900 1 save 300 10 save 60 10000 # Will save the DB if both the given number of seconds and the given # number of write operations against the DB occurred. # # In the example below the behaviour will be to