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