事故经过：
1 15:18收到短信报警：国际酒店调用OMS queryGorderOrderList方法失败；成单接口调用OMS获取token失败。
2 查看checkList发现15:18开始发现调用OMS 订单列表接口响应时间明显变长。
3 业务反馈国际酒店MIS系统查询不到数据，也无法导出数据。怀疑是因为这个引起的。
登录ihotelMs系统
IhotelMis调用OMS返回errorCode
总共调用OMS出现问题3000多次，并且还在调用。
4 查看ihotelMs cpu使用率正常，gc也正常。
5 15:27登录OMS一中心机器，CPU使用率60%以上，并且一直full gc，几乎把老龄带内存全部占满。导致OMS服务不可用，
影响其他业务线。二中心的机器没有问题。
6 15:28重启一中心两台OMS，但是过几分钟又挂了。
7 查看日志曾有人在导出国际酒店半个月的数据，大概两万条，猜测是国际酒店的问题。15:38将ihotel的业务都切到outeroms.
然后国际酒店业务正常，查询OMS没有问题。
8 15:56将OMS全部切到二中心。
9 15:59trainAPI也切到outeroms，服务也正常了。
10 16点以后所有服务正常【OMS一中心没有流量】
11 17:45恢复一中心流量。所有业务正常。
事故分析：
国际酒店MS系统大量调用OMS造成OMS服务不可用，进而影响其他业务线。
分析订单导出代码，发现可能造成死循环：
标红线部分代码，一次调用OMS设置的是分页大小是5000，很容易造成OMS返回失败，如果调用OMS返回失败【可能OMS收到请求，已经执行了查询命令，但是因为网络或者别的异常原因没有返回国际酒店数据】，代码会执行continue，重试去调用OMS，如果再失败再重试。。如果正好有几秒钟的时间，网络不好或者因为OMS系统问题没有返回正常数据，这段代码会一直循环调用OMS，这种大量调用造成OMS系统压力大，OMS堆内存使用过多，更加剧国际酒店这行代码收不到正常数据，恶性循环。。最终造成OMS down掉。
解决方案：
1.代码中写continue的作用是为了防止在业务导出数据，多次查询OMS有一次失败，可以进行重试操作,保证拿到的数据。但是会造成死循环，并且查询OMS订单列表底层已经设置了重试机制，双重重试会加重OMS负担。因此去掉continue。
2. 设置OMS分页大小为5000，很容易造成OMS压力过大，因此设置分页大小为500，分多次调用OMS。
薛天俊
OMS国际酒店
事故经过：
1 15:18收到短信报警：国际酒店调用OMS queryGorderOrderList方法失败；成单接口调用OMS获取token失败。
2 查看checkList发现15:18开始国际酒店开始大量调用OMS 订单列表接口，很不正常。
3 业务反馈国际酒店MIS系统查询不到数据，也无法导出数据。怀疑是因为这个引起的。
登录ihotelMs系统
IhotelMis调用OMS返回errorCode
总共调用OMS出现问题3000多次，并且还在调用。
4 查看ihotelMs cpu使用率正常，gc也正常。
5 15:27登录OMS一中心机器，CPU使用率60%以上，并且一直full gc，几乎把老龄带内存全部占满。导致OMS服务不可用，
影响其他业务线。二中心的机器没有问题。
6 15:28重启一中心两台OMS，但是过几分钟又挂了。
7 查看日志曾有人在导出国际酒店半个月的数据，大概两万条，猜测是国际酒店的问题。15:38将ihotel的业务都切到outeroms.
然后国际酒店业务正常，查询OMS没有问题。
8 15:56将OMS全部切到二中心。
9 15:59trainAPI也切到outeroms，服务也正常了。
10 16点以后所有服务正常【OMS一中心没有流量】
11 17:45恢复一中心流量。所有业务正常。
事故分析：
国际酒店MS系统大量调用OMS造成OMS服务不可用，进而影响其他业务线。
分析订单导出代码，发现可能造成死循环：
标红线部分代码，一次调用OMS设置的是分页大小是5000，很容易造成OMS返回失败，如果调用OMS返回失败【可能OMS收到请求，已经执行了查询命令，但是因为网络或者别的异常原因没有返回国际酒店数据】，代码会执行continue，重试去调用OMS，如果再失败再重试。。如果正好有几秒钟的时间，网络不好或者因为OMS系统问题没有返回正常数据，这段代码会一直循环调用OMS，这种大量调用造成OMS系统压力大，OMS堆内存使用过多，更加剧国际酒店这行代码收不到正常数据，恶性循环。。最终造成OMS down掉。
解决方案：
1.代码中写continue的作用是为了防止在业务导出数据，多次查询OMS有一次失败，可以进行重试操作,保证拿到的数据。但是会造成死循环，并且查询OMS订单列表底层已经设置了重试机制，双重重试会加重OMS负担。因此去掉continue。
2. 设置OMS分页大小为5000，很容易造成OMS压力过大，因此设置分页大小为500，分多次调用OMS。
补充一些：
1.当发现oms一中心的服务处于假死状态时，ops操作重启了一中心的服务，但是一起来就挂了，因为这时候ihotelMis还有大量的三级联查（每次5000条）的查询请求打到一中心（办公网请求都会打到一中心）。
2.oms流量切到二中心，请求也会打到二中心，所以出现了二中心的请求量也很高的现象。
3.ihotelMis引用的omsagent的包刚好有问题，打印不出inOut日志，这也影响了快速定位问题。