开发技术分享

〇、【引子】由于老婆经常拿着手机问我，“这件衣服好看吗” “这件衣服我能穿吗”…… 所以我萌生出了写一个 AI 换衣工具的想法。 虽然豆包已经有这个功能了，但是操作起来比较麻烦，每次还得输入提示词。为了最大程度减少老婆大人操作的复杂度，我决定还是自己写一个，让她可以： 上传自己的照片 上传衣服/模特图片 点击按钮生成图片 一、【开发】借助 ChatGPT 和千问，差不多半天就写完了所有的代码（主要是调样式耗费时间）。图像大模型用的是：字节 Seedream4.5 本地运行的界面如下： 为了方便用户测试，我在界面上放了几张预置图片，先把图片上传到腾讯云对象存储，然后把链接塞到 html 里。 踩坑：图片跨域本地运行，点击示例图片，点击生成，卧槽，明明已经选择了图片，怎么还提示让我“上传两张图片”？ 打开 console 一看，从 url 下载图片的时候跨域了…… 原因是点击示例图片的时候，会下载图片并转换成 blob 以备后续请求，这一步被拦住了，图片并没有被加载到 post body 里，所以点击 “生成” 的时候，会提示 “请上传两张图片” 不对啊，既然...

25 年上半年一直忙忙碌碌，筹备婚礼和新房相关的事情，直到 8 月份的时候才开始着手规划婚假。 作为一个打工人，除了婚假之外，再难有如此之长的假期可以挥霍了，所以我初步想法是去一个比较远的地方，比如欧洲、澳洲，而像日本、韩国、东南亚这些处于家门口的异国，就留给以后相对较短的假期。 实话说，我自身略微倾向于澳洲，北半球的秋，正对应着南半球的春，气候宜人、风景优美，看一看南半球完全不同的星空也是一件令人激动的事。 在和老婆商量之后，我们最终将目标定在了欧洲，13 天跨越意瑞法三国的行程。 也罢，自然风光哪里都有，但欧洲大陆的人文景观，却独此一份。 出发本次行程算上导游，总共有 18 人，算是一个好消息，小团意味不管干什么事情相对效率都能高一些。 因为旅行团是从北京出发，所以我们提前一天，从西安乘联运班机到达北京，晚上住在了首都国际机场附近的酒店里（顺义区）。 落地北京，正值下班时间，从机场到酒店短短十公里的路，车满为患，司机师傅载着我们在路上缓慢的蠕动，折腾了将近一个小时才到。一路上看着窗外破烂低矮的建筑，我从未想过，首都北京居然还有这样的一面，看起来就和十八线小县城差不多，只有拥挤...

一、从 LeaderAndIsr 请求谈起这个请求的作用是：通知集群中的节点，某个 Broker 成为某个分区的 Leader 或 Follower，以及 该分区最新的的副本状态信息。 1. 发送时机controller 通常会在以下场景发送 LeaderAndIsrRequest： 分区 Leader 选举或切换时：比如原 leader 宕机，controller 会从 ISR（In-Sync Replica）中选出新的 leader，并通知相关副本（所在的 broker） 新 Topic 创建后：controller 会为各个分区选择 leader，并将该信息下发到分区副本所在的 broker Replica 状态变化时：例如重新加入 ISR 分区重新分配（Reassignment）时 2. 请求参数LeaderAndIsrRequest 中携带的重要参数有： 字段名 用途 controllerId 当前 controller id controllerEpoch 用于保证请求的时效性 brokerEpoch 接收方 broker 的 epoch，同样...

延时请求（Delayed Operation），是指某些条件未满足，导致暂时无法处理的请求。例如，对于设置了 acks=all 的 Produce Request，Kafka 必须确保 ISR 中的所有副本都要成功响应这次写入（或者最终没有等到所有的 ISR，最后超时的时候），之后才会返回。 为了执行这些延时请求，Kafka 使用了基于多层时间轮的方案。 一、单层时间轮我们先来看一看单层时间轮（Simple Timing Wheel）： 参考上面这张图，就跟钟表类似，我们把圆上一格当做一个最小时间单位（tickMs），假设这里我们取 1 ms，这个圆总共 8 等分（8 个 bucket），那么不考虑复用的情况，整个单层时间轮就可以覆盖 8 ms 的时间段。 我们给圆上的圆弧编个号，上面的数字 0~7，表示 bucket-0 ~ bucket-7，假设现在时间是 1741773800002，我需要在 1741773800004 的时候执行三个延时任务，那么就向 bucket-7 的链表中增加三个任务即可，等待时间到达 1741773800004 的时候，就捞出链表里的延...

上一篇文章我们学习了三部分内容： controller 与 broker 的通信机制 controller 内部的事件处理机制 controller 的选举过程 这一节，我们以删除 topic 作为切入点，来学习一下 kafka 中的 Partition State Machine 和 Replica State Machine 一、删除 topic1、kafka-topics.sh 脚本kafka 安装目录下会给我们提供一些脚本来管理 kafka，其中就有 topic 的管理工具 kafka-topics.sh，我们可以用下面的命令来删除 topic 1kafka-topics.sh --bootstrap-server <kafka-server>:<port> --delete --topic <topic-name> 如果我们打开 kafka-topics.sh 脚本，会发现里面只有一行内容： 1exec $(dirname $0)/kafka-run-class.sh kafka.admin.TopicCommand "...

中东问题的本质是宗教、民族、资源、政治权力交织在一起的复杂问题。 要想搞明白中东问题，必须要先了解这片土地上信仰的变迁。 我们熟知的基督教、伊斯兰教、犹太教等，被学者称作亚伯拉罕诸教，它们虽然共享一些历史背景、人物和教义，但各自有独立的发展过程。 这所有的一切，都始于先知亚伯拉罕。 一、信仰的开端公元前约 2000 年，亚伯拉罕听从上帝的召唤，离开美索不达米亚平原的乌尔（现在的伊拉克南部）前往上帝应许之地——迦南（今以色列地区）。 上帝与亚伯拉罕立约：承诺赐给他的后代一片土地，并使他们成为大族 亚伯拉罕有两个儿子，一个是以撒（Isaac），一个是以实玛利（Ishmael） 犹太教认为：以撒是神的选民，后来产生了以色列民族。 伊斯兰教认为：以实玛利是穆罕默德的祖先，阿拉伯民族由其而出。 所以，从“宗教谱系”上看，犹太人和阿拉伯人被视为同源的“兄弟民族”，分别从以撒与以实玛利传出。 以撒的儿子叫雅各，后来改名为“以色列”（意为“与神摔跤的人”），他就是以色列人的祖先。 《创世纪》中记载，在雅各与神摔跤之后，被赐名以色列 二、犹太教的变迁1. 埃及的奴役与出埃及雅...

[{"url":"https://img.mofish.zone/wp-content/uploads/2025/04/20250422145410515.jpg","alt":"垂吊矮牵牛-柠檬黄","title":""},{"url":"https://img.mofish.zone/wp-content/uploads/2025/04/20250422145358310.jpg","alt":"酢浆草-胭脂月","title":""},{"url":"https://img.mofish.zone/wp-content/uploads/2025/04/20250422150517251.jpg","alt":"酢浆草-狐仙、酢浆草-岩浆","title":""},{"url":"https://img.mofish.zone/wp-content/uploads/2025/04/20250422145405598.jpg","alt":"垂吊矮牵牛-玫红星斑","title":""},{"url":"https://img.mofish.zone/wp-conte...

Controller 是 Kafka 最核心的组件之一。一方面，它要为集群中的所有主题分区选举领导者副本；另一方面，它还承载着集群的全部元数据信息，并负责将这些元数据信息同步到其他 Broker 上 一、Controller 与 Broker 通信Controller Request在 Kafka 工程目录中，我们可以找到 AbstractControlRequest 类，这是 controller request 的基础类，在 2.7.2 版本中，有三个具体的实现类，也就是说，目前 Controller 在于 brokers 交互的时候，只有这三类场景： UpdateMetadataRequest: 用于更新 broker 上的 Controller 元数据 LeaderAndIsrRequest：用于更新 broker 上，leader 副本信息，以及 in-sync 副本信息 StopReplicaRequest：用于告知 broker 停止某个副本对象，删除日志数据。主要的使用场景，是分区副本迁移和删除主题 下面是 AbstractControlRequest 类的代...

文章开头依然放上 Kafka 的网络通信架构图。 第三节中阅读了 SocketServer 部分的源码，知道了请求时如何接收并返回的。这一节我们一起阅读一下 KafkaRequestHandler 的源码，看看 IO 线程是如何工作的。 IO线程池：KafkaRequestHandlerPoolKafkaRequestHandler 是 IO 线程，那么自然而然的，就应该有一个线程池去调度它，这就是 KafkaRequestHandlerPool。 我们可以在 KafkaServer 的 startup 方法中，可以看到创建这个线程池的代码： 12345678910111213141516171819// KafkaApis 是 kafka 真正处理请求逻辑的地方dataPlaneRequestProcessor = new KafkaApis(socketServer.dataPlaneRequestChannel, replicaManager, adminManager, groupCoordinator, transactionCoordinator, kafkaCo...

在研究学习 Kafka 的各个网络组件之前，我们先从整体上看一下完整的网络通信层架构： 由上图可以看出，Kafka 网络通信组件主要由两大部分构成：SocketServer 和 KafkaRequestHandlerPool。 KafkaRequestHandlerPool 组件就是我们常说的 I/O 线程池，里面定义了若干个 I/O 线程，用于执行真实的请求处理逻辑。 SocketServer 组件是网络通信的核心，主要实现了 Reactor 模式，用于接收外部客户端（Producer、Consumer 或其他 Broker）的请求，并将请求分发给下游 I/O 线程，然后再将下游的 Response 返还给 Clients。 两者的交互点在于 SocketServer 中定义的 RequestChannel，他们通过 RequestChannel 中的 request queue 和 response queue 交换数据。大体流程是这样的： Process 线程会将客户端请求封装成 Request，放到 RequestChannel 对象的 ...