主从复制

• 

• 主从复制是指将主数据库的DDL和DML操作通过二进制日志传到从数据库上，然后在从数据库上对这些日志进行重新执行，从而使从数据库和主数据库的数据保持一致。

• 主要涉及三个线程：binlog 线程、I/O 线程和 SQL 线程。

  • binlog 线程(主库) ：负责将主服务器上的数据更改写入二进制日志（Binary log）中。
  • I/O 线程(从库) ：负责从主服务器上读取二进制日志，并写入从服务器的中继日志（Relay log）。
  • SQL 线程(从库) ：负责读取中继日志，解析出主服务器已经执行的数据更改并在从服务器中重放（Replay）。

读写分离

• 主服务器处理写操作以及实时性要求比较高的读操作，而从服务器处理读操作。
  读写分离能提高性能的原因在于：
  • 主从服务器负责各自的读和写，极大程度缓解了锁的争用；
  • 从服务器可以使用 MyISAM，提升查询性能以及节约系统开销；
  • 增加冗余，提高可用性。
    读写分离常用代理方式来实现，代理服务器接收应用层传来的读写请求，然后决定转发到哪个服务器。

分库分表

• 需要进行分库分表的情况
  • 大量请求阻塞:在高并发场景下，大量请求都需要操作数据库，导致连接数不够了，请求处于阻塞状态。
  • SQL 操作变慢：如果数据库中存在一张上亿数据量的表，一条 SQL 没有命中索引会全表扫描，这个查询耗时会非常久。
  • 存储出现问题:业务量剧增，单库数据量越来越大，给存储造成巨大压力。
  • 业界一般认为超过500万就需要做分表操作

分库

• 按业务分库
• 按表分库

分表

MySql内部分表方案

• 对id进行Hash

水平拆分

• 按月分表
• 按天份表

水平拆分的问题

• 分布式全局唯一ID
• 分片键选择
  • 选择分片键时，需要先统计该表上的所有的 SQL，尽量选择使用频率且唯一值多的字段作为分片键，既能做到数据均匀分布，又能快速定位到数据位置，例如user_id，order_id等。
• 数据扩容
  • 举个例子，目前交易数据库 trade 中的订单表 orders 已经做了水平分库（位于两个不同RDS实例上），这时发现两个 RDS 写入性能还是不够，需要再扩容一个RDS，同时将 orders 从原来的 20 个子表扩容到 40个（user_id % 40），这就需要迁移数据来实现数据重平衡，既要停机迁移数据，又要修改代码，有点出力不讨好的感觉啦。
• 跨库Join
• 跨库排序分页

垂直拆分

• 按照冷热字符进行垂直拆分

垂直拆分的问题

• 跨库Join问题
  • 全局表
  • 数据同步
• 分布式事务问题
  • 本地消息表
    • 消息生产方：需要额外建一个消息表，并记录消息发送状态，消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过 MQ 发送到消息的消费方，如果消息发送失败，会进行重试发送。
    • 消息消费方：需要处理这个消息，并完成自己的业务逻辑，此时如果本地事务处理成功，表明已经处理成功了，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作。

数据库设计

• 需求分析
• 构建E-R图
• 数据库三范式 外键
• CDM（概念数据模型）->LDM（逻辑数据模型）->PDM（物理数据模型）->Database
• 数据库选型
  • 数据库方面主要包括数据存储，检索，安全，读写分离，分库分表，数据归档，接入数据仓库都要进行确认