蝦米(354668137) 11:17:35
memcached的數(shù)據(jù)怎么與數(shù)據(jù)庫的數(shù)據(jù)保持同步啊？？
南京-HF(226358522) 11:18:04
手動同步
南京-HF(226358522) 11:18:06
代碼實(shí)現(xiàn)
滄海長風(fēng)(136419390) 11:18:12
兩邊同時(shí)寫
滄海長風(fēng)(136419390) 11:18:31
或者定期寫
滄海長風(fēng)(136419390) 11:18:35
或者特定條件寫
蝦米(354668137) 11:19:23
額，memcached沒有提供相關(guān)的支持嗎
南京-HF(226358522) 11:20:30
有個對mysql的同步的庫
南京-HF(226358522) 11:20:49
是由mysql同步數(shù)據(jù)到memcached的
ζ 過了時(shí)的流行 ?(779014475) 11:21:13
蝦米(354668137) 11:17:35
memcached的數(shù)據(jù)怎么與數(shù)據(jù)庫的數(shù)據(jù)保持同步啊？？
ζ 過了時(shí)的流行 ?(779014475) 11:21:16
同求。
南京-HF(226358522) 11:21:22
他的機(jī)制也就是，寫都是往mysql寫，查詢從memcached里面查詢
ζ 過了時(shí)的流行 ?(779014475) 11:22:29
這樣寫mysql的時(shí)候同樣得更新mc吧。
南京-HF(226358522) 11:22:44
對
ζ 過了時(shí)的流行 ?(779014475) 11:22:50
加mc 本來就是為了減少mysql操作的。。
ζ 過了時(shí)的流行 ?(779014475) 11:22:54
這樣子都沒啥意義了。。
南京-HF(226358522) 11:23:07
應(yīng)該是mysql里面有觸發(fā)器，當(dāng)數(shù)據(jù)有改變，就會同步到memcached
南京-HF(226358522) 11:23:30
就看你以哪個數(shù)據(jù)為主了
南京-HF(226358522) 11:24:04
這樣memcached的目的就是加快你的查詢速度
滄海長風(fēng)(136419390) 11:24:18
這方案根據(jù)自己需求設(shè)定
滄海長風(fēng)(136419390) 11:24:23
組合很多吧
ζ 過了時(shí)的流行 ?(779014475) 11:25:03
最近也碰到。。mysql與mc同步的。。不知道有啥好方案
南京-HF(226358522) 11:25:08
畢竟，查詢用的是最多的。修改或者插入的話，數(shù)據(jù)庫的數(shù)據(jù)必須得邊，所以才有這么個方案。當(dāng)然這個也不一定適合你們的場景，你自己取舍
南京-HF(226358522) 11:26:21
如果你的數(shù)據(jù)，增刪改查都很頻繁那這種就不適合了
ζ 過了時(shí)的流行 ?(779014475) 11:26:54
恩。。這樣的話讀寫都直接對mc操作。。然后定時(shí)同步。。
ζ 過了時(shí)的流行 ?(779014475) 11:27:09
但是蛋疼的就是同步方案。。
ζ 過了時(shí)的流行 ?(779014475) 11:27:25
不好做增量同步。。
滄海長風(fēng)(136419390) 11:27:31
有時(shí)做些冗余是不錯的
ζ 過了時(shí)的流行 ?(779014475) 11:27:36
服務(wù)端用c寫的。