CSDN博客

img keith21

一个综合数据库设计与软件设计的实例讨论

发表于2004/5/17 22:53:00  488人阅读

下面是我在接到了一个项目设计后的思考,这个项目是向不同的用户群(公司)提供wappush技术,说白了也就是做一个制定的ppg。具体的发送已经由底层封装好,并且提供了规范的api,此项目需要做的就是完成对不同的sp实现接口,让他们通过此系统进行push发送。此系统的功能要求是需要有稳定的性能、有日志记录。

下面是我接到的设计:

1。接口部分,提供Socket的接口调用给SP使用,为了提高性能,必须采用多线程并结合队列实现。并提供一个client的例子

注意,需要经过身份认证方可使用,否则报错。

 2。数据库设计:(用mysql实现)
   3个表:
   SP表:
   mobile_user:每一个push,都应该把用户登记到这个表中,sp_id可以通过登录获得,请keith补充。
   pushlog表:把每次发送的信息记录在这个表中。


3。管理界面:(用php实现)
 a.SP的add,remove,delete,update, search may not required
 b.给一个手机号,能查出是哪家sp发送的push,有多少,列出来
 c.选择SP,统计出一段时间的发送信息,有多少条,成功率
 d.给一个主题,能查出是哪家sp发送的

4.数据库er图:

------------------------------------------------

在看了上面的设计后,我给我的头回信如下:

头你好:
 设计已经收到,不过我个人觉得有些地方可能需要再讨论一下:
  1 首先使用Socket的方式实现接口
    如果只提供Socket的方式实现接口,会存在平台兼容性问题,因为各个sp可能使用不同的开发语言,当然,这个问题应该可以解决,不过这样也增加了sp的工作难度,如果增加了工作难度,那么各个sp可能考虑会调用其他的难度要求较低的push网关来实现。我建议我们提供两套接口:Socket接口和WebService接口。
  2 数据库设计部分,我个人看过设计后,总有些疑惑,说出来我们讨论一下吧:)
    如果按照当前的数据库进行实现,分析一下从一个sp的push请求到我们将这个请求发送到手机用户的过程,我想可能有两种方式去实现:
 a)直接发送一步到位的实现方式;
 b)采用供应者-消费者模式。
 首先我们来分析第一种方式:当sp的一个调用请求到达我们的系统,我们首先进行sp鉴权(认证),对sp表进行select操作(建议对sp的鉴权操作这块使用内存数据库技术以提高性能),在鉴权通过的情况下我们将会进行发送操作,首先需要对mobile_user表进行select操作(因为也许这个sp的mobile_user已经存在),根据select的结果分成两种情况:1.如果此sp的mobile_user表中没有这个手机用户, 则对mobile_user表进行insert,然后进入下一步;2.如果此用户已经存在,则直接进行下一步。下一步是进行发送操作(我们调用底层接口进行),在发送完毕后进行对pushlog表的insert操作。这种实现的担心是:1.对mobile_user的多余select,每一个sp-push的调用请求对要对应对mobile_user进行select,而且随着系统的运行时间增长,mobile_user表的记录数量也在不断增长,这里消耗的系统性能会越来越多;2.如果系统发生异常,不能记录用户的手机号码等资源,不能对sp-push调用进行日志记录,因为我们是在所有操作都结束时候进行log的;3.如果我们调用底层的接口push发送未能成功或者我们的调用部分发生错误异常,系统会瘫痪,无法记录解下来的sp-push日志和进行re-push操作。
 

然后我们再来分析一下第二种方式:第二种方式使用供应者-消费者模式实现(我倾向于这种方式,因为这种模式从根本上避免了第一种实现的第2、3点担心)。当sp的push请求到达我们的系统,首先进行鉴权,这个过程无需多说,鉴权通过后对mobile_user表进行select操作(因为也许这个sp的mobile_user已经存在),根据select的结果分成两种情况:1.如果此sp的mobile_user表中没有这个手机用户, 则对mobile_user表进行insert,然后进入下一步;2.如果此用户已经存在,则直接进行下一步。下一步是进行对pushlog表的insert操作,insert pushlog表的部分字段(这些字段可能包括:id, mobilej_user_mb_id, subject, url, create_date[采用供应者-消费者模式必须增加这个字段], sent_status)。到此为止供应者行为结束。同事进行的消费者操作比较简单:首先对mobile_user表和pushlog表进行联合select操作(检索出sent_status为“未发送”状态的记录),然后发送(调用底层接口进行),最后对pushlog表进行update操作(更新的字段可能包括:sent_date, sent_status)。这种实现的担心之处:1.供应者对mobile_user的多余select,每一个sp-push的调用请求对要对应对mobile_user进行select,而且随着系统的运行时间增长,mobile_user表的记录数量也在不断增长,这里消耗的系统性能会越来越多;2.供应者和消费者同事对pushlog表进行write操作,在操作十分频繁,pushlog表的记录数量很多(会随时间增长)的情况,很用以产生数据库死锁;3.消费者对mobile_user表和 pushlog表的联合select操作,这两个表都会随着时间不断增长(从均衡角度衡量,前者非线性后者线性,造成一对多的关系),那么这个操作的系统消耗也会随着系统的运行时间呈非线性增长。

---------------------------------------------------------------------------------------------------------------------------------------------

请各位帮助分析一下我的分析是否正确?还有一个问题,就是关于使用socket接口实现还是使用webservice接口实现的争论,从性能上、安全性等等,哪种方式更好一些呢?


 

阅读全文
0 0

相关文章推荐

img
取 消
img