xxs
很多应用含有富文本内容，这类应用最典型的特征是具有编辑器，例如：博客日志，邮箱等。这类应用往往允许使用一定的HTML代码。为了在用户体验和安全之间寻找平衡，各种厂商可能采用了不尽相同的办法。但是总体来说，有2类。
第1类我们称为白名单，即：只允许使用白名单内的合法HTML标签，例如IMG。其它均剔除。例如：百度贴吧回帖时候的代码过滤方式。
第2类我们称为黑名单，即：厂商会构建一个有危害的HTML标签、属性列表，然后通过分析用户提交的HTML代码，剔除其中有害的部分。 如：QQ邮箱的发邮件时的过滤方式。
白名单要安全得多，而黑名单的方式则经常会被绕过。
这么看来，还是白名单好一点。
csrf
你这可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。 服务端进行CSRF防御 (1).Cookie Hashing(所有表单都包含同一个伪随机值) (2).验证码 (3).One-Time Tokens(不同的表单包含一个不同的伪随机值)
DDos
没找到行之有效的方案，目前只能上云和启动云盾这样的付费服务
sql注入
主要设计模式和应用场景
1、工厂模式与抽象工厂模式：不同条件下创建不同实例
2、单例模式：保证一个类仅有一个实例
3、建造者模式：将一个复杂的构建过程与其具表示细节相分离，使得同样的构建过程可以创建不同的表示
4、原型模式：通过拷贝原型创建新的对象
5、适配器模式：使得原本由于接口不兼容而不能一起工作的那些类可以一起工作
6、过滤器模式：使用不同的标准来过滤一组对象，通过逻辑运算以解耦的方式把它们连接起来
7、观察者模式：一对多的依赖关系，在观察目标类里有一个 ArrayList 存放观察者们。当观察目标对象的状态发生改变，所有依赖于它的观察者都将得到通知，使这些观察者能够自动更新（即使用推送方式）
8、策略模式：策略对象依赖注入到context对象，context对象根据它的策略改变而改变它的相关行为(可通过调用内部的策略对象实现相应的具体策略行为)
开发框架
一般框架 单一入口->路由->分发->渲染，加一些扩展性，给路由，分发和渲染加上接口或者抽象类，再方便点加上composer,再好维护点加模块
redis类型，持久化类型
魔术方法
__construct()，类的构造函数__destruct()，类的析构函数__call()，在对象中调用一个不可访问方法时调用__callStatic()，用静态方式中调用一个不可访问方法时调用__get()，获得一个类的成员变量时调用__set()，设置一个类的成员变量时调用__isset()，当对不可访问属性调用isset()或empty()时调用__unset()，当对不可访问属性调用unset()时被调用。__sleep()，执行serialize()时，先会调用这个函数__wakeup()，执行unserialize()时，先会调用这个函数__toString()，类被当成字符串时的回应方法__invoke()，调用函数的方式调用一个对象时的回应方法__set_state()，调用var_export()导出类时，此静态方法会被调用。__clone()，当对象复制完成时调用__autoload()，尝试加载未定义的类__debugInfo()，打印所需调试信息
服务器架构
mysql左前缀
主从复制
http状态码
ab压力测试
负载均衡
主服务器挂掉浏览器显示
redis遇到的坑
redis排序
redis和memcached区别
1、Redis和Memcache都是将数据存放在内存中，都是内存数据库。不过memcache还可用于缓存其他东西，例如图片、视频等等； 2、Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，hash等数据结构的存储； 3、虚拟内存--Redis当物理内存用完时，可以将一些很久没用到的value 交换到磁盘； 4、过期策略--memcache在set时就指定，例如set key1 0 0 8,即永不过期。Redis可以通过例如expire 设定，例如expire name 10； 5、分布式--设定memcache集群，利用magent做一主多从;redis可以做一主多从。都可以一主一从； 6、存储数据安全--memcache挂掉后，数据没了；redis可以定期保存到磁盘（持久化）； 7、灾难恢复--memcache挂掉后，数据不可恢复; redis数据丢失后可以通过aof恢复； 8、Redis支持数据的备份，即master-slave模式的数据备份； 9、应用场景不一样：Redis出来作为NoSQL数据库使用外，还能用做消息队列、数据堆栈和数据缓存等；Memcached适合于缓存SQL语句、数据集、用户临时性数据、延迟查询数据和session等。
mysql两种数据库类型和区别
MyISAM： 1、表级锁， 如果数据量大，一个插入操作锁定表后，其他请求都将阻塞 2、支持全文索引 3、支持查询缓存 4、不支持事务安全 5、MyISAM也很难正确的备份，备份的时候通常需要锁住整个系统的数据，这就意味着每天网站都要宕机或者无法使用15，30，60分钟或者更多 Innodb： 1、支持行级锁和表级锁，能支持更多的并发量 2、mysql5.6版本开始支持 全文索引 3、查询不加锁，完全不影响查询 4、支持事务安全 通常来说，InnoDB表更块，更安全，功能更强大并且正变的越来越好。你应该总是使用它，除非有一些特殊的原因。 哪些特殊的原因可能会使你不用InnoDB表呢？ 至少有两种，首先是count(*)行为。在MyISAM表中，SELECT count(*)在没有WHERE条件时是很快速的。而InnoDB必须确切的计算出行数，这样就会变慢。当然，经常使用count(*)对程序来说不是一个很好的方法（首先使用一个索引列会更快，比如：count(id) 并且很少会有一个好的语句不包括WHERE子句。 再则，MyISAM表允许在定期列中进行全文检索，而InnoDB不支持。通常在像Lucene或者Solr（或者在新版本MySQL中的Sphinx）系统中，真正的查询是在MySQL之外被完成的；在这种情况下，你可能需要使用MyISAM的文本表。 总体而言，简单的说就是每张表都应该使用InnoDB，只有很少的例外。
为什么用innodb
phalcon和lereval优势
Phalcon 是开源、全功能栈、使用 C 扩展编写、针对高性能优化的 PHP 5 框架。 开发者不需要学习和使用 C 语言的功能， 因为所有的功能都以 PHP 类的方式暴露出来，可以直接使用。 Phalcon 也是松耦合的，可以根据项目的需要任意使用其他对象。 Phalcon 不只是为了卓越的性能, 我们的目标是让它更加健壮，拥有更加丰富的功能以及更加简单易于使用！ Laravel 的设计思想是很先进的，非常适合应用各种开发模式TDD, DDD 和BDD，作为一个框 架，它准备好了一切，composer 是个php 的未来，没有composer，PHP 肯定要走向没落。 laravel 最大的特点和优秀之处就是集合了php 比较新的特性，以及各种各样的设计模式， Ioc 容器，依赖注入等。 基于组件式的框架，所以比较臃肿
lereval路由
链表
swoole相关
强制使用索引sql怎么写
SELECT * FROM TABLE1 FORCE INDEX (FIELD1)
只使用建立在FIELD1上的索引，而不使用其它字段上的索引。
es做什么，怎么存储
1、Elasticsearch的功能 （1）分布式的搜索引擎和数据分析引擎 搜索：百度，网站的站内搜索，IT系统的检索 数据分析：电商网站，最近7天牙膏这种商品销量排名前10的商家有哪些；新闻网站，最近1个月访问量排名前3的新闻版块是哪些 分布式，搜索，数据分析 （2）全文检索，结构化检索，数据分析 全文检索：我想搜索商品名称包含牙膏的商品，`select * from products where product_name like "%牙膏%"` 结构化检索：我想搜索商品分类为日化用品的商品都有哪些，`select * from products where category_id='日化用品'` 部分匹配、自动完成、搜索纠错、搜索推荐 数据分析：我们分析每一个商品分类下有多少个商品，`select category_id,count(*) from products group by category_id` （3）对海量数据进行近实时的处理 分布式：ES自动可以将海量数据分散到多台服务器上去存储和检索 海量数据的处理：分布式以后，就可以采用大量的服务器去存储和检索数据，自然而然就可以实现海量数据的处理了 近实时：检索个数据要花费1小时（这就不要近实时，离线批处理，batch-processing）；在秒级别对数据进行搜索和分析 跟分布式/海量数据相反的：lucene，单机应用，只能在单台服务器上使用，最多只能处理单台服务器可以处理的数据量 2、Elasticsearch的适用场景 国外 （1）维基百科，类似百度百科，牙膏，牙膏的维基百科，全文检索，高亮，搜索推荐 （2）The Guardian（国外新闻网站），类似搜狐新闻，用户行为日志（点击，浏览，收藏，评论）+社交网络 数据（对某某新闻的相关看法），数据分析，给到每篇新闻文章的作者，让他知道他的文章的公众反馈（好，坏，热门，垃圾，鄙视，崇拜） （3）Stack Overflow（国外的程序异常讨论论坛），IT问题，程序的报错，提交上去，有人会跟你讨论和回答，全文检索，搜索相关问题和答案，程序报错了，就会将报错信息粘贴到里面去，搜索有没有对应的答案 （4）GitHub（开源代码管理），搜索上千亿行代码 （5）电商网站，检索商品 （6）日志数据分析，logstash采集日志，ES进行复杂的数据分析（ELK技术，elasticsearch+logstash+kibana） （7）商品价格监控网站，用户设定某商品的价格阈值，当低于该阈值的时候，发送通知消息给用户，比如说订阅牙膏的监控，如果高露洁牙膏的家庭套装低于50块钱，就通知我，我就去买 （8）BI系统，商业智能，Business Intelligence。比如说有个大型商场集团，BI，分析一下某某区域最近3的用户消费金额的趋势以及用户群体的组成构成，产出相关的数张报表，**区，最近3年，每年消费金额呈现100%的增长，而且用户群体85%是高级白领，开一个新商场。ES执行数据分析和挖掘，Kibana进行数据可视化 国内 （9）国内：站内搜索（电商，招聘，门户，等等），IT系统搜索（OA，CRM，ERP，等等），数据分析（ES热门的一个使用场景） 3、Elasticsearch的特点 （1）可以作为一个大型分布式集群（数百台服务器）技术，处理PB级数据，服务大公司；也可以运行在单机上，服务小公司 （2）Elasticsearch不是什么新技术，主要是将全文检索、数据分析以及分布式技术，合并在了一起，才形成了独一无二的ES；lucene（全文检索），商用的数据分析软件（也是有的），分布式数据库（mycat） （3）对用户而言，是开箱即用的，非常简单，作为中小型的应用，直接3分钟部署一下ES，就可以作为生产环境的系统来使用了，数据量不大，操作不是太复杂 （4）数据库的功能面对很多领域是不够用的（事务，还有各种联机事务型的操作）；特殊的功能，比如全文检索，同义词处理，相关度排名，复杂数据分析，海量数据的近实时处理；Elasticsearch作为传统数据库的一个补充，提供了数据库所不能提供的很多功能
es和sphinx的区别
ES 缺点 基于java，会有一些java的常见问题需要注意，比如gc 单纯执行速度上比C写的sphinx慢 sphinx 优点 纯粹，没有什么花哨的其他功能 C写的，速度快 新版本加了分布式、动态更新索引等功能 下面列举Es比sphinx优秀的部分 1、部署简单，虽然sphinx部署也挺简单，但是在书写配置的时候，你会发现，sphinx的配置是要写好后，重启sphinx，而Elasticsearch针对某个索引的配置，是可以动态写入的。 2、调试简单，sphinx有命令行工具可以调试，而Elasticsearch使用的是http接口进行调试，不需要专门的API类，几行php代码就可以写一个Elasticsearch的API。 3、可视化工具比较多，有收费的，也有免费的，比如kibana head marvel。 4、提供结构化的JSON查询语句，易读性强 5、Es可以保留源数据（可选），也就是说，你可以不需要mysql的支持，就可以完成整个搜索过程，即使你不需要这个功能，在调试的时候，还是让人感到非常便利，不用将查询结果到数据库匹配一下。 6、Es可以动态更新全文索引，动态更新单个记录，而不像sphinx一样需要重建全部 7、对UTF8的支持是不需要单独配置的
安全性方面有什么经验
1、把握整站的结构，避免泄露站点敏感目录 2、使用预编译语句，避免sql注入 3、预防XSS代码，如果不需要使用cookie就不使用 4、限制用户权限，预防CSRF 5、严格控制上传文件类型 6、加密混淆javascript代码，提高攻击门槛 7、验证码安全性
session存储在数据库或者redis怎么做
存在redis中： 方法一： 找到配置文件php.ini，修改为下面内容，保存并重启服务 session.save_handler = redis session.save_path = "tcp://127.0.0.1:6379" 方法二： 直接在代码中加入以下内容： ini_set("session.save_handler", "redis"); ini_set("session.save_path", "tcp://127.0.0.1:6379"); 注：如果配置文件redis.conf里设置了连接密码requirepass，save_path需要这样写tcp://127.0.0.1:6379?auth=authpwd ，否则保存session的时候会报错。 存在mysql中： 请看其他文章
cookie禁用了，session为什么不能用
说一下这2个的基本信息吧，2个统称为会话，session存在于服务器端，cookie存在于用户端。之前有人说过如果禁用了cookie那么session就使用不了了，可以说这是正确的，也可以说这是错误的。因为禁用了cookie，session_id就不能保存，而服务器正是根据session_id来判断用户的session，所以说这是正确的。经过测试，当我们禁用cookie时，刷新页面session_id会改变，说明session_id是用cookie保存的。 解决cookie禁用然后引用session的方法。 1. session.use_cookies = 0 //设置客户端是否使用cookie来保存session值该参数的值不影响上述机制的进行。但是为了验证该机制，这里把该参数设为0，排除cookie携带seesionid的可能 session.use_only_cookies = 0 //是否只使用cookie来保存session值该参数为1时，上述机制失效。 设置session.use_trans_sid = 1或者编译时打开打开了--enable-trans-sid选项 这样他会在每个url后面自动加上PHPSESSID的值，然后正常使用session就可以了。 2. 在url后面加上session_id的值或者保存session_id的值于数据库或redis中，然后在下一次要调用session前，运行session_id（$session_id），还有这条语句要在session_start()前。 目前我了解到的只有这两种方法可以解决。 然后我再聊下session_id吧，它是保存在cookie中，首先session是一个只要活动就不会过期的东西，只要开启cookie，每一次会话，session_id都不会改变，我们可以根据session_id来判断用户是否是正常登陆，防止用户伪造session。然后我们也要防止session被劫持，我们可以对session_id进行再一次的加密，防止暴力破解，还有可以设置HttpOnly。通过设置Cookie的HttpOnly为true，可以防止客户端脚本访问这个Cookie，从而有效的防止XSS攻击。