持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第27天，点击查看活动详情
🍊作者简介：少年不想说话，努力长大
🍊往期回顾：从零开始Redis（十六）
🍊近期目标：写完基础源码，点赞👍🏼、收藏⭐、留言📩
我们知道前面说的主从复制的基本思想了，由于我们的主节点要处理主从数据的同步，又要处理数据的请求，对于大型项目而言，主节点随时会堵住甚至崩掉所以我们必须分流；
我们可以使用分布式的方法用不同的请求地址取不同分区的数据实现，或者主题所说的读写分离。比如阿里云推出的我没见过的为满足读多写少的业务场景，最大化节约用户成本，云数据库Redis版推出了proxy中间件读写分离规格，为用户提供透明、高可用、高性能、高灵活的读写分离服务；其实对于redis的读写分离是存在一定争议；至于阿里推出的我也不敢说好或不好；我在网上找了下说redis默认master用于写，slave用于读，向slave写数据会报错，也就是说redis默认读写分离（如果这样阿里的产品是？）；我不清楚实际项目里是不是这样，如果这样的话我如果就想要读取主机的数据咋办呢（说改权重可以）或者其他某些文章说的可以客户端指定？还望大佬们赐教！
为什么说它存在争议呢？我总结一下大佬们的意思，就是读写分离目的是为缓解读场景和写场景这两个场景的互斥锁. 读写分离后读和写可以并发操作，如果读远超过写场景且读可以接收数据的暂时非一致性那么读写分离有很大使用价值；首先了解下我们这里要的分布式是将所有数据分区分片存放，对于redis的单个主数据库向多个从属数据库发送写操作并不少见，从属数据库执行所有读取查询。Redis采用了这种复制方法来帮助扩展；首先我们的redis是单线程的，不管多少请求进来都是一个一个执行，不存在并发的可能性，自然的也就没有了互斥锁的概念，好像有那么点道理，对于大量请求直接分布式部署读取不同的机器，它不像mysql那样读的时候会受限于行锁表锁等等锁，不会一个请求要很长的时间去取数据；
这里我只是提了一个网上看到的一点小想法，拓宽一下思路，不够成熟吧，我们项目对redis的要求也不是很强制，一般都是默认，所以接触也不深，反正读写分离个人觉得没必要了，我被我自己打动了，主机写，读就随便了；如果redis真的自带，那也再好不过了，如果用分布式部署的话，不同节点存储不同内容，也挺麻烦（不过这样就有了强一致性了）；直接主从+哨兵就这样吧用redis很少要求强一致了，需要就换个方式存储这些强一致数据，下讲我们说说哨兵，好啦🥗🥗🥗；
结束结束，那就🛴🛴🛴
如果对你有所帮助
点个赞呗
