概念：
在了解了这篇文章之后，可以进行该篇文章的说明和测试。MongoDB 副本集（Replica Set）是有自动故障恢复功能的主从集群，有一个Primary节点和一个或多个Secondary节点组成。类似于MySQL的MMM架构。更多关于副本集的介绍请见官网。也可以在google、baidu上查阅。
副本集的同步和主从同步一样，都是异步同步的过程，不同的是副本集有个自动故障转移的功能。其原理是：slave端从primary端获取日志，然后在自己身上完全顺序的执行日志所记录的各种操作（该日志是不记录查询操作的），这个日志就是local数据 库中的oplog.rs表，默认在64位机器上这个表是比较大的，占磁盘大小的5%，oplog.rs的大小可以在启动参数中设 定：--oplogSize 1000,单位是M。
注意：在副本集的环境中，要是所有的Secondary都宕机了，只剩下Primary。最后Primary会变成Secondary，不能提供服务。
一：环境搭建
1：准备服务器
192.168.200.245
192.168.200.252
2：安装
3：修改配置，只需要开启：replSet 参数即可。格式为：
192.168.200.245: --replSet = mmm/192.168.200.252:27017
192.168.200.25: --replSet = mmm/192.168.200.252:27017,192.168.200.245:27017
4：启动
启动后会提示：
说明需要进行初始化操作，初始化操作只能执行一次。
5：初始化副本集
登入任意一台机器的MongoDB执行：
MongoDB shell version: 2.4.6
connecting to: 192.168.200.252:27017/test
> rs.initiate({"_id":"mmm","members":[
... {"_id":1,
... "host":"192.168.200.252:27017",
... "priority":1
... },
... {"_id":2,
... "host":"192.168.200.245:27017",
... "priority":1
... }
... ]})
{
"info" : "Config now saved locally. Should come online in about a minute.",
"ok" : 1
}
######
"_id": 副本集的名称
"members": 副本集的服务器列表
"_id": 服务器的唯一ID
"host": 服务器主机
"priority": 是优先级，默认为1，优先级0为被动节点，不能成为活跃节点。优先级不位0则按照有大到小选出活跃节点。
"arbiterOnly": 仲裁节点，只参与投票，不接收数据，也不能成为活跃节点。
> rs.status()
{
"set" : "mmm",
"date" : ISODate("2014-02-18T04:03:53Z"),
"myState" : 1,
"members" : [
{
"_id" : 1,
"name" : "192.168.200.252:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY"Winform开发框架之简易工作流设计 - 伍华聪 阅读原文»
一讲到工作流，很多人第一反应就是这个东西很深奥，有时候又觉得离我们较为遥远，确实完善的工作流设计很多方面，而正是由于需要兼顾很多方面，一般通用的工作流都难做到尽善尽美。微软也提供了几个版本的WF框架支持，也有一些厂家是基于这个框架基础上开发的工作流应用。
以前由于项目的需要，参与过一些工作流的项目开发，其中有些是基于我简易工作流的原理上进行拓展的，包括一个广州市各区县使用的行业审批业务平台，由于基于自己的流程处理，界面设计、流程流转等方面可以很好符合客户需求，定制的弹性较好，缺点是不够通用，也需要编写表单部分代码。
后面由于业务的需要，工作流方面的业务逐渐显得迫切，公司是想采用一个较为通用工作流框架来组织目前的业务，因此找了广州一家做工作流的公司，购买了他们的产品，虽然号称完全通过后台配置，零代码实现工作流业务表单的处理，但是由于客户对表单的设计要求比较多，有时候需要结合一些外部的数据接口，流程处理方面也有着进一步的需要，这样可能就打破了他们原来的格局，导致无论在表单设计、流程配置等方面，都需要购买他们工程师的现场服务，来进一步完善整个项目的内容，导致整个项目进展缓慢，遭遇水土不服的处境。
因此感觉，一个工作流模块，号称再强大，如果不能很好结合项目应用，即使零代码的功能配置，也可能使你处于尴尬的境况之中，因为通过配置，可能在代码里面平常很容易实现的表单功能，要通过零代码配置，花费的时间更多更难掌握，因为零代码是有代价的，需要您很好利用他们的API，他们的业务对象，有时候还需要很曲折的摸索参数，而这一切可能就是非常致命的弱点。
1、简易工作流的设计模型
在没有第三方工作流模块的情况下，简易工作流就是利用数据库和业务对象之间的协作关系，构建的一个半模块化的流程引擎，它能通过整合到项目代码中进行更好的融合以便实现工作流的相关功能。
首先我们知道，我们在Office里面创建任何文档，都有一个模板的概念，这样我们方便利用一些现成的数据和布局，工作流也一样，有一个流程模板的概念，如下所示。
然后每个流程模板，本身会预定义了一系列的处理流程，以便在流程实例里面进行不同的处理，因此流程模板还包含了多个流程步骤对象，他们的关系构成如下。
每个流程实例，除了他们自己的流程数据和字段信息外，它本身还有一个表单设计的问题，如费用审批，可能包含填写的费用清单数据等，所以流程实例还应该包含了流程的业务表单对象。
这样他们构成了一个完整的流程业务对象关系，如下所示。
2、流程审批的操作
对于一个流程处理操作，我们知道一般有审批通过、拒绝、退回到某步骤、转发到内部阅读、阅读，以及包括起草者能撤销表单呢等操作，当然如果还有一些具体的业务，可能还会有一些流程的处理才操作，不过基本上也可以归结为上面几种，只是他们每步处理的数据内容不同而已。因此审批的操作步骤分类如下所示。
这些操作我们都可以通过一些界面操作的封装实现，因为他们基本上都是通用的，我们传入一些流程ID等相关标识后，就能交给这些标准的操作界面完成了。
如审批界面如下所示，里面包含了通过、拒绝，跳回到某步骤，增加步骤等功能集合。
上面的界面是审批过程中，对于某一个流程处理人员实现的操作，而有时候，我们可能需要针对多个人进行某个步骤的处理，如传递给内部人员进行分阅操作，那么就应该选定多个人员进行处理，大概的处理界面效果如下所示。
当然，若申请人的申请单填写错误，需要撤销的话，那么也应该有这个操作，撤销表单后，就可以重新填写表单，然后再次提交进行流程。
3、流程审批的表单处理
在表单的动态设计和显示方面，一直没有好的思路，因此我觉得把流程模块作为半模块化即可，把部分界面通过代码编写方式进行整合，因此把表单的填写，表单查看做到用户控件里面，然后在界面里面引用即可。
如下面的表单填写操作界面如下所示，对不同的流程表单，在项目中增加一个表单的填写界面和保存操作即可。
查看并处理的表单操作，我们可以先做一个查看表单信息的界面，然后整合流程的处理工具栏，组合成一个查看、处理操作一体化的流程操作。
当然，如果是能够有动态设计表单，然后进行无缝整合当然更加完美，不过这样的操作，界面设计上也不会很麻烦，一般普通的开发人员都能胜任，因此，对于其他流程表单，依葫芦画瓢就可以完成不同的表单了。
而且里面的工具栏代码都是可以操作的，虽然可能集成了不同业务的处理方式，但是我们还是动态进行处理，处理代码如下所示。
{
//如果流程是可以撤销，且表单状态为处理中，那么可以“撤销”操作可用
bool mayCancel = BLLFactory<AppApply>.Instance.IsApplyMayCancel(ApplyId, base.LoginUserInfo.ID);
this.btnCancel.ToVisibility(mayCancel);
//可退回重新编辑
bool mayBackToEdit = BLLFactory<AppApply>.Instance.IsApplyMayBackEdit(ApplyId, base.LoginUserInfo.ID);
this.btnEdit.ToVisibility(mayBackToEdit);
//判断是否需要显示阅办状态
bool isReadStatus = BLLFactory<ApplyRead>.Instance.IsReadSatus(ApplyId, base.LoginUserInfo.ID);
this.btnRead.ToVisibility(isReadStatus);
//如果不是当前审批人隐藏审批按钮
bool canDeal = BLLFactory<BLL.ApplyUser>.Instance.IsCheckPermission(ApplyId, base.LoginUserInfo.ID);
if (canDeal)
{
ApplyFlowInfo flowInfo = BLLFactory<ApplyFlow>.Instance.GetFirstUnHandledFlow(ApplyId);
if (flowInfo != null)
{
string procTypeName = BLLFactory<AppProc>.Instance.GetProcType(flowInfo.ProcType);
BarButtonItem button = new BarButtonItem();
button.Caption = procTypeName;
button.Name = procTypeName;
button.Tag = flowInfo;//绑定流程内容
button.ImageIndex = 3;
button.LargeImageIndex = 3;
button.PaintStyle = BarItemPaintStyle.CaptionGlyph;
button.ItemClick += new ItemClickEventHandler(button_ItemClick);
this.bar1.AddItem(button);
}
}
}
上面对于流程步骤的处理，就交给一个独立的按钮事件进行判断处理即可，根据不同的业务步骤名称进行不同的处理，这样就能够进行很好的控制处理。
本文链接：http://www.cnblogs.com/wuhuacong/p/3557000.html，转载请注明。
没有评论:
发表评论