MySQL主从同步原理

      同步步骤：主库将变更写入 binlog 日志，然后从库连接到主库之后，从库有一个 IO 线程，将主库的 binlog 日志拷贝到自己本地、写入relay log，执行一遍sql保证数据一致。       半同步复制：主写入binlog之后，强制立即同步到从库、写入relay log，从库返回ack才认为写操作成功。(解决主从数据丢失问题)       并行复制：从库开启多个线程，并行读取 relay log 中不同库的日志，然后并行重放不同库的日志，这是库级别的并行。(解决主从同步延时问题)

一、并发控制技术

   基于锁的并发控制：对于可能冲突的操作(读写/写读/写写)，通过锁使其互斥等待执行； (悲观并发控制)    基于时间戳的并发控制：对于可能冲突的操作，通过时间戳排序决定某事务执行，其他事务回滚；  (悲观并发控制)    基于有效性检查的并发控制：先读+局部变量改、有效性检查、写入or回滚。(类似CAS的乐观策略)    基于快照隔离的并发控制：mvcc的一种实现方式，一个数据多个快照版本，事务更新自己的快照，然后有效性检查、写入or回滚。“先提交/更新者获胜”

二、数据库锁

锁：对数据的操作加锁，其他人无法操作当前数据。 流程：向锁管理器申请操作所对应的锁，成功则继续执行，失败则阻塞。         死锁：多个事务持有不同的锁，并且循环等待其他事务的锁，导致阻塞。         饥饿：数据A一直被事务持有共享锁，导致其他事务无法获取A的排它锁。

根据粒度区分：     1.表级锁：开销小，加锁快，不会出现死锁；锁的粒度大冲突概率高，并发度低；     2.行级锁：开销大，加锁慢，会出现死锁； 锁的粒度小冲突概率低，并发度高；     3.页面锁：介于表锁和行锁之间，也会出现死锁；

MyISAM只支持表级锁：select之前默认给涉及的所有表加读锁；增删改之前默认给涉及的所有表加写锁

InnoDB支持表锁、行锁： 行锁是通过给索引加锁实现的，如果没有索引，则使用表锁。有如下两种类型的行锁：            1.共享锁(S)：事务T对数据A加共享锁，其他事务只能对A加共享锁但不能加排他锁    (读操作加共享锁)            2.排他锁(X)：事务T对数据A加排他锁，其他事务对A既不能加共享锁也不能加排他锁   (增删改操作加排它锁)     同时InnoDB还使用间隙锁(next-key)：用范围条件检索时，属于条件范围内但是不存在的记录也会被加锁。作用：防止发生幻读。

三、MVCC  

  多版本并发控制：Multi-Version Concurrency Control.           1. 通过保存数据快照的方式来实现并发控制。每个用户连接数据库时，看到的都是某一特定时刻的数据库快照。           2. 其他事务拥有P的更早的读时间戳RTS的情况下，当前事务不能完成写操作。           3. 在读写并发完成之后，实现旧版本的删除。           4. 版本号随着每次事务的开启自增。读版本号小于当前事务版本的数据；过期版本号大于当前版本的数据(确保读的数据在事务开始之前未删除)。           5. InnoDB有MVCC，MyISAM没有。myisam的表任何行都只有一个版本，所以select count(*)直接出结果；innodb需要用索引或者全表扫，过滤掉已被删除的行。           6. 优点：读操作不会被阻塞； 缺点：同一份数据存储多个版本，冗余开销；

四、ORM框架

    1. Object Relational Mapping 对象关系映射，描述对象和数据库之间映射的元数据，将程序中的对象自动持久化到关系数据库中，数据持久层框架。(对象和数据库之间的桥梁)

    2. 类 --> 表                类的属性 --> 表字段                  类的对象 --> 表中的一条数据