«Одна блокировка, два предложения и три обновления» антипараллельной схемы Alipay

Архитектура

Каждый год Alipay демонстрирует свои превосходные технические возможности в турнирах Double 11 и Double 12. Эта способность проявляется не только в обработке доступа с высоким TPS, но и в почти полном отсутствии ошибок и повторных платежей.Как это достигается?

Это правда, что для достижения технической цели не совершать ошибок при высоком уровне параллелизма Alipay приложил много усилий, таких как идемпотентная обработка, использование распределенных транзакций и т. д., но я лично считаю, что наиболее важным моментом «Один замок и два». Приговорен к трем обновлениям» — вроде бы ничем не примечательный слоган.

Что такое «одна блокировка, два предложения, три обновления»? Проще говоря, когда приходит любой параллельный запрос

  1. Давайте сначала заблокируем связанный документ
  2. Затем определите статус связанного документа, был ли соответствующий статус обновлен ранее
  3. Если на основе суждения на шаге 2 соответствующее состояние ранее не запрашивалось для обновления, этот запрос может быть обновлен, и соответствующая бизнес-логика может быть завершена. Если состояние было обновлено ранее, в этот раз оно не может быть обновлено, а бизнес-логика не может быть завершена.

Схема

Без лишних слов перейдем непосредственно к коду:

//第1步锁当前支付单
PaymentInfo resultPaymentInfo = commonPayCoreService
  .queryPaymentForUpdate(createPaymentInfo.getId());
if (resultPaymentInfo.isFinalStatus()) {
      //第2步，判断当前支付单状态，如果是终态，则直接返回
       //不做任何更新
      return resultPaymentInfo;
}
//第3步更新当前支付单状态到终态，并完成相关业务逻辑(支付成功)
 payCoreService.updateRequestResult(payChannelResult);

Исходя из вышеприведенной схемы, можно на 100% гарантировать отсутствие проблемы повторного обновления в случае параллелизма.По идее, перед каждым изменением конечного автомата необходимо судить, изменилось ли состояние при условии параллелизма безопасность.

Что произойдет, если шаг 1 или 2 отсутствует, давайте посмотрим:

Шаг 1 отсутствует

Шаг 2 отсутствует![Нет шага 2 process.png]

Пока эти 3 шага используются в качестве нашей спецификации кода, можно избежать большинства проблем с параллельными повторяющимися операциями. То же самое верно для обработки асинхронных одновременных и повторяющихся сообщений.После углубления суждения конечного автомата он также может решать проблему неупорядоченных сообщений.

Для использования замков вы можете выбрать [пессимистические замки и оптимистичные замки] в соответствии с реальной ситуацией. Мы подробно обсудим методы реализации и подводные камни пессимистических блокировок (блокировок строк базы данных) и оптимистичных блокировок (блокировок версии базы данных или распределенных блокировок) позже.

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

В предыдущем стресс-тесте Ant Financial система расчетов, за которую я отвечал, имела около 10 вызовов SQL и один удаленный вызов (около 100 мс), а общая стоимость процесса составила около 180 мс. В стресс-тесте на 4-ядерной 8G-машине параллелизм java-сервисов может достигать 150TPS, результаты удовлетворительные, с горизонтальным расширением серверов проблем нет.

Во всей технической архитектуре Alipay есть только одна сцена, которая обновляется напрямую без блокировок и суждений, то есть красные конверты Весеннего фестиваля Wufu 2016, к которым обращаются миллионы TPS.Чтобы обеспечить бесперебойную работу пользователей, приносится в жертву безопасность суждения о статусе. , сделайте примирение постфактум (хотя это не поможет, если это неправильно :) )

Категории