Apache Kafka istemcileri için önerilen yapılandırmalar
Apache Kafka istemci uygulamalarından Azure Event Hubs kullanmak için önerilen yapılandırmalar aşağıdadır.
Java istemci yapılandırma özellikleri
Üretici ve tüketici yapılandırmaları
| Özellik | Önerilen değerler | İzin verilen aralık | Notlar |
|---|---|---|---|
metadata.max.age.ms |
180000 (yaklaşık) | < 240000 | Meta veri değişikliklerini daha erken almak için azaltılabilir. |
connections.max.idle.ms |
180000 | < 240000 | Azure gelen TCP boşta > 240.000 ms'yi kapatır ve bu da ölü bağlantıların gönderilmesine neden olabilir (gönderme zaman aşımı nedeniyle süresi dolmuş toplu işlemler olarak gösterilir). |
Yalnızca üretici yapılandırmaları
Üretici yapılandırmaları burada bulunabilir.
| Özellik | Önerilen Değerler | İzin Verilen Aralık | Notlar |
|---|---|---|---|
max.request.size |
1000000 | < 1046528 | 1.046.528 bayttan büyük istekler gönderilirse hizmet bağlantıları kapatır. Bu değer değiştirilmelidir ve yüksek aktarım hızına sahip üretim senaryolarında sorunlara neden olur. |
retries |
> 0 | delivery.timeout.ms değerini artırmayı gerektirebilir, belgelere bakın. | |
request.timeout.ms |
30000 .. 60000 | > 20000 | Event Hubs şirket içinde varsayılan olarak en az 20.000 ms olacaktır. Daha düşük zaman aşımı değerlerine sahip istekler kabul edilse de istemci davranışı garanti değildir... request.timeout.ms en azından önerilen değer olan 60000 olduğundan ve session.timeout.ms en azından önerilen değer olan 30000 olduğundan emin olun. Bu ayarların çok düşük olması tüketici zaman aşımlarına neden olabilir ve bu da yeniden dengelenmelere neden olabilir (daha sonra daha fazla zaman aşımına neden olur, bu da daha fazla yeniden dengelemeye neden olur vb.). |
metadata.max.idle.ms |
180000 | > 5000 | Üreticinin boşta olan bir konu için meta verileri ne kadar süreyle önbelleğe alacağını denetler. Bir konunun son üretilmesinden bu yana geçen süre meta veri boşta kalma süresini aşarsa, konunun meta verileri unutulur ve buna bir sonraki erişim meta veri getirme isteğini zorlar. |
linger.ms |
> 0 | Yüksek aktarım hızı senaryolarında, toplu işlemden yararlanmak için kalan değerin en yüksek toleranslı değere eşit olması gerekir. | |
delivery.timeout.ms |
Formüle (request.timeout.ms + linger.ms) * retriesgöre ayarlayın. |
||
compression.type |
none |
Sıkıştırma şu anda desteklenmiyor.. |
Yalnızca tüketici yapılandırmaları
Tüketici yapılandırmaları burada bulunabilir.
| Özellik | Önerilen Değerler | İzin Verilen Aralık | Notlar |
|---|---|---|---|
heartbeat.interval.ms |
3000 | 3000 varsayılan değerdir ve değiştirilmemelidir. | |
session.timeout.ms |
30000 | 6000 .. 300000 | 30000 ile başlayın, atlanan sinyaller nedeniyle sık yeniden dengeleme görüyorsanız artırın. request.timeout.ms en az önerilen değer olan 60000 olduğundan ve session.timeout.ms en azından önerilen değer olan 30000 olduğundan emin olun. Bu ayarların çok düşük olması tüketici zaman aşımlarına neden olabilir ve bu da yeniden dengelenmelere neden olabilir (daha sonra daha fazla zaman aşımına neden olur, bu da daha fazla yeniden dengelemeye neden olur vb.). |
max.poll.interval.ms |
300000 (varsayılan) | >session.timeout.ms | Yeniden dengeleme zaman aşımı için kullanılır, bu nedenle bu çok düşük ayarlanmamalıdır. session.timeout.ms'den büyük olmalıdır. |
librdkafka yapılandırma özellikleri
Ana librdkafka yapılandırma dosyası (bağlantı), aşağıdaki özellikler için genişletilmiş açıklamalar içerir.
Üretici ve tüketici yapılandırmaları
| Özellik | Önerilen Değerler | İzin Verilen Aralık | Notlar |
|---|---|---|---|
socket.keepalive.enable |
true | Bağlantının boşta olması bekleniyorsa gereklidir. Azure 240.000 ms boşta > gelen TCP'yi kapatır. | |
metadata.max.age.ms |
~ 180000 | < 240000 | Meta veri değişikliklerini daha erken almak için azaltılabilir. |
Yalnızca üretici yapılandırmaları
| Özellik | Önerilen Değerler | İzin Verilen Aralık | Notlar |
|---|---|---|---|
retries |
2 | Varsayılan değer 2147483647. | |
request.timeout.ms |
30000 .. 60000 | > 20000 | Event Hubs şirket içinde varsayılan olarak en az 20.000 ms olacaktır. librdkafka varsayılan değer 5000'dir ve bu da sorunlu olabilir. Daha düşük zaman aşımı değerlerine sahip istekler kabul edilse de istemci davranışı garanti değildir. |
partitioner |
consistent_random |
Librdkafka belgelerine bakın | consistent_random varsayılan ve en iyisidir. Boş ve null anahtarlar çoğu durumda ideal bir şekilde işlenir. |
compression.codec |
none |
Sıkıştırma şu anda desteklenmiyor. |
Yalnızca tüketici yapılandırmaları
| Özellik | Önerilen Değerler | İzin Verilen Aralık | Notlar |
|---|---|---|---|
heartbeat.interval.ms |
3000 | 3000 varsayılan değerdir ve değiştirilmemelidir. | |
session.timeout.ms |
30000 | 6000 .. 300000 | 30000 ile başlayın, atlanan sinyaller nedeniyle sık yeniden dengeleme görüyorsanız artırın. |
max.poll.interval.ms |
300000 (varsayılan) | >session.timeout.ms | Yeniden dengeleme zaman aşımı için kullanılır, bu nedenle bu çok düşük ayarlanmamalıdır. session.timeout.ms'den büyük olmalıdır. |
Diğer notlar
Yapılandırmayla ilgili yaygın hata senaryolarının aşağıdaki tablosunu denetleyin.
| Belirtiler | Sorun | Çözüm |
|---|---|---|
| Yeniden dengeleme nedeniyle işleme hatalarını dengeleme | Tüketiciniz poll() çağrısı arasında çok uzun süre bekliyor ve hizmet tüketiciyi gruptan atıyor. | Birkaç seçeneğiniz vardır:
|
| Yüksek üretim aktarım hızındaki ağ özel durumları | Java istemcisi + default max.request.size kullanıyor musunuz? İstekleriniz çok büyük olabilir. | Yukarıdaki Java yapılandırmalarına bakın. |
Sonraki adımlar
Bkz. Tüm Azure hizmetlerinin kotaları ve sınırları için Azure aboneliği ve hizmet sınırları, kotaları ve kısıtlamaları.