一、Redis集羣提供瞭如下兩個好處
一、將數據自動切分(split)到多個節點
二、當集羣中的某一個節點故障時,redis還能夠繼續處理客戶端的請求。
二、集羣的方案:javascript
redis-cluster集羣,採用無中心結構,每一個節點保存數據和整個集羣狀態,每一個節點都和其餘全部節點鏈接,主要經過節點的配置,輔以redis的主歷來完成集羣。因爲這塊東西我使用得不多,因此只是平時抽時間去研究過,並無真正的在線上實現過。php
答:都是非關係型數據庫,性能都很是高,可是mongoDB和memcache、redis是不一樣的兩種類型。後二者主要用於數據的緩存,前者主要用在查詢和儲存大數據方面,是最接近數據庫的文檔型的非關係數據庫。html
這裏我主要談談memcache和redis的區別。前端
①從數據存儲位置上來分,memcache的數據存在內存中,而redis既能夠存儲在內存中,也能夠存儲的到磁盤中,達到持久化存儲的功能,memcache一旦斷電,數據所有丟失,redis能夠利用快照和AOF把數據存到磁盤中,當恢復時又從磁盤中讀取到內存中,當物理內存使用完畢後,能夠把數據寫入到磁盤中。java
②從存儲數據的類型上來分,memcache和redis存儲的方式都是鍵值對,只不過redis值的類型比較豐富,有string(字符串),hash(哈希),list(列表),set(集合)zset(有序集合),而memcache主要存儲的是字符串。node
③從架構層次來分,Redis支持master-slave(主—從)模式應用,memcache支持分佈式。mysql
④另外從存儲數據的大小上來分,Redis單個value的最大限制是1GB,memcached只能保存1MB的數據。可是Memcache在存儲100K以上的數據,性能稍微好一點。linux
⑤另外redis只支持單核,memcache能夠支持多核,固然關於redis取代memcache的說法,在通常狀況下,二者性能都很高,在大多的業務場景選擇上,redis的選擇可能更加具備優點,但也不能說能夠徹底取代,最終仍是取決於你的應用場景。nginx
答:主要有兩種方式:laravel
① 快照持久化
在redis配置文件中已經自動開啓了,
格式是:save N M
表示在N秒以內,redis至少發生M次修改則redis抓快照到磁盤。
固然咱們也能夠手動執行save或者bgsave(異步)命令來作快照
②append only file AOF持久化
總共有三種模式,如
appendfsync everysec默認的是每秒強制寫入磁盤一次
appendfsync always 每次執行寫操做的時候就強制寫入磁盤
appendfsync no 徹底取決於os,性能最好可是持久化無法保證
其中第三種模式最好。redis默認的也是採起第三種模式。
答:經常使用的主要分爲兩種,一種是innodb,一種是myisam,二者的主要區別是
①myisam不支持事務處理,而innoDB支持事務處理
②myisam 不支持外鍵,innoDB支持外鍵
③myisam支持全文檢索,而innoDB在MySQL5.6版本以後才支持全文檢索
④數據的存儲形式不同,mysiam表存放在三個文件:結構、索引、數據,innoDB存儲把結構存儲爲一個文件,索引和數據存儲爲一個文件
⑤myisam在查詢和增長數據性能更優於innoDB,innoDB在批量刪除方面性能較高。
⑥myisam支持表鎖,而innoDB支持行鎖
答:SQL注入攻擊指的是用戶或者黑客經過構建特殊的輸入做爲參數傳入咱們的Web應用程序端,而這些輸入大都是SQL語法裏的一些組合,經過執行SQL語句進而執行攻擊者所要的操做,其主要緣由是程序員沒有細緻地過濾用戶輸入的數據,導致非法數據侵入系統而形成的。所以咱們在作開發過程當中必定要預防sql注入,主要從兩方面着手:一、佔位符的方式,就是對sql語句進行預處理,而後執行sql語句
二、經過addslashes或者mysql_real_escape_string這兩個函數對用戶輸入的值進行轉義處理,把一些特殊的字符轉義掉。
答:用過,PDO類中,有個prepare方法能夠實現預處理,PDOStament類中 的excute方法能夠執行預處理,預處理的參數分爲兩種,一種是:字符串佔位符,另外一種是?佔位符,:字符串佔位符在執行預處理傳遞參數時傳入的是關聯數組,而?佔位符傳遞的是索引數組。二者不能混合使用,但通常推薦使用:字符串佔位符。
答:通常成熟的開源框架中都考慮到了數據安全這方面的東西,但有時候咱們可能會使用一些原生的SQL語句時,咱們就須要考慮本身對sql語句進行預處理。固然有時候框架中的過濾方法咱們不但願採用,好比使用文本編輯器時,咱們能夠使用本身的過濾方式。
答:mysql優化主要從如下幾個方面來實現:
①設計角度:存儲引擎的選擇,字段類型選擇,範式
②功能角度:能夠利用mysql自身的特性,如索引,查詢緩存,碎片整理,分區、分表等
③sql語句的優化方面:儘可能簡化查詢語句,能查詢字段少就儘可能少查詢字段,優化分頁語句、分組語句等。
④部署大負載架構體系:數據庫服務器單獨出來,負載大時能夠採用主從複製,讀寫分離機制進行設計
⑤從硬件上升級數據庫服務器。
答:由於訂單表存在着事務的處理,好比下了訂單,商品的庫存就要減小,這裏就涉及到了事務,因此就用到innodb。
答:首先咱們得肯定哪些sql語句須要優化,通常在一個系統中,查詢語句最多,因此咱們主要是針對查詢語句進行優化。主要採用兩種方式來肯定要優化的sql語句:
①使用慢查詢日誌,設置須要優化的sql語句的執行時間,記錄下超過該設置時間的語句,即爲須要優化的語句。
②使用profiling機制,記錄下每條sql語句的執行時間,找出執行較慢的語句,即爲須要優化的語句。
咱們主要經過給表字段添加索引的方式進行優化,加上索引後,sql語句的執行時間顯著提升了,但並非加上索引了這條sql語句就會用到索引,因此首先看執行慢的語句後面是否有加索引,咱們能夠使用explain或者desc加在要執行的sql語句前,查看是否使用到索引。有幾個地方須要注意的是:
①爲了不建議索引而形成索引文件過大,有時候咱們會使用複合索引,這時候要遵循最左原則。
②like查詢,前%不會用到索引
③若是條件中有or,則要求or的索引字段都必須有索引,不然不能用到索引。
④若是列類型是字符串,必定要在條件中將數據使用引號引用起來,不然不使用索引。
⑤優化group by 語句
⑥儘可能避免模糊匹配,這樣會致使全盤掃描
答:索引主要有:
主鍵索引:數據記錄裏面不能有null,數據內容不能重複,在一張表裏面不能有多個主鍵索引。
普通索引:使用字段關鍵字創建的索引,主要是提升查詢速度
惟一索引:字段數據是惟一的,數據內容裏面可否爲null,在一張表裏面,是能夠添加多個惟一索引。
全文索引:在比較老的版本中,只有myisam引擎支持全文索引,在innodb5.6後引擎也支持全文索引,在mysql中全文索引不支持中文。咱們通常使用sphinx集合coreseek來實現中文的全文索引。
答:左前索引主要指的是在複合索引中,給兩個或多個字段創建了複合索引後,在sql語句後的條件中,只有複合索引前面的字段在條件的前面時,該索引才起做用,好比建立了個複合索引index (a,b),在使用where或者orderby條件時,若是隻有條件b的,該索引不會生效,必須有條件a且必需要在條件b的前面該索引纔會生效。
答:我所知道的分佈式數據庫有memcache,主要是分佈式的非關係型數據庫,用於緩存處理。
分佈式是指將不一樣的業務分佈在不一樣的地方。 而集羣指的是將幾臺服務器集中在一塊兒,實現同一業務。
分佈式中的每個節點,均可以作集羣。 而集羣並不必定就是分佈式的。
舉例:就好比新浪網,訪問的人多了,他能夠作一個羣集,前面放一個響應服務器,後面幾臺服務器完成同一業務,若是有業務訪問的時候,響應服務器看哪臺服務器的負載不是很重,就將給哪一臺去完成。
而分佈式,從窄意上理解,也跟集羣差很少, 可是它的組織比較鬆散,不像集羣,有一個組織性,一臺服務器垮了,其它的服務器能夠頂上來。
memcache的應用場景
一、適用memcached的業務場景?
1)若是網站包含了訪問量很大的動態網頁,於是數據庫的負載將會很高。因爲大部分數據庫請求都是讀操做,那麼memcached能夠顯著地減少數據庫負載。
2)利用memcached能夠緩存session數據、臨時數據以減小對他們的數據庫寫操做。
4)緩存一些很小可是被頻繁訪問的文件。
5)訪問比較頻繁,安全性不高,丟失無所謂,修改比較頻繁的數據,好比一些用戶的在線狀態
2 、不適用memcached的業務場景?
1)緩存對象的大小大於1MB
memcache自己就不是爲了處理龐大的多媒體(large media)和巨大的二進制塊(streaming huge blobs)而設計的。
2)key的長度大於250字符
3)應用運行在不安全的環境中
4)業務自己須要的是持久化數據或者說須要的應該是database
(參考阿銘哥手冊)
stub_status模塊主要用於查看Nginx的一些狀態信息,例如統計nginx的訪問量,首先咱們得查看該模塊有沒有安裝,若是沒有安裝,得先安裝,安裝好後,修改nginx的配置文件,開啓該模塊,而後就能夠使用如下命令來進行統計,如:
1.根據訪問IP統計UV
awk '{print $1}' access.log|sort | uniq -c |wc -l
2.統計訪問URL統計PV
awk '{print $7}' access.log|wc -l
3.查詢訪問最頻繁的URL
awk '{print $7}' access.log|sort | uniq -c |sort -n -k 1 -r|more
4.查詢訪問最頻繁的IP
awk '{print $1}' access.log|sort | uniq -c |sort -n -k 1 -r|more
統計nginx日誌中訪問最多的100個ip及訪問次數
awk ‘{print $1}’ access.log|sort | uniq -c |sort -n -k 1 -r| head -n 100
HTTP是一個屬於應用層的面向對象的協議,因爲其簡捷、快速的方式,適用於分佈式超媒體信息系統
HTTP協議的主要特色可歸納以下:
1.支持客戶/服務器模式。
2.簡單快速:客戶向服務器請求服務時,只需傳送請求方法和路徑。請求方法經常使用 的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單,使得HTTP服務器的程序規模小,於是通訊速度很快。
3.靈活:HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加 以標記。
4.無鏈接:無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請 求,並收到客戶的應答後,即斷開鏈接。採用這種方式能夠節省傳輸時間。
5.無狀態:HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。 缺乏狀態意味着若是後續處理須要前面的信息,則它必須重傳,這樣可能致使每次 鏈接傳送的數據量增大。另外一方面,在服務器不須要先前信息時它的應答就較快。
一、cookie數據存放在客戶的瀏覽器上,session數據放在服務器上。
二、cookie不是很安全,別人能夠分析存放在本地的COOKIE並進行COOKIE欺騙
考慮到安全應當使用session。
三、session會在必定時間內保存在服務器上。當訪問增多,會比較佔用你服務器的性能
考慮到減輕服務器性能方面,應當使用COOKIE。
四、單個cookie保存的數據不能超過4K,不少瀏覽器都限制一個站點最多保存20個cookie。
五、因此我的建議:
將登錄信息等重要信息存放爲SESSION
其餘信息若是須要保留,能夠放在COOKIE中
PHP爲session的存儲提供了三種方式: 文件/ 內存/ 自定義存儲,默認是使用文件存儲.在訪問量大的網站上採用這種方式就不大合 適,由於這樣會致使大量的輸入輸出的冗餘.咱們能夠在php.ini更改配置文件或者php腳本中經過相應的函數來設置session文件的存儲類型來改變session文件的存儲形式
XSS又稱CSS,全稱Cross SiteScript(跨站腳本攻擊), XSS攻擊相似於SQL注入攻擊,是Web程序中常見的漏洞,XSS屬於被動式且用於客戶端的攻擊方式,因此容易被忽略其危害性。其原理是攻擊者向有XSS漏洞的網站中輸入(傳入)惡意的HTML代碼,當用戶瀏覽該網站時,這段HTML代碼會自動執行,從而達到攻擊的目的。如,盜取用戶Cookie信息、破壞頁面結
常見的惡意字符XSS輸入:
1. XSS 輸入一般包含 JavaScript 腳本,如彈出惡意警告框:<script>alert("XSS");</script>
2. XSS 輸入也多是 HTML 代碼段,譬如:
(1) 網頁不停地刷新 <meta http-equiv="refresh" content="0;">
(2) 嵌入其它網站的連接 <iframe src=http://xxxx width=250 height=250></iframe>
構、重定向到其它網站等。
方法:利用php htmlentities()函數
php防止XSS跨站腳本攻擊的方法:是針對非法的HTML代碼包括單雙引號等,使用htmlspecialchars()函數。
在使用htmlspecialchars()函數的時候注意第二個參數, 直接用htmlspecialchars($string)的話,第二個參數默認是ENT_COMPAT,函數默認只是轉化雙引號("),不對單引號(')作轉義。
因此,htmlspecialchars()函數更多的時候要加上第二個參數,應該這樣用: htmlspecialchars($string,ENT_QUOTES)。固然,若是須要不轉化如何的引號,用htmlspecialchars($string,ENT_NOQUOTES)。
另外,儘可能少用htmlentities(), 在所有英文的時候htmlentities()和htmlspecialchars()沒有區別,均可以達到目的。可是,中文狀況下, htmlentities()卻會轉化全部的html代碼,連同裏面的它沒法識別的中文字符也給轉化了。
htmlentities()和htmlspecialchars()這兩個函數對單引號(')之類的字符串支持很差,都不能轉化, 因此用htmlentities()和htmlspecialchars()轉化的字符串只能防止XSS攻擊,不能防止SQL注入攻擊。
全部有打印的語句如echo,print等,在打印前都要使用htmlentities()進行過濾,這樣能夠防止XSS,注意中文要寫出htmlentities($name,ENT_NOQUOTES,GB2312)。
能夠,在存儲session的文件中,生成sessionID,經過get傳參的方式將sessionID傳到要實現session共享的頁面,讀取sessionID,從而從session中獲取數據。
MongoDB是一個基於分佈式文件存儲的數據庫。由C++語言編寫。旨在爲WEB應用提供可擴展的高性能數據存儲解決方案。
3二、mongodb是非範式仍是範式
數據表示的方式有不少種,其中最重要的問題之一就是在多大程度上對數據進行範式化。範式化(normalization)是將數據分散到多個不一樣的集合,不一樣集合之間能夠相互引用數據。雖然不少文檔能夠引用某一塊數據,可是這塊數據只存儲在一個集合中。因此,若是要修改這塊數據,只需修改保存這塊數據的那一個文檔就好了。可是,MongoDB沒有提供鏈接(join)工具,因此在不一樣集合之間執行鏈接查詢須要進行屢次查詢。
反範式化(denormalization)與範式化相反:將每一個文檔所需的數據都嵌入在文檔內部。每一個文檔都擁有本身的數據副本,而不是全部文檔共同引用同一個數據副本。這意味着,若是信息發生了變化,那麼全部相關文檔都須要進行更新,可是在執行查詢時,只須要一次查詢,就能夠獲得全部數據。
決定什麼時候採用範式化什麼時候採用反範式化時比較困難的。範式化可以提升數據寫入速度,反範式化可以提升數據讀取速度。須要根據本身應用程序的十幾須要仔細權衡。
MySQL是關係型數據庫。
優點:
在不一樣的引擎上有不一樣 的存儲方式。
查詢語句是使用傳統的sql語句,擁有較爲成熟的體系,成熟度很高。
開源數據庫的份額在不斷增長,mysql的份額頁在持續增加。
缺點:
在海量數據處理的時候效率會顯著變慢。
Mongodb是非關係型數據庫(nosql ),屬於文檔型數據庫。文檔是mongoDB中數據的基本單元,相似關係數據庫的行,多個鍵值對有序地放置在一塊兒即是文檔,語法有點相似javascript面向對象的查詢語言,它是一個面向集合的,模式自由的文檔型數據庫。
存儲方式:虛擬內存+持久化。
查詢語句:是獨特的Mongodb的查詢方式。
適合場景:事件的記錄,內容管理或者博客平臺等等。
架構特色:能夠經過副本集,以及分片來實現高可用。
數據處理:數據是存儲在硬盤上的,只不過須要常常讀取的數據會被加載到內存中,將數據存儲在物理內存中,從而達到高速讀寫。
成熟度與普遍度:新興數據庫,成熟度較低,Nosql數據庫中最爲接近關係型數據庫,比較完善的DB之一,適用人羣不斷在增加。
優勢:
快速!在適量級的內存的Mongodb的性能是很是迅速的,它將熱數據存儲在物理內存中,使得熱數據的讀寫變得十分快。高擴展性,存儲的數據格式是json格式!
缺點:
不支持事務,並且開發文檔不是很徹底,完善。
Mysql和Mongodb主要應用場景(簡單瞭解敘述下便可)
1.若是須要將mongodb做爲後端db來代替mysql使用,即這裏mysql與mongodb 屬於平行級別,那麼,這樣的使用可能有如下幾種狀況的考量: (1)mongodb所負責部分以文檔形式存儲,可以有較好的代碼親和性,json格式的直接寫入方便。(如日誌之類) (2)從data models設計階段就將原子性考慮於其中,無需事務之類的輔助。開發用如nodejs之類的語言來進行開發,對開發比較方便。 (3)mongodb自己的failover機制,無需使用如MHA之類的方式實現。
2.將mongodb做爲相似redis ,memcache來作緩存db,爲mysql提供服務,或是後端日誌收集分析。 考慮到mongodb屬於nosql型數據庫,sql語句與數據結構不如mysql那麼親和 ,也會有不少時候將mongodb作爲輔助mysql而使用的類redis memcache 之類的緩存db來使用。 亦或是僅做日誌收集分析。
PHP 中的 array_count_values() 函數能夠實現 array_count_values() 函數用於統計數組中全部值出現的次數。 本函數返回一個數組,其元素的鍵名是原數組的值,鍵值是該值在原數組中出現的次數。
主要從原理方面來講:重點介紹冒泡排序和選擇排序
· // 冒泡排序
function BubbleSort($arr) {
// 得到數組總長度
$num = count($arr);
// 正向遍歷數組
for ($i = 1; $i < $num; $i++) {
// 反向遍歷
for ($j = $num - 1; $j >= $i ; $j--) {
// 相鄰兩個數比較
if ($arr[$j] < $arr[$j-1]) {
// 暫存較小的數
$iTemp = $arr[$j-1];
// 把較大的放前面
$arr[$j-1] = $arr[$j];
// 較小的放後面
$arr[$j] = $iTemp;
}
}
}
return $arr;
}
· // 交換法排序
function ExchangeSort($arr){
$num = count($arr);
// 遍歷數組
for ($i = 0;$i < $num - 1; $i++) {
// 得到當前索引的下一個索引
for ($j = $i + 1; $j < $num; $j++) {
// 比較相鄰兩個的值大小
if ($arr[$j] < $arr[$i]) {
// 暫存較小的數
$iTemp = $arr[$i];
// 把較大的放前面
$arr[$i] = $arr[$j];
// 較小的放後面
$arr[$j] = $iTemp;
}
}
}
return $arr;
}
· // 選擇法排序
function SelectSort($arr) {
// 得到數組總長度
$num = count($arr);
// 遍歷數組
for ($i = 0;$i < $num-1; $i++) {
// 暫存當前值
$iTemp = $arr[$i];
// 暫存當前位置
$iPos = $i;
// 遍歷當前位置之後的數據
for ($j = $i + 1;$j < $num; $j++){
// 若是有小於當前值的
if ($arr[$j] < $iTemp) {
// 暫存最小值
$iTemp = $arr[$j];
// 暫存位置
$iPos = $j;
}
}
// 把當前值放到算好的位置
$arr[$iPos] = $arr[$i];
// 把當前值換成算好的值
$arr[$i] = $iTemp;
}
return $arr;
}
· // 插入法排序
function InsertSort($arr){
$num = count($arr);
// 遍歷數組
for ($i = 1;$i < $num; $i++) {
// 得到當前值
$iTemp = $arr[$i];
// 得到當前值的前一個位置
$iPos = $i - 1;
// 若是當前值小於前一個值切未到數組開始位置
while (($iPos >= 0) && ($iTemp < $arr[$iPos])) {
// 把前一個的值日後放一位
$arr[$iPos + 1] = $arr[$iPos];
// 位置遞減
$iPos--;
}
$arr[$iPos+1] = $iTemp;
}
return $arr;
}
· // 快速排序
function QuickSort($arr){
$num = count($arr);
$l = $r = 0;
$left = $right = array();
// 從索引的第二個開始遍歷數組
for ($i = 1;$i < $num; $i++) {
// 若是值小於索引1
if ($arr[$i] < $arr[0]) {
// 裝入左索引數組(小於索引1的數據)
$left[] = $arr[$i];
$l++;
} else {
// 不然裝入右索引中(大於索引1的數據)
$right[] = $arr[$i];
$r++; //
}
}
// 若是左索引有值 則對左索引排序
if($l > 1) {
$left = QuickSort($left);
}
// 排序後的數組
$new_arr = $left;
// 將當前數組第一個放到最後
$new_arr[] = $arr[0];
// 若是又索引有值 則對右索引排序
if ($r > 1) {
$right = QuickSort($right);
}
// 根據右索引的長度再次增長數據
for($i = 0;$i < $r; $i++) {
$new_arr[] = $right[$i];
}
return $new_arr;
}
在PHP中,我主要使用瞭如下兩種設計模式
一、單例模式
單例模式顧名思義,就是隻有一個實例。做爲對象的建立模式, 單例模式確保某一個類只有一個實例,並且自行實例化並向整個系統提供這個實例。
單例模式的要點有三個:
一是某個類只能有一個實例;
二是它必須自行建立這個實例;
三是它必須自行向整個系統提供這個實例。
典型的表明如框架中的基類對象。
二、簡單工廠模式
①抽象基類:類中定義抽象一些方法,用以在子類中實現
②繼承自抽象基類的子類:實現基類中的抽象方法
③工廠類:用以實例化全部相對應的子類
這種咱們使用最多見,基本全部的MVC框架中都是這樣產生的。
在開發過程當中,我主要使用過了這麼幾種框架。thinkPHP框架、CI框架,laravel框架和yii框架。我接觸到的第一個框架是TP框架,我簡單的說下我對這幾個框架的見解:
ThinkPHP框架
優勢:
TP借鑑了Java思想,基於PHP5,充分利用了PHP5的特性,部署簡單隻需一個入口文件,一切搞定,簡單高效,中文文檔齊全,入門超級簡單。自帶模板引擎,具備獨特的數據驗證和自動填充功能,框架更新速度比較迅速。
缺點:一個Model中能夠操做多個表,但TP只能一個。
TP默認初始化了不少配置,使用起來很方便,但天然也會影響效率。可是把一些加載配置的時間拿去研究算法,這些小影響近乎能夠忽略了。
CodeIgniter框架
優勢:
配置簡單,上手很快,所有的配置使用PHP腳原本配置,沒有使用不少太複雜的設計模式,執行性能和代碼可讀性上都不錯,執行效率比較高,具備基本的MVC功能. 快速簡潔,代碼量少,框架簡單,容易上手,自帶了不少簡單好用的library,框架適合中小型項目,大型項目也不是不能夠,只是擴展能力稍差。
缺點:
1. 把Model層簡單的理解爲數據庫操做
2. PHP框架略顯簡單,只可以知足小型應用,略微不太可以知足中型應用須要
laravel框架(目前最新的是5.3,要求PHP版本較高5.6)
優勢:
1.Laravel注重代碼的模塊化和可擴展性。
2.artisan: 命令行工具,不少手動的工做都自動了
3.可繼承的模版,簡化view的開發和管理
Laravel一直是PHP開發者最受歡迎的PHP框架。這是一個年輕的框架,可是擁有優雅的語法,可簡單快速開發你的應用。它擁有大多數常見的功能,如:路由,身份驗證,會話,隊列和緩存。
缺點:
laravel的中英文文檔比較少 demo也比較少 有時候一個功能要試很久 甚至要看源碼
YII框架(目前是2.0版本)
優勢:
一、快速,敏捷,不拖沓,給程序員飛翔的能力;
二、有gii功能!(建立控制器,model層,crud等操做);
三、具備高度的可重用性和可擴展性,是純粹的面向對象的。開發速度快,完備的文檔,可重用性可高擴展,是最高效的開發框架之一。
缺點:
一、對Model層的指導和考慮較少
二、文檔實例較少
三、英文太多
四、要求PHP技術精通,OOP編程要熟練!
五、要求會bootstrap
我使用過的版本控制工具備兩種:早期的時候使用的是SVN,如今主要使用git,我就我我的的觀點,簡單的說下二者的區別:
1. Git是分佈式的,SVN是集中式的,好處是跟其餘同事不會有太多的衝突,本身寫的代碼放在本身電腦上,一段時間後再提交、合併,也能夠不用聯網在本地提交;
2. Git下載下來後,在本地沒必要聯網就能夠看到全部的log,很方便學習,SVN卻須要聯網;
3. Git鼓勵分Branch(分支),而SVN,說實話,我用Branch的次數還挺少的,SVN自帶的Branch merge我還真沒用過,有merge時用的是Beyond Compare工具合併後再Commit的;
4. SVN在Commit前,咱們都建議是先Update一下,跟本地的代碼編譯沒問題,並確保開發的功能正常後再提交
SVN 的主要功能
SVN屬於集中化的版本控制系統,有個不太精確的比喻:SVN = 版本控制+ 備份服務器
SVN使用起來有點像是檔案倉庫的感受,支持並行讀寫文件,支持代碼的版本化管理,功能包括取出、導入、更新、分支、更名、還原、合併等。
功能有許多我就不一一列了,SVN大都採用圖形界面操做,直觀,上手快。
Git的主要功能
Git是一個分佈式版本控制系統,操做命令包括:clone,pull,push,branch ,merge ,rebas,Git擅長的是程序代碼的版本化管理。
SVN 的優缺點
SVN對中文支持好,操做簡單,使用沒有難度,美工人員,產品人員,測試人員,實施人員均可輕鬆上手。使用界面統一,功能完善,操做方便。
Git的優缺點
對程序源代碼進行差別化的版本管理,代碼庫佔極少的空間。易於代碼的分支化管理。不支持中文,圖形界面支持差,使用難度大。不易推廣。
SVN 和 Git 哪一個更適用於項目管理?
SVN更適用於項目管理, Git僅適用於代碼管理。
一個研發隊伍的成員正常包括:需求分析、設計、美工、程序員、測試、實施、運維,每一個成員在工做中都有產出物, 包括了文檔、設計代碼、程序代碼,這些都須要按項目集中進行管理的。SVN能清楚的按目錄進行分類管理, 使項目組的管理處於有序高效的狀態。
如今愈來愈多人使用git作爲版本控制工具,我之前的公司也是使用git.
三私一公。
class Example
{
//保存例實例在此屬性中
private static $_instance;
//構造函數聲明爲private,防止直接建立對象
private function __construct()
{
echo 'I am Construceted';
}
//單例方法
public static function singleton()
{
if(!isset(self::$_instance))
{
$c=__CLASS__;
self::$_instance=new $c;
}
return self::$_instance;
}
//阻止用戶複製對象實例
public function __clone()
{
trigger_error('Clone is not allow' ,E_USER_ERROR);
}
function test()
{
echo("test");
}
}
// 這個寫法會出錯,由於構造方法被聲明爲private
$test = new Example;
// 下面將獲得Example類的單例對象
$test = Example::singleton();
$test->test();
// 複製對象將致使一個E_USER_ERROR.
$test_clone = clone $test;
?>
也即非關係型數據庫和關係型數據庫。
目前世界上主流的存儲系統大部分仍是採用了關係型數據庫,其主要有一下優勢:
1.事務處理—保持數據的一致性;
2.因爲以標準化爲前提,數據更新的開銷很小(相同的字段基本上只有一處);
3.能夠進行Join等複雜查詢。
nosql在優點方面,主要體如今下面這三點:
1. 簡單的擴展:典型例子是Cassandra,因爲其架構是相似於經典的P2P,因此能經過輕鬆地添加新的節點來擴展這個集羣;
2. 快速的讀寫:主要例子有Redis,因爲其邏輯簡單,並且純內存操做,使得其性能很是出色,單節點每秒能夠處理超過10萬次讀寫操做;
3. 低廉的成本:這是大多數分佈式數據庫共有的特色,由於主要都是開源軟件,沒有昂貴的License成本;
4.
但瑕不掩瑜,NoSQL數據庫還存在着不少的不足,常見主要有下面這幾個:
1. 不提供對SQL的支持:若是不支持SQL這樣的工業標準,將會對用戶產生必定的學習和應用遷移成本;
2. 支持的特性不夠豐富:現有產品所提供的功能都比較有限,大多數NoSQL數據庫都不支持事務,也不像 SQL Server和Oracle那樣能提供各類附加功能,好比BI和報表等;
3. 現有產品的不夠成熟:大多數產品都還處於初創期,和關係型數據庫幾十年的完善不可同日而語;
雖然都是實例化模型對象,二者仍是有區別的
D和M的區別主要在於
M方法不須要建立模型類文件,M方法不會讀取模型類,因此默認狀況下自動驗證是無效的,可是能夠經過動態賦值的方式實現
而D方法必須有建立模型類。
咱們能夠用下面兩種方法去建立一個數據表的映射對象
第一種:$Test = D(‘Test’)
第二種:$Test = new Model(‘Test’)
雖然這兩種均可以對數據進行select,insert,delete,udpate操做,在
數據驗證上有很大的不一樣,
用第一種方式實例一個模型就會有數據檢查功能,若是 title 沒有填寫的話就會提示 「請輸入標題」 (這個是tp提供的一個自動驗證功能,固然也須要在相應的model中定義好驗證條件);
若是用第二種就沒有了這個數據驗證功能,須要手動驗證。
D函數實例化的是你當前項目的Lib/Model下面的模塊。
若是該模塊不存在的話,直接返回實例化Model的對象(意義就與M()函數相同)。
而M只返回,實例化Model的對象。它的$name參數做爲數據庫的表名來處理對數據庫的操做。
提升訪問速度。從硬件,最好從網站程序等等方面考慮。我給出如下幾種方案:
1.儘可能使用靜態頁,不要老使用動態信息調用。很是容易出問題
2.圖片內容與網站數據儘可能放在同一個服務器或者機房內。大量外鏈圖片是會有問題的
3.一次又一次,一遍又一遍的分析流量走向,而後縮短瀏覽者瀏覽距離,舉個例子,瀏覽者若是如今在你網站看一個新聞須要點5次鼠標,你就要縮短這個點擊數。
4.一次又一次,一遍又一遍的分析,修改你的網站數據庫結構,使其更加簡潔。
5.提升網站的安防能力
6.買個好服務器,託管在一個好的機房!
第一:確認服務器硬件是否足夠支持當前的流量。
普通的P4服務器通常最多能支持天天10萬獨立IP,若是訪問量比這個還要大,那麼必須首先配置一臺更高性能的專用服務器才能解決問題,不然怎麼優化都不可能完全解決性能問題。
第二:優化數據庫訪問
前臺實現徹底的靜態化固然最好,能夠徹底不用訪問數據庫,不過對於頻繁更新的網站,靜態化每每不能知足某些功能。
緩存就是另外一個解決方案,就是將動態數據存儲到緩存文件中,動態網頁直接調用這些文件,而沒必要再訪問數據庫,技術若是確實沒法避免對數據庫的訪問,那麼能夠嘗試優化數據庫的查詢SQL.避免使用Select * from這樣的語句,每次查詢只返回本身須要的結果,避免短期內的大量SQL查詢。最好在相同字段進行比較操做,在創建好的索引字段上儘可能減小函數操做,若是要作到極致的話須要代碼的優化;
第三,禁止外部的盜鏈。
外部網站的或者文件盜鏈每每會帶來大量的負載壓力,所以應該嚴格限制外部對於自身的圖片或者文件盜鏈,好在目前能夠簡單地經過refer來控制盜鏈,本身就能夠經過配置來禁止盜鏈。固然,僞造refer也能夠經過來實現盜鏈,不過目前蓄意僞造refer盜鏈的還很少,能夠先不去考慮,或者使用非技術手段來解決,好比在圖片上增長水印。
第四,控制大文件的下載。
大文件的下載會佔用很大的流量,而且對於非SCSI硬盤來講,大量文件下載會消耗CPU,使得網站響應能力降低。所以,儘可能不要提供超過2M的大文件下載,若是須要提供,建議將大文件放在另一臺服務器上。
第五,使用不一樣主機分流主要流量
將文件放在不一樣的主機上,提供不一樣的鏡像供用戶下載。好比若是以爲RSS文件佔用流量大,那麼使用FeedBurner或者FeedSky等服務將RSS輸出放在其餘主機上,這樣別人訪問的流量壓力就大多集中在FeedBurner的主機上,RSS就不佔用太多資源了。
第六,使用流量分析統計軟件。
在網站上一個流量分析統計軟件,能夠即時知道哪些地方耗費了大量流量,哪些頁面須要再進行優化,所以,解決流量問題還須要進行精確的統計分析才能夠。我推薦使用的流量分析統計軟件是Analytics(Google分析)。
1、數據緩存
這裏所說的數據緩存是指數據庫查詢緩存,每次訪問頁面的時候,都會先檢測相應的緩存數據是否存在,若是不存在,就鏈接數據庫,獲得數據,並把查詢結果序列化後保存到文件中,之後一樣的查詢結果就直接從緩存表或文件中得到。
用的最廣的例子看Discuz的搜索功能,把結果ID緩存到一個表中,下次搜索相同關鍵字時先搜索緩存表。
舉個經常使用的方法,多表關聯的時候,把附表中的內容生成數組保存到主表的一個字段中,須要的時候數組分解一下,這樣的好處是隻讀一個表,壞處就是兩個數據同步會多很多步驟,數據庫永遠是瓶頸,用硬盤換速度,是這個的關鍵點。
2、頁面緩存
每次訪問頁面的時候,都會先檢測相應的緩存頁面文件是否存在,若是不存在,就鏈接數據庫,獲得數據,顯示頁面並同時生成緩存頁面文件,這樣下次訪問的時候頁面文件就發揮做用了。(模板引擎和網上常見的一些緩存類一般有此功能)。
3、時間觸發緩存
檢查文件是否存在而且時間戳小於設置的過時時間,若是文件修改的時間戳比當前時間戳減去過時時間戳大,那麼就用緩存,不然更新緩存。
4、內容觸發緩存
當插入數據或更新數據時,強制更新緩存。
5、靜態緩存
這裏所說的靜態緩存是指靜態化,直接生成HTML或XML等文本文件,有更新的時候重生成一次,適合於不太變化的頁面,這就不說了。
6、內存緩存
Memcached是高性能的,分佈式的內存對象緩存系統,用於在動態應用中減小數據庫負載,提高訪問速度。redis 也能夠作到。
一、單例模式 二、工廠模式 三、觀察者模式 四、命令鏈模式 五、策略模式
單例模式:
一個類在整個應用中,只有一個對象實例的設計模式
類必須自行建立這個實例
必須自行向整個系統提供這個實例
三私:私有靜態成員變量、構造函數、克隆函數
一公:公共的靜態方法
二、工廠模式
能夠根據輸入的參數或者應用程序配置的不一樣一建立一種專門用來實例化並返回其它類的實例的類
三、觀察者模式
觀察者模式提供了組件之間緊密耦合的另外一種方法。
該模式:一個對象經過添加一個方法(該方法容許另外一個對象,即觀察者註冊本身)全自己變得可觀察。當可觀察的對象更改時,它會將消息發送到已註冊的觀察者。這些觀察者使用該信息執行的操做與可觀察的對象無關。
四、命令鏈模式:
以鬆散耦合主題爲基礎,發送消息、命令和請求,或經過一組處理程序發送任意內容。每一個處理程序都會自行判斷本身可否處理請求,若是能夠,該請求被處理,進程中止。
五、策略模式:
此算法是從複雜類提取的,於是能夠方便地替換。
事務是做爲一個邏輯單元執行的一系列操做,一個邏輯工做單元必須有四個屬性,稱爲 ACID(原子性、一致性、隔離性和持久性)屬性,只有這樣才能成爲一個事務:
原子性
事務必須是原子工做單元;對於其數據修改,要麼全都執行,要麼全都不執行。
一致性
事務在完成時,必須使全部的數據都保持一致狀態。在相關數據庫中,全部規則都必須應用於事務的修改,以保持全部數據的完整性。
事務結束時,全部的內部數據結構(如 B 樹索引或雙向鏈表)都必須是正確的。
隔離性
由併發事務所做的修改必須與任何其它併發事務所做的修改隔離。事務查看數據時數據所處的狀態,要麼是另外一併發事務修改它以前的狀態,
要麼是另外一事務修改它以後的狀態,事務不會查看中間狀態的數據。這稱爲可串行性,由於它可以從新裝載起始數據,
而且重播一系列事務,以使數據結束時的狀態與原始事務執行的狀態相同。
持久性
事務完成以後,它對於系統的影響是永久性的。該修改即便出現系統故障也將一直保持。
begin 開始一個事務
rollback事務回滾
commit事務確認
事務處理在各類管理系統中都有着普遍的應用,好比人員管理系統,不少同步數據庫操做大都須要用到事務處理。好比說,在人員管理系統中,你刪除一我的員,你即須要刪除人員的基本資料,也要刪除和該人員相關的信息,如信箱,文章等等,這樣,這些數據庫操做語句就構成一個事務!
好比手機充值過程,支付寶金額減小,相應的手機話費增長,只要有一個操做不成功,則另一個操做也不會成功
require函數一般放在PHP程序的最前面,在PHP程序執行以前,就會先讀取require指定引入的文件,使它變成PHP程序網頁的一部分。
include函數通常是放在流程控制的處理部分中。PHP程序在讀到include的文件時,纔將它讀進來,這種方式能夠把程序執行時的流程簡單化。
他們兩個的用途是同樣的,不必定非要哪一個放在最前面哪一個放在中間,他們最根本的區別在於錯誤處理的方式不同。
require一個文件存在錯誤的話,那麼程序就會中斷執行,並顯示致命錯誤
而include一個文件存在錯誤的話,那麼程序不會中斷,會繼續執行,並顯示一個警告的錯誤
其它區別:include有返回值,而require沒有。
索引就是相似書的目錄,提升檢索數據的效率。
索引是系統按照某個具體的算法(哈希,散列,二叉樹),將數據從所有數據裏進行提取,維護成一個索引文件,而後系統在進行數據查詢的時候,發現若是查詢條件恰好知足索引條件,就能夠從索引文件中快速的定位的數據所在位置。
mysql中有如下幾種索引:
主鍵索引(primary key效率最高的索引)
惟一索引(unique key):不爲空的狀況下效率最高
普通索引(index)對數據沒有要求,文件很大,效率比較低
全文索引(fulltext),對整個文章內部進行關鍵字索引(mysql5.5之後InnoDB支持全文索引)
英文的全文索引很簡單:英文單詞默認是用空格分離的
中文的全文索引很難:中文的詞組成很麻煩,須要利用分詞工具(sphinx)
索引能夠在建立表的同時建立索引,也能夠在修改表結構時添加索引,索引主要是加在常常作爲查詢條件的字段上,能夠使用相應的手段來檢測所執行的sql語句中是否使用到了索引。
\ 將下一個字符標記爲一個特殊字符、或一個原義字符、或一個向後引用、或一個八進制轉義符。例如,’n’ 匹配字符 「n」。’\n’ 匹配一個換行符。序列 ‘\\’ 匹配 「\」 而 「\(」 則匹配 「(」。
^ 匹配輸入字符串的開始位置。若是設置了 RegExp 對象的 Multiline 屬性,^ 也匹配 ‘\n’ 或 ‘\r’ 以後的位置。
$ 匹配輸入字符串的結束位置。若是設置了RegExp 對象的 Multiline 屬性,$ 也匹配 ‘\n’ 或 ‘\r’ 以前的位置。
* 匹配前面的子表達式零次或屢次。例如,zo* 能匹配 「z」 以及 「zoo」。* 等價於{0,}。
+ 匹配前面的子表達式一次或屢次。例如,’zo+’ 能匹配 「zo」 以及 「zoo」,但不能匹配 「z」。+ 等價於 {1,}。
? 匹配前面的子表達式零次或一次。例如,」do(es)?」 能夠匹配 「do」 或 「does」 中的」do」 。? 等價於 {0,1}。
{n} n 是一個非負整數。匹配肯定的 n 次。
{n,} n 是一個非負整數。至少匹配n 次。
{n,m} m 和 n 均爲非負整數,其中n <= m。最少匹配 n 次且最多匹配 m 次。
. 匹配除 「\n」 以外的任何單個字符。要匹配包括 ‘\n’ 在內的任何字符,請使用象 ‘[.\n]’ 的模式。
x|y 匹配 x 或 y。
[xyz] 字符集合。匹配所包含的任意一個字符。例如, ‘[abc]’ 能夠匹配 「plain」 中的 ‘a’。
[^xyz] 負值字符集合。匹配未包含的任意字符。例如, ‘[^abc]’ 能夠匹配 「plain」 中的’p'。
[a-z] 字符範圍。匹配指定範圍內的任意字符。例如,’[a-z]’ 能夠匹配 ‘a’ 到 ‘z’ 範圍內的任意小寫字母字符。
[^a-z] 負值字符範圍。匹配任何不在指定範圍內的任意字符。例如,’[^a-z]’ 能夠匹配任何不在 ‘a’ 到 ‘z’ 範圍內的任意字符。
\b 匹配一個單詞邊界,也就是指單詞和空格間的位置。例如, ‘er\b’ 能夠匹配」never」 中的 ‘er’,但不能匹配 「verb」 中的 ‘er’。
\d 匹配一個數字字符。等價於 [0-9]。
\D 匹配一個非數字字符。等價於 [^0-9]。
\f 匹配一個換頁符。等價於 \x0c 和 \cL。
\n 匹配一個換行符。等價於 \x0a 和 \cJ。
\r 匹配一個回車符。等價於 \x0d 和 \cM。
\s 匹配任何空白字符,包括空格、製表符、換頁符等等。等價於 [ \f\n\r\t\v]。
\S 匹配任何非空白字符。等價於 [^ \f\n\r\t\v]。
\t 匹配一個製表符。等價於 \x09 和 \cI。
\v 匹配一個垂直製表符。等價於 \x0b 和 \cK。
\w 匹配包括下劃線的任何單詞字符。等價於’[A-Za-z0-9_]’。
\W 匹配任何非單詞字符。等價於 ‘[^A-Za-z0-9_]’。
四種標量類型:
boolean (布爾型):這是最簡單的類型,只有兩種取值,能夠爲 TRUE/true 或 FALSE/false ,不區分大小寫。詳細請查看:PHP布爾類型(boolean)
integer (整型):在32 位操做系統中它的有效範圍是:-2 147 483 648~+2 147 483 647。整型值能夠使用十進制,十六進制或八進制表示,前面能夠加上可選的符號(- 或者 +)。八進制表示數字前必須加上 0(零),十六進制表示數字前必須加上 0x。
float (浮點型, 也稱做 double)
string (字符串):字符型變量不一樣於其餘編程語言有字符與字符串之分,在PHP 中,統一使用字符型變量來定義字符或者字符串。
兩種複合類型:
array (數組):數組型變量是一種比較特殊的變量類型,將在後續章節中詳細說明。
object (對象):對象也是一種特殊的數據類型。要建立object變量,請使用 new 關鍵字。詳細請查看:PHP對象類型(object)
最後是兩種特殊類型:
resource(資源):源是一種特殊變量,保存了到外部資源的一個引用。資源是經過專門的函數來創建和使用的。詳情請查看:PHP資源類型(resource)
NULL(NULL):表示一個變量沒有值。NULL 類型惟一可能的值就是 NULL。
搶購、秒殺是現在很常見的一個應用場景,主要須要解決的問題有兩個:
1 高併發對數據庫產生的壓力
2 競爭狀態下如何解決庫存的正確減小("超賣"問題)
對於第一個問題,已經很容易想到用緩存來處理搶購,避免直接操做數據庫,例如使用Redis。第二個問題,咱們能夠使用redis隊列來完成,把要秒殺的商品放入到隊列中,由於pop操做是原子的,即便有不少用戶同時到達,也是依次執行,文件鎖和事務在高併發下性能降低很快,固然還要考慮其餘方面的東西,好比搶購頁面作成靜態的,經過ajax調用接口,其中也可能會出現一個用戶搶屢次的狀況,這時候須要再加上一個排隊隊列和搶購結果隊列及庫存隊列。高併發狀況下,將用戶進入排隊隊列,用一個線程循環處理從排隊隊列取出一個用戶,判斷用戶是否已在搶購結果隊列,若是在,則已搶購,不然未搶購,庫存減1,寫數據庫,將用戶入結果隊列。
購物車至關於現實中超市的購物車,不一樣的是一個是實體車,一個是虛擬車而已。用戶能夠在購物網站的不一樣頁面之間跳轉,以選購本身喜好的商品,點擊購買時,該商品就自動保存到你的購物車中,重複選購後,最後將選中的全部商品放在購物車中統一到付款臺結帳,這也是儘可能讓客戶體驗到現實生活中購物的感受。服務器經過追蹤每一個用戶的行動,以保證在結帳時每件商品都物有其主。
主要涉及如下幾點:
一、把商品添加到購物車,即訂購
二、 刪除購物車中已定購的商品
三、 修改購物車中某一本圖書的訂購數量
四、 清空購物車
五、 顯示購物車中商品清單及數量、價格
實現購物車的關鍵在於服務器識別每個用戶並維持與他們的聯繫。可是HTTP協議是一種「無狀態(Stateless)」的協議,於是服務器不能記住是誰在購買商品,當把商品加入購物車時,服務器也不知道購物車裏原先有些什麼,使得用戶在不一樣頁面間跳轉時購物車沒法「隨身攜帶」,這都給購物車的實現形成了必定的困難。
目前購物車的實現主要是經過cookie、session或結合數據庫的方式。下面分析一下它們的機制及做用。
1. cookie
cookie是由服務器產生,存儲在客戶端的一段信息。它定義了一種Web服務器在客戶端存儲和返回信息的機制,cookie文件它包含域、路徑、生存期、和由服務器設置的變量值等內容。當用戶之後訪問同一個Web服務器時,瀏覽器會把cookie原樣發送給服務器。經過讓服務器讀取原先保存到客戶端的信息,網站可以爲瀏覽者提供一系列的方便,例如在線交易過程當中標識用戶身份、安全要求不高的場合避免用戶重複輸入名字和密碼、門戶網站的主頁定製、有針對性地投放廣告等等。利用cookie的特性,大大擴展了WEB應用程序的功能,不只能夠創建服務器與客戶機的聯繫,由於cookie能夠由服務器定製,所以還能夠將購物信息生成cookie值存放在客戶端,從而實現購物車的功能。用基於cookie的方式實現服務器與瀏覽器之間的會話或購物車,有如下特色:
一、 cookie存儲在客戶端,且佔用不多的資源,瀏覽器容許存放300個cookie,每一個cookie的大小爲4KB,足以知足購物車的要求,同時也減輕了服務器的負荷;
二、 cookie爲瀏覽器所內置,使用方便。即便用戶不當心關閉了瀏覽器窗口,只要在cookie定義的有效期內,購物車中的信息也不會丟失;
三、 cookie不是可執行文件,因此不會以任何方式執行,所以也不會帶來病毒或攻擊用戶的系統;
四、 基於cookie的購物車要求用戶瀏覽器必須支持並設置爲啓用cookie,不然購物車則失效;
五、 存在着關於cookie侵犯訪問者隱私權的爭論,所以有些用戶會禁止本機的cookie功能。
2. session
session是實現購物車的另外一種方法。session提供了能夠保存和跟蹤用戶的狀態信息的功能,使當前用戶在session中定義的變量和對象能在頁面之間共享,可是不能爲應用中其餘用戶所訪問,它與cookie最重大的區別是,session將用戶在會話期間的私有信息存儲在服務器端,提升了安全性。在服務器生成session後,客戶端會生成一個sessionid識別號保存在客戶端,以保持和服務器的同步。這個sessionid是隻讀的,若是客戶端禁止cookie功能,session會經過在URL中附加參數,或隱含在表單中提交等其餘方式在頁面間傳送。所以利用session實施對用戶的管理則更爲安全、有效。
一樣,利用session也能實現購物車,這種方式的特色是:
一、 session用新的機制保持與客戶端的同步,不依賴於客戶端設置;
二、 與cookie相比,session是存儲在服務器端的信息,所以顯得更爲安全,所以可將身份標示,購物等信息存儲在session中;
三、session會佔用服務器資源,加大服務器端的負載,尤爲當併發用戶不少時,會生成大量的session,影響服務器的性能;
四、由於session存儲的信息更敏感,並且是以文件形式保存在服務器中,所以仍然存在着安全隱患。
3. 結合數據庫的方式
這也是目前較廣泛的模式,在這種方式中,數據庫承擔着存儲購物信息的做用,session或cookie則用來跟蹤用戶。這種方式具備如下特色:
一、 數據庫與cookie分別負責記錄數據和維持會話,能發揮各自的優點,使安全性和服務器性能都獲得了提升;
二、每個購物的行爲,都要直接創建與數據庫的鏈接,直至對錶的操做完成後,鏈接才釋放。當併發用戶不少時,會影響數據庫的性能,所以,這對數據庫的性能提出了更高的要求;
三、使cookie維持會話有賴客戶端的支持。
各類方式的選擇:
雖然cookie可用來實現購物車,但必須得到瀏覽器的支持,再加上它是存儲在客戶端的信息,極易被獲取,因此這也限制了它存儲更多,更重要的信息。因此通常cookie只用來維持與服務器的會話,例如國內最大的當當網絡書店就是用cookie保持與客戶的聯繫,可是這種方式最大的缺點是若是客戶端不支持cookie就會使購物車失效。
Session 能很好地與交易雙方保持會話,能夠忽視客戶端的設置。在購物車技術中獲得了普遍的應用。但session的文件屬性使其仍然留有安全隱患。
結合數據庫的方式雖然在必定程度上解決了上述的問題,但從上面的例子能夠看出:在這種購物流程中涉及到對數據庫表的頻繁操做,尤爲是用戶每選購一次商品,都要與數據庫進行鏈接,當用戶不少的時候就加大了服務器與數據庫的負荷。
一般使用一個list來實現隊列操做,這樣有一個小限制,因此的任務統一都是先進先出,若是想優先處理某個任務就不太好處理了,這就須要讓隊列有優先級的概念,咱們就能夠優先處理高級別的任務,實現方式有如下幾種方式:
1)單一列表實現:隊列正常的操做是 左進右出(lpush,rpop)爲了先處理高優先級任務,在遇到高級別任務時,能夠直接插隊,直接放入隊列頭部(rpush),這樣,從隊列頭部(右側)獲取任務時,取到的就是高優先級的任務(rpop)
2)使用兩個隊列,一個普通隊列,一個高級隊列,針對任務的級別放入不一樣的隊列,獲取任務時也很簡單,redis的BRPOP命令能夠按順序從多個隊列中取值,BRPOP會按照給出的 key 順序查看,並在找到的第一個非空 list 的尾部彈出一個元素,redis> BRPOP list1 list2 0
list1 作爲高優先級任務隊列
list2 作爲普通任務隊列
這樣就實現了先處理高優先級任務,當沒有高優先級任務時,就去獲取普通任務
方式1最簡單,但實際應用比較侷限,方式3能夠實現複雜優先級,但實現比較複雜,不利於維護
方式2是推薦用法,實際應用最爲合適
在我負責的B2B電商項目中,當時我負責的是訂單模塊,因爲客戶一次選擇了多家商戶的商品,最終生成了一個訂單,這樣咱們平臺在給商戶結算時出現了不知道這比費用應該給哪一個商戶,這時候咱們小組通過討論,須要涉及到訂單拆分,也就是說用戶點擊支付後,若是有多件商品,而且不是同一家店鋪那麼 就要用到訂單的拆分,好比若是有兩件商品,而且不是同一店鋪 就在原來的訂單號下 在生成兩個子訂單號 並修改訂單表中兩件商品的訂單號。最終實現了商品的分配管理,解決了咱們的難題。
我以爲在開發過程當中,遇到的難題無非是兩個,一個是技術層次的,我認爲,只要你有恆心,有熱心,沒有以爲不了的難題。另外一個就是溝通問題,在任何地方任什麼時候候溝通都是最重要的,尤爲是咱們作開發的,不溝通好,會影響整個項目的進度,我本人是個很是還溝通的人,因此這點上也沒多大問題。
判斷用戶有沒有登陸,在沒有登陸的狀況下,不容許下單。登錄後,可進行下單
並生成惟一的訂單號,此時訂單的狀態爲未支付。
分爲普通登陸和第三方登陸 這邊主要說一下第三方登陸吧,第三方登錄主要使用的是author協議,我就以QQ的第三方登錄爲例來進行說明:當用戶在咱們的站點請求QQ的第三方登錄時,咱們站點會引導用戶跳轉到QQ的登錄受權界面, 當用戶輸入QQ和密碼成功登陸之後會自動跳回到咱們站點設置好的回調頁面,並附帶一個code參數,接着你使用code再次去請求QQ的受權頁面,就能夠從中獲取到一個access token(訪問令牌),經過這個access_token,咱們能夠調用QQ提供給咱們的接口,好比獲取open_id,能夠獲取用戶的基本信息。獲取到以後,咱們須要拿用戶的受權信息和open_id和咱們平臺的普通用戶進行綁定。這樣無論是普通用戶登錄仍是第三方登錄用戶,均可以實現登錄。
我之前有過使用 hybrid APP開發過APP,作過一個簡單的廣場舞APP,但我主要參與到APP的接口編寫這塊中。
hybrid APP開發過程當中,前端知識是個人硬傷,之前,前端我一直都沒有花太多精力在上面,因此在使用hybrid APP 開發過程當中,頁面樣式老是調得很難看,後面我花了一週時間本身自學惡補瞭如下前端的東西,感受收穫很大。還有我記得之前在公司寫接口時,咱們的安卓工程師認爲他們APP的分頁效果,得咱們接口這邊事先分好頁,而後他們再調用接口,其實分頁的頁碼須要他那邊提供給咱們,可是他就認定了是咱們這邊的問題,後面通過屢次溝通和測試,咱們共同完成了這項任務。
首先,咱們得知道要殺死的進程的進程ID,能夠經過ps -ef | grep 進程名稱 查到當前運行的進程ID,而後經過kill命令殺死進程 ,如 kill -9 3329 表示強制殺死進程,固然還有不一樣的等級,取決於中間的數字。
63 、redis 經常使用的數據類型
Redis 的數據類型主要有:
string:字符串類型,能夠包含任何數據。包括jpg圖片或者序列化的對象。裏面的incr方法能夠實現網站計數器功能,每次訪問一個就能夠進行加1操做。下降了數據庫的壓力。
list:是一個雙向鏈表,經過push,pop操做從鏈表的頭部或者尾部添加刪除元素。
這使得list既能夠用做棧,也能夠用做隊列。好比能夠獲取最新添加的10個商品,獲取最新的登錄的10個信息,作商品的秒殺等等。均可以經過鏈表中的隊列來實現,極大節省了各方面的資源。
hash:hash數據類型是redis模仿數據庫把一條記錄信息給存儲起來,這樣能夠把數據庫中的每一條記錄保存在hash中,做爲緩存處理,很是接近於數據庫的操做。
set :set是string類型的無序集合。set集合類型除了基本的添加刪除操做,其餘有用的操做還包含集合的取並集(union),交集(intersection),差集(difference)。經過這些操做能夠很容易的實現sns中的好友推薦功能。好比qq好友推薦、微博系統的關注關係使用
sorted set:和set同樣sorted set也是string類型元素的集合,不一樣的是每一個元素都會關聯一個權。經過權值能夠有序的獲取集合中的元素,它的適用場合如:得到熱門帖子(回覆量)信息,根據學生成績排序得到信息等.
簡單說下無序集合、有序集合、鏈表三者的主要區別:
set類型:集合類型、內部元素沒有順序,同一個集合沒有重複元素
list鏈表類型:內部元素有彼此的前後順序,同一個鏈表容許有重複元素
Sort set類型:排序集合類型,相比set類型有排序功能
經常使用的網站性能測試有:壓力測試,負載測試,容量測試,併發性能測試,兼容性測試(不一樣的操做系統和不一樣的瀏覽器)。在項目正式上線前,咱們技術部會使用壓力測試工具來測試網站的性能(咱們主要是進行壓力測試的)。我主要用過兩款軟件:一個apache自帶的ab壓力測試工具,這個測試的最大併發量相對較小,通常1000左右就會出現請求拒絕。另外一個軟件是webbench,這個軟件首先得安裝,最大併發能夠到3W。固然還有一些其餘的專業的測試工具,如國外的 Page Speed Online、Pingdom Tools等等,咱們公司有專門的測試部,咱們會配合他們完成測試工做。
ab.exe -n 5000 -c 50 http://www.test.com/index.php
-n是總的執行次數,-c 併發的次數, http://www.test.com/index.php要執行的文件
咱們當時是這麼作的,使用HTTP的POST方式,對固定參數+附加參數進行數字簽名,使用的是md5加密,好比:我想經過標題獲取一個信息,在客戶端使用 信息標題+日期+雙方約定好的一個key經過md5加密生成一個簽名(sign),而後做爲參數傳遞到服務器端,服務器端使用一樣的方法進行校驗,如何接受過來的sign和咱們經過算法算的值相同,證實是一個正常的接口請求,咱們纔會返回相應的接口數據。
我主要用的第三方短信接口,在申請接口時進行相應信息的配置,而後在咱們站點須要用到短信驗證的地方進行調用,咱們一般在用戶註冊時使用到。
個人上一家公司主要使用的是XXX框架,我對該框架很是熟悉,咱們公司在該框架上作了一些相應的擴展,引入了一些本身編寫的類庫文件和插件庫。我之前還使用過yii2,ci、laravel框架,之前還本身封裝過MVC框架。一個新的框架掌握起來很容易,你只要抓住其中的幾個點,好比路由規則、MVC、數據庫相關的操做,其餘的均可以查手冊,孰能生巧,經過一個小項目就能夠把框架用得很熟,固然框架底層的東西,咱們仍是得用一些好的IDE工具去追它的底層源碼。
整體來講:在工做我主要遇到這幾個問題比較難處理:
①我以前工做的時候發現常常會出現一些臨時需求打亂了個人計劃,搞得有時候這個任務還沒完成,又得去作其餘的任務,最後一天下來,大大小小的東西是不少,可是沒有完成得很是好的,後面我總結了一下,我會把這些都添加優先級,遇到臨時需求,按照優先級從新將已有任務和臨時任務進行排版,保證在規定時間內有效率的完成優先級高的任務。
②在作項目需求時候,遇到理解能力欠佳的人,溝通時容易被氣到,影響本身的情緒,最後反倒還不能到達須要的效果。後面,每次到這種時候,我通常會藉助一些紙質的、更加形象的東西,讓雙方都認同的、都能明白的一種方式來進行溝通,後面減小了不少沒必要須的麻煩。你們都知道,對於程序員來講,改需求是一件很痛苦的事情,因此前期的溝通工做很重要。
③還有一件事時,我之前的領導不太懂技術,因此每次出一個新的需求出來,老是要求咱們在很短的時間內完成,完不成咱們就會被懷疑能力有問題。固然,每一個領導都但願本身的員工可以儘快的完成任務,下降成本,提升效率。這時候我會把咱們的需求細化,把其中的重點、難點都列出來,作好時間規劃,耐心的跟領導溝通,項目每一個點的重要性和時間的花費比例,確保在這個規劃的時間點內保質保量的完成任務。慢慢的也獲得了領導的承認,其實領導也不是一味的不通情理,只要把東西計劃好了,以最小的代價換取最高的價值,每一個人都是很容易理解得。
Memcached是一個高性能的分佈式內存對象緩存系統。目前全世界很多人使用這個緩存項目來構建本身大負載的網站,來分擔數據庫的壓力,經過在內在裏維護一個統一的巨大的的hash表,它可以用來存儲各類格式的數據,包括圖像、視頻、文件以及數據庫檢索的結果等,簡單的說就是將數據調用到內存中,而後從內存中讀取,從而大大提升讀取速度。
傳統的查詢方法是直接查詢數據庫,數據庫將結果返回給查詢語句,而當有Memcache中間緩存層時,查詢的是Memcache緩存數據,下面詳細瞭解Memcache各種數據操做原理:
1. 查詢數據(select),首先經過指定的Key查詢(get)Memcache中間緩存層數據,若是存在相對應數據,則直接獲取出數據結果,查詢過程徹底不須要查詢數據庫。若是不存在,則查詢MySQL數據庫,並以key對應value的形式將查詢結果存儲在Memcache緩存數據中,而後將結果返回給查詢語句。
2. 更新數據(update),首先更新數據,而後刪除相關的memcache數據(delete)。
3. 增長數據(add),首先刪除相關緩存數據,而後增長數據。
4. 刪除數據(delete),刪除數據,並刪除Memcache數據。
memcache的應用場景有:
1.若是是一個小網站,pv值不大,就不考慮使用memcached
2.變化頻繁,查詢頻繁,可是不必定寫入數據庫(適合memcached)(用戶在線狀態)
3.變化頻繁,一變化就要入庫(好比股票,金融)不適合memcached
4.變化不頻繁,查詢頻繁,無論入不入庫,都比較適合memcache,(新浪的新聞頻道)
分佈式是指將不一樣的業務分佈在不一樣的地方(幾臺服務器)。 而集羣指的是將幾臺服務器集中在一塊兒,實現同一業務。
分佈式中的每個節點,均可以作集羣。 而集羣並不必定就是分佈式的。
舉例:就好比新浪網,訪問的人多了,他能夠作一個集羣,前面放一個響應服務器,後面幾臺服務器完成同一業務,若是有業務訪問的時候,響應服務器看哪臺服務器的負載不是很重,就交給哪一臺去完成。而分佈式,從窄意上理解,也跟集羣差很少,可是它的組織比較鬆散,不像集羣,有一個組織性,一臺服務器垮了,其它的服務器能夠頂上來。memcache的分佈式算法取決於客戶端,主要用取餘算法和一致性哈希算法。
①直播視頻從技術架構角度主要分爲三個部分:
直播視頻採集SDK=>直播CDN(也即直播流分發加速)=》直播視頻播放器SDK
②音視頻處理的通常流程:
數據採集→數據編碼→數據傳輸(流媒體服務器) →解碼數據→播放顯示
一、數據採集:攝像機及拾音器收集視頻及音頻數據,此時獲得的爲原始數據,要用到攝像機和拾音器。
二、數據編碼:使用相關硬件或軟件對音視頻原始數據進行編碼處理(數字化)及加工(如音視頻混合、打包封裝等),獲得可用的音視頻數據,編碼的方式:CBR、VBR,編碼格式分爲音頻和視頻,音頻通常有MP三、OGG、AAC,視頻通常有TS、MKV、AVI、MP4等。
三、數據傳輸:將編碼完成後的音視頻數據進行傳輸,早期的音視頻經過同軸電纜之類的線纜進行傳輸,IP網絡發展後,使用IP網絡優傳輸
涉及技術或協議:
傳輸協議:RTP與RTCP、RTSP、RTMP、HTTP、HLS(HTTP Live Streaming)等
控制信令:SIP和SDP、SNMP等
四、解碼數據:
使用相關硬件或軟件對接收到的編碼後的音視頻數據進行解碼,獲得能夠直接顯示的圖像/聲音
涉及技術或協議:
通常對應的編碼器都會帶有相應的解碼器,也有一些第三方解碼插件等
五、播放顯示:
在顯示器(電視、監視屏等)或揚聲器(耳機、喇叭等)裏,顯示相應的圖像畫面或聲音
涉及技術或協議:
顯示器、揚聲器、3D眼鏡等
用戶在不登陸的狀況下,能夠把要購買商品的信息(如商品的ID,商品的價格、商品的sku_id,購買數量等關鍵數據)存到COOKIE裏面,當登錄的狀況下。把COOKIE裏面的內容存到數據庫,並清除cookie中的數據。
答案:寫過。接口分爲兩種:一種是數據型接口,一種是應用型接口。
數據型接口:是比抽象類更抽象的某種「結構」——它其實不是類,可是跟類同樣的某種語法結構,是一種結構規範,規範咱們類要以什麼格式進行定義,通常用於團隊比較大,分支比較多的狀況下使用。
應用型接口: API(application interface) 數據對外訪問的一個入口
我主要是參與的APP開發中接口的編寫,客戶端須要什麼樣的數據,咱們就給他們提供相應的數據,數據以json/xml的格式返回,而且配以相應的接口文檔。
答:這裏要說的靜態化指的是頁面靜態化,也即生成實實在在的靜態文件,也即不須要查詢數據庫就能夠直接從文件中獲取數據,指的是真靜態。它的實現方式主要有兩種:
一種是咱們在添加信息入庫的時候就生成的靜態文件,也稱爲模板替換技術,這種主要用在後臺,用於一些基本上不多變化的信息上,在添加信息的時候使用添加的信息來替換制定好的模板中的內容,達到生成靜態文件的目的,這樣在前臺訪問該信息時,能夠直接從生成好的靜態文件中獲取信息,如一些CMS系統。
另一種是用戶在訪問咱們的頁面時先判斷是否有對應的緩存文件存在,若是存在就讀緩存,不存在就讀數據庫,同時生成緩存文件。這種實現的主要原理是基於PHP中的ob緩衝技術來實現的,當沒有靜態文件時,從數據庫中讀取,讀取的數據使用OB緩存,使用相關的函數從OB緩衝中讀取數據,寫入到文件中,造成靜態文件。固然這個過程當中要考慮靜態文件的緩存週期問題,咱們能夠根據文件的最後修改時間和當前時間及設定的緩存時間來定時更新緩存文件。
答:僞靜態不是真正意義上的靜態化,之因此使用僞靜態,主要是爲了SEO推廣,搜索引擎對動態的文件獲取難度大,不利於網站的推廣。僞靜態的實現原理主要是基於apache/nginx等web服務器的rewrite機制。利用Apache/nginx裏面相關的服務器變量和指令來完成重寫。主要有兩種方式,一種是直接在配置虛擬機的位置配置僞靜態,這個每次修改完成後須要重啓web服務器。另外一種採用分佈式的,能夠在網站的根目錄上建立.htaccess的文件,在裏面配置相應的重寫規則來實現僞靜態,這種每次重寫時不須要重啓web服務器,且結構上比較清晰。具體的配置能夠參考 Apache/nginx的手冊。
答:mysql優化前面已經總結了。主要說下讀寫分離,當咱們的數據量很大時,數據庫服務器的壓力變大,這時候咱們須要從架構方面來解決這一問題,在一個網站中讀的操做不少,寫的操做不多,這時候咱們須要配置讀寫分離,把讀操做和寫操做分離出來,最大程度的利用好數據庫服務器。讀寫分離的實現原理就是在執行SQL語句的時候,判斷究竟是讀操做仍是寫操做,把讀的操做轉向到讀服務器上(從服務器,通常是多臺),寫的操做轉到寫的服務器上(主服務器,通常是一臺,視數據量來看)。固然爲了保證多臺數據庫數據的一致性,須要主從複製。主從複製的實現原理是:mysql中有一種日誌,叫作bin日誌(二進制日誌),會記錄下全部修改過數據庫的sql語句。主從複製的原理實際是多臺服務器都開啓bin日誌,而後主服務器會把執行過的sql語句記錄到bin日誌中,以後從服務器讀取這個bin日誌,把該日誌的內容保存到本身中繼日誌裏面,從服務器再把中繼日誌中記錄的sql語句一樣的執行一遍。這樣從服務器上的數據就和主服務器相同了。
SKU = Stock Keeping Unit (庫存量單位)
即庫存進出計量的單位,能夠是以件,盒,托盤等爲單位。SKU是庫存量單位,區分單品。
在服裝、鞋類商品中使用最多最廣泛。 例如紡織品中一個SKU一般表示:規格、顏色、款式。
在設計表時,不只僅只有商品表,商品表中有個總庫存,咱們還須要涉及一張SKU表,裏面有SKU庫存和單價字段,用戶每購買一件商品,實際上購買的都是SKU商品,這樣在下訂單成功後,應該根據所購買的商品的惟一的SKU號來進行相應的SKU庫存的減小,固然商品的總庫存保存在商品主表中,也須要減小總庫存中的庫存量。
Linux日誌文件通常在/var/log目錄下,經過查看日誌,咱們能夠看到Linux系統內核和許多程序會產生各類錯誤信息、警告信息和提示信息,這些信息對於管理員瞭解系統的運營狀態是很是有用的,這些信息都被保存在相應的日誌文件中。syslog是一個歷史悠久的日誌系統,幾乎全部的UNIX和Linux操做系統都是採用syslog進行系統日誌的管理和配置。在默認的syslog配置下,日誌文件一般都保存在「/var/log」目錄下。默認配置的syslog日誌以下:
咱們能夠經過下面幾個命令分別進行查看:
一、cat命令:
功能:1)顯示整個文件。
2)把文件串鏈接後傳到基本輸出,如將幾個文件合併爲一個文件或輸出到屏幕。
二、more命令:
以百分比的形式查看日誌。
三、less命令:
跟more功能差很少,只不過less支持先後翻閱文件。
四、head命令:
功能:從文本文件的頭部開始查看,head 命令用於查看一個文本文件的開頭部分。
五、tail命令:
功能:tail 命令用於顯示文本文件的末尾幾行。
庫存分爲商品總庫存和SKU庫存,每每商品總庫存的爲SKU庫存的總和。通常在商城的後臺對貨品設置最高庫存及最低庫存後,當前庫存數量與最高、最低二者比較,超出庫存或者低於庫存的,則被統計成報表形式反映,便於用戶掌握貨品庫存超、短缺狀態及數量。
在一個電子商務系統中,正常的應該是訂單生成成功後,相應的庫存進行減小。必需要保證二者的一致性,但有時候由於某些緣由,好比程序邏輯問題,併發等問題,致使下單成功而庫存沒有減小的狀況。這種狀況咱們是不容許發生的,MySQL中的事務恰好能夠解決這一問題,首先得選擇數據庫的存儲引擎爲innoDB,事務規定了只有下訂單完成了,而且相應的庫存減小了才容許提交事務,不然就事務回滾,確保數據一致性。
其實redis是不會存在併發問題的,由於他是單進程的,再多的command都是one by one執行的。咱們使用的時候,可能會出現併發問題,好比get和set這一對。
redis爲何會有高併發問題
redis的出身決定
Redis是一種單線程機制的nosql數據庫,基於key-value,數據可持久化落盤。因爲單線程因此redis自己並無鎖的概念,多個客戶端鏈接並不存在競爭關係,可是利用jedis等客戶端對redis進行併發訪問時會出現問題。發生鏈接超時、數據轉換錯誤、阻塞、客戶端關閉鏈接等問題,這些問題均是因爲客戶端鏈接混亂形成。
同時,單線程的天性決定,高併發對同一個鍵的操做會排隊處理,若是併發量很大,可能形成後來的請求超時。
在遠程訪問redis的時候,由於網絡等緣由形成高併發訪問延遲返回的問題。
解決辦法
在客戶端將鏈接進行池化,同時對客戶端讀寫Redis操做採用內部鎖synchronized。
服務器角度,利用setnx變向實現鎖機制。
85 、 秒殺當中的細節你是怎麼得出來的
經過性能測試及模擬秒殺場景。每一個問題都通過反覆測試,不斷的發現問題,不斷的解決。
不少公司爲了快速的開發出一款產品,下降成本,每每會採用一些開源的產品來完成,一款好的開源產品能夠起到事半功倍的效果,咱們只須要在它的基礎上作些二次開發,就能夠達到咱們想要的簡單的效果。可是,每每這些開源產品也有本身的弊端。
好比我之前用過的ecshop:產品線不完整,只有單用戶產品,後臺操做過於煩雜,無用功能比較多,使用起來有不少BUG和不便,系統功能相對薄弱,運營起來很費人力成本。被商派收購以後,宣傳推廣也停滯不前。並且是面向過程的,你必須按照它的規則進行修改,操做起來相對很繁瑣。對PHP5.4以上的版本支持很差,jQuery的兼容性上要好好處理。
PHPCMS:靜態處理很差,SEO有待增強,訪問速度也較慢。
Shopex:代碼不開源,修改很麻煩,只能經過插件的方式去改進,底層是不知道的,有漏洞更新也是很慢,當數量達到必定量的時候shopex很吃內存服務質量也很差,基本用戶提的意見,很難被有效採起。最頭疼的是他的後臺操做,易用性不好,前臺模板也很差看。而且系統各方面的壓力承受能力都有不足。
系統出了問題也只能等待解決,有受制於人的感受。
總之,使用別人成型的東西,就要遵循別人的規範,責任在於本身。
首先要有一個支付寶帳號,接下來向支付寶申請在線支付業務,簽署協議。協議生效後有支付寶一方會給網站方一個合做夥伴ID,和安全校驗碼,有了這兩樣東西就能夠按照支付寶接口文檔開發支付寶接口了,中間主要涉及到一個安全問題。整個流程是這樣的:咱們的網站經過post傳遞相應的參數(如訂單總金額,訂單號)到支付頁面,支付頁面把一系列的參數通過處理,以post的方式提交給支付寶服務器,支付寶服務器進行驗證,並對接收的數據進行處理,把處理後的結果返回給咱們網站設置的異步和同步回調地址,經過相應的返回參數,來處理相應的業務邏輯,好比返回的參數表明支付成功,更改訂單狀態。
單點登陸SSO(Single Sign On)說得簡單點就是在一個多系統共存的環境下,用戶在一處登陸後,就不用在其餘系統中登陸,也就是用戶的一次登陸能獲得其餘全部系統的信任。
什麼狀況下使用緩存
當用戶第一次訪問應用系統的時候,由於尚未登陸,會被引導到認證系統中進行登陸;根據用戶提供的登陸信息,認證系統進行身份校驗,若是經過校驗,應該返回給用戶一個認證的憑據--ticket;用戶再訪問別的應用的時候,就會將這個ticket帶上,做爲本身認證的憑據,應用系統接受到請求以後會把 ticket送到認證系統進行校驗,檢查ticket的合法性。若是經過校驗,用戶就能夠在不用再次登陸的狀況下訪問應用系統2和應用系統3了。
實現主要技術點:
一、兩個站點共用一個數據驗證系統
二、主要經過跨域請求的方式來實現驗證及session處理。
第三方登錄主要是基於author協議來實現,下面簡單說下實現流程:
一、首先咱們須要以開發者的身份向第三方登錄平臺申請接入應用,申請成功後,咱們會得到一個appID和一個secrectID.
二、當咱們的網站需接入第三方登錄時,會引導用戶跳轉到第三方的登錄受權頁面,此時把以前申請的appID和secrectID帶給登錄受權頁面。
三、用戶登錄成功後即獲得受權,第三方會返回一個臨時的code給咱們的網站。
四、咱們的網站接受到code後,再次向咱們的第三方發起請求,並攜帶接收的code,從第三方獲取access_token.
五、第三方處理請求後,會返回一個access_token給咱們的網站,咱們的網站獲取到access_token後就能夠調用第三方提供的接口了,好比獲取用戶信息等。最後把該用戶信息存入到咱們站點的數據庫,並把信息保存到session中,實現用戶的第三方登錄。
環境分爲開發環境和線上環境,咱們作測試是在開發環境上進行測試的,只有測試經過了纔會上線。
APP數據是客戶端傳遞相應的參數調用服務器端的接口,服務器端從數據庫或者緩存數據從讀取數據轉換爲XML/json數據,提供給APP端。
從低成本、高性能和高擴張性的角度來講有以下處理方案:
一、HTML靜態化
其實你們都知道,效率最高、消耗最小的就是純靜態化的html頁面,因此咱們儘量使咱們的 網站上的頁面採用靜態頁面來實現,這個最簡單的方法其實也是最有效的方法。
二、圖片服務器分離
把圖片單獨存儲,儘可能減小圖片等大流量的開銷,能夠放在一些相關的平臺上,如騎牛等
三、數據庫集羣和庫表散列及緩存
數據庫的併發鏈接爲100,一臺數據庫遠遠不夠,能夠從讀寫分離、主從複製,數據庫集羣方面來着手。另外儘可能減小數據庫的訪問,能夠使用緩存數據庫如memcache、redis。
四、鏡像:
儘可能減小下載,能夠把不一樣的請求分發到多個鏡像端。
五、負載均衡:
Apache的最大併發鏈接爲1500,只能增長服務器,能夠從硬件上着手,如F5服務器。固然硬件的成本比較高,咱們每每從軟件方面着手。
負載均衡 (Load Balancing) 創建在現有網絡結構之上,它提供了一種廉價有效透明的方法擴展網絡設備和服務器的帶寬、增長吞吐量、增強網絡數據處理能力,同時可以提升網絡的靈活性和可用性。目前使用最爲普遍的負載均衡軟件是Nginx、LVS、HAProxy。我分別來講下三種的優缺點:
Nginx的優勢是:
1. 工做在網絡的7層之上,能夠針對http應用作一些分流的策略,好比針對域名、目錄結構,它的正則規則比HAProxy更爲強大和靈活,這也是它目前普遍流行的主要緣由之一,Nginx單憑這點可利用的場合就遠多於LVS了。
2. Nginx對網絡穩定性的依賴很是小,理論上能ping通就就能進行負載功能,這個也是它的優點之一;相反LVS對網絡穩定性依賴比較大,這點本人深有體會;
3. Nginx安裝和配置比較簡單,測試起來比較方便,它基本能把錯誤用日誌打印出來。LVS的配置、測試就要花比較長的時間了,LVS對網絡依賴比較大。
4. 能夠承擔高負載壓力且穩定,在硬件不差的狀況下通常能支撐幾萬次的併發量,負載度比LVS相對小些。
5. Nginx能夠經過端口檢測到服務器內部的故障,好比根據服務器處理網頁返回的狀態碼、超時等等,而且會把返回錯誤的請求從新提交到另外一個節點,不過其中缺點就是不支持url來檢測。好比用戶正在上傳一個文件,而處理該上傳的節點恰好在上傳過程當中出現故障,Nginx會把上傳切到另外一臺服務器從新處理,而LVS就直接斷掉了,若是是上傳一個很大的文件或者很重要的文件的話,用戶可能會所以而不滿。
6. Nginx不只僅是一款優秀的負載均衡器/反向代理軟件,它同時也是功能強大的Web應用服務器。LNMP也是近幾年很是流行的web架構,在高流量的環境中穩定性也很好。
7. Nginx如今做爲Web反向加速緩存愈來愈成熟了,速度比傳統的Squid服務器更快,能夠考慮用其做爲反向代理加速器。
8. Nginx可做爲中層反向代理使用,這一層面Nginx基本上無對手,惟一能夠對比Nginx的就只有 lighttpd了,不過 lighttpd目前尚未作到Nginx徹底的功能,配置也不那麼清晰易讀,社區資料也遠遠沒Nginx活躍。
9. Nginx也可做爲靜態網頁和圖片服務器,這方面的性能也無對手。還有Nginx社區很是活躍,第三方模塊也不少。
Nginx的缺點是:
1. Nginx僅能支持http、https和Email協議,這樣就在適用範圍上面小些,這個是它的缺點。
2. 對後端服務器的健康檢查,只支持經過端口來檢測,不支持經過url來檢測。不支持Session的直接保持,但能經過ip_hash來解決。
LVS:使用Linux內核集羣實現一個高性能、高可用的負載均衡服務器,它具備很好的可伸縮性(Scalability)、可靠性(Reliability)和可管理性(Manageability)。
LVS的優勢是:
1. 抗負載能力強、是工做在網絡4層之上僅做分發之用,沒有流量的產生,這個特色也決定了它在負載均衡軟件裏的性能最強的,對內存和cpu資源消耗比較低。
2. 配置性比較低,這是一個缺點也是一個優勢,由於沒有可太多配置的東西,因此並不須要太多接觸,大大減小了人爲出錯的概率。
3. 工做穩定,由於其自己抗負載能力很強,自身有完整的雙機熱備方案,如LVS+Keepalived,不過咱們在項目實施中用得最多的仍是LVS/DR+Keepalived。
4. 無流量,LVS只分發請求,而流量並不從它自己出去,這點保證了均衡器IO的性能不會受到大流量的影響。
5. 應用範圍比較廣,由於LVS工做在4層,因此它幾乎能夠對全部應用作負載均衡,包括http、數據庫、在線聊天室等等。
LVS的缺點是:
1. 軟件自己不支持正則表達式處理,不能作動靜分離;而如今許多網站在這方面都有較強的需求,這個是Nginx/HAProxy+Keepalived的優點所在。
2. 若是是網站應用比較龐大的話,LVS/DR+Keepalived實施起來就比較複雜了,特別後面有 Windows Server的機器的話,若是實施及配置還有維護過程就比較複雜了,相對而言,Nginx/HAProxy+Keepalived就簡單多了。
HAProxy的特色是:
1. HAProxy也是支持虛擬主機的。
2. HAProxy的優勢可以補充Nginx的一些缺點,好比支持Session的保持,Cookie的引導;同時支持經過獲取指定的url來檢測後端服務器的狀態。
3. HAProxy跟LVS相似,自己就只是一款負載均衡軟件;單純從效率上來說HAProxy會比Nginx有更出色的負載均衡速度,在併發處理上也是優於Nginx的。
4. HAProxy支持TCP協議的負載均衡轉發,能夠對MySQL讀進行負載均衡,對後端的MySQL節點進行檢測和負載均衡,你們能夠用LVS+Keepalived對MySQL主從作負載均衡。
5. HAProxy負載均衡策略很是多,HAProxy的負載均衡算法如今具體有以下8種:
① roundrobin,表示簡單的輪詢,這個很少說,這個是負載均衡基本都具有的;
② static-rr,表示根據權重,建議關注;
③ leastconn,表示最少鏈接者先處理,建議關注;
④ source,表示根據請求源IP,這個跟Nginx的IP_hash機制相似,咱們用其做爲解決session問題的一種方法,建議關注;
⑤ ri,表示根據請求的URI;
⑥ rl_param,表示根據請求的URl參數’balance url_param’ requires an URL parameter name;
⑦ hdr(name),表示根據HTTP請求頭來鎖定每一次HTTP請求;
⑧ rdp-cookie(name),表示根據據cookie(name)來鎖定並哈希每一次TCP請求。
Nginx和LVS對比的總結:
1. Nginx工做在網絡的7層,因此它能夠針對http應用自己來作分流策略,好比針對域名、目錄結構等,相比之下LVS並不具有這樣的功能,因此Nginx單憑這點可利用的場合就遠多於LVS了;但Nginx有用的這些功能使其可調整度要高於LVS,因此常常要去觸碰觸碰,觸碰多了,人爲出問題的概率也就會大。
2. Nginx對網絡穩定性的依賴較小,理論上只要ping得通,網頁訪問正常,Nginx就能連得通,這是Nginx的一大優點!Nginx同時還能區份內外網,若是是同時擁有內外網的節點,就至關於單機擁有了備份線路;LVS就比較依賴於網絡環境,目前來看服務器在同一網段內而且LVS使用direct方式分流,效果較能獲得保證。另外注意,LVS須要向託管商至少申請多一個ip來作Visual IP,貌似是不能用自己的IP來作VIP的。要作好LVS管理員,確實得跟進學習不少有關網絡通訊方面的知識,就再也不是一個HTTP那麼簡單了。
3. Nginx安裝和配置比較簡單,測試起來也很方便,由於它基本能把錯誤用日誌打印出來。LVS的安裝和配置、測試就要花比較長的時間了;LVS對網絡依賴比較大,不少時候不能配置成功都是由於網絡問題而不是配置問題,出了問題要解決也相應的會麻煩得多。
4. Nginx也一樣能承受很高負載且穩定,但負載度和穩定度差LVS還有幾個等級:Nginx處理全部流量因此受限於機器IO和配置;自己的bug也仍是難以免的。
5. Nginx能夠檢測到服務器內部的故障,好比根據服務器處理網頁返回的狀態碼、超時等等,而且會把返回錯誤的請求從新提交到另外一個節點。目前LVS中 ldirectd也能支持針對服務器內部的狀況來監控,但LVS的原理使其不能重發請求。好比用戶正在上傳一個文件,而處理該上傳的節點恰好在上傳過程當中出現故障,Nginx會把上傳切到另外一臺服務器從新處理,而LVS就直接斷掉了,若是是上傳一個很大的文件或者很重要的文件的話,用戶可能會所以而惱火。
6. Nginx對請求的異步處理能夠幫助節點服務器減輕負載,假如使用 apache直接對外服務,那麼出現不少的窄帶連接時apache服務器將會佔用大 量內存而不能釋放,使用多一個Nginx作apache代理的話,這些窄帶連接會被Nginx擋住,apache上就不會堆積過多的請求,這樣就減小了至關多的資源佔用。這點使用squid也有相同的做用,即便squid自己配置爲不緩存,對apache仍是有很大幫助的。
7. Nginx能支持http、https和email(email的功能比較少用),LVS所支持的應用在這點上會比Nginx更多。在使用上,通常最前端所採起的策略應是LVS,也就是DNS的指向應爲LVS均衡器,LVS的優勢令它很是適合作這個任務。重要的ip地址,最好交由LVS託管,好比數據庫的 ip、webservice服務器的ip等等,這些ip地址隨着時間推移,使用面會愈來愈大,若是更換ip則故障會接踵而至。因此將這些重要ip交給 LVS託管是最爲穩妥的,這樣作的惟一缺點是須要的VIP數量會比較多。Nginx可做爲LVS節點機器使用,一是能夠利用Nginx的功能,二是能夠利用Nginx的性能。固然這一層面也能夠直接使用squid,squid的功能方面就比Nginx弱很多了,性能上也有所遜色於Nginx。Nginx也可做爲中層代理使用,這一層面Nginx基本上無對手,惟一能夠撼動Nginx的就只有lighttpd了,不過lighttpd目前尚未能作到 Nginx徹底的功能,配置也不那麼清晰易讀。另外,中層代理的IP也是重要的,因此中層代理也擁有一個VIP和LVS是最完美的方案了。具體的應用還得具體分析,若是是比較小的網站(日PV小於1000萬),用Nginx就徹底能夠了,若是機器也很多,能夠用DNS輪詢,LVS所耗費的機器仍是比較多的;大型網站或者重要的服務,機器不發愁的時候,要多多考慮利用LVS。
數據庫優化
考慮到了,當時咱們作秒殺時考慮了好幾種方案,其中有一種就是使用事務加上排他鎖來實現。
架構類的東西接觸過嗎?
有接觸過,曾經本身在本身的服務器上配置過。我之前作過如下幾個架構方面的配置和測試;
一、數據庫的讀寫分離、主從複製及集羣。
二、Nginx負載均衡
三、redis集羣及主從
封裝過一個簡單的MVC框架,主要分爲3層,控制器層和模型層視圖層,以及路由的分配和入口文件,模板引擎,單例模式、工廠模式,第三方類庫的引入等。
我在開發環境下,經過ab壓力和webbench作過相關的壓力測試,當Apache最大到1000併發時,發現請求超時或者服務器積極拒絕。webbench併發到3000時,請求很是慢,5000時,服務器積極拒絕。
商城創業服務平臺,將創業者進行整合,將線下商家搬到線上,使線上商家擺脫地理位置的限制,下降推廣成本,經過商城平臺從線上快速引流,以全新的方式開展營銷策略。線上交易數據可查,永久保存,商家經過平臺交易行爲加以分析,進行開展二次營銷,屢次營銷,深度挖掘幼稚客戶,培養忠實客戶。
2.商城創業服務平臺憑着創新的模式,將帶領廣大創業者咋移動互聯網,O2O電商模式的大浪中殺出重圍,取得成功!
核心思想是:視圖和用戶交互經過事件致使控制器改變 控制器改變致使模型改變 或者控制器同時改變二者 模型改變 致使視圖改變 或者視圖改變 潛在的從模型裏面得到參數 來改變本身。他的好處是能夠將界面和業務邏輯分離。
Model(模型),是程序的主體部分,主要包含業務數據和業務邏輯。在模型層,還會涉及到用戶發佈的服務,在服務中會根據不一樣的業務需求,更新業務模型中的數據。
View(視圖),是程序呈現給用戶的部分,是用戶和程序交互的接口,用戶會根據具體的業務需求,在View視圖層輸入本身特定的業務數據,並經過界面的事件交互,將對應的輸入參數提交給後臺控制器進行處理。
Contorller(控制器),Contorller是用來處理用戶 輸入數據,已經更新業務模型的部分。控制器中接收了用戶與界面交互時傳遞過來的數據,並根據數據業務邏輯來執行服務的調用和更新業務模型的數據和狀態。
一、cookie數據存放在第三方應用的瀏覽器上,session數據放在服務器上。
二、cookie不是很安全,別人能夠分析存放在本地的COOKIE,進行COOKIE欺騙
考慮到安全應當使用session。
三、session會在必定時間內保存在服務器上。當訪問增多,會比較佔用你服務器的性能
考慮到減輕服務器性能方面,應當使用COOKIE。
四、單個cookie保存的數據不能超過4K,不少瀏覽器都限制一個站點最多保存20個cookie。
五、因此我的建議:
將登錄信息等重要信息存放爲SESSION
其餘信息若是須要保留,能夠放在COOKIE
echo能夠一次輸出多個值,多個值之間用逗號分隔。echo是語言結構(language construct),而並非真正的函數,所以不能做爲表達式的一部分使用。echo是php的內部指令,不是函數,無返回值。
print():函數print()打印一個值(它的參數),若是字符串成功顯示則返回true,不然返回false。只能打印出簡單類型變量的值(如int,string),有返回值
printf():源於C語言中的printf()。該函數輸出格式化的字符串。
print_r()和var_dump()
print_r()能夠把字符串和數字簡單地打印出來,而數組則以括起來的鍵和值得列表形式顯示,並以Array開頭。但print_r()輸出布爾值和NULL的結果沒有意義,由於都是打印"\n"。所以用var_dump()函數更適合調試。print_r是函數,能夠打印出比較複雜的變量(如數組,對象),有返回值
var_dump()判斷一個變量的類型與長度,並輸出變量的數值,若是變量有值輸的是變量的值並回返數據類型。此函數顯示關於一個或多個表達式的結構信息,包括表達式的類型與值。數組將遞歸展開值,經過縮進顯示其結構。
①單引號內部的變量不會執行, 雙引號會執行
②單引號解析速度比雙引號快。
③單引號只能解析部分特殊字符,雙引號能夠解析全部特殊字符。
一、優勢:
a)能夠保證數據庫表中每一行的數據的惟一性
b)能夠大大加快數據的索引速度
c)加速表與表之間的鏈接,物別是在實現數據的參考完事性方面特別有意義
d)在使用分組和排序子句進行數據檢索時,一樣能夠顯著減小查詢中分組和排序的時間
f)經過使用索引,能夠在時間查詢的過程當中,使用優化隱藏器,提升系統的性能
二、缺點:
建立索引和維護索引要耗費時間,這種時間隨着數據量的增長而增長
索引須要佔物理空間,除了數據表佔用數據空間以外,每個索引還要佔用必定的物理空間,若是須要創建聚簇索引,那麼須要佔用的空間會更大
以表中的數據進行增、刪、改的時候,索引也要動態的維護,這就下降了整數的維護速度
創建索引的原則
在常常須要搜索的列上,能夠加快搜索的速度
在做爲主鍵的列上,強制該列的惟一性和組織表中數據的排列結構
在常常用在鏈接的列上,這些列主要是一外鍵,能夠加快鏈接的速度
在經常常須要根據範圍進行搜索的列上建立索引,國爲索引已經排序,其指定的範圍是連續的
在常常須要排序的列上,國爲索引已經排序,這樣井底能夠利用索引的排序,加快排序井底時間
在常用在where子句中的列上,加快條件的判斷速度
1. get是從服務器上獲取數據,post是向服務器傳送數據。
2. get是把參數數據隊列加到提交表單的ACTION屬性所指的URL中,值和表單內各個字段一一對應,在URL中能夠看到。post是經過HTTP post機制,將表單內各個字段與其內容放置在HTML HEADER內一塊兒傳送到ACTION屬性所指的URL地址。用戶看不到這個過程。
3. get傳送的數據量較小,不能大於2KB。post傳送的數據量較大,通常被默認爲不受限制。4.. get安全性很是低,post安全性較高。可是執行效率卻比Post方法好。
一:在php.ini 中設置 session.gc_maxlifetime = 1440 //默認時間
二:代碼實現
$lifeTime = 24 * 3600; // 保存一天
session_set_cookie_params($lifeTime);
session_start();
PHP5.2 之前:autoload, PDO 和 MySQLi, 類型約束 、JSON 支持
PHP5.3:棄用的功能,匿名函數,新增魔術方法,命名空間,後期靜態綁定Heredoc 和 Nowdoc, const, 三元運算符,Phar
PHP5.4:Short Open Tag, 數組簡寫形式,Traits, 內置 Web 服務器,細節修改
PHP5.5:yield, list() 用於 foreach, 細節修改
PHP5.6: 常量加強,可變函數參數,命名空間加強
對稱加密與解密使用的是一樣的密鑰,但因爲須要將密鑰在網絡傳輸,因此安全性不高
非對稱加密使用了一對密鑰,公鑰與私鑰,把以安全性高,但加密與解密速度慢
解決的辦法是將對稱加密的密鑰使用非對稱加密的公鑰進行加密,而後發送出去,接收方使用私鑰進行解密獲得對稱加密的密鑰,而後雙方能夠使用對稱加密來進行溝通
(一)對稱加密(Symmetric Cryptography)
對稱加密是最快速、最簡單的一種加密方式,加密(encryption)與解密(decryption)用的是一樣的密鑰(secret key),這種方法在密碼學中叫作對稱加密算法。
採用單鑰密碼系統的加密方法,同一個密鑰能夠同時用做信息的加密和解密加密方式DES、3DES、TDEA、Blowfish、RC二、RC四、RC5、IDEA、SKIPJACK、AES
優缺點
對稱加密算法的優勢是算法公開、計算量小、加密速度快、加密效率高。
對稱加密算法的缺點是在數據傳送前,發送方和接收方必須商定好祕鑰,而後 使雙方都能保存好祕鑰。其次若是一方的祕鑰被泄露,那麼加密信息也就不安全了。另外,每對用戶每次使用對稱加密算法時,都須要使用其餘人不知道的惟一祕 鑰,這會使得收、發雙方所擁有的鑰匙數量巨大,密鑰管理成爲雙方的負擔。
(二)非對稱加密(asymmetric Cryptography)
容許在不安全的媒體上的通信雙方交換信息,安全地達成一致的密鑰,這就是「公開密鑰系統」。相對於「對稱加密算法」這種方法也叫作「非對稱加密算法」。
優缺點
非對稱加密與對稱加密相比,其安全性更好:對稱加密的通訊雙方使用相同的祕鑰,若是一方的祕鑰遭泄露,那麼整個通訊就會被破解。而非對稱加密使用一對祕鑰,一個用來加密,一個用來解密,並且公鑰是公開的,祕鑰是本身保存的,不須要像對稱加密那樣在通訊以前要先同步祕鑰。
非對稱加密的缺點是加密和解密花費時間長、速度慢,只適合對少許數據進行加密。
一、ob_start() //打開緩衝區,全部輸出的信息不直接發送到瀏覽器,而是保存在緩衝區裏面
二、ob_clean() //刪除內部緩衝區的內容,不關閉緩衝區(不輸出)
三、ob_end_clean() //刪除內部緩衝區的內容,關閉緩衝區(不輸出)
四、ob_get_clean() //返回內部緩衝區的內容,關閉緩衝區。【至關於執行ob_get_contents() and ob_end_clean()】
五、ob_flush() //發送內部緩衝區的內容到瀏覽器,刪除緩衝區的內容,不關閉緩衝區。
六、ob_end_flush() //發送內部緩衝區的內容到瀏覽器,刪除緩衝區的內容,關閉緩衝區
七、ob_get_flush() //返回內部緩衝區的內容,並關閉緩衝區的內容
八、ob_get_contents()//返回緩衝區的內容,不輸出
九、ob_get_length() //返回內部緩衝區的長度,若是緩衝區未被激活,該函數返回false
arch 顯示機器的處理器架構(1) 文件搜索 locate \*.ps 尋找以 '.ps'結尾的文件 -先運行'updatedb'命令
掛載一個文件系統
1,linux裏把文件/etc/aaa中的內容追加到/usr/bbb中的內容的後面
df -hl 查看磁盤剩餘空間 df -h 查看每一個根路徑的分區大小 du -sh [目錄名] 返回該目錄的大小 du -sm [文件夾] 返回該文件夾總M數 |
關機 (系統的關機、重啓以及登出) 文件和目錄 磁盤空間 下載、解壓 1)對於.tar結尾的文件 2)對於.gz結尾的文件 # zip all.zip *.jpg 下載命令 wget + 空格 +要下載文件的url路徑 ===================================== Shell 腳本: 必須以 #!/bin/sh 開頭 簡單例子:判斷這個目錄下有沒有文件(File) #!/bin/bash |
1、常常被讀取而且實時性要求不強能夠等到自動過時的數據。例如網站首頁最新文章列表、某某排行等數據。
2、常常被讀取而且實時性要求強的數據。好比用戶的好友列表,用戶文章列表,用戶閱讀記錄等。
3、統計類緩存,好比文章瀏覽數、網站PV等。
4、活躍用戶的基本信息或者某篇熱門文章。
5、session數據
1。__construct()
實例化對象時被調用,當__construct和以類名爲函數名的函數同時存在時,__construct將被調用,另外一個不被調用。
2。__destruct()
當刪除一個對象或對象操做終止時被調用。
3。__call()
對象調用某個方法,若方法存在,則直接調用;若不存在,則會去調用__call函數。
4。__get()
讀取一個對象的屬性時,若屬性存在,則直接返回屬性值;若不存在,則會調用__get函數。
5。__set()
設置一個對象的屬性時,若屬性存在,則直接賦值;若不存在,則會調用__set函數。
6。__toString()
打印一個對象的時被調用。如echo $obj;或print $obj;
7。__clone()
克隆對象時被調用。如:$t=new Test();$t1=clone $t;
8。__sleep()
serialize以前被調用。若對象比較大,想刪減一點東東再序列化,可考慮一下此函數。
9。__wakeup()
unserialize時被調用,作些對象的初始化工做。
10。__isset()
檢測一個對象的屬性是否存在時被調用。如:isset($c->name)。
11。__unset()
unset一個對象的屬性時被調用。如:unset($c->name)。
12。__set_state()
調用var_export時,被調用。用__set_state的返回值作爲var_export的返回值。
13。__autoload()
實例化一個對象時,若是對應的類不存在,則該方法被調用。
魔術常量:
1。__LINE__
返回文件中的當前行號。
2。__FILE__
返回文件的完整路徑和文件名。若是用在包含文件中,則返回包含文件名。自 PHP 4.0.2 起,__FILE__ 老是包含一個絕對路徑,而在此以前的版本有時會包含一個相對路徑。
3。__FUNCTION__
返回函數名稱(PHP 4.3.0 新加)。自 PHP 5 起本常量返回該函數被定義時的名字(區分大小寫)。在PHP 4 中該值老是小寫字母的。
4。__CLasS__
返回類的名稱(PHP 4.3.0 新加)。自 PHP 5 起本常量返回該類被定義時的名字(區分大小寫)。在PHP 4 中該值老是小寫字母的。
5。__METHOD__
返回類的方法名(PHP 5.0.0 新加)。返回該方法被定義時的名字(區分大小寫)。
__set()當程序試圖寫入一個不存在或者不可見的成員變量時,__set()方法包含兩個參數,分別表示變量名稱和變量值,兩個參數都不可省略
__get()當程序試圖調用一個未定義或不可見的成員變量時,__get()方法有一個參數,表示要調用的變量名
__sleep() 經常使用於提交未提交的數據,或相似的清理操做若是有一些很大的對象,但不須要所有保存,這個功能就很好用。
__construct() 在類實例化對象的同時執行該函數
__distruct() 在類實例化的對象銷燬時執行
__call()對象調用某個方法,若方法存在,則直接調用;若不存在,則會去調用__call函數。
__clone()克隆對象時被調用。如:$t=new Test();$t1=clone $t;
__toString()打印一個對象的時被調用。如echo $obj;或print $obj;
__isset()檢測一個對象的屬性是否存在時被調用。如:isset($c->name)。
__unset()unset一個對象的屬性時被調用。如:unset($c->name)。
__autoload()實例化一個對象時,若是對應的類不存在,則該方法被調用。
索引是創建在數據庫表中的某些列的上面。所以,在建立索引的時候,應該 仔細考慮在哪些列上能夠建立索引,在哪些列上不能建立索引。通常來講,應該在這些列上建立索引, 例如:在常常須要搜索的列上,能夠加快搜索的速度;在做爲 主鍵的列上,強制該列的惟一性和組織表中數據的排列結構;在常常用在鏈接的列上,這些列主要是一些外鍵,能夠加快鏈接的速度;在常常須要根據範圍進行搜索的列上建立索引,由於索引已經排序,其指定的範圍是連續的;在常常須要排序的列上建立索引,由於索引已經排序,這樣查詢能夠利用索引的排序,加快排序查詢時間;在常用在WHERE子句中的列上面建立索引,加快條件的判斷速度。
一樣,對於有些列不該該建立索引。通常來講,不該該建立索引的的 這些列具備下列特色:
第一,對於那些在查詢中不多使用或者參考的列不該該建立索引。這是由於,既然這些列不多使用到,所以有索引或者無索引,並不能提升查詢速度。相反,因爲增長了索引,反而下降了系統的維護速度和增大了空間需求。
第二,對於那些只有不多數據值的列也不該該增長索引。這是由於,因爲這些列的 取值不多,例如人事表的性別列,在查詢的結果中,結果集的數據行佔了表中數據行的很大比例,即須要在表中搜索的數據行的比例很大。增長索引,並不能明顯加 快檢索速度。
第三,對於那些定義爲text, image和bit數據類型的列不該該增長索引。這是由於,這些列的數據量要麼至關大,要麼取值不多。第四,當修改性能遠遠大於檢索性能時,不該該建立索 引。這是由於,修改性能和檢索性能是互相矛盾的。當增長索引時,會提升檢索性能,可是會下降修改性能。當減小索引時,會提升修改性能,下降檢索性能。因 此,當修改性能遠遠大於檢索性能時,不該該建立索引。
答:三次握手(three times handshake; three-way handshake)所謂的「三次握手」即對每次發送的數據量是怎樣跟蹤進行協商使數據段的發送和接收同步,根據所接收到的數據量而肯定的數據確認數及數據發送、接收完畢後什麼時候撤消聯繫,並創建虛鏈接。
TCP/IP協議中,TCP協議提供可靠的鏈接服務,採用三次握手創建一個鏈接。
(1)第一次握手:創建鏈接時,第三方應用端A發送SYN包(SYN=j)到服務器B,並進入SYN_SEND狀態,等待服務器B確認。
(2)第二次握手:服務器B收到SYN包,必須確認第三方應用A的SYN(ACK=j+1),同時本身也發送一個SYN包(SYN=k),即SYN+ACK包,此時服務器B進入SYN_RECV狀態。
(3)第三次握手:第三方應用端A收到服務器B的SYN+ACK包,向服務器B發送確認包ACK(ACK=k+1),此包發送完畢,第三方應用端A和服務器B進入ESTABLISHED狀態,完成三次握手。
完成三次握手,第三方應用端與服務器開始傳送數據
OOP具備三大特色
一、封裝性:也稱爲信息隱藏,就是將一個類的使用和實現分開,只保留部分接口和方法與外部聯繫,或者說只公開了一些供開發人員使用的方法。因而開發人員只 須要關注這個類如何使用,而不用去關心其具體的實現過程,這樣就能實現MVC分工合做,也能有效避免程序間相互依賴,實現代碼模塊間鬆藕合。
二、繼承性:就是子類自動繼承其父級類中的屬性和方法,並能夠添加新的屬性和方法或者對部分屬性和方法進行重寫。繼承增長了代碼的可重用性。PHP只支持單繼承,也就是說一個子類只能有一個父類。
三、多態性:子類繼承了來自父級類中的屬性和方法,並對其中部分方法進行重寫。因而多個子類中雖然都具備同一個方法,可是這些子類實例化的對象調用這些相同的方法後卻能夠得到徹底不一樣的結果,這種技術就是多態性。多態性加強了軟件的靈活性。
一、易維護
採用面向對象思想設計的結構,可讀性高,因爲繼承的存在,即便改變需求,那麼維護也只是在局部模塊,因此維護起來是很是方便和較低成本的。
二、質量高
在設計時,可重用現有的,在之前的項目的領域中已被測試過的類使系統知足業務需求並具備較高的質量。
三、效率高
在軟件開發時,根據設計的須要對現實世界的事物進行抽象,產生類。使用這樣的方法解決問題,接近於平常生活和天然的思考方式,勢必提升軟件開發的效率和質量。
四、易擴展
因爲繼承、封裝、多態的特性,天然設計出高內聚、低耦合的系統結構,使得系統更靈活、更容易擴展,並且成本較低。
你的第三方應用端的cookie被惡意的用戶截取到,而後向服務器端發送,而且經過驗證,他們就會冒充用戶進行登陸,這就是cookie僞造
防cookie僞造:
如今更通用的作法是使用session來標識用戶,也就是說咱們爲每一個第三方應用端生成一個惟一的id,而後在服務端存儲這個id所對應的狀態。
這樣cookie裏面僅僅保存了這個id,而沒有任何其餘的東西。並且這個id每每還有個特性,它是隨機生成,且每次登錄都會產生一個新的。這樣就更下降了信息泄漏的風險。
PHP做爲腳本語言是頁面結束即釋放變量所佔內存的。 當一個 PHP線程結束時,當前佔用的全部內存空間都會被銷燬,當前程序中全部對象同時被銷燬。GC進程通常都跟着每起一個SESSION而開始運行的.gc目的是爲了在session文件過時之後自動銷燬刪除這些文件.在PHP中,沒有任何變量指向這個對象時,這個對象就成爲垃圾。PHP會將其在內存中銷燬;這是PHP的GC垃圾處理機制,防止內存溢出。 執行這些函數也能夠起到回收做用__destruct /unset/mysql_close /fclose php對session有明確的gc處理時間設定session.gc_maxlifetime 若是說有垃圾,那就是總體的程序在框架使用中,會屢次調用同一文件等等形成的非單件模式等。因此在出來的時候,必要的用_once引用,在聲明類的時候使用單件模式。還有簡化邏輯等等。
抽象類是一種不能被實例化的類,只能做爲其餘類的父類來使用。抽象類是經過關鍵字abstract來聲明的。
抽象類與普通類類似,都包含成員變量和成員方法,二者的區別在於,抽象類中至少要包含一個抽象方法,抽象方法沒有方法體,該方法天生就是要被子類重寫的。
抽象方法的格式爲:abstract function abstractMethod();
接口是經過 interface 關鍵字來聲明的,接口中的成員常量和方法都是 public 的,方法能夠不寫關鍵字public,接口中的方法也是沒有方法體。接口中的方法也天生就是要被子類實現的。
抽象類和接口實現的功能十分類似,最大的不一樣是接口能實現多繼承。在應用中選擇抽象類仍是接口要看具體實現。
子類繼承抽象類使用 extends,子類實現接口使用implements。
session共享:
1.各類web框架早已考慮到這個問題,好比asp.net,是支持經過配置文件修改session的存儲介質爲sql server的,全部機器的會話數據都從同一個數據庫讀,就不會存在不一致的問題;
2.以cookie加密的方式保存在第三方應用端.優勢是減輕服務器端的壓力,缺點是受到cookie的大小限制,可能佔用必定帶寬,由於每次請求會在頭部附帶必定大小的cookie信息,另外這種方式在用戶禁止使用cookie的狀況下無效.
3.服務器間同步。定時同步各個服務器的session信息,此方法可能有必定延時,用戶體驗也不是很好。
php支持把會話數據存儲到某臺memcache服務器,你也能夠手工把session文件存放的目錄改成nfs網絡文件系統,從而實現文件的跨機器共享。
session運行原理:
(1)當一個session第一次被啓用時,一個惟一的標識被存儲於本地的cookie中。
(2)首先使用session_start()函數,PHP從session倉庫中加載已經存儲的session變量。
(3)當執行PHP腳本時,經過使用session_register()函數註冊session變量。
(4)當PHP腳本執行結束時,未被銷燬的session變量會被自動保存在本地必定路徑下的session庫中,這個路徑能夠經過php.ini文件中的session.save_path指定,下次瀏覽網頁時能夠加載使用。
爲何session依賴cookie:
當用戶請求servlet,servlet會首先查看第三方應用端cookie中是否有sessionID,若是有則證實是舊的會話,那麼就經過cookie將sessionID發送到服務器,服務器就會根據sessionID到服務器的內存中查找session對象(由於每一個session都會有一個sessionID來標識session對象),找到以後而後使用。
若是cookie中沒有sessionID這證實是一個新的會話。服務器就會建立一個新的Session對象,而後將SessionID存放早cookie中,經過cookie把sessionID發送到第三方應用端。第三方應用端下一次訪問的時候,就會將SessionID發送到服務器以便再次找到這個session對象,完成會話跟蹤因此若是用戶將cookie關閉session也將會失效。session是依賴與cookie的。
與cookie的區別與聯繫:cookie在第三方應用端保存用戶的信息,而session在服務器上保存第三方應用的信息
session依賴於cookie。若是用戶關閉cookie,則session失效,緣由是sessionID沒法從第三方應用端傳遞到服務端,也不能從服務端傳遞到第三方應用端.
session怎麼設置過時時間:
第一種方法即設置php.ini配置文件,設置session.gc_maxlifetime和session.cookie_lifetime節點屬性值
第二種方法即設置Session時間戳
給定字符串abcdef,寫出反轉函數,將字符串反轉爲fedcba.
function myStrReve($str){
$len = strlen($str);
$result = '';
for($i = $len - 1; $i >=0 ; $i-- ){
$result .= $str[$i];
}
return $result;
}
使用session_start()調用session,服務器端在生成session文件的同時,生成sessionID哈希值和默認值爲PHPSESSID的sessionname,並向第三方應用端發送變量爲(默認的是)PHPSESSID(sessionname),值爲一個128位的哈希 值。服務器端將經過該cookie與第三方應用端進行交互。
session變量的值經PHP內部系列化後保存在服務器機器上的文本文件中,和第三方應用端的變量名默認狀況下爲PHPSESSID的cookie進行對應交 互,即服務器自動發送了HTTP頭:header('Set- Cookie:session_name()=session_id();path=/');即setcookie(session_name(),session_id());當從該頁跳轉到的新頁面並調用session_start()後,PHP將檢查與給定ID相關聯的服務器端存貯的session數據,若是沒找到,則新建一個數據集。
在默認狀況下MYisam是表級鎖,因此同時操做單張表的多個動做只能以隊列的方式進行;
排它鎖又名寫鎖,在SQL執行過程當中爲排除其它請求而寫鎖,在執行完畢後會自動釋放;
死鎖解決:先找到死鎖的線程號,而後殺掉線程ID
1)用戶輸入輸出函數(fopen()file()require(),只能用於調用這些函數有相同腳本的擁有者)
2)建立新文件(限制用戶只在該用戶擁有目錄下建立文件)
3)用戶調用popen()systen()exec()等腳本,只有腳本處在safe_mode_exec_dir配置指令指定的目錄中才可能
4)增強HTTP認證,認證腳本擁有者的UID的劃入認證領域範圍內,此外啓用安全模式下,不會設置PHP_AUTH
5)mysql服務器所用的用戶名必須與調用mysql_connect()的文件的擁有者用戶名相同6)
受影響的函數變量以及配置命令達到40個
smarty是個模板引擎,最顯著的地方就是有能夠把模板緩存起來。通常模板來講,都是作一個靜態頁面,而後在裏面把一些動態的部分用一切分隔符切開,而後在PHP裏打開這個模板文件,把分隔符裏面的值替換掉,而後輸出來,你能夠看下PHPLib裏面的template部分。
而smarty設定了緩存參數之後,第一運行時候會把模板打開,在php替換裏面值的時候把讀取的html和php部分從新生成一個臨時的php文件,這樣就省去了每次打開都從新讀取html了。若是修改了模板,只要從新刷下就好了。
mb_sring、iconv、curl、GD、XML、socket、MySQL、PDO等
能夠經過上傳的文件名獲取到文件後綴,而後使用時間戳+隨機數+文件後綴的方式爲文件從新命名,這樣就避免了重名。能夠本身設置上傳文件的保存目錄,與文件名拼湊造成一個文件路徑,使用move_uploaded_file(),就能夠完成將文件保存到指定目錄。
$smarty.get.變量#顯示經過get方式傳過來的指定變量的值
$smarty.post.變量#顯示經過post方式傳過來的指定變量的值$smarty.cookies.變量#顯示經過cookie中指定變量的值
$smarty.server.SERVER_NAME#顯示server變量值,$_SERVER系列變量$smarty.env.PATH#顯示系統環境變量值,$_ENV系列變量$smarty.session.變量#顯示session中指定變量的值
$smarty.request.變量#顯示經過post、get、cookie中指定變量的值
能夠,Cookie和session都是用來實現會話機制的,因爲http協議是無狀態的,因此要想跟蹤一個用戶在同一個網站之間不一樣頁面的狀態,須要有這麼一個機制----會話機制。
Cookie:將會話信息的保存到瀏覽器端。Session:將會話信息保存到服務器端。
session默認狀況下是基於cookie的,對於session來講,每生成一個sessionid,都會將其發送到瀏覽器端,讓後將其保存到cookie當中。
若是禁用了cookie,則基於cookie的session很差使了,咱們能夠使用get,傳遞SID。
PHP7在PHP5的基礎上又作了一次質的提高,固然改變不少,我這裏以個人總結簡單說下,主要發生了下面這些更改:
移除了一些舊的特性
ZEND引擎升級到Zend Engine 3,也就是所謂的PHP NG
增長抽象語法樹,使編譯更加科學
64位的INT支持
統一的變量語法
原聲的TLS - 對擴展開發有意義
一致性foreach循環的改進
新增 <=>、**、??、\u{xxxx}操做符
增長了返回類型的聲明
增長了標量類型的聲明
核心錯誤能夠經過異常捕獲了
增長了上下文敏感的詞法分析
JS的閉包:
所謂「閉包」,指的是一個擁有許多變量和綁定了這些變量的環境的表達式(一般是一個函數),於是這些變量也是該表達式的一部分。
先看下下面這段代碼
這段代碼有兩個特色:一、函數b嵌套在函數a內部;二、函數a返回函數b。
這樣在執行完var c=a()後,變量c其實是指向了函數b,再執行c()後就會彈出一個窗口顯示i的值(第一次爲1)。這段代碼其實就建立了一個閉包,爲何?由於函數a外的變量c引用了函數a內的函數b,就是說:
當函數a的內部函數b被函數a外的一個變量引用的時候,就建立了一個閉包。
①這裏首先得說下JS的垃圾回收機制:
在Javascript中,若是一個對象再也不被引用,那麼這個對象就會被GC回收。若是兩個對象互相引用,而再也不被第3者所引用,那麼這兩個互相引用的對象也會被回收。由於函數a被b引用,b又被a外的c引用,這就是爲何函數a執行後不會被回收的緣由。
②閉包有什麼做用呢?
1)能夠在全局做用域實現對局部變量的引用
2)能夠一直保存咱們的變量或函數駐留在內存中,而不會被GC回收
③閉包的應用場景
一、保護函數內的變量安全。以最開始的例子爲例,函數a中i只有函數b才能訪問,而沒法經過其餘途徑訪問到,所以保護了i的安全性。
二、在內存中維持一個變量。依然如前例,因爲閉包,函數a中i的一直存在於內存中,所以每次執行c(),都會給i自加1。
我眼中的閉包:
函數中函數,且該函數捆綁了一些局部變量,又因爲全局變量的引用,會致使函數與變量都不會被回收,這就是我眼中的閉包。
PHP中的閉包函數:
在PHP5.3之後,容許建立匿名函數,中匿名函數,也叫閉包函數(closures ),容許 臨時建立一個沒有指定名稱的函數。最常常用做回調函數(callback)的參數。
用好閉包,能夠幫咱們
1 減小foreach的循環的代碼
2 減小函數的參數
3 解除遞歸函數
PHP異步處理 redis的異步處理 數據庫的死鎖、悲觀鎖/樂觀鎖、排他鎖/共享鎖、髒讀、幻讀、API優化/設計、框架底層、主從延遲、redis集羣、