关于后端:得物热点探测技术架构设计与实践

说到热点问题，首先咱们先了解一下什么是热点？

热点通常意义来说，是指在一段时间内，被宽泛关注的物品或事件，例如微博热搜，热卖商品，热点新闻，明星直播等等，所以热点产生次要蕴含 2 个条件：1. 无限工夫，2 流量高聚。

而在互联网畛域，热点又次要分为 2 大类：

1. 有预期的热点：比方在电商流动当中推出的爆款联名限量款的商品，又或者是秒杀的会场流动等

2. 无预期的热点：比方受到了黑客的歹意攻打，网络爬虫频繁拜访，又或者突发新闻带来的流量冲击等

针对于有预期的热点能够通过热点数据预热，流量限度和异步队列进行解决。然而对于突发性无感知的热点数据流量，往往因为申请过于集中，导致拜访数据流量超出的 server 的失常负载水位，从而呈现服务过载不可用的状况，这种问题被称之为热点问题。

看完对于热点问题的简略介绍，咱们曾经了解了热点产生的条件是短时间内被频繁拜访导致流量高聚，而流量高聚就会呈现一系列的热点问题。那被频繁拜访的 Key，就是咱们通常所说的热 Key。

接下来咱们来看一下哪些场景会导致热点问题以及对应的热 Key：

MySQL 中被频繁拜访的数据，如热门商品的主键 Id
Redis 缓存中被密集拜访的 Key，如热门商品的详情须要 get goods$Id
歹意攻打或机器人爬虫的申请信息，如特定标识的 userId、机器 IP
频繁被拜访的接口地址，如获取用户信息接口 /userInfo/ + userId

理解完什么是热点问题和热 Key 呈现的场景当前，咱们会提出一个疑难，如何去提前感知这些热点数据？这里就须要聊到热点探测技术。

解决热点问题通常会应用分布式缓存，然而在读取时还是须要进行网络通讯，就会有额定的工夫开销。那如果能对热点数据提前进行本地缓存，即本地预热，就能大幅晋升机器读取数据的性能，加重上层缓存集群的压力。

留神，本地缓存与实时数据存在不统一的危险。须要依据具体业务场景进行评估，缓存级数越多，数据不统一的危险就越大！

3.1.2 躲避危险

对于无预期的热数据（即突发场景下造成的热 Key），可能会对业务零碎带来极大的危险，可将危险分为两个档次：
对数据层的危险

失常状况下，Redis 缓存单机就可反对十万左右 QPS，并能通过集群部署进步整体负载能力。对于并发量个别的零碎，用 Redis 做缓存就足够了。然而对于刹时过高并发的申请，因为 Redis 单线程起因会导致失常申请排队，或者因为热点集中导致分片集群压力过载而瘫痪，从而击穿到 DB 引起服务器雪崩。

对应用服务的危险

每个利用在单位工夫所能承受和解决的申请量是无限的，如果受到歹意申请的攻打，让歹意用户单独占用了大量申请解决资源，就会导致其他人畜有害的失常用户的申请无奈及时响应。

因而，须要一套动静热 Key 检测机制，通过对须要检测的热 Key 规定进行配置，实时监听统计热 Key 数据，当无预期的热点数据呈现时，第一工夫发现他，并针对这些数据进行非凡解决。如本地缓存、回绝歹意用户、接口限流 / 降级等。

首先咱们要定义一下如何能力算是一个热点，咱们晓得热点产生的条件是 2 个：一个工夫，一个流量。那么依据这个条件咱们能够简略定义一个规定：比方 1 秒内拜访 1000 次的数据算是热数据，当然这个数据须要依据具体的业务场景和过往数据进行具体评估。

对于单机利用，检测热数据很简略，间接在本地为每个 Key 创立一个滑动窗口计数器，统计单位工夫内的拜访总数（频率），并通过一个汇合寄存检测到的热 Key。

而对于分布式应用，对热 Key 的拜访是扩散在不同的机器上的，无奈在本地独立地进行计算，因而，须要一个独立的、集中的 热 Key 计算单元。

咱们能够简略了解为：分布式应用节点感知热点规定配置，将热点数据进行上报，工作节点进行热点数据统计，对于合乎阈值的热点进行推送给客户端，利用收到热点信息进行本地缓存等策略这五个步骤：

1. 热点规定：配置热 Key 的上报规定，圈出须要重点监测的 Key

2. 热点上报：应用服务将本人的热 Key 拜访状况上报给集中计算单元

3. 热点统计：收集各利用实例上报的信息，应用滑动窗口算法计算 Key 的热度

4. 热点推送：当 Key 的热度达到设定值时，推送热 Key 信息至所有利用实例

5. 热点缓存：各利用实例收到热 Key 信息后，对 Key 值进行本地缓存（此步骤依据具体业务策略调整）

了解完热点探测原理当前，咱们来聊聊得物的热点探测中间件 Burning。

作为潮流互联网电商平台，得物的电商业务高速倒退，突发性的热点数据一直的冲击着咱们的零碎服务，比方大促秒杀，热点商品，歹意攻打等等。针对于这种突发性的大流量，单纯的机器扩容并不是一个无效的解决伎俩，咱们须要一个集热点探测，热点感知，热点数据推送，热点数据预热，热点监控剖析等性能于一体的热点探测中间件，因而 Burning 应运而生。

Burning 作为得物的热点探测中间件，提供可供业务方接入的 SDK 包和治理台规定配置，用于对热点数据的实时性监控，探测，操作和本地缓存等。次要解决了以下问题：

实时热点感知：能实时监控热点数据，蕴含热 Key，热数据，热接口等，秒级上报集群对立计算
本地数据预热：对于特定场景能够通过动静本地缓存配置，避免流量突增导致 Redis 或 DB 数据流量压力过大导致系统雪崩
周期热点统计：对热点数据进行周期性统计分析，标记出热 Key 规定及散布比例等，能够帮忙业务方进行针对性优化治理和营销策略抉择
系统安全治理：能够通过热点 Key 探测剖析，对于刷子用户，问题 IP，机器人和爬虫进行标识，可实时熔断存在平安危险的申请，进步系统安全和可用性

为满足高并发场景，热点探测中间件 Burning 在设计的时候，重点关注了如下指标：

1. 实时性：热点问题往往具备突发性，客户端必须可能实时发现可疑热 Key 并推送给计算单元进行探测

2. 高性能：热点探测往往须要解决大量的热点探测申请和热点计算，因而热点探测中间件的性能要求较高，能力满足巨量的并发并无效降低成本

3. 准确性：热点探测须要精准的探测合乎规定热 Key，实时监听规定的变动，正确的进行热 Key 上报和热 Key 计算

4. 一致性：热点探测须要保障利用实例的本地缓存热 Key 统一，当热 Key 变更导致 value 生效时，利用须要同时进行生效来保证数据一致性，不能呈现数据谬误

5. 可扩大：热点探测须要统计和计算的 Key 量级很大，而且存在突发流量的状况，对立计算集群须要具备程度扩大的能力

Burning 的架构设计遵循了以上热点探测的技术原理，同时借鉴了 jd-hotKey 的设计思路，次要分为 Burning-Admin、Burning-Worker、Burning-Config、Burning-Client 四个模块：

Burning-Admin（热点探测治理台）：与 Worker 节点 Netty 长链接通信，提供不同维度的利用治理和热点规定配置，提供查问热点数据统计，规定和热点数据监控大盘，提供工作集群信息查问及客户端节点信息查问，提供本地缓存动静配置及热点信息实时告诉
Burning-Worker（热点集中计算单元）：无状态 server 端，与治理台和客户端进行 Netty 长链接通信，获取规定，滑动窗口计算热点，将热点记录推送到治理台展现和客户端解决
Burning-Config（热点配置核心）：作为热点、规定配置核心和注册核心，将规定配置下发到 Worker 节点和客户端，通过 Raft 算法进行零碎高可用一致性保障
Burning-Client（热点客户端 SDK）：与 Worker 节点建设 Netty 长链接通信，监听配置核心配置变动定时推送热 Key 数据，获取热 Key 推送本地内缓存设置，与 Redis-client 无缝集成及其他 ORM 框架无缝集成

热点探测次要蕴含以下几个次要流程：

1. 用户在治理后盾（Burning-Admin）进行热点规定配置并进行热点数据实时监控

2. 治理后盾（Burning-Admin）将规定配置信息上传给配置核心（Burning-Config）

3. 配置核心（Burning-Config）将热点规定下发给客户端（Buring-Client）和工作节点（Burning-Worker）

4. 客户端（Burning-Client）获取到规定，将指定规定的热 Key 定时上报给工作节点（Burning-Worker）

5. 工作节点（Burning-Worker）获取到上报的热 Key 后进行滑动工夫窗口计算，对于满足阈值的热点推送给客户端（Burning-Client）

6. 客户端（Burning-Client）拿到热点数据后，进行对应的本地缓存配置

客户端启动器 ClientStarter，启动配置核心和注册核心，Worker 建连，注册事件监听，设置 app_name、port、caffeine 缓存大小、cache 配置、监控配置等


public synchronized static void startPipeline(BurningCommonProperties burningCommonProperties) {if (STARTED.get() == Boolean.FALSE) {DwLogger.info("start pipeline");
      // 设置参数上下文
      setToContext(burningCommonProperties);
      // 配置核心启动
      EtcdConfigFactory.buildConfigCenter(burningCommonProperties.getConfigServer());
      ConfigStarter starter = EtcdConfigStarter.getInstance();
      starter.start();
      // 注册核心启动
      RegisterFactory.buildRegisterCenter(burningCommonProperties);
      RegisterStarter registerStarter = RegisterStarter.getInstance();
      registerStarter.start();
      // 热点探测启动
      DetectFactory.startDetect(burningCommonProperties.getPushPeriod());
      // 开启 worker 重连器
      WorkerRetryConnector.retryConnectWorkers();
      // 注册事件监听
      registEventBus();
      // 开启监控
      MetricsFactory.startMetrics();
      STARTED.set(Boolean.TRUE);
  }

}

客户端进行热 Key 判断，如果合乎规定就上报给 Worker 节点计算，同时进行统计计数

public static Object dynamicGetValue(String key, KeyType keyType) {
  try {
      // 如果没有为该 key 配置规定，就不必上报 key
      Boolean dynamicRule = dynamicRule(key);
      if (dynamicRule == null) {return null;}
      Object userValue = null;

      ValueModel value = getValueSimple(key);

      if (value == null) {HotKeyPusher.push(key, keyType);
      } else {
          // 邻近过期了，也发
          if (isNearExpire(value)) {HotKeyPusher.push(key, keyType);
          }
          Object object = value.getValue();
          // 如果是默认值，也返回 null
          if (object instanceof Integer && Constant.MAGIC_NUMBER == (int) object) {userValue = null;} else if (Boolean.FALSE.equals(dynamicRule)) {userValue = null;} else {userValue = object;}
      }

      // 统计计数
      MetricsFactory.metrics(new KeyHotModel(key, value != null));

      return userValue;
  } catch (Exception e) {DwLogger.error(DwHotKeyStore.class, "get value error");
      return null;
  }
}

Worker 节点启动 nettyServer，用于各个业务服务实例进行长连贯，接管客户端上报数据

public void startNettyServer(int port) throws Exception {
    //boss 单线程
    EventLoopGroup bossGroup = new NioEventLoopGroup(1);
    //worker 节点组
    EventLoopGroup WorkerGroup = new NioEventLoopGroup(CpuNum.WorkerCount());
    try {ServerBootstrap bootstrap = new ServerBootstrap();
        bootstrap.group(bossGroup, WorkerGroup)
                .channel(NioServerSocketChannel.class)
                .handler(new LoggingHandler(LogLevel.INFO))
                .option(ChannelOption.SO_BACKLOG, 1024)
                // 放弃长连贯
                .childOption(ChannelOption.SO_KEEPALIVE, true)
                // 进去网络 io 事件，如记录日志、对音讯编解码等
                .childHandler(new ChildChannelHandler());
        // 绑定端口，同步期待胜利
        ChannelFuture future = bootstrap.bind(port).sync();
        Runtime.getRuntime().addShutdownHook(new Thread(() -> {bossGroup.shutdownGracefully (1000, 3000, TimeUnit.MILLISECONDS);
            WorkerGroup.shutdownGracefully (1000, 3000, TimeUnit.MILLISECONDS);
        }));
        // 期待服务器监听端口敞开
        future.channel().closeFuture().sync();} catch (Exception e) {DwLogger.error("netty server start error.", e);
    } finally {
        // 优雅退出，开释线程池资源
        bossGroup.shutdownGracefully();
        WorkerGroup.shutdownGracefully();}
}

Worker 节点通过监听客户端上报，异步生产队列 Client 音讯

public void beginConsume() {while (true) {
      try {HotKeyModel model = QUEUE.take();
          if (model.isRemove()) {iKeyListener.removeKey(model, KeyEventOriginal.CLIENT);
          } else {iKeyListener.newKey(model, KeyEventOriginal.CLIENT);
          }
          // 处理完毕，将数量加 1
          totalDealCount.increment();} catch (Exception e) {DwLogger.error("consumer error.", e);
      }
  }
}

如果是新增一个 Key，就生成滑动窗口，基于工夫窗口数据判断是否热 Key

@Override
public void newKey(HotKeyModel hotKeyModel, KeyEventOriginal original) {
  //cache 里的 key
  String key = buildKey(hotKeyModel);
  String name = StringUtils.isBlank(hotKeyModel.getGroup()) ? hotKeyModel.getAppName() : hotKeyModel.getGroup();

  // 判断是不是刚热不久
  Object o = hotCache.getIfPresent(key);
  if (o != null) {return;}
  SlidingWindow slidingWindow = checkWindow(hotKeyModel, key, name);
  // 看看 hot 没
  boolean hot = slidingWindow.addCount(hotKeyModel.getCount());

  if (!hot) {
      // 如果没 hot，从新 put，cache 会主动刷新过期工夫
      CaffeineCacheHolder.getCache(name).put(key, slidingWindow);
  } else {hotCache.put(key, 1);

      // 删掉该 key
      CaffeineCacheHolder.getCache(name).invalidate(key);

      // 开启推送
      hotKeyModel.setCreateTime(SystemClock.now());

      // 当开关关上时，打印日志。大促时敞开日志，就不打印了
      if (ConfigStarter.LOGGER_ON) {DwLogger.info(NEW_KEY_EVENT + hotKeyModel.getKey());
      }

      // 别离推送到各 client 和 etcd
      for (IPusher pusher : iPushers) {pusher.push(hotKeyModel);
      }

  }

}

如果是删除一个 Key，这里删除蕴含客户端发消息删除，本地线程扫描过期 Key 和治理台删除

@Override
public void removeKey(HotKeyModel hotKeyModel, KeyEventOriginal original) {
  //cache 里的 key
  String key = buildKey(hotKeyModel);
  String name = StringUtils.isBlank(hotKeyModel.getGroup()) ? hotKeyModel.getAppName() : hotKeyModel.getGroup();
  hotCache.invalidate(key);
  CaffeineCacheHolder.getCache(name).invalidate(key);

  // 推送所有 client 删除
  hotKeyModel.setCreateTime(SystemClock.now());
  DwLogger.info(DELETE_KEY_EVENT + hotKeyModel.getKey());

  for (IPusher pusher : iPushers) {pusher.remove(hotKeyModel);
  }

}

Worker 计算实现后将后果异步推送给 Client，通过 app 进行分组批量推送

@PostConstruct
public void batchPushToClient() {AsyncPool.asyncDo(() -> {while (true) {
          try {List<HotKeyModel> tempModels = new ArrayList<>();
              // 每 10ms 推送一次
              Queues.drain(hotKeyStoreQueue, tempModels, 10, 10, TimeUnit.MILLISECONDS);
              if (CollectionUtil.isEmpty(tempModels)) {continue;}

              Map<String, List<HotKeyModel>> allAppHotKeyModels = Maps.newHashMap();
              Map<String, List<HotKeyModel>> allGroupHotKeyModels = Maps.newHashMap();

              // 拆分出每个 app 的热 key 汇合，按 app 分堆
              for (HotKeyModel hotKeyModel : tempModels) {if (StringUtils.isNotBlank(hotKeyModel.getGroup())) {List<HotKeyModel> groupModels = allGroupHotKeyModels.computeIfAbsent(hotKeyModel.getGroup(), (key) -> new ArrayList<>());
                      groupModels.add(hotKeyModel);
                  } else {List<HotKeyModel> oneAppModels = allAppHotKeyModels.computeIfAbsent(hotKeyModel.getAppName(), (key) -> new ArrayList<>());
                      oneAppModels.add(hotKeyModel);
                  }
              }

              CustomizedMetricsProcessor processor = CustomizedMetricsProcessor.builder(MetricsConstant.BURNING_NETTY_OUT).build();

              // group hot key push
              pushGroup(processor, allGroupHotKeyModels);

              // app hot key push
              pushApp(processor, allAppHotKeyModels);

          } catch (Exception e) {DwLogger.error("push to client error.", e);
          }
      }
  });
}

Burning 提供了 2 种应用形式，一是通过原生办法调用，二是通过申明式注解 @EnableBurning，以下对应用注解进行热点探测的局部场景提供最佳实际：

1. 进行热点判断，用于热点拦挡和自定义解决实现

@Component
public class Cache {@EnableBurning(prefix = "hot_Key_", cache = false, hitHandler = ExceptionHitHandler.class)
    public String getResult2(String Key) {return "这是一个测试后果" + Key;}
}

2. 命中热点规定解决类，可进行自定义实现 hitHandler 接口（留神 cache=false）

public class ExceptionHitHandler implements HitHandler {
   @Override
   public Object handle(String Key, ProceedingJoinPoint joinPoint) {
       // 此处可自定义实现
      throw new RuntimeException("对不起，您没有权限拜访:" + Key);
   }
}

3. 用于 Redis 缓存热点探测

@Component
public class Cache {

    @Resource
    private RedisTemplate<String, String> RedisTemplate;

    @EnableBurning
    public String getResult(String Key) {return RedisTemplate.opsForValue().get(Key);
    }
}

4. 用于 MySQL 热数据缓存

@Repository
public class SmsSignRepo {

   @Autowired
   private SmsSignMapper smsSignMapper;

   @EnableBurning(prefix = "SMS_SIGN", dynamic = false, KeyType = DATABASE_Key)
   public List<SmsSign> getAll() {Example example = new Example(SmsSign.class);
      Example.Criteria criteria = example.createCriteria();
      criteria.andEqualTo("status", 1);
      return smsSignMapper.selectByExample(example);
   }
}

上游 40 个测试调用实例独特调用的场景下，并发数 800，递进压测

压测后果：1 个 4C8G 工作节点每秒可安稳解决约 15W 个 key 的热点探测，成功率大于 99.999%，worker 节点 CPU 均匀占用为 80%，内存占用 60%

DB 场景压测

Client 配置为 4C8G，120 个并发申请，压测时长 10min

1. 原生未接入 Burning 的 DB 操作接口场景

压测后果：未接入 burning，解决总申请数约 112 万，均匀 TPS 约 1500，均匀 RT 约 63MS。CPU 在压测满载状况下 100%，内存均匀应用 48%

2. 接入 Burning 的 DB 操作接口场景

压测后果：接入 burning 后，解决总申请数 457 万（比照未接入 Burning 减少 345 万 ），均匀 TPS 约 5800（ 比照未接入 Burning 减少 4300），均匀 RT 约 8MS（比照未接入 Burning 降落 55MS）。CPU 在压测满载状况下 100%，内存均匀应用 50%（比照未接入回升 2%，本地缓存耗费）

Redis 场景压测

Client 配置为 4C8G，120 个并发申请，压测时长 10min

1. 原生未接入 Burning 的 Redis 操作接口场景

压测后果：未接入 burning，解决总申请数约 298 万，均匀 TPS 约 3800，均匀 RT 约 14MS。CPU 在压测满载状况下 100%，内存均匀应用 48%

2. 已接入 Burning 的 Redis 操作接口场景

压测后果：已接入 burning，解决总申请数约 443 万（比照未接入减少 145 万），均匀 TPS 约 5700（比照未接入回升 1900），均匀 RT 约 8MS（比照未接入降落 6ms）。CPU 在压测满载状况下 100%，内存均匀应用 48%，根本持平

Burning 工作节点单机每秒解决 15 万个 key 的探测申请，CPU 稳固在 80% 左右，根本无任何异样
客户端利用接入 burning 后，对利用实例自身 CPU 负载根本无影响，内存占用回升次要取决于指定的本地缓存大小，接入后接口性能晋升显著，QPS 显著回升，RT 显著降落

热点问题在互联网场景中每每呈现，特地是电商业务的需要场景，例如对于大促期间或者流动抢购期间的某个爆品，可能会呈现在几秒工夫内流入大量的流量，因为商品数据在 Redis cluster 场景下会依照 hash 规定被寄存在某个 Redis 分片上，那么这个霎时流量也有可能呈现打挂 Redis 分片，导致系统雪崩。所以咱们要长于利用热点探测中间件进行热 Key 探测，通过预置本地缓存解决突发流量导致的零碎瓶颈，也能通过热点数据监控剖析进行针对性的零碎调优。

得物热点探测组件 Burning 上线至今，反对了数十个交易外围链路服务，在满足根底热点探测的前提下，Burning 还反对本地缓存压测标 / 染色标识别能力，客户端本地 Ecache/Caffeine 缓存模式抉择，热点规定 Group 聚合统计等扩大能力。应用服务接入 Burning 后对于热点数据探测及数据获取性能显著进步，通过预热 & 实时本地缓存，极大的升高了上层缓存集群和数据库的负载压力，为业务服务的衰弱运作保驾护航。

文 /Leo

关于后端:得物热点探测技术架构设计与实践

1. 概述

2. 热点场景

3. 热点探测技术原理

3.1 热点探测能够带来什么益处？

3.1.1 晋升性能

3.1.2 躲避危险

3.2 如何进行热点探测？

4.Burning

4.1 价值意义

4.2 要害指标

4.3 架构设计

4.4 链路流程

4.5 外围代码

4.6 最佳实际

4.7 性能体现

4.7.1 Worker 节点性能压测

4.7.2 Client 业务利用性能压测

4.7.3 压测报告

5. 总结

Just My Socks（注册教程内含优惠码）

关于后端:得物热点探测技术架构设计与实践

1. 概述

2. 热点场景

3. 热点探测技术原理

3.1 热点探测能够带来什么益处？

3.1.1 晋升性能

3.1.2 躲避危险

3.2 如何进行热点探测？

4.Burning

4.1 价值意义

4.2 要害指标

4.3 架构设计

4.4 链路流程

4.5 外围代码

4.6 最佳实际

4.7 性能体现

4.7.1 Worker 节点性能压测

4.7.2 Client 业务利用性能压测

4.7.3 压测报告

5. 总结

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）