redis cluster搭建起来了

redis cluster，提供了多个master，数据可以分布式存储在多个master上; 每个master都带着slave，自动就做读写分离; 每个master如果故障，那么久会自动将slave切换成master，高可用

redis cluster的基本功能，来测试一下

1、实验多master写入 -> 海量数据的分布式存储

你在redis cluster写入数据的时候，其实是你可以将请求发送到任意一个master上去执行

但是，每个master都会计算这个key对应的CRC16值，然后对16384个hashslot取模，找到key对应的hashslot，找到hashslot对应的master

如果对应的master就在自己本地的话，set mykey1 v1，mykey1这个key对应的hashslot就在自己本地，那么自己就处理掉了

但是如果计算出来的hashslot在其他master上，那么就会给客户端返回一个moved error，告诉你，你得到哪个master上去执行这条写入的命令

什么叫做多master的写入，就是每条数据只能存在于一个master上，不同的master负责存储不同的数据，分布式的数据存储

100w条数据，5个master，每个master就负责存储20w条数据，分布式数据存储

大型的java系统架构，还专注在大数据系统架构，分布式，分布式存储，hadoop hdfs，分布式资源调度，hadoop yarn，分布式计算，hadoop mapreduce/hive

分布式的nosql数据库，hbase，分布式的协调，zookeeper，分布式通用计算引擎，spark，分布式的实时计算引擎，storm

如果你要处理海量数据，就涉及到了一个名词，叫做大数据，只要涉及到大数据，那么其实就会涉及到分布式

redis cluster，分布式

因为我来讲java系统的架构，有时候跟其他人不一样，纯搞java，但是我因为工作时间很长，早期专注做java架构，好多年，大数据兴起，就一直专注大数据系统架构

大数据相关的系统，也涉及很多的java系统架构，高并发、高可用、高性能、可扩展、分布式系统

会给大家稍微拓展一下知识面，从不同的角度去讲解一块知识

redis，高并发、高性能、每日上亿流量的大型电商网站的商品详情页系统的缓存架构，来讲解的，redis是作为大规模缓存架构中的底层的核心存储的支持

高并发、高性能、每日上亿流量，redis持久化 -> 灾难的时候，做数据恢复，复制 -> 读写分离，扩容slave，支撑更高的读吞吐，redis怎么支撑读QPS超过10万，几十万; 哨兵，在redis主从，一主多从，怎么保证99.99%可用性; redis cluster，海量数据

java架构课，架构思路和设计是很重要的，但是另外一点，我希望能够带着大家用真正java架构师的角度去看待一些技术，而不是仅仅停留在技术的一些细节的点

给大家从一些大数据的角度，去分析一下我们java架构领域中的一些技术

天下武功，都出自一脉，研究过各种大数据的系统，redis cluster讲解了很多原理，跟elasticsearch，很多底层的分布式原理，都是类似的

redis AOF，fsync

elasticsearch建立索引的时候，先写内存缓存，每秒钟把数据刷入os cache，接下来再每隔一定时间fsync到磁盘上去

redis cluster，写可以到任意master，任意master计算key的hashslot以后，告诉client，重定向，路由到其他mater去执行，分布式存储的一个经典的做法

elasticsearch，建立索引的时候，也会根据doc id/routing value，做路由，路由到某个其他节点，重定向到其他节点去执行

分布式的一些，hadoop，spark，storm里面很多核心的思想都是类似的

后面，马上把redis架构给讲完之后，就开始讲解业务系统的开发，包括高并发的商品详情页系统的大型的缓存架构，jedis cluster相关api去封装和测试对redis cluster的访问

jedis cluster api，就可以自动针对多个master进行写入和读取

2、实验不同master各自的slave读取 -> 读写分离

在这个redis cluster中，如果你要在slave读取数据，那么需要带上readonly指令，get mykey1

redis-cli -c启动，就会自动进行各种底层的重定向的操作

实验redis cluster的读写分离的时候，会发现有一定的限制性，默认情况下，redis cluster的核心的理念，主要是用slave做高可用的，每个master挂一两个slave，主要是做数据的热备，还有master故障时的主备切换，实现高可用的

redis cluster默认是不支持slave节点读或者写的，跟我们手动基于replication搭建的主从架构不一样的

slave node，readonly，get，这个时候才能在slave node进行读取

redis cluster，主从架构是出来，读写分离，复杂了点，也可以做，jedis客户端，对redis cluster的读写分离支持不太好的

默认的话就是读和写都到master上去执行的

如果你要让最流行的jedis做redis cluster的读写分离的访问，那可能还得自己修改一点jedis的源码，成本比较高

要不然你就是自己基于jedis，封装一下，自己做一个redis cluster的读写分离的访问api

核心的思路，就是说，redis cluster的时候，就没有所谓的读写分离的概念了

读写分离，是为了什么，主要是因为要建立一主多从的架构，才能横向任意扩展slave node去支撑更大的读吞吐量

redis cluster的架构下，实际上本身master就是可以任意扩展的，你如果要支撑更大的读吞吐量，或者写吞吐量，或者数据量，都可以直接对master进行横向扩展就可以了

也可以实现支撑更高的读吞吐的效果

不会去跟大家直接讲解的，很多东西都要带着一些疑问，未知，实际经过一些实验和操作之后，让你体会的更加深刻一些

redis cluster，主从架构，读写分离，没说错，没有撒谎

redis cluster，不太好，server层面，jedis client层面，对master做扩容，所以说扩容master，跟之前扩容slave，效果是一样的

3、实验自动故障切换 -> 高可用性

redis-trib.rb check 192.168.31.187:7001

比如把master1，187:7001，杀掉，看看它对应的19:7004能不能自动切换成master，可以自动切换

切换成master后的19:7004，可以直接读取数据

再试着把187:7001给重新启动，恢复过来，自动作为slave挂载到了19:7004上面去