Mysql分布式集群

• 主从复制：
  • 
  • 这个过程会产生时延：
    • 网络延迟：可忽略
    • master多个线程在写binlog，但slave只有一个sql线程在重放
    • 即使只有一个master线程在写，我们知道日志是顺序读写的，但relay log日志重放的过程中，是随机写的，也就是sql线程是个随机读写线程 =》解决方法：MTS（enhanced multi-threaded slave）
• MTS:
  • 
  • 但也不能太多，如果突然断点，数据就全没了。
  • 实现方式是在binlog event中增加必要的信息，以便slave节点根据这些信息实现并行复制。
  • 假设有8个线程一起在写内存，由于并发写不能存在锁冲突，所以有了组提交（所以一组里的事务是不能有锁冲突的）的概念。
  • 双一操作简单来说就是控制binlog同步磁盘的速度的操作：
    • innodb_flush_log_at_trx_commit=1：每次事务提交，都会写log（redo），且会刷磁盘。推荐设置为2，每秒才刷一次磁盘。
    • sync_binlog=1：比如说多少次事务提交刷写磁盘，默认为1，这应该就是redo同步binlong
    • 这是默认的，我们可以更改以实现组提交。
• 组提交：

  • 如果一个事务可以commit了，就不存在锁问题了，但其实在prepare阶段就不存在了。

  • 并行复制的策略思想：同时处于prepare状态或commit状态的事务，由于不存在锁冲突，可以在备库上并行。

  • 

  • 组提交：将多个事务的redolog（所以在事务执行期间，是在内存的）组队刷磁盘

  • 怎么知道哪些日志可以放一组？=》时间窗口

    • 如事务1处于prepare状态，成为leader，需要先写binlog，在开始写binlog到开始刷磁盘时（这个过程很慢），这个组里又有三个事务了，这个leader会等他们都从redlog写完binlog了，并且滑过了时间窗口了，再一起提交。

    • 

• 读写分离：
  1.  一台写，其他读 =》负载均衡，读是很多的
  2.  实现方法：

     1. mysql 代理机器

     2. 多线程组件  shardingSphere ，mycat等

1. 立马插入，立马查询的不适合做读写分离，通过上面的延迟分析就直到，还没同步过来，怎么查：设置一个具有读和写的库，或者强制查主库

• 分库分表

1. A表在A库，B表在B库=》一般在insert操作时，这条数据都会存入A库和B库，使得A库有AB表，B库也有AB表。 那就是纯粹降低select开销咯！！！
2. 水平分表很简单，水平砍一刀；垂直分表就是垂直砍一刀，一些字段不经常用(冷数据)，我们就可以把它们单独分离出来成一个表，需要的时候和热查询字段关联查询就行。
3. 分片键盘，其实就类似按月份分表的月份，定位查询哪个表（库）,不然还得轮询所有表
   1. 雪花算法：64bit长整型：
      1. 第一个bit不用，为0，id'为正
      2. 最高的41位时间戳，保证id的自增性
      3. 10bit工作id，哪个库的哪个机器，表示我要去哪里查
      4. 同一时刻可能有多条记录，后bit位做为序列号保证id的唯一性