IM 项目顶层设计思路

微信扫码登录技术方案实现

原文：www.yuque.com/snab/mallc...

‍

前言

我们的项目就是采用的扫公众号事件码的方式登录。

​​

‍

流程时序图

​​

整体流程介绍的比较详细，用户初次注册才需要授权信息。第二次登陆只需要到第 9 步，就登录完成了。

具体的操作可以看微信的公众号文档，接下来我们就代码走读下过程。

生成带参数二维码：

• developers.weixin.qq.com...

用户授权步骤：

• developers.weixin.qq.com...

‍

和微信的交互主要有三个点:

1. 申请带参二维码
2. 扫码事件通知
3. 授权事件通知

‍

详细解析

1. 建立 websocket 连接

​​

进入到这个页面的时候，前端就开始和后端建立了 websocket，这时候就已经可以接受新消息推送啦。不过目前这个连接是一个未登录的用户。需要进行登录认证。

‍

前端通过​new WebSocket("URL")​和后端建立连接。

​​

‍

后端通过在 netty 中添加处理器，记录并管理连接

    private WebSocketService webSocketService;

    // 当web客户端连接后，触发该方法
    @Override
    public void handlerAdded(ChannelHandlerContext ctx) throws Exception {
        this.webSocketService = getService();
    }

    private WebSocketService getService() {
        return SpringUtil.getBean(WebSocketService.class);
    }

‍

将连接放入一个 map 中管理，目前该连接是未登录态。

​​

‍

‍

2. 前端请求扫码登录

前端点击登录，会发出一个请求登录二维码的 websocket 信息。后端做了三件事

public void handleLoginReq(Channel channel) {
    //生成随机不重复的登录码
    Integer code = generateLoginCode(channel);
    //请求微信接口，获取登录码地址
    WxMpQrCodeTicket wxMpQrCodeTicket = wxMpService.getQrcodeService().qrCodeCreateTmpTicket(code, EXPIRE_SECONDS);
    //返回给前端
    sendMsg(channel, WSAdapter.buildLoginResp(wxMpQrCodeTicket));
}

1. 生成一个不重复的​登录码​。并且将登录码和这个 Channel 关联起来。
2. 然后请求微信的接口，将这个​登录码​转成一个带参数的二维码链接
3. 返回给前端，前端就按这个二维码链接转成二维码图片展示

‍

​​

这个事件码就是之后用户登录携带的参数，只有它能和这个​channel​​连接关联起来，很重要。

‍

过期淘汰机制

在“登录时间码”管理这个 Map 中，如果不对存储的对象进行定期清除的话，项目运行很久后就会累计了很多数据，造成 OOM。

所以我们对这个存储数据结构有以下要求：

1. Map 数据结构，可以存储 code --> channel 映射
2. 存在过期策略
3. 最大容量设定，避免 OOM

‍

于是我们引入了 Caffeine 这一个本地缓存包：

    // 保存请求登录的code与channel的关系（本地缓存） ———— 等待登录队列
    public static final Cache<Integer, Channel> WAIT_LOGIN_MAP = Caffeine.newBuilder()
            .expireAfterWrite(EXPIRE_TIME)
            .maximumSize(MAX_SIZE)
            .build();

• Caffeine 是一个高性能的 Java 本地缓存，支持各种需求的缓存设置

‍

要根据业务的需求，选取符合要求的“数据结构”

‍

3. 用户扫码

​​

这是一张携带参数的二维码。当用户扫码后关注公众号。公众号会给我们后台回调一个关注事件 OR 扫码事件。

取决于用户是已关注还是未关注。不管啥事件，都会携带二维码参数 即登录码

‍

4. 用户注册

用户扫码的回调，我们能够获得用户的 openid。和登录码。这还不够，对于新用户我们需要他的头像和昵称。

这个信息需要额外的用户授权。

​​

于是我们先让用户注册了。再额外给用户发一个推送，请求用户授权。

用户注册后，会先临时保存一个 openid 和前端登录码的关系映射。

​​

‍

5. 授权用户信息

我们推送的授权信息是一个微信授权地址，用户点击后，微信就会回调我们的系统，并且获取一个重定向的地址给用户展示。

private static final String URL = 
	"https://open.weixin.qq.com/connect/oauth2/authorize?appid=%s&redirect_uri=%s&response_type=code&scope=snsapi_userinfo&state=STATE#wechat_redirect";

​​

‍

用户看到这样一条信息，点击登录，微信就会给我们发送授权成功的回调。

​​

这个 userInfo 我们就能拿到邮箱，昵称，openid 等。通过 openid 关联出之前的事件码，然后复用已注册的登录逻辑。

​​

‍

‍

​​

‍

6. 在线用户管理

因为用户可能在多点登录。一个 uid 有多个连接。思考两个场景。用户所有连接都下线，才能算用户下线。私聊推送用户的时候，需要推送某个 uid 的所有连接。都需要额外有个 uid 作为 key 的关系映射。

假设用户在手机端也登录了。就是这样的效果：

​​

代码实现：

// 所有在线用户和对应的socket
    /**
     * 具体场景考虑方面，这段代码可能用于一个WebSocket服务中，用于管理在线用户的连接状态和相关信息。
     * 通过将用户ID映射到其对应的WebSocket通道列表，可以方便地获取某个用户当前连接的所有通道，或者添加、删除或更新某个用户的通道信息。
     * 同时，使用CopyOnWriteArrayList可以确保在多线程环境下对通道列表的操作是线程安全的，从而保证系统的稳定性和可靠性。
     *
     * 此处使用List存储Channel的原因是为了实现 “多点登录”。用户有可能同时使用电脑和手机登录平台！
     */
    private static final ConcurrentHashMap<Long, CopyOnWriteArrayList<Channel>> ONLINE_UID_MAP = new ConcurrentHashMap<>();

‍

‍

7. 后端主动推送

​​

后端推送就很简单了，目前都是针对所有连接推送。所以我们应该选取在线连接管理里的所有连接。

​​ ↩

epoll 是解决 C10K 问题的利器，通过两个方面解决了 select/poll 的问题。 ↩

分布式雪花算法基础知识

原文：https://www.cnblogs.com/mikechenshare/p/16787023.html

其他参考：

• https://zhuanlan.zhihu.com/p/85837641

雪花算法简介

雪花算法，英文名为 snowflake，翻译过来就是是雪花，所以叫雪花算法。

在大自然雪花形成过程中，会形成不同的结构分支，所以说不存在两片完全一样的雪花，表示生成的 id 如雪花般独一无二。

​​

雪花算法，它最早是 twitter 内部使用的分布式环境下的唯一分布式 ID 生成算法。

‍

雪花算法的优缺点

优点

1.系统环境 ID 不重复

能满足高并发分布式系统环境ID不重复，比如大家熟知的分布式场景下的数据库表的ID生成。

2.生成效率极高

在高并发，以及分布式环境下，除了生成不重复 id，每秒可生成百万个不重复 id，生成效率极高。

3.保证基本有序递增

基于时间戳，可以保证基本有序递增，很多业务场景都有这个需求。

4.不依赖第三方库

不依赖第三方的库，或者中间件，算法简单，在内存中进行。

缺点

依赖服务器时间，服务器时钟回拨时可能会生成重复 id。

‍

雪花算法原理

详细的雪花算法构造如下图所示：

​​

‍

雪花算法的原理：就是生成一个的 64 位的 long 类型的唯一 id，主要分为如下 4 个部分组成：

1）1 位保留 (基本不用)

1 位标识：由于 long 基本类型在 Java 中是带符号的，最高位是符号位，正数是 0，负数是 1，所以 id 一般是正数，最高位是 0，所以这第一位都是 0。

‍

2）41 位时间戳 ​

接下来 41 位存储毫秒级时间戳，41 位可以表示 2^41-1^ 个毫秒的值，转化成单位年则是: (241−1)/(1000∗60∗60∗24∗365) =69 年 。

41 位时间戳 ：也就是说这个时间戳可以使用 69 年不重复，大概可以使用 69 年。

注意：41 位时间截不是存储当前时间的时间截，而是存储时间截的差值“​当前时间截 – 开始时间截​”得到的值。

这里的的开始时间截，一般是我们的 id 生成器开始使用的时间，由我们程序来指定的，一般设置好后就不要去改变了，切记！！！

因为，雪花算法有如下缺点：依赖服务器时间，​服务器时钟回拨时可能会生成重复 id​。

‍

3）10 位机器

10 位的数据机器位，可以部署在 1024 个节点，包括 5 位 datacenterId 和 5 位 workerId，最多可以部署 2^10=1024 台机器。

这里的 5 位可以表示的最大正整数是 2^5−1=31，即可以用 0、1、2、3、….31 这 32 个数字，来表示不同的 datecenterId，或 workerId。

‍

4） 12bit 序列号

用来记录同毫秒内产生的不同 id，12 位的计数顺序号支持每个节点每毫秒(同一机器，同一时间截)产生 4096 个 ID 序号。

‍

理论上雪花算法方案的 QPS 约为 409.6w/s，这种分配方式可以保证在任何一个 IDC 的任何一台机器在任意毫秒内生成的 ID 都是不同的。

‍

‍

代码实现

​​

​​

​​

‍ ↩ ↩

接口幂等设计

原文：

• 聊聊幂等设计 (qq.com)
• Spring Boot 实现接口幂等性的 4 种方案 (qq.com)

‍

幂等性的定义

在 HTTP/1.1 中，对幂等性进行了定义。

• 它描述了==一次和多次请求某一个资源对于资源本身应该具有同样的结果（网络超时等问题除外）==，即第一次请求的时候对资源产生了副作用，但是以后的多次请求都不会再对资源产生副作用。

这里的副作用是不会对结果产生破坏或者产生不可预料的结果。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。

‍

为什么需要幂等

之前还以为“幂等”是数据上的“一致性”概念，原来更侧重于网络。。。

‍

在接口调用时一般情况下都能正常返回信息不会重复提交，不过在遇见以下情况时可以就会出现问题，如：

• 前端重复提交表单： 在填写一些表格时候，用户填写完成提交，很多时候会因网络波动没有及时对用户做出提交成功响应，致使用户认为没有成功提交，然后一直点提交按钮，这时就会发生重复提交表单请求。
• 用户恶意进行刷单： 例如在实现用户投票这种功能时，如果用户针对一个用户进行重复提交投票，这样会导致接口接收到用户重复提交的投票信息，这样会使投票结果与事实严重不符。
• 接口超时重复提交： 很多时候 HTTP 客户端工具都默认开启超时重试的机制，尤其是第三方调用接口时候，为了防止网络波动超时等造成的请求失败，都会添加重试机制，导致一个请求提交多次。
• 消息进行重复消费： 当使用 MQ 消息中间件时候，如果发生消息中间件出现错误未及时提交消费信息，导致发生重复消费。

使用幂等性最大的优势在于使接口保证任何幂等性操作，免去因重试等造成系统产生的未知的问题。

‍

以上情况都是属于“数据重复提交”

‍

‍

判断接口是否需要实现幂等

幂等性是为了简化客户端逻辑处理，能放置重复提交等操作，但却增加了服务端的逻辑复杂性和成本，其主要是：

• 把并行执行的功能改为串行执行，降低了执行效率。
• 增加了额外控制幂等的业务逻辑，复杂化了业务功能；

所以在使用时候需要考虑是否引入幂等性的必要性，根据实际业务场景具体分析，除了业务上的特殊要求外，一般情况下不需要引入的接口幂等性。

‍

‍

实现接口幂等

幂等意味着一条请求的唯一性。不管是你哪个方案去设计幂等，都需要一个全局唯一的 ID，去标记这个请求是独一无二的。

• 如果你是利用唯一索引控制幂等，那唯一索引是唯一的
• 如果你是利用数据库主键控制幂等，那主键是唯一的
• 如果你是悲观锁的方式，底层标记还是全局唯一的 ID

‍

2023-05-31

美团常用的方式：

1. 分布式锁¹
2. token 令牌¹
3. 状态机幂等¹

‍

‍

全局的唯一性 ID

全局唯一性 ID，我们怎么去生成呢？你可以回想下，数据库主键 Id 怎么生成的呢？

是的，我们可以使用 UUID​，但是 UUID 的缺点比较明显，它字符串占用的空间比较大，生成的 ID 过于随机，可读性差，而且没有递增。

‍

我们还可以使用 雪花 ID¹ 生成唯一性 ID。

雪花算法是一种生成分布式全局唯一 ID 的算法，生成的 ID 称为 Snowflake IDs​。这种算法由 Twitter 创建，并用于推文的 ID。

一个 Snowflake ID 有 64 位。

• 第 1 位：Java 中 long 的最高位是符号位代表正负，正数是 0，负数是 1，一般生成 ID 都为正数，所以默认为 0。
• 接下来前 41 位是时间戳，表示了自选定的时期以来的毫秒数。
• 接下来的 10 位代表计算机 ID，防止冲突。
• 其余 12 位代表每台机器上生成 ID 的序列号，这允许在同一毫秒内创建多个 Snowflake ID。

​

‍

‍

当然，全局唯一性的 ID，还可以使用百度的 Uidgenerator​，或者美团的 Leaf​。

‍

‍

幂等设计的基本流程

幂等处理的过程，说到底其实就是过滤一下已经收到的请求，当然，请求一定要有一个 全局唯一的ID标记​哈。然后，怎么判断请求是否之前收到过呢？把请求储存起来，收到请求时，先查下存储记录，记录存在就返回上次的结果，不存在就处理请求。

一般的幂等处理就是这样啦，如下：

​​

‍

‍

实现幂等的 8 种方案

实现幂等需要唯一 ID，那么判断唯一 ID 需要一个存放 ID 数据库。数据库的选择可以是 MySQL 等关系型数据库，或者 Redis 等非关系型数据库

‍

select+insert+ 主键/唯一索引冲突

日常开发中，为了实现交易接口幂等，我是这样实现的：

交易请求过来，我会先根据请求的唯一流水号​bizSeq​字段，先 select​一下数据库的流水表

• 如果数据已经存在，就拦截是重复请求，直接返回成功；
• 如果数据不存在，就执行 insert​插入，如果 insert​成功，则直接返回成功，如果 insert​产生主键冲突异常，则捕获异常，接着直接返回成功。

流程图如下

​​

伪代码如下：

/**
 * 幂等处理
 */
Rsp idempotent（Request req）{
  Object requestRecord =selectByBizSeq（bizSeq）;
  
  if(requestRecord !=null){
    //拦截是重复请求
     log.info("重复请求，直接返回成功，流水号：{}",bizSeq);
     return rsp;
  }
  
  try{
    insert(req);
  }catch(DuplicateKeyException e){
    //拦截是重复请求，直接返回成功
    log.info("主键冲突，是重复请求，直接返回成功，流水号：{}",bizSeq);
    return rsp;
  }
  
  //正常处理请求
  dealRequest(req);
  
  return rsp;
}

为什么前面已经 select​查询了，还需要 try...catch...​捕获重复异常呢？

是因为高并发场景下，两个请求去 select​的时候，可能都没查到，然后都走到 insert 的地方啦。

当然，用唯一索引代替数据库主键也是可以的哈，都是全局唯一的 ID 即可。

‍

‍

直接 insert + 主键/唯一索引冲突

在 5.1 方案中，都会先查一下流水表的交易请求，判断是否存在，然后不存在再插入请求记录。如果重复请求的概率比较低的话，我们可以直接插入请求，利用主键/唯一索引冲突，去判断是重复请求。

‍

流程图如下：

​​

伪代码如下：

/**
 * 幂等处理
 */
Rsp idempotent（Request req）{
  
  try{
    insert(req);
  }catch(DuplicateKeyException e){
     //拦截是重复请求，直接返回成功
    log.info("主键冲突，是重复请求，直接返回成功，流水号：{}",bizSeq);
    return rsp;
  }
  
  //正常处理请求
  dealRequest(req);
  return rsp;
}

‍

温馨提示 :

大家别搞混哈，防重和幂等设计其实是有区别的。防重主要为了避免产生重复数据，把重复请求拦截下来即可。而幂等设计除了拦截已经处理的请求，还要求每次相同的请求都返回一样的效果。不过呢，很多时候，它们的处理流程可以是类似的。

‍

‍

状态机幂等

很多业务表，都是有状态的，比如转账流水表，就会有 0-待处理，1-处理中、2-成功、3-失败状态​。转账流水更新的时候，都会涉及流水状态更新，即涉及状态机 (即状态变更图)。我们可以利用状态机实现幂等，一起来看下它是怎么实现的。

比如转账成功后，把处理中的转账流水更新为成功状态，SQL 这么写：

update transfr_flow set status=2 where biz_seq=‘666’ and status=1;

简要流程图如下：

​​

伪代码实现如下：

Rsp idempotentTransfer（Request req）{
   String bizSeq = req.getBizSeq();
   int rows= "update transfr_flow set status=2 where biz_seq=#{bizSeq} and status=1;"
   if(rows==1){
      log.info(“更新成功,可以处理该请求”);
      //其他业务逻辑处理
      return rsp;
   }else if(rows==0){
      log.info(“更新不成功，不处理该请求”);
      //不处理，直接返回
      return rsp;
   }
   
   log.warn("数据异常")
   return rsp：
}

状态机是怎么实现幂等的呢？

• 第 1 次请求来时，bizSeq 流水号是 666​，该流水的状态是处理中，值是 1​，要更新为 2-成功的状态​，所以该 update 语句可以正常更新数据，sql 执行结果的影响行数是 1，流水状态最后变成了 2。
• 第 2 请求也过来了，如果它的流水号还是 666​，因为该流水状态已经 2-成功的状态​了，所以更新结果是 0，不会再处理业务逻辑，接口直接返回。

‍

抽取防重表

5.1 和 5.2 的方案，都是建立在业务流水表上 bizSeq​的唯一性上。

很多时候，我们业务表唯一流水号希望后端系统生成，又或者我们希望防重功能与业务表分隔开来，这时候我们可以单独搞个防重表。当然防重表也是利用主键/索引的唯一性，如果插入防重表冲突即直接返回成功，如果插入成功，即去处理请求。

‍

token 令牌

token 令牌方案一般包括两个请求阶段：

1. 客户端请求申请获取 token，服务端生成 token 返回
2. 客户端带着 token 请求，服务端校验 token

流程图如下：

​​

1. 客户端发起请求，申请获取 token。
2. 服务端生成全局唯一的 token，保存到 redis 中（一般会设置一个过期时间），然后返回给客户端。
3. 客户端带着 token，发起请求。
4. 服务端去 redis 确认 token 是否存在，一般用 redis.del(token)​的方式，如果存在会删除成功，即处理业务逻辑，如果删除失败不处理业务逻辑，直接返回结果。

‍

这就是 Austin 消息去重处理¹ 的方法！！！

‍

‍

悲观锁 (如 select for update)

什么是悲观锁？

通俗点讲就是很悲观，每次去操作数据时，都觉得别人中途会修改，所以每次在拿数据的时候都会上锁。官方点讲就是，共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程。

‍

悲观锁如何控制幂等的呢？就是加锁呀，一般配合事务来实现。

举个更新订单的业务场景：

假设先查出订单，如果查到的是处理中状态，就处理完业务，再然后更新订单状态为完成。如果查到订单，并且是不是处理中的状态，则直接返回

整体的伪代码如下：

begin;  # 1.开始事务
select * from order where order_id='666' # 查询订单，判断状态
if（status !=处理中）{
   //非处理中状态，直接返回；
   return ;
}
## 处理业务逻辑
update order set status='完成' where order_id='666' # 更新完成
commit; # 5.提交事务

这种场景是非原子操作的，在高并发环境下，可能会造成一个业务被执行两次的问题：

‍

当一个请求 A 在执行中时，而另一个请求 B 也开始状态判断的操作。因为请求 A 还未来得及更改状态，所以请求 B 也能执行成功，这就导致一个业务被执行了两次。

可以使用数据库悲观锁（select ...for update​）解决这个问题.

begin;  # 1.开始事务
select * from order where order_id='666' for update # 查询订单，判断状态,锁住这条记录
if（status !=处理中）{
   //非处理中状态，直接返回；
   return ;
}
## 处理业务逻辑
update order set status='完成' where order_id='666' # 更新完成
commit; # 5.提交事务

• 这里面 order_id 需要是索引或主键哈，要锁住这条记录就好，如果不是索引或者主键，会锁表的！
• 悲观锁在同一事务操作过程中，锁住了一行数据。别的请求过来只能等待，如果当前事务耗时比较长，就很影响接口性能。所以一般不建议用悲观锁做这个事情。

‍

乐观锁

悲观锁有性能问题，可以试下乐观锁。

什么是乐观锁？

乐观锁在操作数据时,则非常乐观，认为别人不会同时在修改数据，因此乐观锁不会上锁。只是在执行更新的时候判断一下，在此期间别人是否修改了数据。

怎样实现乐观锁呢？

就是给表的加多一列 version​版本号，每次更新记录 version​都升级一下（version=version+1​）。具体流程就是先查出当前的版本号 version​，然后去更新修改数据时，确认下是不是刚刚查出的版本号，如果是才执行更新

比如，我们更新前，先查下数据，查出的版本号是 version =1​

select order_id，version from order where order_id='666'；

然后使用 version =1​和 订单Id​一起作为条件，再去更新

update order set version = version +1，status='P' where  order_id='666' and version =1

最后更新成功，才可以处理业务逻辑，如果更新失败，默认为重复请求，直接返回。

‍

流程图如下：

​

​

为什么版本号建议自增的呢？

因为乐观锁存在 ABA 的问题，如果 version 版本一直是自增的就不会出现 ABA 的情况啦。

‍

‍

分布式锁

分布式锁实现幂等性的逻辑就是，请求过来时，先去尝试获得分布式锁，如果获得成功，就执行业务逻辑，反之获取失败的话，就舍弃请求直接返回成功。执行流程如下图所示：

​​

• 分布式锁可以使用 Redis，也可以使用 ZooKeeper，不过还是 Redis 相对好点，因为较轻量级。
• Redis 分布式锁，可以使用命令 SET EX PX NX + 唯一流水号​实现，分布式锁的 key​必须为业务的唯一标识哈
• Redis 执行设置 key 的动作时，要设置过期时间哈，这个过期时间不能太短，太短拦截不了重复请求，也不能设置太长，会占存储空间。

‍

‍

‍

HTTP 的幂等

我们的接口，一般都是基于 http 的，所以我们再来聊聊 Http 的幂等吧。HTTP 请求方法主要有以下这几种，我们看下各个接口是否都是幂等的。

• GET 方法
• HEAD 方法
• OPTIONS 方法
• DELETE 方法
• POST 方法
• PUT 方法

‍

6.1 GET 方法

HTTP 的 GET 方法用于获取资源，可以类比于数据库的 select​查询，不应该有副作用，所以是幂等的。它不会改变资源的状态，不论你调用一次还是调用多次，效果一样的，都没有副作用。

如果你的 GET 方法是获取最近最新的新闻，不同时间点调用，返回的资源内容虽然不一样，但是最终对资源本质是没有影响的哈，所以还是幂等的。

‍

6.2 HEAD 方法

HTTP HEAD 和 GET 有点像，主要区别是 HEAD​不含有呈现数据，而仅仅是 HTTP 的头信息，所以它也是幂等的。如果想判断某个资源是否存在，很多人会使用 GET​，实际上用 HEAD​则更加恰当。即 HEAD​方法通常用来做探活使用。

‍

6.3 OPTIONS 方法

HTTP OPTIONS 主要用于获取当前 URL 所支持的方法，也是有点像查询，因此也是幂等的。

‍

6.4 DELETE 方法

HTTP DELETE 方法用于删除资源，它是的幂等的。比如我们要删除 id=666​​的帖子，一次执行和多次执行，影响的效果是一样的呢。

‍

6.5 POST 方法

HTTP POST 方法用于创建资源，可以类比于 提交信息​，显然一次和多次提交是有副作用，执行效果是不一样的，不满足幂等性。

比如：POST http://www.tianluo.com/articles 的语义是在 http://www.tianluo.com/articles 下创建一篇帖子，HTTP 响应中应包含帖子的创建状态以及帖子的 URI。两次相同的 POST 请求会在服务器端创建两份资源，它们具有不同的 URI；所以，POST 方法不具备幂等性。

‍

6.6 PUT 方法

HTTP PUT 方法用于创建或更新操作，所对应的 URI 是要创建或更新的资源本身，有副作用，它应该满足幂等性。

比如：PUT http://www.tianluo.com/articles/666 的语义是创建或更新 ID 为 666 的帖子。对同一 URI 进行多次 PUT 的副作用和一次 PUT 是相同的；因此，PUT 方法具有幂等性。 ↩

分布式锁

分布式锁实现幂等性的逻辑就是，请求过来时，先去尝试获得分布式锁，如果获得成功，就执行业务逻辑，反之获取失败的话，就舍弃请求直接返回成功。执行流程如下图所示：

​​

• 分布式锁可以使用 Redis，也可以使用 ZooKeeper，不过还是 Redis 相对好点，因为较轻量级。
• Redis 分布式锁，可以使用命令 SET EX PX NX + 唯一流水号​实现，分布式锁的 key​必须为业务的唯一标识哈
• Redis 执行设置 key 的动作时，要设置过期时间哈，这个过期时间不能太短，太短拦截不了重复请求，也不能设置太长，会占存储空间。

‍

‍

‍

token 令牌

token 令牌方案一般包括两个请求阶段：

1. 客户端请求申请获取 token，服务端生成 token 返回
2. 客户端带着 token 请求，服务端校验 token

流程图如下：

​​

1. 客户端发起请求，申请获取 token。
2. 服务端生成全局唯一的 token，保存到 redis 中（一般会设置一个过期时间），然后返回给客户端。
3. 客户端带着 token，发起请求。
4. 服务端去 redis 确认 token 是否存在，一般用 redis.del(token)​的方式，如果存在会删除成功，即处理业务逻辑，如果删除失败不处理业务逻辑，直接返回结果。

‍

这就是 Austin 消息去重处理¹ 的方法！！！

‍

‍ ↩

消息去重处理

文章详解：Austin 消息去重详解（面试）

前言

之前的去重服务是基于 Redis 来实现的。每条信息发送的时候，都将该信息的 ID 信息备份一份到 Redis 中。当下次发送的时候，再去 Redis 上查询是否存在，以达到去重的效果

‍

现在对去重模块进行重构。采用 中介者模式（Mediator）¹ + 策略模式（Strategy）¹，方便引入多种去重逻辑

• 基于发送次数的去重
• 基于滑动窗口的限流去重策略
• 。。。。

‍

使用上述两种设计模式，将去重逻辑与上层调用耦合分离，达到很好的扩展作用。

‍

更新

1. 频次去重采用普通的计数去重方法，限制的是每天发送的条数。
2. 内容去重采用的是新开发的基于 redis​中 zset​的滑动窗口去重，可以做到严格控制单位时间内的频次。
3. redis​使用 lua​脚本来保证原子性和减少网络 io​的损耗
4. redis​的 key​增加前缀做到数据隔离（后期可能有动态更换去重方法的需求）
5. 把具体限流去重方法从 DeduplicationService​抽取出来，DeduplicationService​只需设置构造器注入时注入的 AbstractLimitService​（具体限流去重服务）类型即可动态更换去重的方法 6、使用雪花算法生成 zset​的唯一 value​,score​使用的是当前的时间戳

Redis Lua 脚本

--KEYS[1]: 限流key
--ARGV[1]: 限流窗口，毫秒
--ARGV[2]: 当前时间戳（作为score）
--ARGV[3]: 阈值
--ARGV[4]: key对应的唯一value（使用雪花算法生成，确保唯一）

-- 1. 移除开始窗口前的数据
redis.call('zremrangeByScore', KEYS[1], 0, ARGV[2] - ARGV[1])

-- 2. 统计当前元素数量
local res = redis.call('zcard', KEYS[1])

-- 3. 是否超过阈值
if (res == nil) or (res < tonumber(ARGV[3])) then
	redis.call('zadd', KEYS[1], ARGV[2], ARGV[4])
	redis.call('expire', KEYS[1], ARGV[1] / 1000)
	return 0
else
	return 1
end

​ZADD key score value​

​ZREMRANGEBYSCORE key min max​

• 移除 score 在 [min, max] 范围内的所有 key

‍

‍

设计大纲

​

去重主要由以下组件组成：

• 去重 Service：负责对外提供去重的统一接口

  • 类似于：装饰模式（Wrapper、decorator）¹

• 去重服务 Param：去重服务需要的统一封装参数

• 去重服务 Holder：中介者模式（Mediator）¹，保存着各种去重服务的中介类，用于路由各种去重逻辑

• 去重 limit：实现去重的核心组件。需要调用 redis 上保持的信息，实现最终的去重效果

‍

大致流程

Task 调用 DeduplicationRuleService 中的 deduplicaiton 方法。该方法是整个 去重模块 的总入口：

1. 通过传递的 taskInfo 参数，构建出 deduplicationParam 去重服务封装类

2. 使用 Param，通过 DeduplicationHolder 路由器，路由到指定的去重服务中，由该服务方法执行去重

3. 服务方法使用一个 AbstractDeduplicationService 抽象类管理，Abstract 会直接调用 LimitService 的方法执行去重逻辑

   1. LimitService 也是一个抽象类，实现了不同的去重方法
   2. LimitService 也是直接访问 Redis 的地方。通过 Redis 获取去重相关的唯一 key

‍

所以最终的调用路线是：

DeduplicationRuleService ---> DeduplicationHolder(中介者) ----> AbstractDeduplicationService ---> AbstractLimitService

其他组件都是在此基础上进行增加的，包括那些各式各样的 builder。

• builder 采用简单工厂模式，为的就是易于扩展，同时不需要修改上层调用代码

‍

使用子类而不是 if-else

在去重模块中，遇到不同的去重逻辑，第一时间肯定会想到使用 if-else 分支处理

但是使用 if-else 处理的话，当分支处理的内容越来越多的时候，if-else 的代码量就会越来越长，导致代码变得繁杂，不容易开发与拓展

这时候我们就需要将原本的 if-else 改为使用父子类或者 责任链模式¹，将原本的分支抽离出来。

这样就能够让代码变得简洁、易于拓展与 debug

‍

与之前对比

看了最新的代码，发现最初的去重逻辑放在了 SimpleLimitService 中了：

• 作为其中一种去重策略存在

package com.quan.austinhandler.deduplication.limit;


/**
 * Description:
 * date: 2022/11/13 下午 8:10
 *
 * @author Four
 */
@Service("SimpleLimitService")
public class SimpleLimitService extends AbstractLimitService {

    private static final String LIMIT_TAG = "SP_";

    @Autowired
    private RedisUtils redisUtils;

    @Override
    public Set<String> limitFilter(AbstractDeduplicationService service, TaskInfo taskInfo, DeduplicationParam param) {
        Set<String> filterReceiver = new HashSet<>(taskInfo.getReceiver().size());

        // 存储redis数据
        Map<String, String> readyPutRedisReceiver = new HashMap<>(taskInfo.getReceiver().size());

        // 获取redis中现存的数据
        List<String> keys = deduplicationAllKey(service, taskInfo).stream()
                .map(key -> LIMIT_TAG + key)
                .collect(Collectors.toList());
        Map<String, String > inRedisValues = redisUtils.mGet(keys);


        for (String receiver : taskInfo.getReceiver()) {
            String key = LIMIT_TAG + deduplicationSingleKey(service, taskInfo, receiver);
            String inRedisValue = inRedisValues.get(key);

            if (inRedisValue != null && Integer.parseInt(inRedisValue) >= param.getCountNum()) {
                filterReceiver.add(receiver);
            } else {
                readyPutRedisReceiver.put(receiver,  key);     // 相当于更新对应的receiver
            }
        }

        // 不符合条件的用户：需要更新Redis(无记录添加，有记录则累加次数)
        putInRedis(readyPutRedisReceiver, inRedisValues, param.getDeduplicationTime());

        return filterReceiver;
    }

    // 存入redis做记录，用作去重标记
    private void putInRedis(Map<String, String> readyPutRedisReceiver, Map<String, String> inRedisValues, Long deduplicationTime) {
        Map<String, String> updateData = new HashMap<>(readyPutRedisReceiver.size());
        for (Map.Entry<String, String> entry : readyPutRedisReceiver.entrySet()) {
            String key = entry.getKey();
            if (inRedisValues.containsKey(key)) {
                updateData.put(key, String.valueOf(Integer.parseInt(inRedisValues.get(key)) + 1));
            } else {
                updateData.put(key, String.valueOf(AustinConstant.TRUE));
            }
        }

        if (CollUtil.isNotEmpty(updateData)) {
            redisUtils.pipelineSetEx(updateData, deduplicationTime);
        }
    }
}

‍ ↩ ↩

中介者模式（Mediator）

实战使用

Austin 中介者模式使用¹​

• 通过一个 HandlerHolder，管理一个对象与一组对象直接的交互

‍

‍

定义

原文：中介者设计模式 (refactoringguru.cn)

​

‍

中介者模式建议你停止组件之间的直接交流并使其相互独立**。** 这些组件必须调用特殊的中介者对象**，** 通过中介者对象重定向调用行为**，** 以间接的方式进行合作**。** 最终**，** 组件仅依赖于一个中介者类**，** 无需与多个其他组件相耦合**。**

‍

‍

结构

​

‍

‍

‍

中介者模式适合应用场景

当一些对象和其他对象紧密耦合以致难以对其进行修改时**，** 可使用中介者模式**。**

该模式让你将对象间的所有关系抽取成为一个单独的类**，** 以使对于特定组件的修改工作独立于其他组件**。**

当组件因过于依赖其他组件而无法在不同应用中复用时**，** 可使用中介者模式**。**

应用中介者模式后**，** 每个组件不再知晓其他组件的情况**。** 尽管这些组件无法直接交流**，** 但它们仍可通过中介者对象进行间接交流**。** 如果你希望在不同应用中复用一个组件**，** 则需要为其提供一个新的中介者类**。**

如果为了能在不同情景下复用一些基本行为**，** 导致你需要被迫创建大量组件子类时**，** 可使用中介者模式**。**

由于所有组件间关系都被包含在中介者中**，** 因此你无需修改组件就能方便地新建中介者类以定义新的组件合作方式**。**

‍

‍

实现方式

1. 找到一组当前紧密耦合**，** 且提供其独立性能带来更大好处的类**（例如更易于维护或更方便复用**）。
2. 声明中介者接口并描述中介者和各种组件之间所需的交流接口**。** 在绝大多数情况下**，** 一个接收组件通知的方法就足够了**。**
   如果你希望在不同情景下复用组件类**，** 那么该接口将非常重要**。** 只要组件使用通用接口与其中介者合作**，** 你就能将该组件与不同实现中的中介者进行连接**。**
3. 实现具体中介者类**。** 该类可从自行保存其下所有组件的引用中受益**。**
4. 你可以更进一步**，** 让中介者负责组件对象的创建和销毁**。** 此后**，** 中介者可能会与工厂或外观类似**。**
5. 组件必须保存对于中介者对象的引用**。** 该连接通常在组件的构造函数中建立**，** 该函数会将中介者对象作为参数传递**。**
6. 修改组件代码**，** 使其可调用中介者的通知方法**，** 而非其他组件的方法**。** 然后将调用其他组件的代码抽取到中介者类中**，** 并在中介者接收到该组件通知时执行这些代码**。**

‍

‍

中介者模式优缺点

优点：

• ​单职​原​一责​则​**。** 你可以将多个组件间的交流抽取到同一位置**，** 使其更易于理解和维护**。**
• ​开原​闭则​**。** 你无需修改实际组件就能增加新的中介者**。**
• 你可以减轻应用中多个组件间的耦合情况**。**
• 你可以更方便地复用各个组件**。**

‍

缺点：

• 一段时间后**，** 中介者可能会演化成为上帝对象。

  • 负责过多的职责，导致这个类过于臃肿

‍

‍

‍

与其他模式的关联

• 责任链模式​**、​** 和用于处理请求发送者和接收者之间的不同连接方式​​：

  • 责链​任按照顺序将请求动态传递给一系列的潜在接收者**，** 直至其中一名接收者对请求进行处理**。**
  • 命​令在发送者和请求者之间建立单向连接**。**
  • 中者​介清除了发送者和请求者之间的直接连接**，** 强制它们通过一个中介对象进行间接沟通**。**
  • 观者​察允许接收者动态地订阅或取消接收请求**。**

• 外观模式和中介者的职责类似**：** 它们都尝试在大量紧密耦合的类中组织起合作**。**

  • 外​观为子系统中的所有对象定义了一个简单接口**，** 但是它不提供任何新功能**。** 子系统本身不会意识到外观的存在**。** 子系统中的对象可以直接进行交流**。**
  • 中者​介将系统中组件的沟通行为中心化**。** 各组件只知道中介者对象**，** 无法直接相互交流**。**

• 中介者和观察者之间的区别往往很难记住**。** 在大部分情况下**，** 你可以使用其中一种模式**，** 而有时可以同时使用**。** 让我们来看看如何做到这一点**。**

  • 中者​介的主要目标是消除一系列系统组件之间的相互依赖**。** 这些组件将依赖于同一个中介者对象**。** 观者​察的目标是在对象之间建立动态的单向连接**，** 使得部分对象可作为其他对象的附属发挥作用**。**
    有一种流行的中介者模式实现方式依赖于观者​察​**。** 中介者对象担当发布者的角色**，** 其他组件则作为订阅者**，** 可以订阅中介者的事件或取消订阅**。** 当中者​介以这种方式实现时**，** 它可能看上去与观者​察非常相似**。**
    当你感到疑惑时**，** 记住可以采用其他方式来实现中介者**。** 例如**，** 你可永久性地将所有组件链接到同一个中介者对象**。** 这种实现方式和观者​察并不相同**，** 但这仍是一种中介者模式**。**
    假设有一个程序**，** 其所有的组件都变成了发布者**，** 它们之间可以相互建立动态连接**。** 这样程序中就没有中心化的中介者对象**，** 而只有一些分布式的观察者**。**

‍

‍

‍

‍

实例代码

以公共聊天室为例，最小单元示例步骤：

• 1、创建中介类。

  public class CharRoom {
      public static void showMessage(User user, String message) {
          Log.e("---", new Date().toString()
                  + " [" + user.getName() + "] : " + message);
      }
  }
        
      

• 2、创建 user 类。

  public class User {
      private String name;
  
      public User(String name) {
          this.name = name;
      }
  
      public String getName() {
          return name;
      }
  
      public void setName(String name) {
          this.name = name;
      }
  
      public void sendMessage(String message) {
      	  // 使用中介类
          CharRoom.showMessage(this, message);
      }
  }
  
  
  

• 3、使用 User 对象来显示他们之间的通信。

      User jingbin = new User("jingbin");
      jingbin.sendMessage("Hi~ youlookwhat!");
      //---: Sun Feb 02 08:11:47 GMT+00:00 2020 [jingbin] : Hi~ youlookwhat!
  
      User jingbin = new User("youlookwhat");
      jingbin.sendMessage("Hi~ jingbin!");
      //---: Sun Feb 02 08:11:49 GMT+00:00 2020 [youlookwhat] : Hi~ jingbin!
  

  ↩ ↩

代码中的实现逻辑

​

• 对于 “一对多” 的处理方式，均采用 Map 实现路由器的操作
• 方便对代码进行统一管理！

‍ ↩

策略模式（Strategy）

定义

如果一个类实现某种功能可以用不同的方法，那么策略模式就是对这些 ”不同的方法“ 进行封装的方式，它可以使这些算法按照需求进行替换，使得这个类实现功能的时候可以选择不同的方法。

策略模式是针对程序运行时的算法的。

‍

‍

真实世界类比

​

各种前往机场的出行策略

假如你需要前往机场**。** 你可以选择乘坐公共汽车**、** 预约出租车或骑自行车**。** 这些就是你的出行策略**。** 你可以根据预算或时间等因素来选择其中一种策略**。**

‍

‍

策略模式适合应用场景

当你想使用对象中各种不同的算法变体**，** 并希望能在运行时切换算法时**，** 可使用策略模式**。**

• 策略模式让你能够将对象关联至可以不同方式执行特定子任务的不同子对象**，** 从而以间接方式在运行时更改对象行为**。**

‍

当你有许多仅在执行某些行为时略有不同的相似类时**，** 可使用策略模式**。**

• 策略模式让你能将不同行为抽取到一个独立类层次结构中**，** 并将原始类组合成同一个**，** 从而减少重复代码**。**

‍

如果算法在上下文的逻辑中不是特别重要**，** 使用该模式能将类的业务逻辑与其算法实现细节隔离开来**。**

• 策略模式让你能将各种算法的代码**、** 内部数据和依赖关系与其他代码隔离开来**。** 不同客户端可通过一个简单接口执行算法**，** 并能在运行时进行切换**。**

‍

‍

‍

结构

​

‍

‍

实例代码

原本的实现

假设有一个 Role 接口，里面定义了很多方法。我们需要创建 RoleA、RoleB 去实现这个接口。

这样的话，A 和 B 都必须将 Role 接口中的所有方法都实现了，才能够正常运行。A 和 B 中的方法有可能出现重复情况，这时候就有冗余代码：

    public RoleB(String name) {
        this.name = name;
    }

    @Override
    protected void display() {
        Log.e("", "样子2");
    }

    @Override
    protected void run() {
        Log.e("", "金蝉脱壳");//拷贝,显得冗余
    }

    @Override
    protected void attack() {
        Log.e("", "降龙十八掌");//拷贝,显得冗余
    }

    @Override
    protected void defend() {
        Log.e("", "铁布衫");
    }

• A 与 B 出现重复的地方

‍

‍

将方法给抽离出来

我们将里面的方法抽象为一个接口，这样我们就可以根据算法的不同来创建不同的实现类的。而且 RoleA、RoleB 的实现，只需要导入两者需要的实现类，而不需要在这两者中重复实现

public abstract class Role {

    protected String name;

    private IDisplayBehavior iDisplayBehavior;
    private IDefendBehavior iDefendBehavior;
    private IRunBehavior iRunBehavior;
    private IAttackBehavior iAttackBehavior;

​

• 实现类

‍

每个 Role 实现类按需导入：（相当于选择自己适合的 ”策略”）

RoleA roleA = new RoleA("---A");
roleA.setiDisplayBehavior(new DisplayYZ())
      .setiAttackBehavior(new AttackXL())
      .setiDefendBehavior(new DefendTMS())
      .setiRunBehavior(new RunJCTQ());
roleA.display();// 样子
roleA.attack();// 攻击
roleA.run();// 逃跑
roleA.defend();// 防御

‍

‍

本质上是通过接口将实现类进行抽离，这样就能够尽可能将冗余代码消除。

‍

‍

‍ ↩

装饰模式（Wrapper、decorator）

装饰设计（装饰者模式 / 装饰器模式） (refactoringguru.cn)

‍

定义

装饰模式是一种结构型设计模式**，** 允许你通过将对象放入包含行为的特殊封装对象中来为原对象绑定新的行为**。**

​

‍

动态地给子类添加额外更多的功能。

并且在不需要额外创造更多子类的情况下，将对象的功能继续扩展

‍

‍

代码拓展问题

在项目开发后期，如果需要对该类进行拓展的话，有可能会造成代码量的激增，并且使代码难以管理

‍

假设你正在开发一个提供通知功能的库**，** 其他程序可使用它向用户发送关于重要事件的通知**。**

库的最初版本基于** 通知器​Noti­fi­er 类，** 其中只有很少的几个成员变量**，** 一个构造函数和一个** send​发送方法。** 该方法可以接收来自客户端的消息参数**，** 并将该消息发送给一系列的邮箱**，** 邮箱列表则是通过构造函数传递给通知器的**。** 作为客户端的第三方程序仅会创建和配置通知器对象一次**，** 然后在有重要事件发生时对其进行调用**。**

​

程序可以使用通知器类向预定义的邮箱发送重要事件通知。

此后某个时刻**，** 你会发现库的用户希望使用除邮件通知之外的功能**。** 许多用户会希望接收关于紧急事件的手机短信**，** 还有些用户希望在微信上接收消息**，** 而公司用户则希望在 QQ 上接收消息**。**

​

每种通知类型都将作为通知器的一个子类得以实现。

这有什么难的呢**？** 首先扩展** 通知器​类，** 然后在新的子类中加入额外的通知方法**。** 现在客户端要对所需通知形式的对应类进行初始化**，** 然后使用该类发送后续所有的通知消息**。**

但是很快有人会问**：** ​** “为什么不同时使用多种通知形式呢？** 如果房子着火了**，** 你大概会想在所有渠道中都收到相同的消息吧**。” **

你可以尝试创建一个特殊子类来将多种通知方法组合在一起以解决该问题**。** 但这种方式会使得代码量迅速膨胀**，** 不仅仅是程序库代码**，** 客户端代码也会如此**。**

​

子类组合数量爆炸。

‍

你必须找到其他方法来规划通知类的结构**，** 否则它们的数量会在不经意之间打破吉尼斯纪录**。**

‍

真实世界类比

​

穿上多件衣服将获得组合性的效果。

穿衣服是使用装饰的一个例子**。** 觉得冷时**，** 你可以穿一件毛衣**。** 如果穿毛衣还觉得冷**，** 你可以再套上一件夹克**。** 如果遇到下雨**，** 你还可以再穿一件雨衣**。** 所有这些衣物都** “扩展”** 了你的基本行为**，** 但它们并不是你的一部分**，** 如果你不再需要某件衣物**，** 可以方便地随时脱掉**。**

使代码对修改 关闭，对增加 开发

‍

‍

结构

​

‍

‍

‍

实现代码

装饰者模式：若要扩展功能，装饰者提供了比集成更有弹性的替代方案，动态地将责任附加到对象上。

• 先简单描述下装饰者模式发挥作用的地方，当我们设计好了一个类，我们需要给这个类添加一些辅助的功能，并且不希望改变这个类的代码，这时候就是装饰者模式大展雄威的时候了。这里还体现了一个原则：类应该对扩展开放，对修改关闭。

• 需求：设计游戏的装备系统，基本要求，要可以计算出每种装备在镶嵌了各种宝石后的攻击力和描述：

• 1、装备的超类：IEquip.java

  • public interface IEquip {
    
        /**
         * 计算攻击力
         */
        public int caculateAttack();
    
        /**
         * 装备的描述
         */
        public String description();
    }
    

• 2、各个装备的实现类：

  • eg：武器的实现类: ArmEquip.java

  • public class ArmEquip implements IEquip {
    
        @Override
        public int caculateAttack() {
            return 20;
        }
    
        @Override
        public String description() {
            return "屠龙宝刀";
        }
    }
    

• 3、装饰品的超类（装饰品也属于装备）：IEquipDecorator.java

  • public interface IEuipDecorator extends IEquip {
    }
    

• 4、装饰品的实现类：

  • eg：蓝宝石的实现类(可累加): BlueGemDecorator.java

    • public class BlueGemDecorator implements IEuipDecorator {
      
          private IEquip iEquip;
      
          public BlueGemDecorator(IEquip iEquip) {
              this.iEquip = iEquip;
          }
      
          /**
           * 累加攻击力
           */
          @Override
          public int caculateAttack() {
              return 5 + iEquip.caculateAttack();
          }
      
          @Override
          public String description() {
              return iEquip.description() + "+ 蓝宝石";
          }
      }
      

  • 红宝石装饰类

    • public class RedGemDecorator implements IEuipDecorator {
      
          private IEquip iEquip;
      
          public RedGemDecorator(IEquip iEquip) {
              this.iEquip = iEquip;
          }
      
          /**
           * 累加攻击力
           */
          @Override
          public int caculateAttack() {
              return 15 + iEquip.caculateAttack();
          }
      
          @Override
          public String description() {
              return iEquip.description() + "+ 红宝石";
          }
      }
      

• 5、最后测试：计算攻击力和查看描述：

   Log.e("---", "一个镶嵌2颗红宝石,1颗蓝宝石的靴子: ");
   IEquip iEquip = new RedGemDecorator(new RedGemDecorator(new BlueGemDecorator(new ShoeEquip())));
   Log.e("---", "攻击力:" + iEquip.caculateAttack());
   Log.e("---", "描述语:" + iEquip.description());
  
  
  

‍

‍

上述装饰类都继承自一个基类 IEquip。同时，每个装饰类中，都有 IEquip 类

这样就能够实现 “嵌套” 装饰了！！！ ↩

责任链模式

关联项目

项目中的责任链模式主要在 support 模块下的 pipeline 包中：

‍

‍

责任链通用实现

现在我就默认大家都知道什么是责任链模式了，如果还对这个不懂的同学，可以先看看我之前的文章。

‍

首先，我们会有一个业务执行器接口，所有的业务实现都会实现该接口，这意味着上图的 逻辑A、B、C 都会实现这个接口

/**
 * 业务执行器
 * @author 三歪
 */
public interface BusinessProcess {
    void process(ProcessContext context);
}

可以看到的是接口异常的简单，只有一个 process 处理的方法，方法接收的是 ProcessContext

‍

‍

为什么 process 方法需要接收 ProcessContext？很简单，我们在处理 逻辑A、B、C 的时候，可能 逻辑B 需要依赖 逻辑A 的处理结果。于是我们就需要有一个载体把这些给记录下来。

所以，我们就有了 ProcessContext，它代表的是责任链的上下文。

/**
 * 责任链上下文
 * @author 3y
 */
public class ProcessContext {
    // 标识责任链的code
    private String code;
    // 存储上下文的真正载体
    private Model model;
    // 责任链中断的标识
    private Boolean needBreak = false;
}

现在责任链的执行器和责任链所涉及的上下文都已经有了，这意味着我们已经有了责任链最主要的抽象了。

‍

‍

接下来就是我们需要把链给串起来，于是我们需要一个 模板 ，其实我们做的就是用一个 List 来把 BusinessProcess 的子类给串起来。

/**
 * 业务执行模板（把责任链的逻辑串起来）
 * @author 3y
 */
public class ProcessTemplate {
    private List<BusinessProcess> processList;
    public List<BusinessProcess> getProcessList() {
        return processList;
    }
    public void setProcessList(List<BusinessProcess> processList) {
        this.processList = processList;
    }
}

‍

‍

OK，现在我们已经把责任链的整块给抽象好了，接下来就是暴露流程控制器去执行这个责任链：

/**
 * 责任链的流程控制器（整个责任链的执行流程通用控制）
 * @author 3y 
 */
@Data
public class ProcessController {
    
    // 不同的code 对应不同的责任链
    private Map<String, ProcessTemplate> templateConfig = null;

    public void process(ProcessContext context) {
        //根据上下文的Code 执行不同的责任链
        String businessCode = context.getCode();
        ProcessTemplate processTemplate = templateConfig.get(businessCode);
        List<BusinessProcess> actionList = processTemplate.getProcessList();
        //遍历某个责任链的流程节点
        for (BusinessProcess action : actionList) {
            try {
                action.process(context);
                if (context.getNeedBreak()) {
                    break;
                }
            } catch (Exception e2) {
                //...
            }
        }
    }
}

我们可以看到的是在 ProcessController 执行链通用的流程控制器上会有一个 Map 去存储多个责任链的模板，这样做的好处就是：ProcessController 这个流程控制器可以根据 code 支持多个责任链执行。

接下来就是我们有具体的 BusinessProcess 去加入到 ProcessTemplate 的链上，然后调用 ProcessController 的方法去执行整一条推送链。

‍

‍

一般我们在 XML 注入就好了，比如说现在我们有两个 BusinessProcess 的实现，分别是白名单和发消息的逻辑：

/**
 * 白名单处理器
 * @author 3y
 */
@Service
public class WhiteListProcess implements BusinessProcess {
    @Override
    public void process(ProcessContext context) {
        UserModel user = (UserModel) context.getModel();
        if ("3y".equals(user.getName())) {
            context.setNeedBreak(true);
        }
    }
}

/**
 * 发消息处理器
 * @author 三歪
 */
@Service
public class SendMessageProcess implements BusinessProcess {

    @Override
    public void process(ProcessContext context) {
        UserModel user = (UserModel) context.getModel();
        System.out.println("给"+user.getName()+"发消息");
    }
}

然后我们把上面两个处理器添加到 ProcessTemplate 的模板上，把 ProcessTemplate 添加到 ProcessController 的 Map 上：

<!--发送消息的责任链-->
<bean id="sendMessageTemplate" class="com.chainofresponsibility.ProcessTemplate">
  <property name="processList">
    <list>
      <ref bean="whiteListProcess"></ref>
      <ref bean="sendMessageProcess"></ref>
    </list>
  </property>
</bean>

<!--通用流程处理器，维护多条责任链-->
<bean id="processController" class="com.chainofresponsibility.ProcessController">
  <property name="templateConfig">
    <map>
      <entry key="sendMessage" value-ref="sendMessageTemplate" />
    </map>
  </property>
</bean>

‍

可以用 springboot 代替掉 xml 的注入

‍

‍

‍

然后我们在接口里边执行这个责任链：

@RestController
public class UserController {
    @Autowired
    private ProcessController processController;

    @RequestMapping("/send")
    public void  send(String userName) {
        // 构建上下文
        ProcessContext processContext = new ProcessContext();

        UserModel userModel = new UserModel();
        userModel.setAge("24");
        userModel.setName(userName);
        processContext.setModel(userModel);

        processContext.setCode("sendMessage");

        processController.process(processContext);
    }
}

我做了这么大的一套东西实现了什么功能？其实就一个 if 逻辑：

if ("3y".equals(userModel.getName())) {
  return;
}
System.out.println("给" + userModel.getName() + "发消息");

下面我们还是来看看效果，从功能上我们可以发现，只要我们输入的不是「3y」，那就会打印消息

‍

​

上面的逻辑，实际上就是一套通用的责任链的代码，最核心的其实就是四个角色：「业务抽象接口」、「执行过程中的上下文」、「将业务实现类串起来」和「一个通用的控制器执行责任链」

如果没看懂的同学， 三歪建议再对比一下代码看看 ，责任链这种设计模式是非常好用，在项目里边也是非常常见的。

只要把 BusinessProcess/ProcessContext/ProcessTemplate/ProcessController 的代码给拷过去自己的项目中，这就能帮你把原有的 if else 逻辑给干掉。

‍

‍

‍

Pipeline

不知道大家看过 Pipeline 这个词了没，在学 Redis 的时候可能会见过，在 Redis 里边我们会用 Pipeline 去做批量的操作。

抛开 Redis 的 Pipeline，但从宏观的角度上来，Pipeline 其实是一种架构思想。

同时我也认为它是「责任链模式」的实现之一。

下面来看看我这边的一个 Pipeline 实现的架构图：

可以看到前人实现的 Pipepline 还是相对复杂的，没有上面 通用 的责任链模式好理解，经过分析可以看到都是换汤不换药的。

下次再见到 Pipeline 这个词的时候（因为这个词还是很常见的），你们就应该能想到 责任链模式，然后你就发现你看懂了

‍

‍

‍

‍ ↩

状态机幂等

很多业务表，都是有状态的，比如转账流水表，就会有 0-待处理，1-处理中、2-成功、3-失败状态​。转账流水更新的时候，都会涉及流水状态更新，即涉及状态机 (即状态变更图)。我们可以利用状态机实现幂等，一起来看下它是怎么实现的。

比如转账成功后，把处理中的转账流水更新为成功状态，SQL 这么写：

update transfr_flow set status=2 where biz_seq=‘666’ and status=1;

简要流程图如下：

​​

伪代码实现如下：

Rsp idempotentTransfer（Request req）{
   String bizSeq = req.getBizSeq();
   int rows= "update transfr_flow set status=2 where biz_seq=#{bizSeq} and status=1;"
   if(rows==1){
      log.info(“更新成功,可以处理该请求”);
      //其他业务逻辑处理
      return rsp;
   }else if(rows==0){
      log.info(“更新不成功，不处理该请求”);
      //不处理，直接返回
      return rsp;
   }
   
   log.warn("数据异常")
   return rsp：
}

状态机是怎么实现幂等的呢？

• 第 1 次请求来时，bizSeq 流水号是 666​，该流水的状态是处理中，值是 1​，要更新为 2-成功的状态​，所以该 update 语句可以正常更新数据，sql 执行结果的影响行数是 1，流水状态最后变成了 2。
• 第 2 请求也过来了，如果它的流水号还是 666​，因为该流水状态已经 2-成功的状态​了，所以更新结果是 0，不会再处理业务逻辑，接口直接返回。

‍ ↩

归并排序模板

数组归并

• 基本思路：借助额外空间，合并两个有序数组，得到更长的有序数组。例如：「力扣」第 88 题：合并两个有序数组。
• 算法思想：分而治之（分治思想）。「分而治之」思想的形象理解是「曹冲称象」、MapReduce，在一定情况下可以并行化。

‍

class Solution {
    //归并排序
    public int[] sortArray(int[] nums) {
       return mergeSort(nums, 0, nums.length-1);
         
    }
    public int[] mergeSort(int[] nums, int left, int right){
        //递归退出条件
        //如果左指针大于右指针，就退出循环
        //经过左右拆分，数组元素形成单个元素的树
        if(left >=right){
            return nums;
        }
        //数组中的中位数
        int mid = (right+left)/2;
        //数组左拆分
        mergeSort(nums, left, mid);
        //数组右拆分
        mergeSort(nums, mid+1, right);
        //数组合并，将单个元素进行合并
        return merge(nums, left, mid, right);
    }
    public int[] merge(int[] nums, int left, int mid, int right){
        //定义一个临时数组，存储排序好的元素
        int[] temp = new int[right-left+1];
        //左排序的元素数组的左指针
        int i = left;
        //右排序的元素数组的左指针
        int j = mid+1;
        //定义一个指向临时数组的左指针
        int t = 0;
        //循环判断条件
        //左数组到mid，右数组到right
        //左右数组都有元素的时候，进行比较
        while(i<=mid&&j<=right){
            //取左右数组中较小的元素，填入临时数组中
            //并将较小元素所在数组的左指针和临时数组的左指针都一起右移
            if(nums[i]<=nums[j]){
                temp[t++] = nums[i++];
            }else{
                temp[t++] = nums[j++];
            }
        }
        //当左右数组其中一个数组没有元素的时候
        //如果左数组中还有剩余元素，就将剩余元素全部加入到临时数组中
        while(i<=mid){
            temp[t++]=nums[i++];
        }
        //如果有数组中还有元素，就将剩余元素全部加入到临时数组中
        while(j<=right){
            temp[t++] = nums[j++];
        }
        //将临时数组的元素复制到原数组中去
        for(int k = 0; k<temp.length;k++){
            //特别注意这便nums数组起始位置要从 k+left开始 
            //原因在加右数组的时候，起始位置要加left
            //这里不理解，直接把它记住。
            nums[left+k]=temp[k];
        }
        //返回原数组
        return nums;
    }
}

‍

‍

链表归并

前言

本来这是快手三面的算法题。我告诉面试官“我没做过归并算法，我尝试一下”，结果硬是给我搓出来了。。。

而且算法逻辑上还基本没什么问题的。。。但就是无法输出正确答案。。。面试官都找不到问题所在。。。。

• 不过还好最后过了，幸亏一开始就拼命强调“我没做过”，所以面试官认为我代码能力很强！
• 而且当时我写得特别快。。。。进入状态了！

题目难点

这道题融合了多道算法思路：

1. 使用快慢指针（双指针）¹ 找中点
2. 21. 合并两个有序链表¹
3. 链表截断，然后才能继续递归

当时快速写出的写法

import java.util.*;
public class Main {
    public static void main(String[] args) {
        // 1 4 6 -2 10
        Node head = new Node(0), cur = head;
        cur.next= new Node(1);  cur = cur.next;
        cur.next = new Node(4); cur = cur.next;
        cur.next = new Node(6); cur = cur.next;
        cur.next = new Node(-2); cur = cur.next;
        cur.next = new Node(10);

        Node sortLsit = mergeSort(head.next);
        cur = sortLsit;
        while (cur != null) {
            System.out.println(cur.val);
            cur = cur.next;
        }
    }

    // 升序
    static Node mergeSort(Node head) {
        // 单个点
        if (head == null || head.next == null) return head;

        // 两个值，判断并交换
        if (head.next != null) {
            if (head.next.val < head.val) {
                int temp = head.val;
                head.val = head.next.val;
                head.next.val = temp;
            }
            return head;
        }

        // 拆分，并递归（对半分）
        // 快慢指针找中点
        Node fast = head, slow = fast;
        while (fast != null && fast.next != null) {
            fast = fast.next.next;
            slow = slow.next;
        }
        // 截断链表，并进入下一个递归
        Node first = head, second = slow.next;
        slow.next = null;

        Node c1 = mergeSort(first);
        Node c2 = mergeSort(second);

        // 合并有序链表
        Node newArr = mergeList(c1, c2);

        return newArr;
    }

    static Node mergeList(Node first, Node second) {
        if (first == null) return second;
        if (second == null) return first;

        Node dummy = new Node(-1), cur = dummy;
        Node c1 = first, c2 = second;
        while (c1 != null && c2 != null) {
            if (c1.val < c2.val) {
                cur.next = new Node(c1.val);
                c1 = c1.next;
            } else {
                cur.next = new Node(c2.val);
                c2 = c2.next;
            }

            cur = cur.next;
        }

        while (c1 != null) {
            cur.next = new Node(c1.val);
            c1 = c1.next;
            cur = cur.next;
        }

        while (c2 != null) {
            cur.next = new Node(c2.val);
            c2 = c2.next;
            cur = cur.next;
        }

        return dummy.next;
    }
}

class Node {
    Node next;
    int val;
    Node(int val) {
        this.val = val;
    }
}

‍

模板代码

package com.quan;

import java.util.*;
public class Main {
    public static void main(String[] args) {
        // 1 4 6 -2 10
        Node head = new Node(0), cur = head;
        cur.next= new Node(1);  cur = cur.next;
        cur.next = new Node(4); cur = cur.next;
        cur.next = new Node(6); cur = cur.next;
        cur.next = new Node(-2); cur = cur.next;
        cur.next = new Node(10);

        Node sortLsit = mergeSort(head.next);
        cur = sortLsit;
        while (cur != null) {
            System.out.println(cur.val);
            cur = cur.next;
        }
    }

    // 升序
    static Node mergeSort(Node head) {
        // 单个点
        if (head == null || head.next == null) return head;

        // 拆分，并递归（对半分）
        // 快慢指针找中点
        Node fast = head, slow = head;
        // 要十分注意这里！！！
        while (fast.next != null && fast.next.next != null) {
            fast = fast.next.next;
            slow = slow.next;
        }
        // 截断链表，并进入下一个递归
        Node mid = slow.next;
        slow.next = null;

        // 进入递归
        Node left = mergeSort(head);
        Node right = mergeSort(mid);

        return mergeList(left, right);
    }

    static Node mergeList(Node first, Node second) {
        if (first == null) return second;
        if (second == null) return first;

        Node dummy = new Node(-1), cur = dummy;
        while (first != null && second != null) {
            if (first.val <= second.val) {
                cur.next = new Node(first.val);
                first = first.next;
            } else {
                cur.next = new Node(second.val);
                second = second.next;
            }
            // 一定不要忘记cur指针要前进
            cur = cur.next;
        }

        cur.next = (first != null) ? first : second;

        return dummy.next;
    }
}

class Node {
    Node next;
    int val;
    Node(int val) {
        this.val = val;
    }
}

‍

golang：

/**
 * Definition for singly-linked list.
 * type ListNode struct {
 *     Val int
 *     Next *ListNode
 * }
 */
func sortList(head *ListNode) *ListNode {
	if head == nil || head.Next == nil {
		return head
	}

	// 取中点
	fast, slow := head, head
	for fast.Next != nil && fast.Next.Next != nil {
		fast = fast.Next.Next
		slow = slow.Next
	}

	first, second := head, slow.Next
	// 截断处理
	slow.Next = nil

	return mergeList(sortList(first), sortList(second))
}

func mergeList(left, right *ListNode) *ListNode {
	dummy := &ListNode{}
	cur := dummy

	for left != nil && right != nil {
		if left.Val < right.Val {
			cur.Next = &ListNode{Val: left.Val}
			left = left.Next
		} else {
			cur.Next = &ListNode{Val: right.Val}
			right = right.Next
		}

		cur = cur.Next
	}

	if left != nil {
		cur.Next = left
	} else {
		cur.Next = right
	}

	return dummy.Next
}

‍

核心代码模式

class Solution {
    public ListNode sortList(ListNode head) {
        //如果链表为空，或者只有一个节点，直接返回即可，不用排序
        if (head == null || head.next == null)
            return head;
      
        //快慢指针移动，以寻找到中间节点
        ListNode slow = head;
        ListNode fast = head;
        while(fast.next!=null && fast.next.next !=null){
          fast = fast.next.next;
          slow = slow.next;
        }
        //找到中间节点，slow节点的next指针，指向mid
        ListNode mid = slow.next;
        //切断链表
        slow.next = null;
      
        //排序左子链表
        ListNode left = sortList(head);
        //排序左子链表
        ListNode right = sortList(mid);
      
        //合并链表
        return merge(left,right);
    }
      
    public ListNode merge(ListNode left, ListNode right) {
       ListNode head = new ListNode(0);
       ListNode temp = head;
       while (left != null && right != null) {
           if (left.val <= right.val) {
                temp.next = left;
                left = left.next;
            } else {
                temp.next = right;
                right = right.next;
            }
            temp = temp.next;
        }
          
		temp.next = (left != null) ? left : right;

        return head.next;
    }
}

‍

之前自己的错误点

1. 使用快慢指针（双指针）¹ while 条件写错

   1. 错误：while (fast != null && fast.next != null)​ —— 直接导致空指针异常！！！
   2. 正确：​while (fast.next != null && fast.next.next != null)​

2. 递归终止条件错误

   1. 不应该设置“两个节点”判断作为第二个终止条件，这个设置直接导致无法排序！！！

      1.          // 两个值，判断并交换
                  if (head.next != null) {
                      if (head.next.val < head.val) {
                          int temp = head.val;
                          head.val = head.next.val;
                          head.next.val = temp;
                      }
                      return head;
                  }
         

   2. ​if (head == null || head.next == null) return head;

      1. 这个就能够充当终止条件了！！！

‍

解决掉原有的问题后，自己的代码就直接能够跑起来了！！！

‍ ↩

使用快慢指针（双指针）

• 第一个指针先走，第二个指针后行。

• 第一个指针走 k-1 步，然后第一个、第二个指针一起走。

• 当第一个指针走到结尾时，第二个指针恰好就到了倒数 第 k 号位置！！！

解释

第二个指针慢走了 k-1 步，就等同于在最后减去了 k-1 步，所以第二个指针最后只能走到倒数第 k 号位置上。 ↩ ↩

21. 合并两个有序链表

尝试

class Solution {
    public ListNode mergeTwoLists(ListNode list1, ListNode list2) {
        if (list1 == null || list2 == null) {
            if (list1 == null) return list2;
            if (list2 == null) return list1;
        }

        ListNode dummyHead = new ListNode(0), cur = dummyHead;
        ListNode c1 = list1, c2 = list2;
        while (c1 != null && c2 != null) {
            if (c1.val <= c2.val) {
                cur.next = c1;
                c1 = c1.next;
            } else {
                cur.next = c2;
                c2 = c2.next;
            }
            cur = cur.next;
        }

        while (c1 != null) {
            cur.next = c1;
            c1 = c1.next;
            cur = cur.next;
        }
        while (c2 != null) {
            cur.next = c2;
            c2 = c2.next;
            cur = cur.next;
        }

        return dummyHead.next;
    }
}

• AC
• 希望美团二面考这道题目

‍ ↩