WEB·攻城志

Post/Redirect/Get 简称PRG，是一种用来防止表单重复提交数据的一种Web设计模式，典型的重复提交form内容的情况像用户刷新提交响应页面等可通过PRG模式来得到避免。

当一个表单通过HTTP POST被请求提交的时候，用户在服务器端返回响应期间如果刷新了响应页面，将会导致原始HTTP POST过来的内容重复提交，可能会导致一些不可预期的结果，比如重复提交数据。

阅读全文…

一、Nginx安装

安装Nginx可以采用YUM方法，Nginx官方提供的源可以保证安装最新版本的稳定程序

vim /etc/yum.repos.d/CentOS-Base.repo 添加以下YUM源信息

[nginx]

name=nginx repo

baseurl=http://nginx.org/packages/centos/$releasever/$basearch/

gpgcheck=0

enabled=1

更新YUM缓存

yum makecache

安装Nginx

yum install nginx

控制Nginx运行：

通过YUM安装完毕Nginx后可以使用service命令管理，目前支持以下参数

service nginx {start|stop|restart|condrestart|try-restart|force-reload|upgrade|reload|status|help|configtest} 阅读全文…

因为是程序员出身，平时虽然经常接触服务器，偶尔也会要装一些软件、配置优化什么的，可能还是个人习惯问题，一般情况下我还是以手工编译居多(这其中的优缺点就不在这里啰嗦了)。这几天有同事提出YUM其实更便于日常管理维护，确实，相对于手工编译，服务器多的时候YUM确实要方便不少。今天整理了一下YUM相关的背景知识，东西还不够详细，后续会逐步完善。

YUM简单介绍

YUM，是Yellow dog Updater, Modified的简称，具体念什么？既然是首字母缩写念Y-U-M应该没错吧，（有时候也听人叫晕，那就晕吧:).起初是由yellow dog这一发行版的开发者Terra Soft研发，用python写成，那时还叫做yup(yellow dog updater)，后经杜克大学的Linux@Duke开 发团队进行改进，遂有此名。

YUM的宗旨是自动化地升级，安装/移除rpm包，收集rpm包的相关信息，检查依赖性并自动提示用户解决。YUM的关键之处 是要有可靠的repository，顾名思义，这是软件的仓库，它可以是http或ftp站点，也可以是本地软件池，但必须包含rpm的header， header包括了rpm包的各种信息，包括描述，功能，提供的文件，依赖性等.正是收集了这些 header并加以分析，才能自动化地完成余下的任务。

YUM的特点：

• 可以同时配置多个资源库(Repository)
• 简洁的配置文件(/etc/yum.conf)
• 自动解决增加或删除rpm包时遇到的倚赖性问题
• 使用方便
• 保持与RPM数据库的一致性

阅读全文…

最近刚刚把博客转移到WordPress上了，博客托管在百度Hi上面确实不是长久之际，长期被鸡肋的功能和诸多限制折磨摧残，实在是不堪回首。

工具采用PHP编写，运行在CLI模式下。本人在XP下php5.29下运行测试通过。程序生成SQL文件，直接在MySQL管理工具(PHPMyAdmin、Navicat等)下执行SQL文件。

工具采用BSD协议授权，因为本人是开源新手，确实还有很多东西没有弄清楚，发布这个工具形式意义大于实际作用，寄此以自勉，希望以后能有更多更成熟的东西在开源社区分享。

博客上面写的东西不多，主要以转载为主，这2年下来也有100多往篇，百度Hi不带博客导出功能，Google了N久也没找到个满意的方案，遂动手写了一个，功能是简单了点，比较适合有一定编程基础的人使用.

软件名称：Baidu-hi2WordPress 1.0
软件作者：clear – 直来直往
授权方式：BSD
发布日期：2011.12.29
运行环境：WinXP/Linux
托管地址：https://github.com/aboustudy/baidu-hi2wordpress

当前只支持博客内容以及图片本地化，将来考虑评论导出功能，敬请期待。

使用过程中需要帮助请联系我 

先了解一下几个关于开源协议的基本常识

开源≠免费

开源世界有个很重要的容易被误解的地方就是“开源即免费”，并不是这样的，开源不等于免费，GPL的倡导组织自由软件组织也一再强调过“free不是免费，free是指自由”。由于大多数开源软件都是免费的，所以容易造成这种误解。

Contributors 和 Recipients

Contributors 指的是对某个开源软件或项目提供了代码(包括最初的或者修改过的)发布的人或者实体(团队、公司、组织等),Contributors 按照参与某个软件开源的时间先后,可以分为 an initial Contributor 和 subsequent Contributors .

Recipients指的是开源软件或项目的获取者,显然,subsequent Contributors 也属于 Recipients之列.

Source Code 和 Object Code

Source Code 指的是各种语言写成的源代码,通过Source Code,结合文档, 可以了解到整个软件的体系结构及具体到某个功能函数的实现方法等.

Object Code 指的是Source Code 经过编译之后,生成的类似于“类库”一样的,提供各种接口供他人使用的目标码,按我的理解,它就是像常见的DLL、ActiveX、OCX控件性质的东西.(不知道这样理解对不对)

分清楚这两个概念的目的在于,有些开源,只发布Object Code ,当然,大多数发布的是Source Code.很多协议也对 “你发布的是哪种Code的时候应该怎样”,有着明确的约束.

Derivative Module 和 Separate Module

Derivative Module 指的是,依托或包含“最初的”或者“从别人处获取的”开源代码而产生的代码,是原“源代码”的增强(不等于增加)、改善和延续的模块,意为“衍生模块”.

Separate Module 指的是,参考或借助原“源代码”,开发出的独立的,不包含、不依赖于原“源代码模块”,意为“独立的模块”.理解这两个概念的目的在于,很多协议对涉及到商业发布的时候,会有哪些是衍生的,哪些是独立的,有着明确的商业发布规定.

专有软件：需要购买，然后才能使用，且只能使用该软件而不能作其他用途。如修改、分享、再发布等。

共享软件：基本上就是专有软件，但你能在实际购买前试用。

免费软件：你可以自由的分享和使用该软件，但你无法修改该软件，因为该软件的源代码不是公开的。

开源软件/自由软件：你能够自由分享该软件与其源代码、使用该软件并可随意修改该软件源码 – 这给予了你最大的自主权。 阅读全文…

        Sysctl命令用来配置与显示在/proc/sys目录中的内核参数．proc下的内核参数文件为内存映射，虚拟文件，实际中不存在，不能使用编辑器进行编辑。如果想使参数长期保存，可以通过编辑/etc/sysctl.conf文件来实现。

命令格式及参数：

-p从指定的文件加载系统参数,默认从/etc/sysctl.conf 文件中加载，如：

看了原文觉得挺实用的，确实对于DB新农来讲，用系统默认配置或者MySQL自带的几个配置模板比较多，顶多会去调几个参数。这编博客列出的点如作者所述，“MySQL可调的参数确实不少，不过真正对系统性能有非常显著的影响就那么几个”。

key_buffer_size
innodb_buffer_pool_size
innodb_additional_mem_pool_size
innodb_log_file_size
innodb_log_buffer_size
innodb_flush_log_at_trx_commit
table_cache
thread_cache
query_cache_size

阅读全文…

Linux有很多很好的内存、IO调度机制，但是并不会适用于所有场景。对于DBA来说Linux比较让人头疼的一个地方是，它不会因为MySQL很重要就避免将分配给MySQL的地址空间映射到swap上。对于频繁进行读写操作的系统而言，数据看似在内存而实际上在磁盘是非常糟糕的，响应时间的增长很可能直接拖垮整个系统。这篇blog主要讲讲我们作为DBA，怎样尽量避免MySQL惨遭swap的毒手。

首先我们要了解点基础的东西，比如说为什么会产生swap。假设我们的物理内存是16G，swap是4G。如果MySQL本身已经占用了12G物理内存，而同时其他程序或者系统模块又需要6G内存，这时候操作系统就可能把MySQL所拥有的一部分地址空间映射到swap上去。

cp一个大文件，或用mysqldump导出一个很大的数据库的时候，文件系统往往会向Linux申请大量的内存作为cache，一不小心就会导致L使用swap。这个情景比较常见，以下是最简单的三个调整方法：
1、/proc/sys/vm/swappiness的内容改成0（临时），/etc/sysctl.conf上添加vm.swappiness=0（永久）
这个参数决定了Linux是倾向于使用swap，还是倾向于释放文件系统cache。在内存紧张的情况下，数值越低越倾向于释放文件系统cache。
当然，这个参数只能减少使用swap的概率，并不能避免Linux使用swap。
2、修改MySQL的配置参数innodb_flush_method，开启O_DIRECT模式。
这种情况下，InnoDB的buffer pool会直接绕过文件系统cache来访问磁盘，但是redo log依旧会使用文件系统cache。值得注意的是，Redo log是覆写模式的，即使使用了文件系统的cache，也不会占用太多。
3、添加MySQL的配置参数memlock
这个参数会强迫mysqld进程的地址空间一直被锁定在物理内存上，对于os来说是非常霸道的一个要求。必须要用root帐号来启动MySQL才能生效。

还有一个比较复杂的方法，指定MySQL使用大页内存（Large Page）。Linux上的大页内存是不会被换出物理内存的，和memlock有异曲同工之妙。
具体的配置方法可以参考：http://harrison-fisk.blogspot.com/2009/01/enabling-innodb-large-pages-on-linux.html

这里需要补充一下上面4种方法原理和实现机制，对于Linux api不感兴趣的同学可以直接跳过。

一、操作系统设置swap的目的
程序运行的一个必要条件就是足够的内存，而内存往往是系统里面比较紧张的一种资源。为了满足更多程序的要求，操作系统虚拟了一部分内存地址，并将之映射到swap上。对于程序来说，它只知道操作系统给自己分配了内存地址，但并不清楚这些内存地址到底映射到物理内存还是swap。
物理内存和swap在功能上是一样的，只是因为物理存储元件的不同（内存和磁盘），性能上有很大的差别。操作系统会根据程序使用内存的特点进行换入和换出，尽可能地把物理内存留给最需要它的程序。但是这种调度是按照预先设定的某种规则的，并不能完全符合程序的需要。一些特殊的程序（比如MySQL）希望自己的数据永远寄存在物理内存里，以便提供更高的性能。于是操作系统就设置了几个api，以便为调用者提供“特殊服务”。

二、Linux提供的几个api
1、mlockall()和munlockall()
这一对函数，可以让调用者的地址空间常驻物理内存，也可以在需要的时候将此特权取消。mlockall()的flag位可以是MCL_CURRENT和MCL_FUTURE的任意组合，分别代表了“保持已分配的地址空间常驻物理内存”和“保持未来分配的地址空间常驻物理内存”。对于Linux来说，这对函数是非常霸道的，只有root用户才有权限调用。

2、shmget()和shmat()
这一对函数，可以向操作系统申请使用大页内存（Large Page）。大页内存的特点是预分配和永驻物理内存，因为使用了共享内存段的方式，page table有可能会比传统的小页分配方式更小。对于多进程共享内存的程序（比如ORACLE），大页内存能够节省很多page table开销；而对于MySQL来说，性能和资源开销都没有显著变化，好处就在于减少了内存地址被映射到swap上的可能。至于为什么是减少，而不是完全避免，之后再讲解。

3、O_DIRECT和posix_memalign()
以上两个方法都不会减少内存的使用量，调用者的本意是获取更高的系统特权，而不是节约系统资源。O_DIRECT是一种更加理想化的方式，通过避免double buffer，节省了文件系统cache的开销，最终减少swap的使用率。O_DIRECT是Linux IO调度相关的标志，在open函数里面调用。通过O_DIRECT标志打开的文件，读写都不会用到文件系统的cache。传统的数据库（ORACLE、MySQL）基本都有O_DIRECT相关的开关，在提高性能的同时，也减少了内存的使用。至于posix_memalign()，是用来申请对齐的内存地址的。只有用posix_memalign()申请的内存地址，才能用来读写O_DIRECT模式下的文件描述符。

4、madvise()和fadvise()
这对函数也是比较温和的，可以将调用者对数据访问模式的预期传递给Linux，以期得到更好的性能。
我们比较感兴趣的是MADV_DONTNEED和FADV_NOREUSE这两个flag。前者会建议Linux释放指定的内存区域，而后者会建议文件系统释放指定文件所占用的cache。

三、MySQL内存使用相关的一些代码
1、memlock
在MySQL的源码目录里面查询memlock，可以知道这个参数的作用是使MySQL调用mlockall()。在源码里面匹配可以得知NDB、MyISAM和mysqld都调用了mlockall()。NDB是可以独立于MySQL而存在的存储引擎，此处按下不表。mysqld调用mlockall()的方式有点出乎意料，在init_server_components()函数里传给mlockall()的flag是MCL_CURRENT，也就是说之后申请的内存一概不用锁住。再看看MyISAM的调用顺序是：mlockall() <- lock_memory() <- mi_repair()，MyISAM只有修复的时候会调用mlockall()函数。

2、large-pages
根据Linux的内核文档，大页内存有两种方法可以用到：一种是创建hugetlb类型的文件，并将它mmap到程序的内存地址里面，然后进行正常的读写操作。另外一种是之前说到的shmget()+shmat()，也正是MySQL采用的方式。在MySQL的源码目录里面匹配shmget，可以发现BDB、NDB、InnoDB、MyISAM都调用了这个函数。接着看一下比较常用的InnoDB和MyISAM引擎。
在InnoDB里面可以找到os_mem_alloc_large()调用了shmget()，而调用os_mem_alloc_large()的函数只有buf_pool_init()――InnoDB Buffer Pool的初始化函数。根据观察得到的结论是，InnoDB会根据配置参数在Buffer Pool里面使用大页内存，Redo log貌似就没有这个待遇了。
对于MyISAM，在storage层级的代码里面找不到对shmget()的直接调用。这是因为MyISAM是MySQL的原生存储引擎，很多函数存放在上一层的mysys目录里面。通过搜索shmget()，我们可以找到MyISAM的调用顺序是这样的：shmget() <- my_large_malloc_int() <- my_large_malloc() <- init_key_cache()。也就是说MyISAM只有索引缓存用到了大页内存，这是很容易理解，因为MyISAM的数据是直接扔给文件系统做缓存的，没法使用大页内存。

3、innodb_flush_method
O_DIRECT是BDB、NDB、InnoDB特有的参数，在这里只讨论InnoDB这个比较常见的引擎。在InnoDB的源码目录里面匹配O_DIRECT，很容易找到一个叫做os_file_set_nocache()的函数，而这个函数作用是将文件的打开方式改为O_DIRECT模式。再跟踪一下，会发现只有os_file_create()函数调用了os_file_set_nocache()。虽然函数名里面还有create，实际上os_file_create()会根据传入参数的不同，选择打开或者新建一个文件。同时os_file_create()还会根据MySQL的配置，来调用os_file_set_nocache()关闭文件系统的相应cache。在os_file_create()函数里面有如下一段代码：
/* We disable OS caching (O_DIRECT) only on data files */
if (type != OS_LOG_FILE &&
srv_unix_file_flush_method == SRV_UNIX_O_DIRECT)
{
os_file_set_nocache(file, name, mode_str);
}
这段代码的意思是，只有InnoDB的数据文件有资格使用O_DIRECT模式，Redo log是不能使用的。

以上的分析基于5.0.85版本的原版MySQL，InnoDB是Innobase。
版本不同情况下可能会有一些出入，欢迎参与讨论。

参考文献：
Virtual memory@wiki
All about Linux swap space
HugeTLB C Large Page Support in the Linux Kernel
Page table@wiki
原文 http://www.taobaodba.com/html/552_mysql_avoid_swap.html

MySQL的Query Cache系统变量都是以“query_cache“作为前后缀的，它们分别是：

have_query_cache
query_cache_limit
query_cache_min_res_unit
query_cache_size
query_cache_type
query_cache_wlock_invalidate

其中”have_query_cache“变量标识是QueryCache是否可用。可通过以下命令查看：

通常这个变量值为YES，即使QueryCache功能不可用的时候：当“query_cache_size”的值为0的时候，即使”have_query_cache=YES”,QueryCache也不可用。

标准版MySQL中“query_cache_size”为0，也即，默认配置下QueryCache是不可用的。

我们可以通过配置文件、启动参数和命令设置相关参数。如通过”SET”命令设置“query_cache_size”:

全局设置：mysql> SET GLOBAL query_cache_size = 1048576;
会话设置：mysql> SET SESSION query_cache_size = 1048576;

      如果你使用的时候标准 MySQL 分发版的话，Query Cache 功能默认都是打开的，我们可以通过调整 MySQL Server 的参数选项打开该功能。它们主要由以下5个参数构成：

• query_cache_limit：允许 Cache 的单条 Query 结果集的最大容量，默认是1MB，超过此参数设置的 Query 结果集将不会被 Cache
• query_cache_min_res_unit：设置 Query Cache 中每次分配内存的最小空间大小，也就是每个 Query 的 Cache 最小占用的内存空间大小
• query_cache_size：设置 Query Cache 所使用的内存大小，默认值为0，大小必须是1024的整数倍，如果不是整数倍，MySQL 会自动调整降低最小量以达到1024的倍数。
  query_cache_size最小值不能小于40KB，否则系统将会产生一个WARNING:Query cache failed to set size 39936;new query cache size is 0.
• query_cache_type：控制 Query Cache 功能的开关，可以设置为0(OFF),1(ON)和2(DEMAND)三种，意义分别如下：
  • 0(OFF)：关闭 Query Cache 功能，任何情况下都不会使用 Query Cache
  • 1(ON)：开启 Query Cache 功能，但是当 SELECT 语句中使用的 SQL_NO_CACHE 提示后，将不使用Query Cache
  • 2(DEMAND)：开启 Query Cache 功能，但是只有当 SELECT 语句中使用了 SQL_CACHE 提示后，才使用 Query Cache
• query_cache_wlock_invalidate：控制当有写锁定发生在表上的时刻是否先失效该表相关的 Query Cache，如果设置为 1(TRUE)，则在写锁定的同时将失效该表相关的所有 Query Cache，如果设置为0(FALSE)则在锁定时刻仍然允许读取该表相关的 Query Cache。

现在网站发展的趋势对网络负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术：

一种是通过硬件来进行进行，常见的硬件有比较昂贵的NetScaler、F5、Radware和Array等商用的负载均衡器，它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，所以对于规模较小的网络服务来说暂时还没有需要使用；另外一种就是类似于LVS/HAProxy、Nginx的基于Linux的开源免费的负载均衡软件策略,这些都是通过软件级别来实现，所以费用非常低廉，所以我个也比较推荐大家采用第二种方案来实施自己网站的负载均衡需求。

近期朋友的项目成功上线了，PV达到了亿级/日的访问量，最前端用的是HAProxy+Keepalived双机作的负载均衡器/反向代理，整个网站非常稳定；这让我更坚定了以前跟老男孩前辈聊的关于网站架构比较合理设计的架构方案：即Nginx/HAProxy+Keepalived作Web最前端的负载均衡器，后端的MySQL数据库架构采用一主多从，读写分离的方式，采用LVS+Keepalived的方式。

在这里我也有一点要跟大家申明下：很多朋友担心软件级别的负载均衡在高并发流量冲击下的稳定情况，事实是我们通过成功上线的许多网站发现，它们的稳定性也是非常好的，宕机的可能性微乎其微，所以我现在做的项目，基本上没考虑服务级别的高可用了。相信大家对这些软件级别的负载均衡软件都已经有了很深的的认识，下面我就它们的特点和适用场合分别说明下。

LVS：使用集群技术和Linux操作系统实现一个高性能、高可用的服务器，它具有很好的可伸缩性（Scalability)、可靠性（Reliability)和可管理性（Manageability)，感谢章文嵩博士为我们提供如此强大实用的开源软件。

LVS的特点是：

1. 抗负载能力强、是工作在网络4层之上仅作分发之用，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的；
2. 配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率；
3. 工作稳定，自身有完整的双机热备方案，如LVS+Keepalived和LVS+Heartbeat，不过我们在项目实施中用得最多的还是LVS/DR+Keepalived；
4. 无流量，保证了均衡器IO的性能不会收到大流量的影响；
5. 应用范围比较广，可以对所有应用做负载均衡；
6. 软件本身不支持正则处理，不能做动静分离，这个就比较遗憾了；其实现在许多网站在这方面都有较强的需求，这个是Nginx/HAProxy+Keepalived的优势所在。
7. 如果是网站应用比较庞大的话，实施LVS/DR+Keepalived起来就比较复杂了，特别后面有Windows Server应用的机器的话，如果实施及配置还有维护过程就比较复杂了，相对而言，Nginx/HAProxy+Keepalived就简单多了。

Nginx的特点是：

1. 工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构，它的正则规则比HAProxy更为强大和灵活，这也是许多朋友喜欢它的原因之一；
2. Nginx对网络的依赖非常小，理论上能ping通就就能进行负载功能，这个也是它的优势所在；
3. Nginx安装和配置比较简单，测试起来比较方便；
4. 也可以承担高的负载压力且稳定，一般能支撑超过几万次的并发量；
5. Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测；
6. Nginx仅能支持http和Email，这样就在适用范围上面小很多，这个它的弱势；
7. Nginx不仅仅是一款优秀的负载均衡器/反向代理软件，它同时也是功能强大的Web应用服务器。LNMP现在也是非常流行的web架构，大有和以前最流行的LAMP架构分庭抗争之势，在高流量的环境中也有很好的效果。
8. Nginx现在作为Web反向加速缓存越来越成熟了，很多朋友都已在生产环境下投入生产了，而且反映效果不错，速度比传统的Squid服务器更快，有兴趣的朋友可以考虑用其作为反向代理加速器。

HAProxy的特点是：

1. HAProxy是支持虚拟主机的，以前有朋友说这个不支持虚拟主机，我这里特此更正一下。
2. 能够补充Nginx的一些缺点比如Session的保持，Cookie的引导等工作
3. 支持url检测后端的服务器出问题的检测会有很好的帮助。
4. 它跟LVS一样，本身仅仅就只是一款负载均衡软件；单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的。
5. HAProxy可以对Mysql读进行负载均衡，对后端的MySQL节点进行检测和负载均衡，不过在后端的MySQL slaves数量超过10台时性能不如LVS，所以我向大家推荐LVS+Keepalived。
6. HAProxy的算法现在也越来越多了，具体有如下8种：
   ① roundrobin，表示简单的轮询，这个不多说，这个是负载均衡基本都具备的；
   ② static-rr，表示根据权重，建议关注；
   ③ leastconn，表示最少连接者先处理，建议关注；
   ④ source，表示根据请求源IP，这个跟Nginx的IP_hash机制类似，我们用其作为解决session问题的一种方法，建议关注；
   ⑤ ri，表示根据请求的URI；
   ⑥ rl_param，表示根据请求的URl参数’balance url_param’ requires an URL parameter name；
   ⑦ hdr(name)，表示根据HTTP请求头来锁定每一次HTTP请求；
   ⑧ rdp-cookie(name)，表示根据据cookie(name)来锁定并哈希每一次TCP请求。