Amaran yang Berbunyi Sekali, Bukan Sekali bagi Setiap Pelayan

Salah satu amaran operasi kami, “kredit rendah” untuk aplikasi terbit sesebuah pembina, sepatutnya sampai kepada kami paling banyak sekali sehari. Pada suatu petang, ia tiba lima kali. Puncanya: setiap salinan API kami mengingati amaran mana yang sudah dihantar dalam ingatannya sendiri, jadi dua pelayan menghantarnya dua kali, dan setiap deploy mengosongkan ingatan itu dan membenarkan mereka menghantarnya semula. Corak yang sama menyebabkan satu kerja latar belakang dibuat dua kali. Kedua-duanya kini diselaraskan melalui storan kongsi, dan kedua-duanya gagal dengan cara yang selamat jika storan itu tidak tersedia.

Gejalanya

Mythex menghantar amaran pasukan apabila sesuatu memerlukan perhatian: perkhidmatan terhenti, kerja tersekat, atau baki kredit pembina semakin rendah sedangkan aplikasinya diterbitkan. Setiap amaran mempunyai tetingkap dedupe, iaitu tempoh ketika amaran yang sama hanya dihantar sekali. Bagi amaran kredit rendah, tetingkap itu ialah 24 jam.

Lima salinan amaran yang sama dalam satu petang bermakna tetingkap itu tidak berfungsi. Lebih teruk lagi, ia tiba secara berpasangan, kira-kira 11 minit antara satu sama lain.

Mengapa ia berlaku

Pakej amaran kami menyimpan dedupe dalam memori: jadual “kunci amaran → bila kali terakhir dihantar”, di dalam proses yang sedang berjalan. Itu berfungsi apabila hanya ada satu proses yang tidak pernah dimulakan semula. Pengeluaran tidak memenuhi kedua-dua syarat itu:

• Dua replika API. Pengeluaran menjalankan dua salinan API. Setiap satu mempunyai jadualnya sendiri, jadi setiap satu menghantar amaran sekali. Itulah pasangannya.
• Deploy. Setiap deploy menggantikan kedua-dua replika dengan proses baharu dan jadual kosong. Selepas deploy, amaran itu dihantar semula seolah-olah ia tidak pernah dihantar.

Jurang lebih kurang 11 minit antara dua amaran dalam setiap pasangan datang daripada kerja yang menimbulkan amaran ini. Kerja itu berjalan pada kedua-dua replika dan mengambil kunci, jadi replika bergilir-gilir memenangi kunci itu, dan setiap satu menimbulkan amaran apabila gilirannya tiba.

Ada satu lagi pepijat yang lebih senyap dalam kod yang sama. Untuk mengelakkan jadual itu membesar selamanya, ia membuang entrinya sendiri apabila jumlahnya mencecah 500 kunci, dengan memadam setiap entri yang berusia lebih 15 minit, tanpa mengira tetingkapnya. Di bawah beban, dedupe 24 jam boleh bertahan hanya selama suku jam.

Pembetulannya

Satu rekod kongsi bagi setiap amaran

Sebelum API menghantar amaran, ia kini menuntut kunci dedupe amaran itu dalam Redis, sebuah storan dalam memori bersama yang diakses oleh kedua-dua replika dan tidak dimulakan semula apabila API dimulakan semula. Tuntutan itu ialah satu operasi tunggal: “tetapkan kunci ini hanya jika ia belum wujud, dan tamatkan tempohnya selepas tetingkap”. Replika yang menuntutnya dahulu menghantar amaran; yang satu lagi mendapati kunci itu telah diambil dan diam. Proses baharu selepas deploy masih mendapati kunci itu di situ.

Kunci dan tetingkap datang daripada peraturan yang sama yang digunakan oleh pakej amaran, kini dikongsi antara kedua-duanya, supaya kedua-dua lapisan tidak akan berbeza pendapat tentang apa yang dikira sebagai “amaran yang sama”.

Gagal terbuka, bukan tertutup

Keputusan paling penting ialah apa yang perlu dilakukan apabila Redis tidak dapat dihubungi. Kami memilih untuk tetap menghantar amaran. Jika Redis tidak berfungsi, atau tidak menjawab dalam masa 1.5 saat, amaran tetap dihantar. Amaran berganda ialah bunyi bising. Amaran yang tercicir bermakna seseorang tidak diberitahu.

Amaran paling serius, P0, tidak sekali-kali ditahan oleh dedupe.

Setiap entri mengekalkan tetingkapnya sendiri

Dalam dedupe dalam memori pakej amaran itu sendiri, setiap entri kini menyimpan bila tetingkapnya tamat, dan pembuangan hanya mengeluarkan entri yang tetingkapnya sudah habis. Kunci 24 jam kekal selama 24 jam, tanpa mengira berapa banyak amaran lain yang tiba.

Pepijat yang sama, di tempat lain

Corak yang sama juga telah menggandakan sejumlah kerja latar belakang: satu kerja penyelarasan yang memastikan rekod kami tentang status setiap ruang kerja sepadan dengan penyedia sandbox kami. Setiap lulus menyenaraikan setiap sandbox dalam akaun itu (ribuan dalam pengeluaran, kira-kira lima saat), serta setiap projek yang sedang berjalan atau dijeda. Kedua-dua replika menjalankannya setiap dua minit.

Tulisannya bersifat idempoten, bermakna menjalankannya dua kali memberi keputusan yang sama seperti menjalankannya sekali, jadi tiada yang rosak. Ia hanya dua kali ganda kerja. Kini setiap tetingkap dua minit dituntut dalam Redis dengan cara yang sama seperti meter penggunaan kami sudah menuntut tetingkap mereka, dan hanya replika yang menuntutnya menjalankan lulus itu. Jika Redis tidak dapat dihubungi, lulus itu tetap dijalankan: melakukan kerja dua kali tidak membahayakan, tetapi tidak melakukannya langsung memang membahayakan.

Cara kami mengujinya

Ujian memodelkan persediaan sebenar. Ia memuatkan modul amaran dua kali, sebagai dua “replika” berasingan, menunjuknya kepada satu storan kongsi, menimbulkan amaran yang sama daripada setiap satu, kemudian memuatkan salinan baharu ketiga untuk mewakili “selepas deploy” dan menimbulkannya sekali lagi. Tepat satu amaran dihantar. Ujian lain menyemak bahawa amaran pembina yang berbeza masih dihantar, bahawa P0 dihantar daripada kedua-dua replika, dan bahawa amaran masih dihantar apabila storan tidak tersedia atau melebihi had masa. Pembetulan pembuangan mempunyai ujiannya sendiri: kunci 24 jam kekal selepas 600 amaran lain tiba 20 minit kemudian.

Bagi kerja penyelarasan, dua replika berdetik serentak, ditambah detikan ketiga dalam tetingkap yang sama, menghasilkan satu senarai sahaja.

Apa yang kami pelajari daripadanya

• Keadaan dalam memori adalah bagi setiap proses. Apa sahaja yang mesti benar merentasi pelayan, sama ada “dihantar sekali” atau “dijalankan sekali”, perlu disimpan di tempat yang dikongsi bersama.
• Deploy ialah permulaan semula. Keadaan yang hanya kekal sehingga permulaan semula seterusnya tidak akan kekal sepanjang hari kerja biasa.
• Tentukan cara mana untuk gagal. Bagi amaran, jika storan kongsi tidak tersedia, itu sepatutnya bermakna lebih banyak amaran, bukan lebih sedikit.
• Cari corak, bukan contoh sahaja. Amaran itu ialah kes yang paling bising; kerja penyelarasan yang digandakan ialah pepijat yang sama, yang diam-diam membazirkan kerja.

Tiada satu pun perkara ini kelihatan dari dalam Mythex. Untuk lebih lanjut tentang cara kami memastikan platform kekal stabil, lihat bagaimana kami mengurangkan ralat 502 semasa deploy kepada sifar dan fail swap yang hilang. Jika anda baru mengenali idea menjalankan lebih daripada satu salinan perkhidmatan, panduan kami tentang apa itu pelayan meliputi asasnya.