工作流5.3.5集群配置使用手册.pdfVIP

EOS5.3.5 工作流集群配置说明 集群中需要多台相互独立的应用服务器来共享数据，达到业务数据的一致性，对于大型 企业应用中，对性能要求相当高，我们为了尽可能的提高效率都会使用缓存技术，这样每台 相互独立的应用服务器缓存之间的数据一致性问题就需要有一种稳定、可靠、高效的通信方 案来保证。    集群补丁的改变和背景  一、 通知模式改变  EOS5.3 版本中，工作流的集群通信技术使用的是开源的 JGroups 通知技术，由于对于开 源产品的技术没办法控制，客户应用系统有时会出现一些集群数据不同步、通信消息耗费大 量内存导致宕机现象等，一些非常棘手的问题不好解决或控制。  在 EOS5.3.5 版本中工作流集群不再使用 JGroups 集群通信技术，使用更为稳定的 RMI 通信方式取而代之，流程实例缓存由于操作非常频繁，这些通信技术可能会因为网络问题导 致延时，导致数据错误，所以采用了数据库时间戳的方式来保证数据的正确性，使用轻微的 同步时间操作几乎不会有性能损失。    5.3 版本通信方式  5.3.5 版本通信方式  流程实例缓存  JGroups  不通知（数据库时间戳）  流程定义缓存  JGroups  RMI  代理关系缓存  JGroups  RMI  1. 数据库时间戳进行流程实例缓存运行原理：  流程实例缓存对象有一个内存变量，存储的是缓存最后更新版本，流程实例表中也 有一个字段是数据库最后更新版本，当集群中 Server 中流程实例的缓存被更新后，先 更新缓存版本，然后再更新数据库版本，当集群中的其他 Server 进行数据读取时，先 通过本地内存中版本和数据库版本进行比对，如果版本一致，则直接从缓存中读取流程 实例数据，如果版本不一致，则先从数据库中加载到缓存中，然后再从缓存中读取，这 样就能够通过数据库方式有效保障数据的正确性  2. RMI 进行流程定义和代理代办缓存处理运行原理：  集群RMI通知示例图：    上图所示一个集群中有三个节点 Server A 、Server B、Server C  ，每个节点在集群中的身份 既是主管 Server 又可以是被管 Server，也就是说在任意一个节点上对集群成员进行管理均可 以生效。    在启动时每个 Server 都会首先注册一个消息处理器”Message Consumer”  ，然后再加载 配置好的除自己外的所有成员列表，成员列表中每个成员”Member”分别对应集群中一个节 点。    运行时成员列表中的每个”Member” 负责把要发送的消息分别发送给它自己代表的节 点。”Message Consumer”负责接收并处理其他节点发送过来的消息。    为了保障集群通信的稳定性，成员列表中的每个”Member”都会定时的发送心跳探测消 息到它自己对应的节点，检查该节点的状态。一旦发现对应的节点失去联系，还可以缓存一 定数量的消息，等待该节点重新连接后将缓存的消息再次发送，但如果在缓存消息超过限制 将清除所有消息，继续进行心跳探测，不再发送其他消息。       二、 增加组的概念  在 EOS5.3 版本工作流应用中还发现一些其他问题，比如一台工作流引擎创建了超时、 提醒任务，任意一台连接该数据库的工作流引擎正常启动，就可以触发该数据库中的定时任 务。想要实现某几个引擎分别触发自己的任务就无法做到。  我们在 EOS5.3.5 版本中，工作流引擎引入了组的概念，每个工作流引擎都需可以配置 一个组名称，组名称相同的引擎就属于同一个组，同一个组内的所有机器可以触发同组内的 所有定时任务（为了向下兼容，触发定时器的规则是“同组+组为空”的定时任务均可以触 发），同样也只有同一个组内的成员才可以配置集群。再配合其他的技术还可以实现多