Jump to Navigation

WEB

WEB/PHP开发

membase-1.7数据库导出备份

*) 存储位置/opt/membase/var/lib/membase/default-data/
*) 执行数据备份:
cd /opt/membase/
./bin/mbbackup ./var/lib/membase/data/default-data/default /data1/backup/
注意上面的命令的第一个参数,指向桶的名字命令的数据文件default。
这样就把default桶的数据导出来了。查看导出文件大小,
ls -lh /data1/backup/
这个mbbackup命令没有别的参数,也没有别的选择,这么执行就ok。
这么备份出来的是整个集群的数据吗?还是只这个结点的呢? 对,数据仅是在这个结点上的。
*) 配置备份
./var/lib/membase/config/config.dat
把这个配置文件也一起备份了,或者还是把./var/lib/membase/config/整个目录也备份了呢。
这个目录只有一个文件,效果一样的。
*) 执行恢复

Category:

本套shell+gearman+PHP方案实现技术解析

本套shell+gearman+PHP方案实现技术解析

*)配置信息文件

使用shell脚本的加载,source 命令加载配置信息文件,

这个脚本看上去是个ini文件,但这种语法也是shell脚本的基本变量声明语法,

这种方式对于复杂的脚本还是非常有用的,可以把脚本的控制逻辑与配置信息分离开。

*)简单进程控制,

使用shell相关的命令和功能实现,

获取运行脚本路径信息,$(readlink -f $0)

获取运行脚本的目录信息,$(dirname $(readlink -f $0))

加载配置变量信息,后台启动PHP进程,并传递相应的参数,

使用$!获取启动的PHP进程的pid,存放到pid文件,

为下次关闭该进程或者查看该进程状态作准备。

为了防止启动PHP进程失败,使用shell的$?命令获取进程启动返回值,为0时成功。

使用shell的进程输出重定向功能">>",实现启动的PHP脚本程序输出日志存储在指定的日志文件中。

*)GearmanWorker的封装

Category:

分布式消息中间件汇总

最近分布式消息中间件非常热门,这是随着IT行业大数据的兴起与分布式处理兴起而热起来的。

最终原因还是在于IT技术需求,要求处理的数据越来越多,要求处理的逻辑越来越复杂,但要求响应时间越来越短。

这些消息组件的作用,大致可分为两类,用于数据队列,用于任务队列。

现有的成型分布式消息组件,

gearman

beanstalkd

activemq

zookeeper

zeromq

metaq

在做项目选型时,可能考虑的就比较多,需要多做它们实现机制的比较,

确定哪个组件更适合自己当前的项目需求。

Category:

后台PHP进程的多版本框架可重入方法总结

PHP一般用于web 开发,执行一次结束,而对后台PHP进程相关机制的支持不是太好。

由于系统需要的原因,对它的这种后台运行方式考虑了一段时间,总结出几种方法,

*)使用启动新进程的方法,可以完全启动一个新的PHP运行环境
*)使用PHP 的 runkit扩展,在当前的进程中生成一个全新的PHP虚拟运行环境
*)使用pcntl_fork方式生成一个新进程,这个进程与执行fork时的父进程相同,但之后的环境是全新的。

但是这三种都各有优点与不足的地方,
第一种,效率上可能是问题,再有是难以控制
第二种,这个扩展的稳定性还有待测试,效率上不太好说,也类似创建一个新的虚拟机支持环境
第三种,这个对新生的进程有影响,不是完全全新的PHP运行环境。

这个问题的来源在于,对于使用include*,require*引入的文件中包含的类和函数,都是全局有效的。
在使用多版本的框架后,第一次加载的框架版本会影响后续的执行代码所引用的框架版本,必然会导致后续代码的执行结果。

Category:

依托现有基础组件的gearman部署方案

gearman属于异步任务框架,目前实现了gearman框架相关封装管理工作,
*) 包括启动停止管理php程序编写的worker相关程序,
*) 包括启动信息管理gearmand job server的相关脚本程序
*) 一些动态检测gearman集群状态及部署状态的核心worker

Category:

nginx耗时模块的不阻塞主事件循环的异步处理机制

1) 在模块中生成线程池,把nginx的请求交给线程序池来处理

不过,需要在模块的handler中把r->main->count++,并且返回一个NGX_DONE,

这个值必须+1,否则在handler返回后,连接会被nginx断掉。

2)使用upstream机制,把耗时请求放在backend进程处理,把nginx当一个连接池使用

这种方式稍微复杂,不是单单nginx模块的问题,实际是开发一个独立的fastcgi进程或者其他协议服务进程,

通过upstream访问后端。

线程池模式示例代码:

static ngx_int_t ngx_http_nullimp_handler(ngx_http_request_t *r)
{
r->main->count += 1;
pthread_t pth;
int pcr;
pcr = pthread_create(&pth, NULL, test_thread_proc, (void*)r);

return NGX_OK;
}

Category:

nginx worker的调度策略

1)accept_mutex = on,在低连接量的情况下,大都由一个worker处理

2)accept_mutex = off,每个连接都激活所有的worker,哪个worker抢到算哪个的

这种在worker多的时候容易有惊群问题。

3)使用worker绑定CPU的方式,按照连接进来的顺序,设定每个CPU(worker)可接收的连接

配置麻烦,不同的机器需要不同的配置。

4) 倒置配置法??? worker_process 为128, 但每个work_connection设置为1,是否可行

保证在前一个连接没有处理完成之前不再接收新的连接。

Category:

couchbase应用注意事项

尽量使用failover

少用rebalance

有出问题且无法恢复,先停止该节点进程再执行删除

设置bucket的数据目录,不要存储在默认位置

对使用内存要求不同的数据使用不同的bucket,设置不同的内存资源

对非重要数据不做replicate备份。

couchbase-1.8的离线备份速度非常慢,占CPU非常高,能看到是使用sqlite3命令备份的。

不要存储大于50K的文本数据或二进制数据。

couchbase-1.8.0某个bucket太大(>200G,分配内存比较小1-2G),可能导致重启动后无法恢复,一直处理pend状态,无法提供服务。

太大的bucket还是导致无法加入新的节点,也是一直处理pend状态,无法提供服务。

不要在centos-5.4系统及更低版本系统上安装,系统负载稍大(load>80)可能会出些couchbase宕机问题。

Category:

基于/proc/loadavg的web前端压力自调节模块设计

cat /proc/loadavg

从负载500的时候开始有选择的放弃某些请求的处理

500-600 10%

600-700 20%

700-800 40%

800-900 70%

900-1000 100%

1000以上的时候系统就崩溃了。

设定每一档压力放弃20%的请求,到1000之后,不再处理任何请求

放弃的请求放入队列中,随后慢慢的模拟发起这些请求。

需要在服务器还能动的情况下才有效,否则,做判断的请求未必能有机会执行。

Category:

基于couchbase的全局日志系统设计

web系统的日志记录很重要,但单独设置独立的日志系统很费开发与维护。

导致现有的系统日志记录零散混乱无规则。

对现有的日志记录方式的总结:

×)在本机上记录日志文件

×)记录到关系数据库中,如MySQL

×)临时记录,测试完后删除日志代码

现有的web系统一般都是基于负载均衡的多web前端架构,

这几种方式都有比较大的缺点,很难综合存储处理分析web系统日志。

当前比较好的日志方式:

×)独立的日志系统,为各web系统提供日志记录服务,提供查询

这种方式引入了系统维护与开发复杂度,同时由于处理大量日志,

还需要投入大量硬件资源来满足大量的日志处理。

在现有的无法满足大量独立硬件资源的情况下,在现有的系统基本之上,

使用couchbase来实现全局日志系统,其优点有,

×)不需要新加硬件

×)充分利用web前端空闲的硬盘存储资源

×)不需要新加软件系统

×)实现分布式日志系统

×)效率比较关系型数据库高

×)很容易导出到其他非线上机器实现离线数据处理与分析

×)存储任意结构数据

Category:

页面

订阅 RSS - WEB


Main menu 2

by Dr. Radut