用Redis缓存存储数据，感觉数据存取问题好像没那么难了

知乎回答“为什么说Redis是缓存的首选？”高赞回答者“程序员小富”的分享）

记得刚入行那会儿,每次遇到高并发的场景，比如搞活动秒杀或者首页热点数据加载，数据库就压力山大，动不动就反应慢半拍，甚至直接“罢工”，页面加载那个圈圈转得人心烦，后台监控告警短信滴滴响个不停，那叫一个焦头烂额，当时带我的老大哥看我愁眉苦脸，就说了一句：“别老盯着数据库死磕，试试把常用的、不怎么变的数据丢到Redis里。”我当时还将信将疑，心想这能有多大区别？结果照着做了之后，感觉像是打开了新世界的大门，数据存取这事儿，一下子感觉轻松了好多。

以前从数据库里查点东西,哪怕是最简单的根据ID查用户信息，也得经过建立连接、执行SQL、数据库引擎查找、网络返回这一套流程，要是遇到复杂点的联表查询或者聚合计算，耗时就更没谱了，尤其是当很多人同时来访问，数据库CPU蹭蹭往上涨，磁盘IO也忙得不可开交，响应时间自然就慢下来了。（内容来源：CSDN博客文章“传统数据库与缓存数据库性能对比浅析”中关于数据库瓶颈的论述）

用了Redis之后,情况就大不一样了，它把数据直接放在内存里，读写速度飞快，比从硬盘读写的传统数据库快了不是一星半点，就像是你想找本书，以前得跑去图书馆（数据库）的书架上慢慢翻，现在这本书（热点数据）就常备在你手边的桌面上（内存），随手就能拿到，比如那个让我头疼的用户信息查询，第一次从数据库查出结果后，我顺手就把这个用户对象序列化成JSON字符串，然后用用户ID作为key，存到Redis里，设置个半小时的过期时间，接下来半小时内，再有请求来查这个用户，我程序里就先跑去Redis看看有没有，有的话直接拿出来用，根本不用再去麻烦数据库，这一下子，响应速度肉眼可见地提升了，数据库的压力也瞬间小了很多，那种立竿见影的效果，真的让人很有成就感。

再说说Redis丰富的数据结构,用起来特别顺手，感觉很多业务场景都能对得上号，不像有些缓存工具只能存简单的键值对，Redis提供了好几种“收纳盒”，比如处理排行榜，以前得在数据库里用SQL语句各种group by、order by，数据量一大就慢，用Redis的有序集合（ZSET）就特别方便，直接把用户ID和对应的分数（比如积分）塞进去，它自己就帮我们排好序了，要取前十名就是一个命令的事儿，又快又准。（内容来源：掘金小册《Redis深度历险》中对Redis数据结构的应用场景介绍）

还有列表（List）可以用来做消息队列，虽然可能没专业的MQ那么强大，但处理一些简单的异步任务，比如发站内信、记录操作日志，非常轻量级，集合（Set）可以用来存标签、共同好友之类需要判断是否存在、求交集的场景，哈希（Hash）则适合存储一个对象的多个字段，比如一个用户的姓名、年龄、头像等多个属性，可以一次性存取，比一个个字段存成单独的key要高效和整洁，这些数据结构让缓存不再是简单的“临时储物间”，而更像一个功能灵活的“多功能工作台”，很多数据处理的逻辑可以直接在Redis里完成，进一步减轻了应用服务器和数据库的负担。

Redis的持久化机制也让我觉得挺安心,虽然数据主要是在内存里，但它支持定期把数据快照保存到磁盘（RDB），或者记录所有写操作命令（AOF），这样即使服务器重启了，数据也能恢复回来，不用担心缓存全部丢失导致数据库被瞬间冲垮，虽然我们追求的是缓存的高性能，但有这份“保险”在，用起来心里踏实多了。（内容来源：Redis官方文档关于持久化的说明，以及一些技术社区对RDB和AOF适用场景的讨论）

用Redis也不是说就一劳永逸了,刚开始也踩过坑，比如没设置好过期时间，导致一些冷数据长期占着内存；或者缓存和数据库的数据一致性问题上考虑不周，偶尔会出现数据对不上的情况，但这些问题，随着经验的积累，慢慢也找到了应对的方法，比如设计合理的过期策略、使用缓存失效模式或者延迟双删策略来尽可能保证一致性。

引入Redis之后,我感觉数据存取不再是那个令人望而生畏的难题了，它就像一个高性能的缓冲层，帮我们扛住了大部分的读请求，让数据库能更专注于处理复杂的写入和事务操作，整个系统的响应速度上来了，能支撑的并发量也大了，开发时很多性能优化的思路也打开了，虽然它只是整个技术体系中的一环，但这一环用好了，确实能让整个系统的体验顺畅很多，让人不禁感慨：“原来搞定数据存取，可以这么简单高效。”