Synchronizacia dat v db a pameti

Mam tu taku situaciu ktoru si nemyslim ze vyriesim takze toto beriem ako taku poslednu sancu.Mam sluzbu ktora prijma a uchovava spravy a taktiez umoznuje citat ulozene spravy podla roznych filtrovacich kriterii pre kazdeho klienta. Poradie sprav je dolezite a ziadna sprava sa nemoze "stratit" alebo preskocit nejak. Kazdy klient ma lokalne ulozene id/poradie poslednej spravy ktoru spracoval.Doteraz som to mal ako request-response ale pridavam moznost streamovania. Pri request-response to je bezproblemove nakolko kazdy request sposobi query do db a kazdy request obsahuje id/poziciu poslednej spravy ktoru klient ma lokalne uchovanu takze sa nikdy nestane ze dostane duplicitu alebo ze sa preskoci nejaka sprava - toto je kriticke. Skratka je to nieco ako zoradena fronta sprav.Teraz ide o to ze pridavam to streamovanie ale zaroven pridavam aj to ze nove spravy sa po zapise do db taktiez ulozia do pamete, takze aktivny klienti nemusia robit zbytocne query do DB kazdu sekundu a zbytocne ju zatazovat, ale rovno si vezmu spravy z pamete. Cize ked sa novy streamovany klient pripoji, tak sa z DB nacitaju nove spravy od poslednej ktoru klient ma az kym sa nenajdu ziadne nove. Vtedy by sa malo citanie sprav prepnut na citanie z pamete - respektive pocuvanie na nove spravy ktore budu prichadzat a kopirovane do pamete.

Tymto rapidne uvolnim databazu od zbytocnych query.Teraz kde je problem - akonahle sa novy klient dostane na poslednu spravu a chcem ho prepnut na pocuvanie na nove spravy v pameti, neviem prijst na to ako zarucit aby sa v tejto kratkej dobe nestalo ze nejake nove spravy sa zapisu do db ale klient este nebol prepnuty na pocuvanie na spravy v pameti a teda tieto nove spravy nezachyti ani priamo z db ani priamo z pamete.Snad som to napisal nejak zrozumitelne :)Kvoli acidite nemozem spravy davat najprv do pameti a az potom ich zapisovat do db. DB je jediny zdroj pravdy a nemoze sa absolutne stat ze nejake spravy budu stratene.PS: akurat ma napadlo mozne riesenie s mutexom na vstupe(zapis novych sprav), ale ak mate nejake idei, sem s nimi.PS2: nj, vyzera to tak ze sa mi to podarilo vyriesit. vzdy ked sa novy klient synchronizuje tak sa blokne zapis novych sprav, ked sa klient dostane na 0 novych sprav, prepne sa na pamet a nasledne za zapis odblokuje pre nove spravy. samozrejme ta pociatocna synchronizacia je v davkach takze zapis sa blokuje vzdy pred nacitanim novej davky(query) a po zisteni ci je pocet vratenych sprav z db 0 alebo nie, takze novy klient nezablokuje kmpletne zapis a neodfajci tak server.

vymýšlíš kolo. Tohle již má funkčně hotové řada databází, namátkou Kafka, rabbitmq, couchdb, redis (jeho queue), sqllite (s journaled ext3/4), postrgres cluster (nikoliv mysql/mariadb, které mají jen optimistic locking), zookeeper, etcd/consul, hbase či cokoliv novějšího nad rocksdb enginem.Mrkni na to, jestli ti něco vyhovuje a nepiš si to sám. Pokud si to chces napsat, nastuduj si nejprve teorie kolem CAP, konkurenčních zápisů, integrity dat a jejich ověřitelné transakčnosti.Osobně bych začal kafkou, která přesně tohle umí i přes více serverů a přesně kvůli tomuhle jí nasazuji.

ak som porozumel spravne - riesil by som takto+ "public pre read" z $mem+ "public pre write" na $diskvzdy existuje iba "1 source pre typ operacie" - je jasny a nie hrozi desync alebo strata

Ano, vymýšlíte kolo, nechápu vůbec proč. Použijte vhodný databázový server a korektně ho nechte nastavit, víc není třeba.