Можно в микросервисы вынести части которые не требуют ACID — отчеты там и отображения, куча всего связанного с UI, логами и т.п.
Вытащить отдельно кучу интеграций — когда надо данные залить в систему извне или вылить наружу.
Монолит прилично урежется, останется один (ну или небольшое количество если удачно поделите) большой сервис который транзакционный.
Будет пачка микро и один макро сервис уже позитив. Время деплоя меньше, части менее зависимы. Хотя оркестрация тоже геморрой.
Я не автор, но могу описать некоторые из подходов.
1. разбить на шаги, каждый из которых это atomic message.
Начал проводить платеж, снял деньги с одного, записал состояние в очередь из которой два выхода — снял со второго и закомитил либо не получилось и сложил новое событие на возврат денег первому.
Этакий конечный автомат и по сути ручная многоступенчатая транзакция на бизнес логике. Иногда без этого никак если между шагами 1 и два есть например внешний сервис (допустим надо провести проверку на мошенничество, которая может занять время). А деньги снимаются, чтобы параллельный перевод не схватил.
2. логическое укрупнение сервисов, чтобы транзакция целиком проходила внутри сервиса.
Получается довольно редко, но иногда прокатывает если удается по бизнес логике.
3. распределенная транзакция.
Это может быть как двухфазный коммит (условно если разные базы) или передача transactionId как параметра.
Можно, но необязательно. В повых версиях спринг сам разберется. А вообще рекомендуют по возможности @Autowire на конструктор. Так меньше шансов что останется не инициализированными. Но в случае циклических зависимостей не прокатит.
@Controller
public class IndexController {
final VisitsRepository visitsRepository;
public IndexController(VisitsRepository visitsRepository) {
this.visitsRepository = visitsRepository;
}
...
}
Тут наверное @Autowire потерялся на конструкторе. Чтоб понятнее было.
Это не принципиально. Для реальной скорости надо использовать массивы, а не inner class.
Я знаю как ускорять java. Так написано чтобы было понятнее как работает алгоритм.
Но насчет prime_count^2 нет.
для 2 мы сделаем не более n/2 сложений, для 3 — n/3 и т.д.
получаем n/2 + n/3 + n/5… то есть n * log log(n)
а если 2 выкинуть четные незачем проверять. И вот чуть ниже есть коммент что стартовать можно с candidate^2 и перепрыгивать при суммировании
if (p.lastCrossed < candidate) {
p.lastCrossed += p.prime * Math.round((candidate — p.lastCrossed) / p.prime());
}
то сложность поменьше будет. Хотя так сходу не могу прикинуть число. Буду думать.
Вытащить отдельно кучу интеграций — когда надо данные залить в систему извне или вылить наружу.
Монолит прилично урежется, останется один (ну или небольшое количество если удачно поделите) большой сервис который транзакционный.
Будет пачка микро и один макро сервис уже позитив. Время деплоя меньше, части менее зависимы. Хотя оркестрация тоже геморрой.
1. разбить на шаги, каждый из которых это atomic message.
Начал проводить платеж, снял деньги с одного, записал состояние в очередь из которой два выхода — снял со второго и закомитил либо не получилось и сложил новое событие на возврат денег первому.
Этакий конечный автомат и по сути ручная многоступенчатая транзакция на бизнес логике. Иногда без этого никак если между шагами 1 и два есть например внешний сервис (допустим надо провести проверку на мошенничество, которая может занять время). А деньги снимаются, чтобы параллельный перевод не схватил.
2. логическое укрупнение сервисов, чтобы транзакция целиком проходила внутри сервиса.
Получается довольно редко, но иногда прокатывает если удается по бизнес логике.
3. распределенная транзакция.
Это может быть как двухфазный коммит (условно если разные базы) или передача transactionId как параметра.
Тут наверное @Autowire потерялся на конструкторе. Чтоб понятнее было.
Я знаю как ускорять java. Так написано чтобы было понятнее как работает алгоритм.
По операциям n log(log(n)) (n/2 + n/3 + n/5+… n/Pk… +)
BigInteger может быть. java выбрана потому как для меня более знакомый язык. Корректнее бы на С писать выжимая все возможное побитово.
Вероятностный мало. Надо доказывать что это простое, а проверок будет слишком много.
В общем компьютер должен работать, а человек думать. Буду думать дальше. Спасибо за коммент.
Но насчет prime_count^2 нет.
для 2 мы сделаем не более n/2 сложений, для 3 — n/3 и т.д.
получаем n/2 + n/3 + n/5… то есть n * log log(n)
а если 2 выкинуть четные незачем проверять. И вот чуть ниже есть коммент что стартовать можно с candidate^2 и перепрыгивать при суммировании
if (p.lastCrossed < candidate) {
p.lastCrossed += p.prime * Math.round((candidate — p.lastCrossed) / p.prime());
}
то сложность поменьше будет. Хотя так сходу не могу прикинуть число. Буду думать.
2. Если надо искать тысячебитовые числа куда их складывать?