自己做网站百度能收录码,企业解决方案怎么写,翻译软件翻译英语做网站,wordpress稳定版本多WEB部署时#xff0c;面临的核心问题是WEB服务器间的数据共享和同步。就数据存储的方式而言#xff0c;Discuz数据包含两部分#xff0c;一部分存储在MySQL数据库中#xff08;用户、帖子等文本类、结构化的数据#xff09;#xff0c;一部分存储为文件#xff08;附件… 多WEB部署时面临的核心问题是WEB服务器间的数据共享和同步。就数据存储的方式而言Discuz数据包含两部分一部分存储在MySQL数据库中用户、帖子等文本类、结构化的数据一部分存储为文件附件、缓存文件等。其中存储在MySQL中的数据可以方便地在多服务器间共享扩展和冗余也已经有比较成熟的方案。这里我们主要讨论Discuz文件类型的数据部分涉及到多台MySQL服务器的内容。Discuz文件类型的数据都存储于DISCUZ_ROOT/data目录各目录主要功能如下data/p_w_upload 附件类data/log 运行日志data/cache 配置参数类缓存文件默认是sql配置参数通过pre_common_syscache表缓存、CSS缓存、部分JS缓存data/template 模块缓存data/threadcache 论坛页面缓存针对游客的优化DISCUZ_ROOT/data目录下有几个重要的文件文件锁data/install.lock 安装程序锁定。如果该文件存在DISCUZ_ROOT/install/中的安装程序不能执行。data/sendmail.lock 发送邮件锁。Discuz默认通过类似home.php?modmiscacsendmailrand1379315574这个隐藏页面调用由用户的浏览行为触发邮件发送流程浏览器侧用一个300秒的cookie控制频率服务器侧通过sendmail.lock文件的mtime控制频率5秒。如果可以控制 服务器应该优化掉这个机制。data/updatetime.lock 某管理后台使用的锁。data/update.lock 系统升级锁。执行版本升级程序如x2升级到x3时会生成这个文件锁。下面这些功能会涉及到多web服务器间的数据共享和同步默认Discuz通过MySQL实现。用户session 表pre_common_session管理面板session 表pre_common_admincp_session系统配置项缓存 表pre_common_syscache我们假设部署两台web服务器的场景且web服务器也是php应用服务器。我们需要解决data目录共享的问题引入NFS服务可以简单解决这个问题。服务器复用此处不表。这里会有一个选择哪些目录放置在NFS上从上面的分析来看将data目录放置在NFS上即可即各web服务器均独立部署程序文件将NFS挂载到data目录节点缺点是需要将程序文件部署到每一台web服务器上要解决程序文件更新部署的问题优点是可以节省web服务器通过网络取NFS上的程序文件的开销。如果图方便也可以把程序文件也放到NFS上则所有文件都只有一个副本了程序更新也很方便缺点是会增加web服务器通过网络取程序文件的开销。这两者需要权衡建议第一种。上面的方案存在一些问题。当用户访问一个附件时WEB服务器都需要通过网络从NFS上取文件这给内网网络带来了压力和一些不必要的开销这可以通过在web前端增加缓存机制来缓解如squidnginx的proxy cache等。为静态资源配置单独的域名供访问也是值得实施的工作Discuz可以很简单的做到这一点通过配置“本地附件URL地址”项就可以实现附件类data/p_w_upload目录里的文件URL重构但后台发布的广告不行有BUG在X3版本测试。在使用文件锁且依赖于文件的mtime等时间值执行逻辑时请务必保证服务器时钟的一致性。上面的方案简单且对Discuz的改造很小维护成本低适合单台服务器向多台服务器数量较少扩展时选择。随着访问量和web节点的增加内网流量NFSMySQL均需要进行扩展。MySQL的扩展有较成熟的方案如主重复制机制。NFS这个稍稍麻烦一点且很多人诟病NFS的文件共享机制不安全论坛附件以较小尺寸几百字节不等的文件居多而linux的ext文件系统的块大小一般是4K从而浪费了存储空间对inode的利用率也不好从长远来看NFS终将成为系统的瓶颈我们有必要重新规划文件共享/同步机制。这里我们先讨论文件共享问题MySQL扩展涉及的问题后面一点再说明。目前很多公司都有解决大量小文件存储的方案如国内某大互联网公司使用基本MangoDB的GridFS等。实现的细节不在讨论范围其基本思想就是构建文件存储服务把附件类静态文件存储到远端远端系统返回一个URL供访问并且由这个远端系统处理用户访问的各种优化等。我们讨论如果已经有了这样的一个服务Discuz接入到这样的一个服务需要注意些什么。在这之前我们来看一下Discuz的附件上传、存储流程。帖子附件的上传和帖子的发布是异步的。附件上传后的实体文件会被存储到类似data/p_w_upload/forum/201307/20/路径同时会在附件表中pre_forum_p_w_upload_unused添加相应记录发布帖子时这些记录被散列分布到相应的附件表pre_corum_p_w_upload_[0-9]中并标识其所属的pid, tid。这是附件本地存储的流程。远程附件Discuz支持“远程附件”功能全局上传设置远程附件。“远程附件”功能支持将附件通过FTP的方式存储到远端系统如果网站当前没有文件存储服务但又想将文件存储分离使用这个内建功能也是一种不错的选择毕竟FTP很好维护也不需要对Discuz进行改造。虽然Discuz默认只支持FTP方式但远端存储在功能接口层面基本是共同的概念添加、删除之类。所以当要把“远程附件”扩展到自有的远端文件存储服务时一个比较好的实践是继承Discuz的ftp类用远端文件存储的功能重写Discuz的ftp类定义的各方法然后在ftp类实例化的地方调用这个新的子类如果不打算保留默认的FTP机制甚至可以直接修改Discuz的ftp类实现这样连ftp类实例化的地方也不用修改了。这样的处理对Discuz的改造最小细节都隐藏在了ftp类的实现中遵守与ftp相同的行为模式。远程附件将大部分的静态资源流量分离我们可以分别的优化两个系统。但Discuz的远程附件的行为模式仍需要我们注意我们必须清楚它是怎样运行的是否有某种陷阱以便于系统的某些功能行为表现异常时心里有底。1开启远程附件时附件上传、存储流程附件异步上传阶段与本地存储是一样的附件始终会先被上传到类似data/p_w_upload/forum/201307/20/路径同时会在附件表中pre_forum_p_w_upload_unused添加相应记录发布帖子时这些记录被散列分布到相应的附件表pre_corum_p_w_upload_[0-9]中并标识其所属的pid, tid。然后向远端上传附件数据上传完成后会删除掉本地的副本并将附件表pre_corum_p_w_upload_[0-9]的remote字段标识为远程附件类型。2在什么时间点执行向远端上传附件上传到远端的时间点是发布帖子的时候且在该进程周期内上传该帖子的所有附件阻塞模型。这会有一些风险点如果上传附件到无端系统花费的时间较长一个帖子的附件很多、很大或网络带宽限制用户界面的响应体验会有很明显的卡顿感甚至页面超时失败。3已知会被存储到远端的数据帖子附件4已知不会存储到远端的数据或者说会被存储在本地帖子附件在上传到无端之前会存储在本地。“游客查看小图”需要启用“游客登陆查看大图”功能小图是用类似forum.php?modp_w_picpathaid4size100x100key05869b37379ff990type1的调用生成的。小图生成并存储在类似data/p_w_upload/p_w_picpath/000/00/00/123.gif 且会在本地保留副本。活动贴的封面不会存储为远程附件。编辑帖子时显示的缩略图所见即所得是即时生成的通过网络访问远端获取原图生成这个缩略图的过程中会把图片存储到data/p_w_upload/temp目录图片数据内容输出到浏览器后该位置存储的的缩略图被会删除。图片附件的缩略图都是通过forum.php?modp_w_picpathxxx 这个模块生成的。用户可以通过拼装请求使服务器侧执行生成远程附件的本地副本的流程所以这里可能存在某种风险。从上面关于“远程附件”的讨论我们看到即使启用了“远程附件”机制但Discuz仍然会在众多功能上用到data目录下的多个子目录且有的子目录还必须在多个web服务器间共享如data/p_w_upload。所以如果不对这些功能点进行改造我们仍然需要NFS这个设备毕竟远程附件已经将大部分的流量分走了NFS是保证业务正常运行的最简单的办法谁知道还有多少其它功能会依赖于此呢MySQL扩展在Discuz的业务模型上对MySQL进行扩展使用最广泛的机制是“主从复制”、“读写分离”。Discuz本身也支持这些机制最近的版本还支持分库的部署我们不讨论这些机制部署的细节我们讨论将Discuz部署到这样的环境中时需要做出的一些调整。1复制延迟造成的主库、从库数据不同步。复制机制的延迟虽然很小但总存在即使是这种很小延迟也足以给系统带来行为异常特别是实施“读写分离”的场景。在Disuz业务场景中以下情况是曾经出现过的在后台配置的参数不起作用有可能是配置项写入了主库pre_common_setting同时在主库删除了配置的缓存pre_common_syscache但在数据同步到从库之前另一个请求发现pre_common_syscache没有缓存于是触发了生成缓存的流程这个流程会在从库中读到旧的配置项“读”操作是在从库。类似的场景还有很多如刷积分管理员进后台异常等。解决类似这种与时序相关的场景往往需要针对个例去处理就缓存这个问题建议是在程序更新时间点统一生成好缓存且避免线上对配置的操作。2仅将需持久化的数据同步到从库。如pre_common_session、pre_common_admincp_session, pre_forum_threadaddviews这类数据是不应该同步到从库的它们更新非常频繁且都是临时性的它们应该被配置为忽略同步的表replicate_wild_ignore_table选项或者更好的办法是通过其它机制处理如memcache、redis等来实现从而彻底从数据库中分离。从库同步主库的写操作时同样会使用写锁而这些性能开销是不必要的、应该优化以使从库最大限度的服务于核心内容的读取查询。其它一些多web部署时要注意的问题改造内置计划任务。默认Discuz内置的计划任务是通过用户浏览行为触发的如果能控制 服务器这应该改成用操作系统的计划任务驱动Discuz!提供了api.php?modcron稍作改造即可。仅在某一台WEB服务器上部署并且将Discuz的每个任务单独部署成操作系统计划任务的一项有一种选择是只部署一个“每分钟”周期的计划任务然后由这个任务每分钟的轮询操作来驱动Discuz内置的计划任务机制不建议这种做法计划任务的数量毕竟是很有限的、执行的频率也是有计划的。使用“文件”缓存配置项数据。即 $_config[cache][type] fileDiscuz默认是使用的MySQL存储配置缓存表pre_common_syscache。$_config[cache][type] sql如果开启了内存缓存机制如memcache这些缓存数据会放到缓存中以缓解数据库的压力。这些缓存项是每个动态页面都需要调用的所以如果浏览量高的话这种方式在网络等方面的开销累计起来就很可观了。建议使用文件缓存这部分数据缓存文件跟着程序文件一起部署每套程序文件都有一套配置项的缓存文件的副本从而完全优化掉了这部分开销。优点将配置项的缓存写入文件是Discuz内置的机制无需改造磁盘文件IO稳定性是最好的成本是最低的避免中心节点故障带来的风险上线时间点所有配置项缓存已经生成客观上达到了“暖缓存”效果。缺点在系统上线部署之前需要生成全部的配置项缓存文件Discuz默认的生成缓存文件的策略Discuz默认的策略是“找不到缓存再生成”对于短时间并发较高的系统这种策略往往会造成多个处理进程同时触发写缓存的情况不能满足这个需求这需要一些开发量。在具体实施时有一些建议。生成的缓存文件同程序源代码一样纳入版本控制以便于跟踪配置变化。而通过后台UI操作存储在数据库中的配置数据则没有这么方便。配置项缓存的生成比较简单按照pre_common_syscache表的记录生成即可。同理模板缓存文件也可以在上线部署前完成生成只是模板缓存文件初始化会麻烦一些建议收集最常用页面的入口建立脚本来触发。如果要覆盖Discuz默认的配置项的值建议启用一个配置文件用新值覆盖旧值尽量避免管理后台UI操作特别是线上环境因为配置参数最终需要与配置项缓存文件同步才能起作用。所有WEB服务器上部署程序的路径要完全一样。Discuz的缓存项会生成一些绝对路径一个例子是“本地附件保存位置”配置项通过管理后台“全局上传设置基本设置”操作。mysql select * from pre_common_setting where skeyattachdir;------------------------------| skey | svalue |------------------------------| attachdir | ./data/p_w_upload |------------------------------表pre_common_syscache cnamesettingmysql SELECT * FROM pre_common_syscache WHERE data LIKE %p_w_upload%;在输出结果中查找attachdir有类似下面的内容s:9:attachdir;s:39:D:/Apache/htdocs/./data/p_w_upload/;这些绝对路径需要在所有WEB服务器上存在且功能匹配。如果网站的部署路径发生了变更重新生成这些缓存项值。“论坛页面缓存”“论坛首页缓存”只针对游客有效、缓存帖子这些缓存数据默认被存储于data/threadcache目录特别的这些缓存数据没有过期删除机制往往会生成大量缓存文件需要注意监控缓存目录的情况。有些建议是使用类似memcache这样的有过期控制机制的设备来改造这个缓存可能需要权衡网络的负载。“优化更新主题浏览量”、“附件下载量延迟更新”选项。如果是通过写文件的方式缓存这部分数据建议把这些文件存储在各web服务器上而不是写到NFS上以减少网络开销各种锁在把数据汇总到数据库中时需清理每台WEB服务器上的相关日志。最近的X版本通过“pre_forum_threadaddviews”表来缓存主题浏览量个人感觉写文件的方式对于均衡性能方面更好。通过上面的优化步骤后只有data/p_w_upload目录需要在各web服务器间共享所以把NFS挂载到该目录即可。保持这个位置可以在WEB服务器间共享可以在最小改造下避免众多已知和不预知的问题场景出现。mount /PATH/TO/DISCUZ_ROOT/data/p_w_upload NFS_SERVER:/PATH 转载于:https://blog.51cto.com/dikeen/1299948
