【数据库】——分布式数据库演变历程

た入场券 2022-05-16 02:16 276阅读 0赞

# 前提 #

本文主要介绍分布式数据库演变历程，以及演变过程的解决方案，没有方案的具体实现步骤。

# 数据库高可用的发展历程 #

1、查询操作比较多，利用缓存，缓解数据库的读压力  
2、写操作成为数据库瓶颈，利用数据库主从复制，在代码中进行读写分离  
3、为了避免写服务器宕机，从而造成写操作异常，进行主主复制  
4、单台不能在支撑系统压力的时候，进行集群扩展，通过负载均衡完成集群均匀分担压力  
5、为了避免宕机对系统影响，搭建高可用集群成为关键。  
6、MySQL的单表最多支撑5000万，为了扩大容量，需要分库分表

# 数据库高可用解决方案 #

**1、添加缓存，缓解数据库查操作。**  
缓存方式有两种，本地缓存，分布式缓存。  
本地缓存通常采用ehcache，分布式缓存通常有两种选择，redis和memcached，关于两者区别请移步[《redis和memcached区别》][redis_memcached]关于分布式缓存和本地缓存的选择，主要针对业务具体商定。ehcache占用的是本地内存，当数据量比较少，而且查询比较频繁，不影响系统内存占用的情况下可以采用，相比分布式缓存效率更高。分布式缓存，数据量比较大，或者对持久化有一定要求的时候可以采用。  
当然最好的方案将redis+ehcache做成两级缓存，推荐案例[《  
Spring+ehcache+redis两级缓存–缓存实战篇（1）》][Spring_ehcache_redis_1]  
**2、主从复制，读写分离**  
主从复制，利用的是MySQL的binlog日志实现。具体方案移步[《【开发进阶】——MySQL配置主从同步，代码层实现读写分离》][MySQL]  
在代码层的实现方案有两种，博客中小编用的时JDBC的方法类型进行判断。还有一种方案利用spring的aop+注解的方式，通过拦截注解，判断操作哪个数据库。一般编辑的方法中标注写库，查询的方法上标注读库，这样代码编写比较复杂，但是代码灵活度比较高。  
**3、主主复制**  
大概实现思路与主从复制一致，利用的同样的时binlog日志。这样保证了写操作的高可用，避免了写服务器宕机，对系统的影响，同时实现了数据库的负载。  
**4、负载均衡集群**  
三种实现方式  
Nginx，采用的Http协议  
LVS，网络依赖比较大，稳定性很高  
HaProxy，支持Http，TCP协议，而且有可视化监控页面  
三者详细的对比请移步[《三大主流软件负载均衡器对比(LVS VS Nginx VS Haproxy)》][LVS VS Nginx VS Haproxy]  
小编采用的时HAProxy，实现MySQL的负载均衡。  
**5、高可用集群**  
数据冗余实现高可用，小编采用的是Keepalived实现高可用。  
**6、分库分表**  
两种分割方式  
垂直切割：根据业务的维度，将原本的一个库或表拆分为多个库或表，每个库或表与原有的结构不同。  
水平切割：根据分片算法，将一个库或表拆分成多个库或表，每个库或表依旧保留原有的结构。  
整理分为三种思路  
1、客户端分片

*  在应用层直接实现  
    非常通用，简单的解决方案，直接在应用层读取分片规则，然后解析分片规则，根据分片规则实现切分的路由逻辑。这种方案侵入业务，但是实现比较简单，适合快速上线，因为切分逻辑是自己开发，所以生产上的问题比较容易解决。但是这样会让数据库保持连接比较多，需要考虑应用服务器的节点数量，需要提前进行容量评估，而且对开发人员能力要求比较高。  
    开源框架dbsplit就是采用这种方式。
 *   通过定制JDBC协议实现  
    通过定制JDBC协议，针对业务层提供与JDBC一致的接口，让开发人员专注业务开发，不再关心分库分表的实现，让分库分表在JDBC的内部实现。但是需要开发人员理解JDBC协议才能实现分库分表逻辑。  
    流程的客户端分库分表框架Sharding JDBC 采用这种方案。
 *  通过定制ORM框架  
    因为关系数据库与面向对象语言之间的差距，ORM框架的广泛使用，就有了通过定制ORM框架实现分库分表的方案。把分片规则实现到ORM框架中或者通过ORM框架支持的扩展机制来实现。一般常用的是通过在Mybatis配置文件的SQL中增加表索引的参数来实现分片。如下：

<select id="getUser" parameterType="java.util.Map" resultType="User">
        select userId,username
            from user_#{index}
        where userId = #{userId}
    </select>

2、代理分片  
在应用层和数据库层增加一个代理层，把分片的路由规则配置在代理层，代理层提供对外提供与JDBC兼容的接口给应用层，应用层的开发人员不用关心分片规则，只需要关心业务逻辑的实现。  
这种方案让开发人员专注于业务逻辑的实现，把分库分表的操作留给代理层做；不足之处：增加代理层，加重了网络传输的负担，还需要维护代理层，以及硬件成本。  
常用代理分片实现框架有Cobar和Mycat等。  
3、支持事务的分布式数据库  
OceanBase，TiDB等数据库对外提供可伸缩的体系架构，并提供分布式事务支持，将可伸缩和分布式事务的实现包装到分布式数据库内部实现，对使用者透明。  
使用分布式数据库的需要综合实际情况，不要盲目的追求技术的实现。  
**分库分表的带来弊端**  
1、如何保证id唯一  
2、配置多数据源  
3、分布式锁的问题  
4、分布式事务的问题  
当然这些问题均有解决的方式，但是也这说明了事物的两面性。小编的公司采用的是MyCat中间件解决，针对分库分表这一部分的使用小编还会在后续博客中持续更新！

# 总结 #

关于分布式不要一口吃个胖子，针对业务，数据，实际情况具体分析，原则就是兵来将挡水来土掩，相信问题终会有解决方案的。

[redis_memcached]: https://blog.csdn.net/jiadajing267/article/details/81274634
[Spring_ehcache_redis_1]: https://blog.csdn.net/liaoyulin0609/article/details/51787020
[MySQL]: https://blog.csdn.net/jiadajing267/article/details/81271688
[LVS VS Nginx VS Haproxy]: https://www.cnblogs.com/ahang/p/5799065.html