Re: [vpsFree.cz: community-list] OT - PHP, MSQL a sdílení dat
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
Ahoj, prave proto jsem navrhoval pouzit buffer (cache) rovnou a odesilat uctenky na server az pozdeji (cronem kazdou minutu?). Pak neresis jestli funguje spojeni nebo ne, ale jestli se ti pocedlo odeslani te jedne uctenky nebo nebo. A podle toho ji pak z cache vymazes nebo ne. Co se produktove db tyka, bude pouzijes replikaci, coz v jednoduchem master-slave nastaveni by melo fungovat ok. Nebo muzes do tabulky s produktama pridat sloupec "global_id", ktery budes incrementovat vzdy pri kazde zmene. Pokladna si pak stahne jen zaznamy s novejsim "global_id" nez stahla posledne. Zase v tomto pripade nebude vadit, kdyz pripojeni k serveru na nejakou dobu padne. Nevyhoda takovehoto postupu je, ze nepoznas smazane produkty. Dalsi co me napada je udelat tabulku "transactions" se sloupecky "global_id", "product_id", "operation". Tam ulozis zaznam pri kazde zmene a pokladny se pak mohou syncovat oproti teto tabulce. Zase si pokladna bude jen pamatovat posdleni stahnute "global_id". Mirek On 2.7.2018 16:14, Jan B. Kolář 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
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@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
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_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@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 <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
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-cluste... <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@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 <mailto:minowara@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@zazen-nudu.cz <mailto: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 <mailto:janbivoj.kolar@zazen-nudu.cz> www.zazen-nudu.cz <http://www.zazen-nudu.cz/> _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@lists.vpsfree.cz> http://lists.vpsfree.cz/listinfo/community-list <http://lists.vpsfree.cz/listinfo/community-list>
_______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz <mailto:Community-list@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@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Ahoj, podařilo se někomu rozchodit KVM na Ubuntu 16.04? Po instalaci podle návodu na https://kb.vpsfree.cz/navody/vps/kvm (Debian 8), končím s chybou Jul 03 22:33:04 vps01 systemd[1]: Starting LSB: QEMU KVM module loading script... Jul 03 22:33:04 vps01 qemu-kvm[68]: * Configuring kvm qemu-kvm Jul 03 22:33:04 vps01 qemu-kvm[68]: modprobe: ERROR: ../libkmod/libkmod.c: 586 kmod_search_moddep() could not open moddep file '/lib/modules/3.16.6-042 stab131.42/modules.dep.bin' Jul 03 22:33:04 vps01 qemu-kvm[68]: modprobe: FATAL: Module kvm_intel not found in directory /lib/modules/3.16.6-042stab131.42 Jul 03 22:33:04 vps01 qemu-kvm[68]: mknod: /dev/kvm: File exists Jul 03 22:33:04 vps01 qemu-kvm[68]: ...done. Jul 03 22:33:04 vps01 systemd[1]: Started LSB: QEMU KVM module loading script. KVM mám na VPS povolené. Dík H
participants (5)
-
Ivan Moucha [Minowara] -
Jan B. Kolář -
Martin Miksanik -
Miroslav Misek -
mochour＠email.cz