重学 Java 设计模式：实战享元模式「基于Redis秒杀，提供活动与库存信息查询场景」

做者：小傅哥
博客：https://bugstack.cn

沉淀、分享、成长，让本身和他人都能有所收获！😄

1、前言

程序员👨‍💻‍的上下文是什么？

不少时候一大部分编程开发的人员都只是关注于功能的实现，只要本身把这部分需求写完就能够了，有点像被动的交做业。这样的问题一方面是因为不少新人还不了解程序员的职业发展，还有一部分是对于编程开发只是工做并不是兴趣。但在程序员的发展来看，若是不能很好的处理上文(产品)，下文(测试)，在这样不能很好的了解业务和产品发展，也不能编写出颇有体系结构的代码，日久天长，1到3年、3到5年，就很难跨越一个个技术成长的分水岭。

拥有接受和学习新知识的能力

你是否有感觉太小时候在什么都还不会的时候接受知识的能力很强，但随着咱们开始长大后，慢慢学习能力、处事方式、性格品行，每每会固定。一方面是造成了各自的性格特征，一方面是圈子已经固定。但也正由于这样的故步，而不多愿意听取别人的意见，就像即便看到了一整片内容，在视觉盲区下也会过掉到80%，就在眼前也看不见，也所以致使了能力再也不有较大的提高。

编程能力怎样会成长的最快

工做内容每每有些像在工厂🏭拧螺丝，大部份内容是重复的，也能够想象过去的一年你有过多少创新和学习了新的技能。那么这时候通常为了多学些内容会买一些技术书籍，但！技术类书籍和其余书籍不一样，只要不去用看了也就只是轻描淡写，很难接纳和理解。就像设计模式，虽然可能看了几遍，可是在实际编码中仍然不多会用，大部分缘由仍是没有认认真真的跟着实操。事必躬亲才是学习编程的最好是方式。

2、开发环境

1. JDK 1.8
2. Idea + Maven
3. 涉及工程三个，能够经过关注公众号：bugstack虫洞栈，回复源码下载获取(打开获取的连接，找到序号18)

工程	描述
itstack-demo-design-11-01	使用一坨代码实现业务需求
itstack-demo-design-11-02	经过设计模式优化代码结构，减小内存使用和查询耗时

3、享元模式介绍

享元模式，主要在于共享通用对象，减小内存的使用，提高系统的访问效率。而这部分共享对象一般比较耗费内存或者须要查询大量接口或者使用数据库资源，所以统一抽离做为共享对象使用。

另外享元模式能够分为在服务端和客户端，通常互联网H5和Web场景下大部分数据都须要服务端进行处理，好比数据库链接池的使用、多线程线程池的使用，除了这些功能外，还有些须要服务端进行包装后的处理下发给客户端，由于服务端须要作享元处理。但在一些游戏场景下，不少都是客户端须要进行渲染地图效果，好比；树木、花草、鱼虫，经过设置不一样元素描述使用享元公用对象，减小内存的占用，让客户端的游戏更加流畅。

在享元模型的实现中须要使用到享元工厂来进行管理这部分独立的对象和共享的对象，避免出现线程安全的问题。

4、案例场景模拟

在这个案例中咱们模拟在商品秒杀场景下使用享元模式查询优化

你是否经历过一个商品下单的项目从最初的日均十几单到一个月后每一个时段秒杀量破十万的项目。通常在最初若是没有经验的状况下可能会使用数据库行级锁的方式下保证商品库存的扣减操做，可是随着业务的快速发展秒杀的用户愈来愈多，这个时候数据库已经扛不住了，通常都会使用redis的分布式锁来控制商品库存。

同时在查询的时候也不须要每一次对不一样的活动查询都从库中获取，由于这里除了库存之外其余的活动商品信息都是固定不变的，以此这里通常你们会缓存到内存中。

这里咱们模拟使用享元模式工厂结构，提供活动商品的查询。活动商品至关于不变的信息，而库存部分属于变化的信息。

5、用一坨坨代码实现

逻辑很简单，就怕你写乱。一片片的固定内容和变化内容的查询组合，CV的哪里都是！

其实这部分逻辑的查询在通常状况不少程序员都是先查询固定信息，在使用过滤的或者添加if判断的方式补充变化的信息，也就是库存。这样写最开始并不会看出来有什么问题，但随着方法逻辑的增长，后面就愈来愈多重复的代码。

1. 工程结构

itstack-demo-design-11-01
└── src
    └── main
        └── java
            └── org.itstack.demo.design
                └── ActivityController.java

• 以上工程结构比较简单，以后一个控制类用于查询活动信息。

2. 代码实现

/**
 * 博客：https://bugstack.cn - 沉淀、分享、成长，让本身和他人都能有所收获！
 * 公众号：bugstack虫洞栈
 * Create by 小傅哥(fustack) @2020
 */
public class ActivityController {

    public Activity queryActivityInfo(Long id) {
        // 模拟从实际业务应用从接口中获取活动信息
        Activity activity = new Activity();
        activity.setId(10001L);
        activity.setName("图书嗨乐");
        activity.setDesc("图书优惠券分享激励分享活动第二期");
        activity.setStartTime(new Date());
        activity.setStopTime(new Date());
        activity.setStock(new Stock(1000,1));
        return activity;
    }

}

• 这里模拟的是从接口中查询活动信息，基本也就是从数据库中获取全部的商品信息和库存。有点像最开始写的商品销售系统，数据库就能够抗住购物量。
• 当后续由于业务的发展须要扩展代码将库存部分交给redis处理，那么久须要从redis中获取活动的库存，而不是从库中，不然将形成数据不统一的问题。

6、享元模式重构代码

接下来使用享元模式来进行代码优化，也算是一次很小的重构。

享元模式通常状况下使用此结构在平时的开发中并不太多，除了一些线程池、数据库链接池外，再就是游戏场景下的场景渲染。另外这个设计的模式思想是减小内存的使用提高效率，与咱们以前使用的原型模式经过克隆对象的方式生成复杂对象，减小rpc的调用，都是此类思想。

1. 工程结构

itstack-demo-design-11-02
└── src
    ├── main
    │   └── java
    │       └── org.itstack.demo.design
    │           ├── util
    │           │    └── RedisUtils.java    
    │           ├── Activity.java
    │           ├── ActivityController.java
    │           ├── ActivityFactory.java
    │           └── Stock.java
    └── test
        └── java
            └── org.itstack.demo.test
                └── ApiTest.java

享元模式模型结构

• 以上是咱们模拟查询活动场景的类图结构，左侧构建的是享元工厂，提供固定活动数据的查询，右侧是Redis存放的库存数据。
• 最终交给活动控制类来处理查询操做，并提供活动的全部信息和库存。由于库存是变化的，因此咱们模拟的RedisUtils中设置了定时任务使用库存。

2. 代码实现

2.1 活动信息

public class Activity {

    private Long id;        // 活动ID
    private String name;    // 活动名称
    private String desc;    // 活动描述
    private Date startTime; // 开始时间
    private Date stopTime;  // 结束时间
    private Stock stock;    // 活动库存
    
    // ...get/set
}

• 这里的对象类比较简单，只是一个活动的基础信息；id、名称、描述、时间和库存。

2.2 库存信息

public class Stock {

    private int total; // 库存总量
    private int used;  // 库存已用
    
    // ...get/set
}

• 这里是库存数据咱们单独提供了一个类进行保存数据。

2.3 享元工厂

public class ActivityFactory {

    static Map<Long, Activity> activityMap = new HashMap<Long, Activity>();

    public static Activity getActivity(Long id) {
        Activity activity = activityMap.get(id);
        if (null == activity) {
            // 模拟从实际业务应用从接口中获取活动信息
            activity = new Activity();
            activity.setId(10001L);
            activity.setName("图书嗨乐");
            activity.setDesc("图书优惠券分享激励分享活动第二期");
            activity.setStartTime(new Date());
            activity.setStopTime(new Date());
            activityMap.put(id, activity);
        }
        return activity;
    }

}

• 这里提供的是一个享元工厂🏭，经过map结构存放已经从库表或者接口中查询到的数据，存放到内存中，用于下次能够直接获取。
• 这样的结构通常在咱们的编程开发中仍是比较常见的，固然也有些时候为了分布式的获取，会把数据存放到redis中，能够按需选择。

2.4 模拟Redis类

public class RedisUtils {

    private ScheduledExecutorService scheduledExecutorService = Executors.newScheduledThreadPool(1);

    private AtomicInteger stock = new AtomicInteger(0);

    public RedisUtils() {
        scheduledExecutorService.scheduleAtFixedRate(() -> {
            // 模拟库存消耗
            stock.addAndGet(1);
        }, 0, 100000, TimeUnit.MICROSECONDS);

    }

    public int getStockUsed() {
        return stock.get();
    }

}

• 这里处理模拟redis的操做工具类外，还提供了一个定时任务用于模拟库存的使用，这样方面咱们在测试的时候能够观察到库存的变化。

2.4 活动控制类

public class ActivityController {

    private RedisUtils redisUtils = new RedisUtils();

    public Activity queryActivityInfo(Long id) {
        Activity activity = ActivityFactory.getActivity(id);
        // 模拟从Redis中获取库存变化信息
        Stock stock = new Stock(1000, redisUtils.getStockUsed());
        activity.setStock(stock);
        return activity;
    }

}

• 在活动控制类中使用了享元工厂获取活动信息，查询后将库存信息在补充上。由于库存信息是变化的，而活动信息是固定不变的。
• 最终经过统一的控制类就能够把完整包装后的活动信息返回给调用方。

3. 测试验证

3.1 编写测试类

public class ApiTest {

    private Logger logger = LoggerFactory.getLogger(ApiTest.class);

    private ActivityController activityController = new ActivityController();

    @Test
    public void test_queryActivityInfo() throws InterruptedException {
        for (int idx = 0; idx < 10; idx++) {
            Long req = 10001L;
            Activity activity = activityController.queryActivityInfo(req);
            logger.info("测试结果：{} {}", req, JSON.toJSONString(activity));
            Thread.sleep(1200);
        }
    }

}

• 这里咱们经过活动查询控制类，在for循环的操做下查询了十次活动信息，同时为了保证库存定时任务的变化，加了睡眠操做，实际的开发中不会有这样的睡眠。

3.2 测试结果

22:35:20.285 [main] INFO  org.i..t.ApiTest - 测试结果：10001 {"desc":"图书优惠券分享激励分享活动第二期","id":10001,"name":"图书嗨乐","startTime":1592130919931,"stock":{"total":1000,"used":1},"stopTime":1592130919931}
22:35:21.634 [main] INFO  org.i..t.ApiTest - 测试结果：10001 {"desc":"图书优惠券分享激励分享活动第二期","id":10001,"name":"图书嗨乐","startTime":1592130919931,"stock":{"total":1000,"used":18},"stopTime":1592130919931}
22:35:22.838 [main] INFO  org.i..t.ApiTest - 测试结果：10001 {"desc":"图书优惠券分享激励分享活动第二期","id":10001,"name":"图书嗨乐","startTime":1592130919931,"stock":{"total":1000,"used":30},"stopTime":1592130919931}
22:35:24.042 [main] INFO  org.i..t.ApiTest - 测试结果：10001 {"desc":"图书优惠券分享激励分享活动第二期","id":10001,"name":"图书嗨乐","startTime":1592130919931,"stock":{"total":1000,"used":42},"stopTime":1592130919931}
22:35:25.246 [main] INFO  org.i..t.ApiTest - 测试结果：10001 {"desc":"图书优惠券分享激励分享活动第二期","id":10001,"name":"图书嗨乐","startTime":1592130919931,"stock":{"total":1000,"used":54},"stopTime":1592130919931}
22:35:26.452 [main] INFO  org.i..t.ApiTest - 测试结果：10001 {"desc":"图书优惠券分享激励分享活动第二期","id":10001,"name":"图书嗨乐","startTime":1592130919931,"stock":{"total":1000,"used":66},"stopTime":1592130919931}
22:35:27.655 [main] INFO  org.i..t.ApiTest - 测试结果：10001 {"desc":"图书优惠券分享激励分享活动第二期","id":10001,"name":"图书嗨乐","startTime":1592130919931,"stock":{"total":1000,"used":78},"stopTime":1592130919931}
22:35:28.859 [main] INFO  org.i..t.ApiTest - 测试结果：10001 {"desc":"图书优惠券分享激励分享活动第二期","id":10001,"name":"图书嗨乐","startTime":1592130919931,"stock":{"total":1000,"used":90},"stopTime":1592130919931}
22:35:30.063 [main] INFO  org.i..t.ApiTest - 测试结果：10001 {"desc":"图书优惠券分享激励分享活动第二期","id":10001,"name":"图书嗨乐","startTime":1592130919931,"stock":{"total":1000,"used":102},"stopTime":1592130919931}
22:35:31.268 [main] INFO  org.i..t.ApiTest - 测试结果：10001 {"desc":"图书优惠券分享激励分享活动第二期","id":10001,"name":"图书嗨乐","startTime":1592130919931,"stock":{"total":1000,"used":114},"stopTime":1592130919931}

Process finished with exit code 0

• 能够仔细看下stock部分的库存是一直在变化的，其余部分是活动信息，是固定的，因此咱们使用享元模式来将这样的结构进行拆分。

7、总结

• 关于享元模式的设计能够着重学习享元工厂的设计，在一些有大量重复对象可复用的场景下，使用此场景在服务端减小接口的调用，在客户端减小内存的占用。是这个设计模式的主要应用方式。
• 另外经过map结构的使用方式也能够看到，使用一个固定id来存放和获取对象，是很是关键的点。并且不仅是在享元模式中使用，一些其余工厂模式、适配器模式、组合模式中均可以经过map结构存放服务供外部获取，减小ifelse的判断使用。
• 固然除了这种设计的减小内存的使用优势外，也有它带来的缺点，在一些复杂的业务处理场景，很不容易区分出内部和外部状态，就像咱们活动信息部分与库存变化部分。若是不能很好的拆分，就会把享元工厂设计的很是混乱，难以维护。

8、推荐阅读

• 1. 重学 Java 设计模式：实战工厂方法模式(多种类型商品发奖场景)
• 2. 重学 Java 设计模式：实战抽象工厂模式(替换Redis双集群升级场景)
• 3. 重学 Java 设计模式：实战建造者模式(装修物料组合套餐选配场景)
• 4. 重学 Java 设计模式：实战原型模式(多套试每人题目和答案乱序场景)
• 5. 重学 Java 设计模式：实战桥接模式(多支付渠道「微信、支付宝」与多支付模式「刷脸、指纹」场景)
• 6. 重学 Java 设计模式：实战组合模式(营销差别化人群发券，决策树引擎搭建场景)