淘宝双十一性能优化实践

DRC, 为什么我们要走最难的路: https://yq.aliyun.com/articles/2350
kvproxy - memcache 主从复制: https://yq.aliyun.com/articles/27264

性能优化基本思路: 预估流量; 性能评估; 找出瓶颈; 预案+容灾+演练
预估流量: 拍脑袋; 历史数据估算; 流量分解 - qps(总流量, 机器数, 内核数, 10h)
性能评估 - 流量压测: ab Jmeter Tcpcopy
找出瓶颈: 指标 - cpu 网络 磁盘io 日志(vmstat iotop tsar top); xhprof
预案+容灾+演练: 预案(超时设置, 代码容错); 模拟故障(iptables); 持续观察

分库分表: 写入/访问/修改表结构/承受压力; 水平/垂直 分表 + 新/从 库
问题: 查询变变复杂; 数据一致性(主从延迟)
解决方案: 数据库中间件(隐藏细节 读写分离 流量分配); DRC 数据同步

安全 - 降级系统(勉强的活着, 优雅的死去)
memcache 数据同步

程序员都该知道的mysql秘籍

从 MyISAM 升级到 InnoDB: https://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ==&mid=200910426&idx=1&sn=dd14fc0df2cc5296d07cb1b515b91a5e&key=710a5d99946419d9c0222e435f42cafdce7d9db8d140b7da9859fbe93ce1f2fd524ff75942d52183667100d29fcca9e6&ascene=0&uin=MjA5MTA1NTIwMA==&devicetype=iMac+MacBookPro12,1+OSX+OSX+10.11.3+build(15D21)&version=11020201&pass_ticket=InSTgGFYLtTtxNL2jUgxbKUjkTR2R8mE71oZDEH/NfkVFzhdMiuD200C/sPt78Rc
mysql autocommit: http://www.qttc.net/201208175.html
mysql 性能优化之 icp: http://blog.itpub.net/22664653/viewspace-1210844/
MySQL优化的奇技淫巧之STRAIGHT_JOIN: http://huoding.com/2013/06/04/261
维基百科 - I/O scheduling: https://en.wikipedia.org/wiki/I/O_scheduling
tokudb 特性: http://www.cnblogs.com/billyxp/p/3567421.html
在线 ddl: http://www.cnblogs.com/gomysql/p/3776192.html

MyISAM -> InnoDB: 适合95%以上的业务场景; 事务->高并发tps; crash recovery; read 效率更高

认识InnoDB

基于 B+ 树结构的聚集索引组织表;
表数据的逻辑存储顺序取决于聚集索引的顺序; 默认使用主键作为聚集索引, 没有使用内置生成 ROW_ID;
行锁是加载索引上的; 4个事务隔离级别, 默认RR解决了幻读问题

InnoDB 正确使用

都要有主键, 且最好没有业务用途, 不要修改主键; 主键最好顺序递增;
随机主键增加随机io, 降低性能; 大事务拆分成多个小事务, 分步快跑;
没有索引的更新的, 会导致全表数据被锁定, 等同于表级锁; 列属性 -> 长度够用就好, varchar/text 实际存储数据长度越小越好, 发生行溢出(off-page storage) 对性能影响可能很大;
不要直接 select * 读取全部列, 可能会导致更多的 io 读

优化

联合索引 & icp 特性(>=5.6)
straight_join & 查询驱动表: 多表join, 如果排序列不属于驱动表, 则无法使用索引完成排序

硬件/系统/配置选项 优化

I/O scheduling: deadline/noop > cfq(坚决不用)
file system: xfs > ext4/zfs > ext3(坚决不用)
mysql 配置优化

坑

query cache: 最好关闭
ibdata1: 文件暴增
自动类型转换: 查询的数据类型和列设置的数据类型不同
连接数过高: max_user_connections; 定时检查, 干掉慢查询

运维

备份: mysqldump(字符集) -> xtrabackup(混合引擎); 自动备份/检查/验证
高可用/故障转移: 双机+keepalived高可用; 多机 MHA(多节点); 备用异地机房(成本高); 延迟复制防止误操作
数据量: 10w -> 简单索引; 100w -> 在线ddl风险 + >=1s sql; 1000w -> 备份 + 预先做好sql解析; sql 监视/自动处理/报警; 大数据量 -> 优先冷热备份, 分区发表(优先在同一个实例, 跨库要靠谱的 proxy)未必是银弹; pt-query-digst + anemometer
大量日志: tokudb 引擎; 大数据分析平台; 按时间分表; 定期 创建/删除/归档 分表

拥抱 5.7

5.6 -> 5.7, 不建议 5.5 -> 5.7
安全性提升: 初始随机密码; 支持 ssl/tls 链接方式
标准化提升: 部分语法 报警 -> 报错
功能 & 性能 & 新特性

php 做大数据实时分析

走进大数据之storm流式计算基础: http://www.imooc.com/learn/461

统计平台: 简单的2栏式布局 + bootstrap
日志分析: 实时
架构: 业务线 -> kafka -> storm(stdio -> 多语言支持) <=> php 分析程序 -> DB + 报警机制(sms/mail); ui -> php接口(data/operate) -> db/cache
连接 storm 与 php: connect pool(fastcgi)
php 解析日志程序: 无状态(只做文本处理); input校验; 精简(不引入框架); 配置 php-fpm; 避免网络开销(DB/cache); 统一入口

kafka: 分布式消息系统, 数据分析项目中 producer 首选
kafka 实践: 消息状态(避免消息重复消费); 批量发送(buffer); 合理压缩(gzip, snappy, lz4); 消息持久化(避免消息落地过大); 消息时间序(queue, 小心多partition导致乱序); 依赖zookeeper(小心ZK节点过多导致数据同步的时间开销)

storm: 分布式实时计算系统, 极速处理大数据

php7: ?? 运算符

利用 docker 优化 php 开发流程

好雨云: http://www.goodrain.com/
the 12-factor app: http://12factor.net/zh_cn/

php开发流程的问题: 环境/测试/发布
环境: 代码即环境; 简单安装, 灵活配置; 公共镜像 -> 制定环境 -> 打包 -> 私有镜像
测试: 测试环境需要和开发环境分离, 也要保持一致, 而且要方便扩展多台进行服务器集群压测
发布: 秒级发布到所有场景

docker 工作流: 封装 -> 发布 -> 分发

产品快速交付: build(code + dockerfile) -> ship(环境切换) -> run

php 开发企业应用常见问题

易软天创-开发中心: http://devel.cnezsoft.com/
js 钩子机制: http://developer.51cto.com/art/201206/341822_all.htm
乌云网: http://www.wooyun.org/

企业管理软件 / 私有部署 / 终端环境: os, webserver, php / 大量问题 / 最小依赖, 最简安装, 最简维护

如何选择php框架

自创 zentaoPHP
第三方框架方向难以控制, 很多无法兼容老版本
程序员一定要控制代码

如何保护自己的代码

商务: 开源
技术: 安全(访问限制); 加密(ioncube, zend); 前端保护(用php输出, 代码混淆, 签名, 彩蛋-bmpcrypt); 法律(对内, 对外)

如何解决应用部署

尽可能简化用户安装: 一键安装包 docker镜像 虚拟机镜像

二次开发和升级的矛盾

模块: model view control lang config
oop
主干代码(目前没有分支) + 扩展代码

全文检索功能

第三方: 部署成本, 有局限
mysql fulltext: 不做分词, 单字索引; 小规模; 中文<=>unicode, 英文填充

计划任务

linux crontab
php ignore_user_abort() -> 仿 crontab(php版本) -> 用户可以后台添加 -> webserver重启, 需要用户手工触发

和其他数据格式交换

phpexcel ->excel phpword -> word; 另一种思路: 将 docx/xslx 当做模板
使用 api接口, 和其他应用集成

轻量级 IM 服务

nw.js: http://nwjs.io/

服务器: php + socket: 跨平台, 最小依赖; 启动一个 php 脚本即可
客户端: nw.js, h5 的方案
协议: 没有使用 websocket, 基于 socket 自定义
业务逻辑: 正常 B/S 架构, mvc 结构
文字->socket 附件->http

消息通知

邮件还是最常用的方式: 用户对smtp不了解; 邮件服务商对 smtp 越来越严格
技术无法解决 -> 尝试用商务来解决

常见安全问题

核心: 对用户输入过滤
xss->HTML Purifier
sql注入->接管sql拼接
附件木马->白名单
csrf->密码/邮箱/文件 验证
垃圾过滤->审核/基于用户行为特征过滤
防ddos->cdn/云加速

php游戏开发

web: 无状态 -> 横向扩展; 数据静态化(缓存); 读写比例大
游戏: 单机能力最大化; 基本是动态请求处理; 基本每个请求都有数据请求

配置(代表数值, 游戏基石之一): 配置优化
极致缓存: 进程内/本机共享/分布式共享
缓存单条数据, 大数组反序列化开销非常大
Yac 有概率取到错误数据
更新: flush共享内存; 配置文件使用redis 不同的库(selectDB)
游戏数据: 数据量小/快/相对独立

redis: hash结构 非常适合用户数据; 性能, 可持久化; 结构非常多, zsort做排行, KV做cache
redis 问题: 内存需求不断增长; 不适合做 gm 数据
解决方案: 改造 redis -> redis-storage; 后台直接读取 leveldb

5ms 级别: 一个 api 只做一次 读写
执行流程: client -> getMulti() -> 进程内的 static 数组 -> 所有业务都是基于 static 数组 -> setMulti() 一次性写入到 db
好处: 5-10ms; 不产生脏数据, 处理失败可以安全跑异常, 而不写入db; 业务逻辑简单清晰, 无瓶颈

安全: 请求防伪造(数据加密); 请求防并发(请求锁, redis-setnx)
外挂: ip监控; 用户请求监控; 用户行为监控(产出固定, 可靠); 社会工程学

小经验: 和策划配合 -> 配置的规律化/自动化;
规律化: id -> 包含多个信息, 不用反复查表; 奖励(类型+id+数量 / 随机概率); 条件(类型 + id + min + max)
自动化: 策划修改 excel -> git hook 判断 -> 对应到 db

断线重连: 粗暴型 -> 断线重新进入游戏, 数据一致; 友好型 -> 根据当前操作判断是否需要重新加载游戏, 体验好, 但是逻辑复杂, 可能会数据不一致

php应用性能管理与实践

听云: http://www.tingyun.com/
深入理解php内核: http://www.php-internals.com/

APM: application performance management
SLA: service-level agreement
server端关注点: 运行性能; 服务质量(异常, 错误); 应用拓扑; 跨应用追踪

php性能监控原理: zend/opcode/extension

phpcon-china2016

第四届中国php开发者大会: https://github.com/ThinkDevelopers/PHPConChina/tree/master/PHPCON2016

微博移动服务集群升级php7

升级后盾: 单元测试(覆盖率); CI; 监控+日志; 配置管理+反馈系统

php7+swoole 开发超高性能后台程序

关于C10K、异步回调、协程、同步阻塞: http://rango.swoole.com/archives/381
MySQL协议分析: http://blog.csdn.net/wind520/article/details/43964821

c10k: epoll 实现 异步IO; nginx+swoole; 并发 100w
1w+ qps: 单台近 10亿动态请求; 100 台服务器解决 全民级应用(双11, 抢红包)
实现 1w+ qps: IO足够快(redis, mysql, CURL, 磁盘)/异步; cpu消耗(web server, php framework, php app)
同步阻塞: 多开进程增加处理能力; 增加进程带来额外进程切换开销
提升性能: php7(一倍); yaf/phalcon
swoole: 常驻内存, 取消 php-fpm 创建销毁进程开销; 纯 c 编写; 支持 php7
zend 引擎: opcache 只能优化 opcode; opcdoe 需要 hashtable(消耗 cpu); lamp 每次请求都会释放 hashtable
swoole 服务器: 常驻内存, 只需初始化一次(big array, object, constant value 等等); 只需专心编写业务代码

实践: php7 + swoole + yaf/phalcon + redis
短网址服务(62进制): swoole_http_server + redis; swoole task
mysql-proxy: swoole_mysql, mysql 连接池
超高性能统计计算程序

swoole2.0: 同步代码, 异步IO

php7 高性能之源

bench.php: https://www.pureftpd.org/project/phpbench

profile: 权威性能测试, 这样才能得出各部分耗时的占比
profile-php5.5: zend vm; memory(is the key)
profile-zval: 原来的类型过少, 导致有些类型分配的内存比实际使用的要高

zval + array + huge page + memory manager

php 在金融股票项目中的应用

php 弱类型安全总结: http://blog.spoock.com/2016/06/25/weakly-typed-security/

类型自动转换的场景: 包括函数 , switch, 数字(不同进制, 科学计数法)-string-array

数据准确性

弱类型: 配置化 validation
浮点: 全部 x 100000(bigint) + 字符串化(bcmath/gmp)
校验: 接口(json); 格式(validation); 数据(对比监控)

解耦: 一切皆接口

问题: all in one -> 数据处理 + 对外服务; 读库 + 写库
一个程序只干一件事情: 容灾/多数据源; 统一处理; 有损服务/降级服务; 重构

性能问题

缓存: 高速缓存 vs 大量数据 -> redis/ssdb; 主动 vs 被动; 特殊情况 -> daliy cache; 正向 vs 反向
请求最频繁的接口(行情): 自研方案; nginx + lua; swoole; php-fpm
kql(一个页面请求多个接口): 基于 yar 自组织合并接口
实时计算: 准实时; 计算离数据近; 尽量少写代码; 数据层面的解决方案(mysql, spark, mongodb 等); 通用计算模型(rank, sum/avg, map-reduce, 除复权)

lxc

lxc部署, git代码发布

全栈

nginx + php-fpm
mysql: 5.7.x, 大量使用 json 字段
mongodb: 计算用数据, 3.2.x, 数据仓库
sphinx: 搜索
Python: 数据处理 + 机器学习
redis: 高速缓存 + pubsub
ssdb: 普通缓存

php 系统问题排查

常见问题: 502; mysql_connect(warning); high cpu
解决问题基本思路: 验证 -> 排查问题 -> 恢复服务(摘机/回滚/重启/降级) + 保留现场(运行状态/外部监控/系统日志)

排查问题

知识 + 工具 + 数据

语言: 基本语法, php运行机制
系统: 操作系统/软件 相关知识
协议: tcp, mysql通信协议

系统: top vmstat stat
网络: tcpdump wireshark netstat
进程: gdb pstack strace

案例

cpu 100%: 摘机/重启 -> 日志 -> gdb 分析进程 -> 验证(设置连接超时等待)
找出有问题的机器: 修改超时时间 -> 分析 php-fpm 日志 -> tcpdump 抓包分析 -> 摘机, 持续观察(wireshark 正常包/异常包)
后端执行: &(会话机制) + crond(锁占用)

qq会员活动运营平台

bitmap 算法: http://www.cnblogs.com/dyllove98/archive/2013/07/26/3217741.html
3种MPM介绍: http://www.cnblogs.com/fnng/archive/2012/11/20/2779977.html
深入研究PHP及Zend Engine的线程安全模型: http://blog.163.com/zdm_84/blog/static/8694933320134253285119/
gdb 调试 php 代码: http://rango.swoole.com/archives/325
AMS 升级 php7: http://hansionxu.blog.163.com/blog/static/241698109201651784036924/

活动: 上线周期短; 功能多样; 节假日
cgi层问题根源分析: 扩容(权限, 人工开通); 单机并发(apache-prefork); php版本

平台早期: 功能集中, 开发部署简单
系统庞大: 代码耦合, 代码更难理解(效率); 修改需要多人确认, 测试回归(协作)

unix 哲学 do one thing and do it well: SOA/微服务

php升级: 清理扩展; 线程安全; 语法兼容(function_exists); 灰度上线(限流, 白名单); gdb/strace/var_dump()+exit 调试; web server 调试模式

mysql 5.7 sys 扩展

使用 /proc 文件系统来访问 Linux 内核的内容: http://www.ibm.com/developerworks/cn/linux/l-proc.html
linux vmstat 命令实战: http://www.cnblogs.com/ggjucheng/archive/2012/01/05/2312625.html
百度百科-覆盖索引

知识 + 效率 + 立竿见影(开发)
sys schema: 视图/函数/存储过程; 帮助 dba/开发 分析定位问题; 5.7 默认安装, sys database
performance_schema: 数据量太大, 太专业

views: 使用者角度(user/host); 资源角度(io/memory); schema 级别统计信息(对象, 索引, 表, 表锁); statement 级别统计信息(执行出错, 全表扫描, 创建临时表, 排序); 其他(buffer bool, 锁等待, 会话, 延迟)
function: 格式化数据, 提取对象名字, dump线程堆栈
procedures

索引结构: MyISAM 为每个 key 单独建立结构, InnoDB 为 pk + pk&key
索引好处: 过滤, 减少扫描; 避免排序和临时表; 随机io -> 顺序io; 覆盖索引
索引的坏处: 占用磁盘空间; 增加 crud 代价

索引统计 schema_index_statistics; 查看并删除重复索引 schema_redundant_indexes; 无用索引 schema_unused_indexes

从学徒到大师 - 谈laravel框架扩充&套件开发

http://packalyst.com
https://socialiteproviders.github.io

composer(autoloading) + psr + laravel 全栈
DI / loC Container / Contract(interface) / service provider
packagist: 发布 laravel 插件
更换模板引擎: rcrowe/TwigBridge; ytake/Laravel.Smarty

架构探险

我们用起来不错, 也许别人也需要呢
我要知道我们又多受欢迎
百度百科 - kafka: 高吞吐量的分布式发布订阅消息系统
lambda 架构: http://www.tuicool.com/articles/uiyYFf
Apache Mesos和Mesosphere DCOS：历史、架构、发展和应用: http://www.dataguru.cn/article-8220-1.html
百度百科 - SDN

BaaS(backend as a service)
单体应用 vs 微服务
服务化, 容器化
统计: 日活; 日新增; session 时长; IAP 统计数据

微服务 + lambda
微服务 + dcos + sdn

百万并发下php协程 + 非阻塞框架设计实践

说说 json 和 jsonp: http://kb.cnblogs.com/page/139725/
php 生成器: http://php.net/manual/zh/language.generators.syntax.php
百度百科 - bigpipe
前端优化 bigrender: http://www.tuicool.com/articles/fYvyMr

连接数; 并发; 性能
web io 模型: php-fpm 进程; java 线程; go 协程; node.js callback
zan io 模型: just like GO; 基于 swoole 非阻塞 callback + php yield
callback(嵌套, 异步回调) vs 协程(同步方式)
php 协程: yield; Generator; 函数中断(return); 双向通信
并行: 基于 syscall, 业务开发无须关心内部实现
异常处理: 全流程异常捕获; 完美支持 callback 后异常处理; rpc 异常透传
单元测试

zan 框架设计: sqlmap(sql定位, sharding, cache, 建模); view(继承, 组件化, bigpipe&bigrender); 连接池; 非阻塞 libs(mysql, redis, KV, TCP, HTTP); SOA

起点中文网全新改版协程之路

基础框架: koa(前后分离的模板服务) + swoole + TSF(业务逻辑服务协程框架) + TAF(soa后台服务框架)
数据: 动态加载 + 外部广告 + 运营编辑 + 业务统计
测速对比: 首页延时-全国各省市
架构: 接入层(dnspod->TGW->nginx) + 模板层(koa) + 逻辑层(TSF) + soa服务层(TAF, java, php, nodejs) + 数据层
协程调度: async IO + eventloop + splstack
文件服务
web灰度(将灰度进行到底): client/server/web; 账号/地域/独立端; 全站调用灰度api, 设置 cookie

mark

time php test.php # 查看某一个命令的执行时间# lxclxc-clone -o ubuntu -n foobar # 复制tar --numeric-owner -czf ./foobar.tgz /path/to/lxc/foobar # 备份tar --numeric-owner -xzf ./foobar.tgz # 迁移gdb -p 10343 # 分析进程tcpdump -i eth0 -s 3000 port 3306 -w ~/sql.pcapstrace -Ttt -v -s 1024 -f -p pid # 查看work 进程工作处理pidstat -ruh -p pid 1 10 # 查看进程资源消耗php test.php & # EIOphp test.php &> test.log &nohub php test.php &lsof|grep test.lock # 查看锁占用情况select @@performance_schema # 查看变量, @@ 为系统(全局)变量show variables like 'version%'set performance_schema=xxx # 设置变量select * from host_summary_by_file_io # 视图的2种写法select * from x$host_summary_by_file_io