業(yè)務(wù)系統(tǒng)中的核心業(yè)務(wù)數(shù)據(jù)變化比較少，但是讀取量卻巨大無比，目前不超過30W條數(shù)據(jù)，但是每日的讀取量都在3000W+以上，整個(gè)業(yè)務(wù)數(shù)據(jù)直接使用Java序列化緩存起來占用的內(nèi)存總量不超過175MB，如果采用Redis/memcache等集中式緩存的話，對存儲(chǔ)空間和并發(fā)量來講都可以接受，只是需要實(shí)現(xiàn)非?？煽康母呖捎眯?，至少要雙機(jī)（主備、雙寫等方式都可以接受），并且要有良好的單點(diǎn)失敗處理機(jī)制（如果Cache掛5秒，連接Cache使用1秒超時(shí)的話估計(jì)系統(tǒng)整個(gè)會(huì)被拖垮）。
鑒于這樣的特征，我考慮使用本地緩存的方式來存儲(chǔ)這些最核心的數(shù)據(jù)，給WEB前端系統(tǒng)提供最可靠、最高效的支持。緩存直接分散到各WEB機(jī)器上去了，可靠性立馬就上來了，由于是本地JVM內(nèi)的數(shù)據(jù)，用Hash存儲(chǔ)的話，性能那也是Redis/memcache之流沒法比了。
接下來需要決絕的問題就是如果同步更新緩存這個(gè)問題了。
有好些可以選擇的方案：
（1）采用OSCache之類的JGroup方式來組播方式更新；
（2）定時(shí)加載DB中有變化的那一部分?jǐn)?shù)據(jù)；
（3）使用支持發(fā)布/訂閱機(jī)制的消息隊(duì)列等；
（4）采用Linkedin的Databus的方式，來直接解析DB的binlog來更新；
個(gè)人傾向于使用方案（3），不光是為了處理這個(gè)業(yè)務(wù)，對于我等互聯(lián)網(wǎng)業(yè)務(wù)來講，要使用異步解耦合的地方實(shí)在是多，有了消息隊(duì)列這個(gè)大刀，很多地方都可以砍一砍了。只是，消息隊(duì)列也實(shí)在是多，比如RabbitMq、ActiveMq、Memcacheq、ZeroMq、MSMQ、Redis、Kafka等等，對于Kafka我是情有獨(dú)鐘的，一直也想使用它做實(shí)時(shí)的日志分析的隊(duì)列，只是很遺憾，業(yè)務(wù)系統(tǒng)中采用的消息隊(duì)列要求是不能丟數(shù)據(jù)、最好有順序、支持持久化存儲(chǔ)消息、可用性要很好，它有點(diǎn)不滿足這個(gè)要求（最新的0.8版本支持這些特性），其中Redis、ZeroMQ也被淘汰了，只剩下RabbitMq、ActiveMq這個(gè)2個(gè)重量級產(chǎn)品和相對較為輕量的Memcacheq、MSMQ了。
看來要把這幾款產(chǎn)品拉出來溜一溜了！
