寫教學的最大目的是教會未來的自己

我的PHP&MYSQL

我的網站伺服器確定掛了….

最近我的server出現了一些狀況

整個死機了,經過搶救之後網站算是復原了,server雖然戰時開得起來,但HDD 跟 RAM都有故障

所以我就不維修了

 

目前網站放在另一台主機上,改天再看看怎麼辦好了

 

另外

異機 備分要定期執行阿

Post to Twitter Post to Plurk Post to Facebook Send Gmail

關於PHP7升級這檔事,一個商業網站升級的經驗談

幾個月前,我幫我們公司網站,進行了一次系統性升級,其中包括了CentOS、PHP、tomcat、Java,前前後後花了超過三個月的時間, 當然中間還要持續做網站內容的更新維護,這次僅針對PHP的部分進行說明

因為公司網站有點歷史,所以這次升級是從php5.3升級至7.3,一口氣填補了很多前輩在公司挖得坑,這次我就列舉出一些我所知道的狀況,我的作法是無痛轉移,所以事先把網站內容改進程前後版本都通用後,才用臨時server做切換

1. E_DEPRECATED 是最基本的,他會告訴你使用到的函示庫中那些是即將失效的,看著LOG把所有的code改過一輪吧,這是最簡單,但又是最耗時的,為了解決mysql被廢棄的問題,我整合了網站中所有相關功能成一個class,最後在一次性改成mysqli

2.語法規則更加嚴格了,因為我一次跨多個版本更新,這部分我是在PHP7 的測試機台中,人肉把所有頁面檢查過一遍,確認沒有問題,這部份十分麻煩,因為有時候功能故障,網頁卻能正常顯示,主要的變更有array 跟 字串之間無法自由切換,function 輸入的變數如果不固定一定要給預設值,不再會有預設的false了,這部分算是強制改正工程師們的寫作習慣

3.global regester 根本是個恐怖的坑,因為這個我們卡在PHP5.3 很久了,為了清理這個問題真的是一把鼻涕一把淚,毫無快速搜尋的方法OTZ

4.老的wordpress 版本升級也很恐怖…..不提了….

網站就算經過三組人馬 花了一個多月的時間做最後檢查,網站上線後,還是會發現一些細微的功能出現異常…..

Post to Twitter Post to Plurk Post to Facebook Send Gmail

來自幹股票的回測系統吧-2 抓資料失敗

如上一篇所說,我嘗試擷取yahoo 網站上的股市歷史資訊,但是經過一天的努力後發現無法成功,目前只能改由手動擷取。

在這理說明一下我研究的成果好了

1.首先使用者要在打開yahoo 歷史資訊的時後,會產生兩把key,其中一把放在cookie,一把放在網頁的JS 資訊當中

2.在使用者打開網頁後,JS資訊才會產生下載連結給消費者使用,期中最令人頭大的是網頁中的JS資訊太多太複雜,相同的參數名稱也有四五個,這對於我這種不擅長正則的人來說,完全擷取不能….是了半天搞不定 只好放棄

目前的做只能寫個form 手動上傳資料了….

Post to Twitter Post to Plurk Post to Facebook Send Gmail

來自幹股票的回測系統吧

玩股票也玩了一年了,學習到許多知識,根據許多大師的教導,要來建立自己的交易規則,為了驗證,我應該開始回測我的理論,然後有啥軟體我也不知道,所以我決定 來自幹了,只要有資料,理論上所有數據都算的出來吧?

今天先把網站環境弄出來,為啥用網站? 因為我靠這個吃飯的阿,雖然我沒拿來當做數學計算,但應該OK的,NGINX+PHP+MYSQL,花了10分鐘 把網站弄出來了,因為部方便給大家用,就不公開了XD

今天第一步 找尋資料來源。

本來我打算使用goodinfo 的歷史資訊,但發現他的資料不好處理,說是xls 資料,其實是經過美化的HTML…..,後來我找到美版yahoo 的股票資訊,好用阿

OK 周末來搞吧

然後使用介面UI 啥的,應該就看心情了….XD

參考資料 https://blog.xuite.net/fly888/go/29185880-%E5%BE%9Egoogle+%26+yahoo%E4%B8%8B%E8%BC%89%E8%82%A1%E7%A5%A8%E6%AD%B7%E5%8F%B2%E8%B3%87%E6%96%99

Post to Twitter Post to Plurk Post to Facebook Send Gmail

HTTP轉HTTPS的血與淚,funtime https 轉換記

最近替我們公司網站 從http 轉換成https

這真的事血與淚的故事阿

 

https 的架設流程很簡單,基本上市已下幾個步驟

 

1.購買憑證,這部份我們公司是買全網域都可以用的

2.server 設定

我們是使用nginx  首先 把原先的server 設定加上 憑證,憑證包含一個key 跟一個 crt,crt應該就是憑證,key 是我們自己生成的私鑰

有些廠商不是給crt 而是給pem 不過差不多,另外 還有鎖有上游的憑證,這部分就通通放報crt 後面就OK了

另外 各人建議 把 80 port的網業透過301 通通轉址到 443 port的 https

3.網頁修正

這才是最令人頭大的地方

因為我們公司網站有放大量的外部廠商iframe 或是 js,另外因為歷史遺留問題

許多地方式使用絕對路徑,這在轉換的過程中 出現很多問題

因為在https的網頁中,大多數的瀏覽器會預設不讀取 http的 CSS /JS / iframe,這會導至網站一堆地方出問題

雖然有下列者種語法可以快速解決(功能是強制升級)

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
但還是有一些問題
1.IE 系列不之源
2.舊版safari不支援
3.如果廠商的憑證有問題,還是無法解決

說了那麼多 只是想要說
已後寫code多注意阿
最好不要用絕對路徑
http:// 最好改成 //,這樣系統會自動判定

Post to Twitter Post to Plurk Post to Facebook Send Gmail

強大的資料庫熱備份軟體 xtrabackup

最近我們公司網站碰到一個嚴重問題

就是原先使用的galera 的同步系統時有一個嚴重缺陷,就是 在 DB 故障再重新同步後,會造成另一台DB 也鎖死,雖然仍可以讀取但沒鳥用啊…..

當然這個問題 可以透過 架設三台來解決,但是 這成本太高…..

 

之後我們就找到一個很強的備份系統 xtrabackup

他 是直接在DB的檔案層做備份,針對innoDB 備份 可以做到快速熱備份

可以多線同時備份,可以快速壓縮,可以快速還原

經過測試在50G的資料量 備份可以在兩分鐘內完成,還原也只需要五分鐘(mysqldump大概要10~20倍的時間)

他可以全部備份、局部備份、增量備份,不過並不建議增量備份,他還原很麻煩…

 

不過他還是有缺點的

1.innodb的 ibdata檔案過大時,會備份很久,我在測試時只要兩分鐘,實際上機 要20分鐘….

2.有MYSYIAM 時會有鎖表的備份,所以使用前請小心

3.當備份時碰到鎖表時會備份 拜請小心

4.局部備份跟還原 不是很方便,也不建議使用(有要使用此功能的 請使用2.2版)

 

 

官方網站:https://www.percona.com/doc/percona-xtrabackup/2.4/index.html

Post to Twitter Post to Plurk Post to Facebook Send Gmail

mariaDB+galera 的ㄧ些優缺點

我們公司網站www.funtime.com.tw 已經使用mariaDB+galera 的DB cluseter 系統已經一段時間了

我們是使用兩台DB 的同步運作模式

這套同步系統的最大好處是她的同步運作效率很高,相同的資料量用檔案匯入要4小時’ 但SST 同不只需2小時

先來介紹一下galera的運作原理

galera 是在收到query時先作分析,如果是單純select 就會直接回應給對方,如果是insert這類會更改DB的指令,就會同不丟給每個cluster上的DB

另外galera有一個快取機制,儲存最新更新的資料,如果當某個DB故障重啟時,她會使用其他DB的ˊ快取來回復,這稱作IST  她速度很快

另外還有一個機制叫做SST,這是當 DB掛點帶久超出快取容許範圍,就會作整個DB的重新同步,這時間就會比IST久很多

SST有一個恐怖缺限,就是在同步時,會把另一台DB鎖死,當然為了同步這樣做合理,但碰到我們公司這樣只有兩台DB的情況下就麻煩了

ㄧ台掛了兩台都不能用………

 

當然官方建議的方案是 開三台………..

好吧 這套系統的缺陷就在這了,對於需求不上不下的網站來說這有點浪費

 

Post to Twitter Post to Plurk Post to Facebook Send Gmail

MYSQL 轉mariaDB+galera的兩三事

前幾個月我們公司的網站的資料庫系統從MYSQL 5.1.3轉移到mairaDB ,其中最大的目的就是使用galera 同步技術,這當中碰到一些狀況…..

這一篇 主要就是說明一些我所知道的事,至於怎麼安裝的,請自己google吧…..

 

 

一開始我要說的是”MYSQL 轉 mariaDB 不保證完全相容….”,沒錯就是不完全相容,架設你的網站用的SQL 有點複雜,強烈建議先去測試一下,個人猜測是這樣的,mariaDB 只保證 從他所說的MYSQL版本移植過去是相容的,其他版本號不保證,另外因為mariaDB有些加速的手法會導致部分語法失靈,個人目前碰到兩種狀況 閱讀全文

Post to Twitter Post to Plurk Post to Facebook Send Gmail

MYSQL透過 SQL_CALC_FOUND_ROWS取得資料總筆數

參考自:http://blog.farmer.idv.tw/?p=250

http://ma-bank.com/item/998

 

通常我們碰到資料量大的結果,我們會使用分頁的方式來呈現,那分頁的方式我們會使用到limit的方式,但是這有個缺點,我們不知道解果有多少個,通常我們會下兩次SQL,一次取得資料總量,一次取資料 但這太麻煩了,現在有個快速的好方法

 

在 SELECT  A,B,C FROM….WHERE 語句中 加入 SQL_CALC_FOUND_ROWS

變成

SELECT SQL_CALC_FOUND_ROWS  A,B,C FROM …. ..WHERE

他是參數不是資料欄位所以不需要用逗點隔開

之後只需要用

 SELECT FOUND_ROWS() 就可以取出剛剛SELECT 結果的資料總量,就算是有使用LIMIT也一樣

Post to Twitter Post to Plurk Post to Facebook Send Gmail

提升資料庫 (SQL)效能

引用自 http://blog.xuite.net/j2ee/code/15120677-調校+SQL+以徹底改善應用程式效能

單純引用 給自己看

有些程式員在撰寫前端的應用程式時,會透過各種 OOP 語言將存取資料庫的 SQL 陳述式串接起來,卻忽略了 SQL 語法的效能問題。版工曾聽過某半導體大廠的新進程式員,所兜出來的一段 PL/SQL 跑了好幾分鐘還跑不完;想當然爾,即使他前端的 AJAX 用得再漂亮,程式效能頂多也只是差強人意而已。以下是版工整理出的一些簡單心得,讓長年鑽究 ASP.NET / JSP / AJAX 等前端應用程式,卻無暇研究 SQL 語法的程式員,避免踩到一些 SQL 的效能地雷。

1、資料庫設計與規劃

• Primary Key 欄位的長度儘量小,能用 small integer 就不要用 integer。例如員工資料表,若能用員工編號當主鍵,就不要用身分證字號。

• 一般欄位亦同。若該資料表要存放的資料不會超過 3 萬筆,用 small integer 即可,不必用 integer。

• 文字資料欄位若長度固定,如:身分證字號,就不要用 varchar 或 nvarchar,應該用 char 或 nchar。

• 文字資料欄位若長度不固定,如:地址,則應該用 varchar 或 nvarchar。除了可節省儲存空間外,存取磁碟時也會較有效率。

• 設計欄位時,若其值可有可無,最好也給一個預設值,並設成「不允許 NULL」(一般欄位預設為「允許 NULL」)。因為 SQL Server 在存放和查詢有 NULL 的資料表時,會花費額外的運算動作 [2]。

• 若一個資料表的欄位過多,應垂直切割成兩個以上的資料表,並用同名的 Primary Key 一對多連結起來,如:Northwind 的 Orders、Order Details 資料表。以避免在存取資料時,以叢集索引掃描時會載入過多的資料,或修改資料時造成互相鎖定或鎖定過久。

—————————— 閱讀全文

Post to Twitter Post to Plurk Post to Facebook Send Gmail

Copyright © 2024. All Rights Reserved.

歡迎光臨
初音