forked from OpenTSDB/opentsdb
-
Notifications
You must be signed in to change notification settings - Fork 8
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Remove the need for explicit row locks when allocating UIDs.
The existing code with explicit row locks exhibited very poor performance, and also prevented multiple TSDs from allocating UIDs concurrently. The new approach consists in: 1. Performing an atomic increment to grab a new UID. 2. CAS'ing (CompareAndSet) the reverse mapping (uid => name) 3. CAS'ing the forward mapping (name => uid) If we die after step 1, we waste an UID. If we die after step 2, we just end up with an orphaned reverse mapping (harmless). When two TSDs race to assign a UID to the same name, one of them will fail to CAS the forward mapping at step 3, and will retry to find the UID assigned by the winning TSD. When that occurs, the only net consequence is that a UID will have been wasted by the losing TSD, whereas the previous implementation wouldn't waste one when this happened. The 'uid fsck' command can easily detect orphaned or wasted UIDs, and we could conceivably put them on some kind of a free list in the future to re-allocate them. If two TSDs are running side-by-side, and one uses the old method while the other uses the new lock-less method, things still work as expected. There are two possible scenarios: - Old TSD goes first, locks the MAXID row, and does its thing. The new TSD will have to wait until the row lock is released for its atomic increment to go through. - The new TSD goes first, atomically increments the MAXID row, and does its thing. The second TSD locks the MAXID row and proceeds to allocate its own ID concurrently.
- Loading branch information
Showing
3 changed files
with
186 additions
and
278 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.