[vpsFree.cz: community-list] {Disarmed} Re: OT - PHP, MSQL a sdílení dat

[Petr Sykora]

Ahoj,
kdyby clovek chtel byt moderni frikulin, tak by to cele slo postavit nad
nejakou message queue (rabbitmq, kafka, zeromq, ...)
a neresit prenaseni celeho aktualniho stavu, ale zmeny stavu/prikazy jako
jednotlive message.

V ramci prikladu vyse zkratkovite:
kazda pokladna ma sve vlastni uloziste (jedno zda *sql, ci cokoliv
dalsiho), stejne jako centrala, tyto uloziste vzajemne naprimo nijak
nekomunikuji
Veskera komunikace se jede pres message, tedy napr.:
- msg o zmene seznamu dostupnych polozek, na kterou jsou prihlaseny
jednotlive pokladny, ktere si podle toho zmeni svuj otisk
- msg o nove objednavce, na kterou je zavesene hlaseni eet, pripadne treba
centralni statistiky
- volitelne msg o kompletni zmene seznamu polozek, ktera se normalne
nepouziva, ale jde pouzit v pripade rozpadnuti seznamu na nejake pokladne

klicova slova napr. "microservice messaging"

Petr

2018-07-02 13:05 GMT+02:00 Jan B. Kolář <janbivoj.kolar at zazen-nudu.cz>:

> Díky moc za odpověď, určitě se na podívám podrobněji, zda bych to zvládl
> implementovat/použít.
>
> Co se týká té replikace, tak jsem právě uvažoval nad tím, že by každá
> pokladna
> měla svou vlastní databázi, tzn. na serveru by bylo databází tolik, kolik
> by
> bylo pokladen. To by mi bohatě stačilo v případě účtenek, protože každá
> pokladna si řeší jen své účtenky a nepotřebuje vidět/upravovat cizí. Pak
> jsem
> si ale uvědomil, že mám data, která naopak potřebuji "sdílet" a tedy můj
> plán
> s replikací nebude fungovat.
>
> Mohl bys mi prosím trochu líp vysvětlit, jak myslíš ten poslední odstavec?
> Není mi totiž jasné, co myslíš tou centrální aplikací a kontrolou změn.
>
> Díky,
>
> Honza
>
> Dne pondělí 2. července 2018 11:48:18 CEST, Jaroslav Týc napsal(a):
> > Chápu, že umíš PHP a MySQL, takže učit se něco nového je zátěž navíc,
> > ale jak jsem dočetl popis tvého problému, tak mi naskočila CouchDB
> > <http://couchdb.apache.org/>, kterou používají třeba pro apku Wallet
> > <https://play.google.com/store/apps/details?id=com.
> droid4you.application.wal
> > let>.
> >
> > CouchDB má mu vlastnost, že si synchronizaci dat řeší sama, včetně toho
> > který záznam je poslední, co s konflikty (ne, není to tak magické jak to
> > zní) a nějaké výpadky spojení ji moc netrápí.
> >
> > Co si pamatuju z přednášky vývojáře Wallet, tak si data posbírají přes
> > CouchDB a pak to z ní vycucnou a hodí do SQL databáze, se kterou pak
> > pracují jak jsou zvyklí.
> >
> > Pokud by mě osobně tlačil čas, tak bych šel cestou nejmenšího odporu a z
> > centrálního serveru bych kontroloval změny každých pět minut (třeba).
> > Nedržel bych se replikace, protože udržovat *všude* stejnou databázi je
> > zbytečná datová zátěž a kdyby mi někde vznikl konflikt (byt jenom se
> > stejným ID u autoincrementu), tak bych si toho asi hodil mašli.
> >
> > Jarda
> >
> > On 07/02/2018 11:26 AM, Jan B. Kolář wrote:
> > > Ahoj,
> > >
> > > chtěl jsem Vás poprosit o radu s jedním problémem, který teď řeším.
> > >
> > > Když byl loni blázinec kolem EET, rozhodl jsem se jít vlastní cestou a
> pro
> > > svoje prodejny nasadil pokladní software v PHP (v PHP umím programovat,
> > > takže jsem si byl schopen do programu udělat implementaci EET). Celá
> věc
> > > mi běží na serveru a pokladny se tam připojují pomocí SSH tunelu.
> > >
> > > Co mi však  začalo dělat starosti jsou výpadky připojení. Za celý rok
> jich
> > > bylo jen pár, přesto bych však nechtěl dostat pokutu za to, že v době
> > > výpadku nedávám lístky.
> > >
> > > Začal jsem si tedy pohrávat s myšlenkou, že bych aplikaci přesunul na
> > > každou pokladnu zvlášť (tzn. na pokladně by běžel nginx, PHP a mysql) a
> > > na server si dělal jen replikaci databází, abych pak mohl dělat z
> > > pokladen výkazy, aniž by byly v běhu.
> > >
> > > Až po sem myšlenka dobrá, jenže dnes mi došlo, že budu potřebovat
> některá
> > > data sdílet mezi pokladnami - například seznam produktů. Ten potřebuji
> > > mít přístupný lokálně, aby šlo produkty účtovat v případě výpadku, ale
> > > zároveň ho také potřebuji synchronizovat, aby se produkt do seznamu
> > > nemusel přidávat na každé pokladně zvlášť. No a tady nevím, jak k tomu
> > > mám přistoupit :-(
> > >
> > > Neřešil jste někdo podobný problém? Napadlo mě, zda nemít pro sdílená
> data
> > > druhou databázi, která by byla na serveru a replikovala se na pokladny.
> > > Přiznám se ale, že nevím, jak bych v tomto případě řešil zápisy do
> master
> > > databáze na serveru a čtení z lokální slave databáze na pokladně.
> > >
> > > Ocením jakoukoliv radu nebo odkaz.
> > >
> > > Všechny zdraví
> > >
> > > Honza
>
> --
> Jan B. Kolář
>
> Zažeň nudu
> Hodolanská 17, 779 00 Olomouc
> tel: +420 605 800 859
> e-mail: janbivoj.kolar at zazen-nudu.cz
> www.zazen-nudu.cz
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20180702/0c9e7e85/attachment-0001.html>