No.1
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区别
Redis和Memcache都是将数据存放在内存中，都是内存数据库。不过memcache还可用于缓存其他东西，例如图片、视频等等；
Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，hash等数据结构的存储；
虚拟内存--Redis当物理内存用完时，可以将一些很久没用到的value 交换到磁盘；
过期策略--memcache在set时就指定，例如set key1 0 0 8,即永不过期。Redis可以通过例如expire 设定，例如expire name 10；
分布式--设定memcache集群，利用magent做一主多从;redis可以做一主多从。都可以一主一从；
存储数据安全--memcache挂掉后，数据没了；redis可以定期保存到磁盘（持久化）；
灾难恢复--memcache挂掉后，数据不可恢复; redis数据丢失后可以通过aof恢复；
Redis支持数据的备份，即master-slave模式的数据备份；
应用场景不一样：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攻击。
