本文就分库分表的产生背景、一些通用的分库分表的涉及记录做一下简要的理解和阐述。
为什么的需要分库分表
在分布式架构中，随着数据量的不断上升和用户量的不断累加，原先数据库的单点（很多为了数据库的高可用只是做了简单的读写分离）设计早就已经不够用使用数据库的三个阶段
第一阶段：单库单表
第二阶段：单库多表
比如一个User 表，当数据量增加的时候，查询出现很慢的情况，增加和删除索引的代价太大，就可以考虑把User表分为 User_1 ,User_2 ....这时候可以放在不同的实例里面，也可以放在同一个实例里面。第三阶段：多库多表
微服务的设计思路里面就是每个服务有自己的数据库。
分而治之
数据库拆分的两个方式就是
垂直拆分：一个数据库实例多个表组成，需要按照业务的使用不同把表拆分成多个分类，分布到多个数据库实例，达到负载均衡的效果。专人干专事。
水平拆分 ：同一个表中的数据分散到多个数据库实例里面。简单来说就是拆分成User_1 ,User_2 .... 与原有结构相同。多个人干一件事。
冷热分离的角度去拆分
冷数据：查询多，变更少，推荐使用引擎MyISAM，可配置多个从库缓解读取的压力
热数据：查询和变更都多 推荐使用引擎InnoDB，对于活跃数据，在某些场景下适合使用redis等缓存，比如点赞系统，等到累积一定的量再去跟新数据库。。
读写分离的也是一个拆分角度
分库分表存在的问题
- 存在分布式事务的问题
- 跨界点Join问题
- 跨界点合并数据和分页的问题
- 多个数据源的管理的问题
水平切分的维度选择
- 一致性Hash
为什么使用一致性Hash而不是简单的Hash，为了解决缩容和扩容的问题，
缺点很明显，很难做数据聚合的处理。 - 按照时间切边
在一些场景下面存在数据倾斜的问题，数据的二次查询也存在问题。
垂直切分更加偏向于业务拆分的过程，水平拆分的技术难度相对于比较高。
分片后的查询问题
例如： 用户购买了商品,需要将交易记录保存下来,那么如果按照买家的纬度分表,则每个买家的交易记录都被保存在同一表中,我们可以很快、很方便地查到某个买家的购买情况,
但是某个商品被购买的交易数据很有可能分布在多张表中,查找起来比较麻烦。反之,按照商品维度分表,则可以很方便地查找到该商品的购买情况,但若要查找到买家的交易记录,则会比较麻烦。
- 分片数据聚合，但是这样的效率很低 。
2.记录两份数据，比如在商品服务中，一份买家的维度拆分，一份商品维度拆分。
3.在搜索实时性比较高的情况下，考虑使用搜索引擎，例如采用大数据工具Elasticsearch。
当然查询还有其他变相的方案
电商系统的订单和商品价格的问题
分片后事务处理机制
柔性事务和刚性事务
柔性事务满足BASE理论（基本可用，最终一致）
刚性事务满足ACID理论
二阶段提交协议(2PC)
分为准备阶段和提交阶段
对应技术上的XA、JTA/JTS
缺点比较明显，在准备的时候需要锁定资源，参与者较多的情况下，等待的时间差拉长，影响响应时间，出现死锁的可能性比较大。所以很少使用这个方案
最大努力保证模式
例如商户交易结果通知重试、补单重试
这种模式适用于一致性要求不高但是对性能要求高的场景
1.开始消息事物
2.开始数据库事物
3.接收消息
4.跟新数据库
5.提交数据库事务
6.提交消息事务
如果5失败了那么数据库和消息队列全部回滚，保持一致。
5成功但是6超时失败，这时候出现不一致的现象。可以配合事务补偿模式完成，也就是消息队列的重试机制
事物补偿模式(TCC)
TCC型事务（Try/Confirm/Cancel）可以归为补偿型。补偿型的例子，在一个长事务（long-running）中，一个由两台服务器一起参与的事务，服务器A发起事务，服务器B参与事务，B的事务需要人工参与，所以处理时间可能很长。如果按照ACID的原则，要保持事务的隔离性、一致性，服务器A中发起的事务中使用到的事务资源将会被锁定，不允许其他应用访问到事务过程中的中间结果，直到整个事务被提交或者回滚。这就造成事务A中的资源被长时间锁定，系统的可用性将不可接受。WS-BusinessActivity提供了一种基于补偿的long-running的事务处理模型。还是上面的例子，服务器A的事务如果执行顺利，那么事务A就先行提交，如果事务B也执行顺利，则事务B也提交，整个事务就算完成。但是如果事务B执行失败，事务B本身回滚，这时事务A已经被提交，所以需要执行一个补偿操作，将已经提交的事务A执行的操作作反操作，恢复到未执行前事务A的状态。这样的SAGA事务模型，是牺牲了一定的隔离性和一致性的，但是提高了long-running事务的可用性。
异步确保型
将一些同步阻塞的事务操作变为异步的操作，避免对数据库事务的争用，典型例子是热点账户异步记账、批量记账的处理。
