Kafka源码·二 - Log
上一节学习了一下 LogSegment 的相关知识，今天来看看 kafka 中 Log 对象的具体构造。不过在此之前，需要先了解一下面几个知识： 一、高水位 High Watermark1. 高水位的含义在 kafka 中，HW (High watermark 高水位)的作用主要有两个： 定义消息可见性，它被用来标识分区下哪些消息是可以被消费者消费的 帮助完成副本同步 在分区高水位以下的消息被认为是已提交消息，反之就是未提交消息。而消费者只能消费已提交消息，或者说消费者只能消费高水位以下的消息，即上图中 offset 小于 8 的消息，而当前高水位是 8，就表示 8 和 8+ 的数据是不能被消费的。 需要注意的是，这是在不考虑事务的情况下的简单模型，因为事务会影响消费者所能看见的消息范围，而日志对事务型消费者的可见性，由 LSO（Log Stable Offset）的值来决定，这个不是我们今天讨论的主题，先略过不谈。 在上面的图中，还有一个 LEO（Log End Offset），它表示分区中下一条待写入消息的位移值。所以我们可以得到结论：介于高水位和 LEO 之间的消息属...
从一战到俄乌战争
俄乌冲突已经有一段时间了，有一天，女朋友突然问我知道啥情况不，由于我的世界史完全是两眼一抹黑，完全没什么概念，也就没有说出个所以然来。 最近不太忙，依靠维基百科、知乎、ChatGPT 和通义千问，学习了一下从一战开始到现在俄乌冲突的当下，这一百多年的时间里波澜壮阔的历史变迁。这篇笔记的主要思路，来自知乎上的几篇万赞长文，我在月度文章的过程中，查阅资料，逐渐丰富了自己对这期间历史进程的认知。 那么要谈俄乌冲突为什么要从一战那么远开始呢？事实上，俄乌冲突的实质，还是地缘纷争的具象化，而要在科技、经济飞速发展的全球化时代讲地缘纷争，至少要从一战讲起，才能更深刻的理解各国之间的国仇族恨亦或是蝇营狗苟。串完这个主线，接下来再去看美洲、亚洲、中东等地的发展变迁时，心中的概念就更加立体了。 普法战争1870 年至 1914 年间发生的第二次工业革命，给西欧（包括英国、德意志帝国、法兰西第三共和国、低地国家和丹麦等）、美国及大日本帝国带来了巨大的发展动力。自此，人类开始了对电力以及石油能源的大规模利用，内燃发动机、新材料与物质（包括合金和化学品），以及如电报和无线电等通信技术的迅速发展，不仅大大...
跨域与预检
以前对“跨域”的含义只知道个大概，即浏览器出于安全考虑，不允许域名是 a 的网页，访问域名 b 的资源。 今天在 v2ex 上看了一篇关于跨域的帖子，对跨域和预检（preflight）有了更进一步的了解，打算自己做一个实验，来验证并加深自己的理解。 跨域首先要澄清的是：跨域只会出现在浏览器环境中！，纯服务端之间不存在这个问题。 所谓的跨域，就是：网页地址的域名是 A ，但是接口请求的地址是 B 。这就是跨域，跨越了不同的域(名)想要去请求资源。它的严格定义和介绍可以看这里。 事实上，协议、域名、端口三者有任意一个不同，就算“跨域”了，例如： http://mofish.zone:3000 和 http://mofish.zone:9527 是跨域 http://x 和 https://x 是跨域 发生跨域问题的时候，我们一般会在控制台看到下面的错误： 12Access to fetch at 'http://backend.com/test/cors/ping' from origin 'http://frontend.com' has...
学习笔记：LLM 时代，知识库是如何“工作”的？——从 RAG 到语义空间的底层逻辑
引言：重谈“知识库”在很长一段时间里，企业里的“知识库”是什么样的？ 大多数人都不陌生：一堆文档、Wiki、FAQ，外加一个搜索框。 你输入关键词，系统帮你在标题、正文里做字符串匹配，然后返回一串结果。 这种方式能用，但问题也很明显： 用户需要思考该用什么关键词去搜 同一个意思，换个说法，可能就搜不到了 文档写得再好，也经常躺在硬盘的角落里吃灰 后来，搜索引擎变聪明了一点，引入了排序、权重、召回策略等，但核心逻辑一直没变： “你给我词，我帮你找“包含这些词”的文章。” 直到大语言模型（LLM）出现，事情开始变得不一样了。我们第一次看到一种系统，可以： 用自然语言提问 得到结构清晰、看起来“理解了问题”的回答 于是我们自然会想一个问题： 既然模型这么聪明了，是不是可以让它“读完”公司的所有资料，然后直接回答问题？ 但现实很快泼了一盆冷水，训练好的模型并不知道我们的私有数据，即使我们“喂”过私有数据，它也可能记不准、答不全、甚至编造。 况且模型本身也并不适合频繁更新知识。 一、RAG于是，大家有了一个新的思路： 不是让模型去“记住”所有知识，而是在回答问题前，先...
Kafka源码·一 - LogSegment 与 Index
新年新气象，从今天起开始来看 Kafka 的源码。 首先简单描述一下 Kafka 的整体架构： 发布消息的客户端程序称为生产者（Producer），Producer 通常持续不断地向一个或多个 Topic 发送消息，而订阅这些 Topic 的客户端称为消费者（Consumer）。 Kafka 的服务端由多个 Broker 服务进程组成，Broker 负责接收和处理客户端发送过来的请求，以及对消息进行持久化。虽然多个 Broker 进程能够运行在同一台机器上，但更常见的做法是将不同的 Broker 分散运行在不同的机器上。 为了提供可拓展性，Kafka 使用分区机制，把数据分割成多份保存在不同的 Broker 上。Kafka 将每个主题划分成多个分区（Partition），每个 Partition 是一组有序的消息日志。生产者生产的每条消息只会被发送到一个 Partition 中，也就是说如果向一个双分区的主题发送一条消息，这条消息要么在分区 0 中，要么在分区 1 中。 同时，每个分区下可以配置若干个副本（Replica），其中只能有 1 个领导者副本（Leader replic...
Docker In Docker 探索
背景2024年过年前最后一个版本，接到了一个奇怪的任务，大致要求是这样的：k8s 给用户创建一个 pod，用户在容器中可以使用 docker 相关的功能，并且 inner docker 和外部 k8s是隔离的，有点类似于公有云的虚拟机的效果。 其实，最初的需求是这样的，甲方有一批机器和显卡，想把这些资源给自家员工使用，当做 playground，跑跑算法、训练训练模型之类的。其实这个需求并不复杂，按照公有云厂商的设计照着抄就可以了(提供公有镜像，用户可以上传自己的私有镜像)，但是最终产品同学定了 docker in docker 的方案：不为用户管理私有镜像，只提供一个公共的基础镜像，并预装好 docker，让用户在里面自己捯饬。虽然我们几个执行的人都 get 不到这样到底有多大用，但是上面拍板了，也只能先这么定了。 调研一、DinD网上稍微一搜，就可以找到 DinD(Docker in Docker) 这个方案，但是很遗憾，github 的页面上提示： This repository has been archived by the owner on May 24, 2019...
Redis 高可用主线 - 分片集群
一、分片集群分片集群（切片集群），就是指启动多个 Redis 实例组成一个集群，然后按照一定的规则，把收到的数据划分成多份，每一份用一个实例来保存。 在面向百万、千万级别的用户规模时，横向扩展的 Redis 分片集群会是一个非常好的选择。但是同时，又引申出来两个问题： 数据分片后，在多个实例之间如何分布？ 客户端怎么确定想要访问的数据在哪个实例上？ 从 3.0 开始，官方提供了一个名为 Redis Cluster 的方案，用于实现分片集群。Redis Cluster 方案中就规定了数据和实例的对应规则。 具体来说，Redis Cluster 方案采用哈希槽（Hash Slot，接下来我会直接称之为 Slot），来处理数据和实例之间的映射关系。在 Redis Cluster 方案中，一个分片集群共有 16384 个哈希槽(2^14)，这些哈希槽类似于数据分区，每个键值对都会根据它的 key，被映射到一个哈希槽中。 具体的映射过程分为两大步：首先根据键值对的 key，按照 CRC16 算法计算一个 16 bit 的值；然后，再用这个 16bit 值对 16384 取模，得到 0~...
赏花
[{"url":"https://img.mofish.zone/wp-content/uploads/2024/03/20240305215101798.jpg","alt":"","title":""},{"url":"https://img.mofish.zone/wp-content/uploads/2024/03/20240305215111435.jpg","alt":"","title":""},{"url":"https://img.mofish.zone/wp-content/uploads/2024/03/20240305215057493.jpg","alt":"","title":""},{"url":"https://img.mofish.zone/wp-content/uploads/2024/03/20240305215114668.jpg","alt":"","title":""},{"url":"https://img.mofish.zone/wp-content/uploads/2024/03/20240305215106226.jp...
记一次云服务器被攻击事件
一、告警下午快下班的时候，突然收到一条腾讯云的告警短信 什么 phpivpVCE、phpGFJopg 一看就不是正经文件。 二、应急处理既然机器被入侵了，第一反应就是关机，于是果断登录控制台，关机。 接下来就要考虑如何处理了，为了防止对方继续操作机器，首先关闭所有网络策略，即调整安全组，把所有的端口全部屏蔽掉。 然后，通过控制台 VNC 登录服务器，结果尴尬的是居然把密码忘了，于是重置密码，再尝试重新登录。 折腾了半天，终于登上去了，到目录下面看了看，却没有找到告警短信中提示到的文件，查看了控制台的消息中心： 卧槽，给我惊到了，腾讯云居然直接给它们干掉了。 然后看看监控： 应该是那个时间点 cpu 突然飙升（估计是想挖矿吧），触发了腾讯云的监测机制，扫描到文件之后，将它们杀掉了。 这就说明了，腾讯云上确实是没有隐私的；腾讯云的霸王条款里，一定有一条类似 “如果你的机器可能对平台造成影响，腾讯云有权对它进行处理” 既然文件被清除了，而且从监控来看，后续所有指标全部恢复了，密码也重置了，并且我机器里就跑了个博客，也没啥重要的东西，索性就不管了，放他跑一晚上，第二天再看看情况...
Redis 高可靠主线 - 哨兵机制
上一篇文章，我们了解了主从库集群模式。在这个模式下，如果从库发生故障了，可以通过 psync/sync 重新进行同步。那么如果主库发生了故障，我们该怎么办呢？ 这时候我们就需要一个新主库，比方说把一个从库切换为主库。这就涉及到三个问题： 主库真的挂了吗？ 该选择哪个从库作为主库？ 怎么把新主库的相关信息通知给从库和客户端呢？ 为了解决这些问题，redis 引入了哨兵机制。在 Redis 主从集群中，哨兵机制是实现主从库自动切换的关键机制，它有效地解决了上面三个问题。 一、哨兵模式哨兵其实就是一个运行在特殊模式下的 Redis 进程，主从库实例运行的同时，它也在运行。哨兵主要负责的就是三个任务：监控、选主和通知 1. 监控监控是指哨兵进程在运行时，周期性地给所有的主从库发送 PING 命令，检测它们是否仍然在线运行。如果实例没有在规定时间内响应哨兵的 PING 命令，哨兵就会把它标记为“下线状态”；如果它是主库的话，哨兵就会判定主库下线，然后开始自动切换主库的流程。 1. 主观下线”和“客观下线”哨兵进程会使用 PING 命令检测它自己和主、从库的网络连接情况，用来判...