传统MySQL+ Memcached架构遇到的问题
实际MySQL是适合进行海量数据存储的,通过Memcached将热点数据加载到cache,加速访问,很多公司都曾经使用过这样的架构,但随着业务数据量的不断增加,和访问量的持续增长,我们遇到了很多问题: - MySQL需要不断进行拆库拆表,Memcached也需不断跟着扩容,扩容和维护工作占据大量开发时间。
- Memcached与MySQL数据库数据一致性问题。
- Memcached数据命中率低或down机,大量访问直接穿透到DB,MySQL无法支撑。
- 跨机房cache同步问题。
NoSQL主要用于解决以下几种问题 - 少量数据存储,高速读写访问。此类产品通过数据全部in-momery 的方式来保证高速访问,同时提供数据落地的功能,实际这正是Redis最主要的适用场景。
- 海量数据存储,分布式系统支持,数据一致性保证,方便的集群节点添加/删除。
- 这方面最具代表性的是dynamo和bigtable 2篇论文所阐述的思路。前者是一个完全无中心的设计,节点之间通过gossip方式传递集群信息,数据保证最终一致性,后者是一个中心化的方案设计,通过类似一个分布式锁服务来保证强一致性,数据写入先写内存和redo log,然后定期compat归并到磁盘上,将随机写优化为顺序写,提高写入性能。
- Schema free,auto-sharding等。比如目前常见的一些文档数据库都是支持schema-free的,直接存储json格式数据,并且支持auto-sharding等功能,比如mongodb。
总结:- Redis使用最佳方式是全部数据in-memory。
- Redis更多场景是作为Memcached的替代者来使用。
- 当需要除key/value之外的更多数据类型支持时,使用Redis更合适。
- 当存储的数据不能被剔除时,使用Redis更合适。
|