No.1

xxs

1. 不少應用含有富文本內容，這類應用最典型的特徵是具備編輯器，例如：博客日誌，郵箱等。這類應用每每容許使用必定的HTML代碼。爲了在用戶體驗和安全之間尋找平衡，各類廠商可能採用了不盡相同的辦法。可是整體來講，有2類。
2. 第1類咱們稱爲白名單，即：只容許使用白名單內的合法HTML標籤，例如IMG。其它均剔除。例如：百度貼吧回帖時候的代碼過濾方式。
3. 第2類咱們稱爲黑名單，即：廠商會構建一個有危害的HTML標籤、屬性列表，而後經過分析用戶提交的HTML代碼，剔除其中有害的部分。 如：QQ郵箱的發郵件時的過濾方式。
4. 白名單要安全得多，而黑名單的方式則常常會被繞過。
5. 這麼看來，仍是白名單好一點。

 

csrf

1. 你這能夠這麼理解CSRF攻擊：攻擊者盜用了你的身份，以你的名義發送惡意請求。
2. 服務端進行CSRF防護
3. (1).Cookie Hashing(全部表單都包含同一個僞隨機值)
4. (2).驗證碼
5. (3).One-Time Tokens(不一樣的表單包含一個不一樣的僞隨機值)

 

DDos

1. 沒找到行之有效的方案，目前只能上雲和啓動雲盾這樣的付費服務

 

sql注入

 

主要設計模式和應用場景

一、工廠模式與抽象工廠模式：不一樣條件下建立不一樣實例 
二、單例模式：保證一個類僅有一個實例 
三、建造者模式：將一個複雜的構建過程與其具表示細節相分離，使得一樣的構建過程能夠建立不一樣的表示 
四、原型模式：經過拷貝原型建立新的對象 
五、適配器模式：使得本來因爲接口不兼容而不能一塊兒工做的那些類能夠一塊兒工做 
六、過濾器模式：使用不一樣的標準來過濾一組對象，經過邏輯運算以解耦的方式把它們鏈接起來 
七、觀察者模式：一對多的依賴關係，在觀察目標類裏有一個 ArrayList 存放觀察者們。當觀察目標對象的狀態發生改變，全部依賴於它的觀察者都將獲得通知，使這些觀察者可以自動更新（即便用推送方式） 
八、策略模式：策略對象依賴注入到context對象，context對象根據它的策略改變而改變它的相關行爲(可經過調用內部的策略對象實現相應的具體策略行爲)

 

開發框架

1. 通常框架 單一入口->路由->分發->渲染，加一些擴展性，給路由，分發和渲染加上接口或者抽象類，再方便點加上composer,再好維護點加模塊

 

redis類型，持久化類型

 

魔術方法

1. __construct()，類的構造函數
2. __destruct()，類的析構函數
3. __call()，在對象中調用一個不可訪問方法時調用
4. __callStatic()，用靜態方式中調用一個不可訪問方法時調用
5. __get()，得到一個類的成員變量時調用
6. __set()，設置一個類的成員變量時調用
7. __isset()，當對不可訪問屬性調用isset()或empty()時調用
8. __unset()，當對不可訪問屬性調用unset()時被調用。
9. __sleep()，執行serialize()時，先會調用這個函數
10. __wakeup()，執行unserialize()時，先會調用這個函數
11. __toString()，類被當成字符串時的迴應方法
12. __invoke()，調用函數的方式調用一個對象時的迴應方法
13. __set_state()，調用var_export()導出類時，此靜態方法會被調用。
14. __clone()，當對象複製完成時調用
15. __autoload()，嘗試加載未定義的類
16. __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、不支持事務安全 五、MyISAM也很難正確的備份，備份的時候一般須要鎖住整個系統的數據，這就意味着天天網站都要宕機或者沒法使用15，30，60分鐘或者更多 Innodb： 1、支持行級鎖和表級鎖，能支持更多的併發量 二、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同樣須要重建所有 七、對UTF8的支持是不須要單獨配置的

 

 

安全性方面有什麼經驗

1、把握整站的結構，避免泄露站點敏感目錄
2、使用預編譯語句，避免sql注入 3、預防XSS代碼，若是不須要使用cookie就不使用 4、限制用戶權限，預防CSRF 5、嚴格控制上傳文件類型 6、加密混淆javascript代碼，提升攻擊門檻 七、驗證碼安全性

 

 

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攻擊。