通道服务是基于表格存储数据接口之上的全增量一体化服务,用户可以简单地实现对表中历史存量和新增数据的消费处理,Tunnel Client 为通道服务的自动化数据消费框架。

Tunnel Client 的设计哲学是通过每一轮的定时心跳探测(Heartbeat)来获取以下内容:
  • 活跃 Channel 的探测
  • Channel 和 ChannelConnect 状态的更新
  • 数据处理任务的初始化、运行和结束等

TunnelWorkerConfig 为用户提供 Tunnel Client 的自定义配置,配置包括:

  • Heartbeat 的间隔和超时时间。
  • 记录消费位点的时间间隔。
  • 客户端的自定义标识。
  • 数据处理的自定义 Callback。
  • 数据读取和数据处理的线程池资源配置。

配置详解

  • Heartbeat 相关
    • HeartbeatTimeoutInSec:Heartbeat 的超时时间间隔,默认为300秒。当Heartbeat发生超时,Tunnel 服务端会认为当前 TunnelClient 不可用(失活),客户端需要重新进行 ConnectTunnel。
    • HeartbeatIntervalInSec:进行 Heartbeat 检测的时间间隔,默认为30秒。当Heartbeat 用于活跃 Channel 的探测时,该参数最小支持自定义到5秒,该配置会影响 Channel 状态的更新时间间隔或(自动化)数据拉取任务的初始化时间等。
  • Checkpoint 时间间隔

    CheckpointIntervalInMillis:用户消费完数据后,向 Tunnel 服务端进行记录消费位点操作(Checkpoint)的时间间隔,单位为 ms,默认为5000ms。

    说明
    • 因为读取任务所在机器不同,进程可能会遇到各种类型的错误。例如因为环境因素重启,需要定期对处理完的数据做记录(checkpoint)。当任务重启后,会接着上次的 checkpoint 继续往后做。在极端情况下,Tunnel Service 不保证传给您的记录只有一次,只会保证数据至少传一次,且记录的顺序不变。如果出现局部数据重复发送的情况,需要您注意业务的处理逻辑。
    • 如果您希望减少在出错情况下数据的重复处理,可以增加做 checkpoint 的频率。但是过于频繁的 checkpoint 会降低系统的吞吐量,请根据自身业务特点决定 checkpoint 的操作频率。
  • 客户端的自定义标识 ClientTag:客户端的自定义标识,用于生成Tunnel Client ID,用户可以自定义此参数来区分 Tunnel Client。
  • 数据处理的自定义 Callback

    ChannelProcessor:用户注册的处理数据的 Callback,包括 process 和 shutdown 方法。

  • 数据读取和数据处理的线程池资源配置
    • ReadRecordsExecutor:用于数据读取的线程池资源,如无特殊需求,建议使用默认的配置。
    • ProcessRecordsExecutor:用于处理数据的线程池资源,如无特殊需求,建议使用默认的配置。
    说明
    • 自定义上述线程池时,线程池中的线程数要和 Tunnel 中的 Channel 数尽可能一致,这样可以保障每个 Channel 都能很快的分配到计算资源(CPU)。
    • 在默认线程池配置中,为保障吞吐量,我们进行了如下操作:
      • 默认预先分配32个核心线程,以保障数据较小时(Channel数较少时)的实时吞吐。
      • 工作队列的大小适当调小,这样在用户数据量比较大(Channel数较多)时,可以更快的触发线程池新建线程的策略,及时的弹起更多的计算资源。
      • 设置了默认的线程保活时间(默认60s),当数据量降下后,可以及时回收线程资源。