Welcome to funboost's documentation!

Contents:

• 0. Funboost 快速预览
• 1. Python 分布式函数调度平台 Funboost 简介
  • 1.0 funboost 框架说明介绍
    • 1.0.1 funboost 示意图
      • 1.0.1.1 funboost 运行流程图
      • 1.0.1.2 funboost 功能思维导图
    • 1.0.2 快速了解和上手funboost，直接看1.3例子
    • 1.0.3 funboost 框架安装方式
    • 1.0.4 funboost 功能作用
      • 1.0.4.1 Funboost 的适用场景
      • 1.0.4.2 🤔 灵魂发问：Funboost 到底是什么？
      • 1.0.4.3 💖 核心关切：值得我投入时间学习吗？
      • 1.0.4.4 Funboost 与 Celery 的理念区别
      • 1.0.4.5 Funboost 支持的并发模式
      • 1.0.4.6 Funboost 支持的消息队列中间件 (Broker)
      • 1.0.4.7 funboost 学习难吗?
      • 1.0.4.8 📊 可视化监控与管理
      • 1.0.4.9 🚀 性能表现：断层式领先
      • 1.0.4.10 ⭐ 用户口碑与评价
  • 1.1 📚 核心资源与文档导航
    • 1.1.1 📝 项目文档入口
      • 📖 文档章节速览
    • 1.1.2 📦 源码与依赖
  • 1.2 框架功能介绍
    • 1.2.1 🆚 对比：Funboost 取代传统线程池
      • ❌ 方式 A：手动开启线程池 (传统)
      • ✅ 方式 B：Funboost @boost 模式 (推荐)
      • ✅ 方式 C：FunboostPool 模式
    • 1.2.2 🚀 任务控制功能矩阵
      • 🌌 维度一：连接与架构 (Connectivity & Architecture)
      • ⚡ 维度二：并发与吞吐 (Concurrency & Throughput)
      • 🛡️ 维度三：可靠性保障 (Reliability)
      • 🕹️ 维度四：流量治理 (Traffic Governance)
      • 🎼 维度五：调度与编排 (Scheduling & Orchestration)
      • 🔭 维度六：可观测性 (Observability)
      • 🧬 维度七：开发体验 (Developer Experience)
  • 1.3 🚀 快速上手：你的第一个 Funboost 程序
    • 1.3.1 ✨ Hello World：最简单的任务调度
    • 1.3.2 🔥 进阶实战：RPC、定时任务与丝滑连招
    • 1.3.3 ✂️ 极简写法：省略 @boost
    • 1.3.4 ❌ 过时写法： 直接在 @boost传各种配置入参，不推荐
  • 🖥️ funweb (Funboost Web Manager) 界面预览
  • 1.4 💡 为什么 Python 极其需要分布式函数计算？
    • 1️⃣ 痛点一：GIL 锁的限制 (多核利用率低)
    • 2️⃣ 痛点二：原生性能瓶颈 (动态语言特性)
  • 1.5 🎓 最佳学习路径
  • 1.6 🥋 funboost 练就吸星大法神功，一招吸走 Celery 毕生内力
    • ⚔️ 降维打击：化繁为简的绝世武功
• 2. 对比celery框架
  • 2.0 funboost 是不是抄袭celery的源码?
  • 2.1 celery对目录层级文件名称格式要求很高
  • 2.2 性能远远超过celery20倍以上（使用初中的严格控制变量法）
  • 2.3 celery的重要方法全部无法ide自动补全提示
  • 2.4 比celery强的方面的优势大全
    • 2.4.1 funboost对win linux mac 都支持
    • 2.4.2 funboost万物皆可为broker，支持消息队列种类远超celery
    • 2.4.3 funboost性能远超celery几十倍，性能不在一个数量级。
    • 2.4.4 使用funboost框架时候，代码在ide自动补全暴击使用celery。
    • 2.4.5 funboost 无需使用难记复杂的命令行启动消费。
    • 2.4.6 框架不依赖任何固定的目录结构，无结构100%自由。
    • 2.4.7 funboost框架比celery更简单10倍
    • 2.4.8 funboost的消息格式比celery更容易自己构造
    • 2.4.9 celery目录结构限制严格，不规范目录结果层级使用难度高。
    • 2.4.10 funboost学习难度远低于celery
    • 2.4.11 funboost原生支持 asyncio ，支持async def 函数
    • 2.4.12 funboost比celery对函数的辅助运行控制方式更多
    • 2.4.13 funboost能分布式qps全局控频，celery不能
    • 2.4.14 funboost自带内置一键启动多进程，celery无法。
    • 2.4.15 funboost 限速控频精准度远高于celery
    • 2.4.16 funboost日志的颜色和格式，远超celery。
    • 2.4.17 funboost内置支持python代码级别的一键远程linux机器消费部署
    • 2.4.18 funboost 直接支持类/实例方法作为消费函数，celery只支持静态方法/函数
    • 2.4.19 funboost支持多进程叠加 多线程或者协程，是叠加的。 celery只能gevent/threading和多进程二选一。
    • 2.4.20 funboost 队列路由配置直观度和简易度暴击celery，celery的队列路由配置是劝退新手的第一步。
    • 2.4.21 funboost的配置方式吊打celery
    • 2.4.22 funboost 能非常容易的扩展用户自己的任何中间件作为broker，celery无法做到。
    • 2.4.23 funboost 强大的的fct上下文，完胜celery 装饰器的bind=True侵入式设计
    • 2.4.24 funboost全流程支持asyncio生态，celery望尘莫及
    • 2.4.25 funboost作者的自定义线程池能自动伸缩，完胜。
    • 2.4.26 funboost死信队列机制更完善：
    • 2.4.27 funboost可以消费一切任意json消息(无论json包含什么keys)，celery无法识别
    • 2.4.28 更强力灵活的,funboost 可以消费一切任意不规范格式的消息(非json也能消费), celery完全不可行.
    • 2.4.29 funboost等待任务完成机制：提供了 wait_for_possible_has_finish_all_tasks() 方法
    • 2.4.30 funboost无需 框架专用插件
    • 2.4.31 funboost的定时任务比celery更强，能动态添加删除 和 多点部署。
    • 2.4.32 funboost + REDIS_ACK_ABLE ack能力 吊打celery + redis + ack + visibility_timeout (小细节)
    • 2.4.33 funboost: 通过继承 BoosterParams 实现显式配置（清晰度爆表）
    • 2.4.34 funboost可以是事件驱动平台,远超celery传统消息队列能力
    • 2.4.35 funboost可以作为万能发布者对几十种消息队列发布原始消息内容,celery会对消息转换添油加醋
    • 2.4.36 funboost 自带 faas 功能，一键实现函数动态发现和 Faas
    • 2.4.37 funboost的用户自定义扩展比celery更容易,更彻底
    • 2.4.38 funboost支持微批消费
    • 2.4.40 （王炸）funboost 支持celery作为broker_kind
  • 2.4b 讨Celery檄：Funboost十胜定乾坤，函数王朝开天命
    • 十胜十败·定鼎九州
    • 弑王绝刃·乾坤倒转：
  • 2.5 funboost能支持celery整体框架作为broker_kind
  • 2.6 funboost 和 celery 性能比较源码（控制变量法）
    • 2.6.1 funboost vs celery 控制变量法说明
    • 2.6.2 funboost vs celery 发布性能对比
    • 2.6.3 funboost vs celery 消费性能对比
    • 2.6.4 funboost vs celery 总体性能对比
    • 2.6.7 funboost VScelery benchmark对比源代码直接贴出来
      • 2.6.7.1 celery的跑分源码
      • 2.6.7.2 funboost的跑分源码
    • 2.6.8 驳斥小白说 celery 在单核机器(或单进程)每分钟可以执行100万个消息
      • 什么情况下celery单核机器上能达到每分钟执行100万个消息?
    • 2.6.9 【！更新】2026-01最新funboost极限性能优化，发布和消费性能提升120%
  • 2.7 rq celery funboost 段位比较
    • 2.7.1倔强青铜：RQ (Redis Queue)
    • 2.7.2荣耀黄金：Celery
    • 2.7.3 传奇王者：Funboost
  • 2.8 celery 和 funboost 分别将加减乘除作为消费函数完整例子，哪个框架更好用，你自己判断！
    • 2.8.1 funboost 来实现加减乘除
      • 2.8.1.1 Funboost 项目演示（简洁配置）
      • 2.8.1.2 funboost代码文件内容
        • 2.8.1.2.1 funboost文件：math_operations/add_function.py
        • 2.8.1.2.2 funboost文件：math_operations/subtract_function.py
        • 2.8.1.2.3 funboost文件：math_operations/multiply_function.py
        • 2.8.1.2.4 funboost文件：math_operations/divide_function.py
        • 2.8.1.2.5 funboost文件：main.py
        • 2.8.1.3 Funboost 运行说明
    • 2.8.2 Celery 项目演示（复杂配置）
      • 2.8.2.1 celery项目文件树
      • 2.8.2.2 Celery代码文件内容
        • 2.8.2.2.1 文件：celery_config/celery_config.py - Celery复杂配置示例
        • 2.8.2.2.2 文件：celery_config/celery_app.py - Celery应用实例配置
        • 2.8.2.2.3 文件：math_operations/add_function.py
        • 2.8.2.2.4 文件：math_operations/subtract_function.py
        • 2.8.2.2.5 文件：math_operations/multiply_function.py
        • 2.8.2.2.6 文件：math_operations/divide_function.py
        • 2.8.2.2.7 文件：main.py - 发布任务
        • 2.8.2.2.8 文件：start_worker.py - 启动Worker的复杂命令
      • 2.8.2.3 Celery 运行说明
    • 2.8.3 对比总结：哪个框架更容易使用？
      • 2.8.3.1 Celery 配置复杂性突出体现：
      • 2.8.3.2 Funboost 简洁性体现：
      • 2.8.3.3 结论
      • 2.8.3.4 说明，celery有稍微简单不爱出错的方式
  • 2.9 funboost到底为什么性能比celery高几十倍？太离谱了,太假了是吗？
  • 2.20 funboost 比 celery 的战略优势和 战术优势
    • 2.20.1 一、 战略优势 (Strategic Advantages)
      • 2.20.1.1 架构定位：FaaS 微服务平台 vs 传统任务队列
      • 2.20.1.2 设计哲学：自由赋能 vs 框架奴役
      • 2.20.1.3 兼容性格局：万物皆 Broker vs 依赖 Kombu
      • 2.20.1.4 技术栈前瞻性：原生 Asyncio vs 伪异步
    • 2.20.2 二、 战术优势 (Tactical Advantages)
      • 2.20.2.1 性能表现：多维叠加并发 vs 单一模式
      • 2.20.2.2 控频能力：精准令牌桶 vs 模糊限制
      • 2.20.2.3 可靠性：心跳 ACK vs 超时重发
      • 2.20.2.4 开发体验：IDE 友好 vs 字符串魔法
      • 2.20.2.5 运维能力：内置可视化 vs 第三方插件
    • 2.20.3 总结
• 3.框架详细介绍
  • 3.1 各种中间件选择的场景和优势
  • 3.2 框架支持的函数调度并发模式种类详细介绍
  • 3.3 框架最最重要的boost装饰器的BoosterParams参数入参大全
    • 3.3.1 funboost_config.py 配置文件内容
    • 3.3.2 funboost 重要公有方法大全介绍
    • 3.3.3 boost装饰器 的 concurrent_num 和 qps 之间的关系。
  • 3.4 框架的乞丐精简版实现方式
  • 3.5 框架的任务消费确认
  • 3.6 框架的设计规范原则
• 4. 🔑 使用框架的各种代码示例(学习funboost用法最重要的章节)
  • 4.0 框架最重要的@boost装饰器的入参格式说明
    • 4.0.1 老的 @booost 直接传入多个参数方式
    • 4.0.2 新的@ boost 只传入一个 pydantic Model BoostParams 类型或子类 的入参
    • 4.0.3 pydantic model 的 BoosterParams 的入参pycharm下自动补全
    • 4.0.4 关于很多funboost 例子的@boost 使用直接入参,没有使用 pydantic Model类型的BoostParams
    • 4.0.5 自定义子类继承 BoosterParams,使得每次少传参
  • 4.1 装饰器方式调度函数
  • 4.2c 在函数内部无限次按照队列名动态生成booster(消费者、生产者) (非装饰器方式)
  • 4.2d 框架的 BoostersManager boosters管理介绍
    • 4.2d.2 使用 BoostersManager 一次性启动所有队列消费,
    • 4.2d.3 使用 BoostersManager ,通过 consume_group 启动一组消费函数
    • 4.2d.4 使用 BoostersManager ,通过queue_name 得到 booster对象
  • 4.2e funboost 支持实例方法、类方法、静态方法、普通函数 4种类型，作为消费函数的例子
  • 4.3a 演示如何解决多个步骤的消费函数
  • 4.3.b 演示多个函数消费者使用同一个线程池
  • 4.3c 演示清空消息队列和获取消息队列中的消息数量
  • 4.4 演示funboost定时运行例子
    • 4.4.0 funboost定时任务最基本原理说明
    • 4.4.1 funboost定时任务代码演示：
    • 4.4.2 ApsJobAdder对象.aps_obj 核心对象说明
    • 4.4.3 演示在python web中定时任务的添加 （添加和执行定时任务分在不同的py脚本中）
      • 4.4.3.2 web_app.py 是web应用，负责添加定时任务到redis中。此处使用flask框架演示， django fastapi同理，不需要我一一举例子。
      • 4.4.3.3 run_consume.py 是启动消费 和 启动apschduler定时器的脚本
  • 4.4.4 新增的 支持 aps_obj.add_job 添加定时任务(可以不用 add_push_job) (2025-08)
  • 4.5 多进程并发 + 多线程/协程，代码例子。
  • 4.6 演示rpc模式，即客户端调用远程函数并及时得到结果。
    • 4.6.1 rpc 消费端执行两数求
    • 4.6.2 发布端获取求和的结果
    • 4.6.2b 发布端获取求和的结果，在线程池中进一步处理结果
    • 4.6.3 手动设置rpc结果最大等待时间
    • 4.6.4 为什么获取不到执行结果？
    • 4.6.5 asyncio 语法生态下rpc获取执行结果。
    • 4.6.7 从mongo中获取函数执行结果
  • 4.7 演示qps控频
    • 4.7.1 演示qps控频和自适应扩大和减小并发数量。
    • 4.7.2 此框架对固定耗时的任务，持续控频精确度高于99.9%
    • 4.7.3 对函数耗时随机性大的控频功能证明
    • 4.7.4 分布式全局控频和单个消费者控频区别
  • 4.8 再次说明qps能做什么，qps为什么流弊？常规并发方式无法完成的需求是什么？
    • 4.8.1 下面讲讲常规并发手段为什么对8qps控频需求无能为力？
    • 4.8.2 使用分布式函数调度框架，无论接口耗时多少，轻松达到8qps的例子
    • 4.8.3 并发数量和qps(每秒执行多少次)之间的区别
  • 4.9 演示延时运行任务
    • 4.9.2 Funboost 延时消息实现原理与REDIS_ZSET_DELAY专用延时中间件模式介绍
      • 4.9.2.1 🛠️ 默认模式：基于 APScheduler 二次投递
      • 4.9.2.2 🚀 专业模式：基于 REDIS_ZSET_DELAY 原生延时队列
      • 4.9.2.3 💻 专业模式：基于 REDIS_ZSET_DELAY broker 的使用示例
      • 4.9.2.4 📌 选择建议
  • 4.10 在web中如flask fastapi django 如何搭配使用消费框架的例子。
  • 4.11 保存消费状态和结果包mongo，开启消费状态结果的web页面
    • 4.11.1 保存消费状态和结果到mongodb
    • 4.11.2 框架是可以自动保存消费状态/结果到mongo，你想保存到MySQL?
      • 4.11.2.b 作者自己贡献一个吧函数消费状态保存到mysql的函数,(2024.02新增)
    • 4.11.3 可视化，启动python分布式函数调度框架之函数运行结果状态web
  • 4.12 框架 asyncio 方式运行协程
    • 4.12.1 concurrent_mode=ConcurrentModeEnum.ASYNC 运行协程
    • 4.12.2 concurrent_mode=ConcurrentModeEnum.THREADING 运行asyncio协程
  • 4.13 跨项目怎么发布任务或者获取函数执行结果(即不定义@boost消费函数就发送消息)？
    • 1)第一种方式，使用能操作消息中间件的python包，手动发布任务到消息队列中间件
      
    • 2)第二种方式，使用伪函数来作为任务,只写函数声明不写函数体。
      
    • 3)第三种方式(推荐),使用BoostersManager.get_cross_project_publisher来获取发布者,然后使用publish来发布函数的入参字典。
    • 4) 第四种方式,在消费函数所在项目里面用 fastapi flask啥的写一个接口用于接受请求并把接收到的消息发送到消息队列(框架自带了一个fastapi 发布消息接口).
    • 5） ！！！强烈推荐，第五种方式，使用 funboost.faas 一键实现
  • 4.13b 彩蛋!!不使用funboost的消费功能,funboost作为各种消息队列的万能发布者
  • 4.14 获取消费进程信息的方法(用于排查查看正在运行的消费者)
  • 4.16 文件日志所在的地方
    • 4.16.1 没亲自指定 日志文件名
    • 4.16.2 亲自指定日志文件名,log_filename的值
    • 4.16.3 把用户自己的业务日志和funboost框架日志写到同一个文件
  • 4.16.4 funboost 日志由 nb_log 提供。
  • 4.17 判断函数运行完所有任务，再执行后续操作
  • 4.18 暂停消费
  • 4.19 用户自定义记录函数消费 状态/结果 钩子函数
    • 4.19.b 自定义保存函数消费状态结果到mysql/sqlite/pgsql请看4.11.2.b的章节
  • 4.20 通过 broker_exclusive_config 参数 设置不同中间件能使用到的差异化独特配置
    • 4.20.2 怎么知道每种消息队列 broker_exclusive_config 能支持哪些独有特殊的参数配置
  • 4.21 【funboost完全自由定制扩展（方式1）】 使用 register_custom_broker 完全彻底自由灵活自定义扩展和定制修改中间件(消费者和发布者)
  • 4.21b 【完全自由定制扩展(方式2)】,使用 consumer_override_cls 和 publisher_override_cls 来自定义消费者 发布者。
    • 4.21b.1 重写某些方法的例子
    • 4.21b.2 完全实现新增中间件类型.
    • 4.21b.3 funboost的用户自定义扩展比celery更容易,更彻底
  • 4.21c 不想吃苦？让ai来帮你扩展funboost中间件或者定制运行逻辑
    • 4.21c.2 假设你要使用python内置的list作为 funboost的消息队列：
      • 4.21c.2.2 说个ai使用技巧秘密，网页版ai大模型生成funboost代码 吊打编程 ide中的 ai大模型和claude code
  • 4.23 演示funboost框架是如何代替用户手写调用线程池的
  • 4.24 设置消费函数重试次数
    • 4.24.1 抛出ExceptionForRequeue类型错误，消息立即重回消息队列
    • 4.24.2 抛出 ExceptionForPushToDlxqueue 类型错误，消息发送到单独另外的死信队列中
    • 4.24.3 设置is_push_to_dlx_queue_when_retry_max_times,重试到max_retry_times最大次数没成功发送到死信队列
    • 4.24.4 (内置辅助)将一个消息队列中的消息转移到另一个队列
    • 4.24.5 funboost 高级重试：指数退避重试
      • 4.24.5.1 advanced_retry_config 参数详解
      • 4.24.5.2 示例：配置一个典型的指数退避
  • 4.25 push 和 publish 发布消息的区别
    • 核心区别对比
    • 代码演示与说明
  • 4.26 性能调优演示
    • 4.26.1 在一个进程中启动多个函数的消费，适合轻型任务
    • 4.26.2 在多个进程中启动函数的消费，适合一次启动大量函数的消费或重型任务
  • 4.28 funboost 支持celery框架整体作为funboost的broker (2023.4新增)
  • 4.29 funboost支持任务优先级队列
    • 4.29.1 队列支持优先级的说明：
    • 4.29.2 优先级通俗理解，用食堂打饭比喻：
    • 4.29.3 队列支持任务优先级的代码主要有三点：
    • 4.29.4 队列支持任务优先级的代码如下：
    • 4.29.5 消息队列优先级是针对一个queue内消息的，那么怎样才能实现不同函数之间的按优先级运行？
  • 4.30 funboost 远程杀死(取消)任务
    • 4.30.1 funboost远程杀死函数的代码例子
    • 4.30.2 远程强制杀死函数、超时自动杀死(function_timeout设置不为0)， 这两个功能要注意死锁：
    • 4.30.2.b 如果想启用funboost函数超时自动杀死功能或者 远程杀死函数功能，推荐消费函数中使用可过期锁 expire_lock
  • 4.31 神级别 fct (funboost_current_task) 上下文获取当前消息和任务状态
  • 4.32 重磅更新！！！ funboost 独家新增支持实例方法和类方法作为消费函数
    • 4.32.0 !!! 实例方法和类方法作为funboost任务时候，push方法需要特别注意第一个入参。
    • 4.32.1 funboost 支持实例方法和类方法作为消费函数的原理
    • 4.32.2 funboost 支持实例方法、类方法、静态方法、普通函数 4种类型，作为消费函数的例子
  • 4.33 @boost设置is_auto_start_consuming_message，自动启动消费。
  • 4.34 pyinstaller 打包 funboost项目为exe 的说明
  • 4.35 演示 funboost 的函数入参过滤功能
    • 4.35.2 警告！！！: funboost的 rpc功能和 函数入参过滤过滤 不要同时使用
  • 4.35c 使用 nb_cache 作为缓存装饰器
    • 4.35c.1 为什么 要用 nb_cache 而不是 funboost 自带的 do_task_filtering
    • 4.35c.2 nb_cache 功能比 funboost自带的 do_task_filtering 全面太多了
      • 4.35c.2.2 举个例子 nb_cache 的防止缓存击穿为什么吊打 funboost的 do_task_filtering
    • 4.35c.2 如何在 funboost 中使用 nb_cache
      • 4.35c.2.1 方式一，@boost 和 @cache 叠加使用
      • 4.35c.2.2 方式二 cache 装饰器传给 funboost 的 consuming_function_decorator
  • 4.36 演示funboost入参可以是自定义类型(不可json序列化的类型的入参,自动使用pickle)(2025-07新增支持)
  • 4.37 funboost 启动消费函数的方式大全(再次集中总结)
    • 4.37.1. 基础启动 (最常用)
    • 4.37.2. 多进程叠加并发启动 (高性能推荐)
    • 4.37.3. 自动启动 (懒人模式)
    • 4.37.4. 批量启动所有消费者(最粗暴无脑)
    • 4.37.5. 分组启动 (Group Start)
    • 4.37.6. 命令行启动 (CLI)
    • 4.37.7. 远程自动部署启动 (Fabric)
    • 4.37.8. Celery 模式启动 (特殊)
  • 4.38 MemoryFunboostPool 和 FunboostPool 的使用
    • 4.38.1 MemoryFunboostPool：内存增强型任务池
    • 4.38.2 FunboostPool：全能与分布式任务池
    • 4.38.3 选择指南
  • 4.100 使用funboost时候对框架的疑问和猜测，使用控制变量法
    • 4.100.b 举个例子，验证测试框架的超时杀死 function_timeout参数的作用
  • 4.200 [分布式函数调度框架qq群]
• 4b.使用框架的各种代码示例(高级进阶)
  • 4b.1 日志模板中自动显示task_id
    • 4b.1.1 日志模板中显示task_id
    • 4b.1.2 用户在消费函数中想自动显示task_id,方便搜索task_id的关键字来排查某条消息的所有日志.
    • 4b.1.3 一键全局使用 TaskIdLogger 代替 logging.Logger 的方式
    • 4b.1.4 能在消费函数的整个链路里面的调用的任意函数获取task_id的原理
  • 4b.2 支持消费函数定义入参 **kwargs ,用于消费包含随机不确定keys(或者keys太多了)的json消息
    • 4b.2.0 funboost函数执行一条消息的最根本原理是 fun(**消息字典)
    • 4b.2.1 演示错误的消费已存在json消息的例子,企图使用 def task_fun(message) 的函数签名来消费
    • 4b.2.3 方式一: 使用 **kwargs 方式 消费随机keys (或者json的一级keys太多不想逐个定义消费函数入参的情况)
    • 4b.2.4 方式二: 使用 下面的 4b.2c 中章节的 强力灵活的 _user_convert_msg_before_run 方式,来消费随机keys或者keys太多的json
  • 4b.2c 更强力灵活的,funboost支持消费地球上一切任意格式的不规范消息(非json格式也能消费)
    • 4b.2c.1 例如funboost消费消息队列中已存在的消息 'a=1,b=2' 这种.
    • 4b.2c.2 例如,funboost消费队列中已存在的 "1000123"(假设是纯粹的用户id) 这种非json消息
  • 4b.3 funboost + 全asyncio 编程生态演示
    • 4b.3.1 funboost 天然支持 async def 的消费函数,和支持 aio_push 来异步发布消息.
    • 4b.3.2 演示fastapi 中aio_push来发布消息,和 AioAsyncResult asyncio方式 等待获取结果.
    • 4b.3.3 关于funboost的asyncio生态支持实现原理的答疑
    • 4b.3.4 劝退不懂asyncio的loop是什么的小白，使用funboost + asyncio 来编程
      • 4b.3.4.2 想在funboost中玩的溜asyncio实际比例如fastapi这种框架中使用asyncio 更难。
    • 4b.3.5 演示funboost解决 ,async并发模式,由于跨线程loop 操作任何socket连接池 的报错,
  • 4b.4 等待n个任务完成后，再做下一步操作(其实就是canvas任务编排)
  • 4b.5 funboost 原生任务编排(实现canvas功能)
  • 4b.6 @boost装饰器 user_options 入参的妙用
    • 4b.6.1场景一： user_options “反向实现” consume_group**
    • 场景二： user_options 多租户与覆盖全局配置（以Kafka集群做例子）
  • 4b.7 opentelemetry 全链路任务追踪，funboost生产级别的重要战略级功能 (高级功能)
    • 4b.7.1 安装 jaeger ,可视化展示 opentelemetry 的全链路追踪
    • 4b.7.2 opentelemetry 全链路任务追踪 和计入 logger日志 + task_id 的排查区别
      • 4b.7.2.1. 传统的 Logger + task_id：一维线性的“流水账”
      • 4b.7.2.2. OpenTelemetry (OTel)：二维/三维的“树状结构”
    • 4b.7.3 从opentelemetry功能集成， 侧面证明 funboost 对普通用户扩展性吊打celery10倍。
      • 4b.7.3.1 你如果在celery就没那么简单能自定义实现这个功能了
      • 4b.7.3.2 funboost的扩展比celery更容易更彻底：
      • 4b.7.3.3 celery 的 opentelemetry 代码在此，太难了：
  • 4b.8 funboost 声明式任务编排 workfolw
    • 4b.8.1 🚀 快速开始
    • 4b.8.2 📦 核心概念
    • 4b.8.3 🔧 API 详解
      • 4b.8.3.1 Signature（任务签名）
      • 4b.8.3.2 Chain（链式执行）
      • 4b.8.3.3 Group（并行执行）
      • 4b.8.3.4 Chord（并行+汇总）
    • 4b.8.4 ⚙️ WorkflowBoosterParams
    • 4b.8.5 🆚 与 Celery Canvas 对比
    • 4b.8.6 🆚 与 Funboost 命令式编排对比
      • 4b.8.6.1 同一个视频处理流程的两种写法
      • 4b.8.6.2 对比总结
    • 4b.8.7 📁 文件结构
    • 4b.8.8 📖 完整示例
  • 4b.9 funboost 支持 prometheus 指标监控 （高级功能）
    • 4b.9.0 Funboost Prometheus 监控指标 Mixin
    • 4b.9.1 用法1：HTTP Server 模式（单进程）
    • 4b.9.2 用法2：Push Gateway 模式（多进程推荐）
    • 4b.9.3 指标说明
  • 4b.10 funboost支持微批消费
    • 4b.10.1 funboost 微批消费用法
    • 4b.10.2 如果每次临时手写微批操作，会怎么样？
  • 4b.12 funboost的周期额度功能
    • 4b.12.2 周期额度用法例子
  • 4b.13 使用内存队列 broker_kind=BrokerEnum.MEMORY_QUEUE 时候，用 get_future 获取消费函数的运行结果
  • 4b.14 funboost 支持自动熔断，智能自动熔断、半开、恢复 （高级功能）
    • 4b.14.0 funboost 支持自动熔断管理和手动熔断管理
      • 4b.14.0.1 手动熔断管理
      • 4b.14.0.2 自动熔断管理
    • 4b.14.1 funboost 自动熔断，CircuitBreakerConsumerMixin
      • 4b.14.1.1 三态状态机
      • 4b.14.1.2 两种触发策略
      • 4b.14.1.3 两种计数后端
      • 4b.14.1.4 两种熔断行为
      • 4b.14.1.5 user_options的 circuit_breaker_options 参数说明
      • 4b.14.1.6 钩子方法（子类重写）,用于你发送告警到 微信/钉钉/飞书/邮件等等
      • 4b.14.1.7 用法示例
  • 4b.15 funboost 配置失败告警的多种方式
• 6.常见问题回答
  • 6.0 最最最重要的第一个问题: "funboost这个框架怎么样呀，值得我学习使用吗？"
  • 6.0b 有人问 funboost 是做什么的? 怎么回答最合适?
    • 6.0b.1. Funboost 可以做什么？—— Python 函数的“微服务化”与“超音速”引擎
    • 6.0b.2. 一句话说清楚 (电梯演讲版)
    • 6.0b.3. 解决你的核心痛点 (痛点解决版)
    • 6.0b.4. 你可以用 Funboost 来构建什么？ (场景举例版)
    • 6.0b.5. 为什么 Funboost 如此强大？—— 架构理念的降维打击
  • 6.0c funboost教程这么长,funboost学习和使用难吗?
  • 6.0d Funboost 可以用于哪些场景？（7大核心领域）
    • 1. 传统的异步后台任务（Asynchronous Tasks）
    • 2. FaaS 微服务与 RPC 调用（Function as a Service）
    • 3. 高性能分布式爬虫（Distributed Crawling）
    • 4. 轻量级 ETL 与 数据同步（Data Pipeline & CDC）
    • 5. 定时任务与调度平台（Scheduling）
    • 6. 物联网与实时通信（IoT & Real-time）
    • 7. 运维自动化与远程执行（DevOps）
  • 6.0e Funboost 能同时替代哪些框架？（“杀手”清单）
    • 1. 替代 【任务队列框架】
    • 2. 替代 【爬虫框架】
    • 3. 替代 【微服务/RPC 框架】
    • 4. 替代 【定时任务框架/工具】
    • 5. 替代 【数据同步/CDC 工具】
    • 6. 替代 【Web 框架的插件】
    • 🏆 终极总结
  • 6.0f 为什么可以将 funboost 看作为一个超级装饰器来使用？ (如果你不使用分布式和消息队列，funboost 也是大有可为）
    • 6.0f.0 为什么选择 funboost 作为装饰器？
    • 6.0f.1. 最简模式：只用并发和控频
    • 6.0f.2. 加上高级自动重试功能
    • 6.0f.3. 任务去重，避免重复执行
    • 6.0f.4. 获取函数执行结果（非分布式场景）
    • 6.0f.5. 异步函数使用 asyncio 并发
    • 6.0f.6. 函数超时控制
    • 6.0f.7. 消息过期，丢弃旧消息
    • 6.0f.8. 只在特定时间运行（cron表达式）
    • 6.0f.9. 自动启动消费
    • 6.0f.11. 总结
  • 6.1 你干嘛要写这个框架？和celery 、rq有什么区别？
  • 6.2 为什么包的名字这么长?
  • 6.4 框架如何实现定时？
  • 6.5 为什么强调是函数调度框架不是类调度框架，不是方法调度框架？(说明：2024.06月以后新增支持了实例方法和类方法作为消费函数)
  • 6.6 是怎么调度一个函数的。
  • 6.7 框架适用哪些场景？
  • 6.8 怎么引入使用这个框架？门槛高不高？
  • 6.9 怎么写框架？
  • 6.10 框架能做什么
  • 6.11 日志的颜色不好看或者觉得太绚丽刺瞎眼，想要调整。
  • 6.12 是不是抄袭模仿 celery
    • 6.12.2 生产者-broker-消费者 不是 celery 的专利
    • 6.12.3 gemini-2.5pro ai大模型来分析, funboost 是不是抄袭粘贴了 celery 源码
      • 理由一：核心架构与设计哲学的根本不同
      • 理由二：并发模型的实现方式截然不同
      • 理由三：可靠性机制的实现细节差异巨大
      • 理由四：“抄袭”的技术难度与反证
      • 结论
    • 6.12.4 仅用几个celery文件证明抄袭celery有多困难
      • 6.12.4.1 kombu的redis transport源码文件
      • 6.12.4.2 celery的consumer源码文件
  • 6.13 使用此框架时候，在一个python项目中如何连接多个相同种类的消息队列中间件ip地址
  • 6.14 什么是确认消费？为什么框架总是强调确认消费？
  • 6.15 如何等待队列中的消息全部消费完成
  • 6.16 框架支不支持函数上加两个装饰器？
    • 6.16.1 方式一：使用consuming_function_decorator 传参装饰器，
    • 6.16.2 方式二：装饰器直接加到消费函数上，设置should_check_publish_func_params=False
  • 6.17 嫌框架日志记录太详细？
    • 6.17.a 设置发布者消费者的日志级别,控制是否显示发布了什么消息和消费了什么消息.
    • 6.17b 嫌funboost启动时候打印太多提示用户的消息?
  • 6.18 为什么框架在cmd shell终端运行时候要求会话中设置环境变量 export PYTHONPATH=你的项目根目录？
    • 6.18.2 为什么celery scrapy django不需要用户设置pythonpath？
    • 6.18.3 怎么指定配置文件读取 funboost_config.py 和nb_log_config.py的文件夹位置
    • 6.18.4 怎么根据不同环境使用不同的funboost_config配置文件？
    • 6.18.5 多个ptyhon项目怎么使用同一个funboost_config.py 作为配置文件
  • 6.19 定时任务或延时任务报错 RuntimeError: cannot schedule new futures after interpreter shutdown
  • 6.21 支不支持redis cluster集群模式的redis作为消息队列？
  • 6.22 怎么使用tcp socket 作为消息队列
  • 6.23 安装包时候自动安装的三方依赖包太多？
    • 6.23.b 作者为什么不开发pip 选装方式?例如实现选装 pip install funboost[rabbitmq]
  • 6.24 funboost框架从消息队列获取多少条消息？有没有负载均衡？
  • 6.25 funboost消费启动后，按ctrl + c 无法结束代码？
  • 6.25b ctrl_c_recv 到底要不要加？—— 直接看效果
    • 6.25b.0 ctrl_c_rev的源码很简单，很容易看懂。
    • 6.25b.1 ✅ 情况A：代码末尾加了 ctrl_c_recv()
    • 6.25b.2 ❌ 情况B：代码末尾没有加 ctrl_c_recv()
    • 6.25b.3 效果对比表（一目了然）
    • 6.25b.4 最终结论
  • 6.25b.5 顺便说一下，文档中其他地方提到的 ctrl_c_recv 和 apscheduler 的定时器之间的关系
    • 6.25b.5.1 APScheduler 的两种原生定时器
    • 6.25b.5.2 早期版本（2025年之前）的问题
    • 6.25b.5.3 2025年之后的改进
    • 6.25b.5.4 三种定时器的行为对比
    • 6.25b.5.5 总结
  • 6.26 ASYNC 并发模式,异步函数操作数据库/aiohttp连接池报错 attached to a different loop(是用户不看文档和boost的入参说明造成)
    • 6.26.1 演示aiohttp连接池,解决报错 RuntimeError: context manager should be used inside a task
    • 6.26.2 演示 aiomysql 连接池在funboost使用,解决 attached to a different loop
    • 6.26.3 演示子线程怎么正确的使用aiomysql连接池的本质(和funboost无关但原理相通)
  • 6.28 日志提示 是掉线或关闭消费者的 和 重新放入掉线消费者未消费确认的任务 ,是正常的提示.
  • 6.29 funboost 推荐用户使用什么并发模式？
    • 6.29.1 默认推荐：当前进程内 + 多线程模式 (最省心、最稳定、最好用)
    • 6.29.2 高性能推荐：多进程叠加并发模式 (性能炸裂)
      • 6.29.2.2 ⚠️ 极度重要：多进程在 Linux 上建议显式设置 spawn 模式，抛弃默认的 fork 模式
    • 6.29.3 极客推荐：纯 Asyncio 协程模式 (高手的玩具)
    • 6.29.4 特殊场景：单线程串行模式 (Single Thread)
    • 6.29.5 至于 gevent 和 eventlet 并发模式，直接忽略就好
  • 6.30 funboost 如何实配置触发失败告警和恢复告警
    • 6.30.1 使用内置告警 Mixin（AlertNotifier）
      • 6.30.1 AlertNotifierConsumerMixin 发送警告到 微信 钉钉 飞书
      • 6.30.1 AlertNotifierConsumerMixin 发送警告到任意渠道
    • 6.30.2 通过熔断器钩子自定义告警
    • 6.30.3 基于 Prometheus 指标 + Grafana 告警
    • 6.30.4 使用funboost的 MongoAlertMonitor 实现错误告警
      • 6.30.4.1 MongoAlertMonitor 使用例子，发到内置实现的 企业微信 钉钉 飞书
      • 6.30.4.2 MongoAlertMonitor 使用例子，发到自定义的渠道
    • 6.30.5 elk + grafana 实现错误告警
    • 6.30.6 错误触发警告的方式选择
  • 6.31 怎么知道 Funboost 发布者生成的最终消息内容格式是什么样？
    • 6.31.1 方式一：直接查看 Broker
    • 6.31.2 方式二：预览消息（不真正发送）
• 7.更新记录
  • 7.0 很小的更新，对api使用完全无变化或者无增加新功能的不写更新记录。
  • 7.1 新增第十种Consumer，以redis为中间件，但增加了消费确认，是RedisConsumerAckAble类。
  • 7.2 新增基于以redis为消息中间件时候的页面管理和消费速度显示。
  • 7.3 新增一个10行代码的函数的最精简乞丐版实现的分布式函数执行框架.
  • 7.4 新增sqlachemy 支持的数据库作为消息中间件
  • 7.5 日志改为导入独立包nb_log，支持用户配置文件自定义日志配置。
  • 7.6 优化qps控频。
  • 7.7 增加rocketmq支持。 (2020-7)
  • 7.8 新增 async 并发模式 (2020-12)
    • 7.8.2 gevent/eventlet 和 asyncio 用法区别感受
    • 7.8.3 关于 async 并发模式，为什么框架还使用 pyredis pika pymongo，而没有使用aioredis aiomongo
  • 7.8.4 愚蠢的celery调用异步函数写法
  • 7.9 2021-04 新增以 redis 的 stream 数据结构 为中间件的消息队列。
  • 7.10 2021-04 新增以 redis 的 list 为数据结构，但使用 brpoplpush 命令 双队列 作为中间件的消息队列。
  • 7.11 2021-04 新增以 zeromq 为中间件的消息队列。
  • 7.12 2021-04 新增以 操作kombu包 为中间件的消息队列
  • 7.14 2021-04 新增以mqtt emq 作为消息中间件
  • 7.15 2021-04 新增以 httpsqs 作为消息中间件
  • 7.16 2021-04 新增支持下一代分布式消息系统 pulsar 。
  • 7.17 2021-04 新增延时运行任务,介绍见4.8
  • 7.18 2021-09 新增 轻松远程服务器部署运行函数
  • 7.19 2021-09 新增 socket udp/tcp/http 消息队列，不需要安装消息中间件软件。
  • 7.20 2021-09 新增 支持 nats 高性能消息队列
  • 7.21 2022-01 新增 @boost装饰器全局默认配置
  • 7.22 2022-02 新增暂停消费功能
  • 7.23 2022-04 消费者/boost装饰器 新增 broker_exclusive_config 参数
  • 7.24 2022-04 新增用户 自定义记录消费状态结果函数钩子
  • 7.25 2022-04 新增用户灵活自由自定义扩展中间件和生产消费逻辑的功能
  • 7.26 2022-07 新增内置以redis作为apscheduler存储的定时器，动态增删改查定时任务配置。
  • 7.27 2023-02 新增适配python 3.6-3.11所有版本
  • 7.28 2023-02 新增 asyncio 语法生态下rpc获取执行结果
  • 7.29 2023-03 新增死信队列
  • 7.30 2023-03 新增支持ctrl + c 退出程序
  • 7.31 2023-04 新增支持 celery 作为 broker。
  • 7.32 2023-04 新增支持 python 微服务框架 nameko 作为 broker。
  • 7.33 2023-05 优化了apscheduler定式框架的动态删除添加定时任务
  • 7.34 2023-05 重新实现了boost装饰器
  • 7.35 2023-06 新增支持优先级队列
  • 7.36 2023-07 新增支持 funboost远程杀死任务
  • 7.37 2023-07 新增所有命名空间的日志和print都另外写入到一个总的文件中。
  • 7.38 2023-10 多线程并发模式，增加了支持async def的函数
  • 7.39 2024-01 @booost装饰器入参变成pydantic Model类型, BoostParams类或子类
  • 7.40 2024-03 函数运行状态页面增加消息运行中状态
  • 7.41 2024-03 新增 funboost_current_task 上下文
  • 7.42 2024-04 新增支持消费函数定义入参 **kwargs,用于消费任意json消息
  • 7.43 2024-05 新增另外一种方式来 自定义增加或重写 消费者 发布者
  • 7.44 2024-06 重磅升级！funboost 支持实例方法、类方法、静态方法、普通函数 4种类型，作为消费函数的例子
  • 7.45 2024-08 @boost入参新增 is_auto_start_consuming_message，定义后立即自动启动消费。
  • 7.46 2024-08 修复使用redis心跳来辅助确认消费的redis中间件模式，重复消费的bug
  • 7.47 2025-01 加强了 funboost web manager 功能
  • 7.48 2025-07 消费函数的入参类型可以是自定义类型对象(不可json序列化的类型)
  • 7.49 2025-08 新增Booster对象pickle序列化, 间接支持了 aps_obj.add_job 方式添加定时任务
  • 7.50 2025-08 新增 grpc 作为funboost 的 broker
  • 7.51 2025-08 新增支持 mysql_cdc 作为 broker
  • 7.52 2025-10 @boost装饰器,新增设置 booster_group 消费分组
  • 7.53 2026-01 新增 funboost.faas，快速实现FaaS（非常好用重要）
  • 7.54 2026-01 修改了一些拼写错误的名字，（对应funboost 版本 53.0之后）。
    • 1. 内部保护方法变更
    • 2. 消息发送与配置类变更
    • 3. BoosterParams 参数拼写修正
    • 4. 💡 迁移建议
    • 5. funboost 没有celery的配置变化改动大
  • 7.55 2026-01 函数结果持久化支持设置表名
  • 7.56 2026-01 新增 opentelemetry 全链路任务追踪，这是funboost的一个生产级别的重要战略级功能
  • 7.56 2026-01 新增 Prometheus 指标监控，对接你们自己的运维系统
  • 7.58 2026-01 funboost新增声明式任务编排 workfolw
  • 7.59 2026-01 增强redis稳定性
  • 7.60 2026-01 funboost 的确认消费，unack消息重回队列去掉 scan
  • 7.61 2026-01 funboost极限性能优化，发布和消费性能提升120%
  • 7.62 2026-01 funboost消费新增支持微批消费
  • 7.63 2026-03 funboost 增加高级重试：指数退避重试
  • 7.63 2026-03 funboost 增加熔断降级
  • 7.64 2026-03 funboost 增加 失败告警，使用AlertNotifierConsumerMixin
  • 7.65 2026-03 funboost 增加 失败告警，使用MongoAlertMonitor
  • 7.66 2026-03 funboost_web_manager 统一改称 funweb，增加3个系统功能
  • 7.77 2026-05 增加 funboost_pool 两个类, 完美复刻 concurrent.futures.Executor API
  • 7.78 2026-05 优化增强 FlexibleThreadPool 和 AsyncPoolExecutor
• 8.用于爬虫
  • 8.0 funboost 用于爬虫前序
    • funboost scrapy 两种框架写爬虫代码方式代码明显对比
      • funboost框架是自由框架的证据:
      • scrapy是框架奴役的证据:
    • 8.0.1 tips : 202309 新增boost_spider爬虫框架
    • 8.0.2 funboost 降维打击仿scrapy api爬虫框架
      • funboost 太省时间
      • @boost 一键赋能你的函数，功能远超爬虫框架
      • funboost 打破数据孤岛：秒变微服务，Java/Go 随时调用
      • 有人怀疑 funboost没有http请求中间件，这恰好是对scrapy的最大优势
      • funboost能轻松自然完成，而scrapy无法完成的爬虫场景1，浏览器多轮交互
      • 总结下funboost和scrapy在小项目和大项目：
    • 8.0.3 讨scrapy檄文：Funboost兴，Scrapy亡，天下爬虫，当顺天命！
    • 8.0.4 很多人问这个框架能不能爬虫？
    • 8.0.5 为什么 funboost 用来爬虫时候，扩展性简单性 远超 scrapy api式的一众传统爬虫框架？
    • 8.0.6 主动集中简要回答驳斥一些scrapy 优势更大的观点
      • 你质疑funboost 没有 http middware ？
      • 你质疑funboost 没有 pipeline，质疑保存数据麻烦？
      • 你说Scrapy 插件生态丰富，质疑Funboost 没有三方包插件生态不够？
      • 你项目下的 utils 文件夹的工具类是黄金还是废铁？取决于你用什么哲学的框架
      • 你说scrapy社区支持，有庞大的专门各种问题的讨论？质疑funboost没有社区？
      • 你羡慕scrapy的response有自带.xpath .css .extract_first .extract_all 方法？
      • scrapy twisted 性能强悍？担心funboost爬取不快？
      • 你质疑scrapy重试功能强大？
      • 你怀疑scrapy稳定，funboost不稳定？
      • 你质疑scrapy自带去重，funboost不能去重？
      • 你质疑funboost不能断点续爬？
    • 8.0.7 funboost爬虫时候是任何方面超过scrapy,不接受辩证法说scrapy也有优势
    • 8.0.8 国内爬虫框架突破很小,不是有意抄袭巧合,而是情不自禁模仿scrapy api
  • 8.0b 你的 utils 文件夹是黄金还是废铁？取决于你用什么哲学的框架
  • 8.1 演示获取汽车之家资讯的 新闻 导购 和 评测 3个板块 的 文章。
  • 8.2 演示经典的豆瓣top250电影的爬虫
    • 8.2.2 funboost 对比网上的 scrapy 爬取 douban代码
  • 8.3 演示3种最常见代码思维方式爬取汽车之家资讯
    • 8.3.1 每次临时手写rquests + 多线程,使用low爬虫方式的缺点
    • 8.3.2 scrapy 爬虫框架来实现缺点
    • 8.3.3 scrapy 框架 和 分布式函数调度框架爬虫对比
    • 8.3.4 临时low方法手写爬虫全流程的代码 （手写多线程 + queue 分发调度 ）
    • 8.3.5 scrapy爬虫代码
    • 8.3.6 分布式函数调度框架的代码
  • 8.7 scrapy 和 仿scrapy api 式爬虫框架 回调地狱，代码写法思维反直觉
  • 8.8 详细说明为什么 Scrapy 爬虫代码不是直观的"平铺直叙"写法？
  • 8.9 仿scrapy api框架中无法完成的需求真实例子2，token有效期太短
  • 8.10 scrapy的 response.meta 字典传参无法ide自动补全提示
  • 8.11 funboost中反爬虫换代理ip 请求头 破解等 容易程度暴击专用爬虫框架scrapy
    • 8.11.1 scrapy中换代理ip和请求头代码
    • 8.11.2 用户自己自由封装一个换代理ip和请求头的request函数，自然又简单
    • 8.11.3 为什么scrapy换代理IP和请求头的高难度分析my_request
  • 8.12 scrapy 可直接运行测试验证性很差
  • 8.13 funboost 断点接续运行能力吊打scrapy-redis 的 blpop （funboost支持确认消费）
    • 8.13.1 为什么 funboost的断点续爬完胜 scrapy-redis的断点续爬(防丢数据1)
    • 8.13.2 funboost的函数重试功能远远暴击scrapy的url重试功能(防丢数据2)
  • 8.14 其他funboost 吊打 scrapy原因 详细介绍
    • 8.14.1 为什么funboost的去重功能远远吊打scrapy的Request对象指纹去重？
      • 8.14.1.1 funboost 支持有效期过滤
      • 8.14.1.2 scrapy无法过滤url中的噪音入参，例如ts时间戳，rd随机数，追踪来源id
    • 8.14.2 详细驳斥 Scrapy 插件生态丰富，质疑Funboost 没有三方扩展
    • 8.14.3 架构级碾压：Funboost 天然就是 FaaS 微服务，而 Scrapy 只是数据孤岛
      • 8.14.3.1 Funboost 的实现方式：微服务式的天然解耦
      • 8.14.3.2 Scrapy 的实现方式：反直觉的高耦合代码
      • 8.14.3.3 场景扩展：数据补采与调试
      • 8.14.3.4 总结
      • 8.14.3.5 架构选型结论
  • 8.15 funboost的调度、去重、并发、反爬定制，各方面吊打了scrapy,非专业框架竟然虐专业框架?
  • 8.16 为什么funboost 在面对反爬虫网站时候 吊打 scrapy?
  • 8.16b funboost + boost_spider 在反爬方面，完胜 scrapy 这种所谓的专业爬虫框架
    • 8.16b.1 🛡️ 反爬虫能力全方位对比表：boost_spider vs scrapy
  • 8.17 如果禁止使用搜索 ai外部辅助,人工默写scrapy和funboost爬虫,哪个更难?
  • 8.30 为什么 funboost 能用于爬虫 的本质原因
  • 8.31 boost_spider (powered by funboost) 专业爬虫工具库介绍
    • 8.31.1 boost_spider 的 RequestClient 类介绍
    • 8.31.2 boost_spider 的 SpiderResponse 类介绍
    • 8.31.2b boost_spider/http/request_client.py 中的 RequestClient 和 SpiderResponse 功能如下:
    • 8.31.3 boost_spider 内置了各种类型的数据库sink,全部只需要一行代码就能把字典入库.
    • 8.31.4 boost_spider 写法demo (写法完全和funboost一样)
    • 8.31.5 补充这个 boost_spider内容 是为了打消用户质疑
  • 8.40 集中总结的 Funboost vs. Scrapy 优势快速对比 (表格版)
  • 8.40b 集中总结 funboost vs scrapy 优势快速对比（文字版）
  • 8.41 Funboost vs. Scrapy 爬虫能力全方位对比（百分制评分）
• 9 轻松远程服务器部署运行函数
  • 9.1 远程服务器部署函数的意义
  • 9.2 远程服务器部署函数的入参介绍。
  • 9.3 远程服务器部署消费函数的代码示例。
• 10.python3.6-3.12 安装/使用funboost出错问题反馈
  • 10.0 框架与你项目依赖的三方包版本不一致冲突？
  • 10.1 windwos安装后如果报错 ImportError: DLL load failed while importing win32file
  • 10.2 启动消费后报错: RuntimeError: cannot schedule new futures after interpreter shutdown
  • 10.3 文档1.3例子 BrokerEnum.PERSISTQUEUE,sqlite作为中间件例子在mac/linux运行,报错 read-only
• 11 funboost 使用某些中间件或三方任务队列框架作为broker的例子(包括celery框架)。
  • 11.1 使用celery作为funboost的中间件
    • 11.1.1 funboost启动celery消费和定时和flower
    • 11.1.2 funboost发布任务到celery队列
    • 11.1.3 funboost使用celery作为中间件的运行截图
    • 11.1.4 funboost 的api 操作celery，比人工操作 celery 大大简化。
    • 11.1.5 funboost 使用celery作为中间件时候，可以填写的celery任务配置
    • 11.1.6 网上关于celery项目目录结构和文件夹/文件命名必须很死板， 是错的
    • 11.1.7 仍然想使用celery命令行？
    • 11.1.8 任然可以亲自使用celery的原生任务函数对象 celery.app.task.Task
    • 11.1.10 funboost使用celery作为broker_kind的原理
  • 11.2 使用nameko 微服务框架作为funboost消息中间件例子
    • 11.2.1 nameko服务端脚本
    • 11.2.2 nameko客户端脚本
    • 11.2.3 funboost操作nameko能简化亲自使用nameko框架的语法
  • 11.3 使用kombu作为funboost的broker
    • 11.3.1 kombu操作rabbitmq作为funboost的消息队列
    • 11.3.2 kombu+redis作为消息队列
      • 11.3.2.b kombu + redis哨兵作为消息队列
    • 11.3.3 kombu+sqlalchemy 作为消息队列
    • 11.3.4 kombu+mongo作为消息队列
    • 11.3.5 kombu+文件作为消息队列
  • 11.4 使用dramatiq框架作为funboost消息队列
  • 11.5 使用huey框架作为funboost消息队列
  • 11.6 使用rq框架作为funboost的broker
  • 11.7 使用 grpc 作为funboost的broker
  • 11.8 使用 mysql_cdc 作为 funboost 的broker
  • 11.9 演示 funboost 使用 tcp/udp/http 作为broker
  • 11.10 Watchdog Broker：监听文件系统变更（ETL 利器）
    • 11.10.1 核心配置说明
    • 11.10.2 代码示例
    • 11.10.3 特性深度解析
      • 11.10.3.1 关于 existing 事件
      • 11.10.3.2 关于 read_file_content
      • 11.10.3.3 关于 debounce_seconds
• 12 funboost 控制台支持命令行
  • 12.0 funboost命令行使用fire实现
  • 12.1 命令行分为调用funboost包内命令和用户自身项目的命令行
    • 12.1.1 funboost自身命令行,python -m funboost 是自动调用 funboost的 main.py 的fire命令行
    • 12.1.2 用户项目根目录下的 funboost_cli_user.py 的文件可以接受命令行传参
      • 说明:之后的例子不再同时列举 python -m funboos 和 python funboost_cli_user.py
    • 12.1.3 python -m funboost 和 python 项目根目录/funboost_cli_user.py 传参不同点
  • 12.2 funboost命令行指定消费函数所在的模块或文件夹
  • 12.3 打印发现的用户定义的@boost消费函数
  • 12.4 funboost命令行清空消息队列
  • 12.5 funboost命令行给一个队列发布消息
  • 12.6 funboost命令行启动多个queue消费者
    • 12.6.b funboost命令行启动所有queue消费者,用户无需指定队列名
  • 12.7 funboost命令行暂停消费
• 13 funweb (funboost web manager) 介绍
  • 13.1 介绍 启动 funweb (funboost web manager) (方式一)。
    • 13.1.b 直接在代码中启动web start_funboost_web_manager() (方式二)：
  • 13.2 funweb 截图
  • 13.3 funboost web 图片对应的测试代码
  • 13.4 funweb 系统功能-脚本部署管理（爽功能）
    • 13.4.1 核心功能
    • 13.4.2 使用方式
      • 13.4.2.2 funboost 查看日志按时间筛选范围说明
    • 13.4.3 funweb 脚本部署功能说明
    • 13.4.4 脚本部署功能截图
    • 13.4.5 降维打击：funweb 脚本部署为何完爆 Supervisor？
      • 13.4.5.1. 📝 纯 Web 可视化配置，告别反人类的 .ini 与环境变量地狱
      • 13.4.5.2. ⚡️ 堪比 ELK 的神级日志检索（百G日志，毫秒级响应）
      • 13.4.5.3. 🚀 内置 CI/CD：兼具“发版平台”能力
      • 13.4.5.4. 🛡️ 进程防误杀机制：解决 PID 复用的终极痛点
      • 13.4.5.5. 🏥 智能健康检查与“秒退”精准诊断
      • 13.4.5.6. 💻 真正的跨平台支持与“零特权”部署 (Win/Linux 双端通吃)
      • 13.4.5.7. 👁️ 告别黑箱，极致的透明操作反馈
    • 13.4.6 funweb 是否支持远程部署（部署到其他机器）？
      • 13.4.6.2 Funboost 部署 vs 传统 Jenkins 发版平台：为什么我们选择“本地化”？
    • 13.4.7 降维打击：Funboost Web 部署比直接用 Xshell 爽在哪里？
      • 13.4.7.1. 🔌 告别繁琐的登录与“断连焦虑”
      • 13.4.7.2. 🖱️ 零门槛“傻瓜式”操作，彻底解放开发者
      • 13.4.7.3. 👁️ 拒绝“黑盒启动”，所见即所得的存活监控
      • 13.4.7.4. 📖 降维打击的日志查阅体验，终结反人类的 grep
      • 13.4.7.5. 🛡️ 自带“死而复生”的进程守护，远超脆弱的 nohup
      • 13.4.7.6. 🧬 配置资产沉淀，告别“祖传 txt 小本本”
      • 13.4.7.7. 🎯 精准狙击 PID，彻底杜绝“同名误杀”惨案
      • 13.4.7.8. ⚖️ 傻瓜式的一键“多进程”横向扩容
  • 13.5 funweb 系统功能-资源监控
  • 13.6 📖 funweb 系统功能 - 通用日志查看器
    • 13.6.2 ✨ 功能亮点
• 14 🏅[懒人必看章节] 利用ai来掌握 funboost 的 正确方式
  • 14.0 🤬 [高能预警]在此章节最开头，先允许我用最恶毒的语言来刺激骂醒一部分又懒又蠢的懒癌患者的大脑皮层！
    • 14.0.1 🧠 脑残行为大赏
    • 14.0.2 🚫 别拿通用框架的经验来羞辱我的智商
    • 14.0.3 ❌ [严重警告] 懒癌患者请把下面这几点刻在脑门上！
    • 14.0.4 ✅ ai掌握funboost的唯一正确的路径
    • 14.0.5 🤬 当我问你怎么使用ai时候，你最少要回答200字到底是怎么使用ai的，别踏马就简单的说:"我已经用ai来问funboost问题了"
  • 14.0b 推荐一个在ai时代 神级别黑科技掌握任意非知名的it项目的方式 nb_ai_context
  • 14.0c 为什么要专门写第14章这个教程？
  • 14.0d 各个 ai 掌握funboost 能力评分
  • funboost_all_docs_and_codes.md 文档说明
    • 14.1.1 一定要上传markdown文档再提问
    • 14.1.2 funboost 的 markdown文档地址说明
    • 14.1.3 funboost的ai markdown文档是使用神级别 ai上下文生成工具 nb_ai_context 生成的
    • 14.1.4 公布 funboost ai上下文 markdown 文档的生成方式
• 15. ⚡ Funboost.FaaS：让函数起飞的 Serverless 引擎
  • 15.1 🌟 架构质变：从 Worker 到 Service
  • 15.2 💎 核心特性：六大“无限宝石”
    • 🔌 开箱即用 (Out-of-the-Box)
    • 🔥 无缝热发布 (Hot Discovery)
    • 🔄 RPC 同步调用 (HTTP-RPC Bridge)
    • 🧬 全自动参数校验
    • ⏱️ 可编程调度中心
    • 📊 全景透视能力
  • 15.3 🌌 深度发散：从“任务队列”到“无服务器计算平台”
  • 15.4 🛠️ 核心原理：为什么它能"以一当百"？
    • ❌ 痛点：传统的"硬编码"地狱
    • ✅ Funboost 解法：基于元数据的动态代理
  • 15.5 📚 API 接口清单 (Swagger 开箱即用)
    • 15.5.1. 📨 消息发布与结果查询
    • 15.5.2. 🔍 服务发现与元数据 (FaaS 核心)
    • 15.5.3. ⚙️ 队列运维与全景监控
    • 15.5.4. ⏰ 动态定时任务编排
    • 15.5.5. 🎛️ Scheduler 调度器控制
    • 15.5.6. 🏷️ 项目筛选 (care_project_name)
    • 15.5.10. 📄 Swagger接口文档
  • 15.6 💻 快速接入指南
    • 15.6.1 FastAPI 接入 (推荐 🌟)
    • 15.6.2 Flask 接入
    • 15.6.3 Django 接入 (使用 Django-Ninja)
    • 15.6.4 权限控制 (Security)
  • 15.7 🎯 调用示例
    • 场景：通过 Curl 发布一个 RPC 任务并等待结果
  • ⚠️💡 15.8 注意事项
  • 🧪 15.9 funboost.faas 演示例子
    • 15.9.2 如何测试测试函数自动发现？
  • ⏰ 15.10 funboost.faas 定时任务管理 —— 架构级解耦的调度中心(完爆传统 APScheduler 管理)
    • 15.10.1 🥊 核心差异：为什么完爆传统 APScheduler 管理？
    • 15.10.2 🚀 Funboost 的解决方案：彻底解耦
    • 15.10.3 🛠️ 接口能力概览
    • 15.10.4 💻 调用示例：完全黑盒化的管理
      • 1. 动态添加任务 (无需代码引用)
      • 2. 管理任务
    • 15.10.5 ⚙️ 技术原理：为什么能做到？
    • 15.10.6 总结
  • 15.11 funboost.faas 为什么比传统Web框架写接口更爽？
    • 15.11.1 传统 Django/Flask 的尴尬："脱了裤子放屁"
    • 15.11.2 funboost.faas 的设计哲学：函数即接口
    • 15.11.3 代码量对比
    • 15.11.4 上新功能流程对比
    • 15.11.5 最爽的几个点
      • 15.11.5.1 真正的"写完即上线"
      • 15.11.5.2 Web 网关 = 万能入口
      • 15.11.5.3 天然支持异步和 RPC
      • 15.11.5.4 跨团队协作超方便
    • 15.11.6 什么场景传统方式更合适？
    • 15.11.7 本质区别
• 16 对funboost的评价
  • 16.0 个人用户对funboost的评价
  • 16.1 google ai studio + gemini-pro 对funboost的评价
  • 16.3 腾讯ima-deepseek 对funboost的评价
    • 🧠 核心战略思想：自由赋能，拒绝奴役
    • 🌉 战略桥梁：打通“离线任务”与“在线服务”的任督二脉
    • 🧩 战略抽象：万物皆可调度，万物皆可为 Broker
    • ⚡ 战略性能：数量级领先的代差优势
    • 🎯 战略价值：开发者生产力的核聚变
    • 🏆 总结：升维的架构哲学
  • 16.4 qwen3-max 对funboost的评价
• 20. Funboost 核心思想：一场关于“函数解放”的革命 🌪️(gemini生成总结)
  • 20.1 🗽 核心哲学：拒绝“框架奴役”，拥抱“函数至上”
    • 20.1.1 👑 函数即国王 (Function is King)
    • 20.1.2 🔓 极致的自由主义 (Absolute Freedom)
  • 20.2 🔌 万物皆可 Broker，打破时空界限
    • 20.2.1 🌌 Broker 的终极抽象：万物互联
    • 20.2.2 ⚡ 并发模式的“核武库”
  • 20.3 🚀 Funboost.FaaS：从“后台任务”到“云原生微服务” (New!)
    • 20.3.1 🌐 秒变 Serverless 计算平台
    • 20.3.2 🔥 热更新与动态架构
  • 20.4 🛡️ 精确的暴力美学：可靠性与控制
    • 20.4.1 🎯 QPS 控频：时间的主人
    • 20.4.2 🧱 叹息之墙：万无一失的消息确认
  • 20.5 🧠 为什么说 Funboost 是“高维生物”？
  • 20.6 👑 终极定义：Funboost 是什么？