1 Обзор обязанностей системы расчетов по бухгалтерскому учету

Система расчетов по счетам – это модуль контроля и управления средствами платежной системы, который подразделяется на:

1.1 Аккаунты

Система бухгалтерского учета предоставляет внешним клиентам и внутренним менеджерам различные бухгалтерские документы, бухгалтерские книги и финансовую отчетность, соответствующие внутреннему финансовому учету компании. Обычно ее разделяют на:

• Модуль учета в режиме реального времени,Отвечает за обновление баланса счета клиента в режиме онлайн.
• Модуль пакетной обработки в конце дня,Отвечает за проверку баланса на конец дня и заполнение статистики бухгалтерского отчета.

1.2 Клиринг и расчеты

Конечной целью модуля расчета средств платежного бизнеса является проведение платежа с продавцом. Его функции включают в себя:

• Клиринг заключается в расчете клиентских резервов, комиссий мерчанта, банковских издержек и других сумм операции на основании результатов операции и условий договора, а также уточнения сумм к получению и оплате по каждому клиенту.
• Расчет (Расчет) заключается в завершении перевода денежных средств на суммы дебиторской и кредиторской задолженности, возникшие в результате расчета в соответствии с положениями расчетного цикла, окончательно завершающего расчет как товаров, так и платежей;
• Сверка (Сверка), в ходе которой участники торгов проверяют и подтверждают полученные и выплаченные расчетные платежи, чтобы убедиться в том, что их собственные права и интересы не затрагиваются.

2 Строительный фокус

Система бухгалтерского клиринга и расчетов берет на себя обработку средств всех платежных операций. Помимо соблюдения основных правил расчетного бизнеса и правил финансового учета, необходимо принять дополнительные соображения, исходя из характеристик бизнеса интернет-платежей:

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

3 Функциональная архитектура системы

В сценарии трехсторонней оплаты учет и расчеты являются необходимыми частями транзакции. Запросы на учет и расчеты поступают из платежной системы транзакции.

3.1 Стандартный поток информации о вводе и расчетах для платежных операций

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

Итак, почему нам нужно выполнять ввод транзакций и запросы на клиринговые расчеты отдельно и параллельно?

• Размеры Счета должны соответствовать притоку и оттоку капитала по сделке один к одному.,Комбинированная оплата и сценарии комбинированной оплаты,Один платеж не может полностью соответствовать одному расчету,Правила разделения заказов должны быть четко прописаны в системе платежных операций.,Отправка Клиринга и расчетов в режиме мерчанта,Отчет Счета по аналитике платежного поручения
• Счетаи Клиринг и расчетыотдельный,Слабую проверку можно выполнить внутренне.,Даже если один из них пойдет не так,Также гарантируется отсутствие потерь капитала.,Снизить финансовый риск

После того как система клиринга и расчетов по счетам получает платежное поручение, она проектирует структуру системы клиринга и расчетов на основе бизнес-процесса, правил бухгалтерского учета и правил расчетов:

1. Передний интерфейс Внешняя система предоставляет различные протокольные службы для завершения логики бухгалтерских операций и расчетов. Основная обработка:

• контроль потока：интерфейсконтроль поток, для предотвращения пиков трафика, контроль единого счета, для предотвращения перегрева; аккаунт Влияние
• Калибровочный центр：Полная проверка целостности транзакции、Проверка идемпотентности、Наличие проверки статуса аккаунта и т.д.
• центр принятия решений：завершить транзакциюиправила бухгалтерского учета、правила сопоставление расчетов при обработке решений о понижении уровня бизнеса в рамках механизма автоматического выключателя

2. Обработка расчетного счета,Основной процессинговый модуль поселка Счета. Эта часть бизнеса основана на традиционных правилах расчетного бизнеса и правилах бухгалтерского учета Счета.,Реализуйте автоматизированный расчетный бизнес, бухгалтерский бизнес и бухгалтерский отчет с помощью технических средств.

4 Технические трудности

4.1 Горячие аккаунты

То есть счета с чрезвычайно высокой частотой появляются в течение определенного периода времени в ходе обычного торгового процесса. Если высокая частота вызвана повторными попытками базы данных или ручным восстановлением сбоев транзакций, горячие учетные записи обычно не используются.

Учетная обработка не может избежать блокировок строк базы данных. Если транзакция базы данных обработки учетной записи занимает 10 мс, максимальное значение TPS для горячей обработки учетной записи составляет 100. Как только пороговое значение будет превышено, частая конкуренция за блокировку приведет к внезапному падению производительности базы данных.

Горячие категории аккаунтов:

4.1.1 Точки депозита

Обычной практикой для горячих точек депозита является буферизация депозита, буферизация депозитной транзакции и выполнение учетной обработки в соответствии с определенной скоростью обработки, чтобы скорость бухгалтерской обработки была ниже порогового значения TPS, чтобы обеспечить стабильную производительность базы данных, если она еще существует; проблема во время обработки буферизации транзакций. Давление, вы можете использовать суммарную буферизацию.

4.1.2 Точки вывода средств

Если для точек доступа для вывода используется буферизация, это может привести к неблагоприятным последствиям и обычно не используется. Обычными решениями для точек доступа являются:

① Перезапись уровня драйвера базы данных.

Уровень драйвера базы данных обнаруживает блокировки строк базы данных, объединяет обновления в течение определенного периода времени и единообразно возвращает результаты обработки, аналогично сводному учету, что снижает частоту обновлений горячих точек.

② Горизонтальное разделение базы данных

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

③ Реализация прикладного уровня

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

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

4.2 Модуль бизнес-процессинга

4.2.0 Блок-схема

4.2.1 Обработка остатков на счетах в режиме реального времени

• Принять запрос клиента на вывод средств,Пересылается в модуль кэш-обработки баланса счета на обработку.
• сделать реальную базу работа баланса данных, прием запросов от модуля обработки или модуля регулярной проверки сводных обновлений кэш-базы данных

4.2.2 Обработка кэширования баланса счета

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

4.2.3 Обработка временной компенсации

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

5 разделений базы данных

Данные расчетов по счету разделяются по назначению:

• Каждая транзакция записывает стороны дебета и кредита, чтобы облегчить проверку баланса на конец дня и удовлетворить требования к бухгалтерским ваучерам. Необходимость удовлетворения ежедневных статистических требований по транзакциям
• Требования к запросу на расчетный счет продавца, продавец T+1 День нужно проверить T Данные ежедневного отчета о расчетах Необходимость удовлетворения ежедневных запросов торговцев в режиме реального времени.
• У мелких и микроторговцев разные расчетные циклы и длительные циклы сверки. Необходимо удовлетворить потребности мелких и микроторговцев в чтении ежемесячных или даже квартальных счетов.

Правила разделения таблиц базы данных на основе горячих учетных записей и основных требований:

Сначала выполните разделение по атрибутам клиентов:

• данные участника канала капитала должны соответствовать ежедневной сводке и T-2 Для требований ежедневной сверки эта часть данных разделяется на ежедневной основе. Чтобы избежать транзакций, произошедших в течение одного дня, заказы разделяются. hash Разбейте на разные таблицы, постарайтесь, чтобы записи в одной таблице были в пределах нескольких миллионов.
• Данные продавца, поскольку платежные предприятия делятся на мелких и микро-торговцев и KA Торговец. У этих двух типов торговцев разные требования.
  • Торговцы КА имеют большой поток капитала,Большое количество транзакций,Запросить ежедневный расчет,Разделить по продавцу + дата + номер заказа,Контролируйте одну запись в пределах нескольких миллионов,Гарантированная эффективность запросов продавца за один день
  • Малые и микроторговцы с небольшим объемом транзакций и длительным периодом выполнения запросов разделяются только по уровню номера торговца.

6 Правила расчетов

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

6.1 Блок-схема выполнения

Подписывайтесь на меня и следите за этой серией рубрик, мы продолжим следующую!

Об авторе: технический эксперт и архитектор государственного предприятия в Шанхае, имеющий передовой опыт исследований и разработок в серверной части многих крупных производителей, ведущий блоггер-эксперт в крупных технических сообществах и основатель Programming Select Network. Он имеет богатый опыт руководства командами и глубокое накопление бизнес-структур и решений.

ссылка:

• Сеть выбора программирования

Эта статья опубликована на платформе Blog One Article Multiple Posting Platform. OpenWrite выпускать!