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

[Martin Miksanik]

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 at gmail.com>:

> Ahoj,
>
> to co hledas je Circuit Breaker (https://en.wikipedia.org/
> wiki/Circuit_breaker_design_pattern nebo https://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 at 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 at zazen-nudu.cz <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
>
>
>
> _______________________________________________
> Community-list mailing list
> Community-list at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vpsfree.cz/pipermail/community-list/attachments/20180702/93eed106/attachment-0001.html>