<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">Il giorno 30 settembre 2015 11:27, Carlo Miron <span dir="ltr"><<a href="mailto:miron@python.it" target="_blank">miron@python.it</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">2015-09-30 10:34 GMT+02:00 Marco Beri <<a href="mailto:marcoberi@gmail.com">marcoberi@gmail.com</a>>:<br>
<br>
> On Wed, Sep 30, 2015 at 10:14 AM, Carlo Miron <<a href="mailto:miron@python.it">miron@python.it</a>> wrote:<br>
</span><span class="">>> Già, è un bel casino. Dato che non sempre la consistenza eventuale è<br>
>> un opzione, obbliga ad utilizzare approcci tipo il [3PC][¹], con tutte<br>
>> le complicazioni del caso.<br>
><br>
> "The main disadvantage to this algorithm is that it cannot recover in the<br>
> event the network is segmented in any manner. The original 3PC algorithm<br>
> assumes a fail-stop model,<br>
> where processes fail by crashing and crashes can be accurately detected, and<br>
> does not work with network partitions or asynchronous communication:<br>
><br>
> Brrr...<br>
<br>
</span>Riporto un dialogo immaginario tra me e un personaggio fittizio che<br>
chiamerò Pelatone™ per proteggerne l'identità.<br>
<br>
me<br>
non c'è soluzione, al problema del partitioning<br>
ma nemmeno con nessuna replica master-master relazionale<br>
quindi è un problema comune<br>
<br>
Pelatone<br>
certo<br>
ma tu useresti un db replicato in una applicazione finanziaria per esempio?<br>
<br>
me<br>
se lo devo scalare sui c100k non vedo grosse alternative<br>
<br>
Pelatone<br>
ok<br>
100.000 connessioni al secondo in una app finanziaria... uhm...<br>
solo la borsa mi sa<br>
però in quel caso lì io devo essere sicuro delle transazioni...<br>
come faranno?<br>
<br>
me<br>
evitano accuratamente che il sistema si partizioni :D<br>
<br>
Pelatone<br>
:D :D<br>
bella roba... allora è come dicevo io... non si usano<br>
i microservizi<br>
in una app finanziaria<br>
<br>
me<br>
ripeto, il problema del partitioning non è insito nei microservizi<br>
ce l'hai anche nello sharding<br>
solo la replica master/slave ne è immune<br>
ma presenta forti limiti di scalabilità, infatti<br>
poi non è vero che il fail-stop model è sempre la soluzione migliore<br>
per esempio la borsa. se la cina si isola, il sistema borsa crolla?<br>
no, si formano due isole indipendenti; il mercato va avanti da una<br>
parte senza la cina, dall'altra solo con la cina<br>
e poi qualche povero deficente riconcilia il casino ammano :-/<br>
hai indubbiamente perso consistenza. ma è la migliore quantità di<br>
consistenza che puoi ottenere in un sistema distribuito peer<br>
e non c'è nessun "non me lo posso permettere" che tenga, punto.<br></blockquote><div><br></div><div>segnalo questa intervista all'inventore del "CAP theorem", Eric Brewer<br></div></div><div class="gmail_quote"><a href="https://medium.com/s-c-a-l-e/google-systems-guru-explains-why-containers-are-the-future-of-computing-87922af2cf95">https://medium.com/s-c-a-l-e/google-systems-guru-explains-why-containers-are-the-future-of-computing-87922af2cf95</a><br><br>parla di container, di orchestration e di "compromises on consistency"</div><div class="gmail_quote"><br></div><div class="gmail_quote">un estratto:</div><div class="gmail_quote"><br></div><div class="gmail_quote">That bothered me for a little while until I eventually realized that was a fundamental tradeoff and that anyone that wants to be highly available in a distributed system has to make some compromises on consistency. It was not at first well received, because it implies that people who build databases can’t promise to be up all the time, even though they do make that promise. And it means if you want to have both you actually have to work pretty hard to even get good compromises.<br> <br>certo ci sono varie strategie di eventually consistency ...</div><div class="gmail_quote"><br></div><div class="gmail_quote">sono spesso citati i casi di un ATM mi permette di prelevare soldi che non mi appartengono o Amazon che mi lascia ordinare beni che non esistono più... </div><div class="gmail_quote">è qualcosa che va gestito a vari livelli: dal livello del codice applicativo (logica supplementare per gestire queste situazioni) su su fino ai livelli dirigenziali dell'azienda per capire cosa è accettabile e cosa no</div><div class="gmail_quote"><br><div class="gmail_quote">il caso citato da Carlo è però emblematicamente divertente nella sua enormità: vorrei proprio vedere chi sarebbe l'autorità delegata a ri-raccordare le quotazioni delle borse occidentali con le borse asiatiche in caso di partitioning continentale...</div><div class="gmail_quote"><br></div><div class="gmail_quote">ciao,</div><div class="gmail_quote">Marco</div></div></div></div>