缓存理解

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信息的维护,数据结构要设计好。

缓存理解_第1张图片



基于 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) -> 返回数据

你可能感兴趣的:(缓存)