小白初探架构模式—常用的设计模式

news2024/11/15 18:57:16

1.前言

2. 主从架构

2.1 主从架构的优点

2.2 主从架构的应用场景

2.3 主从架构的实现

2.4 主从架构的示例

3. 主从架构设计的延伸

3.1 主备模式

3.2 主从复制

3.3 集群分片

3.4 异地多活

4. 总结

1.前言

作为一个架构设计小白，我们通常用了很多种工具，比如 Mysql 、Redis、Kafka、 Hdfs、Hbase、MongoDB、RocketMQ等等，但是这些优秀工具，是如何设计的这么优秀？我们有的一知半解，有的甚至干脆不讲，只要能用就行。下面我主要做个简短的介绍，算是普及了以下知识，让小伙伴们知道是什么，最起码有这方面的印象就好，好了，下面我们开始介绍：

2. 主从架构

主从架构设计模式是一种常见的软件设计模式，它将系统划分为两个或多个组件：一个主组件和一个或多个从组件。主组件负责管理和控制整个系统，而从组件负责执行主组件分配的任务。

2.1 主从架构的优点

（1）可扩展性：主从架构设计模式可以很容易地扩展，以适应不断增长的系统需求。只需添加更多的从组件即可提高系统的性能。

（2）可靠性：主从架构设计模式具有很高的可靠性，因为如果主组件发生故障，从组件可以继续运行。

（3）可用性：主从架构设计模式具有很高的可用性，因为如果主组件发生故障，从组件可以立即接管主组件的任务。主从架构设计模式也有一些缺点：

（4）单点故障：主组件是整个系统的单点故障，如果主组件发生故障，整个系统将无法运行。

（5）性能瓶颈：主组件可能会成为系统的性能瓶颈，因为所有请求都必须经过主组件。

2.2 主从架构的应用场景

主从架构设计模式可以应用于各种各样的场景，包括：

（1）数据库系统：主从架构设计模式可以用于数据库系统，其中主组件负责管理数据库，而从组件负责执行数据库查询。

（2）Web 服务器：主从架构设计模式可以用于 Web 服务器，其中主组件负责处理用户请求，而从组件负责生成网页。

（3）分布式系统：主从架构设计模式可以用于分布式系统，其中主组件负责管理整个系统，而从组件负责执行主组件分配的任务。

2.3 主从架构的实现

主从架构设计模式可以通过多种方式实现，包括：

（1）进程：主组件和从组件可以作为独立的进程运行。

（2）线程：主组件和从组件可以作为同一个进程中的不同线程运行。

（3）网络：主组件和从组件可以通过网络通信。

2.4 主从架构的示例

以下是一个主从架构设计模式的示例：

class Master { 
    public void start() { 
        // 创建从组件 
        Slave slave1 = new Slave(); 
        Slave slave2 = new Slave(); 

        // 启动从组件 
        slave1.start(); 
        slave2.start(); 

        // 等待从组件完成任务 
        slave1.join(); 
        slave2.join(); 
    } 
} 

class Slave { 
    public void run() { 
        // 执行主组件分配的任务 
        // ... 
    } 
}

在这个示例中，主组件负责创建和启动从组件，然后等待从组件完成任务。从组件负责执行主组件分配的任务。

3. 主从架构设计的延伸

从上文我们了解了，主从架构的优点，应用场景以及应用中的实现方式，下面我们再说下，平常我们所听到的一些架构模式是怎么样的，例如：主备模式、主从复制、集群分片、异地多活，这些名词又是什么？又该怎么理解呢？我们下面一一介绍：

3.1 主备模式

主备模式实际就是一主多备，master 负责提供读写服务，slave 作为数据备份，一旦主机宕机，将其中一个备节点作为主节点。通常是在单体应用中，我们采用nginx 做负载时候，会用到的多，一旦一个主库宕机，我们发现后，可以修改配置切换主库。这种模式，主要还是依靠主库，备份的只是为了防备而已，不知道什么时候才会用上。

3.2 主从复制

主从复制实际是一主多从，master 对外提供读写服务，slave 作为数据备份提供只读服务。主机定期复制数据给从机。多副本的关键问题是保证数据一致性，通常需要考虑数据同步延时的问题。通常用在数据库中的居多，另外主从再结合注册中心，自动选举，就可以实现自主切换主库，数据备份这块一般会在晚上进行，白天会影响主数据库的读写性能。

另外这个主从复制的思维模式，也大多数是用在我们平常使用的中间件上面，RocketMQ、Mysql、MongoDB、Redis中，我们在用到这些，或者部署的时候可以好好理解下，这种设计模式思维。

3.3 集群分片

集群分片是为了解决每台机器上存储全量数据的问题，面对大数据单机的存储量总是有上限的，当面对 PB 级数据时，单机是无法支撑的，因此就需要对数据进行分片。这个设计模式，我们在大数据的设计中，会经常的遇到，例如，HDFS 的强大存储能力，还有容错能力，都是依靠这个集群的分片设计，简单的理解，就是说，我把一个大文件，分散成多个小文件，这样我无论是存储，还是计算的时候，都会很快，如果下载这个大文件，我再合并下就可以了，计算的时候，也是多个小文件并行计算，最后把结果合并，这样提高了性能和效率；还有个就是Flink 这个是用到这个思想最多的系统，他把任务计算这块用到了极致，大家有兴趣的可以研究下。

3.4 异地多活

异地就是指在地理位置上不同的地方，可分为同城异地、跨城异地、跨国异地，多活就是指不同地理位置上的系统都能够提供服务。这种架构的复杂度较高，且部署成本也会提高。

这个设计设计模式，主要用在特别大的系统上，为了加深理解，我举个例子方便大家的理解。就是我们现在出门所使用的地图，大家都不陌生吧，作为基础性质的工具，保障他的安全稳定是非常必要的，拿淘宝来说，阿里收购开发高德地图，是很有必要的，因为他的订单，支付，配送物流这些，都是需要依赖地图信息的，首先他必须要把这块掌握在自己手中，其次保证他的稳定性。也就是他不可能把数据只存放到一个地方，会在多个地方都会存一份这样的数据，这样在某个地方的服务器被地震或者其他不可预期的破坏了，不会影响服务的正常运行。这是异地多活的目的。

异地多活的技术这块更加复杂，简单的说下一个两地多活的吧，就是可以把一个服务的数据，同时保存到两个地方的服务器就可以了，我们可以先这样的理解。