lamp進階

 

  前言：上一文說到，在lamp上簡單的部署應用程序，wordpress和phpmyadmin

  稍稍回顧一下，動態頁面apche發日後端類PHP程序，其PHP自己提供能與後端mysql進行交互的驅動，使得PHP運行中的代碼能與後端mysql互動（解釋器自己無需與mysql交互，事實上是代碼段涉及用戶數據時，才須要進行交互）

1、PHP

  1.1簡介

   PHP是通用服務器腳本編程語言，其只要是用於web開發以實現動態web頁面。PHP自身須要將本身的代碼運行在類虛擬機即解釋器上，以實現跨平臺通用性，不過，這樣一來也就形成了性能降低。

   除此外，它仍是最先實現將腳本嵌入HTML源碼文檔中的服務器腳本語言。就web而言靜態頁面自己的HTML標籤由apache提供（前端設計師），天然，動態頁面便須要後端的應用程序添上HTML標籤（類PHP程序員），但並不是每一個PHP程序員既能懂得PHP又懂得HTML、CSS等前端語言的，爲此PHP專門設立了腳本，將兩者分離，寫前端的寫前端，寫PHP的寫PHP，寫完代碼後交給腳本無需手動添上HTML標籤。

   PHP可以將代碼直接嵌入至HTML中，純HTML交由apache識別，純PHP代碼由解釋器識別。

　　從echo "<h1>hello world!</h1>"到

　　　<h1>

 　　　　<?php>echo "hello world!"?>

　　　</h1>

　PHP的默認配置文件爲/etc/php.ini，/etc/php.d/*.ini

　配置文件（php.ini）在PHP啓動時被讀取，對於服務器模塊的PHP，僅在WEB服務器啓動時讀取一次，對於CGI和CLI版本每次調用都會被讀取。

     注1：以前說過CGI架構時，PHP由服務器生成的子進程響應客戶端，因此本質上配置文件也是在啓動時被讀取

     注2：CLI命令行接口時，每當執行一次命令，CLI程序皆會自動加載配置文件

     注3：PHP5.2+後可以爲每一個PHP版本提供不一樣的配置文件，linux上需在編譯時手動指定配置文件

   1.2 Zend Engine

   早期在沒有Zend Engine的時候，PHP要將源碼轉換爲可執行的機器碼效率十分的底下，需翻譯一句執行一句。Zend Engine出現後將PHP代碼處理過程分解成了兩個階段：分析PHP代碼並將其轉換爲Zend opcode的二進制格式（相似JAVA字節碼），並存儲在內存上；第二階段再使用Zend Engine執行opcode

    

opcode離機器碼僅有一步之遙，且存儲在內存之中，即至關與在未執行以前便開始了翻譯，須要執行代碼的時候進行極少的翻譯步驟即可執行，比之原始的翻譯一句執行一句效率不知道要高尚多少倍。

   1.3 PHP的opcode

   opcode是一種介於源碼和機器碼間的一種特殊的二進制格式，它是由PHP編譯後的一種中間語言，相似JAVA的ByteCode或.NET的MSL。PHP執行PHP腳本代碼通常會通過如下4步驟：

    一、Scanning（Lexing）——將PHP代碼轉換爲語言片斷（Tokens）

    二、Parsing——將Tokens轉換爲簡單而有意義的表達式

    三、Compilation——將表達式編譯成Opcode

    四、Execiution——順次執行Opcode，每次一條，從而實現PHP腳本的功能

        掃描 --> 分析 -->編譯 -->執行

    1.4 PHP加速

    重點來了，上文所述，PHP首先編譯成opcode。基於Php的特殊緩存擴展機制，或能將opcode存儲在共享內存中，從而可讓同一段代碼的後續重複執行時跳過編譯階段以提升性能。本質上來講，這些加速器並不是真正提升opcode的運行速度，而僅是經過分析opcode並將經過從新編排以實現加速的目的。

    常見的PHP加速器

    Xcache：經過將opcode存儲在共享內存中，以便跳過不一樣程序對重複的PHP代碼編譯

    Memcached：高性能分佈式緩存程序。memcached的安裝位置位於應用程序和數據存儲之間，它可以將須要存儲的對象存儲在RAM中。每次緩存命中中將替換到數據庫的一次往返，使得應用程序響應更快、

    APC（Alternative PHP Cache）它對php opcode進行緩存，從而減小執行時從新翻譯的次數。不過這玩意，多年前便中止了維護，並且僅支持到PHP5.3

  1.41 加速演示

   PHP5.5+如下系統PHP還未內置加速可經過編譯Xcache、APC等等手動爲PHP進行加速。5.5+以上以後PHP內置opcache能對opcode進行加速（編譯時需手動指定）。不過這之上仍是有些區別，5.5版本的PHP opcache默認是關閉的需手動修改php.ini，而5.6採用的是模塊化設計，配置文件再也不是php.ini，php.d下的opcache.ini，且默認是開啓。雖然，兩個版本的配置文件不一樣但配置方式大同小異。

;模塊
zend_extension=opcache.so

; Determines if Zend OPCache is enabled
opcache.enable=1

; Determines if Zend OPCache is enabled for the CLI version of PHP
;是否啓動1爲開啓，0爲關閉
;opcache.enable_cli=0

; The OPcache shared memory storage size.
;共享內存大小，單位MBzuizuidopcache.memory_consumptionzuida=128

; The amount of memory for interned strings in Mbytes.
；暫存池中字串符佔內存的總量，單位MB
opcache.interned_strings_buffer=8

; The maximum number of keys (scripts) in the OPcache hash table.
; Only numbers between 200 and 100000 are allowed.
;最大緩存文件數
opcache.max_accelerated_files=4000

; The maximum percentage of "wasted" memory until a restart is scheduled.
;「浪費」內存的最大值，便會重啓調度
;opcache.max_wasted_percentage=5

 

 

   首先對環境進行速度測試，隨意一個php頁面便可，這裏是使用以前安裝的phpmyadmin，200併發1000次請求，

   這裏採用PHP的版本是5.6，不過爲了演示，事先將其關閉了opcache。

    ab -c 200 -n 1000 http://192.168.139.135/pma/

   

  開啓opcache對opcode進行加速。

 

 秒請求數從54.44到119.45近乎一倍的提高。顯然opcode緩存對PHP的加速效果是十分可觀的。

 

2、MySQL

   2.1概念

      數據庫主要是代表如何組織數據的。有着三種主流的組織模型：層次模型（樹狀模型）、網狀模型、關係模型

           層次模型：一個主節點有多個子節點，一個子節點只有一個主節點，並不能讓一個子節點擁有多個主節點。

           網狀模型：在層次模型的基礎上進行改進，可以讓一個子節點擁有多個主節點

           關係模型：在網狀模型上更進一步，解決了網狀模型與應用程序的耦合性問題（應用程序發生改變底層數據庫也隨之改變；底層數據庫發生改變應用程序也得發生改變）。

      關係型數據表現爲二維表結構，由行和列（row、column）構成，某列某行表示某單位。

      關係型數據的設計理論，必須知足六個範式和五個約束。範式之間遞次規範，即每一個範式都是在前一個範式的基礎下進一步規範，不一樣類型數據庫所遵循的設計範式可能有些許區別；約束爲數據庫的硬性要求，數據庫的基本要求，簡單的來講，既是所填的數據必須在必定的範圍裏，不一樣類型數據庫一樣遵循不一樣約束。

     設計範式是在設計期需知足的基本約束，約束是數據庫設計完成以後對每一個表的自我約束。

     凡是應用程序根據設計範式實現，皆被稱爲數據庫管理系統（DBMS），關係型數據庫稱爲RDBMS

     在範式的規範下可以儘量的下降數據冗餘，更重要的是須要修改時可以一次性地修改多個數據。

          第一範式（1NF）：無重複域。全部的域都是原子性的，即數據表中每一列都是不可再分割的。

          第二範式（2NF）：第一範式基礎上，一個或多個字段能惟一標識實體，屬性徹底依賴主鍵。惟一標識是說，至少有一字段能標識其在表中的位置，換言之，沒有徹底同樣的行。徹底依賴的意思是不能存在僅依賴主鍵的一部分。若是存在那麼主鍵必須單獨分離出一個新的實體且創建新表來存儲各個實體的惟一標識，新實體與實體之間爲一對多關係。

          第三範式（3NF）：第二範式基礎上，任何非主屬性不依賴其餘非主屬性，第二表中依賴第一表時，若出現與第一表中相同的字段，則第二表的相同部分的字段必須爲主鍵，表與表以前，新表主鍵能依賴舊錶非主主鍵，相反，新表非主鍵不能依賴舊錶非主主鍵。

     除了這三個範式以外還有歌德巴斯範式、第四範式、第五範式（完美範式），範式越規範數據冗餘越小，一樣開發難度也越大。因此，通常而言知足前三種設計範式便可。

     題外話，成也範式，敗也範式。有一點不能否認的是，因爲數據庫設計需遵循設計範式，一張大的表也就必須拆分紅無數張小表，這樣一來完整的表掃描會給內存及CPU帶來極大的壓力（不過數據庫自己即是爲了不全表掃描而設計的）——論優秀DBA的重要性。

   如今數據庫已經完成設計，以後即是數據庫建立的多種約束。

      六大自我約束（constraint）：向數據表中提供要遵照的限制

           主鍵約束：一個或多個字段的組合，填入的數據必須能在表中惟一標誌本行；不能爲空，即NOT NULL，一個表只能存在一個

           惟一鍵約束：一個或多個字段的組合，填入的數據必須能在表中惟一標誌本行；能爲空，即NULL，一個表能存在多個

           外鍵約束：一個表中某字段可填入數據取決於另外一表的主鍵的數據

           檢查性約束：自我定義的表達式，只有知足該式纔會被寫入

           非空約束：字段不能爲空NOT NULL

           默認約束：當填入的數值爲空時，自動提供值

         

       MySQL是關係型數據庫管理系統的一種開源實現方式。所謂關係型數據庫管理系統這裏便很少闡述，簡而言之即是將原始數據庫中字段抽取出來，從新存儲爲新的數據庫且其值當中包含指向數據塊的鍵。

       RDBMS:

           MySQL：Mysql，MariaDB，Percona-Server

           PostgreSQL：簡稱爲pgsql --> EnterpriseDB

           Oracle

           MSSQL

 2.2架構

     mysql組建：

    mysql可以自我分析、進行優化從新，從新書寫最優的語句。鎖管理系統完成多個程序之間的協做，讀鎖（獨立）和寫鎖（共享）。事務管理器，爲了保證事物的進行，會將事物保存在磁盤上兩次，一爲事物，二纔是存儲。恢復管理器，即是將只存儲在事物日誌的文件，恢復到原始文件中。

     事物：多個操做被看成一個總體對待（ACID原則）。數據庫要進行數據交換之時，事先在一段連續的磁盤空間中寫入事物信息，雙方要嘛是未修改的狀態，要嘛是修改後的狀態，只要有一方不一致便將回滾。

         ACID:

              1）原子性（atomic）               

              2）一致性（Consistency）

              3）隔離性（Isolation）

              4）持久性（Durability）

    用戶經過數據存儲協議與SQL組建進行交互(每一款數據庫所使用的協議皆不一樣)，該協議是一種C/S架構的協議。監聽3306號端口，用戶爲客戶端（Client），SQL爲服務器端（Server)

   其中Client端有兩種交互方式:1)經過程序接口:CLI接口和GUI接口；2)應用編程接口:Open DateBase Connection

3、小結

   從概念簡單地提及了PHP，講到了PHP的Zend Engine和opcode，再介紹了PHP的加速器，以及最後演示了PHP內部Opcache加速Opcode的效果（5.5+）。緊接着即是Mysql，依舊是從簡單的概念提及，Mysql僅是關係型數據庫的一小部分，重點說了數據庫的設計範式，五大基本約束。最後說到了數據庫組建，數據庫並不是一個單獨程序，而是由數個程序聯合而成的小型系統。