根據(jù)當(dāng)前的開發(fā)進(jìn)度,已經(jīng)利用hazlecast做了存儲對象的緩存,但是,對于每次寫文件時(shí)候replica的更新并沒有做緩存,每有一個(gè)寫文件操作請求,都會直接去數(shù)據(jù)庫中更新replica的信息,導(dǎo)致當(dāng)一個(gè)寫動作引發(fā)連續(xù)的寫請求的時(shí)候,就會連續(xù)的去更新數(shù)據(jù)庫,為了降低數(shù)據(jù)庫的讀寫次數(shù),我們想放個(gè)全局的緩存對象在內(nèi)存中,然后異步得將緩存中的replica更新到數(shù)據(jù)庫中。而這樣又會引出另一個(gè)問題,多個(gè)客戶端寫同一個(gè)文件的同步問題,這又該如何在緩存中處理呢?總結(jié)出:1.建立緩存對象,通過線程異步更新數(shù)據(jù)庫以打到減少數(shù)據(jù)庫讀寫次數(shù)來提高性能。2.引出的同步問題該如何處理。 開發(fā)語言,java。
1 回答

慕桂英546537
TA貢獻(xiàn)1848條經(jīng)驗(yàn) 獲得超10個(gè)贊
首先,個(gè)人覺得,用緩存只是來解決可用性問題。如果直接將更新對象放入緩存,這個(gè)方法是不可取的,你必須保證緩存的高可用性。緩存終究只是緩存,沒法保證一致性。其實(shí)你目前的狀況是需要解決分布式鎖的問題,可以嘗試使用隊(duì)列,或者paxos算法去解決?;蛘咴谌志彺嬷杏靡粋€(gè)所標(biāo)記去標(biāo)記你要寫的文件。 其實(shí)你完全沒必要自己去實(shí)現(xiàn)這套邏輯,直接用hdfs或者其他的分布式文件系統(tǒng),加上zookeeper,肯定可以解決你的問題。
添加回答
舉報(bào)
0/150
提交
取消