Il mondo è asincrono e distribuito
dicembre 1, 2011 Lascia un commento
Oggi ho pubblicato il seguente post sul blog indigeni digitali:
http://blog.indigenidigitali.com/amazon-ec2/
In questo post viene descritto:
Maggio 2, 2011 2 commenti
1. INVIO DEL MESSAGGIO
Il messaggio, proveniente da un webserver, viene preso in consegna e rediretto verso una coda SQS, di seguito un pezzo di codice in java per l’invio del messaggio.
Class SQS{
xml message String xmlexample = "<Order> <iduser>XYZ</iduser> <idoperation>555555</idoperation> <mailoperation>mail@mailmail.com</mailoperation> <bookid>5556677999</bookid> </Order>";
ThreadPoolExecutor poolexc = new ThreadPoolExecutor(10, 10, 50000L, TimeUnit.MILLISECONDS,new LinkedBlockingQueue()); for (int j = 0; j < 500; j++) { poolexc.execute(new Task(j+xmlexample,j)); }
poolexc.shutdown();
Task Class
public void run()
{
queue us-east String myQueueUrl ="https://sqs.us-east-1.amazonaws.com/44444/queue-1";//
try {
request SendMessageRequest sq = new SendMessageRequest(myQueueUrl,_xml); /// send message sqs.sendMessage(sq);
.....
La classe SQS simula un carico di 500 richieste di un xml (lungo 143) con un ThreadPoolExecutor di 10 elementi, quindi la responsabilità del modulo Request.Aumentando il numero di task sul ThreadPoolExecutor si aumenta il throughput, ovviamente il numero task va deciso in base ai server e al tipo di connessione. Un valore troppo elevato potrebbe avere l’effetto contrario.
Eseguendo il test dalla mia normalissima connessione di casa ho avuto i seguenti risultati:
****** Start Request Time:2011-04-26 17:06:16:616
****** End Request 499 at 17:06:28:919 (post ultimo messaggio )
(circa 41 messaggi al secondo).
Ho provato lo stesso JAR su una istanza MICRO EC2 (debian) ed ho ripetuto il test avendo i seguenti risultati:
XMLExample len:143
****** Start Request :2011-04-26 15:15:38:1538
****** End Request task 499 at 15:15:40:832 (post ultimo messaggio )
(circa 250 messaggi al secondo).
Ovviamente sull’istanza EC2 è molto più veloce.
2. RICEZIONE DEL MESSAGGIO
Per ricevere i messaggi dalla coda bisogna effettuare un pool di lettura.
Il modulo Elab a tempo controlla se ci sono messaggi, di seguito un pezzo di codice per la ricezione del messaggio:
ReceiveMessageRequest receiveMessageRequest = new ReceiveMessageRequest(myQueueUrl);
message receiveMessageRequest.setMaxNumberOfMessages(10);
List messages = sqs.receiveMessage(receiveMessageRequest).getMessages();
if (messages.size()>0)
{ for (Message message : messages) {
elabmessage(message )
String messageRecieptHandle = message.getReceiptHandle(); sqs.deleteMessage(new DeleteMessageRequest(myQueueUrl, messageRecieptHandle))
};
Quando il server è scarico può ricevere il messaggio elaborarlo e cancellarlo.
Invio e ricezione completati.
Note:
SQS di default salva il messaggio per 4 giorni, volendo si può estendere a 2 settimane, ma l’idea è che il messaggio dovrebbe essere processato subito.
Un messaggio può essere al massimo di 64k, per informazioni più grandi bisogna utilizzare altre tecniche.
Data la natura distribuita del sistema, SQS non garantisce la sequenzialità dei messaggi.
Ogni volta che un messaggio viene preso in consegna è opportuno cancellarlo.
Conclusioni
Amazon SQS è un ottimo servizio a messaggi che può essere usato sia sui server che sui dispositivi mobile.
Come tutti i servizi Amazon ci sono a disposizione varie regions da poter utilizzare , quindi c’è la garanzia di continuità è decisamente elevata.
In questo esempio non c’è un throughput elevatissimo (specialmente dalla mia rete ), ma l’idea è che il redirect sul cloud deve essere fatto solo dei messaggi ritenuti importanti, quindi se riesci a vendere 250 libri al secondo per tutto l’anno puoi anche permetterti delle istanze più grandi e linee più veloci :)!!
SQS ha un costo che, secondo me, se hai un bel business è trascurabile. Studiando i casi d’uso di amazon c’è chi ha installato un broker ( es:RabbitMQ,ActiveMQ eccc) su delle istanze EC2. Questa soluzione può aumentare le performance e diminuire i costi, ma il cluster dei broker non è più gestito da Amazon, per cui possono aumentare i punti di failover.
Su una istanza EC2 sto provando FuseMessageBroker basato su ActiveMQ.
Gabriele Santomaggio's Blog 