<div dir="ltr"><div>Ahoj,</div><div>kdyby clovek chtel byt moderni frikulin, tak by to cele slo postavit nad nejakou message queue (rabbitmq, kafka, zeromq, ...)</div><div>a neresit prenaseni celeho aktualniho stavu, ale zmeny stavu/prikazy jako jednotlive message.<br><br></div><div>V ramci prikladu vyse zkratkovite:<br></div><div>kazda pokladna ma sve vlastni uloziste (jedno zda *sql, ci cokoliv dalsiho), stejne jako centrala, tyto uloziste vzajemne naprimo nijak nekomunikuji<br></div><div>Veskera komunikace se jede pres message, tedy napr.:<br></div><div>- msg o zmene seznamu dostupnych polozek, na kterou jsou prihlaseny jednotlive pokladny, ktere si podle toho zmeni svuj otisk<br></div><div>- msg o nove objednavce, na kterou je zavesene hlaseni eet, pripadne treba centralni statistiky</div><div>- volitelne msg o kompletni zmene seznamu polozek, ktera se normalne nepouziva, ale jde pouzit v pripade rozpadnuti seznamu na nejake pokladne</div><div><br></div><div>klicova slova napr. "microservice messaging"<br><br></div><div>Petr<br></div><div class="gmail_extra"><br><div class="gmail_quote">2018-07-02 13:05 GMT+02:00 Jan B. Kolář <span dir="ltr"><<a href="mailto:janbivoj.kolar@zazen-nudu.cz" target="_blank">janbivoj.kolar@zazen-nudu.cz</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Díky moc za odpověď, určitě se na podívám podrobněji, zda bych to zvládl <br>
implementovat/použít.<br>
<br>
Co se týká té replikace, tak jsem právě uvažoval nad tím, že by každá pokladna <br>
měla svou vlastní databázi, tzn. na serveru by bylo databází tolik, kolik by <br>
bylo pokladen. To by mi bohatě stačilo v případě účtenek, protože každá <br>
pokladna si řeší jen své účtenky a nepotřebuje vidět/upravovat cizí. Pak jsem <br>
si ale uvědomil, že mám data, která naopak potřebuji "sdílet" a tedy můj plán <br>
s replikací nebude fungovat.<br>
<br>
Mohl bys mi prosím trochu líp vysvětlit, jak myslíš ten poslední odstavec? <br>
Není mi totiž jasné, co myslíš tou centrální aplikací a kontrolou změn.<br>
<br>
Díky,<br>
<br>
Honza<br>
<br>
Dne pondělí 2. července 2018 11:48:18 CEST, Jaroslav Týc napsal(a):<br>
<span class="">> Chápu, že umíš PHP a MySQL, takže učit se něco nového je zátěž navíc,<br>
> ale jak jsem dočetl popis tvého problému, tak mi naskočila CouchDB<br>
</span>> <<a href="http://couchdb.apache.org/" rel="noreferrer" target="_blank">http://couchdb.apache.org/</a>>, kterou používají třeba pro apku Wallet<br>
> <<a href="https://play.google.com/store/apps/details?id=com.droid4you.application.wal" rel="noreferrer" target="_blank"><font color="red"><b>MailScanner has detected definite fraud in the website at "play.google.com". Do <i>not</i> trust this website:</b></font> https://play.google.com/<wbr>store/apps/details?id=com.<wbr>droid4you.application.wal</a><br>
> let>.<br>
<span class="">> <br>
> CouchDB má mu vlastnost, že si synchronizaci dat řeší sama, včetně toho<br>
> který záznam je poslední, co s konflikty (ne, není to tak magické jak to<br>
> zní) a nějaké výpadky spojení ji moc netrápí.<br>
> <br>
> Co si pamatuju z přednášky vývojáře Wallet, tak si data posbírají přes<br>
> CouchDB a pak to z ní vycucnou a hodí do SQL databáze, se kterou pak<br>
> pracují jak jsou zvyklí.<br>
> <br>
> Pokud by mě osobně tlačil čas, tak bych šel cestou nejmenšího odporu a z<br>
> centrálního serveru bych kontroloval změny každých pět minut (třeba).<br>
</span>> Nedržel bych se replikace, protože udržovat *všude* stejnou databázi je<br>
<div class="HOEnZb"><div class="h5">> zbytečná datová zátěž a kdyby mi někde vznikl konflikt (byt jenom se<br>
> stejným ID u autoincrementu), tak bych si toho asi hodil mašli.<br>
> <br>
> Jarda<br>
> <br>
> On 07/02/2018 11:26 AM, Jan B. Kolář wrote:<br>
> > Ahoj,<br>
> > <br>
> > chtěl jsem Vás poprosit o radu s jedním problémem, který teď řeším.<br>
> > <br>
> > Když byl loni blázinec kolem EET, rozhodl jsem se jít vlastní cestou a pro<br>
> > svoje prodejny nasadil pokladní software v PHP (v PHP umím programovat,<br>
> > takže jsem si byl schopen do programu udělat implementaci EET). Celá věc<br>
> > mi běží na serveru a pokladny se tam připojují pomocí SSH tunelu.<br>
> > <br>
> > Co mi však  začalo dělat starosti jsou výpadky připojení. Za celý rok jich<br>
> > bylo jen pár, přesto bych však nechtěl dostat pokutu za to, že v době<br>
> > výpadku nedávám lístky.<br>
> > <br>
> > Začal jsem si tedy pohrávat s myšlenkou, že bych aplikaci přesunul na<br>
> > každou pokladnu zvlášť (tzn. na pokladně by běžel nginx, PHP a mysql) a<br>
> > na server si dělal jen replikaci databází, abych pak mohl dělat z<br>
> > pokladen výkazy, aniž by byly v běhu.<br>
> > <br>
> > Až po sem myšlenka dobrá, jenže dnes mi došlo, že budu potřebovat některá<br>
> > data sdílet mezi pokladnami - například seznam produktů. Ten potřebuji<br>
> > mít přístupný lokálně, aby šlo produkty účtovat v případě výpadku, ale<br>
> > zároveň ho také potřebuji synchronizovat, aby se produkt do seznamu<br>
> > nemusel přidávat na každé pokladně zvlášť. No a tady nevím, jak k tomu<br>
> > mám přistoupit :-(<br>
> > <br>
> > Neřešil jste někdo podobný problém? Napadlo mě, zda nemít pro sdílená data<br>
> > druhou databázi, která by byla na serveru a replikovala se na pokladny.<br>
> > Přiznám se ale, že nevím, jak bych v tomto případě řešil zápisy do master<br>
> > databáze na serveru a čtení z lokální slave databáze na pokladně.<br>
> > <br>
> > Ocením jakoukoliv radu nebo odkaz.<br>
> > <br>
> > Všechny zdraví<br>
> > <br>
> > Honza<br>
<br>
</div></div><div class="HOEnZb"><div class="h5">-- <br>
Jan B. Kolář<br>
<br>
Zažeň nudu<br>
Hodolanská 17, 779 00 Olomouc<br>
tel: +420 605 800 859<br>
e-mail: <a href="mailto:janbivoj.kolar@zazen-nudu.cz">janbivoj.kolar@zazen-nudu.cz</a><br>
<a href="http://www.zazen-nudu.cz" rel="noreferrer" target="_blank">www.zazen-nudu.cz</a><br>
______________________________<wbr>_________________<br>
Community-list mailing list<br>
<a href="mailto:Community-list@lists.vpsfree.cz">Community-list@lists.vpsfree.<wbr>cz</a><br>
<a href="http://lists.vpsfree.cz/listinfo/community-list" rel="noreferrer" target="_blank">http://lists.vpsfree.cz/<wbr>listinfo/community-list</a><br>
</div></div></blockquote></div><br></div></div>