推荐学习书目
› Learn Python the Hard Way
Python Sites
› PyPI - Python Package Index
› http://diveintopython.org/toc/index.html
› Pocoo
值得关注的项目
› PyPy
› Celery
› Jinja2
› Read the Docs
› gevent
› pyenv
› virtualenv
› Stackless Python
› Beautiful Soup
› 结巴中文分词
› Green Unicorn
› Sentry
› Shovel
› Pyflakes
› pytest
Python 编程
› pep8 Checker
Styles
› PEP 8
› Google Python Style Guide
› Code Style from The Hitchhiker's Guide
bfpiaoran
V2EX  ›  Python

Python 有啥对协程支持好的队列框架么 试了几个都不行 最近快被搞崩溃了 难道要自己撸一个

  •  
  •   bfpiaoran · Jan 20, 2020 · 7254 views
    This topic created in 2484 days ago, the information mentioned may be changed or developed.
    28 replies  •  2020-01-22 09:57:48 +08:00
    blodside
    blodside
    Jan 20, 2020
    1
    Python 那些协程实现最大的问题是:代码里的其他依赖可能不支持协程,打补丁偶尔会出千奇百怪的错
    ps: 我研究了一段时间,发现还是 Twisted 更好用
    ipwx
    ipwx
    Jan 20, 2020
    2
    我觉得也只有自己撸一个了。。。

    @blodside 这个我觉得问题不大,你可以把其他代码放进 thread executor 或者 process executor 里面。反正你其他依赖不支持携程,理论上不也不支持 Twisted callback 么( doge )
    ClutchBear
    ClutchBear
    Jan 20, 2020
    3
    换 golang?
    TypeError
    TypeError
    Jan 20, 2020
    4
    @blodside #1 asyncio + concurrent.futures "其他依赖可能不支持协程"有什么关系
    niubee1
    niubee1
    Jan 20, 2020
    5
    为啥对协程有这么大的执念?用多进程不香么?
    bfpiaoran
    bfpiaoran
    OP
    Jan 20, 2020
    6
    @ClutchBear golang 短期不想换啊
    bfpiaoran
    bfpiaoran
    OP
    Jan 20, 2020
    7
    @blodside 对 celery 总是出现些奇怪的内存泄露 worker 收不到任务的问题 然后试了下 huey 啥的对 asyncio 支持也是特别差 还有的队列本身用的就是异步 event 也会出现莫名其妙的问题
    bfpiaoran
    bfpiaoran
    OP
    Jan 20, 2020
    8
    @niubee1 有的节点没法开多进程呀 核心本身就低 效率更低了 不如多线程呢 但是多线程 lock 的问题又不想搞 所以就这样了
    Vegetable
    Vegetable
    Jan 20, 2020
    9
    你的主要诉求是?队列操作一般算不上是 io 吧
    Vegetable
    Vegetable
    Jan 20, 2020
    10
    是要任务队列不是消息队列啊..这个可能会复杂不少没有了解了
    niubee1
    niubee1
    Jan 20, 2020
    11
    @bfpiaoran 你对多进程有什么误解唉
    bfpiaoran
    bfpiaoran
    OP
    Jan 20, 2020
    12
    @Vegetable 没啊 但是队列下的任务是 io 的
    bfpiaoran
    bfpiaoran
    OP
    Jan 20, 2020
    13
    @Vegetable 是的系统设计就有问题 任务队列每个人物需求不一样 打算重构一个了
    hankai17
    hankai17
    Jan 20, 2020
    14
    gevent?
    wangyzj
    wangyzj
    Jan 20, 2020
    15
    虽然不是不可以,但是你这个需求是要满足多大的量?不能横向扩展么?
    dsphper
    dsphper
    Jan 20, 2020
    16
    ???看半天看得我糊涂,celery 内存泄露 worker 收不到任务???这和协程有一毛钱的关系吗?很明显你写的代码有问题把 worker 卡死了,兄弟你得把基础打牢,最起码明白多进程多线程协程的基础原理,才能写出优质的代码。不要看网上那些乱七八糟的文章对个协程无脑吹(都是一些不经脑子跟风的),就感觉协程是个万能药。
    flynaj
    flynaj
    Jan 20, 2020 via Android
    17
    python 入门简单,真做产品你还是 golang 高效
    hehe12dyo
    hehe12dyo
    Jan 20, 2020
    18
    建议换 go。。。
    watsy0007
    watsy0007
    Jan 20, 2020
    19
    不如把问题发出来.
    下面回复换 go 的是认真的吗?
    wdf86
    wdf86
    Jan 20, 2020
    20
    能不能说一下队列和协程具体的关系?
    lolizeppelin
    lolizeppelin
    Jan 20, 2020 via Android
    21
    OpenStack 用 eventlet

    你说呢
    whi147
    whi147
    Jan 20, 2020
    22
    建议换 cpp
    sylvos
    sylvos
    Jan 20, 2020 via iPhone
    24
    Arq
    hj24
    hj24
    Jan 20, 2020 via iPhone
    25
    gevent 或者 asyncio 提供的 queue 不可以吗?还是说楼主都试过了,不满意的点在哪里?
    wzwwzw
    wzwwzw
    Jan 21, 2020
    26
    rabbitmq 之类的应该有异步链接库吧,自己撸一个吧。目前看 asyncio 的库还不够生产用。
    Leigg
    Leigg
    Jan 21, 2020 via Android
    27
    用过哪些,为什么不行?
    guochao
    guochao
    Jan 22, 2020
    28
    我自己闲的时候写的东西也是需要些并发啊什么的。一开始用 nodejs,用不熟,后来换 python,最近一两年又因为试着学 go 换成了 go。所以建议的话:

    能换 go 换 go,天生就是自己调度的协程,只要代码没问题效率就不会低。就跟具体用什么库没关系了。

    如果要用 python 的 tornado/asyncio 的话,建议用 aio-pika 这种库,或者用 aioredis 撸一个,新的 redis 自带 pub sub,不用 pubsub 也可以用 list 或者 sorted set 来做队列。另外就是楼上说的,注意一下别的库的实现,搞不好会给你阻塞一段,遇到这种了就用 ThreadExecutor,我们公司这边 python 的项目就是 patch 了很多同步的库然后自己用。

    node 理论上应该也还好,但是一个是我不熟悉 node,当时不知道为啥用 node 的 redis 会阻塞住,另一个是印象里 node 不开进程线程的话是单线程的。我就不多提这个了
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Privacy   ·   Solana   ·   609 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 58ms · UTC 18:50 · PVG 02:50 · LAX 10:50 · JFK 13:50
    ♥ Do have faith in what you're doing.