Bagikan melalui

Mencegah kesalahan pembatasan tarif untuk operasi Azure Cosmos DB for Apache Cassandra

  • Artikel

BERLAKU UNTUK: Cassandra

Biaya semua operasi database dinormalisasi oleh Azure Cosmos DB dan dinyatakan dengan Request Unit (RU). Unit permintaan adalah performa mata uang yang saat ini mengabstraksi sumber daya sistem seperti CPU, IOPS, dan memori yang diperlukan untuk melakukan operasi database yang didukung oleh Azure Cosmos DB.

Operasi Azure Cosmos DB for Apache Cassandra mungkin gagal dengan kesalahan pembatasan tarif (OverloadedException/429) jika melebihi batas throughput tabel (RU). Hal ini dapat ditangani oleh sisi klien seperti yang dijelaskan di sini. Jika kebijakan percobaan ulang klien tidak dapat diimplementasikan untuk menangani kegagalan karena kesalahan pembatasan kecepatan kita dapat menggunakan fitur Server-side retry (SSR) di mana operasi yang melebihi batas throughput tabel akan dicoba kembali secara otomatis setelah penundaan singkat. Ini adalah pengaturan tingkat akun dan berlaku untuk semua spasi Kunci dan Tabel di akun.

Menggunakan portal Azure

  1. Masuk ke portal Azure.

  2. Navigasi ke akun Azure Cosmos DB for Apache Cassandra Anda.

  3. Buka panel Fitur di bawah bagian Setelan.

  4. Pilih Server Side Retry.

  5. Klik Aktifkan untuk mengaktifkan fitur ini untuk semua koleksi di akun Anda.

Cuplikan layar fitur coba lagi sisi server untuk Azure Cosmos DB untuk Apache Cassandra

Menggunakan Azure CLI

  1. Periksa apakah SSR sudah diaktifkan untuk akun Anda:

    az cosmosdb show --name accountname --resource-group resourcegroupname

  2. Aktifkan SSR untuk semua tabel di akun database Anda. Mungkin diperlukan waktu hingga 15 menit untuk menerapkan perubahan ini.

    az cosmosdb update --name accountname --resource-group resourcegroupname --capabilities EnableCassandra DisableRateLimitingResponses

  3. Perintah berikut akan Menonaktifkan server-side retry untuk semua tabel di akun database Anda dengan menghapus DisableRateLimitingResponses dari daftar kemampuan. Mungkin diperlukan waktu hingga 15 menit untuk menerapkan perubahan ini.

    az cosmosdb update --name accountname --resource-group resourcegroupname --capabilities EnableCassandra

Tanya jawab umum

Bagaimana permintaan dicoba ulang?

Permintaan akan dicoba ulang terus menerus (berulang kali) hingga waktu habis 60 detik tercapai. Jika batas waktu tercapai, klien akan menerima kesalahan waktu habis baca atau tulis yang sesuai

Kapan SSR paling bermanfaat?

Server-side retry (SSR) paling bermanfaat saat ada lonjakan tiba-tiba untuk durasi singkat kurang dari 1 menit dengan kesalahan pembatasan dapat dihindari. Jika beban kerja telah meningkat dan akan tetap terus-menerus di atas RU yang ditentukan, SSR tidak akan banyak membantu. Sarannya adalah untuk meningkatkan RU dengan tepat.

Pengaturan sisi klien yang disarankan?

Setelah SSR diaktifkan, aplikasi klien sebaiknya meningkatkan waktu habis baca di luar pengaturan 60 detik coba kembali server. Kami merekomendasikan 90 detik untuk lebih aman.

Contoh Kode Driver3

SocketOptions socketOptions = new SocketOptions()
	.setReadTimeoutMillis(90000);

Contoh Kode Driver4

ProgrammaticDriverConfigLoaderBuilder configBuilder = DriverConfigLoader.programmaticBuilder()
	.withDuration(DefaultDriverOption.REQUEST_TIMEOUT, Duration.ofSeconds(90));

Bagaimana cara memantau efek dari server-side retry (SSR)?

Anda dapat melihat kesalahan pembatasan laju (429) yang dicoba ulang sisi server di panel Metrik Azure Cosmos DB. Kesalahan ini tidak masuk ke klien saat SSR diaktifkan, karena kesalahan tersebut ditangani dan dicoba kembali di sisi server.

Anda dapat mencari entri log yang berisi estimatedDelayFromRateLimitingInMilliseconds di log sumber daya Azure Cosmos DB Anda.

Apakah server-side retry (SSR) akan memengaruhi tingkat konsistensi saya?

Server-side retry tidak memengaruhi tingkat konsistensi. Permintaan dicoba kembali di sisi server jika nilainya dibatasi (Kesalahan 429).

Apakah server-side retry (SSR) memengaruhi semua jenis kesalahan yang mungkin diterima klien saya?

Tidak, server side retry (SSR) hanya memengaruhi kesalahan pembatasan laju (429) dengan mencobanya kembali di sisi server. Fitur ini mencegah Anda dari keharusan menangani kesalahan yang membatasi kecepatan dalam aplikasi klien. Semua kesalahan lainnya akan dikirim ke klien.

Langkah berikutnya

Untuk mempelajari selengkapnya tentang memecahkan masalah kesalahan umum, lihat artikel ini:

Lihat artikel berikut untuk mempelajari provisi throughput di Microsoft Azure Cosmos DB: