文档的在线查看实现方案

同步上传异步转换附件转换类AttachmentConverter1、同步上传：用户上传完附件立马返回前台，避免前台等待时间过长细节处理：1)附件地址入库，预览地址为空2)将带有附件ID的附件对象加入转换队列publicstaticvoidaddToConvertList(Objecto)发文收文公用该函数，因而参数设计为Obejct，以兼容不同附件对象model3)方法返回，提示上传成功4)此时点击提示转换未完成2、Tomcat启动时1)应用程序自动加载用于附件转换的servlet，并自动调用初始化方法init()。该方法会从数据库中将未转换的附件对象加入等待转换的附件队列convertList。该队列为静态成员，其实现方案有a)采用java自带的同步队列实现。但该队列在队列为空时，代码读取第一个元素会抛出异常，移除第一个元素也会抛出异常。b)采用非线程安全的java队列，通过封装该队列的读、写方法实现外部同步。封装的方式为，将读写方法封装在同一个方法listOperation()内，该方法采用java关键字synchronized修饰从而实现同步。代码设计如下：privatestaticObjectlistOperator(Obejcto,BooleanisGet),如通过isGet为true，则通过Object返回队列convertList的第一个对象，并将该对象从队列中移除。如果isGet为false，则将Obejcto对象加入队列。由于需要兼容收文、发文附件、因为方法的参数和返回值均使用Object对象。2)启动附件的异步转换方法convert()。3、异步转换convert()：privatevoidconvert();在条件恒为true的while循环中转换等待转换的附件队列convertList的第一个附件对象，如果转换成功，则将该对象写回数据库，并将该对象从队列中移除。如果转换失败，则将该对象移动到队列末尾。如果该队列为空，则阻塞while循环所在线程100ms。4、存在问题1)转换阻塞如何判断及处理?初步想通过处理时间(文件大小的函数，或某个配置文件中的值)来判断是否发生阻塞，如果阻塞就终止当前转换进程。2)大并发的情况下，缺乏队列调度算法。过长的队列会导致用户长时间等待。引言：之前附近上传的处理办法是附件的上传与转换同步进行，用户上传附件时，只有当成功转换成swf文件后，才会响应上传成功。这样导致用户上传时会长时间等待，用户体验不好。为了改善这一状况，现在准备采用附近同步上传异步转换的方案。这样一来，用户上传完附近立即得到反馈消息，再由后台专门的进程对附件进行swf格式的转换，实现了上传与转换相分离。1、同步上传异步转换的本质附件上传与转换分开处理，数据库附件表中有附件的原始地址字段和附件的预览地址字段。附件上传时，将附件原始地址入库，而预览地址置为空，将附件对象加入到附件队列则立即返回。附件的格式转换由后台线程专门去做：不断轮循附件队列，对队列中的附件一一进行格式转换,当附件格式转换成功后，将其附件预览地址更新。2、附件队列的实现采用JAVA自带的LinkedList类实现，譔类实现了Queue接口,LinkedList底层采用链表实现，无需考虑队列长度问题。LinkedList本身提供了队列的插入、移除方法：offer(Ee)将指定元素添加到此列表的末尾（最后一个元素）。poll()获取并移除此列表的头（第一个元素）需注意的地方：譔队列是非线程安全的，要保证对队列的同步操作。3、同步上传的流程图4、异步转换的流程图5、同步上传的实现逻辑用户上传完附件后不再等待附件转换，而是立马返回，避免前台等待时间过长。细节处理：1)附件地址入库，预览地址为空2)将带有附件ID的附件对象加入转换队列publicstaticvoidaddToConvertList(Objecto)发文收文公用该函数，因而参数设计为Obejct，以兼容不同附件对象model3)方法返回，提示上传成功4)此时点击提示转换未完成6、异步转换的实现逻辑1）守护线程轮循附件队列，从附件队列中获取第一个附件对象。2）若获取的第一个对象为空，则将转换线程暂时挂起再继续轮循队列;若不为空，则根据譔附件的原始地址，调用附件转换方法进行swf文件转换。3）若2）中附件转换成功，则将附件预览地址入库，并将譔附件对象从附件队列中移除。若附件转换失败，则将附件对象移动到附件列表的末尾。7、容灾处理为了避免停电抑或其他不可抗拒因素，造成tomcat异常关闭后，导致附件队列中信息丢失。采取以下措施：1）tomcat启动时，首先从数据库中将所有尚未进行附件转换的附件初始到附件队列中。2）再自动启动附件转换守护线程，开始轮循附件队列进行附件的格式转换。