---
title: "Geyser gRPC - En İyi Uygulamalar"
description: "Üretim düzeyindeki Geyser gRPC istemcileri için ping/pong, yeniden bağlanma ve filtreler dahil temel ipuçları. Solana Stream SDK, Geyser gRPC'yi destekler."
canonical: "https://erpc.global/tr/doc/geyser-grpc/best-practices/"
locale: "tr"
---

# Geyser gRPC - En İyi Uygulamalar

Bu kılavuz, Geyser gRPC ile sağlam ve üretime hazır uygulamalar geliştirmek için temel kalıpları ele alır. Solana Stream SDK, Geyser gRPC'yi destekler.

## Başlarken

- Basit başlayın: karmaşık filtreler eklemeden önce akışa alışmak için slot abonelikleriyle başlayın.  
- Filtreleri akıllıca kullanın: bant genişliğini/CPU'yu azaltmak için yalnızca ihtiyacınız olana abone olun.

```rust
SubscribeRequestFilterTransactions {
    vote: Some(false),   // Exclude vote txs
    failed: Some(false), // Exclude failed txs
    ..Default::default()
}
```

## Bağlantı yönetimi

- Otomatik yeniden bağlanma: ağ sorunlarını bekleyin; üstel geri çekilme (exponential backoff) ile yeniden bağlanın.  
- Ping/pong işleme: Yellowstone gRPC sunucuları ping gönderir. Her zaman pong ile yanıt verin; aksi halde sunucu bağlantıyı kapatabilir (~30 saniyelik kopmaların yaygın nedeni).  

```rust
if matches!(update.update_oneof, Some(UpdateOneof::Ping(_))) {
    subscribe_tx.send(SubscribeRequest {
        ping: Some(SubscribeRequestPing { id: 1 }),
        ..Default::default()
    }).await?;
}
```

- Boşluk kurtarma: veri kaybını önlemek için yeniden bağlandıktan sonra `from_slot` kullanın (yinelenen veriler kabul edilebilir).

```rust
subscribe_request.from_slot = if tracked_slot > 0 {
    Some(tracked_slot) // Optionally subtract a small buffer to dodge reorgs
} else {
    None
};
```

## Mimari kalıpları

- Ağ IO'sunu iş mantığından ayırmak ve geri basınç (backpressure) eklemek için veri alımını ve işlemeyi kanallarla ayırın.

```rust
let (tx, rx) = mpsc::channel::<SubscribeUpdate>(10_000);
// ingress task reads stream and tx.send(...)
// processing task consumes rx and does business logic
```

- Sınırlı kanallar kullanın: kapasiteyi işleme hızına ve veri kaybı toleransına göre seçin (daha küçük = daha az bellek, daha fazla düşen güncelleme; daha büyük = daha fazla bellek, daha az düşen güncelleme).

## Performans ve dayanıklılık

- İşleme gecikmesini izleyin ve eşikler aşıldığında log kaydı tutun.  
- Veritabanı yazmalarını toplu yapın; toplu iş boyutuna veya zaman aralığına göre boşaltın.  
- Harici çağrılar için asenkron IO kullanın; ağır hesaplamaları worker görevlerine/iş parçacıklarına devredin.  
- Bellek ayırmalarını azaltmak için abonelik isteklerini yeniden kullanın.

## Hata işleme

- Hata türlerini birbirinden ayırın (stream, işleme ve kanal hataları).  
- Geçersiz bir isteği yeniden denemeden önce düzeltin; duraklatmayı dikkate alan üstel geri çekilmeyi yalnızca yanıt yeniden denemeyi gerektirdiğinde kullanın.
- Yavaş tüketici durumlarını izlemek için düşen güncellemeleri log'a ve metriklere kaydedin.

## Yeniden denemeden önce düzeltme ve duraklatmayı dikkate alan geri çekilme

İlk gRPC hatasını, yeniden bağlanma döngüsü onun üzerine yazmadan önce saklayın. Hatanın durumunu ve mesajını, ayrıca mevcutsa `x-erpc-error-code`, `x-erpc-error-reason`, `x-erpc-doc-url`, `x-erpc-retry-after-seconds` ve `x-erpc-retry-at` metadata değerlerini kaydedin. Erken kapanan bir bağlantı genel bir taşıma hatası gibi görünebilir; bu nedenle her trailer'ı içermeyebilir.

Geçersiz bir isteği, reddedilen bir filtre yapısını veya IP kaydı uyuşmazlığını yeniden denemeden önce düzeltin. ERPC duraklatmasında, dönen bitiş zamanına kadar bekleyin; bu, yerel bir geri çekilmeden daha belirleyicidir. Erişilebilirlik hataları ve yeniden denenebilir diğer yanıtlar için üst sınırı olan üstel geri çekilme kullanın. Değiştirilmemiş bir isteği yalnızca sıfır dışında bir durum döndürdü diye tekrar tekrar yeniden denemeyin.

## Kaynak kullanımı ve işleme kapasitesi

Paylaşılan korumalar, tek bir iş yükünün diğer ERPC müşterilerinin ihtiyaç duyduğu teslimat kapasitesini tüketmesini önler. Bir stream; etkin bant genişliği, CPU, bellek, tüketici kuyruğu, veritabanı yazmaları veya harici çağrılar nedeniyle yavaşlayabilir. Kaynaklar iş yüküne yetecek düzeyde olmalıdır; yavaş bir alıcı, tek başına hangi bileşenin darboğaz olduğunu göstermez.

Tüketici tarafındaki en yüksek veri hızını ölçün. MB/s değerini `MB/s × 8` ile Mbps'ye çevirin, ardından ölçülen en yüksek değerin üzerinde pay bırakın. Ölçülmeden belirlenmiş sabit bir minimum yoktur. Alma işini kısa tutun, güncellemeleri sınırlı bir kuyruğa aktarın ve işleme yetişemiyorsa ölçeği büyütün ya da aboneliği daraltın. Sınırlı bir kuyruk bellek kullanımını sınırlar; sürekli yavaş kalan bir tüketiciyi ise çözmez.

## Veri yönetimi

- `from_slot` kullanırken yinelenen verileri işleyin (süre sınırlı önbellek veya veritabanı kısıtlamaları).  
- Kullanım senaryosuna göre commitment seçin:  
  - processed: en hızlı dashboard'lar için; geri alınabilir  
  - confirmed: çoğu uygulama/indexer için iyi bir varsayılan  
  - finalized: mutlak kesinlik gerektiğinde

## Dinamik abonelikler

Yeniden bağlanmadan abonelikleri çalışma anında güncellemek için çift yönlü stream'i kullanın (filtreleri anında değiştirme, kapsamı genişletme).

## Üretim kontrol listesi

- ✅ Üstel geri çekilmeyle otomatik yeniden bağlanma  
- ✅ `from_slot` ile boşluk kurtarma  
- ✅ Ping/pong işleme (30 saniyelik kopmaları önleme)  
- ✅ Sınırlı kanallar/geri basınçla veri alımını ve işlemeyi ayırma  
- ✅ Hata log'ları ve metrikler/uyarılar  
- ✅ İşleme gecikmesi takibi  
- ✅ Yinelenen veri işleme ve filtre optimizasyonu  
- ✅ Toplu yazmalar (veri kalıcı olarak saklanıyorsa)  
- ✅ Düzgün kapatma ve sağlık kontrolleri

## Ek kaynaklar

- Solana Stream SDK (Geyser gRPC desteği): https://github.com/ValidatorsDAO/solana-stream