摘要：在开发LLServer的同时，我一直在跟进测试企业版的相应LLServer客户端，目前这部分代码已测试完毕并提交的Discuz!NT产品中，会跟随最新的源码包一并发布。本文主要是介绍一下产品中引入LLServer的架构思路。在Discuz!NT的企业版产品中，使用了Memcached,Redis这两个软件来提供分布式缓存服务（两者任选其一）。现有又有了LLServer,它不仅提供了KEY/VALUE缓存，还包括持久化存储部分。这样，用户可以有更多大的选择余地。下面是Discuz!NT的企业版分布式缓存中一个架构图： 阅读全文

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

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

摘要： 在前文中，介绍了Discuz!NT引入SPHINX的背景和相应的客户端的C#代码架构实现。今天这篇文章将会介绍如果在LINUX环境下安装配置SPHINX中文搜索工具，也就是服务器配置方案. 目前在网络上可以找到的SPHINX中文插件主要有两个: 1.coreseek: http://www.coreseek.cn/ 2.sfc: http://code.google.com/p/sphinx-for-chinese/ 其中的coreseek是目前对Discuz(PHP版)支持做的比较好的插件，它提供了相应的工具和源码包来尽可能简化sphinx的安装和配置。大家可从网上找到很多相关信息。 阅读全文

摘要： 作为Discuz!NT企业版中的一员，在设计企业级搜索架构之初，就考虑了海量数量，准实时索引更新，并发访问，安装布署等诸多方面。目前在生产环境下被广泛使用的开源搜索引擎中，sphinx以其强大快速的索引功能，优异的并发响应性能，方面灵活的布署，分布式查询等诸多因素而倍受青睐。 目前Sphinx广泛应用在Linux平台上，尽管官方所发布的产品中也有window版本，并且支持mssql数据库，但在使用过程中才发现，其只在发布的windows平台下的版本里才支持mssql数据库，而linux平台下只有MySql,PostgreSQL这两种数据库支持。尽管后来在网上查找资料时发现可以使用UNIXODBC方式在LINUX下链接MsSql数据库，但在unixodbc的官方网站下载的源码包中却发现其并不包含 makefile文件，从而导致下载解压的源码包无法编译（看来unixodbc开发者也疏忽了），当然即使ODBC能链接成功，但效率上还是可能存在问题。 阅读全文

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

摘要： 目前在Discuz!NT这个产品中，数据库作为数据持久化工具，必定在并发访问频繁且负载压力较大的情况下成 为系统性能的‘瓶颈’。即使使用本地缓存等方式来解决频繁访问数据库的问题，但仍旧会有大量的并发请求要访 问动态数据，虽然 SQL2005及2008以上版本中性能不断提升，查询计划和存储过程运行得越来越高效，但最终还是 要面临‘瓶颈’这一问 题。当然这也是许多大型网站不断研究探索各式各样的方案来有效降低数据访问负荷的原 因， 其中的‘读写分离’方案就是一种被广泛采用的方案。 Discuz!NT这个产品在其企业版中提供了对‘读写分离’机制的支持，使对CPU及内存消耗严重的操作(CUD)被 分离到一台或几台性能很高的机器上，而将频繁读取的操作(select)放到几台配置较低的机器上，然后通过‘事务 发布订阅机制’，实现了在多个sqlserver数据库之间快速高效同步数据，从而达到了将‘读写请求’按实际负载 情况进行均衡分布的效果。 阅读全文

摘要： 在之前的文章中，提到了在Discuz!NT中进行缓存分层的概念。之前在产品中也实现了其中的构想，但该方案有一个问题，就是如果将产品进行分布式布署之后，如果某一站点发生数据变化时，只能更新本地缓存和Memcached缓存信息，而其它分布式布署的站点则无法收到缓存数据已修改的‘通知’，导致数据不同步而成为‘脏数据’。 虽然在之前的文章中提到通过将本地缓存失效时间‘缩短’（比如15秒后即失效），以便在相对较短的时间内让本地数据失效从而再次从Memcached读取最新的数据，但这必定不符合我们设计的基本思路，并且导致程序的运行效率低，同时会造成过于频繁的访问Memcached，无形中增加了与 Memcached的socket开销。所以才有了今天的这篇文章。 阅读全文

摘要： 在Discuz!NT的最新版本中，支持目前主流LINUX平台上的负载均衡解决方案，比如NGINX,HAPROXY,LVS等。本文与其说是解决方案，倒不如说是介绍如何搭建Discuz!NT负载均衡解决方案：） 因为我们的产品运行的主流平台是WINDOWS+IIS+SQLSERVER（2000以上版本），而LVS+KEEPALIVED是LINUX下的四层负载均衡软件。其有如下特点：LVS集群采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率（在DR模式下），将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。为此，在设计时需要考虑系统的透明性、可伸缩性、高可用性和易管理性。一般来说，LVS集群采用三层结构，其主要组成部分为： 阅读全文

摘要： 在目前最新版本的产品中，我们提供了缓存静态文件的解决方案，就是使用SQUID做静态前端，将论坛中的大部分静态文件布署或外链到一个新的HTTP链接上，其中可以外链的静态文件包括： 1.Discuz.web/Javascript/ 下所有以‘template_’打头的JS文件以及该文件夹下的部分js文件。 2.模版文件夹下的所有CSS或IMAGE文件（空间相册文件夹除外） 3.前台Image文件夹下的Medal（勋章），Topicidentify（主题鉴定图标）下的所有文件。 阅读全文

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

摘要： 在以前的两篇文章(Discuz!NT 缓存设计简析, Discuz!NT中集成Memcached分布式缓存)中，介绍了Discuz!NT中的缓存设计思路以及如何引入Memcached，当然前者是IIS进程的缓存（本地缓存），后者是分布式内存对象缓存系统。两者通过Discuz!NT中的memcached.config文件中的ApplyMemCached结点的值来决定使用哪一种缓存方式。不过在之后，有朋友反映当使用Memcached时，特别是在大并发来时，效率会打折扣，甚至有很多时间会消耗在socket套接字（创建和传输方面）上。而事实上也的确如此，尽管Memcached在使用池化的方式初始化一定数量的套接字资源（之前测试时实始化为128个链接），在小并发（100左右）时，可能问题不大，但并发上了1000-2000时，其效率要比本地化缓存机制低1/3（loadrunner测试场景），比如loadrunner测试1000并发时，如果showtopic(显示主题)，本地缓存处理时间为15秒，而使用memcached可能会达到25-35秒。 阅读全文

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

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

摘要： DiscuzNT3正式版发布已经有一段时间了，最近半年多来很少再写关于这个产品的技术文章了，一是时间，二是精力有限。不过在正式版发表之后，倒是有了些功夫，同时我们的一个商业客户在从2.6版本升级到3.0正式版之后，出了一个小插曲，导致不得不退回到2.6版本。因为这个客户的论坛访问量和发帖量比较大，平时在线人数5000，日发帖量在2-3万左右。所以出了一些性能上的问题，在大并发情况下，服务器响应超时，且在峰值时越发不稳定。之前我在公司内部用了tinyget做了一些简单的压力测试，发现了一些问题，但原因尚不明显，所以在公司会议上就有人提出使用loadruner来做一下压力测试，看看3.0产品的性能倒底如何，是什么造成用户的服务器不稳定。所以就有了今天的这篇文章。 阅读全文

摘要： 在去年我曾写过一篇文章:“推荐一个Silverlight多文件(大文件)上传的开源项目”。之后有不少朋友询问这个项目示例在开发和配置上的一些问题。当时因为时间有限没有做过多的说明，导致有些问题在大家下载完源码之后运行时才出现。今天就以这个项目为原型，简要介绍一下在DiscuzNT上是如果在该项目基本上，通过完善权限管理，文件大小控制，添加缩略图效果等功能来大体阐述一下如果开发一个真正的silverlight应用，而不是一个简单的DEMO. 阅读全文

摘要： 大约在两年前我写过一篇关于Discuz!NT缓存架构的文章，在那篇文章的结尾介绍了在IIS中如果开启多个应用程序池会造成多个缓存实例之间数据同步的问题。虽然给出了一个解决方案，但无形中却把压力转移到了磁盘I/O上（多个进程并发访问cache.config文件）。其实从那时起我就开始关注有什么更好的方案，当然今天本文中所说的Memcached，以及Velocity等这类的分布式缓存方案之前都考虑过，但一直未能决定该使用那个。起码Velocity要在.net 4.0之后才会提供，虽然是原生态，但有些远水解不了近火。 阅读全文

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

摘要： 在上一篇中, 我们了解了为提供支付宝在线支付功能，所需要的一些助手(helper)类, 在本文中，我们将会以一个线上支付流程来进一步介绍业务设计上的一些内容和思想。在之前的线下支付流程中，我们看到交易是靠买卖双方不断更新本地的交易状态来进行推动的。而线上支付这个过程的推动主要靠支付宝那面的操作来完成，而本地服务器只是提供了交易信息并进行跳转(到支付宝)。并接受支付宝回传过来的交易信息，来更新本地数据库中的交易状态并发送站内消息给买家或者卖家。了解了上面的信息之后，我们通过一个简单的例子来加以说明，同时按“老规矩”，在介绍过程中穿插对源代码的讲解。 阅读全文

摘要： 在上一篇文章中，介绍了商品交易线下交易流程，这一篇则重点介绍一下线上支付宝交易流程。在开始今天的正文之前，有必要介绍一下关于支付宝交易信息通知的一些内容，因为我们的商品交易插件使用了其中的一种通知方式。在支付宝系统中，当交易发生时，根据系统的“处理方式”分为两类： 阅读全文