多写分离，是为了处理大数据而诞生的，如果你做的是小项目，那么这些东西是感觉不到的，如果你做的是百万级甚至千万级的数据量的话，那么多分离是很有必要的，如果这么大的数据量同时读图是血的话，数据库的负担是很重的，那么读写分离之后呢，主要负责读那个附表那个支付的取了这样的话，分开写作，大大减轻了数据库的运行负担

核心思想：分布式，隔离影响，拆分治理

这不是人人都能玩的，第一，读操作的节点少了，等于又增加复杂度又没什么复合平衡用，如果多了，都是同步跟进，则一个节点挂，整个系统停止响应，如果一个是同步其它是异步，则各个节点的客户看到的数据可能顺序不一致，数字不一致。第二，写节点单点失败系统照样挂。 一些情况也许同节点加配redis更省心。

现在绝大部分软件项目，都会使用到关系型数据库，比如MySQL、Oracle、DB2等等，目前这些数据库的单机性能已经是不断优化和提高了，但是随着数据增长的速度和并发访问量的增加，在某些公司、某些场景下，单机数据库已经很难满足业务的需要了，所以必须考虑数据库集群的方式来提高系统的可用性；最常见的两种方法：

• 分库分表：把数据分散到不同的数据库上，每台数据库中存储的数据是不相同的（这里先不考虑每个库做备份或读写分离）；分库分表既可以分散数据库访问的压力，也可以分散数据存储的压力；但是使用分库分表方案的时候，会带来扩容、事务、关联查询等问题和难点，具体这里就不展开讲了。

• 读写分离：将数据库读操作和写操作分散到不同的节点上，通常是一台数据库做写操作，1到N台做读操作；读写分离的架构，每一台数据中的数据是相同的（这里先忽略延迟的问题），所以只分散了数据库访问的压力，并没有分散数据存储的压力；我们这里主要讲一讲读写分离。

读写分离基本架构

MySQL读写分离的基本架构，可以参考下图：

如上图，读写分离实现的基本步骤是：

1. 数据库服务器搭建多台，一主N从（N大于等于1）；

2. 主数据库只负责写操作，从数据库只负责读操作；

3. 主数据库复制数据到从数据库上；

4. 客户端写操作路由到主数据库上，读操作路由到从数据库上。

读写分离还有另外一种架构，就是在MySQL数据库和客户端之间，增加一层中间代理层，客户端只连接代理， 由代理根据请求类型，把请求分发到不同的数据库上：

• 第一种架构，整体架构比较简单直接，性能会稍微高一些，但是如果才用直连的方式，客户端可能会稍微麻烦一些（通常需要引入一些组件，负责管理数据库）；

• 第二种架构，对客户端比较友好，因为客户端只需要和代理交互，并不用关注数据库的具体信息；但是因为多了一层代理，多多少少会对性能有一定的影响。

读写分离带来的好处

• 读写分离结构中，会有两台甚至更多台数据库，这种冗余的设计，可以提高数据的安全性和系统的可用性；就算是在分库分表的架构中，每一台子库，也可以一主多备的部署方式；

• 读写分离更多的时候使用在读操作远远大于写操作的场景下，这样可以保证写操作的数据库承受更小的压力，也可以缓解X锁和S锁争用；

• 服务器数量的增加，意味着可以有效地利用多台服务器的资源；读操作被分摊，提高了系统的性能；

• 如果写操作比读操作多，或者相近，可以采用双主相互复制的架构。

读写分离会带来的问题

之前的文章，我也反复强调过，任何的架构、软件、框架、组件…在解决一部分问题的时候，一定会带来其他的问题；读写分离最大的一个问题就是，数据从主复制到从的过程中，可能会存在延迟的，如果客户端在执行完一个读操作后，立刻从存库中查询的话，可能会读取到旧数据的情况（我们不断优化，也只能缩短这个时间，并不能完全消除掉这个时间）。

那么针对这个问题，有哪些处理方法呢？

• 根据具体场景进行评估，是否可以接收这个延迟（这好像是一句废话，但是大多数业务场景，是可以接收这点儿延迟的）；

• 对于实时性要求很高的场景（查询的数据必须是最新的结果），将这些请求强制路由到主库上；

• 执行完写操作之后，在读操作发生之前，让中间的时间变长（也就是从业务操作角度来做一些控制，不一定操作完了立刻查询）；

• 判断主备无延迟，可以通过判断seconds_behind_master参数、对比GTID、对比位点等方式，判断从数据库是否和主数据库一致。

我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。

很高兴能够看到和回答这个问题！

MySQL是世界上最受欢迎的开源数据库。凭借其经过验证的性能，可靠性和易用性，MySQL已成为基于Web的应用程序的领先数据库选择，被包括Facebook，Twitter，You Tube，Yahool等在内的知名Web财产所使用。

Oracle推动MySQL创新，提供了支持下一代Web，云，移动和嵌入式应用程序的新功能。

在大多数的网络操作中，读和写通常比较少，第一次读取的数据库称为小空间。如果我们想线性改进解决冲突，可以在数据库中使用 “模式”（创建和读取记录组）。

读取和记录分为数据库（INSERT、UPDATE、DELETE）和SELECT请求。数据库复制是用来同步数据库服务器的变化。

为了保证数据库产品的稳定性，很多数据库采用双重热处理。因此，数据库中的第一台服务器是产生附加、减少、修改操作的服务器；第二台数据库服务器只接收第一台服务器的备份数据（注：不同的数据库产品，第一台数据库服务器，备份数据不同 数据传输到第二台数据库服务器的方法）。如果第一数据库发生故障，第二数据库服务器可以立即连接到第一服务器数据库。第一价格数据库服务器故障后，第二服务器上的数据将继续拥有基础数据库(当第一数据库崩溃时，一些新的数据库无法发送到第二服务器数据库，所以这部分数据可能会丢失)。

MYSQL中读写分离有什么样的好处呢，为什么一些人都选择读写分离？

数据库不应分为读和写。如果程序使用的数据库比更新的数据库多，那么在大量请求的情况下，就会和数据库的主用户同步。我们可以减少数据库的压力，提高工作效率。当然，数据库还有其他优化方案。Memcache、平板电脑或者搜索引擎.这个决定了读写部分旨在提高系统的通过能力。有些网站的阅读和记录较多，但记录较少。但对实时读取数据的要求不高。这可能是解决方案。因此，在你的问题中，”数据还需要同步 “是错误的。事实上，这是因为用户有权在分离前的几秒或几分钟内读取和记录数据。

MySQL数据库服务是一项完全托管的数据库服务，使组织能够使用世界上最受欢迎的开源数据库来部署云原生应用程序。它是由MySQL团队100％开发，管理和支持的。

为了保证数据库产品的稳定性，很多数据库都经过了双重热处理。因此，数据库的第一台服务器是提供数据补充和删除的生产服务器，第二台服务器是主要处理数据的数据库服务器。从数据库的主要操作来看，数据库的操作就是补充和排除这四种操作。但对于 “补删 “这三项操作，如果环境中两辆车处于高度警戒状态，那么经过三项操作后的机器就会与其他服务器进行同步。MySQL是世界上最流行的开源数据库。无论你是快速增长的网络财产、技术ISV还是大型企业，MySQL都能低成本地帮助你提供高性能、可扩展的数据库应用。

读取和记录的分工可以包括多个可读取的数据库，比如3个外部用户服务数据库，120读取任务可以处理40条日志到一台电脑，只需要传输3条数据。当然，这个场景比剧本更适合阅读。

但如果需要两车同步，逻辑非常复杂，大大降低了性能。(从节约ACID特性的角度出发，为什么双向同步会如此复杂，性能又如此之低? 因此，第二台备份服务器只执行请求。因此，为了减少第一台服务器的负载，请将数据库中的所有操作都请求，第一台数据库服务器将被添加和删除。我们如果想要深度优化MySQL数据库，需要做的事情不是单方面的，而是要从成本及优化效果选择最适合当前企业需求的方案。所以本课程针对整个出发点，会从各个维度来让MySQL在运行过程中达到最优的状态。

如果读写是分开的，那么那些只用于读取的服务器就不要考虑最贵的城堡。只有在操作过程中，服务器应该使用高级一致性服务器。虽然读取服务器更新需要时间，但它只需要在更新时安装。所以基本上，这样的程序是以数据过时来换取读取速度的。

以上便是我的一些见解和回答，可能不能如您所愿，但我真心希望能够对您有所帮助！不清楚的地方您还可以关注我的头条号“每日精彩科技”我将竭尽所知帮助您！

码字不易，感觉写的还行的话，还请点个赞哦！

MySQL读写分离本质上是解决因数据库的读写性能差异造成的用户平台操作体验的问题，由于数据库本身进行写入操作的性能消耗较大，而读取数据的性能响应较快，故为提升用户操作的体验将数据库的读、写进行分离，而典型MySQL进行读写分离的过程中会伴随着数据库的主从复制，在主服务器进行修改，数据同步至从服务器上，而从服务器只能进行数据读取，不能写入，实现数据备份，同时实现数据库性能的优化，增加数据的安全性，落地的方案为由MySQL的主服务器负责数据的写入（增、改、删），由从服务器负责读取；

典型实现MySQL读写分离的方式分为以下两种：

1.基于程序代码内部实现：在代码中根据select、insert进行路由分类，这类方法也是目前生产环境下应用最广泛的。优点是性能较好，因为程序在代码中实现，不需要增加额外的硬件开支，缺点是需要开发人员来实现，运维人员无从下手，可扩展性弱。

2.由中间代理层实现：代理一般介于应用服务器和数据库服务器之间，代理数据库服务器接收到应用服务器的请求后根据判断后，转发到后端数据库。

总则：MySQL的读写分离能够一定程度上优化数据库的性能，对于数据库查询多而更新少的情况下可引用读写分离的模式，但优化并不是全部仅限于读写分离，如：创建索引、配置IO、使用分区查询、数据结构优化、系统配置优化等。

我也写了篇mysql主从的文章，读写分离可以减少数据库的负载压力。你可以配多个读数据库用于不同的服务，而不必全部请求一个数据库，我想这是读写分离最重要的作用了。

但是不一定所有项目都适合读写分离，小项目没有太大必要，首先增加了维护成本，代码技术成本，读写分离要维护数据的一致性，也需要额外的服务器资源。

建议根据实际应用场景，项目规模来判断是否需要进行读写分离。

类似淘宝网这样的网站，海量的数据存储和访问，数据库的负载很大，数据操作的成本高，对系统稳定性和扩展性的要求也极高。无论怎样升级硬件资源，单台服务器的资源有限，最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。

如果将数据库的读和写都放在同一个数据库服务器中，在安全性、高可用性、高并发等方面，都是完全不能满足实际场景需求的。MySQL性能优、成本低、资源丰富，使用MySQL读写分离，可以解决数据库写入影响查询效率的问题，较大程度地提升系统性能。

本篇知识点纲要

• 读写分离的原理

• 使用读写分离的原因

• 读写分离的适用场景

读写分离的原理

让主数据库（master）处理事务性增（INSERT）、改（UPDATE）、删（DELETE）操作，从数据库（slave）处理SELECT查询操作。数据库复制被用来把事务性操作导致的变更同步到集群中的从数据库。

使用读写分离的原因

使用读写分离的具体原因包括：

提升查询性能、节约成本

数据库为IO写入，在写入过程中，通常会涉及唯一性校验、索引排序等操作，资源消耗大，操作耗时，一次写操作的响应时间往往是读操作的几倍、几十倍甚至更多。譬如，写20000条数据到oracle，大概要3-10分钟，从oracle读20000条数据，只要几秒钟。

缓解X锁和S锁争用

写操作很多时候需要加锁，包括表级锁、行级锁等，这类锁都是排他锁，一个会话占据排它锁之后，其他会话是不能读取数据的，极大影响数据读取性能。

因此，MySQL部署往往会采用读写分离方式，主库用来写入数据及部分时效性要求很高的读操作，从库用来承接大部分读操作，这样数据库整体性能能够得到大幅提升。

读写分离的适用场景

数据库不一定都要读写分离，读写分离适用于“读远大于写”场景，对于读操作为主的应用，使用读写分离将是最好的优化方案，既能让写的服务器压力更小，而读又可以接受点时间上的延迟。

当然了，数据库还有其它的优化方案，譬如Memcache、表拆分或搜索引擎等。由于涉及的知识点很多，Mike在这里也只是抛砖引玉，最后，送大家一套【BAT架构技术专题合集500+】，想要获取更多关于MySQL的知识详解，关注并私信回复【架构师进阶】，即可查看。

1. 问题描述

MYSQL中读写分离有什么样的好处呢，为什么一些人都选择读写分离？

问题结论

MYSQL读写分离的好处：

• 增加服务器，整个集群的负载能力增加。
• 主库只负责写操作，其由读操作引起的性能瓶颈将大大降低。
• 从库异步同步主库binlog日志，对其读操作的性能影响微乎其微。
• 可以多从库分摊读操作压力，以机器和带宽资源换性能。

而使用读写分离的场景往往只有一个：读数据库的量要远远大于写数据库的量，并且读写的压力造成主库的性能瓶颈，并且在缓存无可优化的情况下，读写分离是最合理的方案。而对于增加冗余，确保主从数据备份，这在大厂是基础能力，默认申请的数据库是一主已从，主库挂掉之后，将从库设置为主库。

2. MYSQL读写分离的注意事项

2.1 实现读写分离的方式，MYSQL默认使用的就是异步复制模式。

• 主从异步复制：在主实例写入引擎后就返回成功，然后将事件发给从实例，在从实例上执行。这种同步方式速度较快，但是在主挂了的时候，如果还没有复制，则可能存在数据丢失问题。

• 主从半同步复制：指主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。

• 主从全同步复制：全同步复制跟半同步复制的区别在于，半同步复制只需要一个slave确认已经接收到事务并写入relay log的ACK，就回提交本地的事务并返回成功给客户端。而全同步则需要所有的slave的确认ACK。一般很少使用全同步复制，因为性能太差。

2.2 MYSQL读写分离的缺点

MYSQL读写分离最大的缺点在于主从延迟，导致往主库写入的数据跟从库读出来的数据不一致。尤其是在高并发状态往主库写入的数据量很多的时候，延迟会很严重。

2.3 读写延迟解决方法

• 核心业务读写都指向主库，非核心业务采用读写分离。这个需要产研评估，也是最常见的处理方式。

• 二次读取，读失败后再查一遍，它和业务逻辑无关，只需要对数据库访问层重新封装即可，实现代价小。不过某些场景下，它扩大的读请求的数量，增加了数据库的压力，比如DDoS攻击，很容易把数据库压垮。
• 判断延迟再读取，读取从库前判断是否有延迟，没有延迟再从库查询，如果有延迟到主库查询。

3. 小结

首先在遇到读多写少的情况，优先上缓存(如redis)。之后，如果仍然还是扛不住，可以上读写分离。读写分离架构出现的原因是因为在读远远比写多的情况下(一般读写比至少大于9:1)，为了缓解主库的压力，将大多数读请求压力均摊到多个从库上。如果读写分离仍无法解决问题，就需要考虑分库分表了。

作者：夕阳雨晴，欢迎关注我的头条号：偶尔美文，主流Java，为你讲述不一样的码农生活。

什么是读写分离

读写分离指的是在数据库集群架构中，让Master处理事务性的查询，比如增删改的操作；让Slave负责查询的操作。

读写分离的好处

从读的方面来看：我们知道MySQL数据库有两种引擎，其中InnoDb和 MyISAM，两者在查询性能上MyISAM显然要比InnoDB要强，但是由于MyISAM不支持事务，所以对于写操作显然不太友好，此时如果我们将读数据的引擎设置为MyISAM，那么性能又会得到一个提升。

从写的方面来看：写的过程中，会由于索引，unique的问题会进行插入前的准备工作，这些操作一方面会损耗性能，另一方面会因为表锁/行锁导致数据不可查，那么查询请求就会被阻塞，而如果我们将写请求单独分配到主数据中，那么就不会影响查询操作，两者并行效率更好

读写综合来看：读写分离是以加数据库为代价消除两者的弊端，也就是写由于事务影响了读，而读的本身可以更快却因为写不得不使用InnoDb引擎。

而且抛开性能，读写使用了复制功能，增加冗余，保证了数据丢失的可能性下降。

使用场景

可以根据自己服务器的配置，业务的复杂性，数据请求数量级去分析：

如果服务器配置一般，那可以采用读写分离

如果项目自身业务复杂，可以采用读写分离

如果数据请求量很大，可以采用读写分离(根据读多还是写多，增加主或者从数据库)

希望我的回答对你有所帮助，谢谢

MYSQL读写分离可以极大提升性能表现。具体原因包括：

写操作本身耗费资源

数据库写操作为IO写入，写入过程中通常会涉及唯一性校验、建索引、索引排序等操作，对资源消耗比较大。一次写操作的响应时间往往是读操作的几倍甚至几十倍。

锁争用

写操作很多时候需要加锁，包括表级锁、行级锁等，这类锁都是排他锁，一个会话占据排它锁之后，其他会话是不能读取数据的，这会会极大影响数据读取性能。

所以MYSQL部署往往会采用读写分离方式，主库用来写入数据及部分时效性要求很高的读操作，从库用来承接大部分读操作，这样数据库整体性能能够得到大幅提升。

就是基于主从复制架构，简单来说，就搞一个主库，挂多个从库或只读库，然后我们应用就仅往主库写数据，然后主库会自动把数据同步到从库或只读库上。主要目的是分担主库的压力。

但是读写分离有时也会存在问题，比如：主从延迟时，读取的从库数据不是最新的，怎么办？

mysql有两个机制，一个是半同步复制，用来解决主库数据丢失问题；一个是并行复制，用来解决主从同步延时问题。

1、半同步复制（semi-sync复制），指的是主库写入binlog日志之后，就会强制此时立即将数据同步到从库，从库将日志写入自己本地的relay log之后，接着会返回一个ack给主库，主库接收到至少一个从库的ack之后才会认为写操作完成了。

2、并行复制，指的是从库开启多个线程，并行读取relay log中不同库的日志，然后并行重放不同库的日志，这是库级别的并行。

这问题通俗的说:

其一:各干各的，不产生交叉浪费资源！性能最优化

其二:写入比读先级高，读有很多拓展方案！

其三:维护管理，拓展方便