Алгоритм совместных покупок
Я хотел бы финансировать некоторые вещи. А некоторые нет. Неделю назад сочинил своеобразный алгоритм, вбросил его в твиттер на критику.
Основные идеи алгоритма
- Хочешь что-то сделать, но дорого делать это одному.
- Инициируешь голосование в группе.
- Люди могут отказаться и их это вообще не будет касаться.
- Будут ли они пользоваться совместно приобретённым благом или нет — за рамками этого алгоритма.
- Расходы делятся тем или иным способом среди согласившихся.
Вообще это близко к PAXOS и здесь нужно достичь консенсуса — тратим ли группой деньги или нет. Я использую в этой схеме координатора, им может быть инициатор голосования или выделенный человек, значения не имеет, мы не заморачиваемся за отказоустойчивость, так как алгоритм предназначен для исполнения людьми.
Пример
- Координатор: VOTE-REQUEST, давайте купим видеонаблюдение в подъезд, стоит 50000 рублей.
- Собственник1: VOTE, готов скинуть 5000 рублей.
- Собственник2. REJECT
- …
- СобственникN. VOTE, готов скинуть 2500 рублей.
- Координатор: суммирует числа, присланные в VOTE-сообщениях.
- Координатор: принимает предварительное решение и сумму, требуемую от каждого участника.
- Координатор: ADOPT, скидываемся по 2000 рублей
- Собственник1: ОК
- …
- СобственникN: ОК
- Координатор: ACCEPT, COMMIT
Касательно пункта 7 — здесь может быть два варианта развития событий. Все собственники скидываются поровну или по минимально возможной сумме.
Случай “поровну” не особо осмысленный и справедливый как может показаться — он отсекает людей, готовых скинуться, но не дотягивающих до усреднённого необходимого значения. То есть человек который хотел бы скинуть 1000 рублей будет отброшен, а остальным придётся скидываться на 1000/N больше (каждому). Если кажется что предлагать меньше — нечестная стратегия, то нужно вспомнить, что есть стратегия не платить вообще — REJECT. Но в обоих случаях есть риск не добиться общей цели, так как не хватит “предварительно собранных” денег.
В случае с “минимально возможной суммой” от разных людей могут потребоваться разные суммы. В таком случае в пункте 8 сообщение ADOPT будет не broadcast, а unicast.