Sunum içinde geçen ClickStream Projesi için örnek anlatım https://medium.com/@volkana/gerçek-zamanlı-analiz-projesi-51dc6771dca0

1. PUB/SUB
@volkanaltan DevNote, 30 Kasım 2018
Apache Kafka® is a distributed streaming platform
Mesajlaşma

2. AJANDA
• Publish/subscribe temelleri
• RabbitMQ temelleri
• Apacke Kafka mimarisi
• Hangi araç ne zaman kullanılır?
• Örnek proje: Clickstream / Event projesi

3. NEDEN?
Kaynak: dotnetKonf 2018
• Senkron acılar son bulsun
• Beklemeye son
• ?

4. TARİH
Kaynak: RabbitMQ In Action

5. PUB/SUB NEDİR?
• Pub/Sub, ölçeklenebilir ve gevşek birleşmiş sistemlerin dağıtımına
iyi uyarlanmış bir dağıtık etkileşim modelidir

6. (CORE FUNCTİONALİTİES)
TEMEL FONKSİYONLAR
• Entity decoupling (Varlık ayrımı)
Yayıncılar (publishers) ve tüketiciler (consumers) birbirlerinin farkında
olmalarına gerek yoktur. Pub/Sub altyapısı ortadaki etkileşimi kaldırır.
• Time decoupling (Zaman ayrıştırması)
Pub/Sub’ın (tarafların) etkileşime aktif olarak katılmasına veya aynı
anda aktif olmalarına gerek yoktur.
• Synchronization decoupling (Senkronizasyon ayrışması)
Producer (üretici) veya Consumer (tüketici) ile pub/sub altyapısı
arasındaki etkileşimin, üretici veya tüketici thread lerini eşzamanlı
olarak engellemesi gerekmez. Bu da işlemci kaynaklarının maksimum
kullanımını olanak tanır.

7. TEMEL FONKSİYONLAR
• Topic based
Bu abonelik modelinde publisher mesajı statik olarak etiketler, daha sonra hangi iletinin hangi
tüketiciye gittiğine karar veren filtreleme işleminde çok verimli bir şekilde kullanılabilir. Çoğu
sistem topic adlarında wilcard kullanılmasına izin vermektedir. Bu da filtreleme yeteneklerini
artırır ama işlemci maliyeti artar.
• Content based
Etiketleme için producer’e ihtiyaç duymaz, İletideki tüm veri ve meta verileri filtreleme için
kullanılabilir. Filtreler genellikle name-value çiftlerinden oluşur temel karşılaştırma operatörleri
kullanılabilir (AND, OR, vs.) Bu karmaşık filtreler, yüksek bir işlemci maliyeti getirir.
Pub/sub sistemlerin bir diğer temel işlevi, bir üreticiden gelen bir
paketin tüketiciye ulaşıp ulaşmayacağına karar veren yönlendirme
mantığıdır (routing logic), bu abonelik modeli olarak da bilinir. Farklı
olaylar karşısında gidilecek yollar, performansla ilgili bir çok abonelik
şemalarının doğmasına neden olmuştur. İki ana routing logic

8. QUALİTY-OF-SERVİCE GARANTİSİ
Önceki slide da bahsi geçen pub/sub sistemin temel fonksiyonlarına
ek olarak, gerekli ve istenen garantiler olarak tanımlanır.
Basit olması açısından en önemli pub/sub QoS garantilerini beş ayrı
kategoride ele alacağız. Bu bölümde önemli bir varsayım modern
pub/sub sisteminin distributed (dağıtık) olmasıdır. Scalability
(ölçeklenebilirlik) için dağıtık olma gereklidir ama aynı zamanda tek
başına yeterli değil. Dağıtık depolamanın implementasyonu
beraberinde bir takım teknik sorunları getiriyor.

9. CORRECTNESS (DOĞRULUK)
QUALİTY-OF-SERVİCE
• at most once (“best effort”: no duplicates)
Bu modda normal çalışma koşulları altında paketler teslim edilir.
Başarısızlık durumunda paket kaybı söz konusu, bunun üstünde bir
çabayla yapılacak kontrol verimi düşürür. Bu nedenle en iyi moddur.
• at least once (no-loss )
Bu modda sistem paketlerin kaybolmadığından emin olur. Başarısızlık
durumunda peketin birden fazla kez gönderilmesine neden olabilir.
• exactly once (no-loss ve no-duplicates)
Uçtan uca bir taahhüt gerektirir. Bu nedenle maliyetlidir.
Delivery Guarantees

10. CORRECTNESS (DOĞRULUK)
QUALİTY-OF-SERVİCE
• no ordering
Sıra garantisi olmaması performans için ideal bir durumdur.
• partitioned ordering
Bu modda, sırayla tüketilmesi gereken her ileti akışı için tek bir
bölüm(partition) tanımlanabilir. Üstteki gruba göre daha
maliyetlidir.
• global order
Senkronizasyon yükü nedeniyle farklı kanallar arasında global
order garantisi vermek önemli ek kaynaklar gerektirir. Aynı
zamanda ciddi performans kayıpları söz konusudur.
Ordering Guarantees

11. QUALİTY-OF-SERVİCE
• Dağıtık bir sistemin bir veya birkaçı donanım bileşeni yazılımı başarısız olsa bile hizmetlerini sunma
yeteneğini gösterir.
Reliability(Güvenilirlik)
• Sistemin ayakta olma (uptime) kapasitesini en üst düzeye çıkarma kavramıdır.
Availability (Erişilebilirlik)
• Mesajlaşma sistemlerinde, transactionlar, iletileri atomik unit (birimler) halinde
gruplandırmak için kullanılır. Birimler için tam bir ileti disizi gönderilir (alınır) veya
hiçbiri gönderilmez. Örnek olarak, birkaç anlamsal olarak ilişkili mesaj
yayınlayan (produce) bir üretici emisyon sırasında başarısız olursa, tüketicilerin
(consumer) kısmı tutarsız verileri görmesini istemeyebilir.
Benzer şekilde, görev açısından kritik bir uygulama, bir veya birkaç ileti consume
etmek, işlemek ve sonrasında commitlemek isteyebilir. Eğer consumer
committen önce başarasız olursa, recovery sonrası bütün mesajlar kullanılabilir
olur.
Transactions (İşlemler)

12. QUALİTY-OF-SERVİCE
• Ölçeklenebilirlik kavramı, bir sistemin giderek artan miktarda
görevi desteklemek için sürekli gelişebilme yeteneğini ifade eder.
Bu durumda pub/sub sistemi için scalability birden fazla boyuta
sahiptir. Bunlar, consumers/producers, topics ve mesajlar.
Scalability (Ölçeklenebilirlik)
• Verimlilik. İki yaygın verimlilik ölçüsü gecikme süresi (veya yanıt
süresi) ve (throughput) işlem hacmi (veya bant genişliği) 'dir
Efficiency (Verimlilik):

13. GÖZDEN GEÇİRME
• Pub / Sub mesajlaşma, geliştiricilerin oldukça işlevsel ve mimari açıdan karmaşık uygulamalar oluşturmasını
kolaylaştırır.
• Pub / Sub ile, yayıncılar ve aboneler ayrıştırılır ve birbirlerinin varlığından habersizdirler.
• Aboneler belirli konulara ilgi gösterir ve yayıncılar bir konuya mesaj gönderir.
• Mesaj daha sonra derhal tüm abonelere teslim edilir veya topic’e gönderilir.
• Mesaj ve mesaj boyutu ne olacak?
• Araçlar neler olacak?

14. RABBİTMQ
• RabbitMQ, yüksek performanslı kurumsal mesajlaşma için ortaya çıkan
standart olarak AMQP protokolünü kullanan güçlü ve ölçeklendirilebilir
bir yapıdır.
• Açık kaynak, Güzel döküman, Lightweight (docker image 125 MB)
• Birden fazla protokolü destekler (Direk veya plugin ler üzerinden)
STOMP, MQTT, AMQP
• Çok sayıda dil için destek (Java, Node.js, Erlang, PHP, Ruby vs..)
• Erlang ile yazılmıştır

15. RABBİTMQ

16. APACHE
• ZooKeeper kullanır
• Mesaj Bus değildir ama onun her işini yapar
• Akan datayı sorunlara karşı dayanaklı bir şekilde saklar
• Akan datayı oluştuğu anda işleme imkanı verir
Apache Kafka® is a distributed streaming platform

17. CORE APIS
KAVRAMLAR
• Producer (Verinin Kafka
Cluster'a ulaşmasını sağlar)
• Consumer (Kafka Cluster
üzerinden verileri çeker)
• Connector (Herhangi data
kaynağından okuyup Kafka'ya
gönderilmesini sağlar)
• Streams (Sınırsız ve sürekli
akan datada işlem yapma
olanağı sağlar)

18. PRODUCER
• Her bir mesajın topic'e maplenmesini ve lider partitiona
yazılmasını sağlar. Özel bir ayara ihtiyaç duymaz default olarak
sadece lead partition'a yazıp bırakır.
• Mesajlar Batch (toplu) olarak gönderilebilir,
• Sıralama gönderdiğiniz şekilde gider ancak yazamazsa tekrar et
gibi özel ayar girilirse hangi denemede yazacağı bilinmediğinden
sıra değişmiş olabilir. Default kapalıdır.

19. CONSUMER
• Özel ayarlara ihtiyaç duyar
• Her bir consumer Group id verilerek bir grup hâline getirilir. Gruba
giren çıkan consumer oldukça partition sahiplik ataması yeniden
yapılır. Bunu Broker lardan biri Group koordinatörlüğü ile yapar.
Böylece partitionlar eşit bir şekilde dağıtılır. Buna rebalancing
deniyor.
• Yeni bir Group ID oluşturulursa partitionlardaki data tüketimi ilk
mesajdan değil o andan başlar. Her grubun koordinatörü işlenmiş
offsetleri saklamak için dahili __consumer_offsets den seçilir

20. CONNECTOR VE STREAMS
• Herhangi bir data kaynağından (Solr, Db, Redis) data stream edip
istenilen başka bir şeye istenilen hızda atmayı tek satır kod ile
sağlayan framework.
• Streams: Data akarken üzerinde işlemler yapmaya olanak sağlayan
API
• Streams: KStream: INSERT , KTable: UPDATE, null data gelirse
DELETE işlemi yapılır

21. TOPİCS VE LOGS
• Topic, kategori veya feed adı
olarak düşünülebilir
• Her Topic en az bir partitiondan
oluşur
• Her partition, sıralı ve değişmez
bir şekilde kayıt dizisinden oluşur.
Her bir kaydı tanımlayan benzersiz
ID atanır. Buna offset deniyor.
• Her Consumer Group topic'e
abone olduğunda kendi
metadatası tutulur Consumer
Offset'ine istediği gibi müdahâle
edebilir

22. TOPİCS VE LOGS
• Log size ve
Consumer Offset
arasındaki fark Lag
olarak yansımakta
ve geri kalma
durumunuzu
yansıtmakta
• Tek Consumer
bütün partitionlara
atanmış durumda,
Her partition için
bir consumer da
olabilirdi

23. TOPİCS VE LOGS
• Her Topic'in birden fazla
consumer'ı olabilir, aynıda anda
birden fazla topic'e atanabilir
• Bir partition aynı consumer
grup içinde yalnız bir
consumer'a atanır
• Kayıt saklama süresi default 7
gündür, saklanan data boyutu
performansı olumsuz etkilemez
• Replication sayısına göre
(Broker'a bağlıdır) data
dağıtımı sağlanır

24. DİKKAT EDİLECEK HUSUSLAR
• Her bir topic için doğru partition sayısı (5,10,100,1000 vs.)
• Sistemin monitor edilmesi (Monit, Munin, PRTG, Zabbix)
• Topic lerin monitor edilmesi (Kafka Manager, kafka offset monitor,
confluent control center)
• Yapısal configlerin değiştirilmemesi (compact,delete)
• Yeterli disk alanı seçilmesi

25. KAYNAKLAR
• https://arxiv.org/pdf/1709.00333.pdf
• RabbitMQ in Action
• https://kafka.apache.org
• https://www.cloudamqp.com
• https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-
how-apache-kafka-does-it/
• https://www.rabbitmq.com
• https://www.reddit.com/r/apachekafka/
• https://www.slideshare.net/old_sound/dissecting-the-rabbit

26. SORULAR