In recent years there has been an increasing demand for real-time streaming applications that handle large volumes of data with low latency. Examples of such applications include real-time monitoring and analytics, electronic trading, advertising, fraud detection, and more. In a streaming pipeline the first step is ingesting the incoming data events, after which they can be sent off for processing. Choosing the correct tool that satisfies application requirements is an important technical decision that must be made. This thesis focuses entirely on the data ingestion part by evaluating three different platforms: Apache Kafka, Apache Pulsar and Redis Streams. The platforms are compared both on characteristics and performance. Architectural and design differences reveal that Kafka and Pulsar are more suited for use cases involving long-term persistent storage of events, whereas Redis is a potential solution when only short-term persistence is required. They all provide means for scalability and fault tolerance, ensuring high availability and reliable service. Two metrics, throughput and latency, were used in evaluating performance in a single node cluster. Kafka proves to be the most consistent in throughput but performs the worst in latency. Pulsar manages high throughput with low message sizes but struggles with larger message sizes. Pulsar performs the best in overall average latency across all message sizes tested, followed by Redis. The tests also show Redis being the most inconsistent in terms of throughput potential between different message sizes

Applications found in both large and small enterprises need a communication method in order to meet requirements of scalability and durability. Many communication methods exist, but the most well-used are message queues and message brokers. The problem is that there exist many different types of message queues and message brokers with their own unique design and implementation choices. These choices result in different parameter sets, which can be configured in order to meet requirements of for example high durability, throughput, and availability. This thesis tests two different message brokers, Apache Kafka and RabbitMQ, with the purpose of discussing and showing the impact on throughput and latency when using a variety of parameters. The experiments conducted are focused on two primary metrics, latency and throughput, with secondary metrics such as diskand CPU-usage. The parameters chosen for both RabbitMQ and Kafka are optimized for maximized throughput and decreased latency. The experiments conducted are tested on a cloud platform; Amazon Web Services. The results show that Kafka outshines RabbitMQ regarding throughput and latency. RabbitMQ is the most efficient in terms of quantity of data being written, while on the other hand being more CPU-heavy than Kafka. Kafka performs better than RabbitMQ in terms of the amount of messages being sent and having the shortest one-way latency. / Applikationer som finns i både komplexa och icke-komplexa system behöver en kommunikationsmetod för att uppfylla kriterierna för skalbarhet och hållbarhet. Många kommunikationsmetoder existerar, men de mest använda är meddelandeköer och meddelandemäklare. Problemet är att det finns en uppsjö av olika typer av meddelandeköer och meddelandemäklare som är unika med avseende på deras design och implementering. Dessa val resulterar i olika parametersatser som kan konfigureras för att passa olika kriterier, exempelvis hög hållbarhet, genomströmning och tillgänglighet. Denna avhandling testar två olika meddelandemäklare, Apache Kafka och RabbitMQ med syfte att diskutera och visa effekterna av att använda olika parametrar. De utförda experimenten är inriktade på två primära mätvärden, latens och genomströmning, med sekundära mätvärden som exempelvis diskanvändning och CPU-användning. De parametrar som valts för både RabbitMQ och Kafka optimeras med fokus på de primära mätvärdena. Experimenten som genomförs testades på en molnplattform; Amazon Web Services. Resultaten visar att Kafka presterar bättre än RabbitMQ när det kommer till genomströmning och latens. Gällande inverkan av Kafka och RabbitMQ på mängden skriven data, är RabbitMQ den mest effektiva, medan den å andra sidan är mer CPU-tung än Kafka.

本研究針對物聯網與雲端大數據分析之不同程度的通訊需求，以微服務架構為基礎，設計一個四層式物聯網與大數據平台之通訊架構。面對物聯網之即時通訊需求，本研究採用MQTT通訊協定做為解決方案，而雲端大數據分析之通訊需求則採用Apache Kafka。 本研究基於參與者模型（Actor Model）所提出之「裝置代理人」，全面的解決了物聯網中異質通訊協定所產生的複雜性，同時解決了集中式物聯網閘道器所造成的系統複雜性與效能瓶頸，使物聯網閘道器能進行分散式部署，並且共享運算資源。

Microservice architecture, which involves breaking down applications into smaller and loosely coupled components, is becoming increasingly common in the development of modern systems. Connections between these components can be established in various ways. One of these approaches is event-driven architecture, where components in the system communicate asynchronously with each other through message queues.  AWS, Amazon Web Services, the largest provider of cloud-based services, offers such a messaging queue: SQS, Amazon Simple Queue Service, which can be integrated with SNS, Amazon Simple Notification Service, to enable "one-to-many" asynchronous communication.  An alternative tool is Apache Kafka, created by LinkedIn and later open-sourced under the Apache Software Foundation. Apache Kafka is an event logging and streaming platform that can also function as a message queue in an event-driven architecture.  The authors of this thesis have been commissioned by Scania to compare and evaluate the performance of these two tools and investigate whether there are use cases where one might be more suitable than the other. To achieve this, two prototypes were developed, each prototype consisting of a producer microservice and a consumer microservice. These prototypes were then used to conduct latency and load tests by producing messages and measuring the time interval until they were consumed.  The results of the tests show that Apache Kafka has a lower average latency than SNS/SQS and scales more efficiently with increasing data volumes, making it more suitable for use cases involving real-time data streaming. Its potential as a message bus for loosely coupled components in the system is also evident. In this context, SNS/SQS is equally valuable, as it operates as a dedicated message bus with good latency and offers a user-friendly and straightforward setup process. / Mikrotjänstarkitektur, som innebär att applikationer bryts ned till mindre och löst kopplade komponenter, är något som blir allt vanligare vid utvecklingen av moderna system. Kopplingar mellan dessa komponenter kan etableras på olika sätt. Ett av dessa tillvägagångssätt är händelsedriven arkitektur, där komponenterna i systemet kommunicerar asynkront med varandra genom meddelandeköer.  AWS, Amazon Web Services, som är den största leverantören av molnbaserade tjänster, tillhandahåller en sådan meddelandekö: SQS, Amazon Simple Queue Service, som kan integreras med SNS, Amazon Simple Notification Service för att möjliggöra ”en-till-många” asynkron kommunikation.  Ett alternativt verktyg är Apache Kafka, skapat av Linkedin och senare öppen källkodspublicerad under Apache Software Foundation. Apache Kafka är en händelselogg och strömningsplattform som även kan fungera som en meddelandekö i en händelsedriven arkitektur.  Författarna av detta arbete har på uppdrag av Scania blivit ombedda att jämföra och utvärdera prestandan hos de två verktygen samt undersöka om det finns användningsfall där det ena kan vara mer lämpligt än det andra. För att uppnå detta utvecklades två prototyper, där varje prototyp består av en producent- och en konsumentmikrotjänst. Dessa prototyper användes sedan för att genomföra latens- och lasttester genom att producera meddelanden och mäta tidsintervallet till dess att de konsumerades.  Resultatet från testerna visar att Apache Kafka har lägre genomsnittlig latens än SNS/SQS och skalar mer effektivt vid ökande datamängder, vilket gör det mer lämpat för användningsfall med realtidsströmning av data. Dess potential som meddelandebuss för löst kopplade komponenter i systemet är också tydlig. I detta sammanhang är SNS/SQS lika användbart, då det fungerar som en dedikerad meddelandebuss med god latens och en användarvänlig och enkel startprocess.