锁，分库分表，读写分离，主从同步

锁

1.在关系型数据中，数据库锁分为行级锁（innodb引擎，分为共享锁和排他锁），表级锁（MYISAM引擎和innodb）和页级锁（BDB引擎）。

共享锁又称为读锁，共享锁可以同时加上多个；

排他锁又称作写锁，只可以加一个，和排他锁，共享锁都互斥。

悲观锁：在查询完数据就把事务锁起来，直到提交事务。设用于写多的情况。

乐观锁：在修改数据时把事务锁起来，通过version的方式来锁定。一般用版本号或者CAS实现。适合于写少读多。

2.innobd是基于索引完成行锁

for update是在数据库中上锁用的，可以为数据库中的行上一个排它锁。当一个事务的操作未完成时候，其他事务可以读取但是不能写入或更新。

3.死锁的解决：对同一资源相互占用并请求对方资源

（1）指定程序以相同顺序访问表；

（2）同一事务中，尽可能做到一次锁定所需的所有资源；

（3）尝试升级锁颗粒度，通过表级锁减少死锁的概率；

（4）业务处理不好可以用分布式事务锁或者乐观锁；

 MVCC可以实现事务中的查询不用加锁，只在读提交和可重复读两种隔离级别。

分库分表

1.分表：把一个表的数据放到多个表中，查的时候就查一个表。比如按照ID分表，将一个用户的数据放在一个表中。200万以内。

 分库：单库的并发值保持在每秒1000.

 2.分库分表的中间件

最常用的mycat，基于cobar（阿里的被抛弃了），属于proxy层方案。

还有sharding-jdbc，属于client层

3.对数据库进行垂直拆分或水平拆分

水平拆分就是把一个表的数据弄到多个库多个表，表的结构都一样，所有库的数据加起来就是全部数据。提高并发量，还可以用来进行扩容。

垂直拆分：把一个有很多字段的表拆分多个表，或者多个库上。每个库表的结构都不一样，都包含部分字段。一般按照字段的访问频率去分表。因为数据库是有缓存的，访问频率高的行字段越少，就可以放更多的行，性能越好。

两种分库分表的方式：

（1）按照range划分，每个库一段连续的数据，一般按时间范围，但是容易产生热点问题，大量流量都打到最新数据。

（2）常用的按照某个字段的hash一下均匀分散。可以平均分配每个库的压力；坏处是扩容比较麻烦，有一个数据迁移的过程。之前的数据要重新计算hash重新分配。

读写分离，主从同步

 1.主从同步可以使一个数据库服务器复制到其他服务器上。复制是异步进行的，所以从服务器不需要一直连着主服务器。通过配置文件，可以指定复制哪个数据库或表。

目的：

（1）提高性能，主服务器负责写和更新，从服务器负责读，并且从服务器的数量可以动态调整。

（2）提高数据安全性，可以在从服务器备份还不破坏主服务器。

（3）在主服务器生成实时数据，在从服务器分析这些数据，提高主性能；

（4）数据备份，可以及时备份，还可以备份在不同地方，安全。

2.MySQL读写分离实现

主从复制架构

3.MySQL主从复制流程

主要是三个线程：

主：binlog线程，记录改变数据的语句，放在master的binlog中；

从：IO线程，在使用start slave后，从master上拉取binlog内容，放入自己的relay log（中继日志）中。

从：SQL执行线程，执行relay log语句。

relay-log的结构和binlog非常相似，只不过他多了一个master.info和relay-log.info的文件。

master.info记录了上一次读取到master同步过来的binlog的位置，以及连接master和启动复制必须的所有信息。

relay-log.info记录了文件复制的进度，下一个事件从什么位置开始，由sql线程负责更新。

具体流程：

（ 1）.master在每个事务更新数据完成前，将操作记录在binlog文件中。

（2）从开启IO线程去binlog dump process。如果读取进度跟上master就进入睡眠等待master新事件，最终就是把事件写入relay中继日志中。

（3）SQL线程开始读中继日志，顺序执行SQL事件，产生和主一样的数据结构。

4.主从延时问题解决

MySQL有两个同步机制

（1）半同步复制，解决主库数据丢失问题，主库写入binlog日志后，强制立即同步到从库，从库写入relaylog中，发出一个ack给主库，主库接受到至少一个从库的ack才会认为写操作完成。

（2）并行复制，解决主从延时问题，从库开启多个线程，并行读取relaylog中不同库的日志，然后并行重放不同库的日志，库级别的并行。