数据访问层

• 单机数据库

数据库减压：

• 硬件升级（简单粗暴、效果明显、很快进入瓶颈，解决不了）
• 其余三思路：
  • 优化应用（是否给了数据库没必要要的压力）
  • 是否有其余办法减轻数据库的压力（引入缓存、搜索引擎）
  • 把数据库的数据和访问分布多台机器上
    • 垂直拆分（不一样业务单元拆分到不一样的库里）
      • 带来影响：
        • 单机ACID 变得复杂
        • Jion操做变得困难
        • 靠外键约束场景受影响
    • 水平拆分（按照必定规则，把统一业务单元数据拆分到不一样库里面）
      • 带来影响：
        • 单机ACID 变得复杂
        • Jion操做变得困难
        • 靠外键约束场景受影响
        • 单库的自增id 惟一序列受影响
        • 单个逻辑意义上表的查询要跨库

分布式事务x/open DTP模型

 

• 2PC（两阶段正常提交）

• 2PC（回滚状况）

CAP理论：

• 一致性
• 可用性
• 分区容错性

BASE理论：

• 选择AP 对于C ，确保最终一致性就好

Paxos 协议：

• 比两阶段更加轻量级的一致性协议
• 分布式系统中，节点之间信息交换有两种方式：
  • 共享内存
  • 信息投递
    • 分布式系统中，信息投递会发生不少意外：网络问题、进程挂掉、反应很慢、进程重启、机器挂掉等
• 不存在拜占庭将军问题（即：通讯环境不可靠）
• 本人已有博客专门讨论该问题，不作赘述

集群内数据一致性算法：

Quorum算法（权衡分布式系统中数据一致性和可用性的）

• W+R>N 强一致性
• W+R<=N最终一致性 

Vector Lock算法

• 对同一份数据的修改，每次都加上<修改者，版本号>
• 好比：能看书Dave 的建议版本2最新

多机 Sequence 问题与处理

• 单机序列不是问题，分库分表后成为问题
  • 连续性
  • 惟一性
    • 单考虑惟一性，UUID
• 分布式系统中，能够考虑作一个独立的系统来完成该工做（ID生成器）
  • 存在问题须要解决：
    1. 性能问题
       • 每次远程取id 会有资源消耗（改进：每次取一段id，缓存到本地；可是取了后不用会照成浪费）
    2. 生成器稳定性问题
       • id 生成器做为一个无状态集群，其可用性要靠整个集群来保证
    3. 存储的问题
       • 选择空间大，须要根据不一样类型对应不一样的容灾方案

• 改进：省掉单独的id 生成器，这样数据可能不是严格的顺序增加的，须要额外的管理

应对多机的数据查询：

• 跨库join：
  • 在应用层，把原来join 操做分红多个数据库操做
  • 对经常使用数据进行冗余，变跨库为单表
  • 借助外部系统解决一些跨库问题，好比：搜索引擎
• 外键约束
  • 比较难解决，不能彻底依靠数据库自己，须要应用程序的合做

跨库查询问题及解决：

• 具体要参看如何分库分表的
• 排序
  • 各路先排好序、再多路归并排序
• 函数处理
• 求平均值
  • 多数据源求和后，再算平均值
• 非排序分页
  • 同等步长
    • 数字表明所在页数
  • 同等比例
    • 数字表明所在页数
• 排序后分页
  • 各个数据源排序，归并
  • 大型系统请尽可能避免

数据访问层，简称数据层：

• 数据读写的抽象层
• 对外提供访问层方式：
  • 第一种：为用户提供专有API（不推荐，通用性不好），即使采用也要提供通用方式
  • 第二种：通用方式，Java提供JDBC
  • 还有一种，基于ORM类或ORM接口的形式（myBatis、hibernate、springJDBC）

• 合并排序查询场景下，取一页4条数据，须要在每个数据源取4条做比较，取出排在最前面的4条
  • 主要是要考虑极端状况，有可能某一数据源的4条数据就是要的4条
  • JDBC 的方式实现
    • 使用jdbc 的方式，能够设置每次取回的数据，作链式排序，分屡次查询取回（要考虑网络平衡）

按照数据流程的顺序，看数据层设计

• 规则处理

• 一致性哈希算法
  • 把节点对应的hash 值变成一个范围
  • 减去一个节点（范围），变成：
    • 第一和第四管理的数据没影响，第三也没影响，把第二映射到第三就好
  • 增长一个节点道理相似

• 增长节点时，只有一个节点受影响，增长节点和受影响节点负载明显低于其余
• 减小节点反之

虚拟节点对一致性hash 进行改进

• 4个物理节点变成多个虚拟节点，增长一个物理节点就会增长相应的多个虚拟节点
• 这些插入的虚拟节点均匀分配到5个物理节点上

映射表与规则自定义计算

• 通常用于热点数据的特殊处理

自定义规则计算是最灵活的方式

########################

分库分表没有统一的规则

• 原则是分库后尽可能避免跨库查询

数据源管理多个分库

• spring 配置多个数据源
  • 能够考虑在配置管理中心统一配置

• 数据源分组

• 管理单库的数据源
  • 能够把单个数据源配置集中起来统一存储
  • 机房迁移改ip很是方便
  • 禁止某些sql的执行等

• 三层数据源总体视图

• 独立部署的数据访问层

• 读写分离带来的挑战

• 主库从库非对称场景

• 得到消息后开始进行数据的复制（行复制）
  • 不优雅，优雅的方式应该采用基于数据库日志进行数据复制

• 数据库复制在读写分离中是比较关键的任务
  • 也有非对称场景：
    • 主从不是镜像关系
    • 主从采用不一样库

• 数据变动平台

• 数据平滑迁移
  • 扩容、缩容不能接受长时间停机：
    • 平滑迁移
      • 最大挑战：迁移过程当中又会有数据变化
      • 能够考虑方案：
        • 在开始进行数据迁移时，记录增量的日志，迁移结束后再对增量的变化进行处理
        • 最后被迁移数据的写暂停，保证增量数据处理完毕，再放开