Celery: 브로커 지원으로서 Redis를 더 이상 사용하지 않을 것을 제안합니다. [거부]

현재 셀러리의 대안이 존재합니다(예: huey 및 rq 이는 명시적으로 redis를 브로커로 지원하는 데 중점을 둡니다. 샐러리가 풀렸을 때 아무 것도 없었습니다.

@ask sql 브로커 지원 중단에 대해 어떻게 생각하십니까? 프로덕션에서 sql 데이터베이스를 사용하는 사람들이 많이 있는지 의심됩니다. 그들이 하는 경우에도 실제로 해서는 안됩니다.
우리는 또한 rabbitmq를 배포하는 것이 말 그대로 한 명령 거리에 있다는 것을 의미하는 도커가 있습니다. 더 이상 _그렇게_ 어렵지 않습니다.

나는 RabbitMQ / Redis / SQS / Qpid 이외의 다른 모든 브로커를 포함하여 브로커로서의 SQL에 대한 지원을 중단했습니다. :)

(복제하다)

저는 셀러리 커뮤니티에 그렇게 얽매이는 사람이 아닙니다. 내 $0.02에 관계없이:

• Redis는 정말 인기가 많습니다. Google 트렌드가 대표적이라고 생각한다면 지원되는 다른 모든 브로커 _combined_만큼 인기 가 있습니다.
• 정말 좋은 브로커 _및_ 백엔드가 될 수 있습니다(RabbitMQ도 마찬가지임)
• 대규모 클라우드 공급업체가 완전 관리형 서비스로 고유하게 제공합니다.
• 우리는 Redis를 많이 사용합니다!

유지 관리 문제에 대한 귀하의 의견에 공감할 수 있으며 이러한 종류의 조치는 지속 가능성을 향한 한 걸음입니다. 하지만 당신이 할 수 있는 다른 '절단'이 있습니까?

방정식의 '공급' 측면에서 지역 사회에서 셀러리에 더 많은 기여를 하지 않는 이유가 무엇인지 생각하십니까?
커밋 및 PR을 대충 살펴보면 내가 기여한 몇 개의 오픈 소스 라이브러리와 비교하여 셀러리는 주로 한 사람의 작업임을 알 수 있습니다.

@MaximilianR 나 자신을 위해 말하기:

1. 이것은 걷기에 상당한 규모의 코드베이스입니다.
2. 특히 당신이 다시마와 ayncio의 전문가가 아닌 경우
3. 보고된 문제의 깊이에 대한 직관이 없습니다.

그래도 저는 셀러리를 사용하기 때문에 도움이 될 수 있는 방법이 있으면 기꺼이 도와드리겠습니다.

@MaximilianR , 많은 기여자가 있었지만 확실히 나는 많은 일을 했습니다. 프로젝트가 너무 빨리 성장했고 어느 시점에서 나는 버그를 수정하거나 IRC/email/StackOverflow 등에서 사용자를 지원하는 것 중에서 선택해야 했습니다. 특히 다중 처리 풀 교착 상태 문제와 같은 문제는 집중 코딩에 6개월이 훨씬 넘게 걸렸습니다. 사람들을 멘토링. 그 시점에서 우리는 다운로드에서 거의 RabbitMQ의 크기였지만 8명이 풀타임으로 일하는 곳에서는 나밖에 없었습니다.

절단해야 할 다른 항목이 있을 수 있지만 Redis만큼 시간이 많이 걸리는 작업은 없다고 생각합니다.

amqp/kombu를 완전한 asyncio로 이식하는 작업도 시간을 많이 단축했지만 여러 문제를 해결하는 데 필요했습니다. 그래도 완료되지 않았습니다.

@ask 위의 메시지가 여전히 SQS에 노력을 기울이는 데 관심이 있다는 의미입니까? 여기에 열린 SQS 티켓이 하나만 있다는 것을 알았지만 여전히 문서에 "실험적" 경고가 표시됩니다. SQS의 현재 상태와 향후 요구 사항에 대해 조언해 주시겠습니까?

우리는 프로덕션에서 Celery + SQS를 사용할 것이므로 이를 위해 약간의 노력을 기울일 수는 있지만 SQS가 프로젝트에 대한 장기 계획의 일부가 아닌 경우에는 그런 상황에 빠지고 싶지 않습니다.

@ 위에서

확실히 프로젝트에 최선을 다하지만 Redis 지원이 중단되면 내부적으로 Celery를 제거하도록 확실히 밀어붙일 것입니다. 왜 우리가 RabbitMQ를 사용하지 않을 것인지 알고 싶다면 비공개로 자세히 설명하겠습니다. 하지만 공개적으로 다른 프로젝트를 비난하고 싶지는 않습니다.

관련: Docker에서 개발하는 방식이기 때문에 하나의 명령이라고 제안하면 효과적일 수 있지만 나머지 사람들이 배포하는 방식은 반드시 그런 것은 아닙니다.

@nicksloan SQS는 이제 마스터 문서에서 지원되는 전송으로 나열됩니다. http://docs.celeryproject.org/en/master/getting-started/brokers/index.html

비동기 I/O를 사용하여 SQS 전송을 다시 작성하는 작업은 1000달러가 조금 넘는 후원을 받았습니다.

@scoates Redis 전송은 메시지 읽기에 비동기 I/O를 사용하기 위해 함께 해킹되었지만 게시는 여전히 동기식이기 때문에 더 나쁜 상황에 있습니다. Python redis 라이브러리는 동기식이므로 메시지를 읽는 데에도 여전히 여러 문제가 있으며 작동 방식에 대한 많은 불확실성이 있습니다. 버그는 쉽게 숨길 수 있으며, redis-py 라이브러리에 대한 변경 사항은 우리가 비정통적인 방식으로 사용할 때 급격한 영향을 미칠 수 있습니다.

저는 Redis를 지원하고 싶습니다. 정말 그렇습니다. 나는 RabbitMQ/Pivotal에서 일할 때 Celery가 구현하는 패턴에 대한 Python의 공통 솔루션이 필요하다고 느꼈기 때문에 그것을 위해 싸우고 있었습니다. 그러나 커뮤니티와 그것을 사용하는 회사가 계속 작동하도록 투자하지 않으면 나는 소방을 떠날 것이고 최악의 경우 지금처럼 사람들이 프로젝트를 비판하게 만드는 운송과 관련된 심각한 문제를 해결할 수 없습니다. 이것은 내 삶을 더 비참하게 만들고 사기를 떨어뜨립니다.

이것은 셀러리의 역사를 고려할 때 너무 급진적일 수 있지만 RabbitMQ 대신 Redis만 유지하는 것에 대해 생각해 보셨습니까?

@MaximilianR 고려했지만 제 열정은 메시지 전달과 올바른 분산 시스템 구축에 있습니다. Redis는 아직 메시지 확인을 구현하기 위해 작동하는 BRPOPLPUSH 구현을 제공하지 않았으며 분산 시스템에서 벽시계 시간에 의존하는 것이 불가능하다는 사실을 인정할 수 없다는 사실이 밝혀지면서 더욱 조심스럽습니다. RabbitMQ는 적어도 문제 공간을 심각하게 공격하고 있으며 Kafka 및 NSQ와 같은 다른 플레이어가 있습니다. 많은 라이브러리가 작업 대기열을 간단한 목록 작업으로 취급하고 있지만 Celery가 그 중 하나가 되기를 거부합니다. :)

@scoates : 나는 내가 어떻게 발전하고 있는지에 대해 말하는 것이 아닙니다. 2016년에 "rabbitmq는 배포하기 어렵다"는 말은 말도 안되는 소리였다. 어딘가에 배포하는 것에 대해 아무것도 모른다고 해도 정말 도움이 되는 도커가 있습니다. 잘못된 가정을 하지 마시기 바랍니다.

@ 우리와 함께 확인해주셔서 감사합니다. Celery는 훌륭한 제품이며 귀하(및 커뮤니티)가 가진 제한된 리소스를 고려할 때 핵심 제품에 집중하는 것이 최선의 결정이라고 생각합니다. 호환되지 않는 여러 시스템을 사용하여 동일한 훌륭한 기능을 시도하고 제공하는 것이 얼마나 어려운 일인지 상상할 수 있습니다. 소비자 입장에서는 선택의 폭이 너무 넓어 제품이 복잡해지는 것 같아요. 나는 이것이 아마도 일부 사용자를 화나게 할 것이라고 확신하지만 더 적은 브로커를 고수하는 것이 제품에 대해 올바른 일이라고 생각합니다. AMQP가 표준이고 잘 받아들여지는 프로토콜인 것에 초점을 맞추고 싶습니다. 그리고 rabbitmq가 아주 좋은 구현이라고 생각합니다.

정말 할 일이 많지 않다는 것은 슬픈 일이지만, 모든 운송 수단과 기능을 모두 합치면 일주일에 몇 시간으로 지속 가능하지 않습니다.

Redis 프로토콜은 매우 간단하기 때문에 전송을 완전히 비동기식으로 다시 작성하는 것이 그렇게 어려울 필요는 없습니다. Celery가 모든 Tornado 라이브러리를 지원할 수 있도록 하는 레이어를 만들었습니다. 동일한 레이어를 asyncio 및 Twisted에 대해 만들 수 있으므로 재사용할 수 있는 클라이언트가 있을 수도 있습니다.

Python은 stdlib의 asyncio로 크게 변화하고 있습니다. 우리는 새로운 웹 프레임워크, 새로운 네트워크 라이브러리가 필요하며 거의 전체 생태계가 적응해야 합니다. 더 이상 자체 이벤트 루프를 유지 관리할 필요가 없기 때문에 작업이 조금 더 쉬워지지만 전환에는 약간의 작업이 필요합니다.

또한 여러 언어를 지원하는 새 메시지 프로토콜이 있으므로 Go 또는 이와 유사한 것으로 새 작업자를 작성하고 싶습니다. Redis는 메시지 헤더, 속성 등을 구현하지 않기 때문에 메시징 상호 운용성에 가장 적합하지 않습니다. AMQP 프로토콜은 원래 사용 사례 중 하나였기 때문에 확실히 우위에 있습니다.

@sk 내 접근 방식은 회사가 브로커를 유지하도록 하는 것이었습니다. 그래서 Redis 연구소의 누군가와 이야기를 해보고 우리가 어떤 관심을 끌 수 있는지 보도록 합시다.
MongoDB 및 기타 서비스도 마찬가지입니다.
SQL 브로커의 경우 좋은 생각이 아니며 지원해서는 안 된다고 생각합니다.
코드를 제거하는 대신 추출하여 유지 관리할 사람을 찾을 수 있습니다. 관심이 충분하지 않으면 필요하지 않습니다.
일종의 브로커가 될 수 있는 유일한 SQL 데이터베이스는 Pub/Sub 기능이 있지만 현재 구현되어 있지 않기 때문에 Postgres입니다.

나는 우리가 그것을 비추천하고 무슨 일이 일어나는지 볼 수 있다고 생각합니다. 누군가가 유지 보수를 인수하거나 후원을 통해 이를 위해 단계를 밟을 수도 있습니다. 그렇지 않다면 우리는 사람들이 필요로 하는 제품을 가지고 있지만 아무도 지원하고 싶어하지 않습니다. 이 시점에서 총 18표를 받을 가능성이 있습니다. 나는 그것이 Redis Labs를 단독으로 흔들 것이라고 생각하지 않습니다. :)

그러나 커뮤니티와 그것을 사용하는 회사가 계속 작동하도록 투자하지 않으면 나는 소방을 떠날 것이고 최악의 경우 지금처럼 사람들이 프로젝트를 비판하게 만드는 운송과 관련된 심각한 문제를 해결할 수 없습니다. 이것은 내 삶을 더 비참하게 만들고 사기를 떨어뜨립니다.

우리는 여러 프로젝트에서 redis 브로커와 함께 celery를 사용하고 있으며 그것에 의존하고 있지만 그 의견에 강력히 동의합니다. 높은 수준의 품질을 유지할 수 없다면 샐러리라는 이름을 불리고 모든 사용자를 불행하게 만들 뿐입니다.

안녕하세요. 저는 Redis Labs에서 일하며 최근까지 셀러리 사용자였습니다. @thedrow 가 이 사실을

@dvirsky 와 마찬가지로 Redis에 받으며 , 이 백엔드를 지원할 수 있다면(예를 들어) Redis 측에서 최상의 솔루션을 찾는 데 참여하고 잠재적으로 구현에서 특정 사항을 용이하게 하기 위해 Redis 메시징 지원을 확장합니다. HA 지원 경험을 갖기 위해 어느 시점에서 Sentinel/Redis Cluster를 사용하는 백엔드의 기능을 강조할 수도 있습니다. 현재 필요한 노력을 평가하고 있는 빠른 시일 내에 좋은 소식이 있기를 바랍니다.

이것은 정말 좋은 소식입니다! 나는 당신이 그것에 커밋하기 전에 관련된 작업을 알고 싶어한다는 것을 완전히 이해합니다 :)

지금 여기 새벽 3시이고 문제 목록을 수집하지 않았지만 여기에 몇 가지 짧은 메모가 있습니다.

Celery는 Redis에 대한 인터페이스로 구현되는 기능 세트를 대신 정의하지 않습니다.
AMQP API를 사용하여 일반적인 방식으로 메시징을 사용합니다. 이름-대기열 메시징, 게시/구독 및 주제 라우팅. 토픽 라우팅은 엄격한 요구 사항은 아니지만 나머지는 1) 작업 메시지 처리, 2) 모니터링 이벤트 보내기/받기, 3) 작업자에게 메시지를 전달하여 관리하기(예: 종료/동시성 증가 등)와 같은 Celery의 주요 기능에 중요합니다. ).

1) 작업에 대해 작업자를 차단하지 않도록 비동기화되어야 합니다.

현재 버전은 동기식 redis-py 라이브러리를 사용합니다. 나는 이것을 만들기 위해 해킹했다.
그것은 비동기 방식으로 메시지를 소비하지만 클라이언트에서 무슨 일이 일어나는지 정확히 알지 못하기 때문에 여전히 버그가 있다고 생각합니다. 사용할 수 있는 비동기 redis 클라이언트가 이미 있을 수 있습니다.
우리가 사용할 수 있는 Tornado/asyncio 또는 원시 작업을 많이 할 필요가 없기 때문에 최악의 경우에는 그렇지 않을 수 있습니다.
너무 까다로워.

2) 연결 관리

우리는 작업을 소비하는 하나의 연결과 pubsub를 수행하는 하나의 연결, 그 다음 풀을 가지고 있습니다.
메시지 확인 또는 확인되지 않은 메시지 복원과 같은 대역 외 작업을 수행하기 위한 연결 수 여기서 오류 처리와 관련하여 약간의 혼란이 있으며 사용 후 모든 연결을 닫지 않을 수 있습니다.

3) 메시지 수신확인

메시지는 확인된 후에만 서버에서 제거되며 모든 메시지 소비자가 메시지를 복원하려고 시도하는 가시성 제한 시간이 있습니다. 글쎄, 엉망이야.
나중에 더 자세히 설명할 수 있습니다.

@ask 덕분에 "1" 지점에 대해 외부 라이브러리에 의존하는 대신 브로커 내부에서 직접 보내는 몇 가지 명령에 필요한 최소한의 비동기 Redis 지원을 직접 구현하는 것이 합리적일 수 있습니다.

단 2개, 그리고 일부 다른 작은 문제는 곧 솔루션이 필요할 수 있습니다. 대부분 작동하지만 메시지 승인으로 인해 메시지가 손실될 수 있는 경우가 있지만 승인 에뮬레이션 이전에 상황이 훨씬 더 나빴기 때문에 위시리스트 항목입니다. 작업자는 동기식 Redis 클라이언트에 의해 차단될 수 있으며, 이로 인해 성능이 저하되고 드문 경우에는 작업자가 중단됩니다.

1) 작업에 대해 작업자를 차단하지 않도록 비동기화되어야 합니다.

마지막으로 확인한 결과 비동기 redis 클라이언트는 완벽하지 않았습니다(토네이도에 대한 몇 가지가 있음). 이러한 상황에서 내가 여러 번 수행한 것은 스레드 풀 실행기와 퓨처를 사용하여 redis-py가 비동기 클라이언트처럼 작동하도록 만드는 것이었습니다. 동시 작업이 너무 많지 않고 몇 개의 스레드가 수행하는 한 비동기 클라이언트보다 더 잘 작동합니다.

편집: 나는 아직 파이썬의 asyncio로 직접 작업하지 않았지만, 내가 본 바로는 토네이도와 매우 유사하므로 이 패턴은 아마도 쉽게 할 수 있을 것입니다.

@dvirsky 우리는 또한 fork 를 사용하고 있으므로 스레드를 사용할 수 없습니다. Python은 이 경우를 지원하지 않으며 cpython용 패치가 생성된 경우에도 이러한 방식으로 안전하려면 기존 Python 라이브러리, 최소한 C 확장을 조심스럽게 패치해야 합니다. 이것은 얼마 전에 Python 버그 추적기에서 실현되었으며 이것이 우리가 비동기 I/O로 마이그레이션을 수행한 이유입니다. 또한 핵심 비동기 I/O 지원이 포함된 Python의 미래이기 때문에 일반적으로 그곳으로 이동해야 합니다.

@antirez 다시:

포인트 "1"에 대해 외부 라이브러리에 의존하는 대신 브로커 내부에서 직접 보내는 몇 가지 명령에 필요한 최소한의 비동기 Redis 지원을 직접 구현하는 것이 합리적일 수 있습니다.

나는 그렇게하지 않을 것입니다. redis-py의 대부분의 코드는 명령 구현이 아닌 네트워킹 및 연결 관리를 중심으로 이루어집니다...

@dvirsky 우리는 이를 위해 완벽하게 작동하는 연결 관리 제네릭을 가지고 있으므로 시간을 낭비해서는 안 됩니다. 네트워킹이 많지는 않지만 대부분이 프로토콜을 구문 분석하고 있으며 거의 ​​수동으로 또는 기존 redis 클래스에 연결하여 이미 수행하고 있다고 생각합니다.

@ask 예, redis 프로토콜을 구문 분석하기 위한 전용 C 확장인 hiredis가 있습니다. IIRC는 비동기 클라이언트에서도 작동할 수 있습니다. 지금까지 redis를 비동기화하기 위해 어떤 전략을 선택하셨습니까?

어쨌든 최근 비동기 클라이언트에서 무슨 일이 일어나고 있는지 살펴봐야 합니다. 저는 지난 1년 반 동안 파이썬 작업을 많이 하지 않았습니다. https://github.com/leporo/tornado-redis 가 그다지 활성화되지 않았음을 알 수 있습니다.

전략이 많지 않습니다. 이벤트 루프에 소켓을 추가하고 예를 들어 BRPOP를 동기적으로 보낸 다음 소켓을 읽을 수 있을 때까지 기다렸다가 응답을 동기적으로 읽습니다. ;)

응답을 파싱하는 도중에 다시 시작할 방법이 없기 때문에

@dvirsky 프로토콜 구문 분석 이외의 다른 용도로 hiredis를 사용하는 경우 gevent/eventlet과의 호환성 문제(다중 처리 대신 사용되는 경우)가 발생하고 Celery가 PyPy에서 실행되는 경우 임의의 이식성 문제가 발생하게 됩니다.

@dvirsky 또한 py-hiredis는 현재 프로토콜 구문 분석 이외의 기능을 노출하지 않습니다.

Python은 어느 시점에서 적절한 비동기 redis 클라이언트가 필요할 것이므로 적절한 것을 시작하는 것이 나쁜 생각은 아닙니다. 예를 들어 redis-py에서 일부 프로토콜 구문 분석 코드를 리팩토링합니다.

당신은 지금 gevent를 사용하고 있습니까?

@dvirsky 우리는 비동기 I/O로 gevent, eventlet 및 멀티프로세싱(prefork)을 지원합니다. 그러나 하나를 지원하면 일반적으로 다른 하나를 지원합니다.

예, gevent가 작업에 더 적합한 경우가 있습니다. 예를 들어 태스크가 데이터베이스에 쓰기만 하거나 HTTP 요청을 수행할 때.
gevent에서 FD를 노출하고 등록하는 것은 쉽지만 py-hiredis에서 추가 작업이 필요합니다.

@dvirsky 다음은 https://gist.github.com/GuoJing/5875326
gevent와 협력하려면 FD를 노출해야 합니다.

저는 최근에 Redis에 대한 celery 지원을 둘러싼 문제에 대해 소개받았고 철저한 분석을 완료하지는 않았지만 asyncio를 사용하여 python redis 클라이언트를 작성/업그레이드하는 것이 좋은 생각처럼 들리지만 최근 벤치마크에서는 그게 가장 좋습니다. 가능한 한 많은 성능을 끌어내기 위해 asyncio+libuv 위에 구현되었습니다.

참조를 위해

• https://github.com/MagicStack/uvloop
• https://github.com/saghul/pyuv
• http://magic.io/blog/uvloop-blazing-fast-python-networking/

이 입장에 반대하거나 문제를 복잡하게 만들기 위해 개발자이자 사용자로서 Redis 클라이언트에 대한 제 경험에 따르면 libuv에 전적으로 의존하면 클라이언트가 최대 성능을 달성하는 것을 실제로 방지할 수 있으며 고용은 필수입니다. libuv에는 실제로 어떤 경우에는 io 속도를 늦추는 수많은 일이 있습니다. ioredis는 Node를 통해 이를 수행하지만 실제로는 성능이 좋지 않습니다.

따라서 내가 상상하는 솔루션에는 혼합 고용 비동기 구현이 있습니다. (다르게 말하면 수많은 선택과 벤치마킹을 통해 많은 대안을 시도해야 합니다.)

@merl-dev 문제는 여전히 PyPy입니다. 여기서 hiredis+cffi는 순수한 python 프로토콜 파서 구현보다 redis 프로토콜을 파싱할 때 더 느립니다.
적어도 내 버전에는 redis-py에 대한 몇 가지 테스트 실패가 있습니다. https://github.com/redis/hiredis-py/pull/46 참조

고용된 클라이언트를 CPython 확장으로 작성하는 것은 전적으로 가능합니다. 나는 여전히 CFFI에 대해 100% 확신하지 못합니다.

가서 잡자

@thedrow 이것은 나를 상기시켜줍니다 - 새로운 redis 스트림 기능을

우리는하지 않았다. 현재로서는 redis 브로커를 리팩토링할 수 있는 능력이 없습니다.
우리는 여러분이 그렇게 할 수 있는 여유가 있기를 바랐습니다.

@theedrow 우리는... 아무것도 약속하지 않을 수 있지만 Redis 생태계를 사전에 지원하는 데 더 많은 리소스를 할애할 수 있습니다.

@dvirsky 이 제안을 말씀 하시는 건가요? 따라서 TAPPEND 를 사용하여 대기열에 추가하고 TREAD + TACK 를 사용하여 대기열에서 제거, 처리 및 승인할 수 있습니다.

@georgepsarakis 더 이상 제안이 아니며 작동하며 접두사는 X, 즉 XADD입니다. https://www.youtube.com/watch?v=ELDzy9lCFHQ 참조

그렇다면 redis 브로커 지원에 대한 최종 요청은 무엇입니까? 곧 사용이 중단될 예정입니까?

지금은 아닙니다.

커뮤니티가 어느 쪽으로 기울고 있는지 알 수 없었지만 새로운 프로젝트를 시작하고 있고 Redis를 사용하지 않는다는 생각으로 인해 브로커로 Redis와 함께 가기를 주저합니다. 생각?

redis 브로커가 가까운 장래에 계속 유지될 것이라고 가정하는 것이 안전합니다. 너무 많은 사람들이 그것을 중계합니다.

그 동안 #301 / 601 은 오래되지 않습니다.

@ermik 은 관련 문제에 대해 도움을