Celery: Proposal untuk menghentikan Redis sebagai dukungan broker. [Ditolak]

Saat ini ada alternatif untuk seledri, misalnya huey dan rq yang secara eksplisit fokus mendukung redis sebagai broker. Saat seledri dirilis, tidak ada apa-apa.

@ask apa pendapat Anda tentang juga menjatuhkan dukungan broker sql? Saya ragu ada banyak orang yang menggunakan database sql dalam produksi. Bahkan jika mereka melakukannya, mereka sebenarnya tidak seharusnya melakukannya.
Kami juga memiliki buruh pelabuhan yang berarti menggunakan rabbitmq secara harfiah hanya satu perintah. Ini tidak _itu_ sulit lagi.

Saya baru saja menghentikan dukungan untuk SQL sebagai broker, termasuk semua broker lain selain RabbitMQ / Redis / SQS / Qpid :)

(duplikat)

Saya tidak terlalu terikat dengan komunitas seledri; terlepas dari $0,02 saya:

• Redis sangat populer - hampir sama populernya dengan semua broker lain yang didukung _combined_ , jika menurut Anda Google Trends representatif
• Ini bisa menjadi broker _and_ backend yang sangat bagus (RabbitMQ juga)
• Ini secara unik ditawarkan oleh vendor cloud besar sebagai layanan yang dikelola sepenuhnya
• Kami banyak menggunakan Redis!

Saya dapat berempati dengan sentimen Anda seputar masalah pemeliharaan, dan tindakan semacam ini merupakan langkah menuju keberlanjutan. Tapi apakah ada 'amputasi' lain yang bisa Anda lakukan?

Di sisi 'penawaran' persamaan, apakah Anda memiliki pemikiran mengapa tidak ada lebih banyak kontribusi untuk seledri dari komunitas?
Pandangan sepintas pada komit & PR menunjukkan bahwa seledri sebagian besar merupakan karya satu orang, dibandingkan dengan beberapa perpustakaan sumber terbuka yang saya sumbangkan

@MaximilianR Berbicara hanya untuk diri saya sendiri:

1. Ini adalah basis kode yang cukup besar untuk dilalui
2. Apalagi jika Anda bukan ahli dalam kombu dan ayncio
3. Dan Anda tidak memiliki intuisi tentang kedalaman masalah yang dilaporkan

Konon, saya memang menggunakan seledri, jadi jika ada cara saya bisa berguna, saya akan dengan senang hati membantu.

@MaximilianR , Ada banyak kontributor, tapi yang pasti saya telah melakukan banyak pekerjaan. Proyek berkembang terlalu cepat, dan pada titik tertentu saya memiliki pilihan antara memperbaiki bug atau mendukung pengguna di IRC/email/StackOverflow dll. Terutama hal-hal seperti masalah kebuntuan kumpulan multiprosesor membutuhkan lebih dari 6 bulan pengkodean terfokus, padahal seharusnya saya membimbing orang. Kami pada saat itu hampir seukuran RabbitMQ dalam unduhan, tetapi di mana mereka memiliki 8 orang yang bekerja penuh waktu, saya adalah satu-satunya.

Mungkin ada hal lain yang harus diamputasi, tapi menurut saya tidak ada yang memakan waktu seperti Redis.

Pekerjaan mem-port amqp/kombu ke asyncio penuh juga menghabiskan banyak waktu, tetapi diperlukan untuk memecahkan sejumlah masalah. Padahal tidak pernah selesai.

@ask Apakah pesan Anda di atas berarti Anda masih tertarik untuk mencoba SQS? Saya perhatikan bahwa hanya ada satu tiket SQS yang terbuka di sini, tetapi saya masih melihat peringatan "Eksperimental" di dokumen. Bisakah Anda memberi saran tentang status saat ini dan kebutuhan SQS di masa mendatang?

Kami akan menggunakan Seledri + SQS dalam produksi, jadi saya mungkin dapat berkontribusi dalam upaya untuk itu, tetapi tidak benar-benar ingin masuk ke situasi itu jika SQS bukan bagian dari rencana jangka panjang Anda untuk proyek tersebut.

@ask terima kasih telah membagikannya di atas. Saya dapat menghargai dari mana Anda berasal. Saya berharap melalui ini / pendekatan lain seledri dapat lebih mudah untuk mempertahankan dan melanjutkan kesuksesannya...

Pasti melakukan yang terbaik untuk proyek Anda, tetapi saya pasti akan mendorong untuk menyingkirkan Celery, secara internal, jika dukungan Redis dijatuhkan. Saya akan menjelaskan secara pribadi jika Anda benar-benar ingin tahu mengapa kami tidak menggunakan RabbitMQ, tetapi saya tidak benar-benar ingin mem-bash proyek lain di depan umum.

Terkait: menyarankan bahwa itu adalah satu perintah karena begitulah cara Anda mengembangkan, di Docker, mungkin berhasil untuk Anda, tetapi itu belum tentu cara kita menerapkannya.

@nicksloan SQS sekarang terdaftar sebagai transport yang didukung di master docs: http://docs.celeryproject.org/en/master/getting-started/brokers/index.html

Pekerjaan untuk menulis ulang transport SQS untuk menggunakan async I/O disponsori sedikit lebih dari $1000.

@scoates Transportasi Redis berada dalam situasi yang lebih buruk karena benar-benar diretas bersama untuk menggunakan async I/O untuk membaca pesan, tetapi penerbitan masih sinkron. Pustaka redis Python sinkron sehingga masih ada banyak tantangan bahkan untuk membaca pesan, dan banyak ketidakpastian tentang cara kerjanya. Bug dapat dengan mudah disembunyikan di sana, dan perubahan apa pun pada pustaka redis-py dapat memiliki efek drastis saat kita menggunakannya dengan cara yang tidak ortodoks.

Saya ingin mendukung Redis, sungguh. Saya memperjuangkannya ketika saya bekerja di RabbitMQ/Pivotal karena saya merasa bahwa kami membutuhkan solusi umum dalam Python untuk pola yang diimplementasikan Celery. Tetapi jika masyarakat dan perusahaan yang menggunakannya tidak berinvestasi untuk menjaganya tetap berfungsi, maka saya akan dibiarkan memadamkan api dan paling buruk seperti sekarang tidak dapat memperbaiki masalah serius dengan transportasi yang menyebabkan orang mengkritik proyek tersebut. Hal ini membuat hidup saya semakin sengsara dan menurunkan moral.

Ini mungkin terlalu radikal mengingat sejarah seledri, tetapi pernahkah Anda berpikir untuk hanya menyimpan Redis di atas RabbitMQ?

@MaximilianR Saya telah mempertimbangkannya, tetapi hasrat saya adalah menyampaikan pesan dan membangun sistem terdistribusi yang benar. Redis belum memberi kami implementasi BRPOPLPUSH yang berfungsi untuk menerapkan pengakuan pesan, dan dengan pengungkapan ketidakmampuan untuk menerima bahwa tidak mungkin mengandalkan waktu jam dinding dalam sistem terdistribusi, fakta dasar, saya lebih waspada. RabbitMQ setidaknya menyerang ruang masalah dengan serius, dan ada pemain lain seperti Kafka dan NSQ. Banyak perpustakaan memperlakukan antrian tugas sebagai operasi daftar sederhana, tetapi saya menolak Celery untuk menjadi salah satunya :)

@scoates : Saya tidak berbicara tentang bagaimana saya berkembang atau sesuatu. Saya mengatakan bahwa mengatakan "rabbitmq sulit untuk digunakan" pada tahun 2016 adalah omong kosong. Bahkan jika Anda tidak tahu apa-apa tentang menyebarkan sesuatu di suatu tempat, ada buruh pelabuhan yang sangat membantu. Tolong, jangan membuat asumsi yang salah.

Terima kasih @ask telah

Sangat menyedihkan bahwa sebenarnya tidak banyak pekerjaan yang harus dilakukan, tetapi ketika Anda menambahkan semuanya ke semua transportasi dan fitur, itu tidak berkelanjutan hanya dengan beberapa jam seminggu.

Karena protokol Redis sangat sederhana, menulis ulang transport agar sepenuhnya asinkron tidak terlalu sulit. Saya telah membuat lapisan yang memungkinkan Celery mendukung pustaka Tornado apa pun, hal yang sama dapat dibuat untuk asyncio dan Twisted, jadi kami bahkan mungkin memiliki klien di luar sana yang dapat kami gunakan kembali.

Python berubah drastis dengan asyncio di stdlib. Kami membutuhkan kerangka kerja web baru, pustaka jaringan baru, dan hampir seluruh ekosistem perlu beradaptasi. Itu membuat pekerjaan kita sedikit lebih mudah karena kita tidak harus terus mempertahankan loop acara kita sendiri lagi, tetapi transisi akan membutuhkan beberapa pekerjaan.

Saya juga ingin menulis pekerja baru di Go atau yang serupa sekarang karena kami memiliki protokol pesan baru dengan dukungan untuk berbagai bahasa. Redis bukan yang paling cocok untuk interoperabilitas pengiriman pesan, karena tidak mengimplementasikan header pesan, properti, dll. Protokol AMQP jelas lebih unggul karena ini adalah salah satu kasus penggunaan asli.

@ask Pendekatan saya adalah mencoba membuat perusahaan mempertahankan broker mereka. Jadi mari kita coba berbicara dengan seseorang dari lab Redis dan melihat apakah kita mendapatkan daya tarik.
Hal yang sama untuk MongoDB dan layanan lainnya.
Adapun broker SQL, saya pikir itu bukan ide yang bagus dan kita tidak boleh mendukung mereka.
Kami dapat mengekstrak kode alih-alih menghapusnya, dan mencari seseorang untuk memeliharanya. Jika tidak ada cukup minat, maka tidak perlu bagi mereka.
Satu-satunya database SQL yang bisa menjadi broker adalah Postgres karena memiliki kemampuan Pub/Sub tetapi saat ini belum diimplementasikan.

Saya pikir kita bisa mencelanya dan melihat apa yang terjadi. Mungkin seseorang melangkah untuk itu, dengan mengambil alih pemeliharaan, atau dengan sponsor. Jika tidak, kami memiliki produk yang dibutuhkan orang, tetapi tidak ada yang mau mendukung, yang kemungkinan dengan total 18 suara saat ini. Saya tidak berpikir itu akan mempengaruhi Redis Labs sendirian :)

Tetapi jika masyarakat dan perusahaan yang menggunakannya tidak berinvestasi untuk menjaganya tetap berfungsi, maka saya akan dibiarkan memadamkan api dan paling buruk seperti sekarang tidak dapat memperbaiki masalah serius dengan transportasi yang menyebabkan orang mengkritik proyek tersebut. Hal ini membuat hidup saya semakin sengsara dan menurunkan moral.

Kami menggunakan seledri dengan broker redis di beberapa proyek dan bergantung padanya, tapi saya sangat setuju dengan sentimen itu. Jika Anda tidak dapat mempertahankannya pada kualitas tingkat tinggi, itu hanya akan memberi nama buruk pada seledri dan membuat semua orang tidak senang – Anda _dan_ pengguna.

Hai. Saya bekerja untuk Redis Labs dan sampai saat ini saya adalah pengguna seledri. @thedrow membawa ini ke perhatian saya, dan kami telah membahas ini secara internal. Kami bersedia membantu kalian, kami pikir menjaga redis sebagai bagian dari seledri itu penting. Saya belum yakin apakah saya akan melakukannya secara pribadi atau orang lain, tetapi mari kita diskusikan tentang apa yang perlu dilakukan.

Seperti @dvirsky , pekerjaan saya di Redis sepenuhnya disponsori oleh Redis Labs, dan jika kami dapat membantu dengan backend ini (semoga ya) saya akan terlibat dalam membantu menemukan solusi terbaik di sisi Redis, dan bahkan berpotensi memperluas dukungan pesan Redis untuk memfasilitasi hal-hal tertentu dalam implementasinya. Kami juga dapat menekankan kemampuan backend untuk menggunakan Sentinel / Redis Cluster di beberapa titik agar memiliki pengalaman HA-ready. Saya harap kita akan mendapat kabar baik secepatnya, saat ini sedang mengevaluasi upaya yang diperlukan.

Ini benar-benar berita bagus! Saya benar-benar mengerti Anda ingin tahu pekerjaan yang terlibat sebelum berkomitmen untuk itu :)

Sekarang jam 3 pagi di sini, dan saya belum mengumpulkan daftar masalah tetapi berikut adalah beberapa catatan singkat:

Celery tidak mendefinisikan serangkaian fitur yang diimplementasikan dengan antarmuka ke Redis, sebagai gantinya
ia menggunakan API AMQP untuk menggunakan perpesanan dengan cara yang umum. Perpesanan nama-ke-antrean, pub/sub, dan perutean topik. Perutean topik bukanlah persyaratan yang ketat tetapi sisanya sangat penting untuk fitur utama Celery dalam 1) menangani pesan tugas, 2) mengirim/menerima peristiwa pemantauan, dan 3) menyiarkan pesan ke pekerja untuk mengelolanya (mis. mematikan/meningkatkan konkurensi/dll. ).

1) Harus asinkron sehingga tidak memblokir pekerja untuk operasi apa pun

Versi saat ini menggunakan pustaka redis-py, yang sinkron. Saya telah meretas ini untuk membuat
itu mengkonsumsi pesan secara async, tapi saya curiga masih ada bug di sana karena kami tidak tahu persis apa yang terjadi di klien. Mungkin sudah ada klien redis async yang tersedia untuk
Tornado/asyncio yang bisa kita gunakan, atau kasus terburuk karena kita tidak perlu banyak melakukannya mentah mungkin tidak
menjadi begitu rumit.

2) Manajemen koneksi

Kami memiliki satu tugas yang menggunakan koneksi, dan satu koneksi melakukan pubsub, lalu kumpulan
koneksi untuk melakukan operasi out-of-band, seperti mengakui pesan atau memulihkan pesan yang tidak diakui. Ada beberapa kebingungan seputar penanganan kesalahan di sini, dan kami mungkin tidak menutup semua koneksi setelah digunakan.

3) Pengakuan pesan

Pesan hanya dihapus dari server setelah di-ack dan kami memiliki batas waktu visibilitas di mana semua konsumen pesan mencoba memulihkan pesan. Nah itu berantakan,
Saya dapat menjelaskan ini secara lebih rinci nanti.

Terima kasih @ask , tentang poin "1" mungkin masuk akal untuk langsung menerapkan dukungan Redis async minimal yang kami butuhkan untuk beberapa perintah yang kami kirim langsung di dalam broker alih-alih bergantung pada lib eksternal.

Perhatikan bahwa hanya 2, dan mungkin beberapa masalah kecil lainnya memerlukan solusi segera. Ini sebagian besar berfungsi, tetapi ada kasus ketika pesan dapat hilang karena pengakuan pesan tetapi itu adalah item daftar keinginan karena situasinya jauh lebih buruk sebelum emulasi ack. Pekerja dapat diblokir oleh klien Redis sinkron, yang menyebabkan kinerja buruk, dan dalam beberapa kasus yang jarang terjadi, menggantung pekerja.

1) Harus asinkron sehingga tidak memblokir pekerja untuk operasi apa pun

Terakhir saya periksa, klien async redis tidak sempurna (ada beberapa untuk tornado). Apa yang saya lakukan dalam situasi ini berkali-kali adalah menggunakan pelaksana kumpulan utas dan masa depan untuk membuat redis-py berperilaku seperti klien async. selama Anda tidak memiliki terlalu banyak tugas bersamaan dan beberapa utas akan melakukannya, itu berfungsi lebih baik daripada klien async.

EDIT: Saya belum bekerja dengan asyncio python secara langsung, tetapi dari apa yang saya lihat itu sangat mirip dengan tornado sehingga pola ini mungkin akan mudah dilakukan.

@dvirsky Kami tidak diperbolehkan menggunakan utas, karena kami juga menggunakan fork . Python tidak mendukung kasus ini, dan bahkan jika tambalan dibuat untuk cpython, kita harus dengan hati-hati menambal pustaka python yang ada, setidaknya ekstensi C, agar aman dengan cara ini. Ini direalisasikan pada pelacak bug Python beberapa waktu lalu, dan itulah sebabnya kami telah melakukan migrasi ke async I/O. Kita juga perlu pindah ke sana secara umum, karena itu adalah masa depan Python sekarang dengan dukungan core async I/O.

@antirez kembali:

tentang poin "1" mungkin masuk akal untuk langsung menerapkan dukungan Redis async minimal yang kami butuhkan untuk beberapa perintah yang kami kirim langsung di dalam broker alih-alih bergantung pada lib eksternal.

Saya tidak akan melakukan itu. sebagian besar kode redis-py berkisar pada jaringan dan manajemen koneksi, bukan di sekitar penerapan perintah ...

@dvirsky Kami memiliki generik manajemen koneksi yang akan bekerja dengan sempurna untuk itu, sehingga tidak boleh tenggelam. Jaringan yang kami miliki tidak banyak, tetapi saya pikir sebagian besar adalah menguraikan protokol dan kami sudah melakukannya secara manual atau menghubungkan ke kelas redis yang ada.

@ tanya ya ada yang disewa yang merupakan ekstensi C khusus untuk mem-parsing protokol redis, IIRC juga dapat bekerja dengan klien async. strategi apa yang Anda pilih selama ini dalam membuat redis async?

lagi pula saya perlu melihat apa yang terjadi dengan klien async baru-baru ini, saya belum melakukan banyak pekerjaan python dalam satu setengah tahun terakhir. Saya melihat bahwa https://github.com/leporo/tornado-redis belum terlalu aktif.

Tidak banyak strategi, kami menambahkan soket ke loop acara dan mengirim misalnya BRPOP secara sinkron, kemudian kami menunggu soket dapat dibaca dan kami membaca respons secara sinkron;)

Karena kami tidak memiliki cara untuk memulai kembali di tengah parsing respons

@dvirsky Jika kami menggunakan hireis untuk apa pun selain penguraian protokol, kami akan memiliki masalah kompatibilitas dengan gevent/eventlet (ketika digunakan sebagai ganti multiprosesor) dan itu juga akan mewajibkan hireis yang merupakan masalah portabilitas jika Celery dijalankan di PyPy.

@dvirsky Juga py-hiredis tidak mengekspos fungsionalitas apa pun selain penguraian protokol saat ini.

Python akan membutuhkan klien redis async yang layak di beberapa titik saya percaya, jadi memulai sesuatu yang tepat bukanlah ide yang buruk. Misalnya refactoring beberapa kode parsing protokol di redis-py.

Anda menggunakan gevent sekarang?

@dvirsky Kami mendukung gevent, eventlet dan multiprocessing (prefork) dengan async I/O. Tetapi jika Anda mendukung satu, Anda biasanya memiliki yang lain.

Ya, ada kalanya gevent lebih cocok untuk tugas. misalnya ketika tugas hanya menulis ke database atau melakukan permintaan HTTP.
Cukup mudah untuk mengekspos dan mendaftarkan FD di gevent tetapi itu membutuhkan pekerjaan lebih lanjut di py-hiredis.

@dvirsky Berikut ini contoh cara melakukannya dengan PyCurl. https://Gist.github.com/GuoJing/5875326
Anda perlu mengekspos FD untuk berkolaborasi dengan gevent.

Saya baru-baru ini diperkenalkan dengan masalah seputar dukungan seledri untuk Redis dan sementara saya belum menyelesaikan analisis menyeluruh, saya dapat mengatakan bahwa menulis/memutakhirkan klien python redis dengan asyncio terdengar seperti ide yang bagus, tetapi dari tolok ukur baru-baru ini, itu akan menjadi yang terbaik diimplementasikan di atas asyncio+libuv untuk memeras kinerja sebanyak mungkin.

Untuk referensi lihat

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

Terhadap posisi ini - atau untuk memperumit masalah, saya akan mencatat bahwa dari pengalaman saya sendiri dengan klien Redis, sebagai pengembang dan pengguna, mengandalkan sepenuhnya pada libuv sebenarnya akan mencegah klien mencapai kinerja maksimal, dan untuk itu disewa adalah suatu keharusan. Ada banyak hal yang terjadi di bawah kap di libuv yang sebenarnya memperlambat io dalam beberapa kasus, ioredis melakukannya melalui Node dan itu tidak benar-benar berkinerja.

Jadi solusi yang saya bayangkan memiliki implementasi campuran yang disewakan-async. (Dinyatakan secara berbeda, banyak alternatif perlu dicoba dengan banyak pemetikan ceri dan pembandingan)

@merl-dev Masalahnya masih PyPy di ​​mana hireis+cffi lebih lambat dalam mem-parsing protokol redis daripada implementasi parser protokol python murni.
Setidaknya versi saya juga memiliki beberapa kegagalan pengujian dengan redis-py. Lihat https://github.com/redis/hiredis-py/pull/46

Sangat mungkin untuk menulis klien yang disewa sebagai ekstensi CPython. Saya masih belum 100% yakin tentang CFFI.

Ayo kita mulai

@thedrow ini mengingatkan saya -

Kami belum. Kami tidak memiliki kapasitas untuk memperbaiki broker redis saat ini.
Kami berharap kalian punya tangan cadangan untuk melakukannya.

@thedrow kami mungkin... tidak menjanjikan apa pun, tetapi kami mungkin mendedikasikan lebih banyak sumber daya untuk mendukung ekosistem redis secara proaktif.

@dvirsky maksud Anda proposal ini, kan? Jadi Anda bisa menggunakan TAPPEND untuk enqueue, TREAD + TACK untuk dequeue, memproses dan mengakui.

@georgepsarakis itu bukan lagi proposal, ini berfungsi, dan awalannya adalah X, yaitu XADD. lihat https://www.youtube.com/watch?v=ELDzy9lCFHQ

Jadi apa panggilan terakhir untuk mendukung broker redis? Apakah akan ditinggalkan dalam waktu dekat?

Tidak saat ini.

Saya tidak tahu ke arah mana komunitas itu condong tetapi kami memulai proyek baru dan saya ragu untuk pergi dengan Redis sebagai broker karena pemikiran untuk tidak menggunakannya. Pikiran?

Aman untuk berasumsi bahwa broker redis akan bertahan di masa mendatang. Terlalu banyak orang yang menyampaikannya.

Sementara #301 / 601 akan basi.

@ermik mencoba membantu untuk memahami masalah terkait.