On 2 Jul 2018, at 21:29, Martin Miksanik <miksanik@gmail.com> wrote:Jen takova blbost,kdyz uz se resi M2M replikace. Neni lepsi misto ID pouzivat UUID, tim se vyhnes konfliktum ID cek(minimalne ma v sobe UUID4 hash stroje a detekce kolizi bude tak specialni udalost, ze se asi ani nikdy nestane).
Posledni zmena vitezi, umi to MySQL a asi problem solved. Kazdy stroj si muze komunikovat zvlast (vypadek serveru nezpusobi neodeslani EET)Cim vice mustku, tim horsi udrzba..._______________________________________________2018-07-02 16:39 GMT+02:00 Ivan Moucha [Minowara] <minowara@gmail.com>:Ahoj,to co hledas je Circuit Breaker (https://en.wikipedia.org/wiki/Circuit_breaker_design_ nebo https://pattern martinfowler.com/bliki/ )CircuitBreaker.html V PHP uz si neco muzes vygooglit, neco sem nasel :-).Dalsi reseni (ktere pouzivame bezne v produkci) je nasazeni MQ front, ktere je samo od sebe dostatecne robustni a vyresi ti spoustu problemu (ale o to slozitejsi je to dokodovat).--------------Ivan Moucha [Minowara]
On 2 Jul 2018, at 16:14, Jan B. Kolář <janbivoj.kolar@zazen-nudu.cz> wrote:Díky všem za jejich reakci a omlouvám se za moje poněkud delší odezvy. Sedím
zrovna za pultem a zatím co odpovídám, tak ještě obsluhuji zákazníky :-D
V podstatě se mi zdá jako nejjednodušší řešení to, co míše Martin. Můj problém
ale je, že úplně přesně nevím, jak bych to měl v PHP implementovat. Tedy
první, co mě napadlo je, že bych použil dvě databáze - vzdálenou přes SSH
tunel a lokální. Standardně bych pracoval se vzdálenou databází a pokud by se
PHP nepodařilo ke vzdálené databázi připojit, tak by začalo pracovat s lokální
databází a ukládalo si účtenky, které vystavilo pro pozdější synchronizaci.
Jakmile by se spojení obnovilo, tak by se appka pokusila všechno z lokální
databáze nahrát do vzdálené databáze na server.
Hned první, co mě ale napadá je, jak appka pozná, že je spojení přerušeno/
navázáno? Tedy pokud budu při každém požadavku čekat na timeout vzdálené
databáze, tak se ta aplikace asi brutálně zpomalí, ikdyž tam dám třeba jen 1s
timeout.
Čím si však vůbec nejsem jistý, jakým způsobem bych měl řešit tu cache
produktů? To mám třeba co hodinu stahovat celou produktovou tabulku ze
vzdálené databáze a ukládat ji lokálně? Jde sice jen o cca. 2 tisíce produktů
a dvě pokladny, ale přesto...
Neviděl jste někdo nějakou implementaci takového problému, že bych se mohl
podívat na kód?
Dne pondělí 2. července 2018 13:18:36 CEST jste napsal(a):Dne 2.7.2018 v 11:26 Jan B. Kolář napsal(a):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.
Nebylo by jednodušší používat lokální databázi na pokladnách jen jako
cache produktů a buffer účtenek? Databáze na serveru bude hlavní.
Pokladny si z ní v definovaných intervalech budou aktualizovat cache
produktů a průběžně do ní budou zapisovat nové účtenky, které se
serverem Ministerstva vyřídí samy. Když ale selže spojení s hlavní
databází, účtenka se zapíše do bufferu a na server se uloží až
dodatečně, až se spojení zase obnoví.
S pozdravem,
Maritn Doucha
--
Jan B. Kolář
Zažeň nudu
Hodolanská 17, 779 00 Olomouc
tel: +420 605 800 859
e-mail: janbivoj.kolar@zazen-nudu.cz
www.zazen-nudu.cz
_______________________________________________
Community-list mailing list
Community-list@lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
_______________________________________________
Community-list mailing list
Community-list@lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
--S přáním pěkného dne,
Martin Mikšaník
gsm: +420 602 623 934
icq: 311047283
Community-list mailing list
Community-list@lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list