一 数据库从单机到分布式的挑战和应用
1 单机数据库
JDBC ODBC ORM
2 数据库水平垂直/水平拆分的困难
数据库减压方案： 优化应用（看是否有没必要的压力给数据库）
其他办法降低对数据库的压力（引入缓存，搜索引擎）
数据拆分（垂直拆分 水平拆分）
垂直拆分带来的影响：单机ACID被打破 引入分布式事务
join操作困难
靠外键约束场景收到影响
水平拆分带来的影响：除了和垂直拆分带来的影响一样外，还有
依赖单库的自增序列生产唯一ID受影响
针对单个逻辑的表查询需要跨库
3 分布式事务
分布式事务模型与规范：分布式事务规范 XA
分布式事务处理模型 DTP模型
DTP模型：Distributed Transaction Processing Reference Model
定义了三个组件：Application Program
Resource Manager
Transaction Manager
Application Program(AP) 应用程序
Resource Manager（RM） 资源管理器 可以理解为一个DBMS系统
AP通过RM对资源进行控制
Transaction Manager（TM） 事务管理器
提供给AP应用程序编程接口并管理RM
注：如何实际应用？
两阶段提交（2PC）：提交阶段前增加准备阶段
CAP/BASE理论： C Consistency 数据上的一致性，当数据写入成功后，所有节点会同时看到这个数据
A Availability 无论成功或失败，请求都能收到一个反馈（可用性）
P Partition-Tolerance 系统的一部分出现问题时，系统仍能正常工作（分区容忍性）
CAP不能同时满足 选择CA AP 或者CP（一般选择AP）
BASE：Basically Available 基本可用
Soft state 软状态
Eventually consistent 最终一致（选择AP后 一致性通过最终一致解决）
Paxos协议：比两阶段提交要轻量的保证一致性的协议
4 多机的Sequence问题与处理
针对数据水平分库后，原来单库中的Sequence及自增Id的做法需要改变
Id：唯一性 连续性
唯一性：UUID 但是连续性不好
连续性：架设Id生成器，每次取ID都从这台机器上取
这样会带来问题 性能问题（每次远程取ID都有资源损耗） 改进方案 取一段ID缓存在本地
稳定性问题 Id生成器作为一个无状态集群存在，可用性要靠整个集群保证
存储问题
优化：将生成器嵌入到应用中，直接在独立的存储中取ID
5 多机的数据查询
跨库join：JOIN操作分为多次操作
数据冗余：对常用信息进行冗余
借助外部系统（如搜索引擎）
外键约束
跨库查询
二 数据访问层的设计与实现
在分布式系统中，数据访问层也称为分布式数据访问层
1 如何对外提供数据访问层功能
专有API 通用JDBC方式 基于ORM或者类ORM接口形式
2 按照数据层流程顺序看数据层设计
流程：SQL解析 规则处理 SQL改写 数据源选择 SQL执行 结果集返回
SQL解析阶段：考虑 对SQL支持程度
支持多少种SQL语言
规则处理阶段（分库分表规则）：采用固定哈希算法作为规则
采用一致性哈希算法
SQL改写：不同库中表名 索引名可能雷同
选择数据源：根据要执行的SQL特点 是否在事务中以及各个库的权重规则
执行SQL和处理结果
3 独立部署的数据访问层实现方式
对应用呈现的方式：Jar包方式/Proxy方式
4 读写分离的挑战和应对
目的：分担主库的读压力
261
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
