在业务层的优化有nginx+php（fastcgi连接方式、php-fpm.conf配置中的优化），我的一个经验是，如果nginx同phpcgi运行在同一台服务器，采用unix socket的方式进行fastcgi协议的交互是效果最快的，比127.0.0.1的回环地址要快太多。我在08年优化过一台服务器（Dell 2960，16G内存），通过两个步骤，将一台服务器从900qps，优化到6000qps以上,其一是将fastcgi协议运行在unix socket上，其二是合理配置spawn-fcgi的进程数量。现在基本上phpcgi都是运行在php-fpm中的了，其进程池逻辑是我最赞赏的功能之一。

　　如果nginx和php-fpm不在同一台服务器上，可以考虑使用fastcgi_keepalive的配置，实现nginx同fastcgi服务器持久连接，以提高效率。

　　nginx+php-fpm提供的运行状态非常有意义，nginx的status模块和php-fpm的status输出可以告诉我们nginx进程的请求处理状况，php-fpm的status输出可以告诉我们php-fpm的进程池设置是否合理。我们目前对这两个数据通过nagios定期采集，并绘制成图表，很有“观赏价值”。

　　php-fpm.conf的配置中还有几个参数对优化比较重要，其一是进程自动重启的条件 pm.max_requests，其二是php-slow log的配置，slow log 是优化php代码的非常重要的信息。在我目前的环境中，php的慢执行日志是通过rsyslog进行传输并集中分析的，以此反向推进开发对php代码的优化。

　　php的服务器在高并发的情况下，有可能因为服务器本身可提供的端口数量的限制，无法同redis服务器建立大量的连接，这时候可以在sysctl.conf中配合timestamps=1 加上 tw_reuse/tw_recycle的方式，进行端口快速回收，以便更好的向数据层建立连接，接入层的haproxy是不可以这样的。

　　这一层还涉及到一个安全问题，就是php代码被修改并挂马的状况，我的解决方案是，将php-fpm的运行用户同php代码的属主设置成不同的用户，并且保证php-fpm的运行用户不能对php代码具有写的权限。

　　数据层的情况里，MySQL主从结构以及MHA+keepalived的高可用配置，这个基本上是看文档应该就能够理解的。如果是5.6的新版MySQL，其高可用监控可能可以做的更简单，MySQL官方提供对应的工具，只是我还没有测试。对MHA的监控功能，我觉得亮点是MHA对切换过程中MySQL binlog的获取和执行，在最大程度上避免了数据丢失。但是其缺点也是有的，比如：监控进程在触发切换后就停止了，一旦触发，必须重新启动进程再继续监控。06年时我在sina做过一个叫Trust DMM的项目，通过 DNS、MON加上自己写的插件，监控MySQL主从集群的可用性，可以实现，主库、主备自动切换（缺乏binlog处理的环节）；从库是一组服务器，如果从库发生问题，可以自动下线。只是这套系统部署起来比较麻烦。这个项目曾经获得过sina的创新一等奖。

　　我还提到了我认为的DBA日常的工作至少应该包括：审查并执行上线SQL；定期检查MySQL慢日志并分析，将分析结果反馈到开发部门进行调整；定期审查数据库中索引的效率以及可用性，进行优化我反馈。现在做一个一般水平的DBA已经相当容易了，对percona的工具了解透彻，已经能够解决非常多的数据库问题了。

　　MySQL还有一个难缠的问题，numa架构下，大内存服务器内存使用效率的问题，numactl对策略进行调整，如果使用percona的MySQL版本，可以通过 memlock配置对MySQL的Innodb引擎进行限制，禁止其使用swap。

　　MySQL常见的架构里，还有一种主从存储引擎不一致的方式，即主库采用Innodb引擎，提高并发写入的能力，从库采用Myisam引擎，这种方式目前我们也在采用。这样做一是为了获取更好的读性能，另外是，Myisam引擎的是可以节省内存的。Myisam在索引数据内存读取，数据内容磁盘读取的状态下，已经可以比较高效的运行了，myisam_use_mmap的配置项，会让MySQL将myisam的data文件也mmap到内存中，这样做既高效，又可以使用mysiam引擎的特性。

　　数据库主库要避免一件事情发生，就是无条件删除和无条件修改，如“delete from table”以及”update table set xxx=yyyy”等无where条件语句，原则来讲是应该禁止执行的，这样的权限不应该开放给开发的同学，甚至DBA都不能无限制的操作。目前我的解决方案是 sql_safe_updates=1,但这配置是不能够写my.cnf中的，只能启动mysql后进入console进行配置。

　　当前我们还使用了Redis作为DB，基于主从架构，跨IDC。目前的问题是，复制连接断开后，Redis快照重传的问题，从库会在快照替换期间有短暂的性能抖动。 Redis2.8新版本psync的特性应该可以改善这个问题。我们还使用twemproxy，目前部署在每一台php服务器上，并监听unix socket，php使用phpredis的模块进行连接。有效减少三次握手的时间。temwproxy还有很多其他的优秀特性，通过一致性hash做cache集群，可以有效的避免cache迁移问题。通过其对后端redis的健康监控，可以自动下线有故障的redis。

　　还有针对多IDC的图片存储和Cache部署情况。目前我们自建的图片CDN承载网站每天约4亿的请求，带宽最高峰值约1.5G左右，其结构大体上是中心IDC存储图片原图+SQUID disk cache存储图片缩略图，在外地IDC使用两级缓存，分别为一层SQUID disk cache（两台，做HA），另一层为Varnish cache（最多四台），实际上，如果仅考虑work around的状态，squid cache层基本上也可以不要的。但是，目前这样的结构可以减少varnish回中心节点的请求，减少中心机房带宽的压力。这个结构还算简单，varnish在高并发请求下，有一些资源配置是需要注意的，比如NFILES / VARNISH_MAX_THREADS / nuke_limit 等。

　　沟通的技术问题还是非常多的，包括在井源那里提到监控框架的事情，也尤其提到了我对rsyslog的优化，优化后的rsyslog在可靠性方面是非常值得称赞的（优化思路见参考6）

　　我有一些将电商三面的运维运维同学的问题综合到这里了，有些话重复的就不再描述。

　　值得一提的是二面是另一位开发负责人，一看就是个很有独立思考能力的同学，他问了我一个很有意思的问题，大体的意思是，在系统架构方面，有这样的几个层次，从下往上：使用开源、精通开源，优化并修改开源软件，创造开源软件。问我自己评价我是在哪一个层次的。我认真的思考了一下，我应该是在第二个层次，有些精通的，有些修改过的。

　　电商四面是时间最长的，至少有两个小时以上，结束的时候已经是夜里一点四十了，我觉得电商的老大是应该在支付宝里面给我捐一些钱才好的 ，不知道有没有小米的同学能够转告哈  。我们应该是谈到了非常多的事情，包括秒杀的解决方案，包括对持续集成和自动化测试的理解、对后台数据业务类型的开发中数据计算错误的理解，时不时能够得到“我们想的很一致”这样的评价。

　　那时已近半夜，记忆进入低效态，一些太琐碎的事情记不得了，重复的技术方案也不再赘述。下面简单描述一下我对秒杀的解决方案的理解：10w的数据，从0到10w，不能多卖。目前的问题是，每次到秒杀时分可能同时进入100w的请求/连接。如何破？