如何实现 MySQL 的读写分离？ MySQL 主从复制原理的是啥？ 如何解决 MySQL 主从同步的延时问题？

高并发这个阶段，肯定是需要做读写分离的，啥意思？
因为实际上大部分的互联网公司，一些网站，或者是 app，其实都是读多写少。
所以针对这个情况，就是写一个主库，但是主库挂多个从库，然后从多个从库来读，那不就可以支撑更高的读并发压力了吗！

mysql主从复制用途
● 实时灾备，用于故障切换
● 读写分离，提供查询服务
● 备份，避免影响业务

主从部署必要条件
● 主库开启binlog日志（设置log-bin参数）
● 主从server-id不同
● 从库服务器能连通主库

如何实现 MySQL 的读写分离？
其实很简单，就是基于主从复制架构，简单来说，就搞一个主库，挂多个从库，
然后我们就单单只是写主库，然后主库会自动把数据给同步到从库上去。

主从复制原理如下

slave（从服务器）
master（主服务器）
mysql主从是异步复制过程

master开启bin-log功能，日志文件用于记录数据库的读写增删

需要开启3个线程，master IO线程，slave开启 IO线程 SQL线程，
Slave 通过IO线程连接master，并且请求某个bin-log，position之后的内容。
MASTER服务器收到slave IO线程发来的日志请求信息，io线程去将bin-log内容，position返回给slave IO线程。
slave服务器收到bin-log日志内容，将bin-log日志内容写入relay-log中继日志，创建一个master.info的文件，该文件记录了master ip 用户名 密码 master bin-log名称，bin-log position。
slave端开启SQL线程，实时监控relay-log日志内容是否有更新，解析文件中的SQL语句，在slave数据库中去执行。

这里有一个非常重要的一点，就是从库同步主库数据的过程是串行化的，也就是说主库上并行的操作，在从库上会串行执行。所以这就是一个非常重要的点了，由于从库从主库拷贝日志以及串行执行 SQL 的特点，在高并发场景下，从库的数据一定会比主库慢一些，是有延时的。所以经常出现，刚写入主库的数据可能是读不到的，要过几十毫秒，甚至几百毫秒才能读取到。

而且这里还有另外一个问题，就是如果主库突然宕机，然后恰好数据还没同步到从库，那么有些数据可能在从库上是没有的，有些数据可能就丢失了。

MySQL 实际上在这一块有两个机制，一个是半同步复制，用来解决主库数据丢失问题；
一个是并行复制，用来解决主从同步延时问题。

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

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

主从复制的问题及解决方法
mysql主从复制存在的问题：
● 主库宕机后，数据可能丢失
● 从库只有一个sql Thread，主库写压力大，复制很可能延时
解决方法：
● 半同步复制—解决数据丢失的问题
● 并行复制----解决从库复制延迟的问题

半同步复制
mysql semi-sync（半同步复制）
半同步复制：
● 5.5集成到mysql，以插件的形式存在，需要单独安装
● 确保事务提交后binlog至少传输到一个从库
● 不保证从库应用完这个事务的binlog
● 性能有一定的降低，响应时间会更长
● 网络异常或从库宕机，卡住主库，直到超时或从库恢复

并行复制

mysql并行复制
● 社区版5.6中新增
● 并行是指从库多线程apply binlog
● 库级别并行应用binlog，同一个库数据更改还是串行的(5.7版并行复制基于事务组)
设置 set global slave_parallel_workers=10;
设置sql线程数为10

实际配置：参考
https://blog.csdn.net/qq_41772936/article/details/80380950