Solved Redis cache

Discussion in 'Spigot Plugin Development' started by Mystic_Mark_, Aug 14, 2019.

  1. I have searched a lot of threads about using Redis as a Caching system. But I dont know exactly if I should change data in the cache directly. This data will be purchased kits, coins and all that sort of things.
     
    #1 Mystic_Mark_, Aug 14, 2019
    Last edited: Aug 14, 2019
  2. You can try storing player data into config files

    Sent from my ZTE BLADE A602 using Tapatalk
     
  3. This is not an option because it will be used on all servers in my bungeecord network.
     
  4. For permanent storage you are better of using MySQL. Redis has its use cases like caching, but the examples you mentioned isn't caching.
     
    • Agree Agree x 2
  5. I'm sorry. I meant I have got a mysql server setup. But when my player joins my network i would use redis as a temporary cache. But is of a good idea to push changes directly to my redis server or am i better of using a locale cache and then when i leave my server save it to my redis server.

    And when the player left my proxy save the redis cache to my mysql server.
     
  6. Depends if your redis server is running on the same machine as your minecraft servers.
    Also depends on how much and how often data is stored.

    If you just want to update stats after a minigame for example, then pushing updates directly to redis is fine.

    PS: Also depends on the usage of data. If you need the data in thread sync events for example, then the setup will be a lot harder
     
    #6 7smile7, Aug 14, 2019
    Last edited: Aug 14, 2019
  7. Things like coins can be changed very often.
     
  8. I mean if your servers run on the same machine then reading and writing of primitives should be pretty fast.
     
  9. But is that a good idea or is of better to load it to a local cache. Then edit the values and when the player switches servers save it.

    But then of the server would crash the data will be lost.
     
  10. Why not cache this in local memory of your Java process instead? To me it seems like unnecessairy overhead; a good MySQL server can respond to simple queries just as fast as a call to Redis. Unless your queries use loads of joins or have seriously large tables with too many columns to count (not literally), then I'd argue that Redis is not even needed. MySQL databases, when done correctly, can be quite fast. It sounds like you only have a simple table with some user ID and a column with a number, to keep track of coins. If that's the case, I would personally not even go with Redis, as I sincerely doubt you'll need it.
     
  11. You are better of using your server (as minecraft server) as your "warm cache" and using that one if possible, and using your Redis as "cold cache" for switching servers and only pushing to that if you expect that an other server will request it (so on logout etc) but doubt that you'll need it. You can use MySQL for that too. I'd only keep Redis as an option if you are planning to use PUB/SUB as well, otherwise it's not worth it in your case.
     
    • Agree Agree x 1
  12. You only use redis if you need the same data on multiple servers. If you dont read or write data from multiple servers you dont need redis.
    In this case you just serialize the objects (maybe as json) and load them when a player joins. You could use redis to distribute the data between server hops but sql should be fine for that too.
     
  13. I could do this. But then we face the problem of player joining before quitting. While switching servers.
     
  14. What do you mean?
     
  15. Yes, you would have that issue if you keep the cache in local memory. However, have you configured no caching at all? If your database is pretty simple and your server has a proper connection and it's not a potato, there's a good enough chance you won't even need caching and you could just directly save and load things from and to the database anytime a value changes.

    Using bungeecord, when switching to a new server, it fires a join event on the other server before it fires a quit on the current one. This makes it quite difficult to handle memory based caches.
     
  16. Ah, but in the case where you are sending the player form a to b (in what im assuming to be a lobby or game scenario) you can wait for the saving to finish before sending the player right? at least, that's how i always handled player sending and local warm cache.
     
  17. Bungeecord handles this, not your plugin. At least, that is, when players use /server. If it is a plugin which forwards players, you can indeed use your approach by first saving the data and then sending the player. @Mystic_Mark_ could probably shed some light on how this is being handled.
     
  18. Good to know. But then i have one more question. If lets say i spam a purchase button. Will the async tasks wait before the previous transaction is done or do i need to create a delay on purchasing something.
     
  19. No, a task is a task. They have no reference to each other. A task is simply added to the queue, which Spigot will process every tick (20 times a second). You would have to keep such state yourself; for example, when creating such task, check if the previous one has even quit. This could be achieved with a simple boolean somewhere which is set to true when the task gets created, and gets set to false when the task has finished. If the value is true when creating a task, send an error stating the user shouldn't spam.
     
  20. Thank you, This helped me a lot.
     
    • Like Like x 1