Как обеспечить производительность в многопоточной среде?

Question

[aiwan9]

Добрый день.

Имеется следующая проблема. Есть сервисный класс OrderService. У него есть метод create(Order order, Long companyId), который перед созданием заказа проверяет не превышает ли сумма заказа баланс компании. Код класса примерно следующий.

public class OrderService {
   public Order create(Order order, Long companyId) {
      Company company = companyService.get(companyId);
      checkCompanyBalance(company.getBalance(), order.getSum());
      return create(order);
   }
}

Существует вероятность того, что два пользователя создадут два заказа на компанию одновременно, при этом превысив баланс компании. Чтобы избежать этого делаем наш метод synchronized и все. Но при этом сильно проседает производительность, потому что нет возможности создать заказ на другую компанию.
Какие есть решения у этой проблемы?

Мне приходит в голову только создать пул айдишников компаний, на которые сейчас делают заказы.

public class CompanyPool {
   private Set<Long> companyIds = new HashSet<Long>();

   public synchronized containsAndPut(Long companyId) {
      if(companyIds.contains(companyId)) {
         return false;
      } else {
         companyIds.add(companyId);
         return true;
      }
   }

   public synchronized remove(Long companyId) {
      companyIds.remove(companyId);
   }
}

и переписать метод OrderService#create() следующим образом

public class OrderService {
   private CompanyPool companyPool = new CompanyPool();

   public Order create(Order order, Long companyId) {
      if(companyPool.containsAndPut(companyId)) {
         Company company = companyService.get(companyId);
         checkCompanyBalance(company.getBalance(), order.getSum());
         Order newOrder = create(order);
         companyPool.remove(companyId);
         return newOrder;
      } else {
         // wait till other thread will stop creating order for specified company
      }
}

Насколько жизнеспособно подобное решение? Товарищи, может кто-то решал сходные задачи?

Answer 1

[Алексей Гусейнов]

Использовать СУБД. Это только первые грабли, на которые вы начинаете наступать. Ваше решение плохо поведет себя, если программа упадет. Может получиться так, что деньги спишутся, а заказ не запомнится или наоборот. Причем нужна СУБД с поддержкой транзакций, модные нынче noSQL решения не подойдут или вы напишите поверх них свой транзакционный движок (в документации к mongodb есть пример).

Ну или, если очень хочется, надо переписать
checkCompanyBalance(company.getBalance(), order.getSum());
так, чтобы он входил в критическую секцию (захватывал бы мьютекс, принадлежащий объекту компании), проверял баланс, если денег достаточно, вычитал из баланса сумму, прописывал в список транзакций сообщение, за что было начато списание денег, после чего записывал бы всю эту информацию в энергонезависимую, резервируемую на несколько машин память и, наконец, отпускал мьютекс. Затем создаем заказ, записываем его на такое же надежное хранилище. И, после этого, снова лезем в объект компании и помечаем транзакцию как выполненную.

Comments

[Алексей Гусейнов]

Интересно, кто тот человек, который считает, что надежность в таких сервисах не нужна?
Или может кто-то считает, что эта задача не похожа на захват семафора? Только вместо целочисленного типа используется денежный и операция enter вычитает не единицу, а произвольное значение. Общепринятый способ решения этой задачи — атомарная операция проверки и вычитания. Заметте, что блокировка происходит на очень короткое время, а не на всю операцию заказа сервиса.
Если нужны fine grained блокировки, то объектом блокировки должен быть баланс компании, а не один лок на все компании.

Но еще раз повторяюсь, что надо использовать СУБД, так как хорошее корректное решение описанной задачи приведет к реализации тех же механизмов, что есть в СУБД. И значительно быстрее работать не будет.

[aiwan9]

Приношу свои извинения за путаницу. Классы OrderService, CompanyService и есть классы работы с базой.

@Transactional(rollbackFor = {ServiceException.class, NullPointerException.class, PSQLException.class})
@Service(value = "orderService")
public class OrderService {
   // code
}

Данные о балансе компании хранятся в базе. Чтобы получить актуальный баланс — нужно вытащить ее из базы. Проблема в том, что я не понимал, как сделать «захват мьютекса» этого объекта, ведь если вытащить компанию из базы еще раз, то это уже будет другой объект. gvsmirnov предлагает завести поле

ConcurrentMap<Long, Lock> companyLocks

, где для каждого id компании будет храниться отельный Lock. И насколько я понимаю — вы предлагаете то же самое.

[Алексей Гусейнов]

Я думал, что данные хранятся в памяти и тогда существовал бы один объект компании, в который можно было бы положить лок.
ConcurrentMap<Long, Lock> companyLocks — не клёво потому, что он однопоточный. Все равно остаётся глобальный лок.

А если данные уже хранятся в базе данных, то не надо никаких блокировок в программе. Достаточно использовать придуманные для этого транзакции. Необходимо изменять баланс компании и создавать запрос на сервис в рамках одной транзакции.

Answer 2

[Moxa]

можно сделать synchronized по компании… но это если на каждую компанию есть только один инстанс…

Answer 3

[knott]

Полностью согласен c товарищем gvsmirnov.
Однако, мне кажется, что производительность проседает из-за оверхеда на планировщик, при неудачном взятии потоком блокировки. Поэтому, мне кажется что здесь имеет место быть спинлок на основании AtomicBoolean.

public class OrderService {
  
   private AtomicBoolean locked = new AtomicBoolean(false);

   public Order create(Order order, Long companyId) {
      Order result;

      // Пробовать зайти в крит. секцию.
      while (!locked.compareAndSet(false, true)) {
          Company company = companyService.get(companyId);
          checkCompanyBalance(company.getBalance(), order.getSum());
          result = create(order);

          // Открыть путь другим потокам.
          locked.set(false);
          break;
      }
      return result;
   }
}

Однако этот подход годится только если:

• методы checkCompanyBalance и create выполняются быстро. Иначе ваш код будет только и ждать освобождения блокировки, совершенно бездарно тратя циклы ЦП.
• многопроцессорная система. Нет смысла ждать освобождения блокировки сделанной на другом потоке.

Comments

[knott]

простите, сонный.

Предложенный мною подход стоит применять только если Вас жаба душит иметь ещё одну карту с локами. Из профитов — нету блокировки на создание Order на ту же компанию.