2. ⚔️ 对比celery框架

此章节对比 celery 和 funboost 分布式函数调度框架，采用严格控制变量法精准对比（中间件一致、控制参数一致、并发类型一致、并发数量一致）。

2.0 ❓ funboost 是不是抄袭celery的源码?

funboost 对比 celery，就像 📱 iPhone 对比诺基亚塞班手机——核心本质功能一样，但不是重复造轮子。

答案和分析，见文档 6.12 章节。

2.1 🔗 celery对目录层级文件名称格式要求很高

celery 对目录层级和文件名要求严格，适合规划新项目，对不规则文件夹套用难度高。

⚠️ celery 消费任务不执行或报错 NotRegistered，与以下 6 方面有关：

1. 📁 整个项目目录结构（celery 对此有严格要求）

2. 🏷️ @task 入参 name（是否主动设置）

3. ⚙️ celery 配置中的 task_queues 和 task_routes

4. 📋 配置中的 include / imports / app.autodiscover_tasks

5. 💻 cmd 命令行启动参数 --queues= 的值

6. 📂 用户启动 cmd 命令行时所在的文件夹

🔍 根本原因：celery 需要中心化的 Celery 类实例（app），消费函数需要 @app.task，celery 启动时需要知道函数在哪里，必须配置 include/imports 列表——否则报 NotRegistered。这产生了互相导入的问题（a 导入 b，b 导入 a），celery 通过 include 字符串延迟导入来解决。

✅ funboost 没有中心化 app 实例的概念，@boost 装饰器独立工作，消费函数写在任意深层级不规则文件夹下都行，不需要 include/imports 配置。

不规范文件夹路径下的 celery 使用演示

2.2 🚀 性能远远超过celery20倍以上（使用初中的严格控制变量法）

任意并发模式、任意中间件类型，发布和消费性能远超 celery。

• 🔥 funboost 发布性能 ≈ celery 的 50 倍

• 🔥 funboost 消费性能 ≈ celery 的 100 倍

性能跑分代码在下面 2.6 章节。

2.3 💡 celery的重要方法全部无法ide自动补全提示

funboost 为 IDE 自动补全做了额外优化，celery 全部重要公有方法无法补全提示：

🏷️ 对比维度	✅ funboost	❌ celery
配置文件	固定的 funboost_config.py，可补全	100+ 配置项，用户不知道能配置什么
启动方式	fun.consume() / fun.multi_process_consume()	cmd 命令行，容易打错
发布参数	fun.push() / fun.publish() 全部可补全	apply_async 函数名和 20 种入参均无法补全
装饰器入参	@boost 所有参数可补全 + Ctrl+Shift+I 查看注释	@app.task 的 *args, **opts 无法知道能传什么

💎 funboost 宁愿重复声明入参也不使用 *args **kwargs，一切为调用者方便而非实现时精简。

2.4 📊 比celery强的方面的优势大全

#	🏷️ 优势维度	✅ funboost	❌ celery
1	🖥️ 平台支持	Win/Linux/Mac 全支持	4.x 后放弃 Windows
2	🔌 Broker 种类	40+ 种，万物皆可为 Broker	仅 Kombu 支持的 MQ
3	🚀 性能	发布 50x，消费 100x	基准性能差
4	💡 IDE 补全	全部公有方法可补全	无法补全
5	▶️ 启动方式	python xx.py	复杂命令行
6	📁 目录结构	无限制，100% 自由	严格文件夹要求
7	📖 使用复杂度	只学 @boost 一个装饰器	5000 页英文文档
8	📨 消息格式	纯净 JSON，跨语言友好	混合 Python 项目信息
9	⚡ asyncio	全链路原生支持	不支持 async def
10	🎯 控频精度	99.9% 精确	~60%
11	🌐 分布式控频	支持全局分布式 QPS	仅单 Worker 限速
12	🔄 多进程+多线程	叠加并发	互斥模式
13	🌈 日志	nb_log 彩色日志	基础日志
14	🖧 远程部署	fabric_deploy 一键部署	无
15	🧬 类/实例方法	支持实例方法和类方法	仅普通函数/静态方法
16	⏰ 定时任务	动态添加/删除 + 多机不重复	配置式 beat_schedule + 单点故障
17	🔀 路由配置	装饰器直接定义队列名	task_routes + task_queues 复杂配置
18	⚙️ 配置方式	继承 BoosterParams + Pydantic 补全	app.conf 和 @app.task 命名不一致
19	🧩 自定义扩展	OOP 继承重写，100% 可定制	依赖预留 Signals，否则需改源码
20	📥 消费任意消息	**kwargs + _user_convert_msg_before_run	无法识别非 celery 格式消息
21	⏳ 等待任务完成	wait_for_possible_has_finish_all_tasks()	无此功能
22	🧱 框架插件	无需 django-funboost 适配插件	需要各种适配插件
23	💀 死信队列	特定异常或配置自动移入	机制简单
24	💓 Redis ACK	心跳检测，精准回收孤儿消息	visibility_timeout 机制有缺陷
25	🧠 fct 上下文	无入侵，函数签名保持纯净	bind=True + 插入 self 参数
26	☁️ FaaS	内置 funboost.faas，函数即服务	无原生 FaaS
27	📦 微批消费	内置 MicroBatchConsumerMixin	不支持
28	🎰 周期额度	支持（非匀速限制）	rate_limit 只能匀速
29	📡 事件驱动	支持 CDC/文件系统/传感器作为 Broker	仅传统消息驱动
30	📤 万能发布者	send_msg 发送纯净消息，跨语言通信	消息格式封闭

2.4.20 🔀 路由配置对比

funboost 为 99% 场景设计 API：fun1.push() 和 fun2.push() 即可发到不同队列。

如需完整 RabbitMQ 路由系统：broker_kind=BrokerEnum.RABBITMQ_COMPLEX_ROUTING 或 broker_kind=BrokerEnum.KOMBU。

2.4.23 🧠 fct 上下文 vs celery bind=True

# funboost：函数签名保持纯净
from funboost import boost, BoosterParams, fct

@boost(BoosterParams(queue_name="add_queue"))
def add(x, y):
    print(f"Task ID: {fct.task_id}")
    return x + y

# celery：必须 bind=True + 插入 self 参数，破坏原函数签名
@app.task(bind=True)
def add(self, x, y):
    task_id = self.request.id
    return x + y

2.4.27 📥 消费任意 JSON 消息

from funboost import boost, BoosterParams

@boost(BoosterParams(queue_name='queue_free_format', should_check_publish_func_params=False))
def task_fun(**kwargs):
    print(kwargs)

无论消息由 funboost 发布还是第三方发布，都能消费。典型场景：消费 canal/Debezium/Maxwell/flink cdc 发到 Kafka 的 binlog 消息。

2.4.32 💓 funboost + REDIS_ACK_ABLE 心跳 ACK 机制

celery + Redis 使用 visibility_timeout 机制存在两大缺陷：

1. Worker 崩溃后孤儿消息需等待超时（默认 1 小时）才重回队列

2. 耗时长的任务会被误判为死亡而重复执行

这两者通过 visibility_timeout 设置是矛盾的——设短则长任务被误重投，设长则孤儿消息不能及时恢复。

funboost 的 REDIS_ACK_ABLE 使用消费者心跳检测机制：精准识别 Worker 是否存活，死掉的 Worker 任务立即回收，长耗时任务不会被误判。

celery 官方文档也承认此问题：Caveats - Visibility timeout

2.4.33 ⚙️ funboost 通过继承 BoosterParams 实现显式配置

class MyBoosterParams(BoosterParams):
    is_using_rpc_mode: bool = True
    broker_kind: str = BrokerEnum.REDIS_ACK_ABLE
    max_retry_times: int = 0

@boost(MyBoosterParams(queue_name='q1'))
def task(...): ...

celery 全局配置 vs 函数级参数命名不一致导致静默失效：

配置目的	全局配置	函数级配置	常见错误
执行完确认	task_acks_late = True	acks_late=True	@app.task(task_acks_late=True) → 无效
限速	task_annotations	rate_limit='10/s'	app.conf.rate_limit='10/s' → 无效
最大重试	task_default_max_retries = 3	max_retries=3	@app.task(task_default_max_retries=3) → 无效

2.4.40 💣 funboost 支持celery作为broker_kind（王炸）

@boost(BoosterParams(queue_name='celery_q1', broker_kind=BrokerEnum.CELERY, qps=5))
def my_task(x): ...

funboost 的极简 API + celery 的核心调度引擎。celery 成为 funboost 的子集。

2.4b ⚔️ 讨Celery檄：Funboost十胜定乾坤，函数王朝开天命

夫任务调度之道，贵在通达！队列纵横之术，胜在易用！ 昔Celery恃RabbitMQ Redis之威，窃踞调度王座十数载，然其架构臃肿如裹足老象，兼容性似残破牢笼！今观其势：弃Windows如敝履，控频精度若醉汉；困目录结构作茧，性能吞吐成笑谈——开发者叩首于五千页文档，匍匐于晦涩命令行，此诚天下苦秦久矣！ 今有Funboost，承函数调度天命，执 @boost神器，以性能裂苍穹之威，兼容纳百川之量，革旧弊，立新规，伐无道！十胜锋芒所指，Celery十败如山崩！

---

十胜十败·定鼎九州

一胜曰：疆域之胜 Celery弃Windows疆土，多进程启动即崩，开发寸步难行，此谓金瓯残缺失半壁！ Funboost跨三界称尊，进程线程协程任选，开发生产皆驰骋，此谓寰宇纵横掌天门！

二胜曰：器量之胜 Celery闭中间件之门，Kafka/MQTT皆拒，新潮队列成陌路，此谓夜郎闭户终自绝！ Funboost纳廿四路诸侯，内建队列立乾坤，更兼兼容Celery全系器，此谓海纳百川容星汉！

三胜曰：神速之胜 Celery吞吐若老牛破车，性能瓶颈成痼疾，此谓老牛破车困泥潭！ Funboost疾如雷霆裂空，发布快2000%惊鬼神，消费疾4000%贯九霄，此谓追风逐电荡八荒！

四胜曰：明道之胜 Celery动态元编程蔽日，参数传递如盲人摸象，此谓雾锁重楼失北斗！ Funboost智能补全烛幽冥，类型声明破迷障，IDE红线斩谬误，此谓日月当空照坦途！

五胜曰：简政之胜 Celery命令行如天书符咒，路径错漏频生，此谓蜀道悬梯困苍生！ Funboost执python xx.py开太平，老幼皆宜无障碍，此谓大道至简定江山！

六胜曰：自由之胜 Celery目录囚笼锁蛟龙，imports镣铐缚云翼，此谓金丝雀困雕花笼！ Funboost十层深阁任穿梭，脚本四海可为家，此谓鲲鹏振翅九万里！

七胜曰：包容之胜 Celery消息混杂Python痕，跨语言协作成天堑，此谓孤岛闭门终自绝！ Funboost纯净JSON通万邦，Python/Java共交响，此谓丝绸新路连寰宇！

八胜曰：天时之胜 Celery拒async浪潮于门外，协程革命空嗟叹，此谓刻舟求剑失沧海！ Funboost纳asyncio入经脉，异步同步皆如意，此谓弄潮敢缚蛟龙归！

九胜曰：王道之胜 Celery控频单机尚粗疏，分布式更成镜花月，此谓乌合之众溃荒原！ Funboost执精密计时算法掌乾坤，分布式控频精度99.9%镇山河，此谓虎符一出千军肃！

十胜曰：革新之胜 Celery拒类方法于高墙，面向对象成虚妄，此谓孤芳自赏终取祸！ Funboost纳万物入调度，实例方法皆可Boost，此谓开宗立派写新章！

---

弑王绝刃·乾坤倒转

更备诛神兵符： Funboost竟容Celery为子集！@boost(broker_kind=BrokerEnum.CELERY)一出，旧王亦成新朝马前卒！此谓乾坤倒转收降将！

剑指苍穹宣言： "旧王Celery骸骨已寒，新皇Funboost旭日灼天！ 以@boost为传国玉玺，以分布式为定鼎九器—— 万物皆可调度，四海终归一统！"

2.5 🔌 funboost能支持celery整体框架作为broker_kind

✨ funboost 的极简 API + celery 的核心调度引擎，结合两者优点。

见文档 4.28 章节。

@boost(BoosterParams(queue_name='celery_q1', broker_kind=BrokerEnum.CELERY, qps=5))
def my_task(x): ...

指定 broker_kind=BrokerEnum.CELERY 后，funboost 自动使用 celery 核心来执行用户函数，而非 funboost 自身的调度核心。

2.6 🏎️ funboost 和 celery 性能比较源码（控制变量法）

🔗 对比源代码：funboost_vs_celery_benchmark

2.6.1 🧪 控制变量法说明

共同点：Win11 + Python3.9 + 本机 Redis + AMD R7 5800H + 单线程并发模式 + 相同逻辑消费函数

区别点：funboost vs celery 5.xx

2.6.2 📤 发布性能对比

🏷️ 框架	⏱️ 10万条耗时	📊 每秒发布
🚀 funboost	5 秒	~20000 条
🐢 celery	110 秒	~900 条

🔥 funboost 发布性能 ≈ celery 的 22 倍

2.6.3 📥 消费性能对比

🏷️ 框架	⏱️ 每1000条耗时	📊 每秒消费
🚀 funboost	0.08 秒	~14000 条
🐢 celery	3.6 秒	~300 条

🔥 funboost 消费性能 ≈ celery 的 46 倍

2.6.7 💻 benchmark 对比源码

2.6.7.1 celery 的跑分源码

# celery_consume.py
from celery import Celery
import datetime

app = Celery('namexx', broker='redis://localhost:6379/0')

@app.task(name='print_number', queue='test_queue_celery02')
def print_number(i):
    if i % 1000 == 0:
        print(f"{datetime.datetime.now()} 当前数字是: {i}")
    return i

if __name__ == '__main__':
    app.worker_main(['worker', '--loglevel=info', '--pool=solo', '--queues=test_queue_celery02'])

# celery_push.py
from celery_consume import print_number
import datetime

if __name__ == '__main__':
    print(f'当前时间: {datetime.datetime.now()}')
    for i in range(100000):
        if i % 1000 == 0:
            print(f'当前时间: {datetime.datetime.now()} {i}')
        print_number.delay(i)
    print(f'当前时间: {datetime.datetime.now()}')

2.6.7.2 funboost 的跑分源码

# funboost_consume.py
from funboost import boost, BrokerEnum, BoosterParams, ConcurrentModeEnum
import datetime
import logging

@boost(BoosterParams(queue_name='test_queue_funboost01',
                     broker_kind=BrokerEnum.REDIS, log_level=logging.INFO,
                     concurrent_mode=ConcurrentModeEnum.SINGLE_THREAD))
def print_number(i):
    if i % 1000 == 0:
        print(f"{datetime.datetime.now()} 当前数字是: {i}")
    return i

if __name__ == '__main__':
    print_number.consume()

# funboost_push.py
from funboost_consume import print_number
import datetime

if __name__ == '__main__':
    for i in range(100000):
        if i % 1000 == 0:
            print(f'当前时间: {datetime.datetime.now()} {i}')
        print_number.push(i)

2.6.9 🆕 2026-01 最新极限性能优化

经过极限优化后，funboost 发布性能是 celery 的 50 倍 🔥，消费性能是 celery 的 100 倍 🔥。

注意：性能倍数指的是执行简单函数（如 def fun():pass）的基准性能，就像测试 web 框架永远是接口直接 return hello world。

优化点：去掉不必要的 deepcopy、属性惰性生成、变量复用、全手写并发池。

2.7 🏆 rq celery funboost 段位比较

🏷️ 框架	🎖️ 段位	📝 特点
RQ	🥉 倔强青铜	简单直接，但只支持 Redis，无定时任务，Windows 无法并发
Celery	🥈 荣耀黄金	功能全面但操作复杂，命令行繁琐，性能受限于 Kombu
Funboost	🥇 传奇王者	简单+强大+灵活+可靠，设计理念领先

🎯 Funboost 的核心优势：操作像 RQ 一样简单，能力比 Celery 更全面，性能超越两者一个数量级。

2.8 💻 celery 和 funboost 分别将加减乘除作为消费函数完整例子

2.8.1 ✅ funboost 来实现加减乘除

项目文件树：

project_funboost/
├── math_operations/
│   ├── add_function.py
│   ├── subtract_function.py
│   ├── multiply_function.py
│   └── divide_function.py
└── main.py

math_operations/add_function.py（无需导入任何 app 实例，无需配置路由，队列名在装饰器中直接定义）：

from funboost import boost, BoosterParams, BrokerEnum

# 队列名、broker 类型都在装饰器中声明，IDE 可补全、可检查、可跳转
@boost(BoosterParams(queue_name='add_queue', broker_kind=BrokerEnum.REDIS))
def add(x, y):
    result = x + y
    print(f"Adding {x} and {y}: {result}")
    return result

main.py（发布和消费在同一脚本，import 即注册，无需 include 字符串列表）：

# 显式 import 即注册——IDE 可跳转检查，改了文件名 IDE 立即报红，不像 celery include 字符串写错不提示
from math_operations.add_function import add
from math_operations.subtract_function import subtract
from math_operations.multiply_function import multiply
from math_operations.divide_function import divide
from funboost import BoostersManager

if __name__ == '__main__':
    add.push(10, 5)
    subtract.push(10, 5)
    multiply.push(10, 5)
    divide.push(10, 5)

    # 方式1：选择性启动消费
    add.consume()
    subtract.consume()
    multiply.consume()
    divide.consume()

    # 方式2：按分组启动 BoostersManager.consume_group("my_group")
    # 方式3：启动所有已注册的消费者 BoostersManager.consume_all()
    # 方式4：多进程启动 divide.mp_consume(2)
    # 方式5：命令行启动 python funboost_cli_user.py consume add_queue subtract_queue
    # 方式6：远程部署 multiply.fabric_deploy(host, port, user, password)

▶️ 运行：python main.py 即可同时发布任务和启动消费者。无需 task_routes、task_queues、include 任何配置。新增函数只需写 @boost + import 即完成注册。

2.8.2 😫 Celery 项目演示（复杂配置）

项目文件树：

project_celery/
├── celery_config/
│   ├── celery_app.py
│   └── celery_config.py
├── math_operations/
│   ├── add_function.py  (每个文件需要 from celery_config.celery_app import app)
│   └── ...
├── main.py
└── start_worker.py

celery_config/celery_app.py：

from celery import Celery

app = Celery('celery_project')
app.config_from_object('celery_config.celery_config')
app.conf.include = [
    'math_operations.add_function',
    'math_operations.subtract_function',
    'math_operations.multiply_function',
    'math_operations.divide_function'
]
app.conf.broker_url = 'redis://localhost:6379/0'

celery_config/celery_config.py（路由 + 队列定义，每新增一个函数都要同步修改）：

from kombu import Queue

# task_routes：必须使用函数的完整模块路径字符串，写错一个字母就静默失效
# 如果用户改了函数名或移动了文件，这里必须同步修改，否则消息走默认队列但不报错
task_routes = {
    'math_operations.add_function.add': {'queue': 'add_queue'},
    'math_operations.subtract_function.subtract': {'queue': 'subtract_queue'},
    'math_operations.multiply_function.multiply': {'queue': 'multiply_queue'},
    'math_operations.divide_function.divide': {'queue': 'divide_queue'},
}

# task_queues：必须显式定义每个队列，需要理解 Kombu 的 Queue/Exchange/routing_key 概念
task_queues = (
    Queue('add_queue', routing_key='add_queue'),
    Queue('subtract_queue', routing_key='subtract_queue'),
    Queue('multiply_queue', routing_key='multiply_queue'),
    Queue('divide_queue', routing_key='divide_queue'),
)

以上配置全部是字符串，IDE 无法静态检查。一旦拼写错误，任务不消费且无明确报错，排查困难。

math_operations/add_function.py（每个任务文件都需要导入中心化的 app 实例）：

from celery_config.celery_app import app  # 如果 app 和此文件互相导入，则会报错

@app.task
def add(x, y):
    return x + y

启动需要：先 python main.py 发布任务，再单独运行 worker 命令并指定监听的队列列表。发布和消费不在同一个脚本中完成。

2.8.3 📊 对比总结

🏷️ 对比项	✅ Funboost	❌ Celery
配置简洁性	只需装饰器参数	需要多文件复杂配置
启动方式	python main.py 一步完成	发布和消费需分开启动
新增任务	写函数 + @boost 即可	需更新 include + routes + queues
IDE 检查	✅ import 可静态检查	❌ include 字符串无法检查
维护成本	模块独立，互不影响	配置集中，易出错

📝 Celery 像是在"填表"——在配置文件、路由表、Include 列表中填写字符串，任何标点错了程序都跑不起来。 ✨ Funboost 像是在"写 Python"——一切都是对象、函数、引用，IDE 能帮你补全，解释器能帮你检查。

2.9 🔬 funboost到底为什么性能比celery高几十倍？

🐢 celery 性能为什么差？

1. 超重的 Kombu 兼容转换层，只要用 Kombu 性能就比原生 MQ 包降低一大截

2. 从消息队列取出消息到真正运行函数逻辑，经过几十层调用链路和层层包装

🚀 funboost 性能为什么高？

1. 没有 Kombu 兼容转换层，直接操作原生 MQ 三方包

2. 从取出消息到运行函数逻辑，只有 3 层调用

3. 对 CPU 耗时超过 1 微秒的对象尽可能优化（惰性生成、变量复用、手写并发池）

2.20 🎖️ funboost 比 celery 的战略优势和战术优势

2.20.1 🌍 战略优势

🏷️ 维度	🐢 Celery	🚀 Funboost
架构定位	后台任务队列	自带 FaaS 能力的计算平台
设计哲学	集权式（中心化 app，强制目录结构）	联邦式（去中心化，零侵入）
兼容性	绑定 Kombu，对 Redis ACK 有缺陷	Broker 层完全解耦，支持 CDC/非标 Broker
异步支持	伪异步（补丁式 asyncio）	全链路原生 Asyncio

2.20.2 ⚔️ 战术优势

🏷️ 维度	🐢 Celery	🚀 Funboost
性能	互斥并发模式	多进程+线程/协程叠加
控频	单 Worker，精度差	单机+分布式，精度 99.9%
可靠性	visibility_timeout（易误重投）	💓 心跳 ACK（精准回收）
开发体验	字符串配置，无法补全	💡 Pydantic + 完美类型补全
运维	需额外部署 Flower	🌐 内置 Web Manager，可远程管控

2.20.3 🎯 总结

• 需要传统稳重的后台任务系统 → 🐢 Celery 够用

• 追求极致性能、开发效率、微服务架构、asyncio 生态融合 → 🚀 Funboost 具有代差优势