6 ms·
I implemented something similar to the approach in this article. I was building a payment transaction system and ran into the issue of having locks and transact
by zacksiri 3y ago
I implemented something similar to the approach in this article. I was building a payment transaction system and ran into the issue of having locks and transactions in the database causing higher and higher latency as the queue got larger.
I never coined a term, but I implemented an “ALTP” using in memory cache library in elixir. The library is called nebulex. It was so simple to implement. Since the library supported distribution out of the box. I had a distributed in memory transactional guarantee that worked well in a short amount of time.
The cool thing was I also wrapped the database lock under the distributed in memory lock so in the case of a net split the database’s lock’s got my back. In normal circumstances it made things scalable because the in memory lock would prevent the client from connecting to the database until the in memory lock was let go.
In elixir doing these things are really intuitive and enjoyable and without requiring an external dependency. I think it took me only a couple of days work design / implement and solved the problem.
- AtlasBarfed 3y agoA couple of days? For a distributed partition tolerant double wrapped locck?
- zacksiri 3y agoYeah. Couple of days. To be fair Elixir and Nebulex library did most of the heavy lifting. I had been using Nebulex for a long time before implementing this solution. But as our system scaled we ran into more and more problems so I decided to try it. Check out this video https://youtu.be/v-n8L-DiPL4 https://youtu.be/v-n8L-DiPL4
- avinassh 3y ago> The cool thing was I also wrapped the database lock under the distributed in memory lock so in the case of a net split the database’s lock’s got my back. In normal circumstances it made things scalable because the in memory lock would prevent the client from connecting to the database until the in memory lock was let go. how did you coordinate this, since both are different systems altogether? edit: I went through the video at 1.5x speed and I understand it now. This is the grand idea: 1. Use a separate distributed lock manager, get lock on the wallet. This lock is in-memory 2. Start transaction on DB and make changes 3. Release the lock 4. Other transactions wait at #1, since they can't get the lock. Thus this reduces the overall load on the DB. This is cool though!
- zacksiri 3y agoYou can see this video. https://youtu.be/v-n8L-DiPL4 https://youtu.be/v-n8L-DiPL4 Update: Thx for going through it! You got the idea.
- hiram112 3y agoI watched the beginning of the video but it's over an hour and relatively slow going. I don't know Elixer or frameworks around it. But I'm guessing you basically just used something like Zookeeper to do distributed locks at the API call level. Only when they got that lock would they then be given DB access, which then ensured the DB itself wouldn't grind to a halt as many calls were all locking tables at the same time. So what was the solution to returning status to the caller? Did you just give them a ticket which they could then poll status later? Meanwhile, the individual servers just put the requests on a local queue and spin in a thread till they get the lock from Zookeeper (or similar) and can access the DB?
- KingOfCoders 3y ago"memory transactional guarantee" This does not exist, at least those then are not ACID, what many people understand as transactions. "ACID (atomicity, consistency, isolation, durability)". In-memory - usually (battery,...) - is not durable.
- zacksiri 3y agoWell aware, as I mentioned I had a safety net baked in.