[PHP] 存儲改造中的邏輯和清理遺留的問題
- 2019 年 10 月 10 日
- 筆記
現象:用戶讀信時,根據路徑的哈希結果,訪問四台服務器中一台請求文件,這四台緩存機器已經下線,訪問不到再去後端存儲訪問浪費了時間
前因:每一封信都是一個文件,存儲在公司內部的分佈式文件系統s3上.因為讀取速度太慢和經常的網絡訪問失敗,後來在s3系統之上新增了nginx緩存代理,imap pop web各端都能使用這幾台緩存.又增加了阿里雲oss存儲,與s3存儲並行.
1. 訪問文件的時候,會根據內部的索引服務返回的location進行判斷,結果是4,5,6,分別代表只存s3,只存oss,s3和oss雙讀.代碼中對location進行判斷,進行讀取訪問文件.當存在雙讀的時候,要根據配置優先讀取oss或者優先讀取s3,讀取不到時再去讀取另外的存儲
2. 在需要讀取s3時,在這之上要先訪問緩存代理.根據指定的哈希規則,對path部分取哈希值,如果在以下四個範圍內就訪問指定的IP '0~25'=>'http://xxx.xxx.88', '25~50'=>'http://xxx.xxx.89', '50~75'=>'http://xxx.xxx.90', '75~100'=>'http://xxx.xxx.91' 哈希算法如下:
function BKDRHash($str) { $hash = 0; $seed = 1313; for ($i=0;$i<strlen($str);$i++) { $hash = ((floatval($hash * $seed) & 0x7FFFFFFF) + ord($str[$i])) & 0x7FFFFFFF; } $hash=$hash & 0x7FFFFFFF; return $hash % 100; }
3. 運維反饋現在訪問文件時是使用的公網域名,把公網域名修改成內網域名,速度會有提升,網絡問題也會減少. 4. 去掉讀信走s3邏輯時候的讀取nginx代理cache部分 5. 在線上單獨拿台機器用於測試,如果沒有問題就全量上線