摘要：个人对分布式系统的涉及很感兴趣，但分布式系统涉及的知识非常多，刚开始学习时也是各个点分散的学习。前两天对于数据拆分这一块做了一个总结，因此记录下来。
个人对分布式系统的涉及很感兴趣，但分布式系统涉及的知识非常多，刚开始学习时也是各个点分散的学习。前两天对于数据拆分这一块做了一个总结，因此记录下来。
技术出现的原因都是为了解决问题，本文章也是按照这个思路去探讨的。
为什么需要将数据库内的数据进行拆分一台机器的处理能力有限，当数据量大了后性能下降，而且硬件单机成本不高。
如何拆分垂直分库(根据业务单元的不同把表分到不同的主机，单台机器能够处理的请求数量有限)
水平分表(当一张表的数据多了之后查询效率就会很慢，可以根据字段范围划分不同的表，学生表的id字段，1~10000分为一张表，10000~20000分为另一张表)
拆分带来的问题单机ACID打破，引入了分布式事务(难点)
join操作困难，查询跨库
自增id受到困难
解决方案
分布式事务：两阶段提交(2pc),大概意思就是分布式系统中有一个事务管理器(TM),执行分布式事务时向每个资源申请，资源返回全都OK后再向每个资源提交事务，同样等待每个资源返回OK后就完成事务，其中任何一个环节出现erro则回滚。 坏处很明显性能太差，高并发系统根本不能使用。
业界现使用消息队列来解决分布式事务(RocketMQ)具体步骤如下：
1.MQ发送方发送消息到MQServer
2.MQServer接收并回应,表明以成功到达
3.MQ发送方Commit本地事务
4.若Commit成功则通知MQServer该消息可被消费，失败则表明该消息应被丢弃
5.若MQ发送方超时未对MQServer发送状态，则主动回查事务状态
跨库join操作：转化为多个数据库的查询，我们设计数据库时也应尽量避免产生跨库操作。
自增id：多带带做一个id生成器的服务，对于每次请求还可以分配一段id，减少请求次数，增加速度。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/68040.html
摘要：为了帮助用户更好地完成消费决策闭环，马蜂窝上线了大交通业务。现在，用户在马蜂窝也可以完成购买机票火车票等操作。第二阶段架构转变及服务化初探从年开始，整个大交通业务开始从架构向服务化演变。 交通方式是用户旅行前要考虑的核心要素之一。为了帮助用户更好地完成消费决策闭环，马蜂窝上线了大交通业务。现在，用户在马蜂窝也可以完成购买机票、火车票等操作。 与大多数业务系统相同，我们一样经历着从无到有...
阅读 1890·2021-11-24 09:39
阅读 2534·2021-10-14 09:43
阅读 3317·2021-10-08 10:10
阅读 2264·2021-09-22 15:54
阅读 2339·2019-08-29 17:20
阅读 1573·2019-08-28 18:14
阅读 2373·2019-08-26 13:28
阅读 1111·2019-08-26 12:16
