sudo apt-get install build-essential gnustep gobjc gnustep-make libgnustep-base-dev gnustep-devel#import <stdio.h>;
int main( int argc, const char * argv[] ) {
printf("hello world\n");
return 0;
}gcc hello.m -o hellogcc `gnustep-config --objc-flags` -lgnustep-base hello.m -o hello./hello
/**
输出结果:
hello world
*/Mysql的复制（replication）是一个异步的复制，从一个Mysql instace（称之为Master）复制到另一个Mysql instance（称之Slave）。实现整个复制操作主要由三个进程完成的，其中两个进程在Slave（Sql进程和IO进程），另外一个进程在 Master（IO进程）上。
要实施复制，首先必须打开Master端的binary log（bin-log）功能，否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。
1)、Slave上面的IO进程连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；
2)、Master接收到来自Slave的IO进程的请求后，通过负责复制的IO进程根据请求信息读取指定日志指定位置之后的日志信息，返回给Slave 的IO进程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置；
3)、Slave的IO进程接收到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的最末端，并将读取到的Master端的 bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”；
4)、Slave的Sql进程检测到relay-log中新增加了内容后，会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容，并在自身执行。
实际上在老版本的Mysql的复制实现在Slave端并不是两个进程完成的，而是由一个进程完成。但是后来发现这样做存在较大的风险和性能问题，主要如下：
首先，一个进程就使复制bin-log日志和解析日志并在自身执行的过程成为一个串行的过程，性能受到了一定的限制，异步复制的延迟也会比较长。
另外，Slave端从Master端获取bin-log过来之后，需要接着解析日志内容，然后在自身执行。在这个过程中，Master端可能又产生了大量变化并声称了大量的日志。如果在这个阶段Master端的存储出现了无法修复的错误，那么在这个阶段所产生的所有变更都将永远无法找回。如果在Slave 端的压力比较大的时候，这个过程的时间可能会比较长。
所以，后面版本的Mysql为了解决这个风险并提高复制的性能，将Slave端的复制改为两个进程来完成。提出这个改进方案的人是Yahoo!的一位工程师“Jeremy Zawodny”。这样既解决了性能问题，又缩短了异步的延时时间，同时也减少了可能存在的数据丢失量。当然，即使是换成了现在这样两个线程处理以后，同样也还是存在slave数据延时以及数据丢失的可能性的，毕竟这个复制是异步的。只要数据的更改不是在一个事物中，这些问题都是会存在的。如果要完全避免这些问题，就只能用mysql的cluster来解决了。不过mysql的cluster是内存数据库的解决方案，需要将所有数据都load到内存中，这样就对内存的要求就非常大了，对于一般的应用来说可实施性不是太大。 2、复制实现级别
Mysql的复制可以是基于一条语句（Statement level），也可以是基于一条记录（Row level），可以在Mysql的配置参数中设定这个复制级别，不同复制级别的设置会影响到Master端的bin-log记录成不同的形式。
Row Level：日志中会记录成每一行数据被修改的形式，然后在slave端再对相同的数据进行修改。
优点：在row level模式下，bin-log中可以不记录执行的sql语句的上下文相关的信息，仅仅只需要记录那一条记录被修改了，修改成什么样了。所以row level的日志内容会非常清楚的记录下每一行数据修改的细节，非常容易理解。而且不会出现某些特定情况下的存储过程，或function，以及 trigger的调用和触发无法被正确复制的问题。
缺点：row level下，所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容，比如有这样一条update语句：update product set owner_member_id = ‘b’ where owner_member_id = ‘a’，执行之后，日志中记录的不是这条update语句所对应额事件（mysql以事件的形式来记录bin-log日志），而是这条语句所更新的每一条记录的变化情况，这样就记录成很多条记录被更新的很多个事件。自然，bin-log日志的量就会很大。尤其是当执行alter table之类的语句的时候，产生的日志量是惊人的。因为Mysql对于alter table之类的表结构变更语句的处理方式是整个表的每一条记录都需要变动，实际上就是重建了整个表。那么该表的每一条记录都会被记录到日志中。
Statement Level:每一条会修改数据的sql都会记录到 master的bin-log中。slave在复制的时候sql进程会解析成和原来master端执行过的相同的sql来再次执行。
优点：statement level下的优点首先就是解决了row level下的缺点，不需要记录每一行数据的变化，减少bin-log日志量，节约IO，提高性能。因为他只需要记录在Master上所执行的语句的细节，以及执行语句时候的上下文的信息。
缺点：由于他是记录的执行语句，所以，为了让这些语句在slave端也能正确执行，那么他还必须记录每条语句在执行的时候的一些相关信息，也就是上下文信息，以保证所有语句在slave端杯执行的时候能够得到和在master端执行时候相同的结果。另外就是，由于Mysql现在发展比较快，很多的新功能不断的加入，使mysql得复制遇到了不小的挑战，自然复制的时候涉及到越复杂的内容，bug也就越容易出现。在statement level下，目前已经发现的就有不少情况会造成mysql的复制出现问题，主要是修改数据的时候使用了某些特定的函数或者功能的时候会出现，比如：sleep()函数在有些版本中就不能真确复制，在存储过程中使用了last_insert_id()函数，可能会使slave和master上得到不一致的id等等。由于row level是基于每一行来记录的变化，所以不会出现类似的问题
从官方文档中看到，之前的Mysql一直都只有基于statement的复制模式，直到5.1.5版本的Mysql才开始支持row level的复制。从5.0开始，Mysql的复制已经解决了大量老版本中出现的无法正确复制的问题。但是由于存储过程的出现，给Mysql的复制又带来了更大的新挑战。另外，看到官方文档说，从5.1.8版本开始，Mysql提供了除Statement Level和Row Level之外的第三种复制模式：Mixed，实际上就是前两种模式的结合。在Mixed模式下，Mysql会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种。新版本中的Statment level还是和以前一样，仅仅记录执行的语句。而新版本的Mysql中队row level模式也被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录，如果sql语句确实就是update或者delete等修改数据的语句，那么还是会记录所有行的变更。 3、复制常用架构
Mysql复制环境90%以上都是一个Master带一个或者多个Slave的架构模式，主要用于读压力比较大的应用的数据库端廉价扩展解决方案。因为只要master和slave的压力不是太大（尤其是slave端压力）的话，异步复制的延时一般都很少很少。尤其是自slave端的复制方式改成两个进程处理之后，更是减小了slave端的延时。而带来的效益是，对于数据实时性要求不是特别的敏感度的应用，只需要通过廉价的pc server来扩展slave的数量，将读压力分散到多台slave的机器上面，即可解决数据库端的读压力瓶颈。这在很大程度上解决了目前很多中小型网站的数据库压力瓶颈问题，甚至有些大型网站也在使用类似方案解决数据库瓶颈。一个Master带多个slave的架构实施非常简单，多个slave和单个slave的实施并没有太大区别。在Master端并不care有多少个 slave连上了master端，只要有slave进程通过了连接认证，向他请求binlog信息，他就会按照连接上来的io进程的要求，读取自己的 binlog信息，返回给slave的IO进程。对于slave的配置细节，在Mysql的官方文档上面已经说的很清楚了，甚至介绍了多种实现slave 的配置方法。 Mysql不支持一个Slave instance从属于多个Master的架构。就是说，一个slave instance只能接受一个master的同步源，听说有patch可以改进这样的功能，但没有实践过。Mysql AB之所以不实现这样的功能，主要是考虑到冲突解决的问题。 Mysql也可以搭建成dual master模式，也就是说两个Mysql instance互为对方的Master，也同时为对方的Slave。不过一般这种架构也是只有一端提供服务，避免冲突问题。因为即使在两边执行的修改有先后顺序，由于复制的异步实现机制，同样会导致即使在晚做的修改也可能会被早做的修改所覆盖，就像如下情形： 时间点 Mysql A Mysql B 1 更新x表y记录为10 2 更新x表y记录为20 3 获取到A日志并应用，更新x表的y记录为10（不符合期望） 4 获取B日志更新x表y记录为20（符合期望） 这样，不仅在B库上面的数据不是用户所期望的结果，A和B两边的数据也出现了不一致的情况。除非能将写操作根据某种条件固定分开在A和B两端，保证不会交叉写入，才能够避免上面的问题。
过去当运行一个大的web应用时候意味着需要运行一个大型的web服务器。因为你的应用吸引了大量的用户，你将不得不在你的服务器里增加更多的内存和处理器。今天，“大型服务器”模式已经过去，取而代之的是大量的小服务器，使用各种各样的负载均衡技术。
“更多小服务器”的优势超过过去的“大型服务器”模式体现在两个方面：
1. 如果服务器宕机，那么负载均衡系统将停止请求到宕机的服务器，转而分发负载到其他正常运行的服务器上。
2. 扩展你的服务器更加容易。你要做的仅仅是加入新的服务器到负载均衡系统。不需要中断你的应用运行。
所以，把握住这个机会。当然，代价就是这要求你的应用开发时增加一点复杂度。这就是本文要覆盖的内容。
这时你可能对自己说:“但是我怎么知道我正在使用负载均衡呢？”。最诚实的回答是，如果你正在问这个问题，那么答案是你多半没有在使用负载均衡系统并且你的系统不需要考虑这个问题。大多数情况，当应用成长足够大的规模时，负载均衡就需要明确提出和设置了。然而，我也偶尔看见虚拟主机公司为客户的应用做这个负载均衡，或者像下面描述的那样要自己来做。
注意，我一直提“web应用”而不是website,这是想区分“web应用”是那些复杂的站点往往涉及服务器端编程和数据库，而不是website那样只显示简单的静态内容。
1. PHP文件
第一个问题是，如果你有大量的小型服务器，你怎么把你的php文件上传到所有的服务器上？有如下的方法供你参考：
◆分别上传所有的文件到每一个服务器 , 这种方法带来的问题是：想像一下你有20个服务器，那么上传过程中这将很容易导致错误，并且更新时极有可能导致不同服务器上有不同版本的文件。
◆使用 ‘rsync ‘ (或类似的软件) . 这样的工具能同步本地目录和多个远程主机目录上的文件。
◆使用版本控制软件(如subversion ) . 这是我最喜欢的方法。用它可以很好地维护我得代码，当发布我的应用时，可以在每一个服务器上运行svn update命令同步。这种方法也使切换服务器得代码到过去的某一个版本更加容易。
◆使用一个文件服务器(你可能发现NFS 非常适合做这件事情). 这种方式是使用一个文件服务器来存放你的web应用. 当然，如果你的文件服务器宕机，那么多所有你的站点将不能使用。这时，你就需要花费更多的开支来恢复它。
选择哪种方式依赖于你的需求和你掌握的技能。如果你使用版本控制系统，那么你可能得计划一个方法如果同时执行一个更新命令更新所有服务器上的代码。然而，如果使用文件服务器，你就要实现一些失败恢复机制，防止万一服务器宕机导致请求失败。
2. 文件上传
当只有一台服务器时，文件上传不是一个问题。但是当我们有多台服务器时，那么上传的文件应该怎么存放呢？上传文件的问题和跨服务器php文件存储是类似的。下面是几种可能的方案:
◆把文件存储到数据库中。大多数数据允许存储二进制数据。当你请求文件下载时，访问数据把二进制数据和相应的文件名和类型输出给用户。在使用这种方案前应该考虑数据库怎样存储你的文件。该方法的问题在于如果数据库服务器宕机将使文件不可用。
◆在一个文件服务器上存储上传的文件 . 与前面的介绍一样，你要安装一个文件服务器让所有web服务器共享，把所有上传的文件上传到这里，上传后所有的web服务器就都可以使用它。但是，如果文件服务器宕机，那么可能发生图像文件下载中断。
◆设计你自己的上传机制传输文件到服务器到每一个服务器 . 这个方法没有单个文件服务器或者数据库方案的缺陷，但是将增加你代码的复杂度。例如，如果上传到多个服务器过程中，服务器宕机，你要怎么处理？
用数据库存储上传文件但是设计一个文件缓存机制是一个不错的方案。当服务器接收一个文件下载请求时，首先检查缓存系统中是否有该文件，如果发现那么从缓存系统下载，否则从数据库读取并把它缓存到文件系统中。
3. 会话(Sessions)
如果你熟悉php的session 处理，你将可能知道默认情况下，它存储session数据在服务器的临时文件里。而且，这个文件仅仅在你请求处理的那个服务器上，但是接下来的请求可能被另外一个服务器处理，这将在另一个服务器上生成新的session。这导致session频繁地不被识别，如登录用户总是要求重新登录。
我推荐的方案是，要么重新php内建的session处理机制存储session数据到数据库，或者实现你自己的机制保证发送一个用户的请求到同一台服务器。
4. 配置(Configuration)
尽管这个话题不是和php特别相关，我感觉还是有必要提及。当运行集群服务器时，用某种方法保持服务器之间的配置文件同步是一个好主意。如果配置文件不一致，可能导致一些非常奇怪的断断续续的行为导致很难排查这些问题。
我推荐使用版本控制系统单独管理他们。这样你可以为不同的项目安装存储不同的php配置文件，也可以保持所有服务器配置文件同步。
5. 日志(Logging)
像配置问题一样，logging不是仅仅和php相关。但是对于保持服务器健康运行它仍然是非常重要的。没有正确的logging系统，你怎么知道如果PHP代码开始产生错误(在系统正式运行时，你总是关闭display_errors 设置，不是吗?)
有几种方法你可以实现logging：
1. 在每一个服务器上记录日志。 这是最简单的方法。每一个机器仅仅记录一个文件。好处是简单，可能只要很少的配置。但是，随着服务器数量的增多，监控每台服务器上的日志文件将变得非常困难。
2. 记录日志到一个共享 这种方法每一个服务器仍然有这个日志文件，但是他们通过共享机制被存储在一个中央文件服务器上，这将使监控日志变得更简单。该方案的问题在于，如果文件服务器不可用将导致一个简单的日志不能写入问题最终导致整个应用崩溃。
3. 记录日志到logging服务器 你可以使用一个logging软件，如syslog 来把所有的日志写到一个中央服务器。尽管这个方法要求更多的配置，但是他也提供了最健壮的方案。
PHP的运行原理
1、我们从未手动启动过PHP的相关进程, 它是随着Apache的启动而运行的。
2、PHP通过mod_php5.so模块和Apache相连(具体来说是SAPI，即服务器应用程序编程接口)。
3、PHP总共有三个模块:内核、Zend引擎、以及类扩展。
4、PHP内核用来处理请求、文件流、错误处理等相关操作。
5、Zend引擎（ZE）用以将源文件转换成机器语言，然后在虚拟机上运行它。
6、扩展层是一组函数、类库和流，PHP使用它们来执行一些特定的操作。比如，我们需要MySQL扩展来连接到MySQL据库。
7、当ZE执行程序时可能需要连接若干扩展，这时ZE将控制权交给扩展，等处理完特定任务后再返回。
8、最后ZE将程序运行结果返回给PHP内核，PHP内核再将结果传送给SAPI层，最终输出到浏览器上。
在这里我们再深入探讨一下：
1、Apache启动后, PHP解释程序也随之启动；
2、PHP的启动过程有两步；
第一步是初始化一些环境变量，这将在整个SAPI生命周期中发生作用；
此步操作在任何请求到达之前执行，启动Apache后，PHP解释程序也随之启动；PHP调用各个扩展的MINIT方法，从而使这些扩展切换到可用状态。MINIT的意思是“模块初始化”。
第二步是生成只针对当前请求的一些变量设置；
当一个页面请求发生时，SAPI层将控制权交给PHP层。于是PHP设置了用于回复本次请求所需的环境变量。同时，它建立一个变量表，用来存放执行过程中产生的变量名和值。PHP调用各个模块的RINIT方法，即“请求初始化”。一个经典的例子是Session模块的RINIT方法，如果在php.ini中启用了Session模块，那在调用该模块的RINIT方法就会初始化$_SESSION变量，并将相关内容读入。(RINIT方法可以看做一个准备过程，在程序执行期间就会自动启动。
3、PHP关闭关闭也分为两步：
第一步：一旦一个页面执行完毕(无论执行到文件末尾还是遇到exit或die函数终止), PHP就会启动清理程序。它会按照顺序调用各个模块的RSHUTDOWN方法。(RSHUTDOWN方法用以清楚程序运行时产生的符号表，也就是对每个变量调用UNSET函数)
第二部：最后所有的请求都已经处理完毕，SAPI也准备关闭了，PHP开始发行第二步。PHP调用每个扩展的MSHUTDOWN方法，这是各个模块最后一次释放内存的机会。
注意：只有在服务器没有请求的情况下才会执行“启动第一步”和“关闭第二步”。
InnoDB和MyISAM是在使用MySQL最常用的两个表类型，各有优缺点，视具体应用而定。基本的差别为：MyISAM类型不支持事务处理等高级处理，而InnoDB类型支持。MyISAM类型的表强调的是性能，其执行数度比InnoDB类型更快，但是不提供事务支持，而InnoDB提供事务支持已经外部键等高级数据库功能。
MyIASM是IASM表的新版本，有如下扩展：
二进制层次的可移植性。
NULL列索引。
对变长行比ISAM表有更少的碎片。
支持大文件。
更好的索引压缩。
更好的键码统计分布。
更好和更快的auto_increment处理。
以下是一些细节和具体实现的差别:
1.InnoDB不支持FULLTEXT类型的索引。
2.InnoDB 中不保存表的具体行数，也就是说，执行select count(*) from table时，InnoDB要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。注意的是，当count(*)语句包含 where条件时，两种表的操作是一样的。
3.对于AUTO_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中，可以和其他字段一起建立联合索引。
4.DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。
5.LOAD TABLE FROM MASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性（例如外键）的表不适用。
另外，InnoDB表的行锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，例如update table set num=1 where name like “%aaa%”
任何一种表都不是万能的，只用恰当的针对业务类型来选择合适的表类型，才能最大的发挥MySQL的性能优势。