目录
分片
数据库分片概述
-
什么是数据切分：
将数据量大的表或表比较多的数据库切分成多个部分放到同一数据库不同表、同一数据库实例节点不同数据库或不同数据库实例节点上 -
为什么要数据切分
优点：分散单台设备的负载，提高数据的安全性，性能
缺点：增加系统复杂度，跨节点Join，跨节点的count,order by,group by以及聚合函数问题）
分片策略
- 分片枚举
- hash
- 约定范围
- 取模
- 按日期分片
分片需要解决的问题
事务问题
什么是分布式事务
分布式事务就是指事务的参与者、资源服务器以及事务管理器分别位于不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务节点或资源节点上，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。
分布式事务产生的原因
从上面事务概念来看，分布式事务产生的原因是因为跨网络通信，我们可以看为两块，一个是service产生多个节点，另一个是resource产生多个节点。
service多个节点
随着互联网快速发展，微服务，SOA等服务架构模式正在被大规模的使用，举个简单的例子，一个公司之内，用户的资产可能分为好多个部分，比如余额，积分，优惠券等等。在公司内部有可能积分功能由一个微服务团队维护，优惠券又是另外的团队维护
这样的话就无法保证积分扣减了之后，优惠券能否扣减成功。
resource多个节点
同样的，互联网发展得太快了，我们的Mysql一般来说装千万级的数据就得进行分库分表，对于一个支付宝的转账业务来说，你给的朋友转钱，有可能你的数据库是在北京，而你的朋友的钱是存在上海，所以我们依然无法保证他们能同时成功。
解决事务问题可行的方案：
分布式事务和通过应用程序与数据库共同控制实现事务下面对两套方案进行一个简单的对比。
方案一：使用分布式事务
优点：交由数据库管理，简单有效
缺点：性能代价高，特别是shard越来越多时 ，对跨service不适用
方案二：由应用程序和数据库共同控制
原理：将分布式事务分拆成多个小事务，每个小事务仅处 於单个数据库上面的，并通过应用程序来总控 各个小事务。 优点：性能上有优势
缺点：需要应用程序在事务控制上做灵活设计。如果使用 了spring的事务管理，改动起来会面临一定的困难。
方案一：
- 全局事务（数据库XA协议）
方案二：
- 异步消息最终一致型
- TCC（两阶段提交型，补偿型）
- 最大努力通知型
跨节点Join的问题
只要是进行切分，跨节点Join的问题是不可避免的。但是良好的设计和切分却可以减少此类情况的发生。解决这一问题的普遍做法是分两次查询实现。在第一次查询的结果集中找出关联数据的id,根据这些id发起第二次请求得到关联数据。
跨节点的count,order by,group by以及聚合函数问题
这些是一类问题，因为它们都需要基于全部数据集合进行计算。多数的代理都不会自动处理合并工作。解决方案：与解决跨节点join问题的类似，分别在各个节点上得到结果后在应用程序端进行合并。和join不同的是每个结点的查询可以并行执行，因此很多时候它的速度要比单一大表快很多。但如果结果集很大，对应用程序内存的消耗是一个问题。
全局序列号
可靠性是周期内正常运行的概率
可用性是从灾难中恢复的时间
提高可靠性需要强调减少系统中断（故障）的次数，提高可用性需要强调减少从灾难中恢复的时间。
示例：
A系统每年因故障中断十次，每次恢复平均要20分钟，B系统每年因故障中断2次，每次需5小时恢复。则A系统可用性比B系统高，但可靠性比B系统差。