Особенность DynamoDB, о которой вы думаете, - это условные записи. DynamoDB не поддерживает «блокировку» изначально, но вы можете использовать условные записи для реализации системы аренды или блокировки, которая должна выполнить то, что вы хотите, используя DynamoDB.
Первое, что нужно решить, - это если вы хотите внедрить систему на основе лизинга или систему на основе блокировки. Основное различие заключается в том, что аренда автоматически истекает, если она не продлевается в течение определенного периода времени, в то время как блокировка никогда не будет автоматически истекать. Вообще говоря, аренда имеет лучшие характеристики при большинстве обстоятельств при использовании распределенной системы. Например, если главный узел умирает, резервный узел будет захвачен при истечении срока аренды, но если бы он был блокировкой, он не перестал бы, пока другая система не выпустила блокировку.
Систему, основанную на блокировке, можно рассматривать как частный случай системы на основе аренды, где срок действия аренды бесконечно в будущем, поэтому я расскажу о том, как реализовать систему аренды в DynamoDB.
, как вы бы реализовать систему аренды в DynamoDB должен иметь таблицу, которая будет иметь записи, где каждый из них представляет другую аренду. Дизайн таблица может выглядеть следующим образом:
- leaseId (Hash Key)
- RESOURCEID (только набор, если срок аренды назначается с тем, кто держит его)
- leaseExpiration (только устанавливается, если срок аренды назначается , когда срок аренды истекает)
Приведенный выше проект предполагает, что ресурсы, известные аренде, которые они пытаются контролировать.
Следующий алгоритм описывает, какие действия требуются от сервера для получения:
if (not holding lease) then
read record from DynamoDB using leaseId
if (resourceId is not set) then
# lease appears to be available
perform conditional write on leaseId record
# set resourceId to our ID and leaseExpiration to time in future
# with condition that resourceId and leaseExpiration are not set
if (conditional write succeeds) then
# we have the lease!
return true
else
# failed to get the lease
return false
done
else if (leaseExpiration is past)
# lease has expired so lets attempt to take it
perform conditional write on leaseId record
# set resourceId to our ID and leaseExpiration to time in future
# with condition that resourceId and leaseExpiration were values we read earlier
if (conditional write succeeds) then
# we have the lease!
return true
else
# failed to get the lease
return false
done
done
else
# we have the lease, so lets keep it
perform conditional write on leaseId record
# set leaseExpiration to time in future
# with condition that resourceId is equal to our ID
if (conditional write succeeds) then
# we still have the lease!
return true
else
# we lost our lease
return false
done
done
Если весь сервер, что защищен, то выше алгоритм, по существу, работает в цикле. Если ресурс имеет аренду, он должен быть запущен до истечения срока аренды, чтобы обеспечить его сохранение. Если ресурс не имеет аренды, он должен немного подождать, прежде чем пытаться его снова получить.
Если сервер хочет отказаться от блокировки, то было бы выполнить следующий алгоритм:
perform conditional write on leaseId record
# erase resourceId and erase leaseExpiration attributes
# with condition that resourceId is equal to our ID
if (conditional write succeeds) then
# we successfully gave up the lease
else
# the lease was not ours to give up
done