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

Mon Jul 2 21:39:01 CEST 2018

Jeste jednu vec pridam k zamysleni … pokud by si fakt uvazoval nad tim ze to budes resit na urovni DB, tak todle by mohlo byt take reseni pro tebe: https://mariadb.com/kb/en/library/getting-started-with-mariadb-galera-cluster/ <https://mariadb.com/kb/en/library/getting-started-with-mariadb-galera-cluster/>

Znamena to prejit s MySQL na MariaDB (je to binarne kompatibilni a nezpusobi ti to zadne problemy)

--------------
Ivan Moucha [Minowara]


> On 2 Jul 2018, at 21:29, Martin Miksanik <miksanik at 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 at gmail.com <mailto:minowara at gmail.com>>:
> Ahoj,
> 
> to co hledas je Circuit Breaker (https://en.wikipedia.org/wiki/Circuit_breaker_design_pattern <https://en.wikipedia.org/wiki/Circuit_breaker_design_pattern> nebo https://martinfowler.com/bliki/CircuitBreaker.html <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 <mailto: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 <mailto:janbivoj.kolar at zazen-nudu.cz>
>> www.zazen-nudu.cz <http://www.zazen-nudu.cz/>
>> _______________________________________________
>> Community-list mailing list
>> Community-list at lists.vpsfree.cz <mailto:Community-list at lists.vpsfree.cz>
>> http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list>
> 
> 
> _______________________________________________
> Community-list mailing list
> Community-list at lists.vpsfree.cz <mailto:Community-list at lists.vpsfree.cz>
> http://lists.vpsfree.cz/listinfo/community-list <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 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/22d145d3/attachment.html>