19. 【实战】测试redis cluster多master写入、读写分离、高可用性

目录介绍测试redis cluster测试多master写入 -> 支撑海量数据的分布式存储测试不同master各自的slave读取 -> 读写分离测试主备自动故障切换 -> 高可用性思想redis cluster去掉主从架构，读写分离扩展思想--如何学习技术 介绍 redis cluster，提供了多个master，数据可以分布式存储在多个master； 每个master都带着slave，自动就做读写分离； 每个master如果故障，自动将slave切换成master，高可用

下面测试redis cluster的基本功能

测试redis cluster 测试多master写入 -> 支撑海量数据的分布式存储

数据分别存储不同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条数据，分布式数据存储

大数据系统架构，分布式存储hadoop hdfs，分布式资源调度hadoop yarn，分布式计算hadoop mapreduce/hive，分布式nosql数据库hbase，分布式的协调zookeeper，分布式通用计算引擎spark，分布式的实时计算引擎storm

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

测试不同master各自的slave读取 -> 读写分离 在这个redis cluster中，如果你要在slave读取数据，那么需要带上readonly指令，get mykey1。
redis-cli -c启动，就会自动进行各种底层的重定向的操作 redis-cli -h 192.168.0.106 -p 7001 -c

测试主备自动故障切换 -> 高可用性

查看状态：redis-trib.rb check 192.168.0.106:7001

把master1，192.168.0.106:7001，kill掉，看看它对应的slave node 192.168.0.107:7004能不能自动切换成master

可以看到192.168.0.107:7004切换成master成功，也没有slave node了，

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

思想 redis cluster去掉主从架构，读写分离 实验redis cluster的读写分离的时候，会发现有一定的限制性，默认情况下，redis cluster的核心，主要是用slave做高可用的；

每个master挂一两个slave，做数据的热备，还有master故障时的主备切换，实现高可用的

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

需要在slave node上，指令readonly，get 相应的key，这个时候才能在slave node进行读取

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

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

如果你要让最流行的jedis做redis cluster的读写分离的访问，那可能需要自己基于jedis封装，自己做一个redis cluster的读写分离的访问api

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

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

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

redis cluster谈主从架构，读写分离，没说错

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

扩展思想–如何学习技术

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

学习redis高并发、高性能，通过实战【每日上亿流量的大型电商网站的商品详情页系统的缓存架构】，学习redis作为大规模缓存架构中的底层的核心存储的支持。

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

架构思路和设计是很重要的，能够用真正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里面很多核心的思想都是类似的
作者：咸鱼也歌

读写分离 cluster 实战 高可用 可用性 master Redis