Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
wushizhenking
advanced-java
提交
4d905626
A
advanced-java
项目概览
wushizhenking
/
advanced-java
与 Fork 源项目一致
从无法访问的项目Fork
通知
2
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
A
advanced-java
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
前往新版Gitcode,体验更适合开发者的 AI 搜索 >>
提交
4d905626
编写于
12月 01, 2018
作者:
Y
yanglbme
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
docs(mysql): add mysql-read-write-separation.md
MySQL如何实现读写分离?主从复制的原理是啥?如何解决主从同步的延时问题?
上级
819cffbe
变更
3
隐藏空白更改
内联
并排
Showing
3 changed file
with
42 addition
and
3 deletion
+42
-3
README.md
README.md
+1
-3
docs/high-concurrency/mysql-read-write-separation.md
docs/high-concurrency/mysql-read-write-separation.md
+41
-0
img/mysql-master-slave.png
img/mysql-master-slave.png
+0
-0
未找到文件。
README.md
浏览文件 @
4d905626
...
@@ -73,9 +73,7 @@
...
@@ -73,9 +73,7 @@
-
[
分库分表之后,id 主键如何处理?
](
/docs/high-concurrency/database-shard-global-id-generate.md
)
-
[
分库分表之后,id 主键如何处理?
](
/docs/high-concurrency/database-shard-global-id-generate.md
)
### 读写分离
### 读写分离
-
如何实现 MySQL 的读写分离?
-
[
如何实现 MySQL 的读写分离?MySQL 主从复制原理是啥?如何解决 MySQL 主从同步的延时问题?
](
/docs/high-concurrency/mysql-read-write-separation.md
)
-
MySQL 主从复制原理是啥?
-
如何解决 MySQL 主从同步的延时问题?
## 高可用架构
## 高可用架构
...
...
docs/high-concurrency/mysql-read-write-separation.md
0 → 100644
浏览文件 @
4d905626
## 面试题
你们有没有做 MySQL 读写分离?如何实现 MySQL 的读写分离?MySQL 主从复制原理的是啥?如何解决 MySQL 主从同步的延时问题?
## 面试官心理分析
高并发这个阶段,肯定是需要做读写分离的,啥意思?因为实际上大部分的互联网公司,一些网站,或者是 app,其实都是读多写少。所以针对这个情况,就是写一个主库,但是主库挂多个从库,然后从多个从库来读,那不就可以支撑更高的读并发压力了吗?
## 面试题剖析
### 如何实现 MySQL 的读写分离?
其实很简单,就是基于主从复制架构,简单来说,就搞一个主库,挂多个从库,然后我们就单单只是写主库,然后主库会自动把数据给同步到从库上去。
### MySQL 主从复制原理的是啥?
主库将变更写入 binlog 日志,然后从库连接到主库之后,从库有一个 IO 线程,将主库的 binlog 日志拷贝到自己本地,写入一个 relay 中继日志中。接着从库中有一个 SQL 线程会从中继日志读取 binlog,然后执行 binlog 日志中的内容,也就是在自己本地再次执行一遍 SQL,这样就可以保证自己跟主库的数据是一样的。
![
mysql-master-slave
](
/img/mysql-master-slave.png
)
这里有一个非常重要的一点,就是从库同步主库数据的过程是串行化的,也就是说主库上并行的操作,在从库上会串行执行。所以这就是一个非常重要的点了,由于从库从主库拷贝日志以及串行执行 SQL 的特点,在高并发场景下,从库的数据一定会比主库慢一些,是
**有延时**
的。所以经常出现,刚写入主库的数据可能是读不到的,要过几十毫秒,甚至几百毫秒才能读取到。
而且这里还有另外一个问题,就是如果主库突然宕机,然后恰好数据还没同步到从库,那么有些数据可能在从库上是没有的,有些数据可能就丢失了。
所以 MySQL 实际上在这一块有两个机制,一个是
**半同步复制**
,用来解决主库数据丢失问题;一个是
**并行复制**
,用来解决主从同步延时问题。
这个所谓
**半同步复制**
,也叫
`semi-sync`
复制,指的就是主库写入 binlog 日志之后,就会将
**强制**
此时立即将数据同步到从库,从库将日志写入自己本地的 relay log 之后,接着会返回一个 ack 给主库,主库接收到
**至少一个从库**
的 ack 之后才会认为写操作完成了。
所谓
**并行复制**
,指的是从库开启多个线程,并行读取 relay log 中不同库的日志,然后
**并行重放不同库的日志**
,这是库级别的并行。
### MySQL 主从同步延时问题(精华)
以前线上确实处理过因为主从同步延时问题而导致的线上的 bug,属于小型的生产事故。
是这个么场景。有个同学是这样写代码逻辑的。先插入一条数据,再把它查出来,然后更新这条数据。在生产环境高峰期,写并发达到了 2000/s,这个时候,主从复制延时大概是在小几十毫秒。线上会发现,每天总有那么一些数据,我们期望更新一些重要的数据状态,但在高峰期时候却没更新。用户跟客服反馈,而客服就会反馈给我们。
我们通过 MySQL 命令:
```
sql
show
status
```
查看
`Seconds_Behind_Master`
,可以看到从库复制主库的数据落后了几 ms。
一般来说,如果主从延迟较为严重,有以下解决方案:
-
分库,将一个主库拆分为多个主库,每个主库的写并发就减少了几倍,此时主从延迟可以忽略不计。
-
打开 MySQL 支持的并行复制,多个库并行复制。如果说某个库的写入并发就是特别高,单库写并发达到了 2000/s,并行复制还是没意义。
-
重写代码,写代码的同学,要慎重,插入数据时立马查询可能查不到。
-
如果确实是存在必须先插入,立马要求就查询到,然后立马就要反过来执行一些操作,对这个查询
**设置直连主库**
。
**不推荐**
这种方法,你这么搞导致读写分离的意义就丧失了。
\ No newline at end of file
img/mysql-master-slave.png
0 → 100644
浏览文件 @
4d905626
24.2 KB
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录