1. MySql+Memcached 架构的问题
Memcached 采用客户端-服务器的架构，客户端和服务器端的通讯使用自定义的协议标
准，只要满足协议格式要求，客户端 Library 可以用任何语言实现。
Memcached 服务器使用基于 Slab 的内存管理方式，有利于减少内存碎片和频繁分
配销毁内存所带来的开销。各个 Slab 按需动态分配一个 page 的内存（和 4Kpage 的
概念不同，这里默认 page 为 1M），page 内部按照不同 slab class 的尺寸再划分为
内存 chunk 供服务器存储 KV 键值对使用（slab 机制相当于内存池机制, 实现从操作系
统分配一大块内存, 然后 memcached 自己管理这块内存, 负责分配与回收。）
关于 memcached 的内存分配机制：Memcached 内存分配机制介绍
实际 MySQL 是适合进行海量数据存储的，通过 Memcached 将热点数据加载到
cache，加速访问，很多公司都曾经使用过这样的架构，但随着业务数据量的不断增加，
和访问量的持续增长，我们遇到了很多问题：
1.MySQL 需要不断进行拆库拆表，Memcached 也需不断跟着扩容，扩容和维护工作
占据大量开发时间。
2.Memcached 与 MySQL 数据库数据一致性问题。
3.Memcached 数据命中率低或 down 机，大量访问直接穿透到 DB，MySQL 无法支撑。
4.跨机房 cache 同步问题。
关于 memcached 问题：Memcache 存储大数据的问题
众多 NoSQL 百花齐放，如何选择
最近几年，业界不断涌现出很多各种各样的 NoSQL 产品，那么如何才能正确地使用
好这些产品，最大化地发挥其长处，是我们需要深入研究和思考的问题，实际归根结底最
重要的是了解这些产品的定位，并且了解到每款产品的 tradeoffs，在实际应用中做到扬长
避短，总体上这些 NoSQL 主要用于解决以下几种问题
1.少量数据存储，高速读写访问。此类产品通过数据全部 in-momery 的方式来保证高
速访问，同时提供数据落地的功能，实际这正是 Redis 最主要的适用场景。
2.海量数据存储，分布式系统支持，数据一致性保证，方便的集群节点添加/删除。
3.这方面最具代表性的是 dynamo 和 bigtable 2 篇论文所阐述的思路。前者是一个完全
无中心的设计，节点之间通过 gossip 方式传递集群信息，数据保证最终一致性，后者是一
个中心化的方案设计，通过类似一个分布式锁服务来保证强一致性,数据写入先写内存和
redo log，然后定期 compat 归并到磁盘上，将随机写优化为顺序写，提高写入性能。
4.Schema free，auto-sharding 等。比如目前常见的一些文档数据库都是支持
schema-free 的，直接存储 json 格式数据，并且支持 auto-sharding 等功能，比如
mongodb。
面对这些不同类型的 NoSQL 产品,我们需要根据我们的业务场景选择最合适的产品。
Redis 最适合所有数据 in-momory 的场景，虽然 Redis 也提供持久化功能，但实际更
多的是一个 disk-backed 的功能，跟传统意义上的持久化有比较大的差别，那么可能大家
就会有疑问，似乎 Redis 更像一个加强版的 Memcached，那么何时使用 Memcached,何时
使用 Redis 呢?
memcache 和 redis 的比较：
剩余19页未读，继续阅读
评论0