Блог

Мы создали клиент исправления. Клиент исправления может получать входящие сообщения, но не может отправлять исходящие сообщения о сердцебиении или отвечать на сообщение TestRequest после отправки последнего сердцебиения что-то срабатывает, чтобы прекратить отправку сердцебиения со стороны клиента.

версия исправления: fix5.0

Тот же инцидент произошел раньше, у нас есть tcpdump для одного сеанса за это время

мы развертываем каждый сеанс исправления в отдельные модули k8s.

1. Мы сомневались, что это проблема с ресурсами процессора, потому что средняя загрузка высока во время проблемы, но это не решается после добавления дополнительных ядер процессора. мы считаем, что средняя нагрузка высока из-за повторного подключения исправления.
2. Мы сомневались, что это проблема ввода-вывода, потому что мы используем AWS efs, которые используются 3 сеансами для ведения журнала и хранения сообщений. но это все еще не решено после того, как мы используем pod affinity для назначения 3 сеансов разным узлам.
3. Это также не проблема с сетью, поскольку мы можем получать сообщения об исправлениях, другие сеансы в то время работали хорошо. Мы также отключили SNAT в кластере k8s.

Мы используем quickfixj 2.2.0 для создания клиента исправления, у нас есть 3 сеанса, которые развертываются в блоках k8s в отдельных узлах.

1. оцените сеанс, чтобы получить валютную цену с сервера
2. заказать сеанс для получения сообщений о транзакциях (отчет о выполнении) с сервера, мы отправляем только сообщения о входе / сердцебиении / выходе на сервер.
3. сеанс backoffice для получения marketstatus

Мы используем компонент apache camel quickfixj для упрощения программирования. В большинстве случаев это работает хорошо, но повторное подключение к серверам исправления происходит через 3 сеанса, частота примерно раз в месяц, в основном проблемы возникают только в 2 сеансах.

heartbeatInt = 30s

Сообщения о событиях исправления на стороне клиента

 20201004-21:10:53.203 Already disconnected: Verifying message failed: quickfix.SessionException: Logon state is not valid for message (MsgType=1)
20201004-21:10:53.271 MINA session created: local=/172.28.65.164:44974, class org.apache.mina.transport.socket.nio.NioSocketSession, remote=/10.60.45.132:11050
20201004-21:10:53.537 Initiated logon request
20201004-21:10:53.643 Setting DefaultApplVerID (1137=9) from Logon
20201004-21:10:53.643 Logon contains ResetSeqNumFlag=Y, resetting sequence numbers to 1
20201004-21:10:53.643 Received logon
  

Исправление входящих сообщений на стороне клиента

 8=FIXT.1.1☺9=65☺35=0☺34=2513☺49=Quote1☺52=20201004-21:09:02.887☺56=TA_Quote1☺10=186☺
8=FIXT.1.1☺9=65☺35=0☺34=2514☺49=Quote1☺52=20201004-21:09:33.089☺56=TA_Quote1☺10=185☺
8=FIXT.1.1☺9=74☺35=1☺34=2515☺49=Quote1☺52=20201004-21:09:48.090☺56=TA_Quote1☺112=TEST☺10=203☺ 
----- 21:10:53.203 Already disconnected ----
8=FIXT.1.1☺9=87☺35=A☺34=1☺49=Quote1☺52=20201004-21:10:53.639☺56=TA_Quote1☺98=0☺108=30☺141=Y☺1137=9☺10=183☺
8=FIXT.1.1☺9=62☺35=0☺34=2☺49=Quote1☺52=20201004-21:11:23.887☺56=TA_Quote1☺10=026☺
  

Исправление исходящих сообщений на стороне клиента

 8=FIXT.1.1☺9=65☺35=0☺34=2513☺49=TA_Quote1☺52=20201004-21:09:02.884☺56=Quote1☺10=183☺
---- no heartbeat message around 21:09:32 ----
---- 21:10:53.203 Already disconnected ---
8=FIXT.1.1☺9=134☺35=A☺34=1☺49=TA_Quote1☺52=20201004-21:10:53.433☺56=Quote1☺98=0☺108=30☺141=Y☺553=xxxx☺554=xxxxx☺1137=9☺10=098☺
8=FIXT.1.1☺9=62☺35=0☺34=2☺49=TA_Quote1☺52=20201004-21:11:23.884☺56=Quote1☺10=023☺
8=FIXT.1.1☺9=62☺35=0☺34=3☺49=TA_Quote1☺52=20201004-21:11:53.884☺56=Quote1☺10=027☺
  

Дамп потока при получении ТЕСТОВОГО сообщения с сервера.Кстати, суть в нашей среде разработки, которая имеет такое же развертывание.
https://gist.github.com/hitxiang/345c8f699b4ad1271749e00b7517bef6

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

Последовательность во времени последовательная

1. 20201101-23:56:02.742 Исходящее сердцебиение должно быть отправлено в это время, похоже, что оно отправляется, но зависает при записи ввода-вывода в запущенном состоянии
2. 20201101-23:56:18.651 тестовое сообщение со стороны сервера для запуска дампа потока
3. 20201101-22:57:45.654 серверная сторона начала закрывать соединение
4. 20201101-22:57:46.727 дамп потока — правильно
5. 20201101-23:57:48.363 сообщение о входе в систему
6. 20201101-22:58:56.515 дамп потока — слева

Правый (2020-11-01T22:57: 46.727Z): когда он зависает, левый (2020-11-01T22:58: 56.515Z): после повторного подключения

Похоже, что проблема возникла из-за хранилища aws efs, которое мы используем. Но отзывы службы поддержки aws показывают, что на стороне aws efs все в порядке. Возможно, это проблема с сетью между экземпляром k8s ec2 и aws efs.

1. Во-первых, мы делаем ведение журнала асинхронным во всех сеансах, чтобы отключение происходило реже.
2. Во-вторых, для сеанса market мы записываем файлы последовательности на локальный диск, отключение произошло во время сеанса market.
3. В-третьих, наконец, мы заменили aws efs на aws ebs (постоянный объем в k8s) для всех сеансов. Теперь это работает отлично.

Кстати, aws ebs не обеспечивает высокую доступность по всей зоне, но это лучше, чем исправление отключения.