淘宝京东抖音微信都在用的Redis究竟是什么样呢？

哎哟，Redis这玩意儿，我早几年就摸过。
跟你说啊，真不是啥花里胡哨的理论，都是踩坑总结出来的。

记得有年冬天，我们系统访问量蹭蹭涨，数据库都卡得像老式拨号上网。
这时候技术小王就拉着我研究Redis。
他说，你看这货，存东西全在内存里，跟直插内存条似的，搞个查询？嗖一下就出来了。
不像我们用过的MySQL，还得去硬盘里扒拉数据，那得多慢啊。

当时我就纳闷了，内存多贵啊，哪能一直这么烧？小王就给我讲，Redis虽然贵，但它快啊！咱们系统访问量那么大，用Redis做一层缓存，把老访客常看的页面、商品信息先放 Redis 里，用户一访问，直接从 Redis 里捞，不就没压力了？确实，搞了几个月后，系统爽快多了，老板都夸。

Redis分好几种类型，当时我们主要用的是字符串和散列。
你想想啊，用户登录，用个 token 去 Redis 里存用户信息，比如用户ID、昵称啥的，用个字符串就行。
要是存购物车的东西，一个商品一个Hash，啥颜色、尺寸、价格，分门别类放 Hash 里，方便得很。
我们当时一天交易量上千万，要是每个商品都拆成多条记录，那数据库得累死。

还有列表，这个我们用得不多，但我知道，像微信朋友圈那种，新消息往左加（lpush），用户取最新几条往右取（rpop），特别适合这种场景。
抖音那种推荐系统，肯定也用得到。

有序集合那个，我们没用过，但我知道挺厉害的。
像搞个排行榜，按分数排，取前1 0名，分分钟搞定。
不像在数据库里搞个 order by，那得卡半天。

当时我们用Redis做缓存，设置过期时间是常事。
比如验证码，发出去6 0秒内没填对就失效，就用 Redis 设置个过期时间。
还有计数器，像点赞、收藏，直接用 incr key，哎，这个我们用得溜。
一天几百万次点赞，数据库肯定扛不住，但 Redis 轻轻松松。

社交列表那个，我们也没搞那么复杂。
简单场景，比如用户关注的人列表，用 Hash 存也行，用 Set 存也行，看你怎么方便。
判断用户A是不是关注了用户B，直接 sismember 就完了，比去数据库查关联表快多了。

消息队列我们倒是用过。
有次搞活动，系统要发短信给用户，但短信通道慢，直接搞个 List，后端生产消息往里 push，短信那边不停从 List 里 pop，完美解耦。

不过啊，Redis 也有坑。
你想想，它存的是内存啊，万一服务器重启或者内存不够了，你那些数据都没了。
所以我们当时就得配上个持久化方案，比如 RDB 快照或者 AOF 日志，定期备份。
不然真出事儿了，哭都来不及。

还有啊，Redis 单线程，这个我一直不太敢全信。
但小王跟我说，它不是靠多线程跑快，是靠 I/O 多路复用，能同时处理好多连接。
反正我们用着是真快，几百个并发请求过来，Redis 根本不慌。

总之一句话，Redis 真是个好东西，尤其适合做缓存、计数器、排行榜这些高并发的场景。
就是得注意数据丢失和内存问题。
你用着用着，慢慢就懂了。

redis是非关系型数据库吗

Redis是NoSQL数据库，适合高并发场景，如缓存、会话管理和消息队列。
坑：别仅依赖AOF日志，确保RDB快照与AOF结合使用。