IoTDB - RegionGroup均衡算法

背景 在不同的共识协议中,Leader 角色要比 Follower 角色承担更多的工作,包括 •CPU:Leader 要对操作进行编号,并且进行转发控制。 •网络IO:Leader 要将操作转发给剩余 R-1 个副本,输入是 1,输出是 R-1。 均衡各 DataNode 的 Leader 数量,能够均衡...

阅读更多

可塑的骸骨

拯救过去的论调在今天看来无疑充满了荒诞色彩,人们也很轻易给这种穿越时空的辩证法打上“不可能”的标签。 往昔已逝,人们对过往的懊悔常深陷“要是当初…就好了”的执念,面对主体面对其符号性失败最直白的哀悼, 世俗的智慧总以“过去无法改变”来劝人“向前看”,这宛如一道温和的赦令,将人从对实在界创伤的无望凝视中拉开。 ...

阅读更多

KV Router Performance Tuning

概述 (Overview) Dynamo 的 KV 路由器 (KV Router) 监听来自工作节点的 KV 事件,以构建一个全局的 KV 缓存前缀树 (global prefix tree of KV caches)。这使得路由器能够预测每个工作节点对传入请求的 KV 命中率(重叠分数,overlap sco...

阅读更多

大数据流上的Heavy Hitters

看了一些Flink RocksDB状态后端热key探测的研究,其中不可避免地要解决Heavy Hitters问题,简单记录。 Heavy Hitters(频繁项)以及它衍生出来的Top-K(前K最高频项)是大数据和流式计算领域非常经典的问题,并且在海量数据+内存有限+在线计算的前提下,传统的HashMap + ...

阅读更多

机密计算

kata这样的所谓的安全容器,密码也一览无余 # pid=$(ps -ef | grep qemu | grep -v grep | sort -k4,4r | head -n 1 | awk '{print $2}') # ./peekPID.sh $pid [New LWP 1361141] [New L...

阅读更多

记一次gc超时排查过程

背景 最近发现监控偶尔集中出现接口异常、超时等报警,查询日志发现是调用接口超时,由于每次出现的报警时间都不一致,并且也很快恢复,以为是偶发的大批量任务导致的,因此没有进行集中排查。直到发现基本每天都开始出现,并且也逐渐影响到其他业务线获取数据,开始仔细观察排查原因。 排查到具体现象如下,每次出现超时,GC监控...

阅读更多

Flink反压的一些总结项

反压机制: 1:数据接受速率 大于 数据输出速率,压力往上游一步步传导,直到source 2:压力传递的细节: 1 输出缓冲区:resultpartition -> local bufferpool -> network bufferpool 2 输入缓冲区:inputgate...

阅读更多

记录一个监控Flink热点key的可行解法

背景抽象: 在物流系统中,上游业务系统向消息队列发送的运单和包裹数据可能存在: 短时间内(1秒或几秒)产生万级重复数据,维度关联导致笛卡尔积倍增,形成”大包裹数据” 导致下游Flink作业消费时出现数据倾斜,卡CP、OOM等问题。 需要在各作业中监控热点key以实现预警功能。 卡点: 通常会将每条数据...

阅读更多