缓存理解

用 Redis 缓存客户信息，用 session id 或者有 access_token 做为 key ， expire  时间为 30 分钟。

而网站信息缓存 信息，产品说明等。这样   就把大部分的流量拦截了下来，数据库的 I/O 解放了出来，

客户最先登录后，就把页面显示的信息，个人信息都缓存好了。无论怎么刷新，

退出登录都不会访问到数据库了。   数据库可以专心的等待交易的进行。

当然缓存的信息都是不常改变的，如产品说明，列表等等这些，另外的像客户信息如购买了产品后，

记得更新缓存，因为产品列表，个人信息发生了变化。

在分布式环境里，nginx作为负载均衡，轮询服务器， 用 redis 做为  分布式会话 缓存工具   尤其常见。

再加上一些静态页面的处理，动静态分离，数据库读写分离，Java虚拟机的优化，TOMCAT容器的优化

1.首先明确是不是一定要上缓存，当前架构的瓶颈在哪里，若瓶颈真是数据库操作上，再继续往下看。

2.明确memcached和redis的区别，到底要使用哪个。前者终究是个缓存，不可能永久保存数据（LRU机制），支持分布式，后者除了缓存的同时也支持把数据持久化到磁盘等，redis要自己去实现分布式缓存（貌似最新版本的已集成），自己去实现一致性hash。因为不知道你们的应用场景，不好说一定要用memcache还是redis，说不定用mongodb会更好，比如在存储日志方面。

3.缓存量大但又不常变化的数据，比如评论。

4.你的思路是对的，清晰明了，读DB前，先读缓存，如果有直接返回，如果没有再读DB，然后写入缓存层并返回。

5.考虑是否需要主从，读写分离，考虑是否分布式部署，考虑是否后续水平伸缩。

6.想要一劳永逸，后续维护和扩展方便，那就将现有的代码架构优化，按你说的替换数据库组件需要改动大量代码，说明当前架构存在问题。可以利用现有的一些框架，比如SpringMVC，将你的应用层和业务层和数据库层解耦。再上缓存之前把这些做好。

7.把读取缓存等操作做成服务组件，对业务层提供服务，业务层对应用层提供服务。

8.保留原始数据库组件，优化成服务组件，方便后续业务层灵活调用缓存或者是数据库。

9.不建议一次性全量上缓存，最开始不动核心业务，可以将边缘业务先换成缓存组件，一步步换至核心业务。
10.

刷新内存，以memcached为例，新增，修改和删除操作，一般采用lazy load的策略，即新增时只写入数据库，并不会马上更新Memcached，而是等到再次读取时才会加载到Memcached中，修改和删除操作也是更新 数据库，然后将Memcached中的数据标记为失效，等待下次读取时再加载。

之前做过这个，是用redis的hashset做的，多台一主多从的环境下

启动的时候先从数据库里全部读出来，存到redis里，分主库和备库，有周期刷新和手动刷新机制，周期刷新和手动刷新是刷新备库，刷新完成后主备切换。主库提供查询功能，备库是用来和数据库同步的。查询的时候先从redis查再从数据库查，redis没有就进行更新。

当时遇到的问题主要是

启动加载的时间问题，另外如果使用redis持久化和分布式的话，从磁盘同步和主从同步期间redis都是不能提供查询的。

缓存功能不管发生了什么，核心业务都不应该有影响，这部分功能要剥离好，和redis连接异常，redis宕机都不能影响核心业务，而且要可恢复。

数据量的问题，多线程的问题，还有redis master slave切换时redis信息的维护，数据结构要设计好。

基于 Canal 的 MySql RabbitMQ Redis/memcached/mongodb 的nosql同步 （多读、nosql延时不严格 需求）

1.mysql主从配置

2.对mysql binlog(row) parser 这一步交给canal

3.MQ对解析后binlog增量数据的推送

4.对MQ数据的消费（接收+数据解析，考虑消费速度，MQ队列的阻塞）

5.数据写入/修改到nosql （redis的主从/hash分片）

6.保证对应关系的简单性：一个mysql表对应一个 redis实例（redis单线程，多实例保证分流不阻塞），关联关系数据交给接口业务

数据：mysql->binlog->MQ->redis(不过期、关闭RDB、AOF保证读写性能) （nosql数据仅用crontab脚本维护）

请求：http->webserver->redis(有数据)->返回数据 （完全避免用户直接读取mysql）

                    ->redis(无数据)->返回空

7.可将它视为一个触发器，binlog为记录触发事件，canal的作用是将事件实时通知出来，并将binlog解析成了所有语言可读的工具。

在事件传输的各个环节 提高 可用性 和 扩展性 （加入MQ等方法）最终提高系统的稳定。

传统 Mysql Redis/memcached nosql的缓存 （业务同步） 从cache读取数据->

1.对数据在mysql的hash算法分布(db/table/分区)，每个hash为节点（nosql数据全部失效时候，可保证mysql各节点可支持直接读取的性能）

2.mysql主从

3.nosql数据的hash算法分布(多实例、DB)，每个hash为节点

4.nosql数据震荡处理 （当某节点挂了寻找替代节点算法（多层hash替代节点）。。。）

5.恢复节点数据

6.请求：http->webserver->【对key计算一致性hash节点】->connect对应的redis实例
                                                    
                                                    ->1.redis(有数据)-> 返回数据

			                            ->2.redis(无数据)-> mysql (并写入数据redis) -> 返回数据

	                                            ->3.redis节点挂掉-> 业务寻址hash替代节点 
	                                                                      -> 3.1 redis(有数据) -> 返回数据

									      -> 3.2 redis(无数据) -> mysql(并写入数据redis) -> 返回数据