Black-Cat 阶段性报告:
Black-Cat 系统是用于个人光盘资料索引检索以及朋友圈交流用的工具(或者称为系统,以下简称BCS),详细信息请参考 http://blackcat.cnblogs.com 的其他文章.
现阶段(2006-11-25)完成进度:
数据库设计阶段性完成(现有设计不会被修改,但是不排除根据新的功能添加的可能性)
DAL层Debug(目前不到2W行,预计控制在4W之内)
业务层还有很多地方比较迷茫.主要还是网络部分分歧太大.需要逐步细化.网络层,代理层,连接层全部要独立.
网络层 现在还在Remoting.跟socket不一样,还不适应这种方式.
计划变更部分(重新叙述,与原计划有冲突的地方以这里为主):
1 用户安装使用模式
A. 独立用户单机模式
B. 网络域用户模式
C. 网络节点方式
三者不相互矛盾.
单机模式用于没有网络接入,并且不想共享或者查询别人的共享,不需要配置网络连接以及服务器登陆.域用户是用户加入一个朋友圈.在多个服务器/客户机范围内进行共享检索.网络节点是用户可以添加多个公共服务器(需要服务器允许非域用户进行资源搜索但是不包含数据的存储,仅仅提供免费信息).用户可以同时使用三种检索方式.
为什么没有冲突?
首先用户使用分为两个主要部分,1 数据的收集提交.(比如从光盘或者其他支持的资源类型) 2 数据的检索. 对于系统来讲.第一步总是先提交给本地数据库(使用SQLite提供数据支持,总不能让终端用户都去安装一个企业版SQL Server吧…) 这样就完成了单机用户的数据提交.至于域用户模式,系统会在完成这一步的基础上,一旦用户属于某个域,那么数据将会与服务器同步,更新服务器上的信息.无论是否本地数据丢失或者甚至是其他人的机器或者移动终端都可以从服务器得到最终版本.这里有一个副本的概念.本地SQLite 收集的是临时数据,只有服务器端的才是主要版本.一旦数据成功上传(同步),那么本地数据库的数据被称为副本.所以请不要讲服务器的数据理解为副本.本地是与服务器”同步”后的数据.由于网络节点方式不允许用户发布数据,所以不存在节点更新方式;检索,比如MSDN的帮助,一旦用户可以上网,那么自然是以网络数据库为主(用户可以选择本地副本优先).至于B C模式在用户看来没有太大区别.
2 多服务器:
就目前需求来看.不排除多服务器的可能.不希望一旦服务器挂掉就要损失全部的数据(太可怕了,N多DVD重新提交一遍?而且很多日文的东西早就忘了是什么东西了,哪个版本的之类根本记不住的.LLOUP服务器稳定性真的不好说..)而且由于分布在全国各地,最好可以根据最快的连接来解决问题.加入域的服务器可以后台传输进行数据同步(最好可以用数据库自身提供的功能,这里存在一些疑问)如果不行,那么本地数据通过计划任务定期备份.服务器之间通过 “请求转发”来获得域内其他服务器的用户信息.
称作工作组,不能合理解释统一的用户认可问题;称之为域,不能合理解释服务器之间的”平等关系”.但是由于有代理的出现,所以就勉强算作域吧.
3 任务请求的分配方式:
首先,不管有没有多服务器,我们总是要多一层代理.这个跟模式有关系.”到底请求发给谁?交给谁处理,怎么发”之类.服务器之间是平等的.代理关注所有的服务器,服务器之间定期发送信号说明自己的状态.代理仅仅是一个旁听.并且推荐某个服务器去完成这个请求.真正实现该请求的还是服务器之间的”讨论”结果.比如服务器A挂了,代理请求A处理,那么其他服务器会自动将A排除在外,并且接管次请求.如果代理依然坚持A解决,那么只能超时等待.(比如用户添加记录的时候,后台数据传输始终无法更新,只有这里才是强制指定服务器的,倘若查询则一般不需要强制指定)这些还要在得知SQL Server是否提供了更加可靠的方法后再确定.
4 使用何种连接方式:
一旦多服务器还真的有很大问题,现在摆在眼前的,1自己用socket(自己搞有些浪费代码数量) 2 .net Remoting(适合分布式计算,要说复杂程度也不是没有) 3 Direct Play(连接封装了很多,基本上能适应各种网络环境了,但是…没必要吧..)
遇到的问题以及尚未成熟的解决办法:
1 数据记录数量以及占用带宽.
主要问题发生在上传记录的时候.由于业务层没有完成,而对数据层测试的结果往往是”最坏的”情况,这里采用估算的方式来进行.一张DVD,倘若是文件DVD,比如一张vs2005安装盘,在用户没有筛选的情况下,记录超过1W是很正常的现象.本地模式还好,倘若是1M的ADSL远程连接是不现实的.所以只能采用代理的方式(当然代理还有其他用途,比如平衡负载)这样用户的数据更新通过后台服务来更新,不至于遭到抱怨… DVD如果是影视DVD,比如动画短片.这样除了目录文件之外还有图片介绍(或者截图),记录数目一般不会超过100,但是图片体积占用是非常大的.这样便会消耗大量的带宽.同理,如果这张DVD是DC拍摄的照片集合,那么即使缩略图外加压缩降低画质,也会占用大量带宽.对于单一服务器只能做到如此.降低画质.
另外还有一个解决办法.给每个图片分派一个唯一标识,交给文件系统去管理.可以用分布式文件系统来缓解数据库压力.这样做好处很多.但是权限跟更新方面就有一些隐患.比如客户端或者服务器还会产生很多零碎的小文件.还要复杂的设置权限,容易被人偷看等等…
2 怎么才能让自己的东西支持类似插件的东西,反射不好搞.莫非最好的办法只能是根据不同的数据库编译不同版本??Emm…
