海量日志分析系統(tǒng)實踐-資料下載頁
2025-04-30 01:26本頁面
【正文】 分代碼不統(tǒng)一，所以需要改動不少 從測試來看，異步取多個數(shù)據(jù)庫的結(jié)果時，可能會出現(xiàn)返回數(shù)據(jù)不正確，以及執(zhí)行順序錯誤等狀況 (懷疑是和 Apache在一起使用的問題， CLI下正常 ) 多 D點方案測試 :Amoeba Amoeba測試結(jié)果 : 支持高可用性， 負載 均衡。 對 多數(shù)據(jù) 庫讀 取的 結(jié) 果只是分 別執(zhí) 行然后直接拼接 高并 發(fā) 情況下，有 時 會出 現(xiàn) 到 Amoeba的 連 接無響 應(yīng) 高版本下高并發(fā)的性能表現(xiàn)已經(jīng)改善不少 數(shù)據(jù)節(jié)點的優(yōu)化 — 結(jié)果 通過上面幾個方案的測試 , 架構(gòu)調(diào)整選擇 Amoeba Proxy是目前比較合適的方案，數(shù)據(jù)切分可以通過 XML靈活配置，對應(yīng)用層的改動比較小，也相對比較穩(wěn)定 . 由于磁盤做 radio0， 對數(shù)據(jù)的保護不夠，所以要加入備份的考慮及產(chǎn)品線增多后數(shù)據(jù)緩存的利用率 數(shù)據(jù)節(jié)點的優(yōu)化 — 緩存 ?Memcache ?客戶端緩存數(shù)據(jù) ? 頁面靜態(tài)化 ?Php級 opcode緩存 xCache 數(shù)據(jù)節(jié)點的優(yōu)化 — Memcache 數(shù)據(jù)點的優(yōu)化 — Memacahe應(yīng)用 memcache有 1m限制。如果列表太大 ,采取拆分數(shù)據(jù)，用 key+特殊標識來保存整個序列。在獲取的時候批量 get來一次性得到這個列表。 預(yù)處理 :提前生成需求數(shù)據(jù)到 cache中 寫庫 :進行數(shù)據(jù)的預(yù)處理 ,寫入到 memcache服務(wù)器中 讀庫 :根據(jù)時間選擇應(yīng)該已在 cache中的數(shù)據(jù) +最近生成的數(shù)據(jù) 拼成最新數(shù)據(jù)展現(xiàn) 缺點 :維護多個存儲操作增加了應(yīng)用層邏輯復(fù)雜度 優(yōu)點 :減少從數(shù)據(jù)庫讀取海量數(shù)據(jù)的問題及避免重復(fù)計算 數(shù)據(jù)節(jié)點的優(yōu)化 — Memache應(yīng)用優(yōu)化 Memcache自重啟 deamon tools監(jiān)控程序，讓其在掛掉時重啟 開啟數(shù)據(jù)壓縮功能 $memcachesetCompressThreshold 根據(jù)數(shù)據(jù)量大小修改 slab及 factor的值提高內(nèi)存利用率 使用類似 get_multi方法發(fā)送請求 減少客戶端和服務(wù)端的通信 使用到的工具 ?Gearman 用于分布式節(jié)點的管理 ?Memcached 緩存數(shù)據(jù) ?Amoeba 展示層數(shù)據(jù)庫代理 ?Php ?FACEBOOK的 HIPHOP ?INFOBRIGHT的 ICE版 對業(yè)務(wù)需求了解透徹是技術(shù)架構(gòu)的基礎(chǔ) ? 標準化，減少錯誤的發(fā)生 ? 根據(jù)業(yè)務(wù)形態(tài)、網(wǎng)絡(luò)情況選擇適合的技術(shù)架構(gòu)方案 ? 用合適的數(shù)據(jù)庫做適合的事情 ? 以組分布 ,各組之間架構(gòu)一致，便于橫向擴展及管理 ? 最大化減少客戶端到網(wǎng)絡(luò)端的網(wǎng)絡(luò)延時 ? 為系統(tǒng)中不同應(yīng)用選擇適合的硬件 ? 根據(jù)情況選擇開發(fā)環(huán)境、開發(fā)語言及工具等 總結(jié) 謝謝
法律信息相關(guān)推薦
鄂ICP備17016276號-1