MySQL主从复制性能优化

MySQL的主从复制的基本原理是从库连接到主库,主库生成一个主库DUMP线程,该DUMP线程的主要任务是
一直挖掘binlog日志,然后发送到从库的IO线程,IO线程接收到日志流后,写入relay log,另一个线
程SQL线程,会读取该relay log内容,然后对sql语句进行重放.

主库DUMP线程会根据从库传来的文件位置信息去读取binlog文件中的内容,DUMP线程并不是每隔一段时间去
读取的,而且在主库上当有写binlog日志时,会产生同步,那么DUMP线程根据同步机制会立即去读取binlog
文件.当主库去写binlog时,DUMP线程去读,问题很快来了,这样的情形可能会产生读写冲突,有时候我们
也把这种情况称为”IO抖动”,如果我们的服务器配置了RAID的cache,或是使用文件系统的cache,当一个写操
作的时候,可能并不会真正的写到磁盘上去,而是写到cache中去了,这样再次去读的话,直接从cache中
读取就可以了.

如果主库有多个从库,DUMP线程和服务器的写binlog线程,DUMP线程和DUMP线程之间读写争用会更加频
繁,如果使用了SSD存储,这种情况可以得到好的的缓解.

当DUMP线程接收到同步事件后,开始执行DUMP操作,这时候在主库上不应该存在CPU负载过高,而使DUMP线程在
运行队列中等待时间过长.

对于需要binlog复制的库,我们在主库使用binlog_do_db,而避免对所有的库操作都生成binlog。不过我
在使用这个参数的时候需要小心测试,因为有些应用写库的方式可能会导致binlog数据丢失.
主库DUMP线程通过网络发送给从库的IO线程,DUMP线程本身不提供压缩功能,所以这时候足够的带宽变得很重
要,特别是对于跨公网的传输,另外可以通过在网络层面上使用网络设备自带的压缩的功能来弥补这方面的不足.
当IO线程接收到binlog后,往relay log里面写数据,存储本身的速度和在每次接收后是否立即同步到磁盘上
的相关参数对IO线程处理的速度变得极为重要.比如sync_relay_log,sync_master_info 和sync_relay_log_info三个参数,
具体的值可能要视环境而做出调整。比如sync_relay_log设置为0,每次接收到数据后不直接写磁盘,而依赖OS去刷新到磁盘上.
SQL线程的原理和DUMP线程的原理很类似,当有relay log日志写入时会产生同步,那么SQL线程就会去读取其中的数据进行
重放。在MySQL 5.6中很重要的一个提升就是可以多个SQL线程可以同时工作,这样增加了吞吐量.可以设置slave_parallel_workers
来达到这样目的.从库上的其他参数比如innodb_flush_log_at_trx等,虽会加快sql线程的吞吐量,但是可能需要缩合考虑
而不仅仅是针对SQL线程.

addslashes与mysql_real_escape_string的区别

addslashes和mysql_real_escape_string.都是为了使数据安全的插入到数据库中而进行过滤.那么这两个函数到底是有什么区别呢??
我们今天来简单的看下..
首先.我们还是从PHP手册入手..
手册上addslashes转义的字符是单引号(’)、双引号(”)、反斜线(\)与NUL(NULL 字符)。
mysql_real_escape_string转义的字符并没有被提到.只是说了一句
注意: mysql_real_escape_string() 并不转义% 和_。
为什么PHP手册没有说呢?因为其实这是个MySql的C的API.所以我们需要查下MySql手册..上面是这么说的.
编 码的字符为NUL (ASCII 0)、’\n’、’\r’、’\’、”’、'”‘、以及Control-Z(请参见9.1节,“文字值”)。(严格地讲,MySQL仅需要反斜杠和引号 字符,用于引用转义查询中的字符串。该函数能引用其他字符,从而使得它们在日志文件中具有更好的可读性)。

不得不说一句.MySql手册上面的话总是令人费解的..

我们为了更深层次的探究这两个函数的不同..还是去看一看PHP的源码吧..

这是PHP的addslashes函数..

PHP_FUNCTION(addslashes)
{
zval **str;
if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &str) == FAILURE) {
WRONG_PARAM_COUNT;
}
convert_to_string_ex(str);
if (Z_STRLEN_PP(str) == 0) {
RETURN_EMPTY_STRING();
}
RETURN_STRING(php_addslashes(Z_STRVAL_PP(str),
Z_STRLEN_PP(str),
&Z_STRLEN_P(return_value), 0
TSRMLS_CC), 0);
}

很显然.它调用了php_addslashes.我们继续看这个函数
Continue reading “addslashes与mysql_real_escape_string的区别”

你想建设一个能承受500万PV/每天的网站吗?

你想建设一个能承受500万PV/每天的网站吗? 500万PV是什么概念?我的服务器每秒要处理多少个请求也能应对?如果计算呢?

PV是什么:

PV是page view的简写。PV是指页面的访问次数,每打开或刷新一次页面,就算做一个pv。

计算模型:
每台服务器每秒处理请求的数量=((80%*总PV量)/(24小时*60分*60秒*40%))/服务器数量
其中关键的参数是80%、40%。表示一天中有80%的请求发生在一天的40%的时间内。24小时的40%是9.6小时,有80%的请求发生一天的9.6个小时当中(很适合互联网的应用,天的请求多,晚上请求少)。

 

简单计算结果:
((80%*500万)/(24小时*60分*60秒*40%))/1 = 115.7个请求/秒
((80%*100万)/(24小时*60分*60秒*40%))/1 = 23.1个请求/秒

初步结论:
现在我们在做压力测试时,就有了标准,如果你的服务器一秒能处理115.7个请求,就可以承受500万PV/每天。如果你的服务器一秒能处理23.1个请求,就可以承受100万PV/每天。(这里不关心是请求的是静态的html,还是动态的jsp,一般认为会执行业务逻辑)

 

留足余量:

以上请求数量是均匀的分布在白天的9.6个小时中,但实际情况并不会这么均匀的分布,会有高峰有低谷。为了应对高峰时段最少也要x2倍,x3倍也不为过,应该留一些余地。

115.7个请求/秒 *2倍=231.4个请求/秒

115.7个请求/秒 *3倍=347.1个请求/秒

23.1个请求/秒 *2倍=46.2个请求/秒

23.1个请求/秒 *3倍=69.3个请求/秒

 

最终结论:

如果你的服务器一秒能处理231.4–347.1个请求/秒,就可以承受500万PV/每天。

如果你的服务器一秒能处理46.2–69.3个请求,就可以承受100万PV/每天。

Continue reading “你想建设一个能承受500万PV/每天的网站吗?”

关于php的libevent扩展的应用

php有个libevent扩展,在一年前我曾经拿它实现了一个thrift socket server,虽然我没有把它放在正式的场合来使用,但是我觉得这个扩展应该可以有更广泛的用途,比如:

  • phpDaemon — 一个异步的服务器端开发框架.
  • tail – 用php实现类似unix下的tail命令行
  • ZeroMQ + libevent in PHP – 用php和ZeroMQ实现的一个事件驱动服务器端

我所想到的一个比较实用的使用场景是,在页面中利用libevent请求多个http接口来获得数据。若是在从前,一个可行的办法是利用 curl_multi_exec来同时请求好几个接口,但是这个办法需要用一个do … while循环来完成请求,很是坑爹。那么看看采用libevent的例子: Continue reading “关于php的libevent扩展的应用”

全站静态生成html的问题讨论收集

全站HTML缓存(这个可能有点中国特色),其实算起来节省的只是服务器的资源,而对服务器有效联网带宽的消耗还是一样的。目前国内大部分虚拟主机已经开始不限制并发连接数,而是用计算单位时间内流量,就可以看出来全站html与否,不是问题的关键。
出于加快页面显示速度的初衷,可以考虑gzip,在CI的config里有设置选项。
还有,就是在程序开发的过程中,尽量多用数组,尽量减少数据库读取的次数,尽量使用缓存(XML方式),再有CI有比较可行的缓存解决方案,也可以参考一下。

ci的缓存是模仿JAVA编译机原理,有点类似zend optimizer。只有在访问后,才可以生成缓存。
如果和模块调用缓存比较的话。CI的缓存机制,可以说成是被动缓存。

实际上CI默认的缓存机制,在某种意义上说,只要你使用,它就是一种静态HTML,而且它的优势是,cache on demand。就是被动缓存。它的更新是时间戳间隔,而不是站长手动更新。

至于用不用Cache这是个争论性问题,没有答案,需要根据实际项目来。

(1)

HTML应该是利用view方法第三个参数,返回HTML并写入文件的,在开发过程中注意URL的管理就好了。

1、HTML比PHP的文件缓存快很多,因为PHP有一个解释的过程。
2、现在搜索引擎看重的不是后缀是域名权重。
3、伪静态对WEB服务器的压力会进一步增大。

reverse:

纯html和php到底谁快,这个可不是绝对的。
再有,伪静态是会占用一点点的系统资源,但也仅仅是一点点。而且这一点点,又被apache/nginx分担了一部分(因为.htaccess)。
纯html与否,纯粹看个人喜好,而不是系统需要(个人观点)。

reply:

php 和 html 有相同的前置处理过程,html无需加载任何解释器,直接输出代码给浏览器。
请问,什么情况下 php 比 html 快?

在大量并发下累计的伪静态资源占用,还是可观的。

html与否应该是取决于系统需要的。

reverse:

我只问楼上一个问题。
无论是纯html,还是php的解释执行,最终是在用户的浏览器解释执行。那么,我的问题是,客户端的解释动作,是在接收全部的html标记(php解释 执行后,也是html标记)后再在页面上显示,还是边接收,边解释。你把这个问题搞清楚,再谈纯html和php是不是就是绝对的。
还有,在服务器层面,数据库读取和PHP解释执行的资源消耗和纯HTML时服务器的I/O消耗,楼上有过精准的测试比较?还是人云亦云?如果有测试比较,你的测试环境和测试数据不妨贴出来。
再有,纯html有很多弊病,如果你的站点更新量不大,服务器硬盘随便用,而且不介意频繁的根据时间戳更新静态页,那就是另当别论了。
静态化并不是什么值得推崇和追求的方式(个人观点)。

还有,我本人最近也总被问到静态化的问题。
我罗列了一下,一些静态化的初衷,居然是降低数据库的调用次数。
其实,降低数据库的访问次数,方法有很多,这个可以在google上一搜一大把,并不是只有静态化才能解决。
还有一些目的是搜索引擎友好,这种需求大多是看了很多SEO方面的资料而发的。我的观点是,一个站点是否经常被蜘蛛光顾,记录,原因不在是不是静态化,而 是站点的内容是不是会让很多人访问。你静态化再完美,每天的IP和PV数量根本达不到搜索引擎的要求,你还会指望蜘蛛光顾么?
还有,就是纯粹的“拉风”需求了。
综合以上三点,所以我说静态化的html,纯粹是看个人喜好了。

再罗嗦一句。
经常也有人用网易、新浪等门户html静态化问我。
我只能说,这种观点是把html“神化”了。门户的静态化html,是不得已而为之,因为他们的数据要保持的时限通常在5年以上。
就说这么多吧,其他的就是个人理解、技术能力和见仁见智的问题了。

reply:

不说谁搞清楚和搞不清楚的问题。
客户端、I/O,这些可以了解成HTML和PHP的共性,至于谁懂谁不懂,就不争论了。

但PHP比HTML多的问题在哪里呢:
PHP解释器,从<?php 开始,服务器就要做额外处理,每一个PHP变量,每一次实例化对象,每个IF的过程,这些在高并发下,服务器压力并不低。

再者伪静态为服务器造成的额外压力,主要在于正则匹配。

同意你说早些年静态化要解决的主要问题之一是数据库瓶颈,这也是现在K-V数据库的意义所在。
只是不能忽略PHP解释器带来的压力,尤其是在后台程序员良莠不齐的情况下。

163 SINA等大量静态化页面,就是符合历史需求,也是在认证 “是否静态化,由项目或环境决定,而不是爱好决定”

reverse:

这个问题确实值得争论一下。
web服务器在内存中解释php并向客户端传递html有压力,从硬盘中读取存在的html并传递给客户端就没有压力?建议楼上再看看大一的计算机基础和CPU的指令集。英特尔的灵动CPU能不能编程是不是必须得买个上网本看看才能知道?
网易、新浪的静态化是不得已而为之,如果楼上搞过分布式+垂直式以及跨地区、跨线路的数据库系统就能明白,这已经与直接输出html或解释php无关了。当然,在CI的论坛里讨论这些问题有些无聊。
对于一般应用,我说的一般应用是web服务器和数据库服务器在一个计算机或在一个网段内,静态化与否纯粹是个人喜好。用一个或几十、几百并发量所得出的所谓测试数据,真的没意义。如果仅仅是因为降低数据库的读取次数,可以参看我前两天发的一个帖子。xml缓存数据库。

系统资源不包括apache/nginx占用的资源??每个一点点量级话后? 如何??对于是否需要使用静态化而言,这个得根据实际需要而定。磁盘、cpu、内存,我想总是围绕这些来转的。不光要考虑性能,价格也是必须考虑的因素。有时候还 是不要一概而定的好,如果只是决定于个人喜好…(省略吧!)。一般情况下,如果应用涉及到了静态化,相信应该是遇到并发问题,采取静态化是可取的。

linux下搭建SVN服务器完全手册-很强大!!!!!

系统环境
RHEL5.4最小化安装(关iptables,关selinux) + ssh + yum

一,安装必须的软件包.
yum install subversion (SVN服务器)
mysql-server (用于codestriker)
httpd mod_dav_svn mod_perl (用于支持WEB方式管理SVN服务器)
sendmail (用于配置用户提交代码后发邮件提醒)
wget gcc-c++ make unzip perl* (必备软件包)
ntsysv vim-enhanced (可选)

二,基本的SVN服务器配置
1,新建一个目录用于存储SVN所有文件
# mkdir /home/svn

2,新建一个版本仓库
# svnadmin create /home/svn/project

3,初始化版本仓库中的目录
# mkdir project project/server project/client project/test (建立临时目录)
# svn import project/ file:///home/svn/project -m “初始化SVN目录”
# rm -rf project (删除临时建立的目录) Continue reading “linux下搭建SVN服务器完全手册-很强大!!!!!”

一致性 hash 算法( consistent hashing )

consistent hashing 算法早在 1997 年就在论文 Consistent hashing and random trees 中被提出,目前在cache 系统中应用越来越广泛;

 

1 基本场景

 

比如你有 N 个 cache 服务器(后面简称 cache ),那么如何将一个对象 object 映射到 N 个 cache 上呢,你很可能会采用类似下面的通用方法计算 object 的 hash 值,然后均匀的映射到到 N 个 cache ;

hash(object)%N

一切都运行正常,再考虑如下的两种情况;

1 一个 cache 服务器 m down 掉了(在实际应用中必须要考虑这种情况),这样所有映射到 cache m 的对象都会失效,怎么办,需要把 cache m 从 cache 中移除,这时候 cache 是 N-1 台,映射公式变成了 hash(object)%(N-1) ;

2 由于访问加重,需要添加 cache ,这时候 cache 是 N+1 台,映射公式变成了 hash(object)%(N+1) ;

1 和 2 意味着什么?这意味着突然之间几乎所有的 cache 都失效了。对于服务器而言,这是一场灾难,洪水般的访问都会直接冲向后台服务器;

再来考虑第三个问题,由于硬件能力越来越强,你可能想让后面添加的节点多做点活,显然上面的 hash 算法也做不到。

有什么方法可以改变这个状况呢,这就是 consistent hashing…

 

2 hash 算法和单调性

 

Hash 算法的一个衡量指标是单调性( Monotonicity ),定义如下:

单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中,又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到新的缓冲中去,而不会被映射到旧的缓冲集合中的其他缓冲区。

容易看到,上面的简单 hash 算法 hash(object)%N 难以满足单调性要求。

 

3 consistent hashing 算法的原理

 

consistent hashing 是一种 hash 算法,简单的说,在移除 / 添加一个 cache 时,它能够尽可能小的改变已存在 key 映射关系,尽可能的满足单调性的要求。

下面就来按照 5 个步骤简单讲讲 consistent hashing 算法的基本原理。

 

3.1 环形hash 空间

 

考虑通常的 hash 算法都是将 value 映射到一个 32 为的 key 值,也即是 0~2^32-1 次方的数值空间;我们可以将这个空间想象成一个首( 0 )尾( 2^32-1 )相接的圆环,如下面图 1 所示的那样。 Continue reading “一致性 hash 算法( consistent hashing )”

CentOS 6.3下Samba服务器的安装与配置

一、简介

Samba是一个能让Linux系统应用Microsoft网络通讯协议的软件,而SMB是Server Message Block的缩写,即为服务器消息块 ,SMB主要是作为Microsoft的网络通讯协议,后来Samba将SMB通信协议应用到了Linux系统上,就形成了现在的Samba软件。后来微软又把 SMB 改名为 CIFS(Common Internet File System),即公共 Internet 文件系统,并且加入了许多新的功能,这样一来,使得Samba具有了更强大的功能。

Samba最大的功能就是可以用于Linux与windows系统直接的文件共享和打印共享,Samba既可以用于windows与Linux之间的文件共享,也可以用于Linux与Linux之间的资源共享,由于NFS(网络文件系统)可以很好的完成Linux与Linux之间的数据共享,因而 Samba较多的用在了Linux与windows之间的数据共享上面。

SMB是基于客户机/服务器型的协议,因而一台Samba服务器既可以充当文件共享服务器,也可以充当一个Samba的客户端,例如,一台在Linux 下已经架设好的Samba服务器,windows客户端就可以通过SMB协议共享Samba服务器上的资源文件,同时,Samba服务器也可以访问网络中 其它windows系统或者Linux系统共享出来的文件。
Samba在windows下使用的是NetBIOS协议,如果你要使用Linux下共享出来的文件,请确认你的windows系统下是否安装了NetBIOS协议。

组成Samba运行的有两个服务,一个是SMB,另一个是NMB;SMB是Samba 的核心启动服务,主要负责建立 Linux Samba服务器与Samba客户机之间的对话, 验证用户身份并提供对文件和打印系统的访问,只有SMB服务启动,才能实现文件的共享,监听139 TCP端口;而NMB服务是负责解析用的,类似与DNS实现的功能,NMB可以把Linux系统共享的工作组名称与其IP对应起来,如果NMB服务没有启动,就只能通过IP来访问共享文件,监听137和138 UDP端口。

例如,某台Samba服务器的IP地址为10.0.0.163,对应的工作组名称为davidsamba,那么在Windows的IE浏览器输入下面两条指令都可以访问共享文件。其实这就是Windows下查看Linux Samba服务器共享文件的方法。
\\10.0.0.163\共享目录名称
\\davidsamba\共享目录名称

Samba服务器可实现如下功能:WINS和DNS服务; 网络浏览服务; Linux和Windows域之间的认证和授权; UNICODE字符集和域名映射;满足CIFS协议的UNIX共享等。

二、系统环境

系统平台:CentOS release 6.3 (Final)

Samba版本:samba-3.5.10-125.el6.x86_64

Samba Server IP:10.0.0.163

防火墙已关闭/iptables: Firewall is not running.

SELINUX=disabled

三、安装Samba服务

1、在可以联网的机器上使用yum工具安装,如果未联网,则挂载系统光盘进行安装。

# yum install samba samba-client samba-swat

有依赖关系的包samba-common、samba-winbind-clients、libsmbclient将自动安装上去。 Continue reading “CentOS 6.3下Samba服务器的安装与配置”

Google Protocol Buffer 的使用和原理

简介

 

什么是 Google Protocol Buffer? 假如您在网上搜索,应该会得到类似这样的文字介绍:

Google Protocol Buffer( 简称 Protobuf) 是 Google 公司内部的混合语言数据标准,目前已经正在使用的有超过 48,162 种报文格式定义和超过 12,183 个 .proto 文件。他们用于 RPC 系统和持续数据存储系统。

Protocol Buffers 是一种轻便高效的结构化数据存储格式,可以用于结构化数据串行化,或者说序列化。它很适合做数据存储或 RPC 数据交换格式。可用于通讯协议、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式。目前提供了 C++、Java、Python 三种语言的 API。

或许您和我一样,在第一次看完这些介绍后还是不明白 Protobuf 究竟是什么,那么我想一个简单的例子应该比较有助于理解它。

 

一个简单的例子

 

安装 Google Protocol Buffer

 

在网站 http://code.google.com/p/protobuf/downloads/list上可以下载 Protobuf 的源代码。然后解压编译安装便可以使用它了。

安装步骤如下所示:

 tar -xzf protobuf-2.1.0.tar.gz
 cd protobuf-2.1.0
 ./configure --prefix=$INSTALL_DIR
 make
 make check
 make install

关于简单例子的描述

 

我打算使用 Protobuf 和 C++ 开发一个十分简单的例子程序。

该程序由两部分组成。第一部分被称为 Writer,第二部分叫做 Reader。

Writer 负责将一些结构化的数据写入一个磁盘文件,Reader 则负责从该磁盘文件中读取结构化数据并打印到屏幕上。

准备用于演示的结构化数据是 HelloWorld,它包含两个基本数据:

  • ID,为一个整数类型的数据
  • Str,这是一个字符串

书写 .proto 文件

 

首先我们需要编写一个 proto 文件,定义我们程序中需要处理的结构化数据,在 protobuf 的术语中,结构化数据被称为 Message。proto 文件非常类似 java 或者 C 语言的数据定义。代码清单 1 显示了例子应用中的 proto 文件内容。

清单 1. proto 文件
 package lm;
 message helloworld
 {
    required int32     id = 1;  // ID
    required string    str = 2;  // str
    optional int32     opt = 3;  //optional field
 }

一个比较好的习惯是认真对待 proto 文件的文件名。比如将命名规则定于如下:

 packageName.MessageName.proto

在上例中,package 名字叫做 lm,定义了一个消息 helloworld,该消息有三个成员,类型为 int32 的 id,另一个为类型为 string 的成员 str。opt 是一个可选的成员,即消息中可以不包含该成员。

 

编译 .proto 文件

 

写好 proto 文件之后就可以用 Protobuf 编译器将该文件编译成目标语言了。本例中我们将使用 C++。

假设您的 proto 文件存放在 $SRC_DIR 下面,您也想把生成的文件放在同一个目录下,则可以使用如下命令:

 protoc -I=$SRC_DIR --cpp_out=$DST_DIR $SRC_DIR/addressbook.proto

命令将生成两个文件:

lm.helloworld.pb.h , 定义了 C++ 类的头文件

lm.helloworld.pb.cc , C++ 类的实现文件

在生成的头文件中,定义了一个 C++ 类 helloworld,后面的 Writer 和 Reader 将使用这个类来对消息进行操作。诸如对消息的成员进行赋值,将消息序列化等等都有相应的方法。

 

编写 writer 和 Reader

 

如前所述,Writer 将把一个结构化数据写入磁盘,以便其他人来读取。假如我们不使用 Protobuf,其实也有许多的选择。一个可能的方法是将数据转换为字符串,然后将字符串写入磁盘。转换为字符串的方法可以使用 sprintf(),这非常简单。数字 123 可以变成字符串”123”。

这样做似乎没有什么不妥,但是仔细考虑一下就会发现,这样的做法对写 Reader 的那个人的要求比较高,Reader 的作者必须了 Writer 的细节。比如”123”可以是单个数字 123,但也可以是三个数字 1,2 和 3,等等。这么说来,我们还必须让 Writer 定义一种分隔符一样的字符,以便 Reader 可以正确读取。但分隔符也许还会引起其他的什么问题。最后我们发现一个简单的 Helloworld 也需要写许多处理消息格式的代码。

如果使用 Protobuf,那么这些细节就可以不需要应用程序来考虑了。

使用 Protobuf,Writer 的工作很简单,需要处理的结构化数据由 .proto 文件描述,经过上一节中的编译过程后,该数据化结构对应了一个 C++ 的类,并定义在 lm.helloworld.pb.h 中。对于本例,类名为 lm::helloworld。

Writer 需要 include 该头文件,然后便可以使用这个类了。

现在,在 Writer 代码中,将要存入磁盘的结构化数据由一个 lm::helloworld 类的对象表示,它提供了一系列的 get/set 函数用来修改和读取结构化数据中的数据成员,或者叫 field。

当我们需要将该结构化数据保存到磁盘上时,类 lm::helloworld 已经提供相应的方法来把一个复杂的数据变成一个字节序列,我们可以将这个字节序列写入磁盘。

对于想要读取这个数据的程序来说,也只需要使用类 lm::helloworld 的相应反序列化方法来将这个字节序列重新转换会结构化数据。这同我们开始时那个“123”的想法类似,不过 Protobuf 想的远远比我们那个粗糙的字符串转换要全面,因此,我们不如放心将这类事情交给 Protobuf 吧。

程序清单 2 演示了 Writer 的主要代码,您一定会觉得很简单吧? Continue reading “Google Protocol Buffer 的使用和原理”

windows系统编译phpredis客户端,64位版本

windows系统编译phpredis客户端,64位版本-rendong

 

windows php_redis 64位版本  windows phpredis 64位版本

 

由于公司统一用win7系统,32位apache+php老是崩溃,实在受不了了,搜索安装了wamp64位版本

官网:http://www.wampserver.com/en/

下载地址:http://sourceforge.net/projects/wampserver/files/WampServer%202/WampServer%202.2/wampserver2.2d-x64.exe/download

各个版本:Apache 2.2.21  Php 5.3.10  Mysql 5.5.20  XDebug  2.1.2  XDC 1.5  PhpMyadmin 3.4.10.1  SQLBuddy 1.3.3  webGrind 1.0

Continue reading “windows系统编译phpredis客户端,64位版本”