浪浪山下那个村 👋🏼

数据倾斜原理 数据倾斜就是数据的分布严重不均，流入部分算子的数据明显多余其他算子，造成这部分算子压力过大。 影响 单点问题 数据集中在某些分区上（Subtask），导致数据严重不平衡。 GC 频繁 过多的数据集中在某些 JVM（TaskManager），使得JVM 的内存资源短缺，导致频繁 GC。 吞吐下降、延迟增大 数据单点和频繁 GC 导致吞吐下降、延迟增大。 系统崩溃 严重情况下，过长的 GC 导致 TaskManager 失联，系统崩溃。 Flink数据倾斜问题定位 定位反压 定位反压有2种方式：Flink Web UI 自带的反压监控（直接方式）、Flink Task Metrics（间接方式）。通过监控反压的信息 ，可以获取到数据处理瓶颈的 Subtask。 确定数据倾斜 Flink Web UI 自带Subtask 接收和发送的数据量。当 Subtasks 之间处理的数据量有较大的差距，则该 Subtask 出现数据倾斜。 Flink 如何处理常见数据倾斜 数据源 source 消费不均匀 解决思路：通过调整并发度，解决数据源消费不均匀或者数据源反压的情况。 例如kaf....

简介 反压（backpressure）是实时计算应用开发中，特别是流式计算中，十分常见的问题。反压意味着数据管道中某个节点成为 瓶颈，处理速率跟不上上游发送数据的速率，而需要对上游进行限速。由于实时计算应用通常使用消息队列来进行生产端和 消费端的解耦，消费端数据源是 pull-based 的，所以反压通常是从某个节点传导至数据源并降低数据源（比如 Kafka consumer）的摄入速率。 简单来说，Flink 拓扑中每个节点（Task）间的数据都以阻塞队列的方式传输，下游来不及消费导致队列被占满后，上游的 生产也会被阻塞，最终导致数据源的摄入被阻塞。 TCP-based 反压的弊端 单个Task导致的反压，会阻断整个TM-TM之间的socket，连checkpoint barries也无法发出。 反压传播路径长，导致生效时延较大。 Credit-based 反压 反压过程简介 如图所示在 Flink 层面实现反压机制，就是每一次 ResultSubPartition 向 InputChannel 发送消息的时候都会发送一个 backlog size 告诉下游准备发送多少消息，下....

RocksDB 介绍 RocksDB 是嵌入式的 Key-Value 数据库，在 Flink 中被用作 RocksDBStateBackend 的底层存储。如下图所示，RocksDB 持久化的 SST文件在本地文件系统上通过多个层级进行组织，不同层级之间会通过异步Compaction 合并重复、过期和已删除的数据。在 RocksDB 的写入过程中，数据经过序列化后写入到WriteBuffer，WriteBuffer 写满后转换为 Immutable Memtable 结构，再通过 RocksDB 的flush 线程从内存 flush 到磁盘上；读取过程中，会先尝试从 WriteBuffer 和 Immutable Memtable 中读取数据，如果没有找到，则会查询 Block Cache，如果内存中都没有的话，则会按层级查找底层的 SST 文件，并将返回的结果所在的 Data Block 加载到 BlockCache，返回给上层应用。 RocksDBKeyedStateBackend增量快照介绍 这里介绍一下大家在大状态场景下经常需要调优的 RocksDBKeyedStateBac....

1. 内存设置 1.1 TaskManager 内存模型 TaskManager的内存模型如下图所示(1.10之后版本内存模型)： Flink使用了堆上内存和堆外内存。 Flink 框架内存使用了堆外内存和堆外内存，不计入slot资源。 Task执行的内存使用了堆上内存和堆外内存。 网络缓冲内存：网络数据交换所使用的内存大小，如网络数据交换缓冲区。 框架堆外内存、Task堆外内存、网络缓冲内存都在堆外的直接内存里面。 管理内存：Flink堆外内存的管理，用于管理排序，hash表，缓冲中间结果以及RocksDb 状态后端的本地内存。 JVM特有内存：JVM本身占用的内存，包括元数据和执行开销。 Flink 使用内存 = 框架堆内和堆外内存 + Task堆内和堆外内存 + 网络缓冲内存 + 管理内存。 进程内存 - Flink 内存 + JVM特有内存 1.1.1 JVM特有内存详解 JVM特定内存： JVM本身使用的内存，包含JVM的metaspace和over-head JVM的metaspace：JVM 元空间。taskmanager.memory.jvm-meta-sp....

跳跃表将有序链表中的部分节点分层，每一层都是一个有序链表。在查找时优先从最高层开始向后查找，当到达某节点时，如果next节点值大于要查找的值或next指针指向NULL，则从当前节点下降一层继续向后查找，这样可以有效提升效率。如下图所示使用跳表查找51的路径为1->21->41->51需要查找4次。如果使用链表查找路径为1->11->21->31->41->51需要查找6次，效率明显提升了，当数据量较大是提升更为明显。

压缩列表ziplist本质上就是一个字节数组，是Redis为了节约内存而设计的一种线性数据结构，可以包含多个元素，每个元素可以是一个字节数组或一个整数。 Redis的有序集合、散列和列表都直接或者间接使用了压缩列表。当有序集合或散列表的元素个数比较少，且元素都是短字符串时，Redis便使用压缩列表作为其底层数据存储结构。列表使用快速链表（quicklist）数据结构存储，而快速链表就是双向链表与压缩列表的组合。 ziplist 压缩列表是一个特殊编码的双端链表（内存上连续），为了尽可能节省内存而设计的。ziplist 可以存储字符串或者整数值，其中整数被编码保存为实际的整数，而不是字符数组。ziplist 支持 O(1) 的时间复杂度在列表的两端进行 push 和 pop 操作。然而因为这些操作都需要对整个 ziplist 进行内存重分配（因为是一块连续的内存），所以操作的实际复杂度和 ziplist 占用的内存大小有关。在 7.0 版本里，ziplist 已经全面被 listpack 替换了（主要是因为连锁更新较影响性能）

检查操作系统配置 redis-server --check-system 结果如下，说明检查通过： [slow-clocksource]...OK [xen-clocksource]...OK [overcommit]...OK [THP]...OK 检查server内存 redis-server --test-memory 1024 --- 长期跟新

在编译源码https://github.com/RedisLabs/memtier_benchmark 的时候执行下面命令： autoreconf -ivf ./configure make sudo make install 报错如下： error: required file './ltmain.sh' not found

redis 命令exists vs get，在判断key是否存在的场景下： exists速度更快，可以忽略类型。 get只适用于string类型，当值越大时，速度越慢。

redis一款高并发的内存K-V数据库，提供了好多命令，但是其中有部分对于生产环境来说比较危险，需要禁用掉。高危命令有：keys、flushdb、flushall、config、debug、eval、script、evalsha、shutdown