一种高并发环境下交易日志连续输出的机制

原文地址：http://www.xzbu.com/1/view-6507464.htm

本文提出了一种在高并发环境下交易日志连续输出的机制。该方法能够接受日志的并发无序提交，根据日志中交易的交易主键将日志进行逻辑划分，使得同一笔交易日志高度内聚，保证了日志的连续输出，大大提高了日志的可读性和友好性，减少甚至避免了日志分析中对日志的额外处理。 　　【关键词】交易日志 高并发 连续输出 　　交易日志对现代交易系统具有极其重要的意义，其作用主要有三个：问题排查、交易信息归档、交易分析与挖掘。交易日志完整记录了每笔交易的具体执行路径。通过人工查看日志，可以精确把握一笔交易成功、失败以及其他异常信息。目前，联机交易系统在高并发环境下，日志的输出通常是不连续的。一笔交易的日志中无规律地穿插着其他交易的日志信息，这样在日志查阅、问题排查时非常不便，需要在现有日志基础上进一步将一笔交易从众多交易日志中隔离或抽取出来才能得到有效的日志信息。 　　1 系统原理 　　本文提出一种处理机制，在日志被输出到目标日志文件之前，在内存缓冲区中对日志进行分拣，并按照一定的策略或在一定的时机输出日志，使得每笔交易日志高度内聚，即使在高并发环境下亦不存在穿插的现象，同时保证单笔交易日志内部有序。 　　工作原理如图1所示。 　　按照标号，1）首先接收交易系统日志提交，2）将日志做持久化处理，3）然后将日志交由日志处理模块进行实时分拣，4）并按照一定的输出策略进行日志输出，5）最后记录日志快照。对于意外断电或系统崩溃的情况，缓冲区内的日志因没能及时输出而丢失。下次启动时，分别读取持久化日志和日志快照，经日志恢复模块处理后交给日志处理模块，然后强制输出此部分日志，清空持久化日志和日志快照，此后便可重新接受新日志的提交，此时系统恢复到正常的工作状态。 　　2 实施方案 　　由于本方法需要在内存缓冲区内对每条日志进行分拣，日志在被输出到目标文件之前是存放在内存中的。而对于一个应用来说，分配的内存大小是有限的。为了防止因日志条目不断增长造成占用的内存无限增加，日志系统设定一个参数：超时时间timeout。超时时间控制一笔交易的输出时机，当当前时间与交易上次提交时间lasttime的间隔大于超时时间时，此交易的日志被立即输出。 　　对于一笔交易，其都有一个确定的交易主键tkey。对于一条交易日志，都有一个tkey与其关联。若任何两条交易日志的tkey相同，则认为它们同属一笔交易，应被连续输出。 　　以下对各个模块详细阐述。 　　2.1 日志提交 　　当交易系统需要记录日志时，交易系统向日志系统同时提交tkey和与tkey相关的日志信息。具体分两类提交： 　　（1）类提交：同时提交tkey和日志正文msg。 　　（2）类提交：同时提交tkey和结束标志finish。 　　若日志并非一笔交易的最后一条日志，则按交易流程将日志逐条进行a类提交，此步向日志系统提交日志正文msg。若一条日志是交易的最后一条日志，则对这条日志进行a类提交后，同时进行b类提交。此时的b类提交不含日志正文，而是日志结束标志finish。b类提交出现在交易的出口处，通知日志系统一笔交易已结束。一笔交易可能因交易成功、交易失败、系统异常等有多个交易出口，这些出口均需设置b类提交。当系统发生了严重错误时，b类提交可能无法正常完成，此时由超时时间控制日志的输出。 　　2.2 日志持久化 　　为了防止意外断电或系统崩溃等原因导致内存中的日志丢失，日志系统在接收到交易系统的日志提交后，首先将日志实时地、无序地写入磁盘，确切的说，写入到持久化日志文件。日志系统维护一个持久化日志文件，日志以行存放，每行包含tkey和msg。持久化日志文件设定文件大小，采用循环覆盖（rotate）的方式，具体文件大小可以根据交易系统情况而定。另外，对于日志实时性要求很高的情况，可以通过此文件查看在缓存中尚未及时输出的日志。 　　2.3 日志处理 　　日志系统内部维护一个自定义的数据结构Ldata，保存tkey、lasttime和一个有序链表Llist。Llist的每一个节点存放一条日志正文。同时维护一个哈希表Lmap，Lmap以tkey为key，以Ldata为value，是交易在内存中的清单。 　　日志处理模块主要负责接收日志提交和日志输出。当接收到交易系统的提交的日志时，日志处理模块进行判断。若是a类提交，则在Lmap中根据tkey查找对应的Ldata，查找失败则根据tkey创建Ldata并添加到Lmap中，表明这是一笔新的交易，此时Ldata中的lasttime为当前时间，Llist中保存着这笔交易的第一条日志；查找成功则更新Ldata的lasttime为当前时间，并将日志正文添加到Llist中；若是b类提交，则按照提交顺序依次输出Llist中的日志，将tkey从Lmap中移除，并在快照文件中记录相应的tkey。 　　另外，对日志输出进行超时控制，必要时强制输出交易日志。具体来讲，遍历Lmap，按tkey逐个取Ldata。判断当前时间与lasttime的差值，若差值大于timeout，则表明超时发生，立即输出，否则取下一个Ldata。日志输出后，将其对应的tkey从Lmap中移除，并在快照文件中记录。 　　2.4 日志快照 　　日志快照模块维护一个日志快照文件，记录已顺利输出的交易的tkey。日志快照文件类似于NOSQL数据库Cassandra中的Commitlog，记录哪些交易已经从内存中输出到了目标文件。日志快照文件采用循环覆盖的方式，限定文件大小或记录数，具体根据交易系统情况而定。 　　2.5 日志恢复 　　对于突发断电、系统崩溃的情况，内存中未及时输出的日志会全部丢失，此步用于恢复丢失的日志信息。 　　具体步骤如下： 　　（1）读取持久化日志文件，逐条取出对应的tkey和msg并进行a类提交； 　　（2）读取日志快照文件，逐个取tkey，若tkey在Lmap中，则说明此tkey对应的日志已输出，将此tkey从Lmap中移除，否则输出日志后移除。 　　（3）清空持久化日志文件和日志快照文件，为下一次使用做准备。 　　在日志恢复过程中，日志系统不接收交易系统的任何日志提交。在日志恢复完成后，日志系统重新回到正常的工作状态。 　　3 关键参数 　　此方案实施过程中，有几个重要的参数，如超时时间、持久化日志文件大小、日志快照文件大小或记录数等。超时时间控制着日志输出的时机，直接影响着日志系统的性能。而持久化日志文件大小和日志快照文件大小、记录数决定着日志系统的完整性。文件大小设定过大，则日志恢复过程可能漫长；文件过小，可能无法完全恢复丢失的日志。 　　4 结束语 　　本文实现了一种高并发环境下交易日志的连续有序输出的方法，大大提高日志的可读性、友好性，一方面改善了人工排查问题时的日志环境，减少排查时间。另一方面，简化甚至消除了日志二次处理的工作。