轉載於:https://zhuanlan.zhihu.com/p/...
答案並不是標準,是做者經驗之談,僅供參考php
mysql_real_escape_string須要預先鏈接數據庫,並可在第二個參數傳入數據庫鏈接(不填則使用上一個鏈接)html
二者都是對數據庫插入數據進行轉義,可是mysql_real_escape_string轉義時,會考慮數據庫鏈接的字符集。mysql
它們的用處都是用來能讓數據正常插入到數據庫中,並防止sql注入,可是並不能作到100%防止sql注入。jquery
由於客戶端編碼以及服務器端編碼不一樣,可能產生注入問題,可是其實這種場景很少見。linux
被棄用的緣由是官方再也不建議使用mysql_xx的數據庫操做方式,建議使用pdo和mysqli,由於無論從性能跟安全來看,mysqli都比mysql要好。redis
產生泄漏的緣由有好幾種:算法
(1) 頁面元素被刪除,可是綁定在該元素上的事件未被刪除;sql
(2) 閉包維持函數內局部變量(外部不可控),使其得不到釋放;shell
(3) 意外的全局變量;數據庫
(4) 引用被刪除,可是引用內的引用,還存在內存中。
從上述緣由上看,內存泄漏產生的根本緣由是引用沒法正確回收,值類型並不能引起內存泄漏。
對於每一個引用,都有本身的引用計數,當引用計數歸零或被標記清除時,js垃圾回收器會認爲該引用能夠回收了。
65535 - 1024 = 64511 個
http頭部能夠被篡改,可是隻能修改X_FORWARDED_FOR,真實ip地址(REMOTE_ADDR)很難修改(除非是路由器去修改),由於真實ip是底層會話ip地址,並且由於TCP 3次握手的存在,鏈接沒法創建,僞造的意義不大,至於UDP的話,通常是內網才使用UDP通訊。
百萬獎品在打亂後預先insert到數據庫,全部中獎操做,均只能update,不能insert。進來抽獎的用戶使用memcahe原子加鎖,實現抽獎次數自增,當抽獎次數到達3時,返回不中獎。
設置獎品機率,分三張表,都使用innodb引擎,一張存中獎記錄(預先插入一行),一張存獎品發放概況,一張存用戶抽獎狀況(uin惟一索引),大併發狀況下,利用mysql的排他鎖進行併發控制。流程以下:
begin
查詢用戶抽獎次數,加排他鎖
對用戶抽獎次數的更新/插入
鎖行查詢發放狀況
得到抽獎結果(某些獎品發完以後,動態變動機率)
更新發放表
插入中獎記錄
commit
CRC32
O(log(n)),O(1)
由於哈希表是散列的,在遇到key
>'12'這種查找條件時,不起做用,而且空間複雜度較高。
b+數根據層數決定時間複雜度,數據量多的狀況下通常4-5層,而後用二分法查找頁中的數據,時間複雜度遠小於log(n)。
使用sapi通信,sapi是php封裝的對外數據傳遞接口,一般有cgi/fastcgi/cli/apache2handler四種運行模式。
垃圾回收是指當php運行狀態結束時,好比遇到了exit/die/致命錯誤/腳本運行結束時,php須要回收運行過程當中建立的變量、資源的內存。
ZEND引擎維護了一個棧zval,每一個建立的變量和資源都會壓入這個棧中,每一個壓入的數組結構都相似:[refcount => int, is_ref => 0|1, value => union, type => string],變量被unset時,ref_count若是變成0,則被回收。
當遇到變量循環引用自身時,使用同步回收算法回收。
http://www.cnblogs.com/xesam/...
創建映射關係並緩存起來;資源並不能真正同步加載,只是返回一個回調。
先用彩虹字典查找,再嘗試暴力破解。
會發生fatal錯誤,由於繼承的方法或屬性只能維持或放大權限,不能縮小,好比protected重載爲public是可行的。
0、瀏覽器本地緩存匹配;
一、本地hosts映射對比;
二、本地dns緩存解析;
三、遠程dns解析得到服務器ip地址;
四、瀏覽器發送tcp鏈接請求包(syn);
五、請求包通過傳輸層、網絡層、數據鏈路層封裝經過網卡到達路由器;
六、路由器轉發數據包到所屬運營商服務器;
七、運營商服務器經過尋址最短路徑經過中繼節點到達指定ip地址;
八、服務器端可能存在反向代理或者負載均衡,都是直接轉發請求至上游服務器,固然也能夠制定安全防護規則直接丟棄請求包;
九、上游服務器收到鏈接請求,在自身可用的狀況下,返回(syn+ack);
十、瀏覽器校驗ack,再次發送(syn+ack);
十一、服務器校驗ack切換鏈接狀態至established,而後根據請求傳輸數據包;
十二、當transform-encoding爲chunked時,瀏覽器開始渲染頁面;
1三、四次揮手,鏈接關閉;
1四、渲染數據完成。
長鏈接機制,表示keep-alive-timeout時間內,若是鏈接沒有closed,再次傳輸數據再也不須要三次握手了。