meobius与DBTwin实现原理
meobius与DBTwin实现原理
数据库扩展器DBTwin 允许同时连接n 个数据库，由DBTwin网关对它们进行统一管理。而对于客户端来讲，DBTwin 屏蔽了后面的n 台数据库，它看到的只是由DBTwin 网关表现出来的一个虚拟数据库服务，只连接客户端只需要连接此虚拟的IP 和端口，就能象访问普通数据库那样进行操作。DBTwin 数据库集群的原理结构如下图所示：
DBTwin 最大的特色是能够对访问数据库的事务（Transaction）进行并发地处理：当DBTwin 网关接收到插入、修改、更新等事务操作时，它同时将这个事务（Transaction）发送到后面连接的n台数据库上，这样n台数据库中的数据同时得到了更新；由于在任何时刻，DBTwin 网关后面连接的n 台数据库的数据是完全一致的，因此当DBTwin 网关接收到查询操作时，整个数据库系统可以实现负载均衡（Load Balance），由此达到客户访问负荷的动态分担，提高整个系统的响应能力。
DBTwin 的实现原理
DBTwin 是一个中间件服务软件，它工作在微软的数据库专用协议TDS 层之上，如下图所示：
TDS(Tabular Data Stream表格数据流)是微软数据库客户端与SQL Server服务器进行通讯的未公开协议，DBTwin 就工作在这一层，因此，DBTwin 能支持所有的SQL Server 客户端数据组件。1433 是微软SQL Server 的缺省服务端口那样，8106 是DBTwin 数据库集群的缺省服务端口，另外8105、8107、8108 和8109 是DBTwin 或者它的代理端软件的固定工作端口，因此，客户在选择端口的时候，一定要避免选择这些端口，以免发生端口冲突。
事务是数据库系统里一个基本，但十分重要的概念，DBTwin 时刻检测来自客户端的事务。一旦接收到客户事务请求，DBTwin 将此事务同时发给集群中的每个数据库，并且确保所有的集群数据库要么全部提交，要么全部回滚此事务，以此保证每个集群数据库的数据映象始终是处于一致状态，同时保持对数据库客户端的透明、无缝连接。
批处理也是数据库系统中的一个重要概念，DBTwin 是以批处理为单位来进行负载均衡的。也就是说，每当DBTwin 接收到来自客户端的一次请求，这个请求其实就是一个批处理，这时候DBTwin 会对此批处理进行语法检查，并判断出是否能负载均衡，若可以进行负载均衡，那么DBTwin 将根据某一算法，挑选出其中某台集群数据库来执行此批处理；如果此批处理不能负载均衡，那么DBTwin 就同时给所有的集群数据库发送此批处理请求。
在DBTwin 集群启动之前，用户可以通过PRT 高级同步工具作数据同步，或者也可以利用SQL Server 提供的BACKUP/RESTORE 命令来作到这一点。在DBTwin 运行过程中，如果有数据库掉线了，这时，DBTwin 会有两种方式来修复集群，一是定时自动方式，此方式是预先设置好在某个时间进行数据库同步和DBTwin 网关的重启动，它适合于一些晚上进行批处理作业的系统。另一种方式是手工同步方式，此方式针对的是由随机错误，例如网络错误，服务器重启等导致的。无论哪种方式，在同步过程中，客户端是始终客户访问DBTwin集群系统的，这样整个数据库系统的可用性就大大提高了。
上述的工作流程如下：
服务器A(虚拟主机)上的代理接收到查询请求的时候：
1. 或者有代理A直接发送给本地的数据库引擎A，让本地引擎A执行查询select * from t，返回结果给客户端。
2. 或者先由代理A把请求转化成这种形式sp_remote ‘192.168.1.2’,’sa’,’123’,’select * from t’, 然后发送给本地的数据库引擎A，本地引擎A在执行的时候，通过远程访问IP为192.168.1.2的数据库引擎B来执行查询，最后查询结果通过服务器A上的引擎A和代理A，返回给客户端。
二者产品比较
为了更加说明问题，我们还是把二者的原理图放在一起，如下：
下面，我们来做一个测试：
测试方法：用查询分析器登录一个连接到DBTWIN集群或友商的虚拟主机，然后执行select * from t这语句100次。
观察方法：执行的时候，观察两台机器的CPU和网卡速率就知道是哪台机器在执行当前的语句了。
测试结果：
1. 对于DBTwin集群，有N次的执行结果会从数据库A来，(100-N)次的结果从数据库B来，N是100之内的一个数，是动态的
2. 对于meobius，100次的结果全部会从同一台数据库服务器来，要么全部从数据库A机器来，要么全部从数据库机器B来，两者必居其一。
分析总结：
1. 由于数据库连接是长时间连接，因此DBTWIN的测试结果符合负载均衡的预期，而meobius的测试结果则不符合对负载均衡的预期。在实际应用中，meobius的集群完全有可能会出现这样的场景：数据库A机器的CPU是100%，而数据库B机器的CPU是0%，这时负载均衡就不发生作用了，而数据库机器A，也就是虚拟主机成了整个集群的性能瓶颈；而DBTwin集群则不会发生这样的场景。
2.DBTWIN对SQL SERVER的任何客户端是都是二进制兼容的，不需要对客户系统作任何修改，只需要修改客户连接数据库的连接字符串中的IP地址和端口号，就可以立即访问数据库了。对于像create/drop/alter database,updatetext,writetext,truncate table,select into等等，全部自动支持，不需要对客户系统的源代码作任何手工修改(况且大部分的情况下，客户系统没有源代码)。因此，DBTWIN的实施时间是很短的，不需要研究客户应用系统的结构等内部逻辑关系，一般是等晚上客户系统空闲的时候，花一两个小时上线，然后观察2至3天就OK了，不需要长时间的调试安装。meobius集群对于上面这些SQL语句是不兼容的，它需要技术员人工处理，因此需要熟悉客户系统，花费较长时间来实施，有的即使时间再长也是解决不了的，这样就会给系统带来不可预知的隐患
TFS源代码管理的8大注意事项
首先，给出上一篇内容的word下载：
下面会给出本文的Word文档下载。另：本篇仅供参考，希望能者补充。
TFS源代码管理的8大注意事项
目录
2. 如果代码没放在源代码管理软件里，等于它不存在... 2
TFS具体使用请参考此链接：http://msdn.microsoft.com/zh-cn/library/ms181382.aspx
源代码管理软件是我们工作的必备工具，是许多开发团队的血液。那么如何更好的利用TFS进行源代码管理呢？
1. 为什么使用TFS 2012进行源代码管理
为什么使用TFS，从源代码管理方面来说，TFS具有以下优势：
l 与Visual Studio无缝结合，方便开发者进行源代码管理
l 支持代码审阅与讨论
l 支持邮件通知
l 支持Web访问与管理
l 支持工作项以及BUG等管理
l 不会上传.NET开发时生成的垃圾文件
l 自带版本合并以及比较工具。
l 支持数据库版本管理
l 自带很多管理工具（测试管理器、反馈客户端、界面设计工具等等）
2. 如果代码没放在源代码管理软件里，等于它不存在
每天重复读这句话——“使用源代码管理软件是唯一的有效措施”。除非你在工作时使用项目的源代码管理库来控制代码版本——否则代码等于没有存在过。
显然你曾发觉在你的本地机器上运行良好的代码在其他人那里运行的效果并不理想。是不是？他们不能获取你的最新版本，他们没法去归并代码文件，你没有正确地部署它（参考 you're deploying it wrong）而且如果你的 SSD 硬盘坏了的话你将永远地失去你的劳动成果。
只要你保持这个心态——代码只有提交后才是真的安全，才是其他良好编程习惯的保障。你可以把你的任务划分成许多很小的单元以便你逐一提交。你需要频繁地这么做。你就不必担心你的硬件会不会出棘手问题。
不过更重要的意义是（至少对于你的团队领导来说），通过源代码管理软件可以看到你做了什么。使用图表并列出项目清单是个好方法，不过怎么知道他们实际上在做些什么？而使用源代码管理软件进行工作就能看得一清二楚了。
3. 要早提交，常提交，并且不要觉得麻烦
关于前面那点，避免“幻影代码”（就是只能在你的机器上看到的代码）的唯一方法是经常提交你的任务并且不要觉得麻烦。它可以解决你的问题，不过这样做也会对你的工作产生其他的影响：
1. 每个提交的修订都会为你提供一个还原点。如果你完全把代码搞砸了（没骗你，我们都这么做过），你是希望恢复到一个小时前的工作还是一周前的工作？
2. 归并文件时会出现的危险会随着时间不断增加。归并文件一直很麻烦。如果你不是每天都保持提交代码，某一天你会突然发现你和其他人的更改内容会有 50 多个冲突。你不会为此感到高兴的。
3. 它促使你把任务分离成分散的单元。通常人们都是快完成的时候才提交的，因为他们想把代码做成一个完整的逻辑单元模块。不过庞大的任务不可避免地要分离出较小的分散功能，而频繁地提交它们会使你更了解它们，你可以一个个地构建并提交。
如果你做到这些，你的提交历史不可避免地开始类似于一种半规律的样式，里面每个工作日都是在提交任务。当然不总是这样，也有停下来重构或测试，或者其他合理的活动也会中断标准的开发周期。
然而，当我在看一个独立的——尤其是完整的项目时，每当发现我们在一个标准的开发周期里，有一天或几天什么都没有做，我便会非常担忧。我之所以担忧是因为这意味着什么地方出问题了。一般不是有人正在想方设法要把问题搞定的话，就是因为卡在某个问题上而导致项目完全没有进度。无论到底是什么情况，源代码管理软件都会告诉你出现问题了。
4. 提交前要检查你更改了什么
往源代码管理软件里提交代码的步骤其实非常简单。（你恐怕会困惑上一条为什么说的那么麻烦。）一般只要发现文件内容有变更时都会不顾后果地把文件传上去。像这样——“我的项目根目录下有文件内容变更了，我要快点提交上去！”
如此会发生一件（或两件）事情：首先，程序员会没有意识地把目录下的垃圾代码文件也上传上去。一些人看到类似下面的SVN提交窗口时，就会点击“选择全部”然后提交——这样源仓库里就会被本不应该存在的未调试的文件和其他垃圾文件给弄乱。
或者是，程序员实际上并没有检查他们更改过什么就把文件上传了。当你在工作中处理配置文件或项目定义文件时很容易就不经意把那些不想提交的文件给上传了，而且那些文件很可能就被别的程序员用到了。
5. 写提交信息时一定要认真
这是一个古老的谚语（出处不详），大意是说“写每一条提交信息时就好象等下会读到它的人是一个斧头杀人狂，而且他还知道你住在哪里”。如果我是那个杀人狂并在研究你的代码想追踪 bug 的话，看到的提交信息全部都是“代码更新了”，小心，我会来砍你的！
我的解决办法就是解释清楚为什么要提交新的代码。每次你对代码进行更改都是有原因的。可能什么地方会崩溃。可能客户不喜欢现在的主题颜色。可能你仅仅要调整一下构建配置。无论是什么，这都是有原因的而且你要把原因用文字保留下来。
为什么？这样做的原因有很多，而且在不同环境下各不相同。举个例子，使用“历史记录”特性或其他类似的功能显示出谁改了代码那些地方。如图：
这是一个可以随时观察代码更改的软件的一种。无论我想了解一个文件的完整更改历史，还是只想知道团队昨天做了什么，留下一个描述性的相关记录意味着只要不经意一瞥就能知道是什么情况了。
6. 使用代码审阅提高代码质量
代码审阅可以提高代码质量。
Visual Studio2012包含了源自于Team Foundation Server的代码审阅工作流。具体使用请参考此链接：http://msdn.microsoft.com/zh-cn/library/hh474795.aspx#code-review-request
7. 一定要管理好数据库的版本
这一点是我们都知道必须要做的，但是很多人觉得它麻烦。问题是很多（或者是大部分）应用程序没了数据库就不能运行。如果你没有管理好数据库，那你实际上做的就是一个不完整的完全无用的应用程序。
老实说，如果你没有管理好你的数据库版本，你的开发会伴随着很大的问题。在更改数据库的时候没有源代码的管理，没有还原点，并且很难和团队密切合作。使用数据库版本控制系统可以使开发更轻松。
那么使用，Visual Studio的数据库项目来管理数据库，就能够利用TFS来管理数据库版本了。具体使用请参考此链接：http://msdn.microsoft.com/zh-cn/library/vstudio/dd193266(v=vs.100).aspx
使用VS数据库项目具有如下优点：
l 支持版本管理
l 便于团队协作开发
l 支持对不能版本数据库进行部署
l 支持生成测试数据
l 提供了许多额外的功能与工具：数据库架构比较、数据比较、生成脚本等
8. 将必要的附属文件集成到源代码管理
这是特别重要的一点。当应用程序需要外部的附属文件存在才可以正常运行的话，把那些文件也都放进源代码管理软件里！人们倾向于犯的错误是，在他们拥有自己设置文件和本地附属文件的环境里一切都表现得很好就把东西都上传了，之后觉得没问题了就不管了。但是其他人不能从源代码库里找到同样的附属文件的话，所有东西都会悲剧性地报错。
比如，通常我们的项目会引用很多第三方的dll，那么就应该将这些dll都集成到源代码管理，如图：
最后
- 本篇文档Word版下载地址：TFS源代码管理的8大注意事项.zip。
- 本文参考了《源代码管理十诫》，并做了一些修改。
- 希望大家积极讨论并补充。
出处： http://www.cnblogs.com/codelove/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
静听鸟语花香，漫赏云卷云舒。