设计模式(一)-开发过程中常用的设计模式(简述)

Myth丶恋晨 2022-06-09 06:39 221阅读 0赞

**个人感觉很多设计模式我们都是一直在用只是我们自己都不知道原来这种操作是一种设计模式，下面只是我个人总结在开发过程中比较常用的设计模式：**

**1.主从设计模式(master-slaver)**

**简介:简单借助于redis的主从设计来演示**

1)主的redis配置文件,使用默认的配置文件就可以了，如果你需要设计其他参数

从的redis配置文件，添加

\#从的redis配置文件，需要添加vim/etc/redis/6379.confslaveof192.168.9.186379

**启动主从redis**

#启动主
    redis（192.168.9.18）/etc/init.d/redis_6379.conf start
    #启动从
    redis（192.168.9.19）/etc/init.d/redis_6379.conf start
    #查看主redis的信息
    redis-cli-h192.168.9.18 info Replication
    #Replicationrole:master
    #代表192.168.9.18:6379这台redis是主connected_slaves:1slave0:192.168.9.18,6379,online
    #查看主redis的信息redis-cli-h192.168.9.19 info Replication
    #Replicationrole:slave
    #代表192.168.9.19:6379这台redis是从
    master_host:192.168.9.18
    master_port:6379
    master_link_status:up
    master_last_io_seconds_ago:4
    master_sync_in_progress:0
    slave_priority:100
    slave_read_only:1connected_slaves:0

配置redis sentinel集群监控服务

1.添加一份redis sentinel 配置文件

vim/etc/redis/sentinel.conf
    ##redis-0
    ##sentinel实例之间的通讯端口port26379
    #master1sentinel monitor
    master1192.168.9.1863791sentinel down-after-milliseconds
    master15000sentinel failover-timeout
    master1900000sentinel can-failover
    master1 yessentinel parallel-syncs
    master12
    #master2可以添加多组主从的redis监听

2).有配置文件了，那么启动redis sentinel做redis集群监听redis-sentinel sentinel.conf --sentinel

*  把主的redis启动
 *  把从的redis启动
 *  把redis sentinel 集群监听启动

3).当redis启动后,一旦主的发生故障, 监听器就会监听到,并从主的redis切换到从的, 而当主的修复完成以后再次启动, 它就变成从的了.

4). redis常见性能问题和解决方案：

(1) Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件

(2) 如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次

(3) 为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内

(4) 尽量避免在压力很大的主库上增加从库

(5) 主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <- ...这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。

**2.单例设计模式**

**简介:确保该类只有一个实例对象, 并且对整个系统提供该实例,计算机中的线程池/ 缓存/ 日志/ 打印机都是单例设计模式**

**注意:两种方式的构造都是private修饰, 也就是不允许外界直接创建该对象**

**懒汉式:**

//懒汉式单例类.在第一次调用的时候实例化自己   
    public class Singleton {  
        private Singleton() {}  
        private static Singleton single=null;  
        //静态工厂方法   
        public static Singleton getInstance() {  
             if (single == null) {    
                 single = new Singleton();  
             }    
            return single;  
        }  
    }

**饿汉式:**

//饿汉式单例类.在类初始化时，已经自行实例化   
    public class Singleton1 {  
        private Singleton1() {}  
        private static final Singleton1 single = new Singleton1();  
        //静态工厂方法   
        public static Singleton1 getInstance() {  
            return single;  
        }  
    }

**3.工厂模式**

**1).工厂方法**

**2).抽象工厂(都是把具体逻辑封装,对外提供接口去做进一步实现)**

**3）简单工厂模式：客户端传一个条件进工厂类，工厂类根据条件创建相应的产品类对象，并return给客户端，供客户端使用。即客户端使用的是工厂类生产的产品对象。**

**4.门面模式**

**简介:将复杂的业务逻辑封装到高层接口, 简化 对子系统的访问**

**\#\#:为遗留的后端系统提供简单且统一的访问, 提供公开的API--如驱动**

**\#\#:为可用服务提供粗粒度访问**

**\#\#:减少网络调用, 门面会对子系统发起多层调用, 而远程客户端只需对门面进行一次调用即可**

**\#\#:门面有时也被实现为单例抽象工厂**

**5.装饰者模式**

**简介:动态地为对象添加一些扩展性功能, 比继承和实现更具有可操作性**

**\#\#****BufferedInputStream和LineNumberInputStream都扩展自FilterInputStream，而FilterInputStream是一个抽象的装饰类, 具有readLine的强大功能**

**6.依赖注入(dependency injection--DI)与CDI**

**\#\#客户端不必关注被注入的资源是如何操作只需使用, 设计更加容易**

**\#\#配置外化,降低了变更的影响**

**\#\#松耦合的架构支持及插及拔**

7.策略模式

策略模式：客户端创建一个Context类对象a（可以看作是工厂模式中工厂类），创建一个策略对象并传参给对象a，然后客户端使用a对象的某些方法来使用前面传参进来的策略，即客户端是通过a对象使用策略的。

**策略模式和工厂模式的区别：**

1.  工厂模式根据条件生产出产品给客户端用。而策略模式是客户端使用传参给Context的策略（你也可以理成产品），传入策略的不同，调用同样方法得到的结果也不同。
2.  工厂模式：客户端是使用工厂类生产的对象进行操作，策略模式：客户端使用自己传给Context的策略的对象进行操作。
3.  工厂模式：有一天你决定去吃披萨，一看菜单，哦，种类很多呀，你就点了个培根披萨，过了二十分钟，你的披萨就来了就可以吃到了。但这个披萨是怎么做的，到底面粉放了多少，培根放了多少，佐料放了多少，有多少到工序，你是不需要管的，你需要的是一个美味培根披萨。
4.  策略模式：同样还是在披萨店，你要一个培根披萨，老板说想吃自己去做吧。原料有培根、面粉、佐料。工序有1、2、3工序，你自己去做吧。然后你就需要自己去做，到底放多少培根，放多少面粉，放多少佐料，这都你自己来决定，工序1、2、3，你是怎么实现的，都你自己决定。最后你得到了披萨。

**如有披露或问题欢迎留言或者入群探讨**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDcwNzMz_size_16_color_FFFFFF_t_70][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM5NDcwNzMz_size_16_color_FFFFFF_t_70]: /images/20220609/bfb3d4f40a6e438786f3a1c2e1b28c22.png