修订客户端可以接收传入消息，但不能发送传出心跳消息

问题描述

我们已经构建了一个修复客户端。修复客户端可以接收传入消息，但不能发送传出心跳消息，也不能回复TestRequest消息。在发送完最后一个心跳后，触发了某些操作以停止从客户端发送心跳。

修复版本：修复5.0

同一事件之前发生过，那时候我们有一个会话的tcpdump

我们将每个修复会话部署到分离的k8s吊舱中。

1. 我们怀疑这是cpu资源问题，因为在发布时间前后平均负载很高，但是在添加更多cpu内核后仍无法解决。我们认为由于修复程序重新连接，平均负载较高。
2. 我们怀疑这是IO问题，因为我们使用3个会话共享的AWS efs进行日志记录和消息存储。但是在使用pod关联性将3个会话分配给不同的节点后，仍然无法解决该问题。
3. 这也不是网络问题，因为我们可以接收到修复消息，所以其他会话在当时表现良好。我们也已在k8s集群中禁用了 SNAT 。

我们正在使用quickfixj 2.2.0创建一个修订客户端，我们有3个会话，这些会话被部署到单独节点中的k8s pod中。

1. rate 会话以从服务器获取外汇价格
2. 订购会话以从服务器获取交易（执行报告）消息，我们仅向服务器发送登录/心跳/注销消息。
3. 后台办公会话以获取市场状态

我们使用apache camel quickfixj组件来简化编程。它在大多数时间都能正常工作，但是它经常在3个会话中重新连接以修复服务器，频率大约是每月一次，大多数情况下只有2个会话有问题。

class SecuritiesPipeline(object): def close_spider(self,spider): print(spider.crawler.stats.get_stats())

客户端修正事件消息

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☺

在收到来自服务器的TEST消息时的线程转储。顺便说一句，要点来自具有相同部署的我们的开发环境。 https://gist.github.com/hitxiang/345c8f699b4ad1271749e00b7517bef6

我们在quickfixj上启用了调试日志，但是信息不多，仅接收到消息的日志。

解决方法

时间序列中的顺序

1. 20201101-23：56：02.742此时应该发送传出的心跳，看起来正在发送，但在io写入时挂起-处于运行状态
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 EF导致了此问题的发生。 但是来自aws支持的反馈是aws efs方面没有错。 也许这是k8s ec2实例和aws efs之间的网络问题。

1. 首先，我们在所有会话中都使日志记录异步，从而减少断开连接的发生。
2. 第二，对于市场交易，我们将序列文件写入本地磁盘，在市场交易中断开连接已经消失。
3. 第三，最后，在所有会话中，我们都将aws efs替换为aws ebs（以k8s为单位的持久量）。现在效果很好。

顺便说一句，aws ebs不是跨区域的高可用性，但是比修复断开连接要好。