Here is an example: when a user is authorized, there is a check whether his data cache exists or not, if not, then there is a selection from the database and a write to the cache. Further, all changes occur in the cache. How to make an update from the cache to the database, because you need to somehow periodically save new values, because the cache, as you know, is not forever?

There is such an option: put the daemon (cron) on a run through all users and if he sees that the data has changed, then updates the account in the database. Check, for example, once every 2 or 1 minute, taking into account the limit.

I do not know whether this option will go or not, whether it is optimal or not, maybe there are some ideas?

Adding.

The question is more than relevant. One of the suggestions: you do not need kroons, just an additional field is made in the cash table - the checkout counter is set, for example, for every 1000 requests to drop the data into the database and the counter is then reset. This is a much better solution. More flexible, because You can change the number of 1000 to taste and does not give a peak load, as when starting through CZK.

    3 answers 3

    My suggestion is nosql in sql. Make one tablet with two fields and use. Such a system is also easily scalable. Although in practice I did not implement such a scheme. Implemented projects with one redis, redis + oracle, redis + mysql. Redis has the ability to save to disk, but it is limited by RAM.

    There was a project: the personal account of the user of the Internet services of the provider, so there was nothing in the redis except the directories.

    If you have all the business logic placed in 8 GB of server RAM, well, or in 2x8 GB of two servers, then you can only redis, but again, 16 GB will not load too much mysql with proper design.

    Many people naively believe that adding cache and stuffing everything in there will solve all their problems. I do not want to insult anyone, but if the tests do not collapse anymore, then there will be an unrecoverable situation (consider switching off and working without a cache, for every fireman).

    And with the scheme with the base and the cache, I will recommend the following (from existing experience, about 4 projects, 4 I am doing now, about this one):

    1. Develop a datalogical model for all business logic. Try to develop in such a way that in the future there will be no intermixing operations insert, update and select. I will explain: if there is only insert, then relieve the table of indexes. Try not to use update or better do it on the basis of one field (foreign key), and create a new field in another table. For example: some guys created a project that was constantly falling due to heavy loads (they have 4 link architecture with an app server on Delphi, fell at the level of 4 links - it would not cope with the influx of huge update transactions). We also decided to cache everything, but there was little use for it. They cited the inability to design in nosql. And all the brakes were on update in the usual database, and nosql could not cope with the volume (please correctly understand the volume of RAM). Helped them to re-design the approach to data storage, their relationality was 5 out of 5: I advised them to get rid of update and replace everything with insert. So far it works without redis, although it also exists, but for intermediate garbage (references and settings).
    2. It will now become a clearer picture of how much data is being chased, which is easy, even in bytes, to calculate, multiplied by the activity and the number of users. Here you can see right away what to put in the cache and when it overflows and everything will collapse. It can only be there immutable directories can be driven, but all the associations do not fit. I saw guys who shove everything from the base in redis, my theory worked, everything flew for them, until then, and then it collapsed. In addition, it is better to optimize some points in the database. And these guys came to this decision on the basis of successful experience with the previous project, only they looked not there, they did not cache the data from the database, but the content already given to the user (html pages).
    3. Only redis or memcash should not be used. Well, or on the extremes, use them with a database with tables without indexes, insert will fly. And it will start a little long, but depending on the priority.

    PS: There is an experience, but in my answers there is a lack of terminology and coherence of sentences due to the fact that thoughts overtake the printed text, so litter for spelling.

      Classics of the genre is memcached . Use it. As for periodic saving, this way you reduce reliability: if something happens in the system ... your cache drops, the connection to the database disappears, or something else and all the data disappears, although you have already convinced the user that everything has been done. So it might not be the best idea if this data has any meaning for users.

      • Also opted for memcached. But the programmer knows it superficially, do not tell me where you can find specialists who will help to deal with memcached? Or a specialized forum with adequate people. Each time the question here is not convenient to write, I want to create a separate topic and lead a discussion there, and how best to do it. I myself am a game designer, our project fgods.ru , and we want to rewrite it to memcached. Thank you in advance. - Maxim Andreev
      • I'm not sure that such a scheme is generally suitable for writing a game server. I think it will slow down under load, more precisely, the response time will be unsatisfactory. - cy6erGn0m

      Your task is very elegantly solved by Redis .

      Option with a demon - a crutch. Which will heavily load the system as soon as the number of users exceeds a certain limit.

      In general, changes should be made not in the cache, but in the database and, possibly, in the cache, but in order for the cache to perform its function, you need to implement the non-caching-free caching paradigm: when installing and updating the cache is done by one process .com)