分布式服务,库表拆分模式详解

简介: 分布式系统架构的明显特点,就是按照业务系统的功能,拆分成各种服务,每个服务下面都有自己独立的数据库,以此降低业务间的耦合度,隔离不同的数据库保证系统最大的稳定性等。

一、服务间隔离

1、分布式结构

分布式系统架构的明显特点,就是按照业务系统的功能,拆分成各种服务,每个服务下面都有自己独立的数据库,以此降低业务间的耦合度,隔离不同的数据库保证系统最大的稳定性等。

07-1.png

例如上图是电商系统中经典的业务场景,订单-仓储-物流的服务模式,不同服务提供不同的应用场景,服务间存在通信机制,以此实现服务的高可用。

2、隔离思想

分布式的架构体系中,涉及一个根本思想逻辑:隔离;

服务和数据库根据业务拆分,进而隔离开来,整个架构中某个服务挂掉,不会影响其他的服务继续执行。例如上述1中:如果物流服务挂掉,影响的是用户无法实时追踪物流状态,但是不会影响订单的持续产生。

隔离的策略也是各有不同,常见的电商系统是典型的按照业务特点进行拆分,这种就是不同的业务场景下,使用不同的服务和数据库;还有一种业务场景,多租户平台,针对大客户提供独立的服务和数据库,对小客户提供公服务和数据库,这种策略比较现实:大客户带来收益多,完全覆盖服务和数据库的成本,必须保证不能被一些非必要因素影响。

不管是基于什么策略拆分隔离,首先都必须面对数据库设计的问题。

二、数据库设计

1、拆分思想

数据库在业务体系不大的情况,一般都是单库出现,最多加一个备份库以备不时之需,当业务体量不断扩大,就会考虑拆分场景,例如常见的:水平拆分,垂直拆分策略。

水平拆分

首先把单表表分割N个结构相同的表,然后把数据按照策略分散到不同的表中,这是表层面;如果把表在分散在不同的数据库中,这就是数据库层面的水平拆分。

垂直拆分

把单表中数据按照不同特点,拆分成两张不同的表,常见的策略是根据数据是修改多,还是读取多,把修改频繁的字段放一张表,读取频繁的放另一张表,这是表层面;如果根据业务特点,拆分不同库,这就是数据库层面。

2、拆分模式

读写分离

读写分离是数据库拆分的最基本方式,实现起来难度也不大,只需要根据读写库的配置,把业务中数据写操作路由到写库,数据读操作路由到读库即可。

07-2.png

这种方式实现的数据库拆分虽然相对容易,如果出现主从复制挂掉的情况,就会导致数据读不到,或者数据读取延时,所以在强一致的要求的情况下,使用不多。

分库分表

分库分表主要用来解决单表数据量过大的问题,根据特定字段的路由规则,把数据分散到不同的库,不同的表中。

07-3.png

通常是基于一些唯一值的哈希算法实现的分库分表策略。也有一些成熟的中间件可以集成到项目直接使用,这种模式更多适用于单点数据的查询的场景,可以基于路由快速定位数据所在的库表。

业务分库

基于业务特点拆分数据库,是当前分布式架构下,或者微服务模式的基础用法,不同业务场景下数据放在一个库,因为数据关联性很强,在使用的时候方便,同时与其他业务数据隔离开来,避免单点故障导致数据库挂掉。

07-4.png

这种模式虽然看起来更合理,但是复杂度也是非常的陡,因为两种业务场景下的数据不可能绝对没有关联,比如订单库一定依赖用户库的信息,这就需要订单服务和用户服务之间需要通信,引发的问题就会很多。

用户分库

在多租户场景下,会根据客户流水大小提供不相同的服务和数据库,这是一个十分现实的策略,毕竟可能一个大客户的月流水超过几个小客户的总和。

07-5.png

既然可以根据客户情况分库,也可以基于其他策略,比如地区,常见云服务的应用,选择华南,华北,华东区之类的。

三、架构体系难点

这里所提到的涉及问题,是指基于业务分库模式下的出现的问题。

1、服务依赖

在分布式架构体系下,不同服务都有各自的数据库,但是数据之间一定是有关系的,服务A要用服务C的数据库,就必须通过服务C提供的接口来获取,这是基本机制,不然拆分服务和库就没意义了,这样就会导致服务间产生依赖关系。

07-6.png

如上图,如果订单服务和论坛服务同时依赖用户服务,那么就要考虑如果用户服务挂掉,会影响多大的范围,做好权衡,还有一个关键点,如果多个服务依赖一个服务,那么就要保证被依赖的服务有足够的能力应对,例如这里,如果订单服务有10W的流量,论坛服务有10W的流量,那么就要保证部署上用户服务起码要能承受20W的流量。

2、分布式事务

既然数据库在不同的服务下面,服务之间又存在依赖关系,那么保证数据的事务一致性就是非常大的难题。

这里基于支付业务的转账场景做一个简单的演示,从数据源1的账户表中,向数据源2的账户表中操作转账,尽管在代码层面看添加了事务最高级别的控制,但是却没有起到控制作用,导致出账成功,但是入账失败,这就是典型的分布式事务问题。

@Service
public class AccountServiceImpl implements AccountService {

    @Resource
    private JdbcTemplate jdbcTemplateOne ;

    @Resource
    private JdbcTemplate jdbcTemplateTwo ;

    /**
     * @param fromUser 出账 账户
     * @param toUser   入账 账户
     * @param money    涉及 金额
     */
    @Transactional(isolation= Isolation.SERIALIZABLE)
    @Override
    public void transfer(String fromUser, String toUser, int money) {
        // fromUser 出账
        jdbcTemplateOne.update(
                "UPDATE user_account SET money = money-? WHERE username= ?",
                    new Object[] {money, fromUser});
                    
        int i = 1/0 ;
        
        // toUser 入账
        jdbcTemplateTwo.update(
                "UPDATE user_account SET money = money+? WHERE username= ?",
                    new Object[] {money, toUser});
    }
}

这里只是先演示分布式事务的问题,如何解决分布式事务问题,需要很多的篇幅描述,后面的连续几篇文章再细说。

相关文章
|
2月前
|
存储 缓存 算法
分布式锁服务深度解析:以Apache Flink的Checkpointing机制为例
【10月更文挑战第7天】在分布式系统中,多个进程或节点可能需要同时访问和操作共享资源。为了确保数据的一致性和系统的稳定性,我们需要一种机制来协调这些进程或节点的访问,避免并发冲突和竞态条件。分布式锁服务正是为此而生的一种解决方案。它通过在网络环境中实现锁机制,确保同一时间只有一个进程或节点能够访问和操作共享资源。
97 3
|
4月前
|
存储 监控 负载均衡
检索服务elasticsearch分布式结构
【8月更文挑战第22天】
54 3
|
9天前
|
消息中间件 存储 安全
分布式系统架构3:服务容错
分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!
44 11
|
4月前
|
存储 消息中间件 Apache
比较微服务中的分布式事务模式
比较微服务中的分布式事务模式
79 2
|
1月前
|
监控
Saga模式在分布式系统中保证事务的隔离性
Saga模式在分布式系统中保证事务的隔离性
|
2月前
|
存储 缓存 NoSQL
大数据-38 Redis 高并发下的分布式缓存 Redis简介 缓存场景 读写模式 旁路模式 穿透模式 缓存模式 基本概念等
大数据-38 Redis 高并发下的分布式缓存 Redis简介 缓存场景 读写模式 旁路模式 穿透模式 缓存模式 基本概念等
75 4
|
3月前
Saga模式在分布式系统中如何保证事务的隔离性
Saga模式在分布式系统中如何保证事务的隔离性
|
3月前
|
数据采集 分布式计算 MaxCompute
MaxCompute 分布式计算框架 MaxFrame 服务正式商业化公告
MaxCompute 分布式计算框架 MaxFrame 服务于北京时间2024年09月27日正式商业化!
109 3
|
4月前
|
存储 分布式计算 算法
探索Hadoop的三种运行模式:单机模式、伪分布式模式和完全分布式模式
在配置Hadoop集群之前,了解这三种模式的特点、适用场景和配置差异是非常重要的。这有助于用户根据个人需求和资源情况,选择最适合自己的Hadoop运行模式。在最初的学习和开发阶段,单机模式和伪分布式模式能为用户提供便利和成本效益。进而,当用户要处理大规模数据集时,完全分布式模式将是理想的选择。
303 2
|
4月前
|
开发者 云计算 数据库
从桌面跃升至云端的华丽转身:深入解析如何运用WinForms与Azure的强大组合,解锁传统应用向现代化分布式系统演变的秘密,实现性能与安全性的双重飞跃——你不可不知的开发新模式
【8月更文挑战第31天】在数字化转型浪潮中,传统桌面应用面临新挑战。本文探讨如何融合Windows Forms(WinForms)与Microsoft Azure,助力应用向云端转型。通过Azure的虚拟机、容器及无服务器计算,可轻松解决性能瓶颈,满足全球用户需求。文中还提供了连接Azure数据库的示例代码,并介绍了集成Azure Storage和Functions的方法。尽管存在安全性、网络延迟及成本等问题,但合理设计架构可有效应对,帮助开发者构建高效可靠的现代应用。
36 0