系统怎么配置读写分离

❶ Redis早期的主从架构原理分析，早期如何实现读写分离的

基于主从复制架构，实现读写分离，redis slave node节点只读，默认开启配置：slave-read-only yes。开启了只读的节点redis slave node，会拒绝所有写操作，这样可以强制搭建成读写分离的架构。

（1）redis采用异步方式复制数据到slave节点。

（2）一个master node是可以配置多个slave node的。

（3）slave node也可以连接其他的slave node。

（4）slave node做复制的时候，是不会block master node的正常工作的。

（5）slave node在做复制的时候，也不会block对自己的查询操作，它会用旧的数据集来提供服务; 但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务了。

（6）slave node主要用来进行横向扩容，做读写分离，扩容的slave node可以提高读的吞吐量。

如果采用了主从架构，那么建议必须开启master node的持久化！不建议用slave node作为master node的数据热备，因为那样的话，如果你关掉master的持久化，可能在master宕机重启的时候数据是空的，然后可能一经过复制，salve node数据也丢了。

（1）当启动一个slave node的时候，它会发送一个 PSYNC 命令给master node。

（2）如果这是slave node 重新连接 master node，那么master node仅仅会 复制给slave部分缺少的数据 ，否则如果是slave node 第一次连接 master node，那么会触发一次 full resynchronization ，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令 缓存在内存中 。RDB文件生成完毕之后，master会先将这个RDB发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中 缓存的写命令 发送给slave，slave也会同步这些数据。

（3）slave node如果跟master node有网络故障，断开了连接，会自动重连。master如果发现有多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node。

从redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制。master node会在内存中建一个 backlog ，master和slave都会保存一个 replica offset 还有一个 master id（run id） ，offset就是保存在backlog中的。如果master和slave网络连接断掉了，slave会让master从上次的replica offset开始继续复制，但是如果没有找到对应的offset，那么就会执行一次full resynchronization全量同步。

master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了。

repl-diskless-sync no 改为开启就可以了

repl-diskless-sync-delay，等待一定时长再开始复制，因为要等更多slave重新连接过来，用一分数据提供服务。

slave node不会过期key，只会等待master过期key。如果master过期了一个key，或者通过LRU淘汰了一个key，那么会模拟一条del命令发送给slave。

（1）slave node启动，仅仅保存master node的信息，包括master node的host和ip，但是复制流程没开始。master host和ip是从哪儿来的？redis.conf里面的slaveof配置的。

（2）slave node内部有个定时任务，每秒检查是否有新的master node要连接和复制，如果发现，就跟master node建立socket网络连接。

（3）slave node发送ping命令给master node。

（4）口令认证，如果master设置了requirepass（master上启用安全认证配置，requirepass 自己取名 ），那么salve node必须发送masterauth的口令过去进行认证（masterauth 自己取名 ）

（5）master node第一次执行全量复制，将所有数据发给slave node。

（6）master node后续持续将写命令，增量异步复制给slave node。

指的就是第一次slave连接msater的时候，执行的全量复制，这个过程里面的一些细节的机制

（1）master和slave都会维护一个offset

master会在自身不断累加offset，slave也会在自身不断累加offset。slave每秒都会上报自己的offset给master，同时master也会保存每个slave的offset。这个倒不是说特定就用在全量复制的，主要是master和slave都要知道各自的数据的offset，才能知道互相之间的数据不一致的情况。

（2）backlog

master node有一个backlog，默认是1MB大小，master node给slave node复制数据时，也会将数据在backlog中同步写一份。backlog主要是用来做全量复制中断后的增量复制的。

（3）master run id

info server命令，可以看到master run id。如果根据host+ip定位master node，是不靠谱的，如果master node重启或者数据出现了变化，那么slave node应该根据不同的run id区分，run id不同就做全量复制。如果需要不更改run id重启redis，可以使用redis-cli debug reload命令。

（4）psync

从节点使用psync从master node进行复制psync runid offset。master node会根据自身的情况返回响应信息，可能是FULLRESYNC runid offset触发全量复制，可能是继续触发增量复制。

（1）master执行bgsave，在本地生成一份rdb快照文件。

（2）master node将rdb快照文件发送给salve node，如果rdb复制时间超过60秒（repl-timeout），那么slave node就会认为复制失败，可以适当调节大这个参数。

（3）对于千兆网卡的机器，一般每秒传输100MB，6G文件，很可能超过60s。

（4）master node在生成rdb时，会将所有新的写命令缓存在内存中，在salve node保存了rdb之后，再将新的写命令复制给salve node。

（5）client-output-buffer-limit slave 256MB 64MB 60，如果在复制期间，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，或复制时间超过60秒，那么停止复制，复制失败。

（6）slave node接收到rdb之后，然后重新加载rdb到自己的内存中，同时基于旧的数据版本对外提供服务，写入后，清空自己的旧数据，用新的对外提供读服务。

（7）如果slave node开启了AOF，那么会立即执行BGREWRITEAOF，重写AOF。在这个过程中，rdb生成、rdb通过网络拷贝、slave旧数据的清理、slave node aof rewrite，很耗费时间的。

（1）如果全量复制过程中，master-slave网络连接断掉，那么salve重新连接master时，会触发增量复制。

（2）master直接从自己的backlog中获取部分丢失的数据，发送给slave node，默认backlog就是1MB。

（3）master就是根据slave发送的psync中的offset来从backlog中获取数据的。

下节讲解哨兵架构，在讲之前，你能否处理下面两个问题呢？

1、异步复制导致的数据丢失

哨兵可以解决主从架构下，因master宕机后不能接收写请求而进行选举salve为新的master，达到高可用的效果。

因为master -> slave的复制是异步的，所以可能有部分数据还没复制到slave，master就宕机了，此时这些部分数据就丢失了，此时应该怎么处理？

2、脑裂导致的数据丢失

脑裂，也就是说，某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着。

此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master这个时候，集群里就会有两个master，也就是所谓的脑裂。

此时虽然某个slave被切换成了master，但是可能client还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了，因此旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据，导致数据丢失，怎么处理脑裂导致的数据丢失呢？

先考虑一下，我们下节进行讲解。

❷ 怎么实现读写分离

为了确保数据库产品的稳定性，很多数据库拥有双机热备功能。也就是，第一台数据库服务器，是对外提供增删改业务的生产服务器；第二台数据库服务器，主要进行读的操作。·
读写分离（Read/Write Splitting）。
1.原理：让主数据库（master）处理事务性增、改、删操作（INSERT、UPDATE、DELETE），而从数据库（slave）处理SELECT查询操作。
2.诞生原因：
2.1 为了确保数据库产品的稳定性，很多数据库拥有双机热备功能。也就是，第一台数据库服务器，是对外提供增删改查业务的生产服务器；第二台数据库服务器，仅仅接收来自第一台服务器的备份数据（注意，不同数据库产品，第一台数据库服务器，向第二台数据库服务器发送备份数据的方式不同）。当第一台数据库崩溃后，第二台数据库服务器，可以立即上线来代替第一台数据库服务器，并且，在第一台数据库服务器崩溃后，宝贵的数据，依然会存在于第二台数据库服务器里（根据目前业界的备份数据发送方式来看，当第一台数据库崩溃后，第一台数据库里的仍然会有少量的新数据，没能来得及被发送到第二台数据库服务器，所以，这部分数据就丢失了）。
2.2 一般来说，为了配置方便，以及稳定性，这两台数据库服务器，都用的是相同的配置（思考一下，如果两台服务器的配置不同，会导致什么结果）。
2.3 从上文的描述中，大家能看到，在实际运行中，第一台数据库服务器的压力，远远大于第二台数据库服务器。因此，很多人希望合理利用第二台数据库服务器的空闲资源。那么，第二台数据库服务器能做些什么事情呢？
2.4 从数据库的基本业务来看，数据库的操作无非就是增删改查这4个操作。但对于“增删改”这三个操作，如果是双机热备的环境中做，一台机器做了这三个操作的某一个之后，需要立即将这个操作，同步到另一台服务器上。单向的同步，不复杂。但如果两台机器都需要向对方进行同步，那逻辑就非常复杂，而且还会大大降低性能。（从保证ACID特性的角度，思考一下为什么双向同步会非常复杂且低性能？而单向同步却不会？）出于这个原因，第二台备用的服务器，就只做了查询操作。进一步，为了降低第一台服务器的压力，干脆就把查询操作全部丢给第二台数据库服务器去做，第一台数据库服务器就只做增删改了。
2.4 到这一步，就实现了所谓的读写分离。这样做，缺点也非常明显了。本来第二台数据库服务器，是用来做热备的，它就应该在一个压力非常小的环境下，保证运行的稳定性。而读写分离，却增加了它的压力，也就增加了不稳定性。因此，读写分离，实质上是一个在资金比较缺乏，但又需要保证数据安全的需求下，在双机热备方案上，做出的一种折中的扩展方案。
简单实现
通过RAID技术，RAID是英文Rendant Array of Independent Disks的缩写，翻译成中文意思是“独立磁盘冗余阵列”，有时也简称磁盘阵列（Disk Array）。
简单的说，RAID是一种把多块独立的硬盘（物理硬盘）按不同的方式组合起来形成一个硬盘组（逻辑硬盘），从而提供比单个硬盘更高的存储性能和提供数据备份技术。