标签：无法 业务 事务 占用 压力 概率 比较 判断 win32
书接上回，继续分享。
通用报文解析服务，用C#开发，经历了三版更新，支撑起了关区内的绝大多数数据交换业务，截止至今，每日收发报文约20万，数据量约5G，平均延迟在1分钟内。
回想起那些半夜处理积压报文的场景，不胜唏嘘，决定把这个演进过程向大家讲述一下。回顾历史，展望未来，如果能给大家一些启发，是再好不过的了。
（第二版）
开发第二版时，更换了底层框架，使用IOC控制反转、DDD领域驱动等设计思想，增加了将报文存放在数据库中的功能，并且分为运行时表和历史表，分别可以查询。数据库用的SQLServer2008 R2
不过这都不是重要的，最重要的是，变成多线程了，将多个操作通过线程形成流水作业，一共有以下几个线程：
可见FileReceiver线程和FileParser线程无需互相等待，真正实现了流水作业。执行效率得到了很大提升。
流程图如下所示，包含了主要的线程FileReceiver和FileParser。之所以叫V2.1，是因为这是经过一次改进之后的流程。
这个新的架构注定要历经磨难才能成熟，不断有新问题困扰着我们。
（1）文件枚举。
有个老问题没有解决，那就是接收目录中文件一多（5000以上），FileReceiver就像死了一样，好久才能读取一个文件，新的报文还在不断涌入，形成恶性循环，如果没人干预，就一直堵到天荒地老。
后来发现了原因，C#中的获取文件的方法是Directory.GetFiles()，这个方法用过的都知道，文件一多，执行速度是很慢的，因为他要把所有文件名都枚举出来后再返回结果。
还是多亏了小蔡，改成了调用Win32 API FindFirstFile、FindNextFile方法，读文件不再等待，秒回！
其实.Net4.0后可以用Directory.EnumerateFiles()方法啊，一样可以枚举到文件。当年还没有这个方法的说，后来为了稳妥就没有再改。
（2）报文优先级
改了文件枚举了之后，解析目录不再堵成一锅粥了，但是数据库中却排起了长队。就像景区大门变宽了，人进的多了，可是里边变堵了。
那段时间正好有新的报文种类，从预订系统发送过来，实时性要求不高，但量很大。这让那些需要及时解析的报文也跟着排起了长队，那段时间真是看着干着急，后来想了个办法建个临时表，每天将待解析的数据倒来倒去。于是就诞生了优先级的设置，FileParser线程优先扫描优先级高的报文，执行。等没有高优先级的报文时，再解析优先级低的报文。
某些报文的实时性算是保证了，但是其他优先级较低的报文却总是得不到光顾，一堵又是一整天。
FileParser就那么一个线程，处理能力已经大大跟不上报文的增长了，需要考虑再拆分了，于是诞生了报文分组。
（3）报文分组
逼迫我考虑报文分组的原因，除了上述原因外，还有一个关键原因，就是某种报文总是引起FileParser线程假死，catch不到异常，又不见动静，这时候只能重启服务。一周出现3-5次，时间不固定，又没有有效的手段及时发现，往往是业务上打电话来报故障了，才意识到报文已经积压了好几万。重启后，半天才能处理完。那阵子，一听到手机响就紧张。o(╯□╰)o
我认为，不能让一种报文的解析影响其他报文，比如某一个系统有2报文，都入他的业务数据，他的数据可能会故障，可能会慢，可能会引起假死，但其他报文也会受到牵连，整个系统就很容易瘫痪。系统故障的概率就变成了ρ = 1 - (1 - ρ1)(1 - ρ2)(1 - ρ3)...
（设ρn是第n个子系统的故障概率）
将各报文类型按照业务相关性进行分组GROUP1，GROUP2，GROUP3...。再按照分组分别建立FileParser线程，每个FileParser只扫描所属分组的报文，执行解析。这样某个报文的故障或缓慢只会影响所在分组，基本就只影响某一个系统。而且出现了问题也容易定位原因。
（4）线程监控
线程多了，运维的问题也随之而来，一个线程假死都会引起巨大的问题，如何及时发现这些问题成了当务之急。
我们的底层框架中Windows服务支持多线程，每个线程可以设定间隔自动执行，每次执行都会更新最近执行时间和执行结果，然后进入等待状态，等待下一次被调用。
于是在我的提议下，我们增加了线程状态监控功能，并且对外提供WCF接口，由Windows服务作为Host承载。结合我们单位的OAM监控系统，自动以短信方式推送，非常方便，让我养成了没事就看看短信的好习惯，感觉心（tí）旷（xīn）神（diào）怡（dǎn）。
总之这件事让系统在人工的维护下，就算bug不断，还是能够相对稳固运行的。
（5）轮询智能变速
报文分组了，FileParser线程也从一个变成了多个，这时新问题又来了，报文数据库的入库和查询速度都变得有些慢了，导致整体上效率比没分组时没高多少。用SqlProfilor分析，也没有显著比较慢的语句，但是现象就是大家都慢了，那段时间我百思不得其解，甚至开始合并一些分组来减少线程。
后来我对着配置文件终于参悟到了原因，当初为了提高效率，每个线程的轮询间隔时间都很短（最短20ms，长一点的250ms），FileParser线程一多，这让数据库根本难以承受啊，怪不得呢。
详细的原因应该是这样，某些分组的FileParser总会很闲，好久不来一个报文，于是就在那里20ms一次的去做SELECT，占用了大部分资源，使得那些有活等着干的FileParser线程被排挤，得不到应有的资源。
就像去工地搬砖，总是有几个人在不停轮流的问工头：“有没有我要搬的砖？”，工头：“没有o(╯□╰)o”。其他人就只能每次排着队等着问工头。解决的办法就是没活干的人可以偷点懒，歇五分钟再来问嘛。于是我让他们都来个智能变速，FileParser线程的当前查询结果是0条时，原地sleep10秒钟。同理，FileReceiver也这样处理。放到正式环境后，效果真是立竿见影。
（6）集群化改造
经过上面一系列的改进，已经能够比较稳定的运行了。但是每日的报文量在不断的增加，从一开始的一万份到两万，再到10万，高峰时的处理速度逐渐跟不上了，延迟有时候能达到1个多小时。
这时，本地磁盘接收目录的读写效率成为了瓶颈。同时，某些解析线程任务量格外大，导致跟不上报文接收的速度了。
于是我开始考虑系统的横向扩展，在一台新的虚拟机上部署新的报文解析服务，将一半报文改在那里接收，同时通过配置，让他启动一部分分组的FileParser线程，来缓解原来一台服务器的压力。
理论上，这样的扩展可以一直做下去，效率满意为止，或直到不能再细分。
（7）失败自动重试
报文解析过程中总会遇到各种意外问题，例如事务失败，网络超时，数据库无法连接，数据库根本无法连接等等，有些问题需要人工干预才能解决，但是像网络超时、事务失败这些一般通过重试就能自动解决的问题，却频繁出现，很是烦人。于是我想到在解析时如果抛出异常，就判断一下异常消息是否带有“事务”，“超时”，“timeout”等字样，如果是，就自动延时一定时间再解析一遍，最多重试3次。
到此几乎能做的改进都做完了，剩下的也就是小修小补的了。但始终有个问题还在困扰我，那就是程序集版本的问题。解析器程序集来自于不同的项目小组，他们会引用一些公共的组件库，这些组件库会有不同的版本，有时候一家更新了公共组件库，就导致更新后不能运行。有时我更新了报文解析服务的组件库，可能导致大家都不能运行，都得用我的组件库版本重新编译、发布。每当出现这种问题的时候，原因特别不好排查，不知道是谁家版本不一致。曾经用过一个折中的办法，就是我提供一套我的公共组件库版本，大家都统一用这个版本编译、发布。而我也基本上不能更新公共组件库了。
为了解决这个“终极问题”，我们引入了RabbitMQ。下一篇再详细讲讲。
虽然问题层出不穷，但是解决问题的过程很有乐趣，解决问题时也很有成就感，希望能给大家一些启发。
通用报文解析服务的演进之路（基于磁盘目录的分布式消息消费者服务）之二
标签：无法 业务 事务 占用 压力 概率 比较 判断 win32
原文地址：http://www.cnblogs.com/pleiades/p/6716353.html
