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 İletim Denetimi Protokolü (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 dahili olarak en az 20.000 ms olarak varsayılan değerdir.
Daha düşük zaman aşımı değerlerine sahip istekler kabul edilir ancak istemci davranışı garanti değildir. request.timeout.ms en az önerilen değer olan 60000 olduğundan ve session.timeout.ms en az 30000 önerilen değer 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 aldırdığı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ğer en yüksek tolere edilebilir değere eşit olmalıdır. | |
delivery.timeout.ms |
Formüle (request.timeout.ms + linger.ms) * retriesgöre ayarlayın. |
||
compression.type |
none, gzip |
Şu anda yalnızca gzip sıkıştırması desteklenmektedir. |
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 | Varsayılan değer 3000'dir 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 30000 önerilen değer 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 çok düşük ayar olmamalıdır. session.timeout.ms büyük olmalıdır. |
librdkafka yapılandırma özellikleri
Ana librdkafka yapılandırma dosyası (bağlantı), aşağıdaki bölümlerde açıklanan ö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 |
> 0 | Varsayılan değer 2147483647. | |
request.timeout.ms |
30000 .. 60000 | > 20000 | Event Hubs dahili olarak en az 20.000 ms olarak varsayılan değerdir.
librdkafka varsayılan değer 5000'dir ve bu sorun olabilir.
Daha düşük zaman aşımı değerlerine sahip istekler kabul edilir ancak 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, gzip |
Şu anda yalnızca gzip sıkıştırması desteklenmektedir. |
Yalnızca tüketici yapılandırmaları
| Özellik | Önerilen Değerler | İzin Verilen Aralık | Notlar |
|---|---|---|---|
heartbeat.interval.ms |
3000 | Varsayılan değer 3000'dir 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 çok düşük ayar olmamalıdır. session.timeout.ms 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ıları 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 + varsayılan max.request.size kullanıyorsanız, istekleriniz çok büyük olabilir. | Daha önce bahsedilen Java yapılandırmalarına bakın. |
Sonraki adımlar
Tüm Azure hizmetlerinin kotaları ve sınırları için bkz . Azure aboneliği ve hizmet sınırları, kotaları ve kısıtlamaları .