MySQLは別の読み取りと書き込みを行うには何もしていますか？mysqlのの分離を読み書きするには？MySQLのマスター・スレーブレプリケーションの原則は有効でしょうか？どのように遅延の問題のmysqlのマスターまたはスレーブを解決するには？
この段階で高い同時実行が、それは確かに読み取りと書き込みの分離するために行われる必要がある、あなたは何を意味するのですか？実際には、ほとんどのインターネット企業は、いくつかのウェブサイトやアプリ、彼らは実際に読んであまり書いているので。だから、このような場合のために、メインライブラリーを書きますが、より多くのメインライブラリ吊りライブラリからと複数のライブラリから読み取ることがあり、それはまだ同時読み取りより多くの圧力をサポートすることはできませんか？
mysqlの分離を読み書きする方法（1）？
実際、非常にシンプルで、マスタースレーブのレプリケーションアーキテクチャに基づいており、短期では、ライブラリーからもっとぶら下がって、メインのライブラリに従事した後、我々は単にメインのライブラリと自動的に同期データへのライブラリから行くことになる主なライブラリを書き込みます。
（2）MySQLのマスター・スレーブレプリケーションの原則は有効でしょうか？
主なライブラリはバイナリログ変更ログを書き込んだ後、メインライブラリにライブラリから接続した後、ライブラリは、IOスレッド、リレーログに書かれたローカルコピーをメインライブラリビンログログを、持っています。そして、そこにSQLスレッドからのライブラリがあるのbinlogからのリレーログを読み取り、その後、あなたがメインのライブラリのデータを自分が同じであることを確認できるように、もう一度自分のローカルSQLの実行では、ログのbinlogの内容を実行します。
非常に重要なポイントは、メインのライブラリのデータからデータベースの同期のプロセスがメインライブラリの並列動作は、ライブラリはシリアルから実行されると言うことですつまり、シリアライズされていることです。SQLの実装は確かに遅くなり、ライブラリのメインライブラリデータから、並行性の高いシナリオの下で、メインのライブラリだけでなく、ライブラリーのシリアルからログのコピーから備えているのでこれは非常に重要な点は、遅延がある、です。だから、多くの場合、単にプライマリ・データベースに書き込まれたデータを読むために数十ミリ秒、またはミリ秒の数百以上に、読み取られない場合があります。
そして、プライマリ・データベースが突然ダウンして、データだけがライブラリに同期していない場合は、一部のデータがライブラリからではないかもしれないが、別の問題が、あります、いくつかのデータが失われる可能性があります。
遅延の問題を解決するための並列コピー、マスタ - スレーブ同期、それほどのMySQL実際、このいずれかに二つの機構、準同期レプリケーション、データ損失の問題を解決するために使用される主なライブラリが存在します。
这个所谓半同步复制，semi-sync复制，指的就是主库写入binlog日志之后，就会将强制此时立即将数据同步到从库，从库将日志写入自己本地的relay log之后，接着会返回一个ack给主库，主库接收到至少一个从库的ack之后才会认为写操作完成了。
所谓并行复制，指的是从库开启多个线程，并行读取relay log中不同库的日志，然后并行重放不同库的日志，这是库级别的并行。
- 主从复制的原理
- 主从延迟问题产生的原因
- 主从复制的数据丢失问题，以及半同步复制的原理
- 并行复制的原理，多库并发重放relay日志，缓解主从延迟问题
（3）mysql主从同步延时问题（精华）
线上确实处理过因为主从同步延时问题，导致的线上的bug，小型的生产事故
show status，Seconds_Behind_Master，你可以看到从库复制主库的数据落后了几ms
其实这块东西我们经常会碰到，就比如说用了mysql主从架构之后，可能会发现，刚写入库的数据结果没查到，结果就完蛋了。。。。
所以实际上你要考虑好应该在什么场景下来用这个mysql主从同步，建议是一般在读远远多于写，而且读的时候一般对数据时效性要求没那么高的时候，用mysql主从同步
所以这个时候，我们可以考虑的一个事情就是，你可以用mysql的并行复制，但是问题是那是库级别的并行，所以有时候作用不是很大
所以这个时候。。通常来说，我们会对于那种写了之后立马就要保证可以查到的场景，采用强制读主库的方式，这样就可以保证你肯定的可以读到数据了吧。其实用一些数据库中间件是没问题的。
一般来说，如果主从延迟较为严重
- 分库，将一个主库拆分为4个主库，每个主库的写并发就500/s，此时主从延迟可以忽略不计
- 打开mysql支持的并行复制，多个库并行复制，如果说某个库的写入并发就是特别高，单库写并发达到了2000/s，并行复制还是没意义。28法则，很多时候比如说，就是少数的几个订单表，写入了2000/s，其他几十个表10/s。
- 重写代码，写代码的同学，要慎重，当时我们其实短期是让那个同学重写了一下代码，插入数据之后，直接就更新，不要查询
- 如果确实是存在必须先插入，立马要求就查询到，然后立马就要反过来执行一些操作，对这个查询设置直连主库。不推荐这种方法，你这么搞导致读写分离的意义就丧失了