設計方案建議(純技術考慮)

2021-08-26 02:08:09 字數 2667 閱讀 3094

一方面系統要求快速、靈活、可擴充套件的特性。隨著一期微語專案完成,並應用到生產環境中,我們可以感覺到微語給使用者帶來的全新感受和體驗的同時,不斷增長使用者量和不斷新增新的功能對伺服器效能提出更加苛刻的要求。這就需要伺服器系統提供給使用者的服務更穩定、更高效!

另一方面由於採用spring +memcache+ mybatis+mysql的軟體架構,在二期的公升級中我們需要用最小改動帶來最大效能提公升與更佳的穩定性。

通用快取特性:

1. 是乙個有界佇列,佇列中物件個數在配置檔案中可配置。

2. 佇列滿後處理機制,比如佇列滿後通過:fifo或lru或lfu踢出物件如何處理.(存入資料庫、拋棄並記錄日誌等)。user做個快取,啟動時載入資料庫中10萬資料,佇列大小為20萬,對於無命中情況對資料庫進行操作並把操作後當前記錄新增到快取中,佇列滿時踢出乙個使用者物件,通過一段時間此快取命中率會逐漸提高(經常在快取中可一定為活躍使用者數,對於捕獲使用者行為極有幫助---資料探勘一部分)。可對佇列做一些監控和分析。(晚上記錄當天活躍使用者數)其實hibernate已經實現物件快取和查詢快取。但個人認為不夠靈活。對於不同應用建立對應快取。

特殊快取--分頁快取:

1. 建立**快取。如果只用一級快取,當快取中資料有更新時,需要全部清掉(hibernater)。而且遍歷的開銷大的驚人。(原來1顆4核hp580機器只能遍歷200次左右)。

2. select id from blogissue where mimier=10447 order by create_time desc limit 0,5 獲取使用者對應的博文。

3. **快取如下:

一級快取是:

key鍵(long型)

value值(型別b)

3id=3的blogissue物件

4id =4的blogissue物件

8id =8的blogissue物件……

二快取是:

key鍵(string型)

value值(arraylist型) size=1000

from blogissue order by create_time desc limit 0,50

arraylist,對應取出來的所有id

from blogissue order by create_time desc limit 50,50

arraylist,對應取出來的所有id

from blogissue order by create_time desc limit 100,50

arraylist,對應取出來的所有id……

**快取:

key鍵(string型)

value值(hashmap)

mimier =10447

key鍵(string型)

value值(arraylist)size=100

userid=10447#0,5

id組成的list

userid=10447#5,5

id組成的list

userid=10447#15,5

id組成的list

……mimier =10256

key鍵(string型)

value值(arraylist)

userid=10256#0,5

id組成的list

userid=10256#5,5

id組成的list

userid=10256#15,5

id組成的list

……mimier =10013

key鍵(string型)

value值(arraylist)

userid=2048#topicid=2008#0,5

id組成的list

userid=2048#5,5

id組成的list

userid=2048#15,5

id組成的list

…………

這種分頁快取好處就是命中率高,可支援每天百萬請求量(非常吃記憶體),並且如果乙個mimier對應資料新增或更新只需:

a. 清除**對應記錄重新新增

b. 清楚二級快取重新新增,對於沒有二級快取需求直接去掉也可以。

c. 更新和新增對應記錄即可。

這樣效率很高,以往我們做了一級和**快取情況查詢,新增和更新資料都很快。需要使用懶漢載入。

對於一對多的關係,我在原來專案中實現把多條記錄(有限記錄)以乙個欄位來儲存,加快資料訪問速度。

記錄日誌格式,我們是這樣用的:

[日期:時間] [執行緒號] [類名] [手機號碼] [引數]

例如:[2010-07-01 14:38:10][thread-2][bindingdaoimpl][13693601659][ip=127.0.0.1,imsi=15046002045,type=1,content=內容,list=,cmd=,dest=,result=0]

這樣日誌格式有利於鎖定問題手機查詢錯誤(可以是呼呼號)。且這種格式我們可以快速做容災處理。

當資料庫當機,資料庫硬體問題情況下使用,在負載均衡器上做重要資訊持久化到檔案。

對於突發時間及時通知到對應人員,可以幫助最快速解決問題。

運用jmx實現重要引數動態更新和載入,在突發事件情況下不需要重啟中介軟體情況改變策略,這個功能與監控和告警模組聯合起來使用效果更佳。

通過使用osgi實現動態載入和解除安裝服務的能力,尤其對於分布式系統策略多元性極有幫助,可根據不同地域、時間指定差異化服務策略。

硬體組網圖

TinyURL設計方案

現在貌似tinyurl很火爆,也逐漸成為一種流行趨勢。對應於php版本的tinyurl也有一些演算法,其實本質上來說是一種hash。除此之外,還有另外一種tinyurl方案 類似於http img.ly 其實這種設計 是最簡單的,沒有使用hash,而是遞增,這種的好 處就是資料庫 可以無限擴充套件,...

許可權設計方案

簡要介紹一下該許可權管理系統的特點,該系統功能上做到了靈活授權,操控細緻,許可權可以細到按鈕及超鏈級別,而且部署簡單,下面談談我自己的設計經驗。該系統主要功能如下 1 自定義操作動作 如增加 刪除 修改 審核等,不再是以前見過的那種粗粒度的 按模組分配許可權,或者稍微先進點的規定死某幾個操作了 2 ...

快取設計方案

redis提供的快取的api,但是在開發階段,如果每個人都自己呼叫原生api實現快取時,由於每個人的水平問題,會導致實現方案千差萬別,同事又很難統一管理維護 通過提供spring的annotation,實現快取方案的統一 target retention retentionpolicy.runtim...