daizhj的专栏

       在上文中，介绍了如果录制脚本和设置脚本执行次数。如果经过调试脚本能够正常工作的话，就可以设置并发用户数并进行压力测试了。       首先我们通过脚本编辑界面上的“工具”菜单项，选择该菜单的第二项“Create Controller Scenario(创建控制场景)”，如下图：            这时，lr会弹出一个窗口，我们只要在select sce

     在今年年初，本人接受了商品交易插件设计和开发任务。在开始的那段时间里，主要是开发一系列商品交易的基本功能，包括：         商品管理（CUD）,在线交易，商品分类管理，定单（交易单）管理等。如下面的图中所示（普通权限用户）：        而下面这张则是有管理权限的用户（管理员或版主之类）用例图。        目前我们开源的商品交

    声明：本文内容纯属个人观点，官方保留最终解释     在上文(Discuz!NT URL地址重写) 中， 聊到了“在线用户”功能，因为当时介绍的重点不是“在线”那一块，所以没做深入介绍。这就为今天这篇文章埋下了“伏笔”。因为在线这个功能太重要了，大家不妨用VS打开我们产品的最新源码，然后搜索一下“OnlineUsers.”这个内容就会看到它在产品中被使用的“频率”。

   声明：本文内容纯属个人观点，官方保留最终解释   通过前几个月的“外围清剿”，我介绍了一些在项目中边边角角的类和项目。当然这种介绍只是前期热身准备。因为从这篇文章开始，本人将跟大家聊一聊关于这个产品架构上面的东西，以备大家对这个产品有一个总体上的认识，从而为后面的文章做一下铺垫。费话少说，开始正文吧:)   首先请大家看一下官方提供的“前台页面层次图”如下： http:

    作为产品中的一大特色，模板机制一经推出，就引来了大家特别是站长们的关注。但它所饱受的风风雨雨也成了那时不少人关注的话题。而今天本人将结合在产品组中的开发经历，介绍一下模板机制在设计使用时的一些体会心得。希望借此陋文，使模板机制揭开“神秘”面纱，为大家在实际设计中提供一些有价值的参考和建议。    好了，开始今天的话题:)    首先阐述一下模板设计的目标，因为这对

          鉴于前一阵子所写的关于Discuz!NT文章在园子中有些朋友存在疑惑这里先做一下声明：         这些关于Discuz!NT的文章不是要帮助大家把这个项目中所有的程序逻辑都解释一遭 (我相信大多数朋友也不希望这么做) 而是希望能给大家提供一把“钥匙”，帮助大家从项目结构和程序架构上先对这个产品有一个初步认识，想信只要有过一定开发项目经验的朋友应该从中

          继上篇文章之后（链接），大家给了一些反馈和意见，有些BUG和不当之处我已修正,将会在2.0正式版本中提供给大家。希望大家能继续支持我们这个开源项目。          好了，开始今天的话题，首先需要说明的是因为这两个控件都比较简单所以放在一起给大家说一下。              先说一下 ColorPicker 控件 ,贴一张运行效果图让大家看一下：

        在开源之后，还没什么文章来说明 Discuz!NT项目的一些特点。作为这个控件库的设计者，本人将在接下来的时间里用连载的方式来向大家解释其中一些控件的设计思想，实现功能以及一些未曾使用过的功能展示（因为管理后台只使用控件的部分功能）。同时因为这组控件开发的周期很短（当时仅用一个半月，后不断增强功能），有不少思路和控件设计的规范相驳，但当时只考虑为后台程序开发和

       在以前的两篇文章(Discuz!NT 缓存设计简析, Discuz!NT中集成Memcached分布式缓存)中，介绍了Discuz!NT中的缓存设计思路以及如何引入Memcached，当然前者是IIS进程的缓存（本地缓存），后者是分布式内存对象缓存系统。      两者通过Discuz!NT中的memcached.config文件中的ApplyMemCached结点的值来决

     在年前发布的基于silverlight4(beta)版的摄像头应用之后。经过最近一段时间的完善。目前已推出了beta2版，在修改了原有程序bug的基础上，做了如下变化：      1.将图片载入修改成为按原图宽高比进行缩放，所以以前可以分别沿X,Y轴变化的功能就砍掉了。     2.添加了控件样式，使显示效果更加丰富。     3.在高级模式下添加了没X,Y,Z轴设置图片

作为Discuz!NT企业版中的一员，在设计企业级搜索架构之初，就考虑了海量数量，准实时索引更新，并发访问，安装布署等诸多方面。目前在生产环境下被广泛使用的开源搜索引擎中，sphinx以其强大快速的索引功能，优异的并发响应性能，方面灵活的布署，分布式查询等诸多因素而倍受青睐。 目前Sphinx广泛应用在Linux平台上，尽管官方所发布的产品中也有window版本，并且支持mssql数据库，但在使用过程中才发现，其只在发布的windows平台下的版本里才支持mssql数据库，而lin

在前文中，介绍了Discuz!NT引入SPHINX的背景和相应的客户端的C#代码架构实现。今天这篇文章将会介绍如果在LINUX环境下安装配置SPHINX中文搜索工具，也就是服务器配置方案. 目前在网络上可以找到的SPHINX中文插件主要有两个: 1.coreseek: http://www.coreseek.cn/ 2.sfc: http://code.google.com/p/sphinx-for-chinese/

在Discuz!NT的企业版设计过程中，处理大数据表一直是一个让人头疼的问题，特别是像主题表（topic），用户表（user）等，因为对于一个流量和发帖量都很大的论坛而言，在运行几年之后，这两个表的数据量可能会破千万（注：因为帖子表采用分表机制，所以这里暂未涉及，但出于性能考虑，也提供了本文中类似的解决方案）。当时考虑的架构设计中有两种思路来解决这种问题：

目前在网上关于TokyoCabinet（以下简称TC）和TokyoTyrant（以下简称TT）的资料已相对丰富了，但在.NET平台上的客户端软件却相对匮乏，因为做Discuz!NT企业版的关系，两个月前开始接触TC和TT，开始写相关的客户端代码。 这里开放的是客户端主要功能代码，开源的目的一方面是希望更多的人来学习研究TC和TT，同时大家可以下载本C#源码继续优化提升性能，同时查找BUG，必定本人精力能力有限，而Discuz!NT企业版的功能点又太多（抽空会多写文章进行介绍）实在

在Discuz!NT的最新版本中，支持目前主流LINUX平台上的负载均衡解决方案，比如NGINX,HAPROXY,LVS等。本文与其说是解决方案，倒不如说是介绍如何搭建Discuz!NT负载均衡解决方案：） 因为我们的产品运行的主流平台是WINDOWS+IIS+SQLSERVER（2000以上版本），而LVS+KEEPALIVED是LINUX下的四层负载均衡软件。其有如下特点：LVS集群采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率（在DR模式下），将请求均

在之前的文章中，提到了在Discuz!NT中进行缓存分层的概念。之前在产品中也实现了其中的构想，但该方案有一个问题，就是如果将产品进行分布式布署之后，如果某一站点发生数据变化时，只能更新本地缓存和Memcached缓存信息，而其它分布式布署的站点则无法收到缓存数据已修改的‘通知’，导致数据不同步而成为‘脏数据’。 虽然在之前的文章中提到通过将本地缓存失效时间‘缩短’（比如15秒后即失效），以便在相对较短的时间内让本地数据失效从而再次从Memcached读取最新的数据，但这必定不符合

在前面的几篇文章中，主要谈到了在Discuz!NT中的跨站缓存数据，数据库负载均衡。但如果要实现将产品分布式布置到若干机器，组成集群来共同支撑起整个业务的话，还是有一定问题的（后面会有所介绍）。下面先介绍一下如何使用 Discuz!NT负载均衡方案搭建分布式应用。 Discuz!NT前端负载均衡是基于nginx实现的，下面是它的一些简介：

在之前的Discuz!NT缓存的架构方案中，曾说过Discuz!NT采用了两级缓存方式，即本地缓存+memcached方式。在近半年多的实际运行环境下，该方案经受住了检验。现在为了提供多样式的解决方案，我在企业版里引入了Redis这个目前炙手可热的缓存架构产品，即将memcached 与Redis作为可选插件方式来提供了最终用户，尽管目前测试的结果两者的差异不是很大（毫秒级），但我想多一种选择对用户来说也是好的。

     在上一篇文章中，大略说明了一个商品交易插件的一些功能上的东西和具体的文件分布。本文章将会以上文中的“管理商品”用例来说明一下商品的添加，编辑和删除方面的设计。     首先看一下商品添加功能。我们打开一个商品添加页面如下：         上图中说明了发布商品时要填写的内容和数据约束项，其中的"商品类目"一侧的“选择”链接点击后效果如下

     在上一篇文章中，大略说明了一个商品的添加编辑和删除操作。本文会继承其支付流程来展示如何购买商品以及系统设计。    首先打开一个有效的商品，在商品显示页面中单击“立刻购买”按钮，如下：           这样就会跳转到“确认购买信息”页面(buygoods.aspx)，如下：       在这个页面中，系统会执行如下操作：

     在商品交易过程中，信用机制的引入是至关重要的，我们在这里参考的是discuz的做法（其实它最终是采用类似TAOBAO的好评机制来实现的）。所以在每笔交易结束时，都会要求买卖双方进行互评，以便为信用机制提供数据。而这里所使用的信用等级信息是参考discuz的数据进行相应级别设置的，其“信用等级”表（dnt_goodscreditrules）结构参见下图所示： 

      大约在两年前我写过一篇关于Discuz!NT缓存架构的文章，在那篇文章的结尾介绍了在IIS中如果开启多个应用程序池会造成多个缓存实例之间数据同步的问题。虽然给出了一个解决方案，但无形中却把压力转移到了磁盘I/O上（多个进程并发访问cache.config文件）。其实从那时起我就开始关注有什么更好的方案，当然今天本文中所说的Memcached，以及Velocity等这类

      在上一篇中, 我们了解了为提供支付宝在线支付功能，所需要的一些助手(helper)类, 在本文中，我们将会以一个线上支付流程来进一步介绍业务设计上的一些内容和思想。     在之前的线下支付流程中，我们看到交易是靠买卖双方不断更新本地的交易状态来进行推动的。而线上支付这个过程的推动主要靠支付宝那面的操作来完成，而本地服务器只是提供了交易信息并进行跳转(到支

      声明：本文内容纯属个人观点，官方保留最终解释          在Discuz!NT中的前台页面访问（特别是aspx）是被HttpModule接管的，所以大家在Discuz.Web项目的目录下看到的唯一"aspx文件"是index.aspx，而所有其它前台页面都有“/aspx/”文件夹下的相应的子目录中，而这些子目录名称是与后台所“生成”的模板存在对应关系的。而这

    声明：本文内容纯属个人观点，官方保留最终解释    根据目前官方提供的数据字典（详情见链接）。可以看出数据库中的数据结构：包括表名，字段名，字段类型，含义等。通过这些文档可以让大家对整个数据的表结构有一个基本了解。另外本人觉得，如果用一篇文章去讲解数据库，让人多少有些凑字的嫌疑。所幸目前还有 Discuz.Entity.dll这个项目没有介绍，所以想以这个 d

    在7月份中我曾经写过一篇随笔叫，叫" .NET2.0 框架中的 AbstractFactory 模式 " 。    里面主要说了在2.0框架下的数据库链接工厂中新增的几个类，而这几个类采用的就是 抽象类工厂模式（Abstract Factory）。因为在Discuz!NT 2。0中使用了这些新的类，所以导致我们的产品dbhelper.cs可以支持几种数据库（目前官方实

        大约还是去年12月份，当时项目中遇到了一个很棘手的问题，就是管理员（或站长）在后台设置了邮箱信息之后，使用注册邮件发送激活验证码时，总有用户反映不能收到激活信息的邮件。        虽然不能收到邮件的情况有很多，甚至我已通过这个邮件发送程序测试过国内大多数知名网站的邮箱（如126，sina ,sohu ,gmail等），但还是有站长或用户隔三差五反映这个问题。甚

         继上篇文章之后（链接），大家给了一些反馈和意见，有些我已动手进行了部分修改,将会在2.0版本中提供给大家。希望大家能继续支持我们这个开源项目。         好了，开始今天的话题，今天就说一下 Tab 控件。        先贴一张运行效果图让大家看一下：                         开发动机：在去年开发后台功能时，最早

        作为一个社区类型软件，大并发支持和高效稳定运行永远是“硬道理”，而有效安全的使用缓存恰恰能起到事倍功半的效果。而.NET本身所提供的缓存机制又显得过于“单薄”，比如说订制不太灵活方便, 缓存对象之间层次感不强, 使用时缺乏统一的管理等等。             Discuz!NT缓存产生背景：         在去年五月份我加入Discuz!NT项目组时

      注：本文的HTM页面均位于Discuz.Web项目中，大家可以到官方下面最终的程序。      在去年我曾写过一篇文章:“推荐一个Silverlight多文件(大文件)上传的开源项目”。之后有不少朋友询问这个项目示例在开发和配置上的一些问题。当时因为时间有限没有做过多的说明，导致有些问题在大家下载完源码之后运行时才出现。今天就以这个项目为原型，简要介绍一下在DiscuzN

     在上一篇文章中，介绍了商品交易线下交易流程，这一篇则重点介绍一下线上支付宝交易流程。在开始今天的正文之前，有必要介绍一下关于支付宝交易信息通知的一些内容，因为我们的商品交易插件使用了其中的一种通知方式。    在支付宝系统中，当交易发生时，根据系统的“处理方式”分为两类：    1.立即返回处理结果，即用户在支付宝页面完成操作后，支付宝将处理结果立即返回给合

      大约在去年的12月份，我们开始着手设计和开发这项功能，而该项功能主要是解决类似于一些帖子附件（图片或文件）访问比较频繁，同时附件的体积又比较大，从而造成对主站服务器访问压力过大的问题。而实现了该项功能之后，在一些合作伙伴的站点上使用了一段时间，发现该功能明显的降低了主站服务器的负载，使其可以节省更多的资源(cpu，内存等) 用于处理用户的其它访问请求。

    望DUDU见谅，暂放首页一天，呵呵:)         就在昨天(2007.12.24), 公司的discuz!nt 2.0 正式版终于开源了，下面就是链接(开源页面):    http://www.discuznt.com/opensource.html        Discuz!NT v2.0 源码包    for .net Framework 2.

    如果大家从官方下载2.0正式版的DLL程序集中会从里面找到discuz.config这个DLL文件。通过reflector 反射加载这个程序集后，后从中找到一些从类名称上非常相似且有一定规律（格式）的类。它们是：    全局配置类    GeneralConfigFileManager.cs    GeneralConfigInfo.cs    General

    其实这个控件的核心基本都在JS上，而相关的数据绑定和显示却非常简单。而需要说明的是在Discuz!NT的1.0和2.0正式版，这个控件做过一些调整，当然改动也基本上是在JS上，今天给大家的源码是1.0正式版的代码，虽然有些“旧”，但程序本身的思想没变，大家只要明白了这里的源码，有了这碗酒垫底，相信再看即将开源的2.0代码，就会一目了然了。    好了，废话到此，马上开

    自从 9月未开始写关于"ICONIX方法"的系列文章以来，到今天已有两个多月了，当初因为兴趣点的转移才划一段落的Discuz!NT 系列文章，从今天开始又要开始续写了。这写这个系列以来，大家对我写的内容也是包贬不一，其实这也是众口难调所致，我会在接下来的几篇随笔中尽力顾及大家的感受和阅读口味。最后还是希望大家能支持我们的这个开源项目。    好了，开始今天的话题!

       在之前的两篇文章中，基本上介绍了如何录制脚本和生成并发用户，同时还对测试报告中的几个图表做了简单的说明。今天这篇文章做为这个系列的最后一篇，将会介绍如何通过测试报告来查看系统的运行情况，找出影响性能的因素，以及如何去进行优化。       首先，看一下这张并发用户的图：             这是在优化之前我生成的测试报告的截图，通过这张图可以看到这个测试过程长

      DiscuzNT3正式版发布已经有一段时间了，最近半年多来很少再写关于这个产品的技术文章了，一是时间，二是精力有限。不过在正式版发表之后，倒是有了些功夫，同时我们的一个商业客户在从2.6版本升级到3.0正式版之后，出了一个小插曲，导致不得不退回到2.6版本。因为这个客户的论坛访问量和发帖量比较大，平时在线人数5000，日发帖量在2-3万左右。所以出了一些性能上的问题，在大并发情况

在开发LLServer的同时，我一直在跟进测试企业版的相应LLServer客户端，目前这部分代码已测试完毕并提交的Discuz!NT产品中，会跟随最新的源码包一并发布。本文主要是介绍一下产品中引入LLServer的架构思路。     在Discuz!NT的企业版产品中，使用了