Sharding改造的背景

随着用户规模的不断扩大，单库的性能瓶颈会逐渐暴露，数据库的检索效率会越来越慢，出现大量的慢SQL，一旦单库出现宕机，业务将随着进入瘫痪。使用NoSQL是其中一种解决办法，这里关注于关系型数据库的解决方案。如何提高关系型数据库的并行处理能力和查询效率成为了架构师需要思考和解决的问题。对数据库实施分库分表，即Sharding改造，便是一种常用的解决方案。

关系型数据库的架构演变

关系型数据库的主要瓶颈：

1. 大量的并发读写操作，导致单库出现极大的负载
2. 单表存储数据量过大，导致检索消息低

读写分离

刚上线的业务系统通常业务量不大，一般使用单库存储数据，随着业务量的上升，单库组件力不从心，为了保证可靠性和性能，演变成一主一从或者一主多从的架构，主从通过同步机制同步数据，并且将数据库的读写操作分离，写操作在master节点进行，读操作在slave节点进行。

缺点：主从之间的同步延迟是这种数据库架构的关键问题，最好保证写入操作能够先缓存一份防止从从库获取不到指定数据的问题。

二八原则：80%的操作是读操作，只有20%为写操作

垂直分库

主从读写分离的架构在一定程度上缓解了业务量的问题，但不能一劳永逸，需要根据具体业务对数据库进行分库，实现分而治之的数据管理和读写操作。

数据库分库

缺点：单一业务的数据仍然落在单表中，读操作性能依旧会很慢

水平分库与水平分表

针对单表数据过大的解决方案是水平分表，将原本冗余在单个业务表拆分为n个“逻辑相关”的业务子表，不同的业务子表各自负责存储不同区间的数据，对外形成整体，即sharding操作。

水平分表之后，如果master节点的负载还是过高，可以考虑进行水平化扩展，将分表后的子业务按照某种特定的算法和规则分散到不同的子业务库中。

缺点： 实施相对复杂，需要专门的Sharding中间件负责数据的路由工作。

数据库分库分表

Sharding与Cluster的区别

• Cluster: 集群模式，只是扩展了数据库的并行处理能力，并且成本高
  了解更多
• Sharding：成熟而实惠的方案，可以提升数据库的并行处理能力，还能解决因为单表数据量过大所产生的检索瓶颈

Sharding中间件

Sharding中间件用于数据的路由，明确定义SQL语句中的路由条件是非常重要的，它直接决定了数据的落盘位置。其次，应该如何根据所定义的路由条件进行路由，需要定义一套特定的路由算法和规则。目前业界拥有许多常用的Sharding中间件，包括MyCat、Shark、Cobar等。

MyCat

MyCat是一个开源的分布式数据库中间件，支持数据库读写分离，可以实现数据库的高可用，并且支持数据库的垂直分表和水平分库分表。架构图如下：

MyCat架构

通过将MySQL语句根据路由规则进行重写和重定向分配到指定的数据库进行数据库操作。

例如：

MyCat实例

将prov设置为mycat的路由规则，根据prov值的不同路由到不同的DB，对于SQL语句：

select * from orders where prov = 'wuhan'

将被mycat重定向为:

select * from DB1.orders where prov = 'wuhan'

并分配到指定的DB上执行和返回。

总结

以上只是Sharding的简单介绍，具体深入的通过需要阅读更多的书籍和博客，最重要的进行实战操作，这块个人待补充。