Redis 这么优秀的原因是什么呢？我们可能会想到它基于内存的存储介质，多路复用的IO方式，以及主模块的单线程模型等等，但往往忽视了一点，就是 Redis 在底层数据结构上的实现。

单线程模型、过期策略、数据恢复、集群模式。

从前有句古话说得好，天将降大任于斯人也，必要先看Redis。

以前古人还说过，窗前明月光，低头Redis。

古人还说过，所有的答案都在源码里。

昨天还有人跟我说，用Redis比Tair申请要方便。

本文主要讲述异地双活方案redis的热备、双写、双向同步的区别和优劣势。并且说明了双写同步方案中redis集群主从数据同步的过程，以及中间件方案遇到的部分问题点，说明最终方案的实现思路和方案。

单机锁主要是为了同步同一进程中各个线程之间的操作。大多数互联网系统都是分布式部署的，当某个资源在多系统之间具有共享性的时候，为了保证大家访问这个资源数据是一致的，那么就必须要求在同一时刻只能被一个客户端处理，不能并发的执行，否者就会出现同一时刻有人写有人读，大家访问到的数据就不一致了。分布式锁，是指在分布式的部署环境下，通过锁机制来让多客户端互斥的对共享资源进行访问。

本文主要是通过分析redis内存结构、介绍内存优化手段，同时结合实践案例，帮助大家在优化内存使用，快速定位redis相关内存异常问题。

如果一定要要求分布式锁百分百可靠，那可以选用Zookeeper或者MySQL作为分布式锁，就能完美的解决锁安全的问题，但是选择了一致性那就要失去可用性，所以Zookeeper或者MySQL实现的分布式锁的性能远不如Redis实现的分布式锁。

本文盘点了Redis消息队列功能的发展历程。

基于生产环境的真实案例，Redis 高风险命令 HSCAN 的踩坑指南。

本文深入源码，介绍了redis的几种基本数据类型，以及新版本的特性。

本文详细介绍redis。

在得物技术体系中，大量使用Redis作为缓存中间件，以应对高并发下的大流量场景。在使用缓存时，不得不考虑数据一致性问题，即保证缓存中的数据和DB始终可以保持一致。常规的解决缓存一致性的方案一般为先修改DB并提交事物，再操作缓存更新或者失效，为了应对极端场景往往会再采用延迟操作的方式进行缓存的二次处理。

但实际开发中，遇到很多代码不规范的场景，在JDBC事务中进行缓存删除或者更新等操作，带来的问题是当JDBC事务未提交就完成了Redis的操作，容易造成二者数据不一致。所以我们思考：既然Redis本身也提供了事务的解决方案，那能不能将Redis事务和DB的事务进行结合，来保证数据一致性的问题呢？接下来我们就带着这个问题看看看Redis事务的实现、使用，最终探索一下将Redis操作结合DB事务使用的可能性。

之前给团队的同事做了一次超容易理解的 Redis 入门分享，这里加以整理修改成文章分享给需要的童鞋。

本文将会从：Redis 使用场景与介绍 -> 数据结构与简单使用 -> 小功能大用处 -> 持久化、主从同步与缓存设计 -> 知识拓展 来书写，初学的童鞋只要能记住 Redis 是用来干嘛，各功能的使用场景有哪些，然后对 Redis 有个大概的认识就好啦，剩下的以后有需要的时候再来查看和实践吧！

本文重点讨论AOF持久化方案，以及其存在的一些问题。

推送平台的特点是并发高、消息量大、送达及时性较高。系统设计中采用Redis集群作为消息存储和中转，以及token信息存储。集群规模大。本文围绕推送系统对Redis集群的使用，遇到的问题及解决方案，优化过程讲解。

​本文将主要分析 Redis 主从复制中的内存消耗过多和堵塞问题，以及 Redis 7.0 (尚未发布) 的共享复制缓冲区方案是如何解决这些问题的。