0

We want to develop an application based on micro services architecture. To communicate between various services asynchronously, we plan to use message queues(like RabbitMQ,ActiveMQ,JMS etc.,) . Is there any approach other than message queue is available to achieve inter process communication?

Thanks.

JavaUser
  • 25,542
  • 46
  • 113
  • 139
  • Possible duplicate of [How to have 2 JVMs talk to one another](https://stackoverflow.com/questions/10942427/how-to-have-2-jvms-talk-to-one-another) – Max Sep 07 '18 at 14:01

1 Answers1

1

You should use Queues to handle the tasks that needs not to be completed in real time.

Append the tasks in queue and when there is a room, processor will take tasks from queue and will handle & will remove from queue.

Example :

  1. Assuming your application deals with images, users are uploading so many images. Upload the tasks in a queue to compress the images. And when processor is free it will compress the queued images.

  2. When you want to write some kind of logs of your system, give it to the queue and one process will take logs from queue and write that to disk. So the main process will not waste its time for the I/O operations.

Suggestion :

If you want the real time responses, you should not use the queue. You need to ping the queue constantly to read the incomings, and that is bad practice. And there is no guarantee that queue will handle your tasks immediately.

So the solutions are :

  1. Redis cache - You can put your messages into cache and other process will read that message. Redis is "In memory data-structure". It is very fast and easy to use. Too much libraries and good resources available on the Internet, as it is open source. Read more about Redis. But here you also need to keep check whether there is some kind of message available and if available read from it, process and give response. But to read from Redis, is not very much costlier. With redis, you do not need to worry about memory management, it is well managed by open source community.

  2. Using Sockets. Socket is very much faster, you can make this lightweight(if you want) as it is event based. One process will ping on port and other process will listen and give response. But you need to manage memory. If the buffered memory gets full, you can not put more messages here. If there are so many users producing messages, you need to manage to whom to you want to respond.

So it depends upon your requirement, like do you want to read messages constantly?, do you want to make one to one communication or many to one communication?

Community
  • 1
  • 1
Ujjaval Moradiya
  • 222
  • 1
  • 12
  • Thanks Ujjaval . There are various sensors installed and these sensors will send data periodically(also based on event or request by someone). We want to get the data and process and persist and do manipulations. To address this , we need a solution which is more scalable and efficient and loosely coupled. – JavaUser Aug 11 '17 at 06:12
  • So it is many to one. And do you need to do this procedure on real time? With the sockets, you can do real time (sensors will make a request on the socket & on the other side process will listen, manipulate and complete the request), with the redis you can put the data in cache and when there is a need, fetch data from it and use, so fetching will become fast and on the timely basis store into DB. Both the things are scalable. I can use cache to store the FB likes for faster access, I can use sockets to make process asynchronous, so it depends how you are making. – Ujjaval Moradiya Aug 11 '17 at 06:56
  • @Ujjaval Moradiya Can you elaborate on reasoning behind the statement "You should use Queues to handle the tasks that are not very much important (..)". In my eyes queues are much more reliable than direct communication (like REST or socket based). Keep in mind that you can also do pub-sub with some products, which eliminates the need for frequent pooling. – Lech Migdal Aug 11 '17 at 08:47
  • @LechMigdal sentence should be - "You should use Queues to handle the tasks that need not to be complete in real time". I wrote 2 examples where use of the queue will fit best. With the queue, there SHOULD be only one consumer otherwise you need to keep track of the tasks which are ongoing. So in this scenario when one task takes time, there is no guarantee that the coming tasks will get delivered in the real time and in that case queue will perform better. For me queue means you are making list of tasks and on the FIFO bases tasks will gets competed. – Ujjaval Moradiya Aug 11 '17 at 10:11
  • sorry for the typo - "there is no guarantee that the coming tasks will get delivered in the real time and in that case you should not use queue" – Ujjaval Moradiya Aug 11 '17 at 11:06
  • @Ujjaval Moradiya, awesome, thank you, agree on the potential "real time" challenge :) – Lech Migdal Aug 11 '17 at 11:15