Best way to create bullet-proof counter

Question

I am building a gaming system where many players can play together some sort of table game. There could be hundreds of game tables at the same time. The system consists of several components where main components are gaming servers and DBworker and in between there is rabbitMQ. DBWorker is something that takes care about databases.

So, I need to make sure that each game has unique ID to properly track results of the games. I would love to have some sort of auto-increment solution. Of course I can do some sort of sequence in PostgreSQL DB and pull new ID every time but for me it seems as an obvious bottleneck (I don't want to be linked to DB all the time. In case DB goes down show must go on while our engineers recover DB).

So, any ideas or personal experience of implementing something similar?

p.s. I am thinking about timestamp as ID but real ID would be better. Cannot figure out why - if I am wrong, please correct me.

Thank in advance for everyone!

Answer 1

That's the domain of GUID's which are not normal counters and supposed to be globally unique. Since you didn't mention the language and framework you use, I throw in this: How to create a GUID/UUID in Javascript

For other frameworks just google your framework + GUID

Answer 2

AFAIK, there is no way to be absolutely 100% safe from collision but you could make it very, very unlikely. Take for example the algorithm John Millikin posted in Maik Semder's link above and attach a hashed timestamp at the end.

That way, even if two users manage to log in at precisely the same millisecond, the chances of them getting the same ID would be one in 22,300,745,198,530,623,141,535,718,272,648,361,505,980,416

:-)

Answer 3

You could use HI/LO algorithm with database sequences. Obtain sequence value, multiply by N and keep internal counter running from 0 to N-1 and add it to multiplied value. When the counter hits N, you get a new value from database sequence. The you'll hit the database only at every Nth ID. Of course this will not help if your database goes down for too long time.

Answer 4

So far I've decided to use lovely rabbitMQ in the following way:

1. I will create a service that will put 1, 2, 3 etc. messages into the rabbitMQ. It will also sometimes check if there are enough numbers or not (let's say in one hour 1000 games in average, so for one day I won't need more that 24000 numbers).
2. When a new game starts gameKeeper will pull new number from the rabbitMQ and use it.

Since rabbitMQ is extremely stable and many other very important things are linked on it - it is ok. If rabbit dies - no problem with number, because whole system will die. So, for me it seems ok.

Why I don't use UUID? UUID is not really good for me for few reasons:

1. I cannot know order of the games (of course I can add extra fields in DB like timestamp or something like this)
2. It is not nice to tell to players something like this: "Yo bro, you are laying game:XXXXX-XXXXXXXXXXXXXX-XXXXXXXXXXXXX-XXXXXXXXX-XXXX" :-)

So, I think my dummy approach will work for me for some while. Thank you for your advices! Ups in you reputations.