PHPCon 2016之前大会PPT总结.md

写在最前

Devlink2016开发者大会没有直接参加，十分遗憾，只能通过会后的PPT来学习学习。最后还附加了一些其他比较有影响力的大会PPT总结

PHP游戏开发（王晶，半桶水）

桶哥的分享很受启发，原来php还可以在游戏领域开发，而且试用领域还挺广，并不只是只能做后台和官网等边缘功能，游戏领域包括

• 社交类
• 页游类
• 手游类

但也有一些差异：

• 单机极致，web开发的无状态特点有很强的横向扩展能力，游戏开发则更考验单机能力的最大化
• 缓存不易，web有很多静态数据需要缓存，游戏则缓存的场景不多，需要动态计算的多
• 读写比例，web的读比例更大，游戏则读写都很大

缓存

游戏开发对数据缓存要求很高，桶哥说缓存可以分为三级

• 进程内缓存，即直接在程序里面使用static保存
• 本机共享缓存，比如redis、mysql、文件
• 分布式缓存，网络缓存？不是很懂

一些坑

• 不要缓存大数组，反序列化会很慢，可以缓存单个值
• Yac会有几率返回错误值！

数据特点

游戏数据的特点

• 小
• 快
• 相对独立

redis非常适合，性能好、可持久化、数据类型也丰富

5ms级别的业务请求

游戏里有大量此种类型的接口要求，桶哥这里给出了以下建议：

不论业务的复杂度如何，一个api请求，只读一次数据，只写一次数据

这样做的好处是速度快、不产生脏数据、业务逻辑清晰

外挂处理

游戏领域的一个常见问题就是作弊问题，比如外挂，有以下几种预防措施

• 同一ip请求监控，不是很可靠，作弊者会切换ip，局域网的ip一样会误伤
• 同一用户的请求密度监控，不是很可靠，游戏里是会出现狂按鼠标的
• 同一用户每天行为阈值，可靠
• 社会工程学，外挂是有一定规律的

配置化管理

这点非常受启发，通过hook机制，在运营同学更新配置文件（如excel）后自动解析加载新配置文件，能够大大提高迭代速度

PHP做大数据量实时分析（吕毅）

此PPT最大的感觉是漂亮，PPT能力果然很重要哦 ^_，感受一下

吕毅-架构设计.png

PHP开发企业应用常见问题（王春生）

讲师总结的企业应用常见的几个问题感觉不错

• 如何选择PHP的开发框架？
• 如何保护自己的代码？
• 如何解决PHP环境部署的问题？
• 如何实现全文检索的问题？
• 如何实现计划任务的问题？
• 怎么导入导出word, excel?
• 如何实现轻量级的聊天服务器？
• 如何实现常见的消息通知？
• 如何应对常见的安全问题？

如何保护自己代码？

保护代码的最好方式是开源？ 这句话不懂，我猜讲师的意思是最好的方式是不要依赖代码的保密性，依赖服务、数据、内容可能更有优势

或者通过加密（ioncube、zend）
或者通过法律途径，这个比较困难

如何解决应用部署问题？

不是指业务代码部署，而是指用户拿到代码后如何部署？
原则是要简单，尽可能的简单
可以通过镜像、deb、rpm、docker等，尽量减少第三方依赖

如何实现计划任务？

看到这个主题终于理解了php版本task的意义
因为不可能再让用户去配置crontab，所以在项目要内置自己的计划任务管理

如何防止安全问题？

• XSS攻击: 对输入做标准化，过滤。HTML Purifier
• SQL注入: 接管SQL的拼装，并严格过滤
• 附件木马: 白名单模式，严格过滤
• CSRF攻击: 重要操作密码验证，邮箱验证，文件验证
• 垃圾过滤: 审核再发布，基于用户行为特征过滤
• 防DDOS: 第三方cdn，云加速之类的解决方案

PHP+Swoole在车轮互联的应用与实践（韩天峰）

峰哥主要介绍了swoole是如何在车轮网造轮子的，实现了一套相对轻量可控的服务治理系统

服务治理

我目前理解的服务治理是指公司内部众多团队都会产出各种各样的通用服务，如何高效的组织管理这些服务是一个很大的挑战。同时如果能够有一套优秀的解决方案，则会鼓励更多的使用服务化的架构（微服务），更加清晰易于维护

那么流行的服务治理有以下几种思路

• 基于PHP类库部署，优点是简单，直接引入类即可。但缺点同样是需要引入类，不易更新升级，无法跨语言- 基于数据库，如mysql、redis。优点是简单，也方便升级，可以跨语言。但这样系统之间耦合度太高，比较难扩展，同时还产生了依赖
• 基于HTTP + JSON + webAPI，优点是简单、跨语言、易升级、解耦，目前比较通用的解决方案。但缺点是http性能差，不支持订阅、推送，长连接支持不好
• Thrift、ProtoBuf。优点是解包打包性能好，IDL自动生成多语言调用。缺点为门槛高，难维护

最后是基于swoole的解决方案，优点为

• 基于c扩展封装了底层网络通信，性能好，简单易用，功能强大
• 可以跨语言调用
• 服务端自带task池，可以异步执行慢任务

缺点的话，依赖第三方扩展swoole，配套开源方案不够强大

swoole造轮子

第二部分为峰哥基于swoole服务治理开发的一些列轮子

先看一下服务治理全景

服务治理.png

配置管理，swoole搞了一套可以在各个平台同步json配置文件的方案
服务发现，swoole搞了一套服务的注册、上线、下线管理方案（zookeeper本质也是这？）
监控报警 & 调用统计，swoole实现了一套机器信息监控、统计监控报警的方案

淘宝社区双十一性能优化实践（信海龙）

本篇主要讲的是淘宝社区在高并发到来之前如何进行优化的

找出性能瓶颈

还在使用microtime(true)打点？请使用xhprof

另外还有一个技巧，能够在每个php文件都优雅统一插入统计文件

php auto_prepend_file="client.php"
nginx fastcgi_param PHP_VALUE "auto_prepend_file=client.php"
apache php_value auto_prepend_file="client.php"

数据库分库分表

首先明白为何分库分表。因为

• 单表读写压力大
• 大表结构调整困难

那么常用的分库手段包含？

• 水平分表
• 垂直分表
• 建立新库
• 增加从库

分库分表的难点一般有查询sql复杂、主从延迟。一般需要使用中间件进行封装与数据同步系统

降级系统

降级系统的意义是勉强的活着，优雅的死去

程序猿都该知道的MySQL秘籍（叶金荣）

老叶一如既往的干货满满，开篇即是高潮，逐条手撕myisam

myisam的观点

• 读性能更好
• 索引和数据分开，且索引有压缩，内存使用效率更高
• 可以直接覆盖myd/myi文件恢复数据，更快更方便
• count(*)和order by效率好，innodb count(*)会锁表
• innodb的insert和update太快，从库跟不上。。跟不上。。
• 有merge类型，可以快速count(*)

老叶的观点

• 大多数业务中，95%的场景都可以使用innodb
• innodb可以把数据、索引、有修改的数据都存放在buffer中，而且还有自适应hash索引，change buffer merge事实上更高效
• innodb也有类似的拷贝文件导入库，虽然不是那么方便，但也不麻烦
• count(*)没索引时任何引擎都慢。innodb全表count(*)时因为是事务表确实会慢，但不会锁表
• 额。。。
• innodb可以使用分区分表，虽然麻烦一些。另外如果目标仅仅是count(*)的话，可以使用第三方如redis统计
• innodb有完整的事务支持，更高的TPS
• innodb支持crash recovery。myisam不能自动修复，且耗时更久
• 事实上，多数场景innodb读性能更好，因为myisam只能缓存索引，而innodb同时缓存了数据

innodb正确玩法

这里老叶总结的很全，但我只记录一下我还模糊的

• innodb的行锁是加在索引上的
• 支持四个隔离级别，默认的RR解决了幻读
• 若无特殊需要，开启事务自动提交。大事务尽量拆成小事务
• 没有索引的update，可能导致锁表

联合索引怎么用？

现有联合索引k1(c1, c2, c3)，下面哪个查询不能完整使用整个联合索引？

where c1=? and c2 in (?, ?) and c3=?
where c3=? and c1=? and c2 in (?, ?)where c1=? and c2=? order by c3
where c1=? and c2 in (?, ?) order by c3

多表join时，order by的若不是驱动列，则无法使用索引

没踩过坑的都不是正常人

query cache(qc)

绝大多数场景鸡肋，最好关闭(query_cache_size=0 & query_cache_type=0)。因为qc锁是全局锁，每次更新qc的内存块锁代价高，很容易出现waiting from query cache lock状态

ibdata1文件暴增

文件内存了什么

• Data dictionary
• Double write buffer
• Insert buffer
• Rollback segments
• UNDO space
• Foreign key constraint system tables

暴增原因一般为大量的未提交事务，或者文件io性能差，还有32bit系统下的bug
解决的话升级5.6，提高io性能，事务及时提交，默认打开自动事务

表数据从十万到千万

• 10万，一般索引足矣
• 100万，需要考虑线上DDL风险，以及超过1s的查询
• 1000万，做好备份，上线前预评估sql，预防严重更新难问题
• 监控sql执行时间
• 分库分表不是银弹。优先考虑冷热数据分离或者无用数据归档。分库分表优先考虑在同一示例，否则需要靠谱的代理
• 工具pt-query-digest + anemometer

大量日志如何处理

• 存储入库优先使用tokudb引擎
• 历史数据归档大数据分析平台
• 日志表可以按时间分区分表，并定期归档处理

LAMP这些年开发的一些感悟（老百度）

PPT里多是经验之谈，有一些还是很中肯的，印象深的如下
不要太迷信于一些流言，xx性能不好、xx架构不行，更多时候是因为理解的不够，该做的优化没有做

另一个是关于规范的制定

1. 能够对开发人员透明的规范最优
2. 其次为包含了自动检查的规范
3. 再次为人肉检查代码的规范
4. 下下策为口头约束

安全编码实战经验（黄敏）

应对cc攻击（ddos的一种）

• 最简单的就是限制异常ip
• 然后就是尽量提高qps
• 减少sleep的进程

sql注入

老生常谈，但有几个仍然需要注意的地方

• gbk是存在漏洞的 比如錦
• php的单字节字符串函数也存在不安全的地方。最好统一使用utf-8和mb_*函数

函数安全

线上环境尽量禁用以下函数

eval
passthru
exec
system
chroot
scandir
chgrp
chown
shell_exec
proc_open
proc_get_status
ini_alter
ini_restore
dl
pfsockopen
openlog
syslog
readlink
symlink
popepassthru
stream_socket_server

文件

上传文件的格式限制要使用白名单而不是黑名单
尽量使用开源库，直接从http请求中处理
因为php原生后缀检查和web服务器的一些配置都存在已知漏洞

include文件时一定要控制可访问目录的权限以及 ../../../ 攻击

xss

xss攻击成功的话基本可以获取平台的部分甚至全部权限

不要试图使用正则去过滤script onload onerror等，xss有一万种方法绕过

服务端采用严格html语法解析，对tagname attrname attrvalue css严格检查才能杜绝

推荐开源库XML_HTMLSax3

社会工程学

最难防的攻击来自代码之外

加好友套话、欺骗工作人员、qq空间、朋友圈搜集信息

防不胜防

一个简单例子

用户基本信息：张小军 ZhangXiaoJun 19901210 18612345678
那么他的密码可能是

zxj1990
zxj19901210
zxj1210
Zxj1990
zhangxiaojun1990
zhangxiaojun1210
zhang1990
zhang18612345678
12345678zhang
zxj18612345678
zxj@1990
zxj@1234
zxj@123456
zxj12345678
12345678zxj

微博升级PHP7经验分享（胡波）

微博升级php7的最大经验就是完善的单元测试，这是他们最大的后盾

在升级过程中，依次保证

1. 函数功能兼容性测试
2. 扩展配置兼容性测试
3. 公共库单元测试
4. 业务逻辑测试
5. 线上小流量测试

编写可测试的PHP代码（罗承成）

这位讲师的分享也很中肯，分享了什么是单元测试？什么是可测试的代码？如何写可测试的代码？

单元测试

单元测试又称模块测试，是对程序中最小单元模块进行功能测试，最小模块可以是一个函数、一个过程、一个类或者就是一个小程序。需要提一下的是，单元测试有一个隐喻是指被测试的单元要跟周围的环境尽量隔离，依赖倒置

可测试的代码

可测试的代码主要是指容易测试的，一般需要遵循以下原则

• 隔离性，尽量不要依赖运行环境，或者至少要有明确的环境依赖配置
• 单元性，一个测试单元要实现一个单一的功能，不要多个功能混杂在一起，做到低耦合、高内聚
• 依赖注入，单元中所有的依赖要通过注入的方式明确声明，不要在程序深处有任何假设

不可测试代码

• $_ 超全局变量，对运行环境严重依赖，难以测试
• PHP魔法方法，同上
• 单例，同上？
• 依赖框架环境的静态方法，如TP的M、I方法
• 构造函数中包含业务逻辑，这种就很难创建类
• 超长的函数和类

Laravel Lego save you from CURD（张卫）

PPT风格很独特，幽默风趣
懒是最大的美德
同时还是个远程工作者（蛋壳公寓）
自己开发了一个库，能够方便的进行各种表单处理，挺实用方便的功能