1. Обзор
Эта статья описывает опыт оптимизации обработки массовых запросов в системе подачи заявок на основе принципа первого пришёл — первого обслуженного, сосредоточенный на базе данных транзакций. Эта система имеет характерную особенность того, что за короткий промежуток времени происходит концентрация десятков тысяч запросов. Пользователи должны удовлетворять несколько условий, таких как максимальное количество кредитов, количество доступных мест и лимиты бронирования, повторяя операции запроса, подачи и отмены. Поэтому обработка транзакций в базе данных для поддержания целостности данных имеет очень важное значение.
В реальной рабочей среде около 20 000 пользователей одновременно используют услугу, в течение 5-10 минут возникают от 80 000 до 100 000 заявок и запросов на отмену. В такой среде создание информации о заявках и обновление данных о числе заявителей стали ключевыми целями обработки транзакций.
2. Начальная реализация и проблемы с производительностью
После завершения разработки проекта были проведены нагрузочные тесты с использованием Apache JMeter при условиях, аналогичных рабочей среде. На начальном этапе реализации API подачи и API отмены были проверены с момента начала работы API до момента его завершения.Транзакции применяются ко всему диапазонубыло.
Однако имелось много предварительных условий для определения возможности подачи заявки, и также существовали проблемы с производительностью SQL, перенесенными из устаревшей системы. Это привело к увеличению времени обработки API и увеличению времени удержания транзакций. В результате соединение с базой данных удерживалось долгое время, пул соединений стал недостаточнымстал.
В ситуации с большими запросами время ожидания для получения соединения в DBCP увеличилось, и некоторые запросы потерпели неудачу из-за превышения времени ожидания. Проблема возникла из-за того, что нормальный процент ответов не соответствовал ожидаемому уровнюбыла. Конечной целью является то, чтобы все запросы получали нормальные ответы.
3. Процесс улучшения производительности
На первом этапе улучшения были добавлены индексы базы данныхи проведен SQL-тюнинг. В результате скорость поиска увеличилась, а время обработки API уменьшилось. Однако проблема нехватки пула соединений по-прежнему не была решена.
На втором этапе в условиях MSA была проведена служба Увеличить количество PodВыполнено масштабирование. В конечном итоге было запущено около 30 подов.Пропускная способность увеличиваетсяОднако Узкое место существует в соединении с базой данныхПроблема с неудачей запроса не была полностью решена, потому что это было сделано.
На третьем этапе Увеличение количества подключений HikariCP с 10 до 100В результате количество запросов, обрабатываемых одновременно в WAS, увеличилось, однако объем используемой памяти резко возрос, что привело к ошибке Out Of Memory.
На четвертом этапе находится Tomcat Увеличение памяти кучи с 256 МБ до 4 ГБХоть проблема OOM была решена, нехватка соединений продолжает возникать. Однако в целом Уровень отказов несколько снизилсявыполнили.
4. Сбалансировка ресурсов WAS и БД
Суть проблемы заключается не только в нехватке вычислительной мощности, но и в способе использования соединений с базой данных. Если часть запроса DB-соединения становится узким местом, k8s должен перевести этот POD в состояние недоступности, чтобы устранить узкое место, однако Tomcat WAS продолжал получать запросы, что привело к сбоям в запросах.
В связи с этим, Tomcat WAS обрабатывает запросы одновременноКоличество потоков запросов изначально 200 изменено на 50было уменьшено, Количество соединений DBCP сокращено с 100 до 50было перераспределено.
С помощью этих измененийПроблема нехватки соединений с БД существенно уменьшиласьПроизошло. Однако одновременно Количество обрабатываемых запросов ограниченоВ то время как возникли другие ограничения производительности.
Дополнительно существовали ограничения интегрированной базы данных. Поскольку несколько систем делили одну физическую базу данных, доступные возможности были ограничены.Максимальное количество подключений к БД ограниченоЭто было так. Следовательно, просто увеличение количества соединений не решало проблему.
5. Управление запросами и оптимизация транзакций
Для обеспечения операционной устойчивости, используемой в существующей унаследованной системеПовторное внедрение решения ожидания запросов (NetPernel)Это позволило контролировать мгновенные всплески трафика и возникшие в процессе эксплуатации Проблема с массовыми сбоями исчезла.
После этого Минимизация объема транзакцийБыла выполнена работа. Мы переместили запрос данных, которые не требуют изменения в реальном времени и не будут изменены в реальном времени, за пределы транзакционного диапазона из различных условий для определения возможности подачи заявления. Тем самым общее время удержания соединения с БД было сокращено.Количество обрабатываемых запросов увеличиваетсяСделано.
6. Проблема взаимной блокировки и её решение
После оптимизации транзакций возникла новая проблема. В процессе обновления информации о численности заявителей возникла ошибка в запросе select for updateпессимистичный замокМы использовали это, но возникло состояние взаимной блокировки из-за того, что много запросов на одну и ту же запись сосредоточилось.
особенно одна транзакция Ситуация, требующая дополнительного подключения к БДЕсли пул соединений недостаточен, может возникнуть взаимная блокировка. Для решения этой проблемы мы проанализировали максимальное количество соединений, необходимых для каждого запроса и определили соответствующий размер пула соединений .
DB Pool Size = T × (C - 1) + 1Здесь T — это максимальное количество потоков WAS, а C — максимальное количество соединений с базой данных, необходимых для одного запроса. После корректировки настроек на основе этой формулы взаимная блокировка исчезла.
7. Реагирование на превышение количества заявок
В среде массовых запросов произошла ситуация, когда заявки завершались с превышением ограничения . Чтобы решить эту проблему, в качестве основы был взят момент сразу после завершения заявки и выполнена повторная проверка . Поскольку метод проверки заключается в том, чтобы проверять, превысили ли они ограничение по очереди, это можно было проверить независимо от времени.
В результате проверки, если количество заявителей превысило , эту транзакцию необходимо было откатить или аннулировать заявкумы поддерживали согласованность, делая это. Благодаря этому мы смогли обеспечить точность окончательных данных.
8. Переход с оптимистичной блокировки на пессимистичную блокировку
Результаты анализа производительности показывают, что пессимистические блокировки (Pessimistice Lock) являются основными в условиях массовых запросов является узким местоми, таким образом, пессимистическая блокировочная структура Изменение структуры на основе оптимистичной блокировки (Optimistic Lock)выполнено.
Чтобы применить оптимистичный лакСвойство времени последнего изменения версииЯ использовал это. Я настроил систему так, чтобы версия увеличивалась каждый раз, когда время изменения сущности меняется, и чтобы исключение OptimisticLockException вызывалось в случае конфликта.
Также Функция Spring Retryс использованием При возникновении столкновения Исключение как условие Автоматическая перезапускбыло осуществлено. Интервал перезапуска установлен менее 0,5 секунды, и реализована возможность до 10 попыток перезапуска.
После этого изменения структуры эффективность использования подключений к базе данных значительно увеличилась. Проблема взаимного блокирования фактически исчезла, и проблема нехватки подключений также была решена. В конечном итоге Количество потоков WAS 50и Количество подключений к БД 20на данном уровне также обеспечивало стабильную работу.
9. Заключение
Этот случай показывает, что простое увеличение серверов или количества подключений не решает проблему обработки большого количества запросов. Важно точно проанализировать реальные узкие места, минимизировать диапазон транзакций и выбрать подходящую стратегию блокировок.
В частности, переход от пессимистической блокировки к оптимистической и внедрение стратегий повторных попыток стали одним из самых эффективных способов улучшения. Кроме того, балансировка между пулом подключений к базе данных, количеством потоков WAS и диапазоном транзакций является ключевым фактором, обеспечивающим стабильность и производительность системы обработки большого объема запросов.
На основе этого опыта можно выделить важные элементы, которые можно применить в проектировании различных систем с высоким трафиком, таких как система записи, система бронирования, участие в событиях, продажи по принципу «первый пришёл — первый обслужен».
Daniel(K)