分库分表条记
海量数据的存储与访问会是体系设计与使用的瓶颈，数据往往存储在数据库中，传统的数据库存在着天赋的不足，即单机（单库）性能瓶颈，并且扩展起来非常的困难。假如单机数据库易于扩展，数据可切分，就可以制止这些问题，但是当前的这些数据库厂商，包括开源的数据库MySQL在内，提供这些服务都是须要收费的，以是转向一些第三方的软件，使用这些软件做数据的切分，将原本在一台数据库上的数据，分散到多台数据库当中，降低每一个单体数据库的负载。1 数据库读写分离
随着互联网技能的发展，人们发如今互联网的体系应用是一个读多写少的应用，比如电商体系，商品浏览的次数是比下单要多的。数据库承载压力大，主要是由这些读的请求造成的，那么是不是可以把读操作和写操作分开，让所有读的请求落到专门负责读的数据库上，所有写的操作落到专门负责写的数据库上，写库的数据同步到读库上，这样保证所有的数据修改都可以在读取时，从读库获得。
假如体系的读请求比较多的话，读库可以多摆设几台，这样读请求就可以均派到多台读库上，降低每一个读库上的压力。但是在写数据的时间，数据要落在一个确定，且唯一的写库中。固然可以摆设多个写库，但是数据怎么分片是一个十分重要的问题，如今仅以一个写库为例，比如：商户发布商品时，将这个商品的数据落在了写库上，同时，写库将这条数据同步给两个读库，买家在网站浏览商品时，会从读库将这个商品数据读取。至于从哪个读库取出数据，那就要看这个请求在当时的路由情况了。
读写分离带来的利益是很多的，对比一下原始的架构和读写分离的架构，从数据流上看，他们的区别是，数据从写入到数据库，到从数据库取出，读写分离的架构多了一个同步的操作。想一想，同步操作的时间是多少，耽误假如太大对体系有没有影响，假如同步挂了怎么办？这就是读写分离的弊端，当同步挂掉，大概同步耽误比较大时，写库和读库的数据差别等，这个数据的差别等，用户能不能接受，订单支付状态这个差别等固然是不能接受的了，其他的业务场景能不能接受呢？这个要对差别的业务场景做详细的分析了。
一些对数据实时性要求不高的业务场景，可以考虑使用读写分离。但是对数据实时性要求比较高的场景，比如订单支付状态，除非网络耽误应该在 5ms 以内，这个对网络情况要求是非常高的，不然还是不发起接纳读写分离的，大概在写步伐时，老诚实实的从写库去读取数据。
2 数据库数据切分
数据切分，就是通过某种条件，将之前存储在一台数据库上的数据，分散到多台数据库中，从而到达降低单台数据库负载的效果。数据切分，根据其切分的规则，大致分为两种类型，垂直切分和水平切分。
2.1 垂直切分
垂直切分就是按照差别的表切分到差别的数据库中，比如：订单表 order 和商品表 product 原本是在同一个数据库中，如今要对其切分，使得订单表和商品表分别落到差别的物理机中的差别的数据库中，使其完全隔离，从而到达降低数据库负载的效果。
垂直切分的特点就是规则简单，易于实施，可以根据业务模块进行划分，各个业务之间耦合性低，相互影响也较小。
一个架构设计较好的应用体系，其总体功能肯定是有多个差别的功能模块组成的。每一个功能模块对应着数据库里的一系列表。比方商品功能模块对应的表包括：类目、属性、属性值、品牌、商品、sku等表；而在订单模块中，对应的表包括：订单、订单明细、订单收货地点、订单日志等。
在架构设计中，各个功能模块之间的交互越统一、越少越好。体系模块之间的耦合度会很低，各个体系模块的可扩展性、可维护性也会大大提高。这样的体系，实现数据的垂直切分就会很容易。
但是，在实际的体系架构设计中，有一些表很难做到完全的独立，往往存在跨库 join 的征象。比如我们接到了一个需求，要求查询某一个类目产生了多少订单，假如在单体数据库中，我们直接连表查询就可以了。但是如今垂直切分成了两个数据库，跨库连表查询是十分影响性能的，也不保举这样用，只能通过接口去调取服务，这样体系的复杂度又升高了。对于这种很难做到完全独立的表，作为体系架构设计人员，就要去做平衡，是数据库让步于业务，将这些表放在一个数据库当中？还是拆分成多个数据库，业务之间通过接口来调用呢？在体系初期，数据量比较小，资源也有限，往往会选择放在一个数据库当中。而随着业务的发展，数据量到达了一定的规模，就有须要去进行数据的垂直切分了。而如何进行切分，切分到什么水平，则是对架构师的一个艰难的考验。
垂直切分的优点：
[*]拆分后业务清晰，拆分规则明确；
[*]体系之间容易扩展和整合；
[*]数据维护简单
缺点：
[*]部分业务表无法 join，只能通过接口调用，提升了体系的复杂度；
[*]跨库事务难以处理；
[*]垂直切分后，某些业务数据过于巨大，仍旧存在单体性能瓶颈；
2.2 水平切分
水平切分相比垂直切分，更为复杂。它须要将一个表中的数据，根据某种规则拆分到差别的数据库中，比方：订单尾号为奇数的订单放在 订单数据库1 中，而订单尾号为偶数的订单放在 订单数据库2 中。这样，原本存在一个数据库中的订单数据，被水平的切分成了两个数据库。在查询订单数据时，我们还要根据订单的尾号，判定这个订单在 数据库1 中，还是在 数据库2 中，然后将这条 SQL 语句发送到正确的数据库中，查出订单。
水平拆分数据，要先订单拆分的规则，要按哪个维度去拆分，比如按订单尾号的奇偶去拆分，那么这样拆分会有什么影响呢？假如我是一个用户，我下了两个订单，一个订单尾号为奇数，一个订单尾号为偶数，这时，我去个人中心，订单列表页去检察我的订单。那么这个订单列表页要去怎么查，要根据我的 用户id 分别取 订单1库 和 订单2库 去查询出订单，然后再合并成一个列表，是不是很贫苦。以是，咱们在拆分数据时，一定要联合业务，选择出适合当前业务场景的拆分规则。那么按照 用户id 去拆分数据就合理吗？也不一定，比如：身份变了，不是买家了，而是卖家，这个卖家有很多的订单，卖家的后台体系也有订单列表页，那这个订单列表页要怎么样去查？是不是也要在所有的订单库中查一遍，然后再聚合成一个订单列表呀。那这样看，是不是按照 用户id 去拆分订单又不合理了。以是在做数据水平拆分时，是对架构师的真正考验。
水平拆分的优点：
[*]解决了单库大数据、高并发的性能瓶颈；
[*]拆分规则封装好，对应用端几乎透明，开辟人员无需关心拆分细节；
[*]提高了体系的稳固性和负载本事；
缺点：
[*]拆分规则很难抽象；
[*]分片事务同等性难以解决；
[*]二次扩展时，数据迁移、维护难度大。比如：开始我们按照 用户id 对2求模，但是随着业务的增长，2台数据库难以支撑，还是继承拆分成4个数据库，那么这时就须要做数据迁移了。
2.3 总结
无论是垂直切分，还是水平切分，它们解决了海量数据的存储和访问性能问题，但也随之而来的带来了很多新问题，它们的共同缺点有：
[*]分布式的事务问题；
[*]跨库 join 问题；
[*]多数据源的管理问题
针对多数据源的管理问题，主要有两种思路：
[*]客户端模式，在每个应用模块内，设置自己须要的数据源，直接访问数据库，在各模块内完成数据的整合；
[*]中间署理模式，中间署理统一管理所有的数据源，数据库层对开辟人员完全透明，开辟人员无需关注拆分的细节。
基于这两种模式，如今都有成熟的第三方软件，接下来在我们的视频中，会分别给各人介绍这两种模式的代表作：
[*]中间署理模式：MyCat
[*]客户端模式：sharding-jdbc
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]