redis持久化存储之RDB VS AOF

RDB 优点:

1.RDB是一种表示某个即时点的 Redis 数据的紧凑文件。RDB 文件适合用于备份。例如,你可能想要每小时归档最近 24 小时的 RDB 文件,每天保存近 30 天的 RDB 快照。这允许你很容易的恢复不同版本的数据集以容灾。

2.RDB非常适合于灾难恢复,作为一个紧凑的单一文件,可以被传输到远程的数据中心,或者是 Amazon S3(可能得加密)。

3.RDB最大化了 Redis 的性能,因为 Redis 父进程持久化时唯一需要做的是启动(fork)一个子进程,由子进程完成所有剩余工作。父进程实例不需要执行像磁盘 IO 这样的操作。

4.RDB 在重启恢复大数据集的实例时比AOF要快。

RDB缺点:

1.当你需要在 Redis 停止工作(例如停电)时最小化数据丢失,RDB 可能不太好。你可以配置不同的保存点。然而,你通常每隔 5 分钟或更久创建一个 RDB 快照,所以一旦 Redis 因为任何原因没有正确关闭而停止工作,你就得做好最近几分钟数据丢失的准备了。

2.RDB 需要经常调用 fork()子进程来持久化到磁盘。如果数据集很大的话,fork()比较耗时,结果就是,当数据集非常大并且 CPU 性能不够强大的话,Redis 会停止服务客户端几毫秒甚至一秒。AOF 也需要 fork(),但是你可以调整多久频率重写日志而不会有损(trade-off)持久性(durability)。

AOF优点:

1.使用 AOF Redis 会更具有可持久性(durable):你可以有很多不同的 fsync 策略:没有 fsync,每秒 fsync,每次请求时 fsync。使用默认的每秒 fsync 策略,写性能也仍然很不错(fsync 是由后台线程完成的,主线程继续努力地执行写请求),即便你也就仅仅只损失一秒钟的写数据。

2.AOF日志是一个追加文件,所以不需要定位,在断电时也没有损坏问题。即使由于某种原因文件末尾是一个写到一半的命令(磁盘满或者其他原因),redis-check-aof 工具也可以很轻易的修复。

3.AOF文件里面包含一个接一个的操作,以易于理解和解析的格式存储。你也可以轻易的导出一个 AOF 文件。例如,即使你不小心错误地使用 FLUSHALL 命令清空一切,如果此时并没有执行重写,你仍然可以保存你的数据集,你只要停止服务器,删除最后一条命令,然后重启 Redis 就可以。

AOF缺点:

1.对同样的数据集,AOF 文件通常要大于等价的 RDB 文件。

2.AOF可能比RDB慢,这取决于准确的 fsync 策略。在处理巨大的写入载入时,RDB 可以提供更有保证的最大延迟时间(latency)

RDB和AOF如何取舍

通常来说,你应该同时使用这两种持久化方法,以提高数据安全程度。

如果你很关注你的数据,但是仍然可以接受灾难时有几分钟的数据丢失,你可以只单独使用 RDB。

有很多用户单独使用 AOF,但是我们并不鼓励这样,因为时常进行 RDB 快照非常方便于数据库备份,启动速度也较之快,还避免了 AOF 引擎的 bug。

laravel中建表为何要用migration来操作数据库?

可以将Migration看作一个数据库版本的管理工具,就如git对项目文件的版本管理,可以rollback,reset等(通过php artisan命令查看具体命令)
所以其实用Migration建表跟直接手动创建表是一样的,不同在于使用Migration有额外的管理数据库的功能:回滚/重置/更新等。当然你也可以完全不用这个工具,用phpmyadmin方式来建表,并没有什么不妥。

为什么Nginx的性能要比Apache高很多?

这得益于Nginx使用了最新的epoll(Linux 2.6内核)网络I/O模型,而Apache则使用的是传统的select模型。

目前Linux下能够承受高并发访问的Squid、Memcached都采用的是epoll网络I/O模型。

处理大量的连接的读写,Apache所采用的select网络I/O模型非常低效。

下面用一个比喻来解析Apache采用的select模型和Nginx采用的epoll模型进行之间的区别:

假设你在大学读书,住的宿舍楼有很多间房间,你的朋友要来找你。

select版宿管大妈就会带着你的朋友挨个房间去找,直到找到你为止。

而epoll版宿管大妈会先记下每位同学的房间号,

你的朋友来时,只需告诉你的朋友你住在哪个房间即可,不用亲自带着你的朋友满大楼找人。

如果来了10000个人,都要找自己住这栋楼的同学时,select版和epoll版宿管大妈,谁的效率更高,不言自明。

同理,在高并发服务器中,轮询I/O是最耗时间的操作之一,select和epoll的性能谁的性能更高,同样十分明了。

$_SERVER[‘PHP_SELF’]、$_SERVER[‘SCRIPT_NAME’] 与 $_SERVER[‘REQUEST_URI’] 之间的区别

$_SERVER[‘PHP_SELF’]、$_SERVER[‘SCRIPT_NAME’] 与 $_SERVER[‘REQUEST_URI’] 三者非常相似,返回的都是与当前 URL 或 PHP 程序文件相关的信息:

  1. $_SERVER[‘PHP_SELF’]:相对于网站根目录的路径及 PHP 程序名称。
  2. $_SERVER[‘SCRIPT_NAME’]:相对于网站根目录的路径及 PHP 程序文件名称。
  3. $_SERVER[‘REQUEST_URI’]:访问此页面所需的 URI 。

一个简单的例子可以看出它们的区别。URL 地址如下:

http://www.5idev.com/php/index.php/test/foo?username=hbolive
  • $_SERVER[‘PHP_SELF’] 得到:/php/index.php/test/foo
  • $_SERVER[‘SCRIPT_NAME’] 得到:/php/index.php
  • $_SERVER[‘REQUEST_URI’] 得到:/php/index.php/test/foo?username=hbolive

从该例子可以看出:

  1. $_SERVER[‘PHP_SELF’] 则反映的是 PHP 程序本身;
  2. $_SERVER[‘SCRIPT_NAME’] 反映的是程序文件本身(这在页面需要指向自己时非常有用);
  3. $_SERVER[‘REQUEST_URI’] 则反映了完整 URL 地址(不包括主机名)。

其实从各自的命名上,也可以体现出它们之间的细微差别。

特别的,对于如下地址:

http://www.5idev.com/
  • $_SERVER[‘PHP_SELF’] 得到:/index.php
  • $_SERVER[‘SCRIPT_NAME’] 得到:/index.php
  • $_SERVER[‘REQUEST_URI’] 得到:/

至于有人提到 $_SERVER[‘PHP_SELF’] 与 $_SERVER[‘SCRIPT_NAME’] 在 PHP 以 CGI 模式运行下会有区别。由于 PHP 在 CGI 模式运行下并不多见,测试较为麻烦,在此就不再叙述了。如有这种情况,可注意并自行测试。

希望在理解了它们之间的区别之后,以便选择更适合自己程序的来使用。

memcache与memcached

Memcache是什么?

Memcache是一个自由和开放源代码、高性能、分配的内存对象缓存系统。用于加速动态web应用程序,减轻数据库负载。它可以应对任意多个连接,使用非阻塞的网络IO。由于它的工作机制是在内存中开辟一块空间,然后建立一个Hash表,Memcached自管理这些Hash表。

Memcached是简单而强大的。它简单的设计促进迅速部署,易于发展所面临的问题,解决了很多大型数据缓存。它的API可供最流行的语言。
Memcache官方网站:http://memcached.org/

Memcached又是什么?

Memcached是memcache的守护进程,随时接受客户端的连接操作。

Memcache客户端(php)

PHP有两个memcache客户端:php memcachephp memcached

php memcache独立用php实现,是老客户端,从我们实践中已发现有多个问题,而且功能少,属性也可设置的少;

http://pecl.php.net/package/memcache

php memcached是基于原生的c的libmemcached的扩展,更加完善,建议替换为php memcached。

http://pecl.php.net/package/memcached